五年前，David Crawshaw 问过很多软件工程师一个问题：你写过什么给自己用的程序？答案几乎都是没有。工程师们整天用别人写的程序写程序给别人用。偶尔有人自己写个博客系统、智能家居控制、家庭实验室，都算稀奇事。

Crawshaw 是 Shelley 的作者，一个开源 AI coding agent。他最近在博客上写了一篇文章，核心论点很简单：开发者工具必须开源。 理由不是传统的自由软件情怀，而是一个跟 AI agent 直接相关的技术判断。

两行 prompt 就能个性化任何软件

Crawshaw 给出了两个 prompt。

第一个：

"下载某个软件的源码，在本地构建。修改 agent 的记忆，让它知道以后对这个软件的任何改动都意味着修改源码并替换当前版本。用版本控制记录每次改动的原始动机。"

第二个：

"设置一个夜间 cron 任务，执行以下 prompt：拉取上游变更，把所有本地修改 rebase 到上游最新版本之上。检查软件是否正常工作，替换当前版本。"

这两行 prompt 改变了两件事：启动个性化的门槛消失了，持续维护的负担也消失了。Agent 不止能帮你改代码，还能自动帮你跟进上游版本的更新，把本地修改 rebase 上去。传统软件个性化的 ROI 被这两行 prompt 彻底翻了个。

插件系统过时了，源码就是扩展系统

在 agent 之前，复杂软件需要配置文件、插件系统、扩展 API 来让用户定制。即使像 Vim 这种中等规模的项目，源码也大得让人望而生畏——一个人类工程师要花几周才能消化，所以不可能为了「默认显示行号」这种小事去读完整个代码库然后自己改一版。更合理的做法是做一个配置系统，让所有用户共享，摊薄开发成本。

但 agent 把学习代码和做修改的成本压到了接近于零。Crawshaw 举了一个具体的例子：他写了一个叫 meat.dev 的工具，用 LLM 分析 diff，自动过滤掉不重要的内容（import 块、nil 检查、错误处理），让代码审查者只看「肉」——真正需要人类判断的架构和用例问题。

他想把这个工具集成到 Shelley 里，在 git commit 创建的瞬间就开始后台预处理 diff，等他回来审查时结果已经就绪。在传统模式下，这意味着要研究 VS Code 扩展 API 或者 vimdiff 的集成方式，然后写一堆胶水代码。但有了 agent，一行 prompt 就搞定了：

"把 meat.dev 集成到 Shelley 里。安装最新版本到 PATH。当 Shelley 创建 git commit 时，在后台开始 meat 处理。在 Shelley 的 Diffs 视图上加一个 toggle。如果 commit 还在处理中，显示正在处理。"

唯一不满意的，是模型选了🥩 emoji 当 toggle 按钮。

这个例子直击要害：传统扩展系统的能力边界是 API 设计者预设的，而 agent 驱动的个性化能做到的远超 API 设计者的想象。源码本身就是最好的扩展系统。

点名 Claude Code

Crawshaw 没有含糊其辞。他直接列了名字：Shelley 是开源的，Pi 是开源的，Codex 是开源的。你在用的 agent 是开源的，你就能个性化它。闭源的 agent 不行。

然后他单点了 Claude Code：「Claude Code 是闭源软件，你不能个性化它。它有大量传统风格的定制 hooks。希望你想要的 agent 工作方式刚好落在他们的 hooks 范围内。如果不是，就换一个让你能个性化定制的 agent。」

这段话的潜台词很清楚：在 agent 时代，闭源工具的竞争力不在功能上，在开放性上。如果 agent 本身不能被你修改，那它就不是你的工具，是别人的产品。

集体需要重新发明

Crawshaw 把逻辑推到底：不只是个人工具，整个团队软件栈都适用这个逻辑。为什么一个工程团队要买一个高度可配置的任务管理器（或 CMS、CRM），花时间学习和配置，然后把团队硬塞进它的限制里——而不是直接组装自己需要的功能？

传统软件的开发和分发模式，建立在「个性化成本太高，所以需要把通用功能打包成产品」这个前提上。当个性化成本消失，这个前提也跟着消失。

Crawshaw 自己的博客就是用 Shelley 写的，因为它比定制传统 CMS 容易得多。

参考来源：

• David Crawshaw: Devtools must be open source