过去大多数团队靠代码审查来解决这个问题，当有人审查你的合并请求时，他们不只是在查缺陷，更是在吸收上下文，理解某些决定为什么被做出，这就是团队的隐性知识。在DevEx领导者社区The Hangar，我们经常讨论代码审查。根据《Looks Good to Me: Constructive Code Reviews》一书的作者Adrienne Braganza Tacke的观点，代码审查最重要的功能其实是记录留存：记载代码库是如何演变的、为什么这么变，而不仅仅是抓bug。
那段对话现在看来已经像是另一个时代了，我们所熟知的整个软件开发生命周期，不仅在加速，更在坍缩和被重新定义，我最近说过，我们应该干掉代码审查，AI生成代码的速度远超人类能审查的速度。合并请求堆积如山，或者被橡皮图章一盖了事，那道审批关卡已经不再匹配我们当下做软件工程的方式了。
但如果AI现在生成了大部分代码，而没有人能读完所有代码，知识该怎么传递?
在代码差异之上做决策
我提出的解决代码审查瓶颈的方案是：把人工检查点前移，去审查意图，审查代码应当满足的契约：规格说明、方案、约束条件和验收标准，知识传递这部分也同样适用。
如果团队在生成代码之前就审查了意图和验收标准，知识传递就会在规划过程中自然发生，你不需要从500行的代码差异里反推决策。你是在任何东西被构建之前，就对齐少数几个关键选择。审阅者读的是10行决策，而不是500行代码。
无论是轻量级规格文档、一组验收标准，还是从prompt对话中提取的要点，原则都一样：让决策可见、可审查，知识就在那里。
当开发者使用Cursor或Claude Code时，他们在不断做决策：架构选择、行为权衡、范围判定，这些决策存在于prompt对话中，存在于与智能体的来回交互里，但当合并请求提交时，这些上下文就没了，代码在，背后的推理不在。
在实现之前形式化意图这个想法并不新，行为驱动开发(BDD)、测试驱动开发(TDD)和按契约设计(Design-by-Contract)这些方法，都试图在写代码之前，用结构化的、人类可读的规格来定义行为。BDD尤其要求团队用自然语言描述系统应该做什么，写成连非技术干系人都能读懂和验证的场景，而且是在写任何代码之前。
这些方法过去常被视为开销，写形式化的行为描述和契约需要纪律和时间。在交付压力下，团队经常跳过它们。AI让它们变得更实用，而不是更不实用。AI可以帮助生成结构化的验收标准、行为规格，甚至契约式描述。它也能帮助执行这些标准。
AI软件工程不是单人运动
我们时不时会听到有些工程师在外面跑智能体编排器，一天能产出10万行代码，比如Steve Yegge和他的Gas Town。有人说这就是软件开发的未来——单人开发者带着一群agent，但我不这么认为。构建软件，即便有智能体加持，也不是单人运动。
如果那个人被车撞了，别人能接手这个项目吗?他们理解所有做过的决定吗?不能。在企业环境中，你需要冗余。多个干系人、多个团队、协作。
知识传递的功能不会因为AI采用率上升而变得不重要，它变得更重要了，因为系统实际做的事和任何个人对它的理解之间的差距，正在以前所未有的速度拉大。没人希望自己的高级工程师成为瓶颈，因为只有他们知道自己是怎么从AI那里得到解决方案的。
当AI参与到流程的每一个环节时，协作的社会契约正在改变。存在作者身份模糊——一个人审查同事提交的代码时，不知道对方花了多少精力去理解这段代码的细节。审查员可能用AI来帮自己理解代码并发表评论，而作者可能用AI来回复这些评论，却没有花时间真正阅读和理解它们。
在AI出现之前的团队里，一个初级工程师的合并请求会产生：
• 高级工程师就惯用法模式给出4~8条评论
• 关于边界情况的来回讨论
• 一堂隐含的"我会怎么思考这个问题"的课
• 一位现在知道这部分代码存在的高级工程师
而在AI重度使用的团队里，同样的变更是：
• AI生成，稍作编辑
• AI审查，稍作通过
• 合并，零个人对它形成了心智模型
新型债务：认知债务
我最近和教授、研究员Margaret-Anne Storey聊过，她为此创造了一个术语：认知债务(cognitive debt)，她最初是在一组用AI快速构建的学生身上注意到这个现象的，某个时刻，学生们告诉她，他们已经没法再对产品做改动了。教授一开始怀疑是技术债务、代码混乱，结果发现学生们积累的是一种新型债务。
他们已经搞不清自己在做什么功能、为什么做，他们不知道团队里谁知道什么，其中一个团队里，只有一个人了解所有代码并理解它，因为是他在监督生成代码的AI，而团队其他人做不到这一点，而且就连生成代码的那个人，也并不真正理解生成了什么。
这就是团队开始用AI快速构建时的风险：因为现实中不可能审查数千行AI生成的代码而放弃代码审查，却什么都不做来替代知识传递的功能。
Anthropic的研究揭示了过度依赖AI编程助手在代码理解方面的弊端，他们对52名工程师的研究发现，AI辅助在任务速度上没有带来统计显著的提升，但在随后的理解测试中得分低了17%。降幅最大的是调试能力，概念理解和代码阅读也有小幅下降。结论很明确：被动地甩给AI("让它能跑就行")对学习的损害，远大于用它来提问和理解代码。
哪怕只是在用主智能体写完代码后触发一个对抗性智能体，问一些诸如"你为什么这么做?""你预期什么行为?""你考虑了哪些权衡?"这样的问题，也能在很大程度上减少认知债务，它迫使开发者在代码往前推进之前，先把理解说清楚。
让知识传递变得有意为之
那些判断和那些决策——这才是我们作为人类在AI优先的世界里真正提供的核心价值。你甚至可以说，大部分写出来的代码都是样板代码。我们真正在做的主要是架构决策、行为决策和技术决策。这些才是我们需要作为输入提供给AI系统的东西，而每一次变更都需要对这些决策有清晰的认知。
过去通过代码审查发生的很多知识传递是附带产生的，工程师吸收上下文，是因为他们必须看代码才能批准它。随着我们逐步淘汰审查，能够审查这些决策变得更加重要。
归根结底，工程师仍然要对自己创建的变更负责。所有这些决策都必须被追踪，必须有人能够审计它们、追问为什么做了某些决定，这就是你的可信来源。我认为团队协作和知识传递就是这样演进的，即便我说过我们应该干掉代码审查。
生产力的提升是真实的，值得追求，但每个纯粹以合并请求吞吐量为优化目标的企业，都是在拿自己的工程文化做实验。五年后，真正赢下来的不会是那些交付最多AI代码的企业，而是那些工程师依然理解自己交付了什么的企业。
