上一篇我们聊了 15 条经典软件工程定律。但 AI 大模型的出现，正在从根本上改变软件开发的方式。那些前辈们用血泪总结的定律，有些正在被 AI 颠覆，有些反而变得更加重要，同时也催生了一批全新的定律。

程序员必知的 15 条软件工程定律

一：正在失效或被削弱的经典定律

1. Brooks 定律——正在被 AI 削弱

原定律：”向一个已经延期的项目增加人手，只会让它更加延期。”

AI 时代的变化：

Brooks 定律成立的两个核心原因是”沟通成本”和”新人学习期”。但 AI 编程助手不需要沟通，也不需要学习期。

• AI 不会问你”这个变量是什么意思”，它自己能看懂代码上下文。
• AI 不需要开会、不需要对齐、不需要 team building。
• 你可以同时让 AI 写十个模块，它们之间不存在沟通开销。

但没有完全失效：

• AI 生成的代码需要人类审查，当 AI 产出量大时，审查成本反而成为新的瓶颈。
• 多个 AI 生成的代码之间的集成问题，本质上是 Brooks 定律的变体。
• 核心架构决策仍然需要人类做，这部分无法通过”加 AI”来加速。

结论：Brooks 定律从”加人无效”变成了”加 AI 有效但有上限”。瓶颈从沟通成本转移到了审查成本和集成成本。

2. Knuth 优化原则——正在被重新定义

原定律：”过早优化是万恶之源。”

AI 时代的变化：

过去不提倡过早优化，是因为优化有成本——需要程序员花时间分析、重写、测试。但现在：

• AI 可以在生成代码的同时就考虑性能最佳实践。
• 让 AI “顺手”写出高性能代码的成本几乎为零。
• AI 可以快速生成多个版本进行基准测试，优化不再”昂贵”。

但仍然有效的部分：

• AI 可能会为了”优化”引入过度复杂的方案，而你并不需要那个性能。
• 架构层面的优化决策（用缓存还是不用、选什么数据库）AI 目前还不擅长判断。

结论：编码层面的优化不再”昂贵”，但架构层面的过早优化仍然危险。定律的适用范围在缩小。

3. DRY 原则——正在被松动

原定律：”不要重复自己。”

AI 时代的变化：

DRY 的核心理由是”重复的代码难以维护，改了一处忘了另一处”。但在 AI 时代：

• AI 可以帮你全局搜索并批量修改所有重复代码。
• AI 可以检测到不一致的代码并提醒你。
• “复制粘贴后让 AI 统一修改”反而可能比”设计精妙的抽象”更高效。

有些人开始倡导 WET 原则（Write Everything Twice）——适度的重复比错误的抽象要好。因为 AI 大幅降低了管理重复代码的成本。

但仍然重要的场景：

• 业务规则的重复仍然危险（AI 可能不理解你的业务逻辑）。
• 跨系统的重复（不同项目之间）AI 还无法有效管理。

结论：DRY 从”铁律”变成了”建议”。在 AI 的辅助下，适度的重复是可以接受的。

4. Linus 定律——正在被 AI 放大

原定律：”只要有足够多的眼睛，所有 bug 都是浅显的。”

AI 时代的变化：

AI 就是那个”永不疲倦的眼睛”。

• AI 代码审查工具可以 7×24 小时不间断地审查每一行代码。
• AI 能发现人类容易忽略的模式（安全漏洞、边界条件、资源泄露）。
• 一个 AI 相当于同时拥有”一千个有经验的 reviewer”的知识。

但有局限：

• AI 善于发现语法层面的 bug，但对业务逻辑错误仍然容易”视而不见”。
• AI 可能对所有代码都给出”看起来不错”的反馈，产生虚假安全感。

结论：这条定律没有失效，反而被 AI 大幅增强了。但”眼睛”的类型变了——AI 的眼睛擅长看代码，人类的眼睛擅长看业务。

5. Hofstadter 定律——仍然顽固地有效

