---
name: vaycentsun/sw-code-review
source: https://app.decimal.ai/s/vaycentsun-sw-code-review@1/SKILL.md
source_sha256: 5c84e4f0ebba
---

# 代码审查

在软件开发流程中自动执行代码审查：完成任务后自动发起审查，收到反馈后技术严谨地处理。

**核心原则：** 审查是流程的自动环节，不是可选步骤。实现前先验证，不表演性同意。

## 阶段一：请求代码审查

### 何时自动触发

**强制触发点：**
- 子 Agent 驱动开发中每个任务完成后
- 完成主要功能后
- 合并到 main 之前

**开发流程集成：**
- 每个任务后自动审查
- 每批（3 个任务）后批量审查
- 合并前最终审查

### 如何请求

**1. 获取 git SHAs：**
```bash
BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)
```

**2. 分派代码审查者子 Agent：**

使用 Task 工具配合 `sw-code-review` 类型，填写 `./code-reviewer.md` 模板

**占位符：**
- `{WHAT_WAS_IMPLEMENTED}` - 你刚刚构建了什么
- `{PLAN_OR_REQUIREMENTS}` - 它应该做什么
- `{BASE_SHA}` - 起始提交
- `{HEAD_SHA}` - 结束提交
- `{DESCRIPTION}` - 简要摘要

**3. 根据反馈行动：**
- 立即修复关键问题
- 继续前修复重要问题
- 记录次要问题稍后处理
- 如果审查者错了，反驳（附推理）

**4. 审查通过后自动推进：**

```
审查通过
    ↓ 自动进入
sw-task-verification（功能验证）
    ↓ 通过
标记任务完成 → 进入下一任务
```

审查不通过 → 修复 → 重新审查（循环最多 3 次）

## 阶段二：接收代码审查

当收到代码审查反馈时（无论是来自子 Agent 审查者还是外部审查者），自动进入处理流程。

### 响应模式

```
1. 阅读：完整阅读反馈，不做反应
2. 理解：用自己的话重述要求（或询问）
3. 验证：根据代码库现实检查
4. 评估：对此代码库技术上合理吗？
5. 回应：技术确认或有理有据的反驳
6. 实现：一次一项，每项都测试
```

### 禁止的回应

**绝不：**
- "你说得完全正确！"（明确的 AGENTS.md 违规）
- "好观点！" / " excellent feedback!"（表演性的）
- "我现在就实现它"（验证之前）

**改为：**
- 重述技术要求
- 提出澄清问题
- 如果错了，用技术推理反驳
- 直接开始工作（行动 > 言语）

### 处理不清晰的反馈

```
如果任何项目不清晰：
  停止 - 还不要实现任何东西
  询问不清晰项目的澄清
```

**示例：**
```
用户："修复 1-6"
你理解 1,2,3,6。不清楚 4,5。

❌ 错误：现在实现 1,2,3,6，稍后询问 4,5
✅ 正确："我理解项目 1,2,3,6。需要澄清 4 和 5 后再继续。"
```

### 按来源处理

**来自用户：**
- **可信** - 理解后实现
- **仍然询问** 如果范围不清
- **不要表演性同意**
- **跳过行动** 或技术确认

**来自外部审查者：**
```
实现之前：
  1. 检查：对此代码库技术上正确吗？
  2. 检查：会破坏现有功能吗？
  3. 检查：当前实现的理由？
  4. 检查：在所有平台/版本上有效吗？
  5. 检查：审查者理解完整上下文吗？

如果建议似乎是错的：
  用技术推理反驳

如果不能轻松验证：
  说出来："我无法在没有 [X] 的情况下验证这个。我应该 [调查/询问/继续] 吗？"

如果与用户的先前决策冲突：
  先与用户讨论
```

**规则：** "外部反馈——保持怀疑，但仔细检查"

### YAGNI 检查"专业"功能

```
如果审查者建议"正确实现"：
  在代码库中搜索实际使用

  如果未使用："此端点未被调用。删除它 (YAGNI)？"
  如果使用：那么正确实现
```

**规则：** "你和审查者都向我汇报。如果我们不需要这个功能，就不要添加。"

### 实现顺序

```
对于多项目反馈：
  1. 先澄清任何不清晰的内容
  2. 然后按此顺序实现：
     - 阻塞性问题（破坏、安全）
     - 简单修复（拼写、导入）
     - 复杂修复（重构、逻辑）
  3. 单独测试每个修复
  4. 验证无回归
```

### 何时反驳

反驳当：
- 建议破坏现有功能
- 审查者缺乏完整上下文
- 违反 YAGNI（未使用的功能）
- 对此技术栈技术上不正确
- 存在遗留/兼容性原因
- 与用户的架构决策冲突

