JetBrains 开源 AI IDE ThinkRail：多工作区并行与规格驱动开发

什么是 ThinkRail：基于 Pi 的智能体 IDE

ThinkRail 是一款开源智能体 IDE（agentic IDE），完全免费，甚至没有付费计划可以订阅。它建立在 Pi 的基础之上——Pi 提供了底层的智能体能力，而 ThinkRail 在其上叠加了图形界面、网页 UI 和桌面客户端，并属于 JetBrains Innovation Hub 的合作项目。据 B站视频作者 NeuralNine 介绍，该项目以 Apache 2.0 许可证开源，代码托管在 GitHub 上。

安装方式相当直接：访问 thinkrail.ai 选择对应系统下载安装包，或者在终端里通过 curl 命令直接从 GitHub 拉取最新版本。安装完成后有两种启动方式——在终端输入 thinkrail 以浏览器作为前端，或从启动器打开桌面客户端。两种方式功能一致，只是载体不同。

与 Pi 深度集成：零配置继承

ThinkRail 最实用的一点，是它与 Pi 的配置完全打通。如果用户已经在使用 Pi，那么 API 密钥、模型配置、权限设置、技能（skills）都会被自动识别并直接沿用。视频演示中，作者打开新对话时 ThinkRail 自动识别出他配置的 OpenCodeGo 提供商，无需重新填写任何密钥。

权限控制同样继承自 Pi。通过修改 Pi 的 permissions 配置文件，可以让智能体在修改文件前必须请求批准，而 ThinkRail 会立即反映这一变化。演示中当作者要求添加登录页面时，界面弹出"permission required"提示，等待用户确认工具调用。这种一致性意味着 Pi 用户迁移成本几乎为零，同时还能获得额外的图形化能力。

Pi 在这里指的是一套底层智能体运行时/框架，负责模型调用、工具执行、权限校验与技能加载，本身偏命令行和配置驱动，不提供图形界面。ThinkRail 并不重复实现这些能力，而是作为“前端外壳”复用 Pi 的配置目录与权限模型，因此 API 密钥、默认模型、允许的工具范围都只需在 Pi 侧维护一份。这种分层的好处是：Pi 的升级会直接惠及 ThinkRail，用户也不会被锁定在某个 IDE 里——同一套 Pi 配置既能在终端用，也能在图形界面用。理解这层关系，就能明白文中“零配置继承”并非营销话术，而是架构上共用同一份状态的自然结果。

多工作区并行：用 Git worktree 同时开发多个功能

ThinkRail 的核心卖点之一是多工作区（workspaces）并行开发。它本质上是对 Git worktree 的可视化封装：主分支代码保持不变，每个工作区从同一仓库检出独立子分支，各自拥有独立的文件改动，最后再合并回主线。

视频中作者演示了同时开启两个工作区——一个负责待办事项的日历视图，另一个进行复杂的 UI 重设计。任一工作区中的改动都不会污染另一个工作区或 main 分支。当一个功能完成后，点击"settle"即可标记为准备合并。对于需要同时推进多个特性的开发者来说，这种隔离机制比频繁切换分支要清晰得多。

Git worktree 是 Git 2.5 引入的功能，允许从同一个仓库同时检出多个工作树（working tree），每个工作树关联不同的分支，但共享同一份 .git 对象数据库。相比传统的 git stash 或复制整个仓库，worktree 省去了重复克隆的磁盘开销，也避免了切换分支时未提交改动被带走的麻烦。每个 worktree 有独立的 HEAD 和索引，因此可以在一个目录里写功能 A、另一个目录里改功能 B，互不干扰。常用命令包括 git worktree add <路径> <分支> 创建、git worktree list 查看、git worktree remove 清理。ThinkRail 的多工作区正是把这套命令行流程图形化，让用户点几下就能创建或合并 worktree。

规格驱动开发：让 IDE 随使用不断进化

规格驱动开发（spec-driven development）是 ThinkRail 的另一项重点能力。它与测试驱动开发思路相近，区别在于不写测试，而是写规格——用 Markdown 文件正式定义软件应该做什么。典型结构包括 goals and requirements、architecture、front end 等文档，并通过元数据字段（id、type、title、status、parent）建立嵌套关系，让架构文档挂靠在目标文档之下，前端规格再挂靠在架构之下。

ThinkRail 的特别之处在于，这些规格文件的引用已经内置为系统提示，用户不需要像其他智能体那样额外编写 agent.md 来指向规格。侧边栏会自动识别并展示规格树，用户只需说一句"implement the specs"，智能体就会按规格逐条实现并验证。作者也坦言，演示中的规格非常精简，如果项目拥有多个互相连接的完整 Markdown 规格文件，这套流程的价值会更明显——它把"提示词碰运气"变成了结构化的工程流程。

规格驱动开发（Spec-Driven Development） 是伴随 AI 编程智能体兴起的一种工作方法，核心思路是先把“软件应该做什么”写成机器可读、人类可审阅的结构化文档，再让智能体依据文档实现代码，而不是依赖一次性提示词。它和测试驱动开发的差别在于：TDD 用可执行测试作为契约，规格驱动用自然语言规格加元数据作为契约，更适合需求尚在演化、测试难以先行的场景。常见实践包括为每份规格维护唯一 id 和父子层级，让智能体在实现时能追溯“这条代码对应哪条需求”，也方便后续变更时定位受影响的模块。ThinkRail 把规格树内置到侧边栏并注入系统提示，正是这一方法的产品化落地。

差异化审阅：Diff 视图与问题追踪

除了智能体对话和终端，ThinkRail 还提供 Monaco 编辑器的只读预览，用户可以选中代码片段直接右键评论，让智能体针对特定行进行修改。Diff 视图则以标准 Git 风格展示每个文件的改动，方便提交前审查。

审阅（review）功能允许用户把某段代码标记为"问题"，记录待处理事项，之后可以跳转到对应文件位置，或标记为已解决。智能体也会尝试修复被标记的问题。这套机制在长会话、多任务并行时尤其实用，相当于给 AI 编程过程加了一层可追溯的工单系统。

Monaco Editor 是微软开源的浏览器端代码编辑器，也是 VS Code 的编辑器内核，支持语法高亮、代码折叠、多光标、Diff 对比等能力，常被集成到 Web IDE 中。ThinkRail 以只读模式嵌入 Monaco，主要看中它的渲染性能和行级定位能力：用户可以选中特定行或片段直接挂评论，评论会携带文件路径与行号传给智能体，从而把“针对某一行改”这种细粒度指令变成可能，而不必在对话里粘贴大段代码。只读设计则避免了用户在 IDE 内直接编辑后与智能体改动产生冲突，所有修改仍统一走智能体的工具调用与审阅流程。

适合谁用

ThinkRail 的界面风格延续了 Pi 的极简气质，采用 JetBrains Mono 字体，布局紧凑、偏技术向。它最适合已经在使用 Pi、且希望获得更完整项目视图的开发者。如果你的工作流涉及多个并行特性、需要严格的规格文档来约束 AI 输出，或者单纯想要一个比终端更直观的智能体工作台，这个 Apache 2.0 开源项目值得一试。需要说明的是，该视频为 JetBrains 赞助内容，作者表示仍保持独立评价。