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 后，对每条 issue 做三选一判断：

• 采纳
• 不采纳
• 待确认

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

采纳标准

以下情况通常应采纳：

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

不采纳标准

以下情况通常不采纳：

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

待确认标准

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

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

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

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

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

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

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

Step 5. 执行增量修复

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

修复时遵守以下要求：

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

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

Step 6. 验证修复结果

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

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

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

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

Step 7. 按固定结构输出

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

1. 修改说明

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

2. 代码修改

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

3. 自检

逐条确认：

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

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

冲突处理

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

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

处理方式：

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

输出风格

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

禁止事项

不要这样做：

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