# Ack Code Review

> 接收一次 code review 审查报告，逐条判断是否采纳，并对采纳的问题基于当前代码做增量修复。Use when the user asks to handle a review report, adopt or reject review findings, continue fixing after code review, address review comments, or implement changes from a review document. 如果用户给了审查报告文件、review markdown、findings 文档，或者明确要求“根据 review 继续改造/整改/修复”，就应使用这个 skill。

- Skill: `vamdawn/ack-code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add vamdawn/ack-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vamdawn/ack-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: vamdawn (https://skillmd.com/u/vamdawn)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vamdawn/ack-code-review

---


# Ack Code Review

根据 code review 审查报告继续推进整改。这个 skill 的职责不是重新发起一次完整审查，而是消费已有审查结论，逐条做技术判断，并把应采纳的问题修到可运行、可验证的真实实现状态。

## 核心目标

完成以下闭环：

1. 读取审查报告
2. 拆分每一条 review 问题
3. 判断每条是否采纳
4. 对采纳的问题做增量修复
5. 对不采纳的问题给出明确技术依据
6. 输出固定结构的整改结果

## 适用场景

优先在这些场景使用：

- 用户要求“根据 code review 修复”
- 用户要求“按审查报告继续整改”
- 用户给了 review Markdown，希望决定哪些意见采纳并落地
- 用户强调当前代码已经修过一部分，希望在现有基础上持续修复
- 用户要求按实现方案和 review 依据继续改造，而不是自由发挥

如果用户要的是“重新做一次审查”，不要使用这个 skill，应切换到发起审查类 skill。

## 输入解析

优先读取 `$ARGUMENTS`：

1. 若 `$ARGUMENTS` 是文件路径，直接读取该文件
2. 若 `$ARGUMENTS` 是一段 Markdown 或文本，把它当作审查报告内容
3. 若 `$ARGUMENTS` 为空，先在仓库里推测候选审查报告，再向用户确认

当用户没有提供审查报告时，不要直接假定某个文件就是目标。优先按文件语义推测候选项：

- 最近新增或最近修改、文件名中包含 `review`、`code-review`、`findings`、`audit` 的 Markdown 文件
- 审查报告、整改记录、审计结论等语义接近的 Markdown 或文本文件
- 若仓库中存在常见目录，如 `docs/reviews/`、`reviews/`、`review/`，再把这些目录作为补充候选来源

推测完成后，向用户给出简短确认，例如：

`我找到了候选审查报告 A/B，默认建议使用 A。请确认。`

只有用户确认后再继续。

## 工作原则

始终遵守以下约束：

1. 增量修改，不推翻重写
2. 每一处改动都要能对齐实现方案或 review 依据
3. 禁止用 TODO、stub、mock、空分支来占位
4. 不因为复杂而跳过 review 中的问题
5. 以当前代码状态为基线继续推进，不抹掉已有修复成果
6. 修复后要验证，不要只停留在代码编辑完成

如果发现用户给的提示词和当前代码状态冲突，以当前仓库事实为准，并把冲突说明清楚。

## Step 1. 建立整改上下文

先收集三类输入：

- `review_report`: 审查报告本身
- `implementation_basis`: 实现方案、设计文档、需求说明、验收标准
- `code_scope`: 当前改动涉及的模块、目录、分支或 diff 范围

处理顺序：

1. 先读审查报告
2. 再找实现依据
3. 再收敛代码范围

如果用户没有显式给实现方案，不要立刻停止。先从以下来源推测：

- 用户当前会话里提到的方案
- 仓库中的设计文档、计划文档、需求文档
- 审查报告中引用的目标、约束和验收要求

如果仍然找不到完整实现依据：

- 可以继续处理那些“仅依赖代码正确性就能判断”的 review 问题
- 对于明显依赖方案判断的问题，要标记为“待确认”，并在输出中说明依据不足

## Step 2. 逐条拆分审查问题

把审查报告拆成原子问题，一条 issue 只表达一个可判断、可处理的点。

对每条 issue 提取：

- 编号或标题
- 原始描述
- 严重级别
- 定位信息
- 建议修改方案
- 关联的实现方案约束

如果审查报告写得比较散，主动整理成“问题列表”，不要照抄一整段模糊描述就开始改代码。

## Step 3. 判断是否采纳

阅读 [references/decision-rules.md](references/decision-rules.md) 后，对每条 issue 做三选一判断：

- `采纳`
- `不采纳`
- `待确认`

判断时必须基于证据，而不是迎合 review 语气。

### 采纳标准

以下情况通常应采纳：

- 审查指出了真实 bug、边界错误、漏测、风险实现
- 当前实现与方案、需求或既有架构约束不一致
- 审查指出了会影响正确性、稳定性、可维护性的问题
- 审查意见虽然表达方式不精确，但核心问题成立

### 不采纳标准

以下情况通常不采纳：

- 审查基于误读，代码实际上已经满足要求
- 建议与实现方案、项目架构或明确约束冲突
- 建议会引入更大破坏，而问题本身并不存在
- 审查只是一种风格偏好，且没有带来明确收益

### 待确认标准

只有在这类情况下才保留为 `待确认`：

- 缺少关键上下文，无法安全判断
- 审查意见之间互相冲突
- 是否采纳取决于业务规则，而仓库和会话里都没有证据

不要把本该自行判断的问题都推给用户。

## Step 4. 先给出整改计划，再动手改代码

在真正修改文件前，先整理一份简短整改计划，至少说明：

- 本次准备采纳哪些问题
- 每个问题会改哪些模块
- 哪些问题明确不采纳，以及原因
- 哪些问题暂时待确认，以及缺少什么信息

如果改动跨度较大，优先按风险最高的问题先修。

## Step 5. 执行增量修复

只对“采纳”的问题动手修改代码。

修复时遵守以下要求：

- 基于当前实现最小化改动
- 优先复用已有抽象、测试和模块边界
- 涉及多文件时，要把结构调整一次做完整
- 不留下半成品逻辑
- 如果发现某条 review 的根因比报告写得更深，要顺着根因一并修掉

如果某个问题已经被部分修复，不要覆盖式重做；在现有修复基础上补完缺口。

## Step 6. 验证修复结果

完成修改后必须运行与改动直接相关的验证：

- 单元测试
- 集成测试
- lint / typecheck
- 最小可复现场景验证

按改动实际情况选择最有证明力的验证方式，不要机械全跑，也不要完全不跑。

如果验证受环境限制无法执行，明确写出未验证项和原因。

## Step 7. 按固定结构输出

最终输出必须使用以下结构，且内容只保留和本次任务直接相关的信息。

### 1. 修改说明

- 本次解决了哪些 review 问题，逐条列出
- 每条对应实现方案中的哪部分，若没有完整方案则说明依据来自哪里
- 是否涉及结构性调整；若有，说明调整原因
- 哪些问题没有采纳，以及技术理由
- 哪些问题仍待确认，以及缺失的上下文

### 2. 代码修改

- 说明改动过的文件
- 概述每个文件承担的修改点
- 如果用户明确要求展示完整代码，再按文件分组给出完整可运行代码
- 默认不要在会话里粘贴超长文件全文，优先给文件路径和改动说明

### 3. 自检

逐条确认：

- [ ] 所有 review 问题已覆盖
- [ ] 没有占位实现
- [ ] 与实现方案一致
- [ ] 没有引入新问题

如果某一项不能打勾，必须说明原因。

## 冲突处理

遇到以下冲突时，不要停在表面：

1. 审查报告与实现方案冲突
2. 审查报告与当前代码事实冲突
3. 不同审查意见相互冲突

处理方式：

- 先指出冲突点
- 再说明你采用的判断依据
- 在可确定范围内继续修复
- 把不能确定的部分单独列出，而不是整单搁置

## 输出风格

- 直接、克制、面向执行
- 先给结论，再给证据
- 不写无关背景铺垫
- 不把“采纳了哪些意见”说成“已经彻底完成”除非有验证证据支持

## 禁止事项

不要这样做：

- 把审查报告视为绝对正确，不加判断全部接受
- 看到已有部分修复就推翻重做
- 用“暂留 TODO”代替真实实现
- 因为涉及多文件或结构调整就跳过问题
- 没有验证就声称修复完成
- 在没有用户确认的情况下，擅自选择一个推测出来的审查报告