把代码贴给 AI，然后问“有没有问题”，得到的往往是一长串看似专业、却无法落地的建议。好的代码审阅从来不是凭感觉挑毛病，而是围绕需求、风险和验证来做。把 ChatGPT 放进这条链路，它才会成为审阅助手，而不是重写机器。
第一步：先给“正确行为”，不要只给代码
在发送代码前，先写清四件事：这个函数要完成什么、输入输出是什么、已知问题如何触发、哪些地方不能改。缺少需求时，AI 只能根据代码猜意图，最危险的是它会把“看起来合理”的改动当成正确答案。
目标：用户提交空字符串时返回明确的校验错误，正常字符串保持原行为。相关文件只有 A 与 B。请先列出当前逻辑、可能的边界情况和最小修改方案；未经确认不要改接口、依赖或其他文件。
第二步：让它按风险排序，而不是罗列清单
| 风险层级 | 优先检查什么 |
|---|---|
| 功能正确性 | 正常输入、空值、边界值、异常路径是否符合需求 |
| 回归影响 | 调用方、返回类型、错误处理和兼容行为是否改变 |
| 安全与数据 | 权限、输入校验、日志、敏感信息和外部调用 |
| 可维护性 | 命名、重复逻辑、复杂度、注释与测试可读性 |
要求它针对每个发现给出“触发条件、影响、建议测试”，而不是只给“这里可能有问题”。无法解释如何触发的建议，先放进待验证列表。
第三步：把修改压缩到最小补丁
一次修改不要同时修样式、重构、升级依赖和改业务。让它先输出拟改文件与每处修改目的，再决定是否执行。这样即使结果不对，也能快速回退和定位。
请只提出最小补丁：保留现有公开接口和数据结构。每项修改说明原因、涉及行或函数、可能影响的调用方；不要顺带格式化或重构无关代码。
需要持续维护需求、代码与讨论时，可用画布协作流程把每一轮修改范围固定下来；复杂协作则把需求、决策和测试记录收进项目工作区。
第四步：先写最小测试，再考虑合并
一次改动至少要覆盖三类情况：
- 正常路径：预期输入得到预期输出；
- 边界路径：空值、最大最小值、缺失字段、重复调用等；
- 失败路径：非法输入、外部服务失败、权限不足或超时。
让 AI 把测试意图写成表格或伪代码也可以，但最终要在你的实际环境里运行。测试通过只是最低门槛，还要检查日志、性能、权限和真实数据行为。
代码审阅的边界
不要把密钥、生产数据、客户隐私和完整内部仓库随意复制到不合适的对话里。对安全敏感的改动，AI 的建议只能是补充视角，不能代替专业安全审查。上线前仍应由负责人确认需求、审阅变更、运行测试并保留回滚方案。
把审阅流程拆小，AI 才能在每一环节提供清楚的帮助：先理解，再识别风险，再给最小修改，最后用测试证明。这样既提升速度，也不会把质量责任交出去。
