开发工具必须开源
文章摘要
作者 David Crawshaw（Tailscale 联合创始人，现在做 exe.dev）从一个观察切入：五年前他跟大量工程师聊天时发现，绝大多数人没有任何自己写给自己用的程序。工程师们整天用别人写的程序去给别人写程序；很多人会通过配置文件、插件、扩展来定制工具，但真正为自己量身写软件的人极少。他认为这在当时完全合理——自己写软件的投入产出比一直很可疑：一天能写的代码有限，工作上总有更要紧的事，而一个项目搁置一年后再回来维护痛苦无比。他自己职业生涯中有好几年干脆扔掉所有自制工具，用最标准的环境写代码；在 Google 早期他甚至连个人电脑都没有。
但他认为现在情况变了。文章给出两条关键提示词模板：第一条是「下载某软件的源码、本地构建使用，并在 agent 的记忆里写明今后任何改动都要改源码并替换当前版本，同时在版本控制里记录改动的初衷」；第二条更重要——「设置一个每晚运行的 cron 任务，执行：拉取上游改动，把所有本地改动 rebase 到上游之上，验证软件按预期工作，然后替换当前版本」。核心洞察是：agent 不只能改代码，还能自动管理与上游同步的过程，这同时降低了「开始定制」和「持续维护」两头的成本。更进一步，只要 agent 本身是开源的，这两条提示词可以做成 skill 内置进去；他们在自家的 Shelley 里就这么做了，用户直接说「把 Shelley 的 UI 改成高对比度」就能完成个性化。
文章用一个真实例子说明这有多强。作者有个副业项目 meat.dev：他发现随着模型变强，代码审查的重点变了——模型在机械正确性（错误处理、nil 检查）上比人更勤勉，人类审查者真正需要看的是架构、意外用例、测试环境反馈不到的视觉输出。所以他写了个工具，用 LLM 把 diff 中不重要的部分（import 块、nil 检查、错误处理）剥离掉，只留下「肉」。但这工具有两个痛点：他想在 Shelley 的漂亮 UI 里看 diff 而不是终端；以及 LLM 处理 diff 要花几分钟，他不想等。解决办法是一条提示词：把 meat 集成进 Shelley，在 Shelley 创建 git commit 时后台启动 meat 处理，并在 Diffs 视图加一个开关。一次就搞定了，包括后台预处理。他调侃说模型唯一的失误是给开关选了个牛排 emoji。他强调，如果要通过 VS Code 扩展 API 或 vimdiff 实现同样的东西，那种「commit 一出现就开始预处理」的机制几乎不可能做到，因为扩展点的形状根本不对。
由此他得出更激进的结论：能被个性化的软件不再需要插件系统或配置文件。前 agent 时代，复杂软件带庞大配置和插件体系是理性的——Vim 这种规模的代码库人类要花几周才能消化，为了「默认显示行号」去读代码改代码不合算，所以更值得设计成可共享的扩展机制、把成本摊薄到众多用户身上。而现在理解代码并改动的成本骤降，对于单用户软件，「仔细的代码审查」常常可以换成「它看上去能用吗」。他进而认为整类软件产品需要被重新发明：小团队为什么要买一个极其可配置的任务管理器／CMS／CRM，花时间学习和配置、把团队扭曲去适应它的限制，而不是用通用积木拼出自己想要的功能？他这个博客本身就是用 Shelley 写的定制软件，因为把 Tiptap 之类的库拼起来比定制传统产品更容易。文章最后点名：同样的 skill 技巧可以轻易套用到 Pi、Codex 等开源 agent 上（他甚至怀疑 Pi 为什么还需要内置扩展系统，「源码就是扩展系统」），但会在 Claude Code 上撞墙——它是闭源的，你只能寄希望于它的 hook 恰好符合你的需求，否则就换一个能让你个性化的 agent。
HN 评论精华
这是本期讨论最热的一篇（728 分、227 条评论），评论区大致分成四派：认同 LLM 让「开源自由」变得真实的、痛斥「删掉配置文件让 LLM 改源码」是巨大浪费的、担心每晚自动 rebase 是灾难的，以及质疑 exe.dev 自己也不开源的。
LLM 让开源的原始承诺重新可行：simonw 贡献了最长的一条主贴（引出 28 条回复）。他指出，开源「可以检查和修改软件」的自由，对包括专家程序员在内的多数人来说，实际含义一直是「可以依赖别人去做这件事」，因为读懂并修改常用工具的代码在时间上不划算。「我觉得 LLM 改变了这个等式。我一天会好几次让 Claude 去『把 x/y clone 下来告诉我 Z 是怎么工作的』。以前光是把软件编译起来的摩擦就大到让我常常懒得动手，现在我把它当成零时间投入的挑战：让 Codex 或 Claude Code 去 checkout 并 build，十分钟后回来看结果。」spullara 说自己现在有一个由 AI 保持更新的 Ghostty 分支，还能自动分类 issue 并提 PR，「起因只是我想要一个内置设置页面而不是手改配置文件」。kuboble 列出了自己「vibe 改造」过的软件：去掉了广告和骚扰提示并加了统计和过滤功能的播客应用、自制记事本（因为 Windows 给记事本塞了 Copilot）、Android 语音键盘，以及给 Wezterm 写 Lua 脚本补齐缺失功能。K3UL 认为这才是 LLM 给开发领域带来的最重要革命，「不是 vibe coding 也不是取代整个团队」，而是让非开发者也能造自己的小工具，「它们会把 personal computing 里的 personal 还回来」。HiPhish 打了个类比：「我不是水管工，但我很希望有自己修水管的自由。不是因为我想修，而是因为这意味着我能选择让谁来修。」
维护分叉到底难不难：throwatdem12311 泼冷水——「你会永远维护一堆叠在上游之上的补丁，因为维护者不想要 AI slop 贡献。」他分享了亲身经历：用 AI 做了个单行、纯语法、行为不变的改动去修复与旧版本语言的兼容性，PR 却因为带了 Claude 署名被拒；最后只能在自己应用代码里绕过去。但他表示理解：「在 AI slop 从四面八方 24/7 轰炸你的年代，把门是维持质量（和理智）的唯一办法，零容忍，否则会被淹没。」Fabricio20 给出了完全相反的实战经验：他自己维护着约 6 个软件的分叉，用 StGit（Stacked Git）管理补丁栈，让 Claude 拉取上游后按顺序重新应用补丁并逐个修复；他在每个 stg 补丁里写详细的「意图」描述，这样 Claude 能判断某个补丁是否已经不再需要（比如上游已经实现了）。「即使上游很动荡（有个项目的独立开发者特别爱重构），全都崩掉的时候也不超过一小时就能更新完。如今维护自己的个性化分叉真的很合理。」dregitsky 则是中间派：他去年 12 月分叉了 codex 加了自己的轻量 plan mode，「很有趣很满足，但保持更新有点痛苦」。awesome_dude 提了个朴素的观点：「保持改动跟得上上游的压力，本身就是把改动推回上游的强大动力。」dolmen 反驳说 AI 时代贡献成本更高：AI 写的 PR 大概率直接被拒，要认真准备一个「人类手写」的补丁反而比让 agent 升级自己的分叉更费事，而且照样可能被无视几个月甚至几年。
「删掉配置文件」引发的最强反弹：kelnos 的评论是全场共鸣最多的反对意见之一——「我同意开发工具应该开源，但我极不同意『工具不该有配置文件、选项或插件系统，想改字体大小就让 LLM 下载代码改掉硬编码值再重新构建』的前提。这太低效、太浪费了。假设一个 LLM 承担大部分编码工作的世界，我们是想烧一次电让它写好一个选项对话框或配置解析器，还是想在每个用户想改一点小东西时烧上百万次电？」他补充：给自己做别人不感兴趣的定制没问题，但做出通用的好功能却懒得推上游，「逊，太逊了」。duped 用反讽表达同样意思：「是啊，为了改个 API 端点或端口号，让我重新构建整个软件真是对时间和电力的美妙利用。配置和插件系统的存在是有充分理由的：软件应该在不整体替换的前提下可重配置、可模块化。」danbruc 逐条拆解 skybrian 的「如果构建够快，改常量和改配置项没多大区别」：改源码你得先取到源码、找到正确的行、有构建环境、构建完还得重装，而且每个未来版本都要重来一遍，「复杂度、精力和资源消耗差好几个数量级，这是改字体大小的疯狂做法」。1718627440 反驳说自给自足的操作系统本来就带构建环境、全文搜索旧值就能定位，danbruc 回击：「代码库里出现『10』多少次？而且你要找的值真的是 10 吗，还是 UI 显示 10 磅但代码里定义成 200 twip？」wilsonnb3 举出 suckless 工具早在 LLM 之前就是这么干的（改头文件里的变量再重编译），nananana9 补充「只对小程序成立——我不介意对 2500 行 C 程序跑 make，但我可不想为此重编译 LLVM 或 Firefox」；ironhaven 精准地指出「suckless 也有配置文件，只是扩展名是 .h」。tajd 强调插件生态的价值：好插件会被回收进主工具。lalitmaganti 作为一个刻意让自家开发工具易于分叉的维护者，说这个想法「诱人但太理想化」：升级时上游新功能可能在 UX 意义上（而非合并冲突意义上）与你的改动冲突，你每个版本都要重新裁决；而且「对于本质上是社交性的开发工具（很多人看同一个东西），大家看到的东西长得一样有真实价值——教学、审计、确认『我们说的是同一件事』的基线，有时候价值最大的恰恰在这里」。
每晚自动 rebase 的争议：theamk 直言那条 cron 提示词「听起来像地狱」：「你让一个不可靠的行动者每晚重做你的软件，每天早上醒来都有可能发现工作流坏了。而且『验证软件按预期工作』根本不够，AI 极其擅长遵守字面而背离本意——你的 diff 出现了但没有文件名；你把文件名加进提示词，文件名回来了但字号是 4 号看不清；你要求显眼一点，下周它变成 54 号占满屏幕。」他强调交互式开发时这些都不是问题，问题在于无人值守的每日 cron。QGQBGdeZREunxLe 补了一刀：「工作流坏掉是你最不该担心的，这是个安全噩梦。」20k 怀疑「鼓吹这个的人其实并不真这么干，这只是听起来时髦、适合写博客的说法」，作者 crawshaw 亲自回复：「我对我的 Shelley 改动就是这么做的，它有效。」9dev 也表示自己用 Claude Code 处理过分歧很大的巨型分支 rebase，「几乎每次都完美完成」。arjie 提出折中：不自动 rebase，但把依赖 vendor 进来，按自己的节奏更新。
关于 exe.dev 自身与商业模式：这条帖子下有不少针对作者立场的质疑。2190asfg 称「一家转售闭源提供商服务的公司在这里布道开源」，还说「个性化这套说辞看起来是协调好的，上周开始满互联网都是」。indigodaddy 和 Brainspackle 为 exe.dev 辩护（指出其 LLM 网关不加价、主力产品 Shelley 是开源的），crawshaw 本人回应：「我唯一协调过的人是我在 exe.dev 的同事……我们都在摸索 LLM 颠覆职业后新工具和新规范的形状，出现相似的想法并不奇怪。事后想想，我应该把草稿发给更多在思考新开发工具的人征求意见。」曾任开发工具公司 CEO 的 jedberg 提供了商业视角：开发工具确实该开源，但这让做成一门生意极其困难，因为「你的客户是开发者和运维，他们都觉得自己完全有能力自己跑这套软件并加上需要的东西——很多时候他们是对的。现在有了 AI 编码，情况糟糕十倍，他们能拿你的开源代码 vibe 出一个『够用』版本的商业产品。我不知道怎么解这个圈。」rglover 补充：「开源加上『慷慨免费额度』的 SaaS 基本上把为软件付费的意愿炸没了。」
其他有意思的角度：davidw 指出一个讽刺——「一边强调工具链的关键部分要开源，一边把外部公司控制的黑箱闭源 LLM 变成整套流程不可或缺的一环」；crawshaw 回应说开源模型现在已经相当好，qwen/glm 等「显然是我的未来」。QwenGlazer9000 有类似担忧：「开放权重模型也不是真正的开源，那基本上等于有后端二进制却没有源码。别把 LLM 正常化成我们与开源软件交互的主要方式。」nextaccountic 更尖锐地质疑版权：他引用了另一个帖子里某项目借 LLM 重写而把 GPL 换成 MIT 的例子，称「LLM 是版权洗白机器」。quintu5 从伦理角度反驳标题：「『我们需要源码』——不，你是想要源码。你想让别人投入时间、精力和判断力做出来的软件随你处置，还不用付出任何回报。这种理所当然的姿态令人疲惫。」stephen_cagle 提出一个有意思的预测：既然「把东西跑起来」的惯性以前是某些开源项目支撑咨询服务的护城河，摩擦消失后可能反而会促使一些人闭源；simonw 认同这个风险，「以前你可以放心开源，因为别人提取核心部分或另起分支的摩擦太大；现在如果你发明了一个绝妙的数据库索引方案并开源，我可以让编码 agent 几分钟内模仿出你的洞见」。最后，aljgz 讲了一个纯粹的经典开源受益故事：他们的 .NET/EF 项目启动要两分钟，profiling 后发现是 EF 的 view generation，去掉一个 [Conditional('DEBUG')] 函数调用后从 450 秒降到 64 秒，再重写其中一个 LINQ 语句降到 120 毫秒，最终这个修复被贡献回 EF Core，「要不是微软开源了 EF，这可能会成为项目的生存威胁」。