原定律：”事情总是比你预期的要花更长时间，即使你已经考虑了 Hofstadter 定律。”

AI 时代的变化：

你可能以为 AI 能让开发更快，估期更准。但实际情况是：

• “AI 五分钟就能写完”——然后你花了两小时调试 AI 生成的代码。
• “让 AI 来做，一天就够了”——然后你发现 AI 理解错了需求，返工花了三天。
• AI 让简单的事情变得更简单，但也让我们的预期变得更乐观，两者相互抵消。

结论：这是最”抗 AI”的定律之一。Hofstadter 定律在 AI 时代不但没有失效，反而以新的形式持续验证着自身。

二：AI 时代催生的新定律

6. Vibe Coding 定律（氛围编程定律）

“当开发者依赖 AI 生成代码而不完全理解它时，系统的可维护性与开发者的理解程度成正比下降。”

背景：

“Vibe Coding”这个词由 Andrej Karpathy（OpenAI 联合创始人）在 2025 年初提出。他描述了一种新的编程方式——”我不再真正写代码了，我只是描述需求，然后接受 AI 给的所有代码。”

这种方式在原型开发时极其高效，但在生产环境中是一颗定时炸弹。

现实中的表现：

• 开发者 copy 了 AI 生成的 200 行代码，它能跑，但没人完全理解它。
• 一周后出了 bug，团队里没人能修——因为没人真正”写”过这段代码。
• 系统中充斥着”能跑但没人理解”的代码块，就像一栋用胶带粘起来的大楼。

启示：AI 生成的代码必须被人类理解和审查。”能跑”不等于”正确”，更不等于”可维护”。

7. 幻觉成本定律

“AI 在生成代码时节省的时间，会被验证和修复 AI 幻觉所消耗的时间部分抵消。”

背景：

大语言模型有一个众所周知的问题——幻觉（Hallucination）。它会一本正经地调用不存在的 API、使用错误的参数、或者编造完全虚假的解决方案。

现实中的案例：

• AI 推荐了一个 npm 包，你花了 20 分钟才发现这个包根本不存在。
• AI 生成的代码引用了一个已经废弃的 API，编译能过但运行时崩溃。
• AI 信心满满地说”这是最佳实践”，但实际上是一个已知的反模式。

关键洞察：

AI 的生产力提升不是免费的。真实的效率公式是：

净效率 = AI 生成效率 – 幻觉验证成本 – 错误修复成本

对于资深开发者，这个公式的结果往往是正的（因为他们能快速识别幻觉）。 对于新手，这个结果可能是负的（他们无法分辨对错，会在错误的方向上越走越远）。

8. 70% 定律（AI 能力边界定律）

“AI 可以完成一个软件任务的大约 70%，但剩下的 30% 需要人类专业知识来完成，而这 30% 往往包含了 80% 的复杂度。”

背景：

随着 AI 编程工具的普及，开发者们逐渐发现了一个规律：AI 在”常见模式”上表现出色，但在”特定领域”上容易出错。

具体表现：

• AI 能快速搭好 CRUD 的脚手架（70%），但业务校验规则需要你自己写（30%）。
• AI 能生成标准的 API 接口代码（70%），但分布式事务的处理逻辑得你来（30%）。
• AI 能写出漂亮的 UI 组件（70%），但复杂的交互状态管理需要人类设计（30%）。

与 Pareto 原则的呼应：

这条定律和 80/20 法则形成了有趣的对照——AI 能做 70% 的工作量，但那需要人类完成的 30% 包含了 80% 的核心价值。

启示：不要期待 AI 完全替代程序员。真正有价值的是那 30% 的领域专业知识和复杂决策能力。

9. 逆 Conway 定律（AI 版）

“AI 正在消解组织边界对系统架构的约束。”

经典 Conway 定律：”系统架构反映组织沟通结构。”

AI 时代的变化：

• 过去：一个人只能写一个模块，所以系统按人头拆分。
• 现在：一个人 + AI 可以同时处理多个模块，跨模块的边界变得模糊。
• 过去：前后端分离是因为前后端是不同的团队。
• 现在：一个全栈开发者 + AI 可以同时搞定前后端，”分离”不再是必然。

