一句prompt,就让一个私人写的diff精简工具long进了自己写的coding agent里——commit一产生,后台就自动开始预处理,连等模型跑完的时间都省了。这是Philip Zeyliger在博客里讲的真事:他做了个叫meat.dev的小工具,专门用LLM把diff里不重要的部分(nil检查、import块、错误处理)剔掉,只留“肉”给人看。他想把它塞进自己开发的开源coding agent Shelley,于是打了一句prompt,agent自己把安装、后台调度、UI开关全干了。唯一不满意的地方是,模型自作主张用了个🥩emoji当按钮图标。
这条细节像个笑话,但作者据此推出一个不小的论断:未来的devtools,必须开源。
一句prompt改变了什么
过去改一个开源工具的成本,不止是“写代码”。真正贵的是长期维护:上游发新版本,你的本地修改要不要跟着改?一年后回来维护,基本等于重新读一遍代码。这也是为什么过去大多数工程师很少给自己写软件——写容易,养不起。
Zeyliger的说法是,现在有两类prompt能同时解决这两头的成本。第一类是“下载源码、本地构建、记录改动动机”;第二类是“设一个nightly任务,让agent自动拉取上游变更,把本地修改rebase上去,测试通过再替换”。前者降低了“开始改”的门槛,后者降低了“一直维护”的门槛。两个成本同时被打掉,自建工具这件事的投入产出比才第一次变得划算。
这套机制并不是这篇文章第一次提出。作者在更早的一篇博客里已经讲过Shelley如何“自己改自己”:用户只需说一句“把UI改成粉色”,Shelley就会在上游发新版时自动把这条个性化改动rebase到最新版本上。meat.dev这个案例,严格说是这套机制的第二次实战验证,不是新理论,是补一个例子。
为什么非开源不可
这套机制成立的前提,是agent能读到、也能改到真正的源码,而不是被关在一个官方预留的扩展口子里。作者拿VS Code的扩展API和vimdiff做了个假设:如果meat.dev要塞进这些封闭或半封闭的环境,光是理解它们的扩展机制,再想办法在commit产生的瞬间触发后台处理,几乎是场“convoluted misery”(纠结的苦役)——你得另外写一个守护进程去监听文件系统,再造一层缓存接口。麻烦不是不能解决,但解决方式已经不是“改一句话”那么便宜了。
这就是这篇文章真正的落点:开源与否,从一个关于理念、社区、道德立场的老话题,被agent重新变成了一道纯粹的成本题。源码可读可改,意味着agent能无限逼近你想要的样子,还能自己维护;源码不可读,你就只能等厂商愿不愿意给你留一个刚好够用的钩子。孟子说“君子创业垂统,为可继也”,放在这里倒是反过来贴切:能不能“继”下去,才是这套机制的真正门槛,而“继”的前提,恰恰是源码在你手里。
一个人的实验,能不能叫结论
这里得说句公道话:整篇文章的证据,只有作者自己的Shelley和meat.dev。没有第三方复现,也没有可查的社区讨论数据能证明这套“fork+nightly rebase”模式在别的项目、别的团队里也跑得通。目前能看到的,是一个开源agent作者拿自己的产品自证了一次,值得关注,但还谈不上被验证的行业趋势。
- 风险.大规模铺开后,谁为agent自动生成、持续变更的本地分叉负责?许可证合规、供应链安全、企业IT的版本一致性,这些问题这篇文章完全没碰。千人千份分叉,对企业支持团队不是好消息。
对闭源工具厂商来说,这套逻辑如果真被更多项目验证,扩展API和插件系统作为“护城河”的价值会被削弱——用户能自己长出功能,就没那么需要官方许可的扩展口子。但现在下这个判断还早,微软、JetBrains这些厂商也在往自家生态里塞AI能力,谁的成本曲线更低,还没见分晓。
“devtools必须开源”这句话听着像结论,其实更像一个假说:机制讲得通,案例只有一个,社区反馈还没形成。真正该盯的不是这句口号本身,而是接下来有没有别的开源项目跟进同样的“自我修改+自动rebase”设计,有没有出现因为分叉失控而翻车的安全事故。账本在往开源那边倾斜,是真的;账算没算完,还早。