LobeHub Product Design Canon：三本经典基准，让 Pattern Base 保持为判断系统而不是日记

LobeHub 仓库的 .agents/skills/product-design/ 目录下沉淀了一套面向 Agent 的产品设计技能，其中的 canon.md 是这套技能的"正典"（Canon）基准文件：它规定了 Pattern Base（模式库）在新增任何一条模式前必须对照的三本经典著作，以及一套明确拒绝软件工程经验入侵的边界测试。读完本文，你能理解 LobeHub 如何用 Cooper 的三模型、Shape Up 的范围纪律与 Jobs-to-be-Done 的情景追问来约束产品设计的判断质量，并掌握其"先对照 canon、再提议入库"的模式沉淀流程。

一、为什么需要 Canon：判断系统与日记的分工

canon.md 的开篇点明问题：一个没有外部基准的 Pattern Base 会退化成一份_"恰好发生过在我们身上的事情"_的清单。因此，每一个新模式在被写下来之前，必须先回答一个问题：

这是 canon 已经命名的某个东西的实例，还是真正的新东西？ Almost always it is an instance.（几乎总是实例。）

文档指出，"是实例"才是正确且有用的结果——模式获得了锚点（anchor），Pattern Base 得以保持为一个判断系统（judgment system），而不是一部日记（diary）。

canon 与 Pattern Base 的分工如下表：

	它提供什么
Canon（本文件）	理论（Theory）。某类失败为何会发生，适用于任何产品
Pattern Base	实例（Instances）。它在本产品中长什么样，用我们的词汇，配以教会我们这一点的那个案例

二者谁也不能替代谁。原文的判断很直接：一个没有 canon 锚点的模式，通常不是发现——而是一个没有经过充分思考的模式（"A pattern with no canonical anchor is usually not a discovery — it is a pattern that has not been thought about hard enough"）。

从仓库源码看，这一纪律在 pattern-base.md 的头部得到了呼应：该文件要求"Propose before appending"（先提议、后入库）——只有当证据推翻了一个没有任何现有模式预测到的假设时，才记录一个候选（candidate）；只有当仓库编辑被授权、且教训具有普适性、已去重、可审查时，才允许追加。每条模式条目必须包含四段固定结构：Symptom（症状）/ The real case（真实案例）/ Why it happens（成因）/ How to detect it next time（下次如何检测）。此外，references 目录中的几个文件被合称为 "SCLPT" 助记：layer-model.md 自称是其中的 L（Layer Model），pattern-base.md 是 P（Pattern Base），trace-schema.md 是 T（Trace Schema），而 canon 正是这套体系的理论层（C）。

二、主文本：Cooper 的《About Face》与三模型

canon.md 明确宣告：主文本直接供给它自己的分层模型。三个模型（详见 layer-model.md）"是他的，未加修改"，因为二十五年过去后，它们仍然是"对哪里会出错的最锋利的可用框架"：

• Implementation model（实现模型）——产品实际上如何工作；
• Represented model（表征模型）——界面声称产品是什么；
• Mental model（心智模型）——用户相信产品是什么。

而目标——整个职业工作压缩成的一句话——是：

表征模型应当尽可能贴近心智模型，并且尽可能远离实现模型，远到"必要"为止。 （The represented model should be as close to the mental model as possible, and as far from the implementation model as necessary.）

canon.md 指出，Pattern Base 中 A 类和 B 类的每一个模式，都是没有守住这条线的失败。Cooper 的 "dancing bear"（跳舞的熊）——一个"难得居然能工作、但用起来极其痛苦"的软件——就是当界面围绕"系统产出了什么"而非"用户必须做什么"来组织时，表面（surface）的宿命（对应模式 P-09）。

阅读此书的目的（原文 "Read it for"）：目标导向设计（goal-directed design）；为什么用户的目标不等于用户的任务；为什么表征模型必须从"意义"中创作（authored from meaning），而永远不能从机制中派生（derived from mechanism）。

纵深：四种跨模型误判

layer-model.md 把三模型落成了四个"实际会发生"的跨模型误判——即用来自某一个模型的证据，去回答属于另一个模型的问题：

