JetBrains开源ThinkRail：可视化AI编程工作台

JetBrains 最近开源了一个名为 ThinkRail 的项目，它试图解决 AI 编程助手的一个核心痛点：当 AI 帮你写代码时，你如何清晰地看到它到底改了什么、为什么改，以及如何安全地管理这些改动。这个项目在 GitHub 日榜上迅速蹿红，据 B 站 UP 主「每天带你了解一个GitHub新兴项目」的观察，抓取当日星标总数约 4000 颗，单日新增星标约 1204 颗。需要说明的是，这只是当时的快照数据，并不代表长期排名。

把 AI 编程助手装进可视化开发环境

ThinkRail 的定位是一个可视化开发环境，它把 AI 编程助手的能力嵌入到一个统一的工作台中。你可以用自然语言描述任务，然后在同一个界面里查看文件编辑、代码运行、终端输出，并检查 AI 究竟改了哪里。

这种设计思路与常见的“聊天窗口+代码编辑器”分离模式不同。多数 AI 编程工具要求你在聊天框里提需求，然后切换到编辑器看结果，再切回终端跑测试。ThinkRail 试图把这些环节收拢到一张工作台上，减少上下文切换带来的认知负担。对于需要逐步审查 AI 改动的开发者来说，这种安排更为直观。

隔离工作区：给每个任务一张独立工作桌

ThinkRail 的一个重点特性是隔离工作区。简单说，就是给不同的任务各开一张独立的工作桌，底层利用的是 Git 工作树（worktree）机制。每张桌子有自己的分支和文件，方便你分开尝试，再决定合并哪些改动。

举个流程示意（非实测）：给网站加一个登录页。你先开一个工作区，把需求交给助手，然后检查它生成的文件和代码差异，运行测试，最后决定是否合并。这种模式的好处是，AI 的尝试性改动不会污染主分支，你可以同时开多个工作区并行探索不同方案，再择优合并。对于想用 AI 开发小工具、又希望逐步审查的开发者，这个流程比较友好。

Git 工作树（worktree）机制是 Git 2.5 引入的一项特性，它允许同一个仓库同时检出多个工作目录，每个目录关联不同的分支。与传统的 git clone 多份副本不同，工作树共享同一份对象数据库，因此磁盘占用和切换成本更低。

具体来说，你可以用 git worktree add ../feature-login login-branch 在仓库外新建一个目录，该目录自动检出 login-branch 分支，而主工作目录保持不变。这样就能在不 stash 或切换分支的情况下，并行修改多个分支的代码。ThinkRail 正是利用这一机制，为每个 AI 任务创建独立的工作树，从而实现任务间的文件隔离，避免 AI 的试验性改动干扰主分支或其他任务。

聊天与代码差异并排，需求文档与代码同行

在官方界面中，聊天窗口旁边就是代码差异视图，加了什么、改了什么可以对着看。

另一个特点是需求文档的管理。ThinkRail 把项目意图写进文档，和代码放在一起，并提供工具让助手读取和维护。这意味着换一次会话、换一个助手，也有文档可以接着参考，不会因为对话历史丢失而失去项目上下文。

**代码差异视图（diff view）**是版本控制工具中的常见功能，用于并列展示文件修改前后的内容，通常以绿色标记新增行、红色标记删除行。在 AI 编程场景中，diff 视图的意义尤为突出：开发者需要快速判断 AI 究竟改了哪些行、是否引入了意外变更。ThinkRail 将 diff 视图与聊天窗口并排，使得审查过程无需离开对话上下文，降低了在聊天记录和编辑器之间反复切换的成本。这种设计也便于开发者针对具体的 diff 行向助手追问，形成“提问—修改—审查”的闭环。

开源不等于免费，审查测试仍是必修课

需要分清楚的是，工作台开源不等于模型调用全部免费。使用 ThinkRail 需要 Git 和模型服务登录，具体费用取决于你接入的服务。

它也不能保证生成的代码正确，审查和测试仍然要做。这一点值得强调：可视化工作台降低的是管理 AI 改动的门槛，而不是替代开发者对代码质量的判断。项目支持 Windows、macOS 和 Linux 系统。

如果你对 AI 编程感兴趣，又希望同时看见代码、需求和修改过程，ThinkRail 是一个值得从开源仓库开始了解的项目。本期内容依据官方资料介绍，UP 主尚未做安装实测，项目链接可在其简介中找到。

模型服务登录通常指通过 API Key 或 OAuth 等方式接入大语言模型提供商（如 OpenAI、Anthropic 或本地部署的模型服务）。ThinkRail 本身作为开源工作台，不包含模型调用额度，用户需要自行配置所接入服务的凭证，费用也由该服务商按 token 用量或订阅模式收取。这意味着“开源”仅指工作台代码可自由使用和修改，而 AI 能力背后的推理成本仍需用户承担。不同模型服务的定价差异较大，开发者在选型时应将调用成本纳入考量，尤其是在频繁进行代码生成和审查的场景下。