当AI不再写Bug:软件工程正在崩塌的11个旧共识

2026年9月19日，德国知名开发者 Thorsten Ball 发布了一组关于软件工程未来的判断。他不绕弯子，第一条就是：

代码审查将消失。

这组判断（英文原文9条，流传中被整理扩到11条）很快在开发者圈子里炸开了锅。有人叫好，有人骂他危言耸听。

我把这11条反复读了几遍，觉得值得认真对待——不是因为它们一定对，而是因为它们指向了一场比"AI帮你写代码"深得多的变化。

这11条表面上在讲工具，实际上在讲同一件事：当"人"从写代码这件事里被抽出来之后，整个软件工程的地基——它的质量观念、分工体系、组织方式——都在重新排列。

下面我把它们分成五层来看。重点在第2层。

一、那些"死掉的"环节

先看最扎眼的几条。它们有个共同点：都是"人替机器把关"的环节。

（1）代码审查将消失。 人工逐行审查已经没意义了——人类跟不上AI生成代码的速度，无法在合理时间内发现AI代码中的问题。未来人类只能审查整体架构是否合理，而不再是通过PR逐行看代码。

（2）单元测试可能消失。 既然AI能随时重写整个实现，再去测一个个代码单元就失去了意义。好比下次迭代整栋楼都要重建，何必再检查单块砖头？将来的项目可能只保留接口测试、集成测试、系统测试。

（9）代码风格规范和 linter 工具也没意义了。 每行不超过80字符、缩进用 tab 还是空格……AI 会在乎这些吗？

（10）终端已死。 命令行、shell、文本编辑器、CLI 工具不会再被人类使用。用命令行就像用 Perl 写单行脚本一样，会变成一种"考古式"的技能。

看出来了吗？这四条拆掉的不是"工具"，而是一道道人工质检的关口。当生产端换成了不知疲倦、不该出低级错的机器，质检端的人工把关就失去了性价比。

二、真正深刻的转变：错误搬家了

这一条是我认为——全部11条里唯一一条跨出了代码本身、触及本质的：

（4）Bug 的性质变了。大多数 Bug 不再是代码 Bug，而是"需求提错了"或"表达不准确"。

它的逻辑链非常硬：

1. AI 把"实现"这一环的错误率压到极低——代码层面的错误，正在被系统性消灭；

2. 于是错误来源被动地向上游迁移：代码之下没问题了，问题就只能出在"你想要什么"这个源头；

3. 上游是什么？是需求定义。需求一旦模糊、自相矛盾、没想清楚，AI 会高效地把错误实现出来——改得越快，错得越快。

一句话概括："输入垃圾，输出垃圾"（GIGO）这句老话，在AI时代被推到了极限。

过去，"垃圾需求"有人兜底——程序员在实现时会发现不对劲，回来找你确认，顺手帮你补漏。现在这个"人肉兜底"环节被抽掉了，需求的质量，第一次如此直接地决定交付的质量。

所以这条判断对组织的影响最大：产品经理/需求方的门槛不是降低，而是大幅提高。 要求从"说个大概"升级为"提出准确、不自我矛盾的需求"。而这恰恰是最难的能力——因为它要求你想清楚你自己到底要什么。

延伸一句：当"怎么做"被AI接管，"要什么"就成了唯一的胜负手。 这不仅适用于软件，也适用于几乎所有知识工作。

三、价值迁移：从"写代码"到"造软件"

（3）软件开发的重点不再是写代码。 程序员的工作重心将移到代码之外：如何用软件解决业务问题、了解软件如何实现、如何发布、如何收集反馈——这才是新的主战场。

（8）"好代码"的概念将消失。 过去"好代码"的标准是便于人类阅读理解、方便重构、维护效率高。但当你已经不读代码、不直接修改大部分代码时，"好代码"赖以存在的前提就没了。

这两条合在一起，是真正的范式转变：软件工程的核心能力，正在从"表达"迁移到"判断"。 以前值钱的是"能把复杂逻辑写成清晰代码"；以后值钱的是"能判断这软件该不该这么做、能不能更好、什么时候上线"。

