一个任务一个 git worktree，一次改动按 hunk 摊开审，项目约定写进随代码提交的规范文件。ThinkRail 是 JetBrains 孵化、Apache-2.0 开源的智能体 IDE，它把"让 AI 改代码"这件事拆成了可检查的几步。

同时让几个 AI 改同一个仓库，麻烦通常不在模型写得对不对，而在它们写在哪。两个会话挤在同一份工作目录里，改到同一个文件就互相覆盖；换一个对话窗口，上一轮定下的约定又得重新讲一遍。ThinkRail 就是冲这两件事来的。

一个任务，一个工作区

它把本地 Git 仓库当项目，再从这个仓库切出工作区。每个工作区是一条独立的 git worktree，有自己的分支和工作目录，文件、终端、差异和聊天都跟着它走。想让一个会话做登录页、另一个修测试，就各开一个工作区，各自改各自的，主干在合并之前一直干净。闲置的工作区会自动收进一个叫 Settled 的搁架，不至于在侧栏里越堆越长。

工作台本身是一套完整的编辑器：代码区用 Monaco，文件树带 Git 变更标记，终端是真的 PTY，并且绑定在当前工作区的目录里。你可以一边看 Agent 改，一边自己跑测试。顶部栏还能直接发布分支、创建拉取请求，并显示 CI 检查的状态。

把规范写进仓库

另一个设计是规范文件。每个模块旁边放一份带前置元数据的规格文档，互相引用连成一张图，记录目标、架构、模块职责和当初为什么这么决定。Agent 有专门的工具去读、去搜、去维护这些文件，界面里的 Specs 面板则把这张图展开给人看。好处很直接：新开一个会话，约定还在文件里，不依赖上一段聊天记录。

这也意味着规范是要跟着代码一起提交的，改架构就得改文档。愿意维护的人能拿到长期收益，不愿意维护的人会觉得多了一道手续。

改动怎么看，决定敢不敢用

ThinkRail 把审查做进了流程。每一轮改动按 hunk 拆开，可以单独保留、单独回退，也可以标成已读；不满意的地方直接在文件或差异上留一条评论，评论会作为上下文交回给 Agent，不用在聊天框里描述"刚才那个文件中间那一段"。

同一个工作区能开多个会话，各自选模型，界面上显示 token 用量和费用。MCP 工具接得进来，非只读的调用在执行前要确认。它还把 pi 这个编程 Agent 放在进程内跑，不替用户拼提示词，模型、花费、上下文压缩都由 pi 自己管，ThinkRail 只负责工作区、编辑器和界面。

对长期维护的老仓库来说，这套流程的价值更明显：接手一个别人写的项目，先把规范过一遍再让 Agent 动手，比直接让它改要稳得多，出问题时也知道该回到哪份文档里改。

0.3.1 这次加了什么

十一月一日发布的 0.3.1 补了几处手感。双击 Shift（或 Ctrl+K）会打开一个命令框，空着的时候列出所有打开项目里等着你回话的会话，最急的排前面；输入几个字母就能搜会话、工作区、项目，或者跳到某个设置页。设置里的 Providers 可以添加自建模型服务，选一个预设或者填地址，点一下查找模型就能接上，密钥不会进浏览器。扩展页可以直接装 pi 包，不用开终端。界面字体和代码字体都能换，代码连字默认关掉了。语言多了俄语，修掉了回复中途崩溃和桌面链接重复打开的问题。

门槛在哪

它要求本机装好 Git，也要有一个能用的模型服务，用自己的 key 或者走平台账号都行。pi 本身是个刻意做小的执行框架，灵活但也意味着上手要花时间；项目还在早期，功能表和路线图都在动。把这些算进去，它更适合天天在真实仓库里干活、又想把 AI 的每一步都看清楚的人。

ThinkRail 真正解决了两个具体问题：并行的会话不再抢同一份工作目录，项目的意图不再只活在聊天记录里。它不试图让 AI 更聪明，而是让 AI 的每一次改动都有出处、有边界、有人签字。