# 07 Learn

> 在交付后使用——对照简报验证工作、审计质量和一致性、记录洞察并关闭项目。

- Skill: `ahaoai/07-learn-2` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ahaoai/07-learn-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahaoai/07-learn-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/07-learn-2

---


# 07-Learn：验证与归档

## 概述
线性工作流的最后一步。在把项目称为完成之前，验证交付的工作是否符合设计简报、质量标准和成功标准。然后归档学到的东西，以便未来项目受益。这结合了验证（原design-verify）和项目关闭与复盘（原finishing-a-design-project）。

## 不可协商的规则
**硬性门槛：在宣布项目完成之前，必须对照原始设计简报进行验证并完成逐阶段执行审计。** "看起来不错"不是验证。每个标准都必须检查。每个阶段的硬性门槛必须通过交叉审查。

## 何时使用
- 交付完成后（06-deliver 已完成）
- 在任何项目被宣布"完成"之前

## 何时不使用
- 项目进行中（验证发生在最后，不是中间）
- 项目被放弃时（仍然验证已交付的内容）
- "这是小项目，跳过吧"——小项目最需要验证，它们隐藏最大的假设

## 流程

### 1. 对照简报验证
- 审查导入和设计简报中的每个成功标准
- 检查：交付的工作是否解决了所述问题？
- 检查：它是否尊重所有记录的约束？
- 检查：它是否满足所有不可协商的要求？
- 评分：满足、部分满足或不满足——每个标准逐一检查

### 2. 逐阶段执行审计

这不是清单。这是交叉审查——对于每个 A-layer 阶段，将当时的验证声明与实际交付物内容进行对比。目标是发现勾选框被打勾但内容空洞：标记显示完成，但工作不满足该阶段的硬性门槛。

#### 如何审计

对每个已执行的阶段，填写一行（6列必填——证据列不可省略）：

| 阶段 | 硬性门槛 | 验证声明 | 实际交付物包含的内容 | 判定 | 证据（步骤ID + 章节 + 片段） |
|------|---------|---------|-------------------|------|---------------------------|
| 01-intake | 在进入设计阶段前完成导入 | 例：✓ 简报已记录，利益相关者已识别，≥3条约束 | 例：简报只有一句话，无利益相关者角色名称，约束只有"预算"无具体数字 | ✓ / ⚠ / ✗ | 01-intake / section 1："…" |
| 02-discover | 调研综合+书面简报，然后才能生成概念 | 例：✓ ≥3个痛点，≥2个竞争者映射，简报已撰写 | 例：痛点泛泛，竞争者部分只有公司名无分析，简报缺少范围之外 | ✓ / ⚠ / ✗ | 02-discover / section 5："…" |
| 03-strategy | 策略定义并获批，然后才能生成概念 | 例：✓ ≥3条评估标准，护栏已记录，策略已获批 | 例：标准是"看起来高档、感觉现代"——模糊形容词，无批准记录 | ✓ / ⚠ / ✗ | 03-strategy / section 2："…" |
| 04-generate | ≥3个不同方向，然后才能收敛 | 例：✓ 3个方向已生成，概念矩阵已完成，≥1个原型已测试 | 例：方向用不同配色但核心相同，矩阵有空单元格，无原型证据 | ✓ / ⚠ / ✗ | 04-generate / section 1："…" |
| 05-review | 至少一次对照简报和标准的评审 | 例：✓ 自我评审已完成，外部评审者反馈已获得，利益相关者评审已完成 | 例：反馈只有"看起来不错"，无基于标准的评估，无修改记录 | ✓ / ⚠ / ✗ | 05-review / section 3："…" |
| 06-deliver | 交付清单完成，然后任何文件离开 | 例：✓ 资产已导出，规格已编写，交付已记录，回执已确认 | 例：文件已导出但无书面规格，无命名规范，无回执确认 | ✓ / ⚠ / ✗ | 06-deliver / section 2："…" |

#### 判定定义

| 标记 | 含义 | 行动 |
|------|------|------|
| ✓ | 验证声明与交付物质匹配。硬性门槛满足。 | 继续。 |
| ⚠ | 验证声明已打勾，但交付物内容空洞——答案存在但缺乏该阶段要求的信息量。 | 回到该阶段，在项目完成前补上空缺。 |
| ✗ | 验证声明已打勾，但硬性门槛明显未满足。该阶段从未被真正执行。 | 项目被阻塞。回到该阶段并正确执行。 |

#### 审计规则

- **范围**：只审计项目实际使用的阶段（精简模式跳过阶段，不审计跳过的阶段）。
- **重点**：只审计与硬性门槛直接相关的验证项——不是每个勾选框。
- **精简模式允许**：在精简模式下，如果用户明确以深度换速度，⚠ 可能可接受。记录这一取舍。
- **对 ✗ 零容忍**：硬性门槛声称满足但明显未满足，意味着审计失败。项目不算完成。
- **记录审计**：填好的表格是项目记录的一部分。不要跳过写下来。

#### 证据绑定（强制要求）

每个审计判定必须由明确的证据支撑。仅总结性验证不可接受。没有可追溯的证据不得宣布完成。

每个审计行必须引用：

| 必要证据 | 含义 | 示例 |
|---------|------|------|
| **步骤ID** | 正在审计哪个阶段 | 03-strategy |
| **技能章节** | 证据位于该技能产出的哪个章节 | 03-strategy / section 2：设计标准 |
| **产出片段** | 来自实际交付物的具体片段——不是转述，不是总结 | "目标受众：25-35岁城市职场人士，偏好简洁界面，信任高端定价" |

