review-iterate

执行原则（必须遵守）

1. 审查和修复必须交替进行，不可只审不修。 每次 Task A 结束后，必须立即执行 Task B 修复发现的问题。禁止在 Task A 后停止并只展示问题清单。
2. Task B 不是可选步骤。 发现问题后的唯一正确行为是修复它（或明确标注跳过原因），然后继续下一轮 Task A 验证修复结果。
3. 修复必须直接编辑待审文档文件。 不是输出修复建议让用户手动改，而是你自己用 Edit 工具直接修改文件。
4. 整个流程是一个连续循环，直到收敛才停止。 不要在某一轮结束后询问用户"是否继续"——直接继续，直到 Task A 审查发现 0 个新问题。

迭代式审查与修复

0. 参数解析

从用户的指令中提取以下信息（若不明确，立即通过 AskUserQuestion 确认）：

• 参考文档（Reference Docs）：待审文档必须与之保持一致的权威文档，可能是 1 个或多个（如 PRD、详细开发计划等）。
• 待审文档（Target Doc）：需要审查和打磨的文档（如 Design doc、E2E 测试文件等）。
• 审查角度（Perspective）：用户指定的审查侧重点。常见角度：
  • "与参考文档的一致性"（跨文档冲突、遗漏、术语不一致）
  • "完整性"（待审文档是否覆盖了参考文档的全部需求）
  • "测试覆盖率"（测试用例是否覆盖了设计中的所有场景）
  • 用户自定义角度

若用户只提供了参考文档和待审文档，未指定审查角度，默认审查角度为"跨文档一致性 + 完整性"。

1. 整体流程

交替执行 Task A（审查） 和 Task B（修复），直到收敛。这是一个循环，不是一个单次操作。

• 最大轮次：6 轮（可由用户通过参数覆盖）。
• 每一轮 Task A 都从零开始独立审查，不得依赖之前轮次的审查结论或修复记录。
• 每一轮 Task B 修复完成后，必须进行自查确认修复正确且未引入新问题，然后进入下一轮 Task A。
• 关键约束：每轮必须包含 Task A + Task B 两个阶段。审查报告不是最终输出，修复后的文档才是。

2. Task A：全面审查

对待审文档进行从零开始的、独立的、全面深入的审查。

2.1 审查方法

1. 完整阅读参考文档和待审文档的全部内容（不能只读部分章节）。
2. 基于用户指定的审查角度，逐项检查。

2.2 通用审查清单

以下清单适用于所有审查角度，按需叠加用户指定的额外检查项：

1. 跨文档一致性：同一功能、模块、接口、数据模型在参考文档和待审文档中的描述是否完全一致？
2. 完整性：待审文档是否覆盖了参考文档中的每一个需求/设计要素？参考文档中是否有遗漏未被待审文档覆盖？
3. 冲突检测：是否存在矛盾（同一功能的不同规格描述、技术选型不一致、术语不一致）？
4. 可追溯性：参考文档中的每个需求/设计点能否追溯到待审文档中的对应章节？
5. 术语一致性：两文档中是否使用了统一的术语？同一个概念是否用了不同的名称？
6. 过时引用：待审文档是否引用了参考文档中已被删除或重命名的功能/章节？
7. 范围对齐：待审文档中是否包含了参考文档范围之外的内容？参考文档中是否有遗漏未被待审文档覆盖？

2.3 审查报告格式

## 第 N 轮审查 — 汇总
- 发现问题总数：X
- 新增问题：Y
- 上轮已修复并确认关闭的问题：Z

## 问题清单
### [ISSUE-001] 类别：[一致性|完整性|冲突|可追溯性|术语|过时引用|范围]
- **涉及章节**：参考文档 §X.X / 待审文档 §Y.Y
- **问题描述**：[具体什么不一致或有问题]
- **严重程度**：[严重|重要|轻微]
- **建议修复方案**：[应在何处做什么修改]

2.4 审查结果判定

• 如果发现 0 个新问题：宣布收敛，输出最终汇总，流程结束。
• 如果发现新问题：立即进入 Task B 修复。不要停止，不要只输出审查报告。

2.5 何时询问产品经理

通过 AskUserQuestion 询问用户的场景：

• 冲突涉及产品功能决定（哪个功能行为是正确的、优先级取舍、范围裁剪）。
• 需求存在歧义，不同解读会影响待审文档的内容。
• 发现两个同样有效但互不一致的规格描述，需要选择。

不要询问用户的事项：

• 技术实现细节、架构选择、代码层面的问题。
• 文档措辞、章节结构如何调整——直接处理即可。

3. Task B：应用修复

根据 Task A 的审查报告，更新待审文档。

3.1 修复规则

1. 直接用 Edit 工具修改待审文档文件。 不要只输出"建议修复方案"——你要自己动手改。
2. 按严重程度依次修复所有问题：严重 → 重要 → 轻微。
3. 修复时必须确保不破坏与参考文档的一致性。
4. 完成所有编辑后，进行一次快速自查：重新阅读被修改的章节，确认修复正确且未引入新的不一致。
5. 记录变更内容：

## 第 N 轮修复 — 汇总
### [ISSUE-001] — 已修复
- 变更内容：[简述做了什么修改]

### [ISSUE-002] — 部分修复
- 变更内容：[...]
- 遗留问题：[...]

### [ISSUE-003] — 跳过
- 原因：[需产品经理决策 / 范围不明确 / 其他]

5. Task B 完成后，立即进入下一轮 Task A。不要停止，不要询问用户是否继续。

4. 收敛与完成

当 Task A 在某一轮发现 0 个新问题时：

1. 输出最终汇总：总轮次、发现问题总数、已修复问题数。
2. 确认待审文档与参考文档已完全一致。
3. 结束。

5. 非收敛停止条件

以下情况停止并报告：

• 达到最大轮次仍未收敛。
• 同一个问题在 2 轮以上持续存在（说明存在更深层的问题，需要标记出来并请用户介入）。
• 某个问题需要产品经理决策但尚未得到解决。