AI 生成的代码不敢用怎么办：3 步验收清单一次讲清

你让 AI 写了一段功能代码，本地一跑居然过了，可真要合进项目、交给团队你又心里发毛——这种谨慎完全正当，别觉得自己多疑。直接给结论：能跑不等于能合，AI 代码必须经过验收再入库。本文给你一套三步验收清单——先让它说清改了什么、再跑通测试与边界用例、最后人工复查风险点，并讲清怎么把这套流程固化成日常习惯。尤其在你还不熟悉 AI 生成代码的边界时，编程狮这篇就帮你从"不敢用"变成"用得稳"。

AI 生成的代码不敢用怎么办：3 步验收清单一次讲清封面图

一、为什么"能跑"不等于"能合"

很多初学者把"本地跑通"当成验收结束，这是最危险的误区。AI 生成的代码有三个典型坑，跑通根本查不出来。

第一，过度设计。AI 为了让回答"看起来专业"，常引入用不上的抽象、额外的配置层。功能能跑，但半年后没人敢动它。这叫"能跑的屎山"。

第二，隐藏依赖。它可能在代码里悄悄 import 了一个你项目没装、甚至已经废弃的包，或者调用了某个环境变量。本地恰好有，别人的机器一拉就崩。

第三，边界缺失。正常输入能跑，但空值、超长字符串、并发、时区这些边界它几乎从不考虑。一旦上线遇到，bug 就藏在这里。

所以"能合"的标准不是运行不报错，而是：改动可解释、行为可预期、风险可控制。下面这份验收清单，就是围绕这三点设计的。想先建立 AI 与编程的整体认知，AI 人工智能教程从基础到实践都有覆盖，适合作为理论底座。

二、第一步验收：让它说清改了什么

验收清单的第一步，不是看代码，而是让 AI 先交代清楚。凡是你让 AI 改的代码，都要求它输出一份变更说明，包含三件事：改了哪些文件、每个文件改了什么、有没有新增依赖。

请基于这次改动，给我一份变更说明：
1. 涉及文件清单及各自改动点；
2. 是否新增了依赖或环境变量，若有列出名称；
3. 这次改动可能影响的其他模块。

为什么要先要说明？因为 diff（代码差异）本身不带语义。你能从 diff 看到"加了一行"，但看不出"这行会不会在空输入时崩溃"。让 AI 自己讲一遍，既是逼它复盘，也方便你做下一步审查的路线图。

很多 AI 编程工具有内置的变更说明能力，Cursor AI中文教程里对这类工具的改动预览和说明功能讲得很细，可以对照着用。这一步花两分钟，能挡掉一大半"改了不知道改了啥"的隐患。

三、第二步验收：跑通测试与边界用例

验收清单的第二步，是把上一步的说明落到测试上。别只跑原有的用例，要专门为这次改动补边界用例。

// 假设 AI 写了一个解析用户输入的函数
function parseUserInput(raw) {
  return raw.trim().split(',');
}

// 最小边界用例：空值、超长、特殊字符都要覆盖
test('空字符串返回空数组', () => {
  expect(parseUserInput('')).toEqual([]);
});
test('前后空格被去掉', () => {
  expect(parseUserInput('  a , b ')).toEqual(['a', 'b']);
});
test('无逗号时返回单元素', () => {
  expect(parseUserInput('hello')).toEqual(['hello']);
});

这段测试故意覆盖了空字符串、空格、无分隔符三种边界。AI 生成的代码往往在"正常输入"上完美，在边界上露怯。你补的边界用例越多，它藏不住的坑就越多。

跑通测试还不够——要看测试是不是真的覆盖了改动点。如果 AI 说"改了校验逻辑"，那对应的校验分支就必须有用例，否则这一步等于没做。

四、第三步验收：人工复查风险点

验收清单的第三步，是你亲自上阵做人工复查。重点盯四类风险点，这是 AI 最容易翻车的地方。

第一，权限。代码有没有越权读写了它不该碰的文件或接口？比如一个简单的导出功能，悄悄带上了删除权限。

第二，密钥。有没有把密钥、token 硬编码进代码，而不是走环境变量？这是常见的安全雷。

第三，外部调用。是不是新增了对外部服务、外部网络的请求？这些调用在异常时有没有超时和降级？

第四，异常处理。出错时会不会把内部堆栈直接抛给用户，或者静默吞掉错误导致问题难查？

关于"把 AI 能力封装成可复用技能"这件事，智能体技能中文教程里讲了怎么把这类审查流程沉淀成标准化动作，值得一看。人工复查不用逐行读，就抓上面四类，效率最高。

五、三步清单怎么固化成日常流程

三步验收清单如果只是"想起来才做"，迟早会漏。要固化成日常，关键是把它接进你已有的开发流程，而不是另起炉灶。

第一步，分支隔离。每次让 AI 改代码都在独立分支进行，合入主干前这清单就是门槛。分支天然划出了"待验收区"。

第二步，PR 模板。把三步清单写进 Pull Request 的描述模板：变更说明、测试与边界用例、风险点自查，缺一项就不让 review。

第三步，CI 门禁。在持续集成里加一道硬闸：测试不通过、或新增依赖未声明，就直接拒绝合并。把人工容易忘的环节交给机器兜底。

这三道加起来，AI 生成的代码从"写完"到"合入"之间始终有一张网拦着。清单本身不用复杂，关键是每次都走一遍，让它变成肌肉记忆。

按 AI 改动范围确定人工复查优先级的决策树

总结

AI 生成的代码不是不能用，而是不能"能跑就合"。把三步验收清单刻进流程：第一步让它说清改了什么，第二步用边界用例跑通测试，第三步人工复查权限、密钥、外部调用和异常处理四类风险点。再把清单固化成分支、PR 模板和 CI 门禁，你就从"不敢用"跨到了"用得稳"。下一步，建议先把这份清单贴进你的 PR 模板，从下一个 AI 改动开始执行。

延伸学习

想把 AI 写代码这件事系统地练成能力，可以按这个顺序补：

先跟着腾讯CodeBuddy+AI设计网页实战课程在真实项目里用 AI 设计网页，把验收流程跑熟；
质量意识这块，这篇 AI 编程质量反思笔记聊了"全民造码"背后的代码质量隐忧，值得对照自省；
概念入门可读 Agentic Coding 入门笔记，从零理解什么是智能体编程。

常见问题

Q：AI 说代码没问题，还要自己测吗？

要。AI 的"没问题"只是基于它见过的模式，不等于覆盖你的边界场景。边界用例必须你根据业务自己补，这是验收清单第二步存在的理由。

Q：小改动也要走三步吗？

改动越小，三步越快，反而更该走。一行改动也可能悄悄引入隐藏依赖或权限变化，花两分钟过一遍清单，比上线后回滚划算得多。

Q：CI 门禁能完全替我审查吗？

不能。CI 只能卡住测试和依赖这类可量化项，权限、密钥、异常处理的判断仍靠人工。门禁是兜底，不是替代，第三步的人工复查始终不能省。