ThinkRail：用独立工作区和项目规格文档管理 AI 编程，GitHub 已获 6378 Star

让 AI 同时开发功能、修复测试、尝试另一套实现，最先遇到的问题往往是如何管理这些改动：哪个任务动了哪些文件，为什么这样设计，最后该合并哪一份结果。

ThinkRail 把 pi 编程代理、代码编辑器、终端、Git 差异和项目规格文档放进同一个工作台。 它由 JetBrains InnovationHub 推出，以独立工作区承载任务，再用随代码保存的 Specs 记录项目目标与模块边界，让后续会话有资料可查。项目官网

截至 2026 年 10 月 30 日，ThinkRail 累计获得 6,378 Star、348 Fork；最新稳定版为 v0.3.0。数据来自 GitHub 仓库 API 与 Release API。

图 1：ThinkRail 工作台，将代理会话与代码差异放在同一界面。图片来源：官方 README。

1. 用 Git worktree 分开并行任务

ThinkRail 把本地 Git 仓库视为 Project，再从中创建 Workspace。新建的隔离工作区使用真实的 git worktree，拥有自己的分支和工作目录，聊天、文件、终端及差异视图都跟随当前工作区。

例如，给一个 Web 项目添加登录功能时，可以把“实现登录页”“修复现有测试”“探索另一种交互”放进三个工作区。每个任务在自己的目录中产生改动，开发者检查结果后，再决定合并哪些分支。

它也支持挂接已有 worktree，或由用户明确选择直接在项目目录工作。需要隔离并行改动时，应为任务创建独立工作区。 多个聊天窗口本身不会自动获得不同的文件目录。官方 README

2. 把项目约束写成可检索的 Specs

跨会话开发时，项目背景很容易散落在历史聊天里。ThinkRail 的做法是把规格说明放到代码旁边，通过相互关联的 SPEC.md 文件组织项目目标、架构和模块职责。

代理可以使用专门的 spec_* 工具读取、检索和维护这些文档；开发者则能在只读的 Specs 面板中查看文档树，并打开具体内容。

以支付模块为例，可以把回调验签要求、订单状态转换和接口职责写进规格。后续修改退款流程时，代理有一个持续维护的入口查阅这些约束。这个机制的价值取决于文档是否准确，以及代码变化后有没有同步更新。Specs 设计说明

图 2：Specs 面板展示项目规格文档树，并在旁边打开具体文档。图片来源：官方 README。

3. 在代码和差异上直接给代理反馈

工作台提供可拆分的 Monaco 编辑器、文件树、Git 改动视图和终端。代理生成代码时，开发者可以同时查看文件、运行测试，并在文件或差异上留下带位置的评论，再把评论作为结构化上下文交给聊天。

例如，发现一处修改缺少空值处理，可以直接定位到相关代码提出要求。反馈关联着具体位置，减少了手动复制代码、解释文件路径的步骤。

GitHub 集成还会展示分支远端状态、PR 检查结果与审查状态，并提供推送、创建 PR 等操作。相关工作流使用用户自己的 gh 环境。功能说明

4. 在同一工作台管理模型、技能和工具

ThinkRail 围绕 pi 运行：模型、技能、上下文压缩、费用和会话状态由 pi 负责，ThinkRail 提供工作区及交互界面。每个工作区可以运行多个会话，各自选择模型，并显示 token 与费用信息。

它可以读取已有的 pi 配置，接入模型提供商，复用 Agent Skills，并配置 MCP 服务。界面已内置简体中文；界面语言设置与代理回答语言分别处理。

以上能力见 当前 README。

5. 如何开始使用

1. 选择安装方式。 从 Releases 下载桌面安装包，或安装 CLI 后通过浏览器打开工作台。

2. 连接模型服务。 首次启动时登录 JetBrains AI，或配置 pi 支持的其他提供商凭证；主机需要安装 Git。

3. 打开项目并创建工作区。 选择本地仓库、克隆仓库或新建项目，再为具体任务创建隔离工作区。

4. 给出任务并检查结果。 先明确需求和约束，查看计划、差异与测试结果，再处理分支或 PR。

macOS / Linux 的官方 CLI 安装命令：

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

