# Iterative

> 迭代 Review（修复后的二次/多次 Review）/ Iterative Review (2nd+ Round After Fixes)

- Skill: `z-zihan/iterative` (Agent Skill)
- Install (CLI): `npx skillmds@latest add z-zihan/iterative`
- Raw SKILL.md: https://api.skillmd.com/api/skills/z-zihan/iterative/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: z-Zihan (https://skillmd.com/u/z-zihan)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/z-zihan/iterative

---

## 迭代 Review（修复后的二次/多次 Review）/ Iterative Review (2nd+ Round After Fixes)

当用户提交修复后的代码再次 review 时（如"改好了，再看一下"、"修了一版，review 一下"），应采用**精简模式**。

### 核心原则 / Core Principle

- **始终 review 用户最新提交的代码**，不是和旧版本对比。即使是二次 review，也要重新审查相关文件的当前状态，确保修复方案没有引入新问题
- **未修复/部分修复/改错的问题，必须重新给出具体的修复建议**，不能只标记状态就结束
- **二次 review 的核心问题是：修复是否真正解决了根因，还是只是 suppress 了表象**

### 精简报告规则 / Streamlined Report Rules

- **已确认符合预期的问题**：完全不提
- **已修复的问题**：逐项确认，用 ✅ 标记修复状态，不用展开分析
- **❌ 未修复的问题**：必须重新分析当前代码，给出**具体的修复建议**（和首次 review 的"需要修复的问题"格式一致）
- **⚠️ 部分修复的问题**：必须说明**还差什么**，并对剩余部分给出修复建议
- **修复改错的问题**：标记为 ❌ 修复改错，分析为什么改错了，给出**正确的修复方向**
- **修复过程中引入的新问题**：正常输出，需要详细说明
- **完成度更新**：如果上次有未完成的功能点，检查是否已补全
- **Suppress 检测**：如果修复方式是删除检查/忽略错误/try-catch 吞掉异常，标记为 🚫 "疑似 suppress"，要求用户确认这不是在掩盖问题
- **关联遗漏检查**：修复某处时，检查是否有相同模式的其他地方也需要同步修复（如修了 A 文件的 bug，B 文件是否有同样问题）

### 精简报告模板 / Streamlined Report Template

```markdown
## 二次 Review

**结论**: 可直接合入 / 仍有问题需修复

### 修复确认

| # | 原问题 | 状态 |
|---|--------|------|
| 1 | 简要描述 | ✅ 已修复 |
| 2 | 简要描述 | ❌ 未修复 |
| 3 | 简要描述 | ⚠️ 部分修复（还差 XXX） |

> 全部 ✅ 且无新问题 → 结论为"可直接合入"，结束 review。

### 未修复 / 修复有误的问题

| # | 原问题 | 当前状态 | 修复建议 |
|---|--------|----------|----------|
| 2 | 原问题描述 | 代码未变更 / 修复方向错误（原因说明） | 具体修复方向 |
| 3 | 原问题描述 | 只修复了 A 部分，B 部分仍存在 | 剩余部分修复方向 |

> 全部已修复则写"无"。

### 新增问题

| # | 严重度 | 位置 | 问题描述 | 修复建议 |
|---|--------|------|----------|----------|
| 1 | Major | 文件:函数 | 新引入的问题 | 修复方向 |

> 没有则写"无新增问题"。

### Suppress 检测与关联遗漏

| # | 修复方式 | 检测结果 |
|---|----------|----------|
| 1 | [修复描述] | ✅ 正常修复 / 🚫 疑似 suppress（原因） |
| 2 | [修复描述] | ⚠️ 关联遗漏（B 文件存在同样模式，建议同步修复） |

> 没有则写"无"。

### 最终结论

一句话 + 是否可合入。
```

### 多轮迭代 / Multi-Round Iteration

- 如果用户再次提交修复，继续使用精简模式
- **每轮都必须审查最新代码**，不能凭记忆判断修复状态
- 每轮只关注：上一轮遗留 + 本轮新增变更
- 累计多轮仍有未修复问题，持续给出具体的修复方向，不要建议"接受现状"或"重构"
- **只要还有需要修复的问题（未修复 / 部分修复 / 修复改错 / 新引入），就必须生成可复制的修复指令**
- 可以省略的部分仅限：①已确认符合预期的问题 ②已完整修复的问题 ③用户明确说不用改的
- **结论为"可直接合入"时，才省略修复指令**

---

### 问题展开分析 / Issue Deep Dive

当用户要求对某个具体问题详细解释时（如"展开讲一下第 2 个"、"第 4 个问题详细分析一下"、"说说这个问题的后果"），针对该问题进行深入分析：

**触发关键词**：展开、详细说一下、讲讲、分析一下、为什么、后果是什么、说说这个

**展开内容应包括：**

1. **问题复现路径** — 在什么条件下、什么场景下会触发这个问题
2. **根因分析** — 为什么会出现这个问题（代码层面/设计层面）
3. **影响范围** — 会影响哪些功能、模块、用户群体
4. **实际后果** — 如果不改，线上可能发生什么（给出具体场景，不是空泛描述）
5. **修复思路** — 为什么建议这样修，有没有其他方案，各方案优劣对比
6. **回归风险** — 修复后可能影响什么，需要验证哪些场景

**格式：**

```markdown
## 深度分析：[问题编号] 简要描述

### 复现场景
具体操作路径和环境条件...

### 根因
代码层面为什么会这样...

### 影响
影响范围和实际后果（给出具体线上场景）...

### 为什么建议这样修
修复方案的分析和备选方案对比...

### 修复后需要验证
回归测试建议...
```

**注意：**
- 只展开用户要求的那个问题，不要顺带分析其他问题
- 如果用户没有要求展开，不要主动输出深度分析（保持报告简洁）
- 后果描述要具体、有场景感，不要写"可能产生不可预期的问题"这类空话

---


> 问题格式同主 Review 报告 §3（无影响变更/建议关注/需要修复），不再重复定义。