五年前,Tailscale 工程师 David Crawshaw 经常问同行一个问题:”你有没有为自己写过程序?”得到的答案大多是”没有”。工程师们每天用别人写的程序,去写给别人用的程序,最多通过配置文件、插件做点定制。当时他写了不少个人软件,但回报存疑:每天能写的东西有限,一年后回来维护旧项目更是痛苦。而现在,情况彻底变了——AI 代理让”个性化软件”变得惊人地容易,而这一切的前提,是源码开放。
两个 Prompt,改变定制软件的成本结构
Crawshaw 在 exe.dev 博客上写道,如今只需两类 Prompt 就能实现软件个性化。第一类:让代理下载某软件的源码并本地构建,把”任何未来修改=改源码并替换当前版本”写进代理记忆,同时把修改动机记录进版本控制。
第二类更关键:设置一个夜间 cron 任务,让代理自动抓取上游更新、把本地修改 rebase 到新版本之上,验证可用后替换当前版本。核心洞察在于:代理不仅能改代码,还能自动管理”与上游同步”这件苦差事——开始定制更容易,持续维护也更容易,ROI 两端同时改善。
案例:一个 Prompt 把工具装进代理
他举了一个亲身案例:他写了一个叫 meat.dev 的 diff 精简工具,用 LLM 把代码评审中”不重要的部分”剥掉——import 块、nil 检查、错误处理统统消失,只留下真正值得看的逻辑。过去六个月他发现,模型在机械正确性上比人类细心得多,人类评审者常纠结的边界情况模型几乎不犯错,错误集中在架构、意外用例、测试环境看不到的视觉输出上。
这个工具好用的代价是要在终端里等几分钟。于是他只用一个 Prompt 就把 meat 内建进 Shelley(他们的开源代理):安装到 PATH,git commit 创建时后台启动 meat 处理,在 Diff 视图加开关。唯一遗憾是模型选了 🥩 emoji 做开关按钮。放在以前,要往 VS Code 扩展 API 或 vimdiff 里塞这种逻辑,光是”提交一出现就预处理”的机制就几乎不可能实现。
结论:开发工具必须开源
这一切魔法都建立在源码可见、可改、可自动 rebase 之上。Crawshaw 由此得出文章的标题结论:开发工具必须开源,否则 AI 代理时代的个性化无从谈起。更进一步,由于开源代理本身也能被 Prompt 定制,连”编辑代理”都不再需要编程——把两段指令装进 skill 文件即可。
社区反响
HN 上这篇 479 分、173 条评论的讨论颇为激烈。有人质疑:定制一旦出错,责任就落到用户头上,而且你和 LLM 可能给不熟悉的代码库引入微妙 bug 或漏洞。Simon Willison 则点出关键转变:开源的”自由检查修改”过去对大多数人(哪怕资深程序员)只是理论自由,现在代理让它第一次成为现实。还有评论调侃,与其争论开源,不如直接给维护者付钱——”想让我的 bugfix 被合并?往 PR 上挂 1000 美元。”
原文:Devtools must be open source | HN 讨论:news.ycombinator.com/item?id=49156111