07-learn

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

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 开始新项目。