把代码diff丢给ChatGPT说"review一下"，你会得到什么？一段听起来很专业的总结，几条放之四海皆准的建议，也许能撞上1-2个真问题。这对生产环境远远不够。
问题出在提示词的设计。大多数人把AI当成评审员，实际上它更适合的角色是预评审检查清单执行者。AI不该批准PR，它该帮你在人类评审介入前，找出明显缺陷、缺失的上下文、薄弱的测试和危险的假设。
这要求输出必须是结构化的，而非一篇泛泛而谈的散文。
你需要的是评审包，不是小作文
当AI实质性参与了代码编写时，预评审环节至少应该检查：实现是否与声明目标一致、PR是否不必要的扩大了范围、逻辑错误或脆弱假设、缺失的边界情况、API/Schema/契约变更、安全与隐私风险、数据完整性风险、性能隐患、测试薄弱或缺失、可维护性问题、回滚或部署风险。
关键诉求很明确：不要模糊的长篇大论，要一份能直接行动的评审产物。
一个更可靠的提示词框架
试试这样组织提示词：
角色设定：扮演一位严格的高级工程师，在人类评审前预审此PR。
上下文结构：
- PR目标：[粘贴目标]
- 预期行为：[粘贴预期行为]
- 变更文件：[粘贴文件列表]
- Diff或相关代码：[粘贴代码]
输出要求：
1. 前5大风险，按严重程度排序
2. 在申请评审前必须处理的具体评审意见
3. 缺失或薄弱的测试
4. 可能的安全/隐私/数据完整性隐患
5. 任何模糊的需求或缺失的上下文
6. 最终建议：可进入人工评审/需要修改/需要补充信息
约束规则：
- 不得批准PR
- 若不确定，说明缺少什么证据
- 优先具体意见而非泛泛建议
- 区分阻塞性问题与可选改进项
这个框架有效，因为它给模型明确了任务、结构和约束条件。
PR模板是另一半工作流
提示词只是环节之一。PR描述本身也应该让AI评审更容易。一份好的PR模板应包含：变更内容、变更原因、故意排除在范围外的内容、相关截图或示例、已运行的测试、已知风险、回滚方案、是否由AI生成或修改代码、是否已完成AI预评审。
最后一点尤其有用：它让AI参与变得可见，却不制造戏剧性。团队不是在问"你用AI了吗"，而是在问"你是否完成了AI辅助代码所需的评审卫生工作"。
真正的收益
重新设计提示词的真正价值，不在于让AI输出更多文字，而在于迫使它扮演一个有明确交付标准的角色。当你要求的是可执行的评审产物而非友好的聊天回复时，AI的表现会显著不同。这不是魔法，只是给模糊工具施加了清晰约束。
热门跟贴