requesting-code-review

请求代码审查

调度代码审查员子 Agent，在问题扩大之前及时发现它们。

核心原则： 尽早审查，经常审查。

何时请求审查

必须：

• 在子 Agent 驱动的开发中，每完成一项任务后
• 完成主要功能后
• 合并到 main 之前

可选但很有价值：

• 遇到难题时（获取新的视角）
• 重构之前（检查基线）
• 修复复杂 Bug 后

快速开始

1. 获取 git SHA：

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. 调度代码审查员子 Agent：

使用 Task 工具并选择 code-reviewer 类型，填写代码审查员模板

必填占位符：

• {WHAT_WAS_IMPLEMENTED} - 刚刚完成的内容
• {PLAN_OR_REQUIREMENTS} - 应实现的功能
• {BASE_SHA} - 起始提交
• {HEAD_SHA} - 结束提交
• {DESCRIPTION} - 简要说明

3. 处理反馈：

严重程度	操作
Critical	立即修复，不要继续
Important	在开始下一项主要任务前修复
Minor	记录下来，之后处理；可以继续

详情请参阅严重程度指南。

与工作流集成

子 Agent 驱动的开发：

• 每完成一项任务后都进行审查
• 在问题叠加之前发现它们
• 修复后再开始下一项任务

执行计划：

• 每批（3 项任务）完成后进行审查
• 获取反馈、应用反馈，然后继续

临时开发：

• 合并前进行审查
• 遇到难题时进行审查

对审查意见提出异议

如果审查员有误：

• 给出技术依据并提出异议
• 提供能证明代码有效的代码或测试
• 引用计划要求
• 请求澄清

请参阅提出异议的示例。

常见错误

切勿：

• 因为“很简单”就跳过审查
• 忽略 Critical 问题
• 带着未修复的 Important 问题继续
• 在没有技术依据的情况下争论

务必：

• 在审查请求中提供完整上下文
• 立即修复 Critical 问题
• 记录有技术依据的异议
• 修复 Critical 问题后重新审查

示例

需要示例？ 请参阅审查示例与工作流，了解：

• 完整的审查输出示例
• 良好与糟糕的审查请求
• 针对不同场景的审查工作流
• 如何处理不同严重程度的问题
• 何时以及如何提出异议

需要模板？ 请参阅代码审查员模板，获取完整的子 Agent 调度模板。