我不是个原教旨主义者。我试过用集成在 IDE 里的 LLM。对于那些描述起来很简单、但自己动手又嫌烦的任务，它们确实挺好用的，比如把网格里的一堆方形图片缩小。我本可以去查查图像处理软件 ImageMagick 的命令行参数，但这种事交给 AI 去干再合适不过了。接着，我又试着用某个 AI 工具分析了我项目里的一段代码，还做了几件小事，然后一切戛然而止。系统通知我：额度用光了。如果想继续，请绑定信用卡购买更多 Token。
所以你一定要相信我：当我发现为了让自己能"思考"，居然还要无休止地给一个服务交钱时，我浑身不自在，以至于连信用卡的影子都不想给他们看。我合上笔记本电脑，卸载了那个 IDE，甚至乖乖用回了极其硬核的纯文本编辑器 Emacs。然后我发现，我压根儿就没觉得少了 AI 有什么不习惯的。
我年纪大了
年纪大确实有点帮助。我写代码已经很多年了，尤其是在这个把只有 5 年经验的开发者就称为"高级工程师"的行业里。有时候，经验是缓解焦虑的一剂良药（前提是，你焦虑的不是在这个 5 年就能称"高级"的行业里遇到的年龄歧视）。这波 AI 热潮确实让我想起了早年那些"低代码"或"无代码"工具所吹嘘的重大突破。我不怀疑 AI 可以成为开发者手中的利器，我知道在很多任务上它能提供更好的工具支持。但这些争论，总是让我回想起关于"偶然复杂性"（accidental complexity）和"本质复杂性"（essential complexity）的经典理论。
即使在我还是个年轻码农的时候，弗雷德·布鲁克斯（Fred Brooks）也算得上是老前辈了。作为 IBM System 360 系列大型机（及配套操作系统）的项目经理，他曾在第一线亲眼目睹了如今软件项目中那些司空见惯的烂摊子。他将这些观察整理成了《人月神话》一书，至今仍应是软件工程课程的必读经典。我手头的那本是后来重印的新版，里面收录了他后期的一篇著名文章《没有银弹》。在这篇文章中，布鲁克斯探讨了新工具对开发者生产力的实际影响。要想像程序员一样思考，你必须明白现实世界是极其复杂的。编程最好被理解为：在混乱的现实之上强加一种简化的模型，我们称之为"抽象"（abstractions），通过降低复杂性来让世界变得可理解。
那么，如果我们继续往下走，把"编程"这个行为本身也抽象掉呢？这就是 AI 智能体的终极梦想：成群结队的智能体接受任务，然后在无人监督的情况下自动实现它们。听起来棒极了！但这解决的仅仅是布鲁克斯所说的偶然复杂性，也就是编写代码本身那些繁琐、笨重的地方。自从那篇文章发表以来，软件开发在应对偶然复杂性方面已经取得了巨大的进步。我们不用再写底层的机器码，而是使用现代的动态解释型语言；我不需要再从头记住如何手写一个快速排序，只需调用标准库里的排序方法即可；我也不用再从零开始搭建整个 Web 应用，而是直接使用现成的框架。如果我想重命名或者重构某段代码，我的编辑器可以代劳。
我不是个原教旨主义者。我试过用集成在 IDE 里的 LLM。对于那些描述起来很简单、但自己动手又嫌烦的任务，它们确实挺好用的，比如把网格里的一堆方形图片缩小。我本可以去查查图像处理软件 ImageMagick 的命令行参数，但这种事交给 AI 去干再合适不过了。接着，我又试着用某个 AI 工具分析了我项目里的一段代码，还做了几件小事，然后一切戛然而止。系统通知我：额度用光了。如果想继续，请绑定信用卡购买更多 Token。
AI 似乎只是这一进程的最新迭代，一些编辑器已经用不可预测的 AI 智能体，取代了过去那些可预测的老式重命名和重构工具。诚然，这听起来像是在掷骰子碰运气，但在实际开发中，那种灾难性的大翻车又能有多常见呢？
大语言模型驱动开发的魅力在于，它标榜能消除一切摩擦。吹鼓手们编织出美好的神话：开发团队一天就能发布几十个新功能，在越来越奇葩的网络拓扑结构下，指挥着好几个 AI 智能体团队自主运转。我懂，软件开发有时候确实枯燥又让人抓狂。能够以不可思议的速度疯狂产出代码，把玩着打磨精美的产品而不是半成品原型，那种感觉一定超级刺激。
不可避免地，对"LLM 驱动速度"的狂热追求，最终会把矛头指向人本身，包括其他工程师、产品经理、项目经理、测试人员、合规审查员或者设计师。因为这些职位，现在也被视为了"摩擦"。既然我们能捏出 AI 用户画像，还要什么用户调研？既然 AI 工具能直接吐出网页排版，还要什么设计师？既然我们自己就是统帅 AI 智能体大军的经理，还要什么项目经理？如果我们不再需要等另一个开发者来审查我们的代码，只要通过了测试和扫描就自动合并，那该多爽？如果我们再也不用把工作时间浪费在跟别人沟通上，而是直接飞升到一个只剩纯粹编码的境界里，那该多美？
我开个玩笑；这里其实不涉及什么法律责任。考虑到两者受众群体的相似度，这也许不足为奇，但 LLM 供应商正在重演特斯拉的套路。他们在没有进行安全测试的情况下就把新功能推送给用户，而且诡异的是，就像特斯拉的狂热死忠粉一样，LLM 的鼓吹者们在面对灾难性后果时，往往会责怪自己和他人，声称这是因为用户的提示词写得不够好。我实在不知道该怎么评价这种现象，但科技界正在将一种极端的资本主义标准化，让消费者承担更多的风险，因为企业和政府双双放弃了他们的监管责任，这让我感到极度不安。当初仅仅因为砸死了一个孩子，我们就全面封杀了容易误伤致命的草地飞镖游戏，但逼得用户自杀或精神失常的 AI 聊天机器人，却被视为了 AI 创新必须付出的合理代价。是不是非得等到凭感觉编程引发系统崩溃导致人员伤亡，而不是仅仅死于尴尬时，情况才会有所改变？
所以你一定要相信我：当我发现为了让自己能"思考"，居然还要无休止地给一个服务交钱时，我浑身不自在，以至于连信用卡的影子都不想给他们看。我合上笔记本电脑，卸载了那个 IDE，甚至乖乖用回了极其硬核的纯文本编辑器 Emacs。然后我发现，我压根儿就没觉得少了 AI 有什么不习惯的。
我年纪大了
年纪大确实有点帮助。我写代码已经很多年了，尤其是在这个把只有 5 年经验的开发者就称为"高级工程师"的行业里。有时候，经验是缓解焦虑的一剂良药（前提是，你焦虑的不是在这个 5 年就能称"高级"的行业里遇到的年龄歧视）。这波 AI 热潮确实让我想起了早年那些"低代码"或"无代码"工具所吹嘘的重大突破。我不怀疑 AI 可以成为开发者手中的利器，我知道在很多任务上它能提供更好的工具支持。但这些争论，总是让我回想起关于"偶然复杂性"（accidental complexity）和"本质复杂性"（essential complexity）的经典理论。
即使在我还是个年轻码农的时候，弗雷德·布鲁克斯（Fred Brooks）也算得上是老前辈了。作为 IBM System 360 系列大型机（及配套操作系统）的项目经理，他曾在第一线亲眼目睹了如今软件项目中那些司空见惯的烂摊子。他将这些观察整理成了《人月神话》一书，至今仍应是软件工程课程的必读经典。我手头的那本是后来重印的新版，里面收录了他后期的一篇著名文章《没有银弹》。在这篇文章中，布鲁克斯探讨了新工具对开发者生产力的实际影响。要想像程序员一样思考，你必须明白现实世界是极其复杂的。编程最好被理解为：在混乱的现实之上强加一种简化的模型，我们称之为"抽象"（abstractions），通过降低复杂性来让世界变得可理解。
那么，如果我们继续往下走，把"编程"这个行为本身也抽象掉呢？这就是 AI 智能体的终极梦想：成群结队的智能体接受任务，然后在无人监督的情况下自动实现它们。听起来棒极了！但这解决的仅仅是布鲁克斯所说的偶然复杂性，也就是编写代码本身那些繁琐、笨重的地方。自从那篇文章发表以来，软件开发在应对偶然复杂性方面已经取得了巨大的进步。我们不用再写底层的机器码，而是使用现代的动态解释型语言；我不需要再从头记住如何手写一个快速排序，只需调用标准库里的排序方法即可；我也不用再从零开始搭建整个 Web 应用，而是直接使用现成的框架。如果我想重命名或者重构某段代码，我的编辑器可以代劳。
AI 似乎只是这一进程的最新迭代，一些编辑器已经用不可预测的 AI 智能体，取代了过去那些可预测的老式重命名和重构工具。诚然，这听起来像是在掷骰子碰运气，但在实际开发中，那种灾难性的大翻车又能有多常见呢？
大语言模型驱动开发的魅力在于，它标榜能消除一切摩擦。吹鼓手们编织出美好的神话：开发团队一天就能发布几十个新功能，在越来越奇葩的网络拓扑结构下，指挥着好几个 AI 智能体团队自主运转。我懂，软件开发有时候确实枯燥又让人抓狂。能够以不可思议的速度疯狂产出代码，把玩着打磨精美的产品而不是半成品原型，那种感觉一定超级刺激。
不可避免地，对"LLM 驱动速度"的狂热追求，最终会把矛头指向人本身，包括其他工程师、产品经理、项目经理、测试人员、合规审查员或者设计师。因为这些职位，现在也被视为了"摩擦"。既然我们能捏出 AI 用户画像，还要什么用户调研？既然 AI 工具能直接吐出网页排版，还要什么设计师？既然我们自己就是统帅 AI 智能体大军的经理，还要什么项目经理？如果我们不再需要等另一个开发者来审查我们的代码，只要通过了测试和扫描就自动合并，那该多爽？如果我们再也不用把工作时间浪费在跟别人沟通上，而是直接飞升到一个只剩纯粹编码的境界里，那该多美？
我开个玩笑；这里其实不涉及什么法律责任。考虑到两者受众群体的相似度，这也许不足为奇，但 LLM 供应商正在重演特斯拉的套路。他们在没有进行安全测试的情况下就把新功能推送给用户，而且诡异的是，就像特斯拉的狂热死忠粉一样，LLM 的鼓吹者们在面对灾难性后果时，往往会责怪自己和他人，声称这是因为用户的提示词写得不够好。我实在不知道该怎么评价这种现象，但科技界正在将一种极端的资本主义标准化，让消费者承担更多的风险，因为企业和政府双双放弃了他们的监管责任，这让我感到极度不安。当初仅仅因为砸死了一个孩子，我们就全面封杀了容易误伤致命的草地飞镖游戏，但逼得用户自杀或精神失常的 AI 聊天机器人，却被视为了 AI 创新必须付出的合理代价。是不是非得等到凭感觉编程引发系统崩溃导致人员伤亡，而不是仅仅死于尴尬时，情况才会有所改变？
宝玉@dotey · X