百人访谈揭示：AI写代码浪潮中什么是真正不可替代的

我们花了四个月时间，与超过 100 位技术负责人、架构师和资深工程师交流，了解他们的团队在实际工作中如何使用 AI。代码评审时间是一个真实的约束。但他们反复提及的那个问题更难命名：控制权。

关于 AI 与代码评审的主流叙事是一个吞吐量故事：AI 写代码比人读代码快，PR 队列积压，解决方案是用更好的机器人、更多的 QA、更多的自动化来加快评审速度。我们访谈的每个人都感受到了这种压力。但问他们人类是否仍然需要时，答案是一个坚定的"是"：决定质量的关键时刻仍由人掌控——设置 AI 的工作方式、写规范、评审上线内容。最后那个——评审，是最深忧虑所在。

人类没有离开这个循环。他们移到了它的边缘。

这个"是"在过去六个月里变得越来越具体。2025 年底模型发布后达到顶峰的那波狂热（也就是所谓的"Saaspocalypse 时代"）已经冷却成一种宿醉：几个月的无协调 AI 使用产生了多年的技术债务。三个时刻反复出现，被认为是不可还原为 AI 的人类工作。

AI 软件工厂。在生成任何代码之前，需要有人设置 AI 工作的系统：CLAUDE.md 和 AGENTS.md、规范、规则、规范格式、标准化工作流的 skills，以及 CI 检查。同样需要有人持续审计 AI 重塑后的架构和代码库。这与技术负责人一直以来的工作相同，只是现在面向的是 AI 而不是人。一个一致的发现是：让 AI 自行运行结构化工作的团队最终都退出了。代码文件膨胀到数千行，布局散落，到了一定规模后 AI 丢失了自己代码的线索。保持系统的可读性始终是人类的工作。

编写规范。LLM 很容易产出符合行业标准的代码，比如样板集成或用 Python 读取 CSV。随着 LLM 日益商品化，这类软件也随之商品化。这将价值推向了业务特定细节所在——在那里，提示者（prompter）的领域专业知识才是使软件变得非标准化的东西。

评审和验证。早期我们遇到了一些信徒，他们坚信自己可以再也不读自己的代码了。几乎我们访谈的没有人仍然相信可以交出代码库的所有权：大约 80% 的人仍然保持人工评审上线内容。AI 是一个工具，而且是一个快速的工具。没有关卡的加速只有一个目的地：法拉利是一种非常快的方式去撞墙。需要有人持有代码库正在变成什么的模型，因为当它崩溃的那一天，你需要的正是那个人。

"你得到的系统看起来是对的但实际不是，当一件事出错时，你完全不知道发生了什么。" — 一位创始工程师

早期创业公司是一个干净的例外，在这个阶段除了在跑道耗尽前找到市场外什么都不重要。可以理解。但我们听到了同样的账单在后来到来：一旦规模化后，代码库变得无法维护，新人无法上手，不止一个团队告诉我们他们暂停增长来清理或重建。债务没问题可以接受。它只是需要被纳入计划。

时间是一个真实的约束。控制权是更深层的担忧。

评审瓶颈几乎总是被描述为时间问题，而且它确实是一个时间问题。Addy Osmani 的《AI 时代的代码评审》就是这样描述的，我们自己的宣言也是如此。AI 的产出超过评审者，队列增长，评审者不堪重负。大约三分之二的团队将评审列为他们的瓶颈。

但这不是让我们惊讶的部分。在技术负责人旁边观察他们评审时，表面的关切不是时间而是控制：能够自信地说出，一个变更对他们负责的系统做了什么。大约 40% 的人直接承认了这种失控；更多的人绕着它说但没有找到一个准确的词。

一位高级工程师携带着一个代码库的心智模型，使他们能够非常快速地评审一个 PR：检查数据模型变更、检查 API、检查业务逻辑、浏览其余部分。完成。这个单一行为签署了一个变更并保持心智模型更新。这个模型就是使他们成为凌晨 2 点代码崩溃时正确人选的东西。

这就是 AI 打破的那个通行证。只要是人写的代码，评审就有一张安全网：作者是一个你认识的队友，你可以问他们在想什么，考虑了哪些边界情况，为什么走这条路而不是明显的那条。现在作者是一个实际上已经离开的陌生人。产生这个变更的推理存在于 AI 的会话中，而不是在 diff 里，所以评审者所有的只是代码。他们不是在针对一个已有的模型浏览，而是阅读每一个变更，并试图仅从代码推断为什么要做这个变更。

"现在我有一个 14,000 行的 PR。我到底要怎么理解发生了什么？我能信任它吗？"

评审机器人也无法弥合这个差距。它们标记单个行，又多了一条要读的流，而真正重要的问题没有被回答：这个变更对系统做了什么？推到极致，代码由一个模型编写，由另一个模型评审，直到人们悄悄地学会不再看那个信号。

"说到底，不过是 AI 在和 AI 说话。"

绑定约束从写代码转移到了理解代码。

写代码的新工具不会改变软件过程的用途。三十年的实践仍然有效。改变的是约束绑定在哪里：写代码现在很便宜，而阅读变更、理解它、为它负责，才是限制一切的那个步骤。那个步骤仍在一个人类可以掌握的 diff 界面运行。观察评审者工作时，我们看到他们过去廉价做的五件事变得昂贵了。

人类是必要的。他们只是没有正确的工具。

这些都不能使评审者的工作自动化，而这正是重点所在。不是因为 LLM 不能总结变更；它越来越能了。而是某个人仍然必须拥有结果并为之负责：对 on-call 轮值、对客户、对任何询问为什么它坏了的人。而拥有一个决策意味着理解它。更好的阅读界面不能决定一个变更是否正确；它只是归还上下文让你更快地决定。它不会拯救一个从未写下规范的团队，也不会把一个 300 文件的 PR 变成一个好主意。

人类远未离开软件开发过程。他们的角色正在转移：从敲代码转变为拥有对代码的判断力，以及保护 AI 侵蚀最快的那个资产——系统正在变成什么样的实时模型。我们认为 SDLC 的绑定约束已经改变，工具必须重建以适应它们。

这就是我们构建 Hervé 想要成为的界面：一个评审界面，在 diff 旁边向评审者呈现意图，这样他们可以重建心智模型而不是从 diff 反向工程它。

这些观察与你产生共鸣了吗？你呢，你是如何保持对代码库的控制权的？