有一段时间，我的工作流是这样的：在终端里用 Claude Code 写代码，AI 改了一堆文件，但我在同一个终端窗口里没法同时看被修改的文件，得不停地切窗口、切应用，打断了节奏。
我想要的其实很简单：在一个窗口里，终端和 AI 都有，能看到文件也能看到对话，不需要来回跳。
做着做着，就做成了 aitm。
一个决定：AI 是副驾，不是驾驶员
在动手做之前，我先想清楚了一件事：我不想要一个替我操作的终端工具。
市面上很多 AI 终端工具的逻辑是"让 AI 决定跑什么，用户来确认"。AI 坐驾驶席，你坐副驾确认每一步。这个模式在演示里看起来很酷，用起来反而让我有点不安——我不确定 AI 下一步要干什么，也不容易判断该不该点"OK"。
aitm 反过来：AI 是副驾，你开车。AI 能看见你的环境、读你的文件、提出建议，但执行序列是固定的：AI 建议 → 你决定 → 然后才发生。
这不只是态度上的区别，它逼出了整个工具调用设计的边界：只读操作可以自动跑，执行操作必须等人。
这张图是 aitm 的默认布局——文件树、终端、AI 侧栏三栏并排。AI 不是一个弹出窗口，是和终端并排的同事。
为什么选 Tauri + Rust
技术选型上，我直接排掉了 Electron。
不是因为对 Electron 有偏见，是因为一个终端工具空载 150 MB 内存、二进制一百多 MB，这在感知上就是"网页套壳"，不是"系统工具"。既然要做，就做对的那种。
直接上 Tauri 2 + Rust，从一开始就奔着这个方向。前后花了大约两个月。结果是：
| 指标 | Electron（如果走那条路） | aitm 1.0 (Tauri) |
|---|---|---|
| 二进制大小 | 140 MB+ | 5.3 MB |
| 冷启动时间 | 2-4 秒 | 3-5 ms |
| 空载内存 | ~150 MB | ~30 MB |
这组数字不需要太多解释。5.3 MB 和 140 MB 是两种截然不同的工具质感。
架构上：React 19 前端通过 Tauri IPC 和 Rust PTY 层通信，AI 侧栏、工具执行管道、安全层全部在 Rust 侧实现。前端负责 UI，Rust 负责可信度高的那些事。
工具调用闭环：只读流动，执行等人
核心设计是一个闭环，逻辑很简单：
你问 AI → AI 判断需要上下文 → 自动调用只读工具 → 结果喂回 AI → AI 回答
如果 AI 想执行命令 → 停下来 → 等你确认 → 你批准才发生
具体的只读工具有四个：list_files（列目录）、read_file（读文件）、get_terminal_history（拿终端历史）、search_history（搜历史命令）。这四个可以无间断自动执行，AI 不需要问你能不能看。
run_command（执行命令）是另一类。它没有静默执行的代码路径，每次调用都产生一个确认弹窗。
AI 还会自动获得它没开口要的上下文：当前 git 分支、工作目录、dirty 状态、监听端口。一打开侧栏，AI 就知道你在哪个项目、现在什么状态。
这张图是 AI 侧栏——AI 在对话开始时已经知道当前项目，不需要你先解释"我在做什么"。
4 层安全门，把 LLM 幻觉拦在外边
AI 工具执行是我花时间最多的部分。担心的不是什么高明的攻击，而是 LLM 会幻觉出 rm -rf——这是很糟糕的下午。
四道关按顺序过：
L1 黑名单 regex：硬编码约 50 个禁止模式，包括 rm -rf /、fork bomb、dd if=/dev/zero 等。快速、零配置、无条件拦截。就算用户点了"我确认"也没用，这些命令不会跑。
L2 启发式风险评分：命令字符串被一组信号打分——是否触碰 /、是否用重定向 >、是否 pipe 到 sh、是否引用系统目录。输出 DESTRUCTIVE / HIGH / LOW 三档，显示在确认弹窗里。
L3 项目作用域白名单：每个项目可以配一个 globset，限定 AI 可触碰的路径模式。超出作用域的操作在 L4 之前就被标记。可选，但建议开。
L4 用户确认弹窗：每个 run_command 调用都有 modal，显示完整命令、风险等级、作用域检查结果。没有自动放行。
L1 和 L2 在 Rust 中同步执行，零异步开销。L4 是 IPC handler 里的硬门，AI 层没有绕过它的代码路径。
踩的三个坑，哪个都不简单
坑一：Tauri IPC 学习曲线
Tauri 2 的 IPC 通信模型、Rust PTY 层的集成、安全层在 Rust 侧的重建，每一块都是新东西。以为两个月够，实际正好卡着完成。Tauri 2 的 WebView 在 Windows 上的行为和 macOS 上有差异，这也是当前 Windows 版本测试没有 macOS 充分的根本原因。
坑二：Apple 公证卡了将近一周
dmg 打好了，签名通过了，提交 Apple 公证之后——卡住了。提交没有错误，状态一直 pending，重提交也一样。
花了将近一周定位，最后发现是新 Apple 开发者账户首次公证需要在 Apple 后台单独配置某些权限，这个配置步骤在 Apple 文档里没有显眼的说明。不是代码问题，是账户状态问题。
教训：新账户首次走公证流程，多预留一周缓冲。
坑三：Windows 版本测试不足
这是我要坦诚说的一个当前限制：aitm 1.0 在 macOS Apple Silicon 上测试很充分，Windows x86_64 和 ARM64 版本功能可用，但边界场景的测试覆盖没有达到同等水平。
如果你在 Windows 上跑遇到问题，Issues 是真的在看的。
这张图是分屏模式——终端、文件编辑器、内置浏览器可以三栏并排，不需要切应用。
当前状态：能做什么，不能做什么
能做的：
- 终端 + AI 侧栏 + 文件树一体，项目作用域感知
- 4 层安全门保护
run_command执行 - 本地 SQLite 持久化，不需要账号，不上传数据
- 6 家 LLM provider：OpenAI、Anthropic、DeepSeek、通义千问（Qwen/DashScope）、智谱（Zhipu）、Moonshot（Kimi）
- 8 套主题 + 中英 i18n
- CodeMirror 文件编辑器，分屏内置
- macOS Developer ID 公证，Gatekeeper 不报警
当前版本的限制：
- Windows 测试覆盖不如 macOS 充分（这是已知的，1.x 里会改善）
- 没有 Linux 版本（Tauri 可以支持，但没精力做充分测试，宁可不发）
- AI provider 的流式响应在极慢网络下有时会有截断，不算稳定
这张图是设置页——8 套主题和布局选项都在这里，中英文切换也在这里。
下载
平台：macOS Apple Silicon、Windows x86_64、Windows ARM64。
源码在 GitHub，Apache 2.0 开源。有问题、想聊安全模型设计，或者在 Windows 上遇到 bug，Issues 和 Discussions 都开着，我在看。
下一篇
aitm 本身是用 PDLC 工作流开发的——PDLC 是我把多年开发经验整理提炼、今年推出的一套专为 AI 辅助开发设计的 Claude Code 插件。
下一篇打算写：PDLC 的设计哲学，以及"AI 辅助开发"和"让 AI 替你开发"的区别在哪。如果你对怎么在真实项目里落地 AI 辅助有兴趣，那篇应该有东西可以参考。
