为什么 AI 写得越快，软件反而越难理解

在上世纪六十年代末，随着系统规模增长到开发者已无法有效掌控的程度，“软件危机”（Software Crisis）这一说法首次出现。此后，每一代人似乎都用更强大的工具“解决”了这场危机，但结果往往只是制造出了更大的问题。

Netflix 工程主管 Jake Nations 表示，如今，AI 正在把这一循环加速到一个新的阶段：无限软件危机（Infinite Software Crisis）。由 AI 生成的代码库，本质上是生成它们的那一连串曲折对话的映射。每一次澄清、每一次方向调整，都会被直接固化进系统架构中。我们正在用 vibe coding 的方式，一步步走向灾难。

Jake Nations 至今在软件工程和大规模 AI/ML 系统设计领域拥有 13 年以上经验，专注于管理复杂代码库与推动高质量工程实践。在 Netflix，他负责推动技术架构与严谨开发流程，强调要理解系统本质、控制复杂性以及在 AI 时代保持代码和设计的可维护性。

针对上述问题，Jake 认为解决之道只有一个：选择“简单”，而不是“容易”。一次冗长的对话很容易；而划分清晰、边界明确的独立阶段，才是真正的简单。他提出了一种三阶段方法论，并指出，当所有人都在以机器的速度竞相生成代码时，真正能够脱颖而出的工程师，是那些能够判断系统何时开始变得纠缠、复杂的人。在无限代码生成的时代，人类在最关键的节点上进行判断，将成为核心竞争优势。

下面是 Jake 的演讲分享，我们对此进行了翻译，并在不改变原意基础上进行了删减，以飨读者。

1 我们正在交付自己并不真正理解的代码

我交付过一些自己其实并不完全理解的代码。这些代码是 AI 生成出来的，测试也跑过，上线也没出问题，但如果你让我解释它到底是怎么工作的，我说不清楚。说实话，我敢打赌，在座的每一个人都做过同样的事。

所以，不如我们干脆承认一个事实：我们现在都在交付自己并不完全理解的代码。

我想带大家回顾一下，这种情况是如何发生的。首先，回顾历史，你会发现历史总是在重复。其次，我们其实掉进了一个陷阱：把“容易”和“简单”混为一谈。最后，我认为是有解法的，但前提是，我们不能把“思考”这件事外包出去。

过去几年，我在 Netflix 推动 AI 工具的落地应用，可以非常负责任地说，这种加速是真实存在的。以前需要好几天才能完成的待办事项，现在几个小时就能搞定；那些在计划里躺了好几年的大型重构，终于开始被真正推进。

但问题在于，大型生产系统总是会以意想不到的方式出现故障。一旦真的出问题，你必须非常清楚自己正在调试的代码是怎么运作的。而现实是，我们现在生成代码的速度和规模实在太快了，理解能力已经明显跟不上了。

说实话，我自己就干过这种事：生成了一大段代码，看了一眼，心里很清楚自己完全不知道它在干嘛。但测试过了，也能跑，那就先上线再说吧。这其实并不是什么新鲜事。每一代软件工程师最终都会遇到一个瓶颈：软件复杂度超出了他们的管理能力。

我们并不是第一批面临“软件危机”的人，但我们是第一批面临这种无限生成规模情况的人。

2 软件危机，一直在循环

如果我们把时间往前拨，你会看到类似的故事一再发生。

在上世纪六十年代末到七十年代初，一群当时最聪明的计算机科学家聚在一起，提出了一个判断：我们正身处一场软件危机之中。社会对软件的需求急剧增长，但我们的开发能力却严重跟不上，项目周期过长、效率低下，整体表现并不理想。

Edsger Dijkstra 曾指出：当计算机性能极弱时，编程只是一个小问题；而当计算机性能极强时，编程反而成了一个巨大的问题。随着硬件能力的提升，社会对软件的需求同步膨胀，最终所有压力都落在程序员身上。

这种循环不断上演。七十年代有了 C 语言，八十年代个人计算机普及，九十年代对象化编程盛行，新世纪迎来了敏捷、云计算、DevOps，而今天，我们迎来了 AI。

模式没有变，但规模彻底变了——它已经是无限的。

3 难点从来不在“写代码”

Fred Brooks 在《没有银弹》中指出：不存在任何一种单一技术，能够让软件生产率实现数量级提升。

因为真正困难的部分，从来不是写代码的机械层面，而是理解问题本身，并设计出正确的解决方案。这一点，是任何工具都无法替代的。

我们发明的所有工具，几乎都在让“机械部分”变得更容易，但核心挑战始终没有改变。

问题的关键在于，我们把“简单”和“容易”混为一谈。

简单关乎结构，意味着无纠缠；容易关乎便利，意味着省力。简单需要思考与设计，而容易随处可得。每一次选择容易，都是用当下的速度，换未来的复杂度。

AI 把“容易”推向了极致，也打破了过去还能慢慢修复复杂度的平衡。

4 对话式 AI，正在放大复杂度

通过对话一步步生成代码，看起来很自然，但它极易把一个简单问题演变成复杂混乱的系统。

每一次新的指令，都会在不知不觉中覆盖之前的架构决策，留下死代码、冲突逻辑和历史残骸。AI 会满足你的指令，却不会对糟糕的架构决策产生任何阻力。

在 AI 眼里，技术债不是债，只是更多的代码模式。

复杂度的本质是“纠缠”。系统一旦复杂，就几乎无法只改一个地方而不影响其他部分。

5 AI 真正需要的不是“更好的提示词”

在 Netflix 的实际案例中，旧授权系统与新系统高度耦合，复杂度已经高到 AI 无法安全重构。AI 无法区分哪些是业务本质，哪些是历史遗留的偶然复杂度。

最终，人类必须亲自下场，理解系统、拆解依赖、手工迁移，才能获得真正可用的方案。

这促使我提出一个方法：上下文压缩 / 规格驱动开发。把数百万 token 的代码库，压缩成清晰、可执行的规格说明，再让 AI 去实现。

6 三阶段方法论

第一阶段：研究
一次性引入所有相关上下文，生成一份系统研究文档，并进行人工校验。

第二阶段：制定可执行计划
形成任何工程师都能照着执行的详细实现方案，完成关键架构决策。

第三阶段：实现
在清晰规格约束下，由 AI 高效完成机械性实现工作。

真正困难的事情已经提前由人类完成，AI 只是执行者。

7 软件，终究是一项人类的事业

每一次为了追求速度而跳过思考，我们失去的不只是理解代码的能力，而是识别复杂度的直觉。

AI 不会内化失败经验，只会生成你要求它生成的东西。

软件失败的根本原因从未改变。真正重要的，始终是深入理解你的系统，理解到你可以安全地修改它。

当 AI 写下大部分代码时，真正的问题是：我们是否仍然理解自己在构建什么？