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 the agentic IDE that gets better every time you use it — learning your project through
living specs today, and building its own capabilities tomorrow.
We built a rich interface around the pi
coding agent, isolated work into separate workspaces, and gave the agent durable project knowledge
through living specs and reusable skills. Next, we’re adding full extension support, so ThinkRail can
create the tools it needs based on how you actually work.
⭐ If you find ThinkRail useful, give it a star — it helps others discover it.
A pi session and the change it made, scoped to an isolated git-worktree workspace.
What you get
Isolated workspaces. Open any git repo as a project and cut workspaces from it as git worktrees,
each with its own branch and working directory. Agents work in parallel without touching your
checkout; merge the good branch, delete the rest. You can also attach existing worktrees or explicitly
work in the project folder itself. Finished and dormant workspaces settle onto a per-project shelf on
their own — when their pull request merges or closes, or after a quiet week — and come back the moment
you work in them. The topbar shows where the active branch stands against origin and its pull request,
with the next step one click away: publish, push, or open a PR described from the plan, the commits,
your PR template, or an agent-written draft. Once a GitHub PR is open it shows the CI checks and review
decision, and lets you mark it ready, hand failing checks or a diverged branch to the agent, merge it
with the repository’s last-used method, reopen it, or delete the remote branch.
A real IDE around the agent. A splittable workbench of Monaco editor tabs, a Files tree with live git
change marks and a Changed view, terminals, and documents — all scoped to the active workspace. Leave
anchored review comments on files and diffs and send them to a chat as structured context, or open the
worktree in your installed IDE.
Chats that stream like the engine thinks. Several concurrent pi sessions per workspace, each with
its own model and live token and cost readout. Steer a running turn or queue a follow-up, delegate to
subagents, and work a shared plan the agent updates and you edit — each completed step can be committed
and reviewed on its own.
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 on ⌘I — runs the app’s commands with their shortcuts shown, and jumps to a Settings
section. With nothing typed it lists the chats waiting for you.
Specs as ground truth. A connected graph of SPEC.md files lives beside the code; the agent reads,
searches, and maintains it through dedicated spec_* tools, so intent survives the session. The
read-only Specs tool renders the graph as a tree in the workbench.
Skills and workflows. Portable Agent Skills you already keep for other coding agents are read in
place, and bundled workflows guide project setup, design brainstorming, and shipping a pull request —
pushing the workspace branch and opening or updating its GitHub PR through your own gh.
Agent tools beyond the shell. Web research, structured multiple-choice questions the agent asks you
in the chat instead of guessing — with mockups, diagrams and diffs right in the question, your own answer
and notes, a one-click “Discuss” when a question is unclear, and a fully keyboard-driven card — and inline
diagrams, option comparisons and file previews rendered right in the chat — 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 gets and lets you switch each one off (and, for questions, their rich
previews) — and installs 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 packages, their individual extensions and skills, and
pi’s built-ins on or off; open chats pick a change up when their turn ends. The questions and visualize
tools are also published as plain pi packages, one each —
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 add them, and a few presets, from
Settings): ThinkRail asks in the chat before calls the server does not mark read-only (or always allows
the tools you trust in a project), keeps servers a repository
defines off until you approve them, 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
— say a personal ~/.pi/agent-personal — or to pass extra environment variables to the agent, terminals
and MCP servers, set them in Settings → Environment; they apply on the next start. A variable you set
when launching (PI_CODING_AGENT_DIR=… thinkrail) still wins.
Your own model servers. Settings → Providers → Custom servers connects a company LLM gateway or a
model running on your own machine — any OpenAI-compatible server, such as LiteLLM, sglang, vLLM, Ollama,
LM Studio or llama.cpp. Find models lists what the server serves, with the context and capabilities it
reports. The server is saved to pi’s models.json, so its 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. Settings → Language follows your system language or a language you pick; English,
Japanese, Russian, Simplified Chinese, and Spanish are built in. Add a language ThinkRail doesn’t ship yet by
dropping a translated en.json into ~/.thinkrail/locales — it applies as you save. Agent replies and
tool output stay as the agent wrote them.
Your themes. Settings → Appearance ships dark, light, minimal and high-contrast themes. Make your own
by copying a bundled *.theme.json, changing its id and colors, and saving it to ~/.thinkrail/themes.
Your fonts. Settings → Appearance picks the interface and code fonts from the bundled Geist and
JetBrains Mono, any font installed on your computer, or font files you drop in (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, with the spec itself rendered alongside.
Install
ThinkRail ships in two additive forms: a native desktop installer and the self-contained thinkrail CLI.
Both are published with SHA256SUMS on the releases page.
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 its setup executable in place, next to its
payload.
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, and librsvg 2 — Ubuntu 24.04 or newer:
Packaged stable and nightly desktop builds check for updates in the background and offer them in
Settings → Updates: Download → Preparing update → Install & Restart. Nothing is applied until
you choose Install & Restart. ThinkRail then shows the installation’s progress and log, closes, and
reopens on the new version. After the restart it tells you whether the update installed. If it didn’t, it
explains why and offers to retry. The updater appears only when the package carries a valid HTTPS feed
identity; installations that predate that identity need one manual installation first.
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 — 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 host’s
existing Git credentials and SSH keys; existing destination folders are never overwritten.
thinkrail --help lists the flags; 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:
Installed stable and nightly CLI hosts periodically offer Run Update in Settings → Updates. It runs
the host machine’s thinkrail update in the background — also when the UI is open in a browser on another
machine — and a successful update asks you to restart the host manually. You can run thinkrail update
directly on any platform: it re-runs the installer for the installed channel and replaces
<prefix>/bin/thinkrail[.exe]; pass --channel or --version only for an explicit override.
thinkrail uninstall removes the executable, the PATH entry the installer added, and the install metadata,
and asks whether to delete your ~/.thinkrail app state (kept by default — --remove-data deletes it,
-y skips the questions).
Prefer a manual install? Download a binary and 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 require 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, provider connections — tied to
a random installation ID. Usage analytics never include prompts, code, files, credentials, or account
identity. Error reports are also always sent, tied to the same installation ID, so we can fix crashes: 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 and how you found ThinkRail are shared only while Share additional usage
data is on; the switch is offered as a step of first-run setup (or right after you skip it) and lives in Settings → Privacy. When launching from
the command line, thinkrail --no-analytics (or THINKRAIL_NO_ANALYTICS=1) turns additional sharing off for
that run. 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, whatever your analytics settings, and are 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 enter one, 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 rich web UI. pi owns models,
skills, compaction, cost, and session state; the app owns the workspace, the editor, and the wire — it
never assembles prompts behind your back. Three rings:
Engine host — 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.
The wire — packages/contracts: the typed, versioned protocol between host and UI.
UI client — apps/web: React 19 + Zustand + Tailwind v4, shipped independently; it dials a host over
the wire and depends on the contracts only.
goal-and-requirements.md and architecture.md are the
canonical product and design specs. ThinkRail is developed spec-first: a SPEC.md sits beside every
module, and a change that moves a boundary, contract, or decision updates the spec in the same change.
Developing ThinkRail
You need Bun 1.4.4 (the pinned package manager and runtime), Node.js ≥ 22.19 (required by the
in-process pi engine), and an authenticated pi 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.
评论