把代码贴给 AI，再问一句“有没有问题”，通常只能得到零散建议。真正能进入日常开发流程的做法，是先把评审目标、上下文和输出格式约定清楚，让每一条建议都能回到具体文件、行号和验证步骤。
先定义 AI 不该替你做的事
AI 可以帮助发现命名混乱、边界遗漏、异常分支和潜在安全问题；但它不能替代运行测试、阅读业务规则或对线上数据负责。提交前请先删掉密钥、用户隐私和生产配置，并明确它只能基于你提供的上下文判断。
评审输入要包含四块信息
| 输入块 | 要写什么 | 作用 |
|---|---|---|
| 目标 | 这段代码要解决的业务问题 | 避免只按语法挑刺 |
| 约束 | 语言、框架、性能或兼容要求 | 让建议符合项目现实 |
| 代码范围 | 文件、函数和调用入口 | 减少脱离上下文的结论 |
| 验收标准 | 必须通过的场景与测试 | 把建议变成可验证任务 |
可直接复用的评审提示词
你是项目的代码评审协作者。请只基于我提供的需求和代码判断，
不要假设未给出的接口或数据。
评审目标：检查正确性、异常处理、可维护性、性能与安全边界。
输出要求：
1. 先列出你理解的业务规则；
2. 按“高 / 中 / 低”标记问题；
3. 每项说明位置、触发条件、影响和最小修改建议；
4. 给出需要补充的测试用例；
5. 不确定时写“需要确认”，不要编造结论。
需求：
[粘贴业务目标与边界]
代码：
[粘贴最小可评审片段]把输出变成真正的修复清单
拿到结果后，先过滤没有定位依据的笼统意见。高优先级问题应当有复现路径；中优先级问题要能对应重构收益；低优先级建议放进技术债列表。每改一项，都让 AI 根据修改后的代码重新检查一次，重点看原问题是否消失、是否引入了新分支。
三个容易失效的写法
- 一次贴整个仓库：上下文太杂，结论容易漏掉关键调用链。
- 只问“有没有 bug”：没有验收规则，回答会停留在通用建议。
- 直接采纳补丁：先在本地测试，再由人工确认业务语义和权限边界。
当团队已经有固定规范时，可把命名、日志、错误码和测试要求作为附录加入模板。这样 AI 输出会越来越接近团队的评审语言，而不是每次从零开始。