四、组织地震：三角瓦解

（7）项目分工将改变。 过去项目组一般是三种角色：项目经理（PM）、设计师（Designer）、工程人员（Engineer）。有了AI，一个人可以兼任多个角色，这种三元架构将消失。

这条其实没那么"死"——但它点出了真实趋势：角色在融合，小团队/个人的战斗力被极度放大。 一个懂业务、能提准需求的人，配上一个AI，就能干过去一个团队的活。这对大厂的重型流程是冲击，对小团队和独立开发者则是红利。

（5）软件开源不再能提升质量。 过去开源的一个理由是"只要关注的人足够多，所有Bug都能被发现"（林纳斯定律）。这句话依然成立，但现在即使不开源，AI也能帮你发现Bug——"足够多的眼睛"不再是非开源不可的理由。

（6）敏捷编程会死亡。 Agile、Scrum 这些方法论意义不大了：AI的生成速度决定了项目的开发时间，你要做的只是把工单直接推给AI。（这一条我认为过于激进，后面说。）

五、认知升级：Token 是新的计算范式

（11）Token 为王。 谁负担得起更多 Token，谁的软件就更好；没有足够的 Token，就开发不出最优秀的软件。

这条是最容易被误读的一条。它真正想说的是：竞争的核心资源变了。 过去拼的是"谁的程序员强"，现在拼的是算力/Token 的供给能力——这已经成了产品竞争力的一部分，"Token 预算"变成了一种战略资源。

作者最后还有一句更宏大的收尾（对应中文版的"后二进制时代"）：确定性计算机统治了80年，我们即将进入"后二进制时代"。

这句话值得琢磨：过去80年，我们默认"计算机是按确定逻辑运行的"；而现在，软件的核心变成了概率化的编排——这确实是一次底层的认知切换。

冷静看：这是判断，不是预言

把这11条读完，我最大的感受是：方向大概率对，但时间线和程度会打折。

三个理由：

第一，它默认"AI不犯错"。 现实是AI会犯错，只是错的方式和人类不同。代码层面的错少了，但"幻觉式实现""看似合理实则跑偏"的错依然存在，且更难发现。所以质检环节不会消失，而是变形——从"逐行看代码"变成"审架构、审行为、审结果"。

第二，"死"从来不是一刀切。 "无纸化办公"喊了30年，纸张还在用；"纸质书会死"喊了20年，书还在印。技术替代的真相，往往不是"消灭"，而是"分层"：数据处理、样板代码这类工作会被快速吞掉，而系统设计、需求洞察、责任判断会显得更贵。

第三，过渡期恰恰是"人"最值钱的时候。 当旧流程还没退场、新流程还没立稳，能同时理解"业务"和"AI能力边界"的人，就是最稀缺的物种。这个窗口期会有多长，取决于AI落地速度和组织的适应能力——但一定不会是明天早上。

写在最后

Thorsten Ball 这11条，价值不在于它们是否字字应验，而在于它逼我们回答一个问题：

如果"写代码"这件事本身正在消失，那软件工程剩下的到底是什么？

我的答案是四个字：表达与判断。

表达——把模糊的业务诉求，翻译成准确、不自相矛盾的需求（第4条，也是本文的重点）；

判断——在AI给出的无数种实现里，决定哪一个是对的、什么时候该上线。

这两件事，恰恰是AI最不擅长、也最难替代的部分。它们需要的不是手速，而是脑子。

所以与其焦虑"程序员会不会失业"，不如换个问法：你在这条链上，是那个"提需求的人"，还是那个"被需求提的人"？

当机器负责"怎么做"，"要什么"的能力，就成了你最硬的护城河。

· · ·

本文基于开发者 Thorsten Ball 2026-09-19 发布的观点整理展开，英文原文共9条，流传中被扩为11条。译文与点评基于公开信息，观点部分为作者个人判断，不代表官方定论。