**规则：**
- 无证据引用 → 判定无效。带着证据重新审计。
- 转述"它大致说了关于受众的内容"不算片段。引用原文，或等于没发生。
- 如果产出根本不存在 → 判定自动为 ⚠（空洞）或 ✗（缺失），取决于是否尝试了某种形式的回答。
- 证据比对："验证声明"列 vs. "产出片段"列——它们匹配吗？如果声明称"≥3条评估标准已定义"但片段显示"看起来高档、感觉现代"（2个模糊形容词），判定为 ⚠。

**证据在审计表中的样子：**

| 阶段 | 硬性门槛 | 验证声明 | 实际交付物包含的内容 | 判定 | 证据 |
|------|---------|---------|-------------------|------|------|
| 03-strategy | 策略定义并获批后才能生成概念 | ✓ ≥3条评估标准已记录 | "1. 看起来高档 2. 感觉现代"——2条模糊要点，未引用来源 | ⚠ | 03-strategy / section 2：未撰写第三条标准，项目产出中无批准记录 |

证据列将软弱的判断替换为可追溯的事实。没有证据的 ⚠ 或 ✗ 本身就是一个空洞的判定。

#### 审计结论

填写表格后：

- **全部 ✓** → 审计通过。进入质量审计。
- **一个或多个 ⚠** → 修复缺口，重新审计受影响的阶段，然后继续。
- **一个或多个 ✗** → 审计失败。回到失败阶段。在全部 ✗ 解决之前项目不算完成。

**冲突解决审计（附加检查）：**

在结束前，验证项目中（在 03-strategy 和 05-review 中）检测到的每个冲突都以书面的冲突解决块得到了解决。未解决或未记录的冲突 = 审计失败。

- [ ] 03-strategy 中出现的每个冲突都有包含决策+理由+取舍的解决块
- [ ] 05-review 中出现的每个冲突都有包含决策+理由+取舍的解决块
- [ ] 没有冲突被悄悄合并或忽略——检查 05-review 的"迭代和记录"章节
- [ ] 决策日志条目与冲突解决一致（没有冲突块说"选了A"但决策日志说"选了B"）

### 3. 质量审计
- 视觉一致性：色彩、字体、间距、对齐
- 技术准确性：正确的格式、分辨率、色彩配置
- 无障碍性：对比度、可读性、包容性语言
- 品牌项目：检查品牌指南合规性
- 数字项目：检查响应式行为、状态、交互

### 4. 伦理与责任检查
- 代表性：设计是否尊重地呈现了受众？
- 暗黑模式：没有操纵性或欺骗性模式
- 文化敏感性：没有挪用或刻板印象
- 环境：考虑材料、数据或生产的可持续性

### 5. 项目复盘
- 什么做得好？（记录以备复用）
- 什么可以做得更好？（记录以改进）
- 下次你会有什么不同的做法？
- 创建了哪些可复用资产？（模板、提示词、模式、组件）

### 6. 归档和关闭
- 归档：调研、简报、策略、概念、原型、最终文件、规格
- 文档化：经验教训、可复用资产、设计决策日志
- 关闭：通知利益相关者、庆祝完成
- 如适用，更新你的作品集或案例研究

## 理性化预防

| 借口 | 事实 |
|------|------|
| "客户批准了，所以没问题" | 客户批准不是验证。对照简报检查。 |
| "我太累了，明天再检查" | 明天你会在另一个项目上。现在就检查。 |
| "不需要审计，这是个小型项目" | 小型项目隐藏最大的假设。验证。 |
| "我会记得学到了什么" | 你不会的。写下来。 |
| "我跑了审计，一切看起来都没问题——不用写下来了" | 记忆不是审计轨迹。写下填好的审计表。写的过程揭示空洞的勾选框。 |
| "早期阶段都标记了 ✓，所以审计只是确认我已经知道的" | 自我报告的 ✓ 正是审计存在要挑战的东西。如果你信任自己的标记，你就完全搞错了审计的意义。 |

## 危险信号
- 你跳过了验证因为"它已经完成了"
- 最终审查中没有参考简报
- 经验教训没有记录
- 可复用资产躺在一个没人会找到的项目文件夹里
- 你在没有关闭当前项目的情况下进入下一个项目
- 执行审计表是空的或没被填写
- 你填了审计表但每行都是 ✓——统计上不太可能。重新检查。
- 你发现了 ⚠ 或 ✗ 但将其合理化为"足够接近"
- 你接受了自己的验证标记而没有与实际交付物交叉核对

## 验证
- [ ] 每个成功标准已检查：满足/部分满足/不满足
- [ ] 逐阶段执行审计表已为每个执行过的阶段填写
- [ ] 所有 ✗ 判定已解决（阶段重新执行并重新审计）
- [ ] 所有 ⚠ 判定已解决或明确记录为可接受的取舍
- [ ] 质量审计已完成（视觉、技术、无障碍）
- [ ] 伦理与责任检查已完成
- [ ] 复盘已撰写（什么做得好、什么待改进）
- [ ] 可复用资产已提取并记录
- [ ] 项目材料已归档
- [ ] 项目已正式关闭，已通知利益相关者

→ 项目完成。通过调用 **using-designagent** 开始新项目。