thinkrail 的出现，指向一个被反复讨论却少有人真正解决的矛盾：AI 编程助手越来越强，但 IDE 仍然是一个需要人工配置、插件拼装、主题调优的重型工作台。开发者想要的是“我用自然语言描述意图，工具理解我的工作方式并主动适配”，而不是在几十个设置面板里寻找一个快捷键，或者在聊天窗口和编辑器之间反复复制粘贴。
现有产品大致分两类：一类是 VS Code 系 AI 编辑器，把聊天、补全、代理塞进编辑器，能力强但依然偏重，且定制多停留在配置层；另一类是终端式 AI 编码代理，轻量、灵活，却缺少真实 IDE 的调试、重构、导航和项目管理能力。thinkrail 的定位正好卡在中间：一个轻量、真实的 IDE，围绕你的工作方式自我定制，并把 pi 作为 Vibe coding 的代理运行时。它要解决的不是“再加一个 AI 按钮”，而是让 IDE 本身成为可被意图驱动、可被工作流塑造的开发环境。
核心技术揭秘
从项目描述推断，thinkrail 的架构核心不是单一模型调用，而是一个“意图—代理—工具—反馈—自配置”的闭环。轻量 IDE 负责提供真实编辑、运行、调试能力；pi 负责把自然语言意图拆解为可执行动作；工作流画像负责记录开发者习惯，并反向调整 IDE 的布局、命令和默认行为。
graph TD
A[自然语言意图] --> B{"意图类型"}
B -->|"编码任务"| C[pi 代理循环]
B -->|"环境定制"| D[工作流画像]
C --> E[上下文检索]
E --> F[工具调用]
F --> G[编辑与验证]
G --> H[反馈沉淀]
H --> D
D --> I[IDE 自配置]
I --> A
这条数据流里，最值得关注的是两个技术难点。其一是上下文工程：代理不能把整个仓库粗暴塞进模型，而要做增量索引、相关性排序和变更影响分析，确定“这次修改需要看哪些文件、哪些符号、哪些测试”。其二是变更安全：pi 的每一次编辑都应经过工具调用、差异生成、编译/测试验证和可回滚应用，而不是直接改文件。轻量 IDE 的“轻”很可能来自按需加载的服务化设计：语言服务、调试器、版本控制、AI 代理通过事件总线和统一工具协议协作，避免把全部能力一次性加载。
设计模式上，它更像“代理循环 + 插件化工具 + 配置即代码”的组合。IDE 的自我定制不是魔法，而是把用户行为事件沉淀为声明式配置，再由配置引擎生成布局、快捷键和命令面板。真正的门槛在于：如何让定制可解释、可撤销，并且不破坏 IDE 的稳定性。
功能亮点与差异
thinkrail 的杀手锏是“AI 原生 + 真实 IDE + 自我定制”三件事同时成立。相比 Cursor/Windsurf，它不是 VS Code 的二次发行版，而是更轻的独立 IDE，理论上可以减少插件冲突和历史包袱；相比 JetBrains AI Assistant，它更激进，把代理和工作流适配放到核心位置；相比终端式编码代理，它保留了真实 IDE 的导航、重构、调试和项目模型。
另一个差异点是“围绕工作方式定制”。多数 AI IDE 让用户适应工具，thinkrail 试图让工具适应人：常用操作、代码审查习惯、测试命令、甚至界面布局都可以被画像和配置驱动。这个方向很有想象力，但也要求极高的产品克制，否则“自定制”容易变成“配置地狱”。
应用场景与落地建议
它适合个人开发者、小团队和实验性项目，尤其是需要快速探索遗留代码、搭建原型、把自然语言需求转成可运行变更的场景。生产环境使用要谨慎：一是权限隔离，代理应只访问必要仓库和凭据；二是审计与回滚，所有 AI 变更都要有差异记录和测试门禁；三是成本控制，上下文检索和代理循环容易放大 token 消耗；四是可重复性，关键任务不能依赖不可复现的对话状态。
建议先在低风险模块试点，把 pi 限定在“读多写少”的任务，例如生成测试、补全文档、定位缺陷，再逐步放开重构和跨文件修改。同时要建立人工审查节点，不要把“能跑”当成“正确”。
综合评价
thinkrail 的方向感很好：它没有在“更强补全”上内卷，而是把 IDE 视为可被工作流重塑的环境。优点是理念前沿、真实 IDE 能力完整、定制潜力大；缺点是项目早期、生态和稳定性有待验证，自定制与 AI 代理叠加后学习曲线不低，且容易受 JetBrains 生态和模型能力制约。一句话总结：它更像下一代 AI IDE 的原型，而不是今天就能无脑上生产的成熟工具；值得关注，但要用工程纪律去驾驭。
ThinkRail is an agentic IDE that gets better every time you use it. With Spec-Driven Development support, it learns your project as you work, becoming more capable and helpful over time.
We built a rich interface around the pi coding agent, isolated work into separate workspaces, and gave the agent durable project knowledge through the spec graph and reusable skills. We are now adding full extension support, so ThinkRail can create the tools it needs based on how you work.
Isolated workspaces. Open any git repo as a project and create git worktree workspaces from it, each with its own branch and working directory. Agents can then work in parallel without touching your original codebase; when they finish, merge the results you want to keep and delete the rest. You can also attach existing git worktrees or explicitly work in the project folder.
Finished and dormant workspaces are settled when their pull request merges or closes, or after a quiet week, and return the moment you work in them again.
The topbar shows where the active branch stands against origin, and the state of its pull request. From there you can publish, push, or open a new PR described from the plan, the commits, your PR template, or an agent-written draft.
Once a GitHub PR is open, ThinkRail shows its CI checks and review decision, and lets you mark it ready, merge it, reopen it, or delete the remote branch.
An IDE around the agent. ThinkRail comes with Monaco editor tabs, a file tree integrated with git to show code changes as they happen, terminals, and document support.
Powerful chat features. You can open several concurrent work sessions per workspace, each with its own model. Send a prompt, or queue it as a follow-up, delegate to subagents, and work together on a shared plan: the agent updates it, and you review and edit.
Find anything from one box.⌘K (or a double tap of Shift) opens a palette that finds chats and the messages inside them, workspaces and projects, files in the current workspace, specs, and plans, with a preview pane. It also runs the app’s commands and opens Settings sections, and with nothing typed it lists the chats waiting for you. Type a task and press ⌘↵ to open Create workspace with it as the prompt. Press ⌘⇧F to find text inside the workspace’s files as you type: matches are grouped by file, with match-case and whole-word toggles and a code preview, and ↵ opens the file at that line.
Chats without a project. Ask, plan, or draft without a repository. Each chat gets its own scratch folder under Chats for its files, terminal, and plan, with no branch, review, or pull request. Start one from the Welcome screen, the Create dialog, the palette, or the Chats section; deleting a chat moves its whole folder to the Trash. When a chat turns into work, Continue in workspace has the agent write a handoff summary and starts a new workspace chat with it.
Always up-to-date specifications. A connected graph of SPEC.md files lives beside the code; the agent reads, searches, and maintains it through dedicated spec_* tools, so project intent persists across sessions. The read-only Specs tool renders the graph as a tree in its own view. Type # and a question in the palette to find the spec sections that answer it, in any word order and word form, ranked the way the agent’s own spec_search ranks them. Press ↵ to open the spec at that heading, or ⌥↵ to ask the agent in a new chat when the specs phrase it differently.
Skills. ThinkRail loads your pi skills and any already in your project. It can also import skills from Claude, Codex, and other coding agents: switch them on in Settings → Extensions, or per project in the Skills dialog, which also shows the size of your skill catalog. A large library is listed within a small prompt budget, and the agent finds the rest with a skill search.
Agent tools beyond the shell. Thanks to the ThinkRail GUI, your AI agent can ask you structured multiple-choice questions in the chat instead of guessing, draw Mermaid diagrams, and show comparisons and file previews. When the agent proposes a UI change, it shows a before/after mockup you can comment on like a diff.
Settings → Extensions lists the ThinkRail extensions the agent may use. It can also install any pi package by source (npm, git or a local folder), for you or for a repository, showing what each one adds and letting you switch individual packages, their extensions and skills, and pi’s built-ins on or off.
The tools behind the questions, diagrams, and previews are also published as plain pi packages: pi install npm:@thinkrail/pi-ask-user-question for the questions @thinkrail/pi-ask-user-question) and pi install npm:@thinkrail/pi-visualize for the diagrams and previews @thinkrail/pi-visualize), so a vanilla pi in the terminal gets the same tools.
MCP servers. Connect the MCP servers in your pimcp.json, or configure them in Settings. ThinkRail asks in the chat before calls that the server does not mark read-only, or always allows the tools you trust in a project. Servers a repository defines stay off until you approve them. ThinkRail signs you in to OAuth servers from Settings and shows each chat’s servers next to its background commands and subagents.
Your providers, your credentials. Sign in with JetBrains AI or connect any provider through pi’s own auth. ThinkRail has no accounts of its own.
Your pi setup. ThinkRail reads your existing pi configuration (~/.pi/agent). To use another one (for example, a personal ~/.pi/agent-personal), or to pass extra environment variables to the agent, terminals and MCP servers, set them in Settings → Environment. The configuration becomes active on the next start. Settings → Models also holds pi’s prompt-cache warming (off, only while a run is active, or also between runs); ThinkRail keeps it to active runs unless you choose otherwise, so idle chats don’t spend in the background.
Your own model servers. Go to Settings → Providers → Custom servers and connect a company LLM gateway or a model running on your own machine. Any OpenAI-compatible server fits: LiteLLM, sglang, vLLM, Ollama, LM Studio, or llama.cpp.
The Find models button lists the models available on the server, together with their capabilities. The server is saved to pi’s models.json. The models models appear in the chat model picker, and in the pi CLI alike.
Desktop app or browser. A native desktop app, or the thinkrail CLI that opens the same app in your browser. Both embed the same engine host. App state lives under ~/.thinkrail.
Your language. ThinkRail uses your system language or a language you pick in Settings → Language: English, Japanese, Russian, Simplified Chinese, or Spanish. You can add a language ThinkRail doesn’t ship yet by putting a translated locale file, for example de.json, in ~/.thinkrail/locales. (Tell your AI agent to do it for you!)
Your themes. In Settings → Appearance, you can choose from dark, light, minimal, and high-contrast themes. You can also make your own theme by copying a bundled *.theme.json, changing its id and colors, and saving it to ~/.thinkrail/themes. (Again, tell your AI agent to do it for you!)
Your fonts. In Settings → Appearance, you can pick the interface and code fonts. You can choose from the bundled Geist and JetBrains Mono, any font installed on your computer, and font files kept in ~/.thinkrail/fonts, with fallback fonts for icon glyphs, a code size, ligatures, and a text-weight slider.
*The project's spec graph as a tree (on the right), with the spec itself rendered alongside in the center.*
Installation details
Desktop
Download the thinkrail-desktop-* asset for your platform:
macOS 14+ (Apple Silicon or Intel): open the DMG for your architecture: thinkrail-desktop-darwin-arm64.dmg or thinkrail-desktop-darwin-x64.dmg.
Windows x64: extract the complete setup ZIP, then run the executable.
Linux x64 / ARM64: extract the setup tarball and run installer. Desktop builds need glibc 2.38+ with GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3, librsvg 2, and Ubuntu 24.04 or newer, plus libnotify-bin for desktop notifications:
There are two update channels: stable and nightly. If the ThinkRail desktop app, you can check them in Settings → Updates: Download → Preparing update → Install & Restart.
Command line
The installer downloads the right binary, verifies its SHA-256 checksum, and puts thinkrail on your PATH.
Then run thinkrail, optionally with a git repo to open as a project:
thinkrail ~/code/my-repo
thinkrail needs git on your PATH and a model provider. You can sign in with JetBrains AI from the app or use your own provider credentials. The first launch walks you through connecting a provider and picking a project; Start a new project creates an empty git repository (under ~/thinkrail by default), so you don’t need one ready.
Add project → Clone repository… clones a Git URL into a new folder on the computer running ThinkRail and opens it as a project. Choose the parent folder and folder name, optionally limit the history depth, or cancel an in-progress clone.
GitHub and other Git hosts work with the Git credentials and SSH keys already on your machine.
thinkrail --help lists the flags, and thinkrail --version prints the build.
Nightly builds, pinned versions, updates, and uninstall
The installer takes `--channel stable|nightly` and `--version`; a pinned version must belong to the
selected channel:
If you keep ThinkRail running, it periodically checks for updates and, when it finds one, shows an “Update available” button in the GUI.
thinkrail uninstall removes the executable, the PATH entry the installer added, and the install metadata; it then asks whether to delete your ~/.thinkrail app state (kept by default; --remove-data deletes it, and -y skips the questions).
If you prefer a manual install, download a binary and the SHA256SUMS from the releases page, and verify the checksum. For self-update to work, rename it to thinkrail (thinkrail.exe on Windows) and place it at <prefix>/bin/thinkrail[.exe]; a binary kept under its release filename or elsewhere must be replaced manually or reinstalled with the script.
Platform notes
Platform
Desktop
CLI
macOS Apple Silicon / Intel
DMG
signed binary
Windows x64
signed setup executable and app binaries
signed .exe
Linux x64 / ARM64
setup tarball, unsigned
unsigned
JetBrains signs the Windows CLI, the desktop setup executable, and every executable and DLL the desktop app installs. The macOS CLI is signed but not yet notarized. Signed and notarized desktop DMGs must come from the coordinated JetBrains service pipeline; older published DMGs and locally built packages may still be unsigned and blocked by Gatekeeper. Linux artifacts are unsigned.
Analytics & privacy
ThinkRail apps collect basic usage events: launches, chat creation, message sends, and provider connections. The data is tied to a random installation ID. Usage analytics never include prompts, code, files, credentials, or account identity. Error reports are always sent as well, tied to the same installation ID, so we can fix crashes: they include the error type and code, and where in ThinkRail’s own code it happened. They never include error messages, file paths, names, URLs, or anything from your projects or extensions.
Additional product usage is shared only while Share additional usage data is on; the switch is offered during first-run setup (or right after you skip it) and lives in Settings → Privacy. From the command line, thinkrail --no-analytics (or THINKRAIL_NO_ANALYTICS=1) turns additional sharing off for that launch. With additional sharing on, a packaged build may open the ThinkRail blog in your browser once to link your installation to the website visit that brought you here - only where you accepted marketing cookies on the website or no consent is required, and that link expires after 30 days.
Feedback surveys are separate from usage analytics. ThinkRail may invite you to a short survey, and you can also open it from Settings → Feedback. Your answers, including anything you type, are sent to the ThinkRail team only when you press Send, and tied to the same random installation ID, not to your name or account. Please don’t include secrets, code, or personal data. To have your answers deleted, email [email protected].
The ThinkRail apps and the ThinkRail website (thinkrail.ai) use PostHog Inc. services for analytics. The website also uses PostHog Surveys to collect feedback after a desktop download and, only if you choose to provide it, your email address, which is used to ask for further feedback and to send product updates. PostHog’s privacy policy is at posthog.com/privacy.
Under the hood
ThinkRail is a thin host that runs pi in-process and bridges it to a web UI. pi owns models, skills, compaction, cost, and session state. ThinkRail owns workspace management, the GUI, and the contracts between the engine and the GUI.
Engine (packages/server + packages/shared): a Bun.serve HTTP+WS host with one in-process pi session per chat, launched by apps/cli or apps/desktop.
Contracts (packages/contracts): the typed, versioned protocol between the engine and the GUI.
GUI (apps/web): React 19 + Zustand + Tailwind v4, shipped independently; it communicates with the engine through the contracts.
goal-and-requirements.md and architecture.md are the product and design specs. ThinkRail is developed spec-first: a SPEC.md sits beside every module, and when a change made by an AI agent moves a boundary or a contract, the spec is updated in the same change.
Developing ThinkRail
You need Bun 1.4.4 (the pinned package manager and runtime), Node.js ≥ 22.23.4 (the in-process pi
engine needs ≥ 22.19; the website build and typecheck need ≥ 22.23.4 for Astro 7.4), and an AI provider for
agent work.
git clone https://github.com/JetBrains/thinkrail.git
cd thinkrail
bun install
bun run dev # host + web client together; Ctrl+C stops both
bun run --filter @thinkrail/cli dev # browser launcher
bun run build:binary # standalone CLI artifact
bun run desktop:dev # package and open the Electrobun app
bun run desktop:build # package without opening it
CONTRIBUTING.md covers the checks, the end-to-end suites, desktop packaging, and the repository layout.
评论