playbook/templates/prompts/coding/code-review.template.md

Code Review 流程

触发场景

收到 MR/PR 需要评审时。

准备

切换到对应分支并获取变更内容：

# GitLab
glab mr checkout <MR_ID>
glab mr view <MR_ID> | cat
glab mr diff <MR_ID> | cat

# GitHub
gh pr checkout <PR_NUMBER>
gh pr view <PR_NUMBER>
gh pr diff <PR_NUMBER>

评审流程

逐步执行以下维度。改动简单时可跳过某些步骤。

1. 理解业务目标

• 能否理解本次改动的业务目标？
• 如果目标不明确，先确认再评审。

2. High-level Review

• 改动是否放在了合适的位置？
• 是否尽可能复用已有实现？
• 是否有破坏现有设计与逻辑的可能？

3. Bug 检查

• 是否隐含业务错误、逻辑纰漏或安全问题？
• 未修改的相关联代码是否有遗漏？

4. 代码清晰度

• 逻辑是否简洁易懂？
• 命名是否清晰合理？
• 一年后再读，是否能轻松理解？

5. KISS 原则

• 是否有不必要的复杂度？
• 是否有未使用的定义、过多参数？
• 是否重复造轮子？

6. 单一职责

• 每个函数/类是否只做一件事？
• 文件/类/方法行数是否合理？

7. 测试覆盖

• 复杂业务逻辑（含 if/else/for）是否有测试？
• 测试是否有效（非空实现）？
• 不应过度测试无控制逻辑的代码。

输出

评审完成后，总结发现的重点问题，按严重性排列。

AI 与人工的分工

维度	负责方	说明
Bug、逻辑漏洞、安全问题	AI + 人工	AI 负责初筛与证据收集，结论需人工复核
代码清晰度、KISS、单一职责	AI + 人工	AI 提供候选问题，人工决定是否采纳
架构合理性、业务对齐	人工	AI 反馈少且准确率低，需人工把关
兼容性、历史债务、战略取舍	人工	依赖背景知识，AI 难以判断

规则：AI 结论必须附文件路径、行号或可复现依据；缺少证据时按待确认假设处理。

注意：评审不只看 diff，需结合代码库整体上下文做评估。