**如何反驳：**
- 使用技术推理，不是防御性
- 提出具体问题
- 引用工作的测试/代码
- 如果涉及架构，请用户参与

**如果不舒服大声反驳：** "Strange things are afoot at the Circle K"

### 确认正确的反馈

当反馈正确时：
```
✅ "已修复。[更改的简要描述]"
✅ "好发现——[具体问题]。在 [位置] 修复。"
✅ [直接修复并在代码中展示]

❌ "你说得完全正确！"
❌ "好观点！"
❌ "感谢指出！"
❌ "感谢[任何东西]"
❌ 任何感谢表达
```

**为什么不要感谢：** 行动胜于言语。直接修复。代码本身表明你听到了反馈。

**如果你发现自己要写"感谢"：** 删除它。改为陈述修复。

### 优雅地纠正你的反驳

如果你反驳了但错了：
```
✅ "你说得对——我检查了 [X]，它确实 [Y]。正在实现。"
✅ "验证了这个，你是对的。我最初的理解错了，因为 [原因]。正在修复。"

❌ 长篇道歉
❌ 为为什么反驳辩护
❌ 过度解释
```

## 与工作流集成

**调用链：**
```
sw-subagent-development 完成任务
    ↓ 自动
sw-code-review（本 Skill）
    ↓ 审查通过
sw-task-verification（功能验证）
    ↓ 验证通过
标记任务完成 → 进入下一任务
```

**子 Agent 驱动开发：**
- 每个任务后自动审查
- 在问题复合前捕获
- 进入下一个任务前修复
- 审查通过后自动进入 `sw-task-verification`

**执行计划：**
- 每批（3 个任务）后审查
- 获取反馈，应用，继续

**临时开发：**
- 合并前审查（由 sw-finishing-branch 决策是否调用）
- 卡住时审查

## 与 sw-task-verification 的边界

| 维度 | sw-code-review（本 Skill） | sw-task-verification |
|------|---------------------------|---------------------|
| **关注点** | 代码质量（静态） | 功能正确性（动态） |
| **核心问题** | "代码写得好吗？" | "功能正常工作吗？" |
| **验证方式** | 代码审查、架构评估 | 运行测试、手动验证、集成测试 |
| **触发时机** | 代码完成后 | 代码审查通过后 |
| **不通过时** | 修复代码，重新审查 | 修复问题，重新验证 |

**本 Skill 不处理：** 功能测试、边界验证、回归验证 —— 这些由 `sw-task-verification` 负责。

## 红旗 - 停止并审查/评估

| 想法 | 现实 |
|------|------|
| "这个很简单，不需要审查" | 简单代码也有盲点。10 分钟审查可能节省数小时调试 |
| "审查者错了，忽略" | 用技术推理反驳，不是忽略。有效反馈可能来自误解 |
| "先继续，稍后修复" | 问题会复合。进入下一任务前修复 |
| "自审就够了" | 自审有盲点。独立审查发现不同问题 |
| " deadline 紧，没空审查" | 未审查的代码会让 deadline 更紧 |
| "你说得完全正确！" | 表演性同意违反 AGENTS.md。重述要求或直接行动 |
| "好观点！" / "excellent feedback!" | 表演性回应浪费时间。行动 > 言语 |
| "我现在就实现它" | 验证之前不实现。检查是否破坏现有功能 |
| "审查者一定是对的" | 外部反馈是建议，不是命令。先验证 |
| "批量修复更快" | 一次一项，每项都测试。批量 = 引入回归 |

## 常见借口表

| 借口 | 现实 |
|------|------|
| "审查浪费时间" | 10 分钟审查可能节省数小时调试 |
| "我已经自审过了" | 自审有盲点，独立审查发现不同问题 |
| "审查者不懂这个领域" | 外部视角常发现领域专家遗漏的问题 |
| " deadline 紧，没空审查" | 未审查的代码 deadline 后会成为技术债务 |
| "合并前再审查也行" | 问题在代码库中停留越久，修复成本越高 |
| "审查者是对的，直接实现" | 外部反馈需要先验证。可能破坏现有功能 |
| "批量修复更快" | 一次一项，每项测试。批量修复容易引入回归 |
| "感谢反馈是礼貌" | 行动胜于言语。代码本身表明你听到了反馈 |
| "反驳不舒服，就同意吧" | 技术正确性 > 社交舒适。有理有据的反驳是专业行为 |
| "项目都清楚，不需要澄清" | 部分理解 = 错误实现。不清楚就询问 |

参见模板：`./code-reviewer.md`