1. 从表征模型推断实现模型："界面上没显示，所以产品一定不做这件事。"这是最昂贵也最隐蔽的一种，因为它感觉像观察而不是推断。守卫：永远不要把界面当作关于产品的证据，每次都要直接落地实现模型（P-04）。
2. 用实现模型搭建表征模型：Cooper 的"中心疾病"。界面照抄机器，继承机器的词汇（paused，实际含义是人类正在阻塞一个 agent）、机器的分组方式（按产出实体而非按所需行动）和机器的形状。守卫：对每个状态问"它迫使谁去做什么"，对每个行动问"它产出什么"（P-01、P-02、P-09）。
3. 表征出实现模型中不存在的东西：#2 的镜像，以"剧场"（theatre）的形式发布——例如对一项已经单方面分配给你的工作放一个 "Accept task" 按钮，该按钮暗示了一个业务并未建模的选择。守卫：说不出背后业务事件的元素，就在原型本身上打上 NEW 标记——"是一笔可见的债务，而不是一场静默的谎言"（P-05、P-06）。
4. 从另外两个模型推断心智模型："没人意识到自己正在做的事"。心智模型是唯一无法被落地验证（cannot be grounded）的一层——既不在领域里，也不在屏幕上，它只来自用户。守卫：关于用户相信或想要什么的说法是主张，必须被论证或被观察，而不能从 schema 或截图中断言。

该文件还给出了一张贴标签的示例表，其中最后一行是整个体系的过滤器："这个 spinner 用 SVG 动画绘制" 属于——不是发现（Not a finding），没有业务含义，丢弃。原文总结："你能从一个代码库中学到的大部分东西都不是产品发现，而放它们进来，正是 Pattern Base 变成 changelog 的方式。"

三、范围纪律：Singer 的《Shape Up》

canon.md 直言：Class D（模式库中关于范围的一类）就是换了说法的 Shape Up。文档给出了一张逐词映射表：

Shape Up 概念	在此处的对应
Appetite（胃口/预算）	在方案之前、而不是之后决定预算（P-10）
Breadboarding（粗制模型）	在像素之前，于"可供性（affordances）与连接"的层面做设计
Rabbit hole（兔子洞）	产品尚未建模的能力——按此定价（P-10）
Circuit breaker（熔断器）	明确说出你不构建什么，然后停止（P-11）

阅读此书的目的：为什么*"在我们现有的胃口之内能构建什么"是一个比"正确的方案是什么"*更好的问题。

纵深：P-10 与 P-11 在模式库中的落地

在 pattern-base.md 中，P-10 与 P-11 构成了 Class D 的完整规则：

• P-10 — 优先选择领域风险更低的连贯价值：定范围之前，把设计需要的每项能力按"业务是否已建模"分桶——✅ 已建模且已暴露（只是重新排列现有能力）、⚠️ 已建模但从未暴露（领域风险更低，工程成本仍需验证）、❌ 业务中尚不存在的概念（需要领域扩展与显式成本/风险评估）。真实案例：一个宏大的团队协作愿景需要 mentions、annotations、presence 和一个 project 概念——全部是 ❌；而核心处的"注意力收件箱"完全是 ✅ + ⚠️（四种消息类型每天都在生产中产生）。那个子集最终发布了。
• P-11 — 命名你不构建的东西，以及它值多少代价：每个 ❌ 桶能力都要以名字写进 spec，并附理由。沉默会被读成疏忽；而写下"单次运行的耗时不显示：业务根本不建模 run 的耗时，这需要新概念"，会把你想要的对话从"你忘了时间戳"变成"我们知道，这是价格"。

SKILL.md 的 Step 6（Scope honestly）继承了同一张三桶表，并补充了一条纪律：当 ✅ + ⚠️ 切片能完成一个完整的用户工作时优先选它；但不要因为某个 ❌ 能力缺失就发布不完整或误导性的切片——当价值、安全或语义完整性需要它时，一个 ❌ 能力可以就是正确的第一笔投资。

四、心智模型：Jobs-to-be-Done

