为什么 Devtools 必须开源

我同意开发工具应该开源，但是……我强烈反对“工具不应该有配置文件、选项或插件系统”这一前提。相反，当你想改变像文本编辑器字体大小这样的东西时，应该让 LLM 下载代码，修改硬编码的值，然后重新构建。

这太 inefficient（低效）且 wasteful（浪费）了。假设在一个 LLM 承担大部分编码工作的世界里，我们是希望 LLM 消耗电力去构建一次选项对话框或配置文件解析器，还是希望当用户想改变软件的任何小细节时，让 LLM 消耗数百万次电力？

我真的希望我对这个问题的回答不会引起争议。

让 LLM 做一些不太可能引起其他人兴趣的定制化？很好，没问题。但给软件添加一个通用的有用功能，却懒得尝试将其上游化（upstream）？太烂了。烂，烂，烂。

> 设置一个每晚运行的 cron 任务，执行提示：获取 <software> 的上游更改，并将所有本地更改变基（rebase）到上游之上。检查软件是否按预期工作，然后替换当前版本。

这听起来像是地狱。你有一个不可靠的代理（actor）每晚都在重做软件，每天你都有可能在醒来时发现你的工作流被搞砸了。

而且，不，“检查软件是否按预期工作”这一条是不够的，因为 AI 非常、非常擅长遵守字面意思却违背精神。是的，你的 diff 出现了，但它们没有文件名。你在提示词里加了这个要求？好吧，文件名回来了，但字体大小是 4，小到无法阅读。你想让它们更清晰可见？下周它们就变成了 54 号字体，占满整个屏幕……

这并不是常规 AI 开发的问题——你会审查更改并进行一些测试。但日复一日地在没有全局概览的情况下这样做，简直就是自找麻烦。

作为一个致力于让开发工具易于分叉和修改的维护者，我能看到这种思路的吸引力，但我认为这可悲地过于理想化了。

使用开发工具的工程师与普通用户并没有太大不同，他们都只希望东西能正常工作。维护开发工具是实实在在的工作；例如，假设上游添加了一个你想要的功能，但它与你下游所做的某些东西发生了冲突。不是合并冲突意义上的，而是用户体验（UX）意义上的。你希望每次发布都去解决这个冲突吗？难道只是指望

AI 会解决这个问题”吗？也许有一天会，但就目前而言，智能体（agents）虽然能做出一些大致正确的东西，却无法很好地捕捉我的 UX 直觉；而且如果核心目标是超个性化，那我就要它完全按照我的意愿来。

“看起来能工作吗？”这句话在一切顺利时很好，但当你正在做重要事情时它却失败了怎么办？你那时要停下来，提示一个智能体去修复你的工具，并希望它这次能做好吗？如果它没做好呢？

此外，对于那些本质上具有社交属性的开发工具（即很多人查看同一个东西），让这个东西对每个人看起来都一样具有真正的价值。拥有一个基准用于教学、审计、验证“我们都在谈论同一件事”具有巨大的价值，有时这正是价值最大的地方。

总而言之，也许在某些类别的开发工具中，这种超个性化确实会发生，但它距离普及还有很长的路要走。

我基于其优点喜欢你的文章，但这一点：

> 软件个性化的前期固定成本和持续成本都已消失。

充其量只是美好的愿望。我们可以说，你自己那古怪的、只在你的电脑上运行的个性化软件可能变得更便宜了。但人们付费购买的生产级软件是另一回事。人们付费购买软件的原因正是：支持和持续维护。LLM 没有、也不太可能改变这一等式。作为一家企业，没有任何人可以就问题进行咨询所带来的纯粹责任风险是一个巨大的问题。

不久前，有一条评论 https://news.ycombinator.com/item?id=48849015

我强烈不同意“光与暗”的框架。我认为“黑客语言”和

blub 语言”之间的真正张力在于用户期望修改语言本身。

这对开发工具也是如此。黑客更喜欢可修改的环境（如 Emacs），而公司则更喜欢标准化的环境（IDE），让程序员去适应它。

（俗话说：“明智的人适应世界；不明智的人坚持试图让世界适应自己。因此，所有的进步都依赖于不明智的人。”这也许就是为什么 Paul Graham 更喜欢那些使用非 blub 语言的创始人，这与 Lisp 本身无关。）

但为了能够适应环境，你必须理解它。因此，推动力是使其变得更简单，成为一套通用工具，而不是一台功能繁多、只能通过遵循处方来使用的复杂机器。