AI 写代码越来越快，为什么线上故障反而更多了？
你有没有遇到过这种情况：上周合并了一个 AI 辅助生成的 PR，diff 看起来很干净，测试用例全部通过，代码审核&查验也没发现明显问题。两三天后，生产环境突然出现了谁都没预料到的故障。
如果你还没遇到过，那只能说你运气不错。因为这类问题在行业内已经越来越普遍，背后其实是有规律可循的。
AI 工具确实让团队的代码产出速度大幅提升，这部分效果是真实的。但它们并没有同步提升代码库安全吸收这些代码的能力。而这两个速度之间的差距，正是生产事故发生的根源。
那些「看起来没问题」的代码，问题到底在哪？
业界给这种失败模式起了一个名字：正确性幻觉。
AI 生成的代码语法规范、结构符合常见模式、能正常编译、测试也能通过。在代码审核&查验环节，看起来就像一位靠谱工程师写的。真正的问题是隐藏在表象之下——AI 基于某些假设生成的代码，只靠阅读代码本身根本无法发现。
根据我的观察，生产环境中最常出问题的主要有以下四类假设： 边界假设。「这个字段肯定会有。」——实际上并非如此。比如某个下游服务八个月前有过一次异常部署，在某些特定条件下开始丢弃该字段。测试环境通过，负载测试也没问题。但凌晨两点，一笔真实订单遇到真实边界条件时，问题就爆发了。
并发假设。「这个接口调用是幂等的。」——实际上不是。于是客户被扣了两次钱，而代码在审核&查验时看起来完全正确。AI 看到了重试模式，但并不知道关于「重复调用该接口会发生什么」的领域规则。
领域假设。「这两个订单状态是等价的。」——实际上不是。你的履约团队和计费团队对它们的处理方式一直不同，但没有人把这条规则写成可执行的约束。AI 更不可能知道，因为它根本不在代码里。
安全假设。「这个请求来自内部服务，所以是可信任的。」——但内部网络并不是你的安全边界。这类假设悄无声息地混入代码，在所有「信任干净代码」的审核&查验中一路绿灯通过。
代码能编译，PR 看起来整洁。但当生产数据遇上真实用户，那些缺失的规则就开始暴露问题了。
更棘手的是，这类问题不会在代码审核&查验时出现，它们只会在事故报告中出现。
跑得更快，为什么反而更慢了？
我给团队建立了一个心智模型。
每个系统都有变更吸收能力——也就是说，在开始出现故障之前，它最多能安全消化多少新代码。这个能力取决于你的契约、你的不变量测试覆盖率、你的可观测性、你的耦合度。当外部变更输入的速度开始超过这个吸收能力时，系统就会变得不稳定。这不会立刻发生，但一定会发生。
而真正让人意外的是：当你对一个跟不上吸收能力的系统施加更大压力时，实际的交付速度往往会下降。你在「更快生成代码」上省下的时间，会在调试、回滚和返工上被消耗掉两到三倍。
我见过的那些真正从 AI 辅助开发中获益的团队，靠的并不是更好的模型。他们建立了一套工程体系，能够吸收 AI 生成的变更，而不会在不知不觉中积累技术债务。
重构不是修修补补，是让你的速度翻倍
大多数团队对重构的理解是错的。他们通常把它当成三件事之一：日常清理、技术债务偿还，或者每个季度被推迟的路标项。
在「又快又安全地交付」这个目标面前，这三种框架都没有帮助。
正确的理解是：重构是降低变更成本的手段，让你的系统能够在更高频、更大量的变更冲击下保持稳定，而不积累隐性脆弱性。在 AI 加速编码的环境中，重构是速度的乘数，而不是拖累速度的税负。
持续重构能带来的实际收益包括：稳定边界让变更可预测地传播、低耦合避免意外级联、更清晰的所有权消除责任模糊地带、可测试的不变量让代码审核&查验不再被迫承担测试该做的事、更好的可观测性让偏差在被用户报告之前就被捕获。
与之对应的反模式是：在未解决的技术债务之上加速 AI 辅助交付。这样做会导致不一致性积累更快、生产回归更多，而净速度因为返工吞噬一切而实际倒退。
遥测：别信代码说的，信它做的
日志、指标、链路追踪——这些告诉你系统实际在做什么，而不是你以为它在做什么。
代码审核&查验告诉你代码写了什么。遥测告诉你代码实际在做什么。两者是两回事。当团队合并 PR 的速度越来越快，代码「说了什么」和「做了什么」之间的鸿沟会迅速扩大。
一个真实案例：团队上线了重构后的订单处理流程，代码审核&查验没问题，压测通过。但空值处理逻辑的一处小改动，导致某类边界订单开始静默失败——不报错，只是状态错误。如果没有人监控订单状态转换，团队要等到三天后客户投诉才会发现问题。
有了漂移检测，0.3% 的错误率就能被发现。而不是等到「周四收入怎么下降了？」才反应过来。
除了发现问题，遥测还能支撑：特性开关、金丝雀阈值、凌晨三点也能执行的回滚清单。如果回滚需要拉四人会议才能操作，那团队根本没有以 AI 速度安全运转的能力。
简化：把重构变成习惯，而非专项项目
持续消除隐藏耦合和模糊归属——不是作为一个独立项目，而是作为功能开发的一部分自然嵌入。
如果重构需要专门开一次路线图会议，它就不会真正发生。真正在做的团队，会把重构和功能开发打包在一起。既然已经在这个文件里了，追加改进几乎没有协调成本。顺手清理，改完就走。
AI 在这方面也能帮忙——它擅长发现重复代码，并建议在哪里应该定义边界。但你需要用自己的领域知识去验证它提出的结构性建议是否合理。AI 能看出模式，但你知道它建议的边界在你的系统里是否真的说得通。
而且要衡量真正重要的指标。不是代码看起来多干净，不是改动行数，而是：做改动这件事，时间成本是在降低还是在增加？这才是衡量重构效果的信号。
两周冲刺：安全加速的第一步
这件事不必变成一个大项目。以下是两周聚焦工作的具体做法——不开路线图会议，不暂停功能开发。
第一周：契约与安全
找到两到三个最脆弱的边界。哪里最容易出问题？团队里谁说过「我以为那一直是这样的」？这些就是契约的候选对象。把契约写下来，不只是数据结构，还有含义——每个字段代表什么？合法值有哪些？谁是负责人？出问题了找谁？
把契约验证加到 CI 里。Schema 校验在合并时作为一道关卡。写一个不变量测试，选那条一旦被违反就会造成最大损害的领域规则。一个测试套件，不用覆盖整个 backlog，只选最重要的一条。
第二周：可观测性与简化
添加漂移检测仪表盘和告警。追踪第一周发现的问题模式，在 0.3% 错误率时就能感知，而不是等客户来报。移除一个高风险耦合点——那个一旦变动就会引发最多连锁反应的共享依赖。把它拆出来，明确归属。
补充安全上线默认值：一个特性开关模板、金丝雀阈值，以及团队真正能在凌晨执行的回滚清单，而不需要临时拉会。
衡量。要有基准数据：PR 规模、每次变更引发的故障数、协调成本。现在就建基线，四周后复盘。
关键转变：从追求速度到构建可信赖的系统
平台工程社区花了多年时间构建更好的工具——内部开发者平台、标准路径、服务网格、可观测性技术栈。这些基础设施都假设团队可以在高速交付的同时，系统不会慢慢变脆。AI 只是让速度这侧发生了巨大变化，而安全这侧还没有跟上。
做得好的组织有一些共同点：契约是一等公民，而不是事后补充；领域不变量测试是独立实践，而不是覆盖率指标；可观测性真的在告诉你系统在发生什么，而不只是在说代码写了什么；重构是持续的，嵌入在功能工作中，而不是挂在 backlog 上的独立项目。
这些做法本身都不新鲜。新鲜的是，它们现在变成了系统运转的必要组件。没有它们，AI 辅助的提速不会产生复利，而是会振荡——快一个季度，然后随着技术债务到期而变慢。
AI 时代奖赏速度，但也比以前更快地惩罚脆弱——因为脆弱现在积累得更快。最终胜出的团队，不是代码生成量最多的那批，而是构建出了能安全吸收 AI 生成变更的系统——通过契约、自动化的验证、完整的遥测，以及持续简化实现的。
如果你现在交付很快，问题不在于要不要加护栏，而在于你是否已经积累了足够的隐性债务，让速度开始逆转。
你的周一行动：找一个最脆弱的边界，写下它的契约，加一条不变量测试。一切从这里开始。
评论