canon.md 把 JTBD 定位为心智模型这一层的工具，并坦率承认这是该技能最薄弱的一层：心智模型是没有任何量的落地验证能够触及的唯一一层。JTBD 提供的是最锋利的工具：用户雇佣这个表面去做什么工作，在什么情景（circumstance）之下？

它给出的杠杆是情景，而不是画像。原文的对比非常具体：

"一个经理"（A manager）什么都不解释。"早上 9 点打开应用、想弄清楚昨晚是否有什么东西坏掉的人"（Someone opening the app at 9am to find out whether anything broke overnight）解释了一整套信息架构——并且立刻杀掉了 dashboard（P-07）。

阅读此书的目的：如何对"用户想要什么"的主张进行审问（interrogate），而不是从 schema 中断言它。

纵深：心智模型不可落地验证，这被当作会话结论

worked-example.md 记录了播种整个 Pattern Base 的那次真实会话（agent 收件箱重设计）。它的结尾给出了全文最值得引用的一段结论：那次会话的 reality-check log 有九条被推翻的假设，全部 NEW——这是"冷启动签名"（cold-start signature），而且"九条全部是实现模型（implementation-model）发现，没有一条关于心智模型"。原文对此的裁决是：可以在书桌前完成的那一半做得很好，而需要用户的那一半根本还没做——下一轮的预算应该花在那里。这与 trace-schema.md 中的日志解读表一致："大量 overturned 且全是 NEW"意味着冷启动、应收割之；"大部分 confirmed、一两条 NEW"才是健康状态；"零行"则要么是很小的表面，要么更可能是谁都没有做任何落地验证——应持怀疑态度。

五、呈现层：Tidwell 的《Designing Interfaces》与 ux 技能的边界

canon.md 对 Tidwell 的处置是"已经划归别处"：密度、层级、界面模式这类问题属于 ux 技能（以及 ux-audit），并且保持在那里。canon 明确声明本技能不应重新推导（should not re-derive）它们，并留下了一条判据：

如果一个发现是关于某样东西看起来如何，而不是它意味着什么，那么它在错误的文件里。

这条边界在仓库中得到了结构性印证：ux/SKILL.md 自称是 "LobeHub product design values / principles / checklists"，明确区分了两份文档的职责——根目录的 DESIGN.md 负责设计系统（可换肤的 token、组件清单、文案语气），而 ux 技能负责交互行为（空态/加载/错误态、列表在规模下的表现、选择可见性、动作流与动量、渐进披露等），并遵循一条经验法则："静态外观与措辞 → DESIGN.md；动态行为 → 本技能"。其检查清单按交互类型分为 Read / Edit / Act / Feedback / Grow 五个模块，与 canon 所划定的"呈现层"问题域恰好重合——两个技能各管一边，互不重复。ux-audit 则承担对已建成表面的审计角色，形成 product-design（应该是什么）→ ux（如何表现）→ ux-audit（建成后是否守约）的接力。

六、明确排除在外：剥离测试（The Strip Test）

canon.md 最后一条纪律是关于什么不属于 canon：

软件工程模式不属于这个 canon，也不属于 Pattern Base。 组件复用、重构风险、框架惯例——都真实、都重要，但都是另一门学科。

它给出了一条可操作的判据，即"剥离测试"：

剥掉所有框架、所有表、所有组件名之后，还剩下什么产品洞察吗？ 如果没有，它就是一条穿着设计外衣的工程笔记，属于工程技能的文件。

这一测试在整个技能目录中被反复重申，形成了三处一致的守卫：

• SKILL.md 的 Anti-patterns 一列把"把局部修正或工程发现添加进共享的产品指南"列为反模式；
• layer-model.md 的推论过滤器：一个不携带任何业务含义的事实（哪个组件画 spinner、模块如何接线）根本不是关于实现模型的事实——它是关于代码的事实，而代码是另一回事，不进入这个体系；
• pattern-base.md 的"What belongs here"一节："复用现有的 spinner 组件""这个重构会破坏已挂载的 modal""优先用这个 hook 而不是那个"——都对、都重要，但都是别人的文件；一条模式只有当它改变产品应该是什么、而不是如何构建时，才配在这里占一个位置。

