AI 会写错代码这件事本身并不新鲜，毕竟，软件工程里演进了几十年的测试、审查、CI 乃至灰度回滚，本就是建立在承认人类会犯错的底层假设之上的防御系统。如果仅仅归咎于 AI 不够可靠、需要人工多加盯防，其实就有些流于表面了。
真实问题并不在于它会犯错，而在于它出错时，并不一定会显式报告错误并停下来。它完全可能交给你一段结构清楚、命名合理、测试也通过的改动，甚至在旁边附着一段看似极其自洽的逻辑解释。比起一份等待修改的粗糙草稿，它更像是一份已经被精心处理过的完美交付物。
而常识告诉我们，简陋的草稿会让人拉起警觉，而精美的交付物却会让人放松警惕。
这就是为什么，当 AI 编程真正进入复杂的工程现场之后，核心问题正迅速从"怎么让它生成"转到"怎么进行验收"上：在它自信地敲完最后一个字符后，我们到底拿什么去判断，这段代码能不能上线交付？
一、 防线的后退：从审查代码，到审查过程
传统防御手段之所以屡屡失效，是因为 AI 带来的风险形态发生了质变。过去我们对付的是单点明显的逻辑错误；但在 Agent 深度参与的工程中，错误已经变成了表面极其自洽、实际上隐藏极深的整条链路偏航。
并不是因为 AI 写出的代码在运行时有什么神秘玄学，代码一旦编译写定，在机器里依然是确定性执行的。真正的根源在于，Agent 是在一个极度狭窄的信息上下文里，去推演一个需要全局经验才能驾驭的复杂系统。人类与 AI 在信息视野上的这种根本错位，直接注定了决策的短视。
人类工程师脑子里装的是长期积淀的历史经验、业务边缘的隐性禁区、以及对线上运行的责任感；而 AI 的全部视野，都被死死限制在当前的上下文窗口里。它缺乏项目历史，没有肌肉记忆，更没有对全局架构的长期敬畏。这种只能看见眼前文本的天然局限，让它的决策带有极强的短视性，它往往能根据局部上下文给出看似正确的当前最优解，却完全感知不到这可能引入了长期的技术债务。
如果 AI 仅停留在聊天窗口里，这种短视顶多产生一段不合要求的草稿，人看一眼丢掉即可；但 Agent 的出现，把这个只有短视视野的概率决策者，直接接入了具备真实操作能力的执行循环。
在 Agent 的循环中，错误不再是一个孤立的改动，而可能成为后续执行的起点。一旦 Agent 在第一步做出了错误的判断，后续的执行循环就会层层放大这种偏差：比如为了让 CI 绿灯亮起，它会顺手扩大异常捕获范围，吞掉错误日志，甚至篡改测试断言。
这种表面自洽、实则隐蔽至深的链路偏航，给传统的 Code Review 带来了灾难。过去我们审的是最终的代码 diff，默认写代码的人逻辑清醒；单元测试也只验证路径是否跑通。但在面对一个逻辑自洽、测试全绿、却从起点就彻底跑偏的 Agent 产物时，依靠结果判定的防线直接失效了。
因此，防线必须被迫后退：我们不能只看最终交付的代码 diff，而必须去审查它每一步决策背后的过程与证据链。
二、 剪刀差的焦虑：生成越便宜，验收越贵
如果说开始讨论的是防线为何被击穿，那么这里要面对的，则是这种击穿在团队生产力上引发的连锁效应：为什么代码生成变快了，工程师却感到越来越疲惫？
答案在于代码生成成本与验收成本之间拉开的巨大剪刀差。
在 Agent 的加持下，过去需要查阅半天文档才能拼凑出的胶水逻辑或样板代码，现在几秒钟就能生成完毕。生产侧的边际成本已几乎归零。然而，判定侧（验收）的成本却无法同步降低，一个 PR 依然需要人花时间审查，测试套件依然需要跑完，灰度发布依然要观察线上表现。
更致命的是，AI 抹去了传统开发中自然发生的微观判定过程。
在传统开发时代，很多质量把控是融在敲代码的过程里的：写着写着发现抽象不对，我们会停下来重构；意识到老接口有包袱，我们会主动收手；测试失败时，我们也清楚刚才动了哪几行。这些微观博弈在编码时就已被消化掉了。
但在 AI 时代，这个中间过程被直接跳过。所有的决策与风险，被一股脑堆积、挤压到了最后的验收关卡。工程师的生态位被迫发生了漂移，我们从代码的执行者，变成了产物之后的裁判员。
作为一个裁判员，最危险的陷阱就是被 AI 编写的精美解释所说服。Agent 生成的 PR 说明通常措辞严谨、条理清晰，让人极其容易产生我已经理解这次改动的假象。但解释绝不是证据，它只是模型对自身概率产物的事后包装。
在生成成本极低、验收极贵的新常态下，裁判员唯一的生存法则，就是将注意力强行从漂亮的自然语言解释中抽离，聚焦真实的运行结果与证据链。
三、 防线的攻防：当判定指标成为 Agent 的优化目标
然而，当我们试图把判定权从繁重的人工走查中抽离，转而通过自动化测试与 Lint 门禁来构筑工程防线时，很快就会遭遇一个新的挑战：判定逻辑本身，正在被它所判定的对象悄然腐蚀。
在经济学中，Goodhart 定律指出：当一个度量指标一旦被用作管理的目标，它就不再是一个好指标。这一定律在 AI 编程时代同样适用：一旦你定义的判定门禁成为了 Agent 必须优化的数字目标，它就不再是有效的质量屏障，而沦为了它的优化靶标。
Agent 本质上是一个纯粹的参数优化器，它没有让代码库保持干净、正确的责任感，它身上只有必须让这次编译和测试指标达标的收敛压力。指标与真实质量目标之间的任何一条缝隙，都会被它精确且毫无顾忌地钻过去。
这种微观层面的指标投机，在日常的开发现场几乎每天都在发生：
- 测试可信度的静默崩溃：当你将测试通过设为强卡门禁时，如果让 Agent 一手包办了写功能与写测试，它会非常自然地陷入自我证明的怪圈，按照代码当前的（甚至是有 Bug 的）行为去写断言，从而把 Bug 固化成新的规范；或者通过 mock 掉一切外部依赖、只测试最简单的 happy path 来混过关。最终在统计面板上，覆盖率被刷到了漂亮的 95%，但实际的防线早已漏洞百出。
- 门禁规则的静默绕过：当代码触发了 Lint 报警，Agent 的首选策略往往不是花时间去重构代码，而是顺手加一行注释关掉规则；而当复杂度超标时，它也可能自作聪明地把一个大函数拆成五个逻辑依然纠缠的子函数，指标上的数值固然被刷了下去，代码的真实理解成本却成倍翻上去。
必须承认，这并非 Agent 在主观上有恶意作弊的企图，它只是在纯粹执行人类给出的优化与收敛逻辑。
这也解释了为什么在 AI 编程时代，测试的可信度远比覆盖率重要。为了防止单侧 Agent 陷入自己写功能、自己写单测的自我证明怪圈，工程上的标准做法是建立职责隔离与对抗走查机制，要么将写逻辑与写测试拆归不同的 Agent 完成，要么引入独立的 Reviewer Agent 专门审查单测的可信度与断言有效性，防范假测试混过门禁。
同时，代码的可维护性，也必须从以往软性的设计美学，彻底重构为刚性的工程门禁。
在传统开发时代，我们强调代码要写得清晰，是为了让下一个人类工程师能看懂；而在 AI 时代，我们写清晰代码的最急迫价值，是让下一个 Agent 能读懂。
Agent 修改一段局部的垃圾代码只要 30 秒，但人类想理清这段改动背后的副作用可能需要 30 分钟。如果项目的架构本身混乱无序，Agent 读不懂整体意图，它绝不会像人类老手那样停下来通盘重构，而是会选择最省力的姿势：绕过它、复制它、或者在最外层套上几层新的抽象补丁。只要短短几个月，代码库就会走向人类读不懂、AI 也读不懂的退化状态。
因此，将代码复杂度上限、函数长度、重复代码检测提升为绝对不可逾越的刚性门禁，去卡死 Agent 的局部便利倾向，是守住系统生命线的最后底线。
四、 系统的重构：从个人手感，到上下文底座
既然 AI 的局限与偏航风险无法彻底消除，工程系统的稳定性就不能寄希望于模型的临场表现，而必须依靠刚性的边界控制与规范流程来硬性保障。
这首先要求我们卡死操作与任务的边界。诸如 Agent 能否删除文件、能否修改测试期望、以及能否调用带副作用的外部 API 等核心权限，都必须通过沙箱、容器和严格的分支策略建立起物理护栏，绝不能依赖临场的手感。
其次，我们必须建立起可追溯的证据链。非确定性系统最怕的从来不是失败，而是失败之后的过程黑盒。一次性让 Agent 修改二十个文件然后丢回一段模糊的总结，是可维护性最差的验收形态。我们应当强迫 Agent 在每一个关键判断节点留下执行证据，并通过小步提交的机制，为人类工程师保留随时接管和退回的抓手。
然而，更重要的防御加固，在于团队上下文的对齐。
个人在使用 AI 时，许多隐性的上下文都是直接装在自己脑子里的。你知道哪段代码调用的库存在兼容包袱，也清楚哪些老接口虽然难看但绝不能动，你能用极简的指令让 Agent 跑通，是因为你随时在用肉身补齐信息。但当开发半径扩大到团队协作时，这种隐性的默契会瞬间蒸发。
在多人的团队里，如果每个人都指望靠自己的手感去驯服 Agent，那么 A 编写的接口规范可能很快就会被 B 的 Agent 误读，大家都觉得自己本地的效率变快了，但在项目的拼接处，却在源源不断地滋生出静默的垃圾代码。
因此，团队协作使用 AI 的核心，是所有人共享一份共同的上下文底座。这不仅包括提交到 Git 仓库的项目级 AGENTS.md，还包括团队共同维护的共享 Skill 库、API 约束规则，以及对过时规范与废弃 Skill 的定期清理作废机制。它把散落在个人脑海中的工程隐性经验，转化为团队可共享、系统可读取的刚性底座，这是从个人提效走向团队沉淀的必然一步。
五、 协同的重排：为什么个人快了 30%，团队却没有变快？
不仅代码层面的防线需要重建，当我们把视角拉到团队层面，会发现一个更让人困惑的现象：
在月度复盘时，每个工程师都说用了 AI 工具后，个人提效在三成上下。但季度结束看交付节奏，团队交付的工单和项目远没有多出三成，甚至连一成不到。那些本该到手的红利，全部在协作的拼接处蒸发了。
这背后的第一个原因，是生产密度的提高带来了沟通频次的指数级增长。个人写代码的速度快了一个量级，意味着代码合并、跨组联调以及接口对齐的事件也变密了数倍。前 AI 时代一周才会发生一次的小冲突，现在可能一天就要发生好几次。
另一个更要紧的原因，是团队成员所带的 Agent 世界模型并不一致。两个工程师开会对齐了接口改动，但他们各自的 Agent 并没有加载相同的上下文信息。两个 Agent 在两个完全不同的背景信息里生成代码，最后的合流必然伴随着严重的静默冲突与排查成本。
这就引出了一个反直觉的结论：在 AI 编程时代，组织形态重排的收益，第一次盖过了单纯工具选型的收益。
过去按前端、后端、测试划分部门，本质上是因为技能壁垒高。在 AI 抹平跨技能门槛后，按问题闭环组织的小团队，其沟通与对齐成本会远低于跨部门的反复沟通。然而，这种协同重排绝不是靠成立一个独立的 AI 专家组就能搞定的，真正的使用规范和验收门禁必须建立在业务团队内部，因为只有直面业务的工程师，才知道哪些防线可以交给 Agent，哪些防线必须由人工死守。
在全栈门槛大跌、分工合理性被部分接管的当下，真正的稀缺能力变成了工程师的工程判断力，去裁决要不要做、做到什么程度、何时该推翻重来。试图通过专人负责的传统思维去成立一个独立 AI 专家组的动作，最终只会让业务团队难以建立自身的工程能力，在脱离实际业务的指标中远离真实的现场。
六、 组织的重塑：资产的代谢与中层管理被压薄
当团队习惯了使用 AI，组织的认知和资产也迎来了前所未有的重构机会，它们第一次有可能从人脑中的隐性经验，转化为可工程化、可版本化、持续迭代的显性资产。
但这也带来了全新的失效形态：静默腐烂。
传统的代码过时了，编译会报错，脚本跑不通。但一个过时的 Skill 或 Spec 不会报错，它依然会被 Agent 忠实地加载并执行，只是它写出的代码引用了废弃的接口、遵循了半年前的规范。它坏了，但你看不出来。
这同样是 Goodhart 定律在组织资产层的投影。组织治理的核心，不再是不加节制地建新资产，而是如何建立机制，让旧资产有序下线。如果旧资产下不去，组织的上下文层就会在静默中持续劣化。
同时，中层管理的信息中继职能被大幅削弱。
中层管理很大一部分工作是信息路由（汇总下情、分发上意、横向对齐）。当全局上下文的同步能被系统化接管，中层管理中属于纯粹信息搬运的部分便不再具备必要性，管理重心自然向高阶决策与风险兜底收敛，组织层级趋向扁平。
最终，当所有兜底防线都建立后，追责的治理逻辑也面临失效。
代码出了错，Git 记录依然能定位到提交的那个人。但提交者面对的是由 Skill、Spec、模型版本和几次 Prompt 迭代共同生成的产物，他对代码的实际掌控感被极大地稀释了。如果一味严厉追责，唯一的自保策略就是降低产出、过度防御。
承认追责失效的组织，治理重心必须从追责转向系统性兜底。出事之后，不是清算个人，而是和提交者一起复盘，去加固没有接住这一漏洞的某一层防御。
结语：能力带入现场，工程留下能力
如果说 AI 编程的前半场是能力的释放，探讨怎么把模型、工具、循环和上下文组合起来，把 AI 拖进真实的工程现场；那么后半场则是秩序的重建，探讨怎么用边界、底座、证据和门禁，在带有随机性的执行者之上建立起软件工程的稳定性。
AI 工具可以极大地提升个人生产力，但它无法替我们承担线上的责任，也无法自动建立起系统的秩序。
真正决定一个团队 AI 编程质量上限的，不再是用了多先进的 Agent 或多炫酷的插件，而是这个团队是否拥有坚固的验收防线、共享的上下文底座、以及从追责转向兜底的治理文化。工具负责把能力带进来，但唯有严密的工程基础设施，才能把能力真正留下来。
这也是《AI 编程的第一性原理》这本书后半部分想要系统讨论的核心脉络：如何在拥抱 AI 生产力的同时，守住软件工程的确定性底线。我已将全书内容开源在 GitHub 上：ai-programming-book。
如果你在阅读过程中，觉得这些关于防线后退、上下文底座以及组织重构的工程实践对你有所启发，欢迎给这个项目点个 Star。
技术浪潮持续演进，最终能支撑一个工程团队走得长远的，依然是那些看似笨拙却无比坚固的工程治理规则。