# 05 Review

> 在概念开发完成后使用——评审、收集反馈、对照简报验证，并在交付前细化。

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

---


# 05-Review：评审与迭代

## 概述
在宣称一个设计"最终"之前，它必须经过评审。此技能管理结构化评审：对照简报、对照标准、与利益相关者一起。评审捕捉熟悉性隐藏的问题。目标不是让每个人都满意——是验证设计对用户、上下文和策略有效。

## 不可协商的规则
**硬性门槛：没有至少一次对照设计简报和成功标准的结构化评审，任何设计都不算最终。** "我看起来不错"不是评审。

## 何时使用
- 概念开发完成后，交付之前
- 设计需要对照简报进行结构化评审时

## 何时不使用
- 概念生成期间（先完成 04-generate）
- 交付最终文件时（使用 06-deliver）
- "你喜欢吗？"——这不是评审。评审需要标准。
- 纯错字修复或文件格式调整（直接做，然后进入 06）

## 流程

### 1. 自我评审（在分享之前）
- 对照设计简报审查：它解决了所述问题吗？
- 对照策略标准审查：它符合策略吗？
- 对照护栏审查：它违反任何约束吗？
- 在给别人看之前修复明显问题

### 2. 同伴或专家评审
与未沉浸在这个项目中的人分享：
- 他们首先注意到什么？
- 什么令人困惑或不清晰？
- 什么感觉不对劲？
- 理由在没有解释的情况下还站得住吗？

### 3. 利益相关者评审
- 用理由展示设计（如需，调用 **design-narrative**）
- 引导反馈：问"这符合标准吗？"而不是"你喜欢吗？"
- 记录：什么有效、什么需要改变、什么被拒绝
- 区分有效反馈和主观偏好

### 4. 用户验证（如适用）
- 与真实用户或代表性用户测试
- 观察行为，不仅是意见
- 他们理解了什么？他们错过了什么？
- 他们会改变什么？

### 5. 迭代和记录
- 列出评审带来的所有修改
- 对每个修改：是必须修复、锦上添花、还是主观偏好？
- 处理必须修复项；将锦上添花项目标记为后续
- 记录决策：什么改了以及什么故意没改

### 6. 冲突检查（检测到冲突时强制执行）

评审常常暴露出矛盾。在退出评审之前，扫描以下情况：

- 利益相关者反馈与用户验证结果矛盾
- 两位评审者对同一元素给出了相反的反馈
- 被请求的修改违反了 03-strategy 的策略标准
- 设计方向与可行性反馈冲突

**冲突解决块格式（与 03-strategy 相同）：**

```
冲突检测：
- 源A：[反馈 / 数据点 — 引用原文]
- 源B：[冲突元素 — 引用原文]
- 性质：[为什么它们矛盾]

解决决策：
→ [选择了哪个方向]

理由：
→ [设计优先级逻辑]

取舍：
→ [什么被牺牲或推迟了]
```

**规则：**
- 冲突反馈不能取平均。必须做出决定。
- 03-strategy 的策略标准在可用性问题上优先于主观偏好。
- 在可用性问题上，用户验证数据优先于利益相关者意见。
- 如果冲突无法在不改变策略的情况下解决，升级回到 03-strategy。
- 记录每一个冲突解决方案。这些决策是 07-learn 审计中的证据。

## 理性化预防

| 借口 | 事实 |
|------|------|
| "做好了，客户一定会喜欢的" | 每个这么说的人都错了。评审它。 |
| "明天就是截止日期" | 晚而正确比准时而错误好。 |
| "我已经知道他们会说什么" | 你不是用户。测试。 |
| "反馈是主观的，我可以忽略" | 反馈中的模式揭示真实问题。倾听模式。 |

## 危险信号
- 你将在没有给任何人看的情况下宣布工作"最终"
- 反馈只有"我喜欢"或"我不喜欢"（没有标准）
- 你忽略了所有反馈因为"他们不理解"
- 做了修改但没有记录原因

## 验证
- [ ] 已完成对照简报和标准的自我评审
- [ ] 至少一个外部评审者给出了反馈
- [ ] 利益相关者评审已进行，使用基于标准的提问
- [ ] 用户验证（或明确跳过决策）已记录
- [ ] 必须修复项已处理；锦上添花项已标记
- [ ] 修改和决策已记录理由

→ 下一步：使用 **06-deliver** 定稿资产、交付并生成规格。

## 设计决策日志（重要评审决策必填）

评审产生决策——改什么、保留什么、推迟什么。重要决策必须记录。

**何时记录：**
- 用有理据的决策推翻利益相关者反馈
- 在冲突反馈之间做出选择（链接到冲突解决块）
- 决定将修改推迟到未来迭代
- 任何修改或与原始策略方向矛盾的决策

**日志格式（与 03-strategy 相同）：**

```
决策：[评审中决定了什么]

选项：
A. [按请求修改]
B. [替代修改方案]
C. [保持原样 / 推迟 / 融合——描述]

选定：[选择]

拒绝：
A → [为什么——与策略、用户数据或可行性挂钩]
B → [为什么]

理由：
→ [为什么这个选择最有利于项目——与证据挂钩]
```

**规则：**
- "客户要求改所以我就改了"没有理由是空洞的决策。这次修改为什么服务项目？
- 被拒绝的反馈必须有理由。"他们不懂设计"不是理由。
- 日志条目是 07-learn 审计中的证据。审计将交叉检查：修改是否可追溯至标准，拒绝理由是否一致？
- 精简模式：至少记录一条主要评审决策。标准/深度模式：记录全部。