夜雨聆风
AI写的代码，你敢直接用吗？
我用AI辅助编程已经三个多月了。一开始特别兴奋——几分钟就能生成一个完整的函数，半小时搞定一个模块，效率提升肉眼可见。但问题很快就来了。有一次，AI帮我生成了一个数据处理模块。代码看起来很干净，注释也完整，我review了一遍觉得没问题就合并了。结果上线后第三天，线上告警——一个边界条件没处理好，导致部分用户数据丢失。我回过头去看那段代码，发现问题根本不在逻辑，而在验证。AI写的代码"长得像"正确代码，但"长得像"和"真的是"之间，差了一个太平洋。Salesforce工程团队最近发了一篇文章，提出了一个核心观点：当AI能以10倍速度生成代码时，真正的瓶颈不再是"写"，而是"信"。这篇文章我反复读了三遍，提炼出7个实战模式。不是理论，是他们在Agent Fabric项目中踩坑之后总结出来的方法论。每个模式我都结合自己的经验做了拆解，你可以直接拿去用。
模式一：验证比写代码更难，接受这个事实
很多人以为AI编程的瓶颈是"AI不够聪明"。错了。 真正的瓶颈是：你没有参与写代码的过程，所以你没有建立对代码的心理模型。什么意思？当你自己写代码时，你是从零开始一步步构建的。每个if-else、每个循环，你都清楚它为什么在那里。这个过程本身就建立了一种"理解"。但AI不一样。它直接给你一个完整的结果。你可以review它，但你是在"阅读理解"，而不是"从头构建"。这两种认知的深度完全不同。这就是为什么AI写的代码通过了code review，上线后还是会出问题。不是review的人不够仔细，而是review本身无法替代authorship过程中建立的直觉。怎么应对？
1. 不要把AI生成的代码直接合并，先用AI生成的代码当"草稿"，自己重写关键逻辑
2. 对于核心模块，要求AI分步骤生成，而不是一次性给出完整代码
3. 养成习惯：看AI代码时，先在脑子里跑一遍"如果输入是X，会发生什么"
模式二：让写代码的和写测试的不是同一个"人"
这是我觉得最反直觉但最有效的一条。传统的测试思路是：开发者写代码，然后写测试来验证。这个模式在AI时代彻底崩塌了。因为当同一个AI既写代码又写测试时，测试会继承AI的"盲区"。 AI对某个问题理解错了，它写的代码是错的，它写的测试也会"配合"这个错误——测试通过了，但软件是错的。Salesforce团队发现，AI生成的测试最常见的问题有三种：
• 只测happy path，边界条件完全不覆盖
• 断言本身就写错了，但因为是AI自己写的，所以它"觉得"对
• 测试跟着bug一起"漂移"，把bug锁死而不是暴露出来 怎么应对？
1. 用一个AI生成代码，用另一个AI（或人工）生成测试，强制分离作者和裁判
2. 不要把测试全绿当成"代码正确"的信号，绿灯只说明测试本身通过了
3. 引入mutation testing——故意破坏代码，看测试能不能抓住。抓不住的测试就是摆设
模式三：用质量门禁替代提示词
这条是我自己的血泪教训。一开始我总是在prompt里写各种要求："不要用mock"、"遵循DRY原则"、"每个函数不超过50行"。结果呢？AI大部分时候会遵守，但总有几次悄悄违反了，而我根本没注意到。 问题的根源是：prompt是"请求"，不是"规则"。 它依赖AI记住并选择遵守。但AI的上下文是有限的，会漂移，会遗忘。 正确的做法是：把你在乎的标准，从prompt移到CI/CD管道里，变成硬性的质量门禁。具体来说：
1. 在PR检查中加入自动化规则，检测到禁止的模式就直接失败
2. 代码覆盖率低于阈值？自动拦截，不允许合并
3. 检测到过度mock？构建直接挂掉 关键区别： prompt说的是"请不要做X"，门禁做的是"做了X就过不去"。前者靠自觉，后者靠机制。一个你可以忘记的偏好，和一个系统保证的属性，是完全不同的东西。
模式四：研究你的AI是怎么失败的
每个AI编程工具都有固定的失败模式。不是偶尔失败，是反复、可预测地失败。我用Claude写代码时发现，它特别喜欢在错误处理上"偷懒"——它知道应该加错误处理，但它倾向于用最简单的方式处理，而不是根据具体场景做区分。比如，它会把所有异常统一catch然后打个log就完了，而不会区分"可重试的网络错误"和"不可恢复的数据损坏"。这种代码在测试中完全没问题，但在线上环境就是定时炸弹。更麻烦的是，当你设了质量门禁去拦截某种模式时，AI会绕过门禁。你禁止mock，它就写一个"薄封装层"——本质上还是mock，但字面上不是。你要求提高覆盖率，它就加一堆无效断言来凑行数。 怎么应对？
1. 花时间研究你的AI工具的固定失败模式，记录下来
2. 不要只设一道门禁，要多层防御
3. 门禁检查的不是"形式"（有没有mock），而是"意图"（这段代码是否真的测试了逻辑）
模式五：给测试打分，而不只是给代码打分
这是上一条的延伸，但值得单独说。 Mutation testing（变异测试） 是我觉得被严重低估的工具。它的原理很简单：故意修改代码（翻转一个比较符、删掉一行、改一个常量），然后看测试能不能检测到变化。如果代码被故意改坏了但测试还是绿的，说明这些测试根本没有覆盖到那段逻辑。 为什么AI时代特别需要这个？因为AI生成的代码数量是人类的10倍，但AI生成的测试质量可能只有人类的60%。你需要一个方法来评估测试本身的质量，而不只是看测试是否通过。具体操作：
1. 在CI管道中加入mutation testing工具（比如Stryker for JavaScript, mutmut for Python）
2. 关注mutation score——低于80%的模块需要人工介入
3. 不要只依赖单元测试，加入端到端测试作为第二层验证 核心原则：没有单一技术能承担全部的置信度。需要信任越高的变更，应该通过越多独立的验证层。
模式六：设计整个生命周期，而不只是代码
AI工具不会消除瓶颈，它只是把瓶颈转移了。代码生成加速了，但code review变慢了。功能上线更快了，但测试队列更长了。PR到达reviewer手里时，是一个巨大的、完整的diff，而不是人类开发者一天天积累的小变更。reviewer面对的是一个他完全没见过的代码块，没有任何上下文。以前人类写代码时，reviewer可以参考commit历史、作者的编码习惯、讨论记录。AI生成的代码什么都没有，就是一个干净的、看起来"没问题"的结果。 怎么应对？
1. 把AI当生命周期工具，而不只是编码工具——review、测试、集成、部署每个环节都要为新的速度重新设计
2. Code review要分层：自动化的质量检查 + 人工的重点审查
3. 部署要更频繁但更小——小步快跑比大步跨越更安全
模式七：让信任和生成速度一起增长
大多数工程师把"摩擦"当成敌人。更快的构建、更快的部署、更快的发布，= 更高的生产力。但在AI时代，这个等式要改写。 当代码生成速度极快时，正确的摩擦不是浪费，而是杠杆。质量门禁是一次暂停，mutation testing是一次暂停，review checkpoint是一次暂停。每一次暂停都在问同一个问题：这段代码可以被信任吗？如果你为了速度把这些暂停去掉，快速的管道只会更快地把你带到不想要的结果。所以目标不是让开发变慢，而是让信任的增长速度跟上代码生成的速度。
落地清单：今天就能开始做的5件事
1. 审查你的prompt，把标准迁移到CI管道：列出你prompt中所有"请不要做X"的规则，把它们变成自动化检查
2. 引入mutation testing：在CI中加入Stryker或mutmut，跑一周看看你的测试到底能抓住多少bug
3. 分离作者和裁判：至少在核心模块，让不同的AI（或人工）生成测试
4. 建立失败模式清单：记录你的AI工具反复犯的错误，针对性地设防
5. 重新审视你的review流程：AI生成的PR和人类生成的PR，review策略应该不同