很多人把 AI 编程助手只当成“帮我写代码”的工具但在真实项目里它更稳定的用法其实是做代码复盘。原因很简单生成代码容易跑偏复盘已有改动却可以围绕真实上下文、真实 diff 和真实风险来提问。这篇文章整理一套我自己会用的轻量流程适合个人开发者、小团队、远程协作项目也适合在提交 PR 前做一次自查。它不要求改项目结构也不需要引入新平台只需要把 AI 放在正确的位置上。## 1. 先把改动范围压小不要一上来把整个仓库丢给 AI。更好的做法是先写一张“五行变更卡”text这次改动解决什么问题影响的文件或模块用户能感知到的变化最担心的失败场景我已经验证过什么这张卡的作用不是给 AI 表演而是逼自己先把边界说清楚。边界越清楚AI 越不容易给出泛泛建议。## 2. 让 AI 只按风险分类提问题很多 AI 复盘失败是因为提示词太宽比如“帮我 review 一下代码”。它会很热情但结果往往像模板。我更推荐这样问text请只从三类风险看这次改动1. 可能破坏已有行为的地方2. 用户输入、边界状态、空值导致的问题3. 缺少验证或日志的地方不要重写代码。每个问题必须说明触发条件和建议验证方式。这能把 AI 从“写作者”变成“质检员”。它不需要替你做决定只需要帮你找盲区。## 3. 用反向测试找漏点复盘时最有价值的问题通常不是“正常情况能不能跑”而是“什么情况下会坏”。可以让 AI 基于改动列出反向测试- 输入为空时会怎样- 重复点击或重复提交会怎样- 网络慢、接口返回异常时会怎样- 老数据、旧配置、未登录状态是否还能兼容- 移动端、小屏幕或低权限用户是否会遇到不同路径这些问题很朴素但它们比抽象的“优化建议”更容易转化成真正的测试用例。## 4. 让 AI 检查“最小改动原则”个人项目经常有一个问题修一个 bug顺手改了很多无关代码。短期看像是勤快长期看会让回滚和排查变困难。我会让 AI 单独回答一个问题text这次改动里有哪些地方看起来和目标问题无关如果要降低回滚风险哪些改动可以拆出去它不一定总是对但会提醒你重新看一眼有没有把重构、样式清理、命名调整和真正的功能修复混在一起。## 5. 最后必须回到人工验证AI 复盘不是最终结论。我的收尾清单通常只有四项- 是否跑过最小验证路径- 是否记录了一个失败场景- 是否确认没有碰高风险配置或权限路径- 是否能用一句话说明这次改动值得合并如果这四项答不上来说明还没到发布或合并的时候。## 小结一套好用的 AI 代码复盘流程并不复杂先压缩改动范围再让 AI 按风险提问然后补反向测试最后回到人工验证。它最大的价值不是替你判断而是让你更快发现自己忽略了什么。对个人开发者来说这种流程比“让 AI 一次性写完所有代码”更可靠也更容易积累成长期的工程习惯。本文为原创实践整理使用 AI 辅助起草并经过人工改写、结构调整和例子核对。