安装后打开本地仓库，将路径替换为自己的项目：

thinkrail ~/code/my-repo

桌面版支持 macOS 14+ 的 Apple Silicon 与 Intel、Windows x64，以及 Linux x64 / ARM64。Linux 桌面版需要 glibc 2.38+ 和对应 GTK/WebKitGTK 等依赖，官方列出的参考环境为 Ubuntu 24.04 或更新版本。安装说明

可以从一个范围明确的任务开始：

阅读项目规格和登录模块，先列出实施计划，再添加登录失败提示。完成后运行相关测试，说明改动文件和需要人工检查的交互。

6. 维护团队与项目定位

ThinkRail 是 JetBrains InnovationHub 项目，仓库位于 JetBrains 官方 GitHub 组织下，采用 Apache-2.0 许可证。官方介绍将其定位为面向 Pi Coding Agent 的图形化开发环境，希望降低工作流的上手成本，同时保留 pi 的灵活性。官方介绍

团队也用规格驱动的方式开发 ThinkRail 自身：顶层文档定义产品目标和架构，各模块的 SPEC.md 描述职责与边界。涉及边界、契约或设计决策的变更，需要先更新对应规格，再修改代码和测试。贡献指南

7. 技术栈

源码开发固定使用 Bun 1.4.4。CLI 与桌面版复用宿主及 Web UI；应用状态保存在 ~/.thinkrail。README、架构文档、依赖清单

8. 项目活跃度

查询日期：2026 年 10 月 30 日。

来源：仓库 API、Contributors API、commit API、Issue、PR、Release API。

9. 如何参与贡献

1. 反馈问题或提出需求。 先搜索已有 Issue，避免重复。报告缺陷时写明操作、预期、实际结果、系统和相关运行环境版本，并附日志或最小复现；交流使用经验可加入官方 Discord。

2. 准备开发与验证。 Fork 后从 main 创建分支，安装依赖并运行开发环境。提交前执行 bun run lint、bun run typecheck、bun run test；涉及应用的修改还需要按指南运行端到端测试。

3. 提交聚焦的 PR。 同步相关规格和测试，向 main 发起 PR，说明改了什么、为什么改。代码、文档、问题反馈及翻译均有官方贡献入口。

具体要求见 CONTRIBUTING.md。

ThinkRail 适合希望同时管理代理任务、项目约束与代码审查的开发者。可以先拿一个小型 Git 项目试用，观察工作区隔离和规格维护是否适合自己的开发节奏。

项目入口：GitHub · 官网 · Discord

资料与使用说明

1. 本文依据 2026 年 10 月 30 日读取的官方 README、架构文档、贡献指南及 GitHub API 编写，未安装或实测软件。功能描述以当时主分支文档为准，所用安装包应对照对应 Release；官网部分平台说明与当前 README 存在更新节奏差异，本文采用当前 README 的安装要求。

2. Star 与 Fork 为查询时累计值，不代表近期新增。Contributors API 使用 per_page=100&anon=1，返回 30 项且无后续分页，类型为 29 个 User、1 个 Bot，未返回匿名条目；统计包含作者和机器人，不等同于维护团队人数。

3. 累计 commit 为默认分支 commit API 分页末页数，最近 commit 日期取该接口最新 commit 的 committer 时间。Issue 与各类 PR 分别使用 GitHub 搜索 API 查询；已关闭且未合并 PR 单列，不与已合并 PR 混用。动态指标在不同查询时刻可能变化。

4. Release API 的发布时间为 2026-10-29 18:26 UTC，换算为北京时间是 10 月 30 日 02:26；最近 commit 时间也已换算为北京时间。近期提交、合并记录和稳定版发布表明项目仍在推进，不据此保证长期维护或使用稳定性。

5. README 将完整扩展支持列为后续方向。现有内置扩展和工具不代表所有计划能力均已实现；Monaco 编辑器也不代表兼容 VS Code 扩展，架构文档明确当前不托管 VS Code 扩展。

6. Apache-2.0 是项目代码许可证，模型调用需连接用户自己的服务，费用与额度依对应提供商规则。官方 README 说明应用包含基础使用统计与错误报告，额外数据分享可在隐私设置中调整；本地运行不代表所有数据均不出设备。