z-Zihan 迭代 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
## 二次 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 个问题详细分析一下"、"说说这个问题的后果"），针对该问题进行深入分析：
触发关键词：展开、详细说一下、讲讲、分析一下、为什么、后果是什么、说说这个
展开内容应包括：
- 问题复现路径 — 在什么条件下、什么场景下会触发这个问题
- 根因分析 — 为什么会出现这个问题（代码层面/设计层面）
- 影响范围 — 会影响哪些功能、模块、用户群体
- 实际后果 — 如果不改，线上可能发生什么（给出具体场景，不是空泛描述）
- 修复思路 — 为什么建议这样修，有没有其他方案，各方案优劣对比
- 回归风险 — 修复后可能影响什么，需要验证哪些场景
格式：
## 深度分析：[问题编号] 简要描述
### 复现场景
具体操作路径和环境条件...
### 根因
代码层面为什么会这样...
### 影响
影响范围和实际后果（给出具体线上场景）...
### 为什么建议这样修
修复方案的分析和备选方案对比...
### 修复后需要验证
回归测试建议...
注意：
- 只展开用户要求的那个问题，不要顺带分析其他问题
- 如果用户没有要求展开，不要主动输出深度分析（保持报告简洁）
- 后果描述要具体、有场景感，不要写"可能产生不可预期的问题"这类空话
问题格式同主 Review 报告 §3（无影响变更/建议关注/需要修复），不再重复定义。