七、实战流程：canon 如何嵌入一次产品设计的收尾

理解了 canon 的四个基准之后，它在 LobeHub 工作流中的实际位置由 SKILL.md 的 "Close" 步骤和 templates/design-spec.md 模板锁定：

1. 对照 canon，只在教训普适时提议：SKILL.md 的收尾第 2 步要求"将意外发现与 canon.md 对照，只有当教训具有普适性时才提议一个 Pattern Base 候选"。design-spec 模板第 8 节（Reality-check log）末尾明确要求："Pattern candidates: 列出候选，或写 'none'；每一个都要对照 canon.md 检查；仅在评审和授权之后追加。"
2. reality-check log 是候选的进料口：trace-schema.md 规定每条假设落地验证记一行（Assumption / What is true / Model / Verdict / Pattern），其中 Pattern 字段填既有模式号 P-nn 或 NEW。规则写道："NEW 就是全部重点——每一条 NEW 行都是 Pattern Base 上的一个洞"。该文件还给出了那次冷启动会话的九行完整样例（paused 的误读、"Request changes" 的误读、"Accept task" 的剧场、不存在的 project 概念、会话没有"归属某成员"概念等），并强调 "What is true" 必须用领域语言而非实现语言书写——不是"枚举有四个值"，而是"业务建模了四种 agent 到人的消息，而表面只渲染了一种"。
3. 在原型本身上标记债务：任何设计展示了而业务撑不起来的元素，都要在 mock 图上（而不只是 spec 里）打上可见的 NEW 标签。trace-schema 给出了具体示例：Total time on this: 11h 06m [NEW] ← 业务不建模 run 的耗时。原文说这是对抗 P-05 类"剧场"最便宜的防御：如果你说不出一个元素背后的业务事件，你就必须画出那个标签。
4. 记录覆盖信号：收尾时记录检查过的来源与生命周期区域、不可用的证据、剩余的低置信主张，以及是否发现了新缺口。SKILL.md 对此有一句防止过度解读的告诫：零个新缺口只意味着在已检查的范围内没有发现——它不证明实现或心智模型已被穷尽。

worked-example 的完整轨迹可以作为这套流程的压力测试：那次会话在 Step 1（Grounding）发现了"表面只展示了四种 agent 消息中的一种——它是一个被关掉三个通道的决策收件箱"（P-04）；Step 5 的原型六轮中每一轮都被业务推翻（v3 自创状态词汇 → P-01；v4 把 "Request changes" 画成评论框 → P-02；v5 的 "Accept task" 按钮 → P-05；v6 的运行时耗时 → P-11）。原文的总结是：原型的工作不是正确，而是以业务能够纠正的方式出错——如果一轮迭代只移动像素，说明落地验证被跳过了。

八、小结：一张判断系统的装配图

把 canon.md 放回 LobeHub 技能目录的全景中，可以看到一条清晰的装配逻辑：

• Canon（理论层）：Cooper 三模型解释"失败为何在任何产品中都发生"，Shape Up 解释"范围如何诚实地划定"，JTBD 解释"心智模型层如何被审问"，Tidwell 则被明确外包给 ux 技能；
• Pattern Base（实例层）：P-01 到 P-14 十五个模式分为 A（词不达义）、B（表征与实现相左）、C（注意力如何组织）、D（范围与诚实）、E（人类判断与机器产出的证据）五类，每一条都锚定到 canon 上的一个理论位置；
• Trace Schema（证据层）：reality-check log 用 P-nn / NEW 字段衡量判断系统的命中率，NEW 行回流为候选，经 canon 对照、评审与授权后才入库；
• 边界层：剥离测试把工程笔记挡在门外，"looks vs means" 判据把呈现层问题挡给 ux。

这套机制的核心主张只有一句话：模式库的价值不在于记录了多少发生过的事，而在于每一个新事实都被迫先回答"canon 是否早已命名过它"——是，则模式获得锚点；否，则必须经过普适性审查才配进入体系。对于维护任何 Agent 技能库或团队知识沉淀的开发者而言，canon.md 提供的是一个可以直接复用的"判断系统 vs 日记"的防腐方案。