夜雨聆风过去十年，我们被一个假设牢牢绑住：复杂软件必须设计成“可配置”的。
想要个性化？去翻设置项，去找插件市场，去读那本比砖头还厚的配置文档。Vim 光是配置文件就养活了几十本教程书，VS Code 的扩展商店里躺着几万个插件——每个插件都试图满足“一部分人”的需求，而没有任何一个能精确满足“你”的需求。
为什么大家忍了这么多年？因为改源码的成本太高了。读一个中型项目的代码要几周，改完还要自己维护，没有十几个人一起用，这笔账怎么算都不划算。
但现在，这笔账算不过来了。
两个 Prompt，改写了个性化软件的 ROI
exe.dev 的 David Crawshaw 在博客里讲了一个很有意思的观察。五年前他做了一场“田野调查”，问身边的工程师：你有没有写过只给自己用的程序？ 答案大多是“没有”。工程师们整天写程序给别人用，但自己用的工具，全是现成的。
他当时的结论是：这很合理。给自己写软件，投入产出比太低了。写一天，修一年，不如用现成的。
但他说，现在情况完全变了。变化来自两个“平平无奇”的 Prompt：
下载 <软件> 的源码并本地构建。
修改你的 agent 记忆，让它知道：以后任何对这个软件的修改，
都意味着改源码并替换当前版本。在版本控制里记录原始动机。第二个更重要：
设置一个 nightly cron 任务：
拉取 <软件> 的上游更新，把本地改动 rebase 到上游之上。
检查软件正常工作，然后替换当前版本。看懂这两条指令的含金量了吗？
第一条解决“上手”——agent 读完源码，想改哪就改哪，不用等官方开放插件接口。第二条解决“持续”——以前你自己改源码，最怕的就是上游发新版，一 rebase 全是冲突，最后只能放弃维护。现在这个脏活累活，agent 每天晚上自动干完了。
个性化软件的 ROI 被同时从两个方向改善了：启动成本归零，维护成本也归零。
meat.dev 的故事：一个 Prompt 顶一套扩展 API
Crawshaw 分享了一个具体的例子，我觉得比任何抽象讨论都有说服力。
他写了个叫 meat.dev 的小工具：AI 生成的代码在 push 之前，他还是要亲自 review 的，但现在的模型在“琐碎正确性”上已经远超人类——nil 检查、错误处理、import 整理，模型写得比人还仔细。问题恰恰出在这里：这些琐碎细节占了他 review 时 80% 的注意力，但真正需要他判断的架构问题、意外用例、视觉输出，反而被淹没了。
于是 meat.dev 的作用是：拿到 git diff，用 LLM 把“不重要”的代码过滤掉，只把“肉”留给他看。
这个工具他挺喜欢，但有两个毛病：一，他喜欢在 Shelley（exe.dev 的 agent）里看 diff，不想跑终端；二，LLM 处理 diff 要几分钟，他不想等。理想方案是：把 meat.dev 内嵌进 Shelley，commit 创建后立刻在后台预处理。
放在以前，这就是一个噩梦级的需求。想插进 VS Code 的扩展 API？光是“commit 一出现就触发后台任务”这一个功能，你就得去理解 VS Code 的扩展生命周期，还得绕过它的权限模型。想塞进 vimdiff？那基本是在跟 vim 的架构对着干，你得搞一个 out-of-band 的文件系统监听器，再搞一个缓存服务，再想办法让 UI 去轮询它——最后作成一个半吊子集成。
但 Crawshaw 只打了一句 Prompt：
把 meat.dev 集成进 Shelley。在 PATH 里安装最新版本。
当 Shelley 创建 git commit 时，在后台启动 meat 处理。
在 Shelley 的 Diffs 视图加一个 meat 开关。
如果 commit 还在处理中，向用户显示处理中状态。一句 Prompt，完成了集成、后台预处理、UI 添加、状态反馈。他唯一不满意的点，是模型给开关按钮选了个🥩表情。
你品品，如果是传统插件系统，你要写多少个文件、处理多少种状态、花多少天调试？而现在，agent 读懂了源码，找到了 commit 创建的地方，插入了调用逻辑——因为源码就摆在那里，它可以理解“这个软件是怎么构建的”，然后精准地把自己想加的东西加进去。
插件系统，是"多人摊薄成本"时代的产物
为什么我们曾经那么依赖插件系统？答案很简单：复杂软件的核心代码太贵了。
一个像 Vim 这样的项目，光读通就要几周。想加个“默认显示行号”的功能？自己改源码，学成本太高；设计一个通用的配置选项，让所有用户都能设？把实现成本摊到几十万人头上，每人只承担几厘钱——这笔账才能平。
所以软件的演进逻辑是：功能越复杂，越需要抽象出通用扩展点，越要把“个性化”从核心代码里抽离出去。 插件系统、配置文件、扩展 API，本质上是“让用户别碰源码”的隔离层——因为碰源码太贵了。
但 Agent 改变了一切。
学习成本不再是瓶颈。一个顶级 agent 现在可以单次完成一个单用户软件的功能添加。代码 review 也不再是瓶颈——单用户软件，运行条件极其有限，“看起来能用”基本就等于“能用”。
当“读懂并修改源码”的成本趋近于零，插件系统存在的根本理由就消失了。
想要改字号？给 agent 源码，告诉它，它在源码里找出硬编码的值改掉。如果是硬编码的位图字体？它会下载一个字体换上去，或者直接用工具生成一个。你不需要一个“字号设置界面”，因为改变代码本身就是设置。
Crawshaw 说了一句很狠的话：“源码本身就是扩展系统。”
这不是比喻，是字面意思。以前扩展系统是“源码的简化替代品”——你用插件 API，是因为碰不到源码；现在 agent 帮你直接改源码，中间那层插件系统的存在意义，就像电话簿之于智能手机。
开源与闭源的岔路口：为什么 Claude Code 会慢一步
这个趋势对开发者工具行业意味着什么？答案是残酷的：能被 agent 个性化的开源工具，和不能的闭源工具，正站在两个不同的进化速度上。
Crawshaw 提到的例子很形象。Codex 是开源的 agent，所以你可以用同样的 skill 技巧去个性化它——甚至他会疑惑：为什么 Pi 还需要扩展系统？“源码就是扩展系统”这句话在这里是完整的逻辑闭环。
但 Claude Code 是闭源的。它有很多“老派”的定制化钩子——配置文件、插件、MCP——但理论上限就在这里了：你永远只能修改它允许你修改的部分，永远只能在它画的框架里玩。它调不了内置的 diff 视图，加不了自己原生的后台任务，改不了 UI 的每一个像素。
你可以把闭源工具想象成一套精装修的房子：房东允许你挂画、换家具、贴墙纸，但你不能拆承重墙。 以前这没什么，因为开源软件的“拆承重墙”也要付巨额代价；但现在，agent 就是一个一天二十四小时、永远不累、随叫随到的施工队——拆墙的代价已经跌到地板价了。
于是我们看到了一个诡异的局面：
- • 开源 agent：用户直接改源码，每个人的版本都是独一无二的"私人定制"
- • 闭源 agent：用户只能等官方发插件、发功能，然后在更新日志里找自己想要的
前者是“软件适应人”，后者是“人适应软件”。谁更具生命力，答案显而易见。
个人化软件时代，正在回来
Crawshaw 文章的标题叫“Devtools must be open source”，但他真正论证的不是一个道德命题，而是一个商业判断：在一个 Agent 可以低成本修改源码的时代，任何拒绝开源的工具，都等于拒绝了进化。
这让我想起他个人的一个细节。以前他问工程师“有没有给自己写过程序”，大多数人答不上来；而现在，他这篇博客本身就是用 Shelley 写的——因为拼装和个性化 Tiptap 这样的开源库，比尝试定制传统软件产品更容易。
五年前，为了给自己加一个“默认显示行号”的功能而去读 Vim 源码，是不理性的。今天，为了任何一个小功能而忍受一个不能改源码的工具，同样不理性。
个人化软件的时代回来了——只不过这一次，写程序的不再是那个半夜打盹的工程师，而是他手下的 agent。
而这场变革的门槛，只有一行字：
把源码交出来。
觉得有用，点个「在看」❤️
