前言¶
2026 年 8 月 3 日，exe.dev 联合创始人、Tailscale 联合创始人 David Crawshaw 在官方博客发表文章《Devtools must be open source》（开发者工具必须开源）。文章很快被推上 Hacker News 热榜，获得 500 分以上讨论热度，评论超过 190 条。Simon Willison 等开发者也在个人博客转述并补充观点。
Crawshaw 的核心论点并不复杂：当 AI Agent 可以直接读源码、改源码、自动 rebase 上游更新时，「插件 API + 配置文件」这套延续了几十年的定制范式，正在被另一种更底层的能力取代——源码本身就是扩展系统。这对正在选 IDE、终端、Coding Agent 的开发者来说，不是哲学辩论，而是实实在在的选型问题。
从「改配置」到「改源码」¶
Crawshaw 在文中回顾了一个长期存在的现象：多数工程师整天用别人写的工具写代码，却很少为自己写程序。偶尔有人用静态站点生成器搭博客、用插件改编辑器主题，但真要 fork 一个 Vim 或 VS Code 来加一行「默认显示行号」，时间成本几乎没人付得起。
AI Agent 改变了这笔账。Crawshaw 给出了两条可复用的 Agent 提示词模板：
- 初始化个性化：拉取某软件的源码、本地编译安装；告知 Agent 今后任何改动都直接改源码；在版本控制里记录每次改动的动机。
- 持续同步上游：用 cron 定时执行——拉取上游更新，将本地改动 rebase 到最新版，验证可用后替换当前安装。
关键不在「能改代码」，而在 Agent 可以自动管理 fork 与上游的同步。过去 fork 一次工具，一年后回来维护是噩梦；现在模型可以承担 rebase、编译、冒烟测试，个性化软件的固定成本和持续成本同时下降。
案例：Shelley、meat.dev 与 VS Code 扩展 API 的对比¶
Crawshaw 用自家产品做了两个具体演示。
Shelley 是 exe.dev 推出的开源 Coding Agent。Crawshaw 团队把上述两条提示词做成了 Agent 的内置 Skill：用户甚至不需要手动配置 cron，直接说「把 Shelley 的 UI 改成高对比度」即可完成个性化。
meat.dev 是 Crawshaw 的个人 side project：用 LLM 过滤 Git diff 中的「噪音行」（import、nil-check、样板 error handling），让人类 reviewer 只看「肉」（架构与业务逻辑）。他希望 meat 在 Shelley 创建 commit 时就在后台预处理 diff，而不是在终端里手动跑命令。
他给 Agent 的提示词大意是：把 meat.dev 集成进 Shelley；安装到 PATH；Shelley 创建 git commit 时在后台启动 meat 处理；在 Diffs 视图加一个切换开关；处理中则提示用户等待。
一条 prompt 搞定。 Crawshaw 特意对比：若走 VS Code 扩展 API，要在 commit 创建的同一时刻触发后台 LLM 预处理，扩展系统的挂载点几乎对不上——更现实的方案可能是另起一个 meatd 守护进程监听文件系统，再让扩展去读缓存。能做成，但「曲率」远大于直接改 Shelley 源码。
这就是他所说的根本差异：经典定制受限于 API 暴露的形状；Agent 定制受限于你有没有源码。
开源 Agent 与闭源 Agent 的分野¶
文章后半段把讨论从编辑器延伸到 Coding Agent 本身。
Crawshaw 认为，Shelley 上这套 Skill 技巧可以平移到其他开源 Agent，例如 Pi；开源版 Codex 理论上也能做，只是 token 开销更大。他甚至反问：Pi 还需要内置扩展系统吗？源码就是扩展系统。
而 Claude Code 被点名为例外的反面：闭源，用户无法让 Agent 改其核心行为，只能在厂商提供的 hooks、配置项里打转。「希望你的需求恰好落在他们的钩子里；否则，换一个能个性化的 Agent。」
HN 热评里，Simon Willison 表达了相近感受：以前 clone 一个项目并编译，摩擦大到常常放弃；现在他会让 Codex 或 Claude Code 去 checkout 并 build，十分钟后回来看结果。他尚未习惯「日常改自己用的软件」，但路径已经清晰。
社区里也有实践佐证：有开发者用 AI 维护 Ghostty 终端的个人 fork——只为加一个图形化设置页，而不是手改配置文件；另有人维护约 6 个工具的私有 fork，靠 Agent rebase 上游，并选择性把 bug fix 贡献回上游。
同时，反对意见同样尖锐：fast-moving 项目 fork 后 merge conflict 仍是现实；「AI slop PR」让上游维护者更不愿合并；插件系统的价值在于可共享、可维护的定制边界，而不是每个人都养一套私有分支。Crawshaw 本人也在回复中承认，exe.dev 这类带大量托管侧能力的平台，全盘开源仍有产品节奏与自托管门槛的问题。
Zed、Ghostty、Cursor：选型地图上的三个坐标¶
原文并未逐一点名 Zed 或 Ghostty，但 HN 讨论与开发者社区实践，把这张地图画得更完整。
Zed 是开源、Rust 实现的高性能编辑器，从设计之初就把 AI 协作写进产品叙事（如 DeltaDB 等方向）。在 Crawshaw 的逻辑下，Zed 属于「Agent 可以 fork、可以改 UI、可以接私有工作流」的一侧。
Ghostty 是 Mitchell Hashimoto 发起的终端模拟器，本身刻意保持简洁、无插件体系。社区里的应对方式恰恰是 Crawshaw 论点的活样本：有人 fork Ghostty，用 Agent 保持与上游同步，并加上内置设置页；也有人像 Henry Chen 那样，用 Ghostty + tmux 跑 Agent、用 Zed 做 diff 审阅——工具链按角色拆分，终端与编辑器都选可组合、可hack 的开源组件。
Cursor 代表另一条路：闭源 AI IDE，集成度高、开箱体验好，但核心行为与模型路由掌握在厂商手中。若你的个性化需求超出官方能力边界，无法像改 Shelley 源码那样「一句话改核心逻辑」，只能等 roadmap 或换工具。
这不是说闭源工具没有价值——Claude Code 在不少场景下 benchmark 表现依然强劲，许多团队也在 Copilot、Cursor、Claude Code 与开源 Agent 之间混用。Crawshaw 强调的是：当 Agent 成为 daily driver，「能否改源码」从 nice-to-have 变成了 first-class 需求。
对开发者的 practical takeaway¶
Crawshaw 的论断可以压缩成三句话：
- 个性化成本骤降：Agent 负责读代码、改代码、rebase、编译；单人维护私有 fork 从「不理性」变成「可日常化」。
- 插件 API 相对贬值：不是插件无用，而是「API 形状不对就永远做不到」的上限，在开源 + Agent 组合下被抬高。
- 闭源 DevTools 的隐性锁：不是今天就要 fork，而是厂商在赌你永远不会行使「改核心」的权利；AI 时代这个赌注值得重新评估。
2026 年选 DevTools，不妨多问一个问题：如果下周 Agent 能改它的源码，我是否拿得到源码？ 答案为否的工具，不是不能用，但要清楚自己买的是「配置空间」，不是「逻辑空间」。
开源 DevTools 在 AI 个性化时代获得的，不是道德优越感，而是结构性的可选权。争论还会持续——fork 维护、许可证、上游 slop、托管侧不可 fork 的子系统，都是真实约束。但方向已经明确：源码访问权，正在成为新一代开发者工具竞争力的一部分。