更深层的影响：

AI 正在让”一个人等于一个团队”成为可能。这意味着很多基于团队边界而做出的架构决策需要被重新审视。

10. AI 复杂度守恒定律

“AI 不会消除软件的本质复杂度，只是将复杂度从编码阶段转移到了需求描述和验证阶段。”

背景：

Fred Brooks 在 1986 年的论文《没有银弹》中区分了两种复杂度：

• 本质复杂度：问题本身固有的复杂度，无法消除。
• 偶然复杂度：由工具和方法引入的复杂度，可以消除。

AI 确实消除了大量偶然复杂度（不用记语法、不用查 API 文档、不用写样板代码），但本质复杂度去哪了？

转移到了 Prompt 里：

• 过去的复杂度在代码里——你需要精确地写出每一行逻辑。
• 现在的复杂度在 Prompt 里——你需要精确地描述你想要什么。
• “描述清楚一个复杂需求”和”写出实现这个需求的代码”，可能一样难。

同时转移到了验证阶段：

• 过去你写代码时就在思考边界情况。
• 现在 AI 帮你写了，但你需要在 Review 时思考 AI 有没有遗漏边界情况。
• 复杂度没有消失，只是换了一个栖身之所。

11. Prompt 即架构定律

“在 AI 辅助开发中，Prompt 的质量决定了代码的质量上限。”

背景：

越来越多的开发者发现，同一个 AI 工具，不同人用出来的效果天差地别。关键差异就在于 Prompt 的质量。

表现：

• 新手的 Prompt：”帮我写一个登录功能。”→ AI 生成一个简陋的、没有安全考虑的登录页面。
• 资深开发者的 Prompt：”用 React + JWT 实现登录功能，需要防止 XSS、CSRF，密码用 bcrypt 加密，支持 remember me，登录失败需要限流。”→ AI 生成一个接近生产级别的实现。

启示：

在 AI 时代，”架构能力”正在从”写代码的能力”演变为”描述系统的能力”。能把需求拆解清楚、约束描述精确的人，才能驾驭 AI 产出高质量代码。

12. AI 助手悖论

“AI 对资深开发者的帮助大于对新手的帮助，但人们直觉上会认为相反。”

背景：

直觉上，我们会觉得 AI 对新手帮助最大——毕竟新手不会写代码，AI 帮他写。但现实恰恰相反：

为什么资深开发者收益更大？

• 资深开发者能判断 AI 生成的代码是否正确，新手不能。
• 资深开发者能写出更好的 Prompt，因为他们知道好的代码应该是什么样的。
• 资深开发者把重复性工作交给 AI，自己专注于高价值决策。
• 资深开发者能修正 AI 的错误，新手可能在错误的基础上越走越远。

对新手的风险：

• 过度依赖 AI 导致基本功缺失——不会调试、不理解底层原理。
• 无法区分 AI 的正确建议和错误建议，像是蒙着眼开车。
• 失去了通过”手写代码”来建立心智模型的学习机会。

启示：AI 不是学习的替代品，而是放大器——它放大你已有的能力。零乘以任何数还是零。

三：在 AI 时代反而更重要的经典定律

有些定律不但没有失效，反而变得比以前更加关键：

总结：AI 时代的生存法则

1. AI 改变了”怎么写代码”，但没有改变”写什么代码”——需求分析和架构设计的重要性不降反升。
2. AI 消除了偶然复杂度，但本质复杂度永远存在——它只是搬了个家。
3. AI 是放大器，不是创造器——放大你的能力，也放大你的不足。
4. 越是 AI 能帮你写代码的时代，理解代码的能力越重要——因为你需要判断 AI 写得对不对。

最终，软件工程的本质没有变——用有限的资源，在有限的时间内，构建满足需求的可靠系统。 AI 只是让我们手中的工具变得更强大了，但使用工具的智慧，仍然来自人类。