LobeHub 产品设计规范模板深析：product-design 技能的 design-spec 九节结构与 SCLPT 证据链

本文以 LobeHub 仓库中 product-design 技能的设计规范模板 design-spec.md 为主体，完整解读这份模板的九节结构与各节填写要求，并结合该技能的 SKILL.md、trace-schema.md、pattern-base.md 等配套参考文件，说明模板背后"先建立业务语义、再谈界面"的设计方法论。读完本文，你将掌握：如何把一个模糊的产品诉求（如"这个页面感觉不对劲"）转成一份有证据支撑、范围诚实、可交付的设计规范文档。

一、模板的定位：Materialize 模式的交付物骨架

这份模板并非孤立的文档格式，它是 product-design 技能在 Materialize（具象化）模式下产出的 Design spec 交付物骨架。技能定义的三种运行模式及完成线如下（见 SKILL.md）：

模式	完成线
Discover（发现）	证据地图、业务模型、用户模型假设与结构性诊断
Frame（定框）	Discover + 用户视图模型、信息架构、范围与开放决策
Materialize（具象化）	Frame + 用户要求的规范文档和/或原型

技能的交付物表明确了模板的使用时机与位置：

交付物	产出时机	模板/位置
Design spec	Materialize 模式被要求时	本模板；使用用户指定路径或先询问
交互原型	被要求或需消除不确定时	与 spec 相邻，经 design-prototype 技能
Reality-check log	随 spec 一起产出	见 trace-schema.md
Pattern 候选	出现普适性经验教训时	写入 spec/回复；仅在评审与授权后追加到 Pattern Base

模板与另外三个技能的分工也值得先厘清，它决定了 design-spec 的边界：product-design 回答"这个界面应该是什么、为什么"；ux 回答交互行为与手感；ux-audit 审计已建成的界面是否守住了规则；design-prototype 提供可测试的具象交互。两条不可谈判的规则是模板一切条款的源头：永远不要从界面出发设计，先弄清业务真正建模了什么；永远不要把业务模型直接变成信息架构——领域约束界面上"可以声称什么"，而用户的检索与决策任务决定界面"如何组织"。

二、文档头元数据块

模板的第一行是标题占位符 # <Surface> — <what this round changes>，即"界面名 — 本轮改变了什么"。随后是一个元数据块：

• Date：YYYY-MM-DD；
• Status：discovery | aligning | scoped | validated 四态之一，对应设计过程从发现到验证的推进阶段；
• Scope：一句话描述范围，并明确写出什么不在范围内（out of scope）；
• Prototype：如有原型，给出路径。

其中 Scope 一行强制写"排除项"的要求，与模板第 6 节"按名字列出所有排除项"、第 7 节"红线"形成呼应——这套模板从文档头开始就在要求作者诚实地画出边界。

三、逐节解读九节结构

1. What the business actually models（业务真正建模了什么）

模板要求回答的不是"界面显示了什么"，而是业务本身拥有什么。针对当前界面触及的概念，需要交代四件事：

1. 存在哪些概念、状态与角色；
2. 每个状态强制某人去做什么——没有人必须对其行动的状态不是队列，而阻塞了人类的状态才是；
3. 每个动作对业务做了什么——它产生的事件，用领域语言表达；
4. 业务没有哪些概念——"缺失"本身就是发现，而且是最昂贵的发现。

这一节直接对应 SKILL.md 的 Step 1（Ground the business model），要求产出：概念/角色/状态（包括当前界面隐藏掉的变体）、谁产生终态业务事实以及什么关闭生命周期、每个状态对人的义务、每个动作产生的业务事件、业务缺失的概念、证据来源/矛盾/置信度。技能还特别强调两点证据纪律：

• 领域类型与状态机是强证据而非唯一真相，要结合服务行为、权限、策略与生产事实核对，"代码可能是陈旧的、偶然的或不完整的"；
• 永远不要沿用团队对产品的假设模型，它在被领域与用户证据核对之前只是假设。

SKILL.md 给出了"剥离测试"：把每个框架、表名和组件名都划掉之后，如果还剩下产品洞察，该发现才配写入 spec；否则它属于工程技能文件。

2. User view model（用户视图模型）

模板要求给出六项内容：

• 情境与任务（"当我打开这个页面时，我需要……"）；
• 检索对象（lookup objects）以及附在每个对象上的证据（attached proof）；
• 首屏扫描（first-scan）要回答的问题与次级维度；
• 每条论断的证据等级：observed（观察到）| reported（用户陈述）| inferred（推断）；
• 置信度与验证缺口。

SKILL.md 的 Step 2 把视图模型的要素进一步细化为：检索对象是用户会稳定地扫描、比较、检查的东西；首屏扫描指"无需点击就能回答的 2–4 个问题"；时间线、来源、运行记录等次级维度除非任务本身是执行审计，否则只作为过滤器或下钻。它同时给出三模型在界面设计中的职责分工：

模型	在界面设计中的角色
业务/领域模型	定义真相、有效性、完整性与红线
用户视图模型	定义分组、排序、标签与默认展开
执行模型	提供来源与审计细节；绝不因此天然获得整页

模板还隐含了一条硬性约束：如果拟定的顶层区块只是 runs、reports、证据版本或表名这类领域/执行名词，说明还没到设计阶段——必须改写为用户真正在找的对象。canon.md 指出，心智模型是"再多的 grounding 也够不到的那一层"，JTBD（Jobs-to-be-Done）是处理它的最锋利工具，其杠杆是情境而非画像："某位经理"什么都解释不了，"某人在早上九点打开应用、想知道夜里有没有东西坏了"则足以解释整个信息架构。

3. Diagnosis（诊断：命名结构性错误）

模板要求命名结构性错误——"与审美无关的、无论如何都是错的"东西，而不是"看起来过时了"。它给了一句近乎苛刻的判定标准：

如果你命名不出一个结构性错误，你就没有诊断，你只有一个观点。

SKILL.md Step 3 给出的结构性错误示例形态包括：决策收件箱只暴露错误，于是被当成错误日志读（模式 P-04）；按钮承诺了一个不存在的业务事件（P-05）；一个页面同时是"分诊台"和"阅览室"，两头都做不好（P-07）。若证据不足以支撑任何结构性错误，应如实报告，而不是编造诊断。

4. Principles（原则：只保留被诊断逼出来的）

模板要求只写被本诊断实际逼出来的原则，且每条原则必须附带一个被拒绝的替代方案（rejected alternative）——"没有附带被拒绝替代方案的原则是装饰"。这与 pattern-base.md 的写作纪律一致：Class C 的每条判断规则都是"靠拒绝一个看似合理的替代方案换来的"。例如 P-07（主界面是分诊台而非仪表盘）的被拒绝替代方案是团队仪表盘——使用趋势、成员排行榜、吞吐图表，其命运是可预见的："管理者看两周，成员从来不看"。

5. Information architecture（信息架构：逐区块说明）

模板要求**逐区块（block by block）**地写信息架构，每个区块交代三点：

• 落在这里的是什么，为什么是它而不是别的东西；
• 它背后的业务概念；
• 它在空态、以及 100 倍数据量时的样子。

这一节是"用户视图模型定义分组、排序、标签与默认展开"的落点，其判断规则可对照 Pattern Base 的三条：

• P-07 主界面是分诊台：收件箱式界面只回答一个问题——"这是不是要我来处理的？"。检验方法：对页面上每个元素问"如果用户从不点击它，会不会有什么卡住？"答"不会"就不属于这个界面。
• P-08 密度跟随决策成本：条目在屏幕上的尺寸应与它需要的思考量匹配，而非生产者恰好写了多少字。"需要我决策"的条目展开为标题+一句话理由+动作；"只需知道"的条目一行；"什么都不需要我做"的折叠成计数。
• P-09 按所需动作分组，不按生产实体分组：Agent 说"我卡住了，你来定"和同事实况"@你 看一下"，对接收者是同一种信号，应归入一个按接收者要做什么分组的列表。推论是排序应按"什么真的在阻塞"而非优先级字段——一个卡住的决策正在阻塞工作，一个已停止的失败运行可以等待。

6. Scope（范围：业务已经支持什么）

这是模板中最有实操价值的一节。它把设计所需的每项能力按"业务是否已建模"分入三桶：

桶	能力	含义
✅ 已建模、已暴露		重新排列已有的东西
⚠️ 已建模、从未暴露		领域风险较低；需验证实现成本
❌ 业务中尚无此概念		领域扩张；需显式评估成本与风险

然后必须写两段结论：推荐的内聚切片（解释它如何完成用户的任务）与 "不做的事，以及为什么"——每一个被排除项都要点名，并给出可能的成本驱动因素。

对应到 Pattern Base 的两条模式：

• P-10 偏好内聚价值与更低的领域风险：优先选能完成完整用户任务的 ✅ + ⚠️ 切片；不要仅因概念已存在就交付不完整或误导性的切片。真实的案例是：一个团队协作为愿景的大设计需要 mentions、annotations、presence 和 project 概念——全是 ❌；而核心的"注意力收件箱"完全是 ✅ + ⚠️（四种消息类型本就在被生产，运行中/未读的工作本已是业务概念），于是这个子集先行上线，昂贵的另一半至今仍被正确地争论着。
• P-11 点名你不构建的东西及其代价：每个 ❌ 能力都要按名字写进 spec 并给出理由，永远不静默丢弃。因为沉默会被读成疏忽——评审者发现缺口会假设你漏了并重新打开讨论；而写明"未显示每次运行的耗时：业务根本不建模运行时长，这需要新概念"，就能把"你忘了时间戳"变成"我们知道，这是价格"。

worked-example.md 中给出了这一节的完整示范：

桶	能力
✅ 已建模且已暴露	错误通道；既有的响应动作
⚠️ 已建模、从未暴露	其余三种消息类型；运行中的工作；未读的已完成工作；消息所属任务
❌ 业务尚无此概念	对个人的提及（mentions）、批注、在线状态、project 概念、运行时长

7. Red lines（红线：业务没有的概念不能拿来设计）

模板要求列出"业务没有的概念，因此不能围绕它们做设计——只能作为领域变更来提议"，并要求加粗这些概念，且明确它们不是偏好（可引用 P-06 这类模式）。

这对应 Pattern Base 的 P-06：界面可以渲染任何东西，所以"概念的缺失"看起来像"控件的缺失"，其实不是。检测方法是：对你想展示的每个东西问"业务有没有'它属于谁/谁看过它/谁可以对其行动'的概念？"若没有，你不是在设计，而是在提议一个领域变更——这是被允许的，但必须大声说出来，因为它会把成本抬高一个数量级。真实案例：团队想做一个"团队正在讨论什么"的 feed，但业务只建模了任务与文档的按成员隐私，会话根本没有"我的 vs 团队的"之分——把会话展示给团队不是布局选择，而是会酿成隐私事故的业务概念缺失。

8. Reality-check log（现实核对日志：假设撞上业务模型的记录）

这是模板中最独特的机制，对应 SCLPT 证据链中的 T（Trace）。模板要求：每个撞上业务模型的假设占一行，Schema 见 trace-schema.md：

Assumption（假设）	What is true（什么是真的）	Model（模型）	Verdict（判定）	Pattern（模式）
按原话记录当时相信什么	推翻它的业务事实，用领域语言写	属于 Cooper 三模型中的哪一个	overturned / confirmed / refined	已有模式 P-nn 预测到则填编号，否则填 NEW

两条让日志保持诚实的规则：

1. "What is true"必须用领域语言而非实现语言。不是"枚举有四个值"，而是"业务建模了四种 agent-to-human 消息，而界面只渲染了一种"。如果一条事实不提到表名就说不出来，它多半根本不是产品发现；
2. NEW 才是重点：每一行 NEW 都是 Pattern Base 上的一个洞。

trace-schema 还给出了"读日志"的方法——日志的形状本身就是对这次设计会话的诊断：

日志形状	含义
大量 overturned，全是 NEW	冷启动：Pattern Base 在此失明——收割它
大量 overturned，全部引用 P-nn	检查相关模式是否被读取并应用了；这可能是流程缺口
以 confirmed 为主，一两个 NEW	健康，系统在正常工作
零行	要么是平凡的界面，要么更可能是——没有人做过任何 grounding。保持怀疑
有记录的轮次零 NEW	在检查过的范围内没有新缺口；转移精力前先查覆盖度

该文件还要求记录覆盖度（检查了哪些来源、角色、权限、状态与生命周期路径；哪些证据不可得；哪些论断仍低置信），并在原型上直接标注债务：任何业务撑不住的设计元素，都要在原型图本身上打可见的 NEW 标签——"如果你说不出一个元素背后的业务事件，你就必须画出这个标签"。

值得说明的是，SCLPT 五字母中，T（Trace，对应 trace-schema）、L（Layer，对应 layer-model.md）、P（Pattern，对应 pattern-base）在文件中有明确标注；从参考文件的组合方式看，其余两个位置对应范围（Scope）与基准（canon.md）。canon 文件为模式库提供了外部基准——Cooper 的《About Face》提供三模型层模型，《Shape Up》提供范围纪律（Appetite 对应 P-10、Circuit breaker 对应 P-11），JTBD 提供心智模型方法——每条新模式入库前必须先回答："这是 canon 已命名事物的一个实例，还是真正的新东西？"

9. Open decisions（开放决策：只留改变答案形状的）

模板要求只列会改变答案形状的决策，每项附推荐与理由，而不是把所有未解决事项都列出来。SKILL.md 的 Step 4 补充了操作细节：只暴露改变答案形状的决策，每项给出推荐、证据与后果；先解决上游决策再解决其约束的下游决策；当某个阻断性问题的答案会实质改变工作量时，单独提问，独立的决策则合并进一份备忘；用户授权自主推进时，按推荐默认值继续并标注该假设；永远不要问一个现有证据已经回答的问题。

worked example 中改变答案形状的两个决策很典型："主轴是注意力（需要我的）还是进度（在动的）？"——答案是注意力，因为进度只是上下文，注意力才是打开这个页面的理由；"Agent 信号与人的信号进一个收件箱还是两个？"——答案是同一个，依据 P-09。

四、贯穿九节的方法论：Cooper 三模型与跨模型误判

模板各节反复出现的判据，底层都是 layer-model.md 中的 Cooper 三模型：

模型	是什么	证据	谁有权威
Implementation model（实现模型）	产品实际如何工作：概念、状态、事件、义务	领域模型、状态机	系统，无可争辩
Represented model（表象模型）	界面声称产品是什么	界面、原型	设计——唯一由我们撰写的模型
Mental model（心智模型）	用户相信产品是什么	用户说与做的	用户；无法从另两个模型推断

设计工作的全部目标被压缩成一句：表象模型应尽可能接近心智模型，并在必要范围内尽可能远离实现模型。 Pattern Base 的每条模式都是守住这条线失败的案例：

• Class A（P-01~P-03）：表象模型继承了实现模型的词汇而非含义。如状态名 paused 被读作"用户暂停了它"，实际含义是"agent 完成了一步、等待人工审批"——这是页面上最紧急的状态，而非"稍后处理"桶；动作 "Request changes" 被读作"留个评论"，实际业务后果是解决该条目并以评论为新输入重跑 agent——是重派任务，不是反馈。
• Class B（P-04~P-06）：表象与实现模型对存在什么存在分歧。最贵的一类是 P-04"不要从界面反推产品"：主页只显示 agent 错误，团队就把它当错误日志来优化，而产品实际每天生产四种 agent-to-human 消息（decision 待裁决、result 待验收、insight 仅供知悉、error 运行失败），四种各带优先级、响应集、关联交付物与完整的 seen→answered 生命周期——三种从未被展示过。
• Class C（P-07~P-09）：表象模型应跟随心智模型而非实现模型（见第三节第 5 节）。
• Class D（P-10~P-11）：前三类确定之后的范围纪律。
• Class E（P-12~P-14）：人类判断与机器证据的关系。如 P-12"关闭生命周期的行动者定义界面"：交付验收只有在用户点击 Accept delivery 时才终结，验证器的 passed 只是建议，界面应组织成决策工作台而非报告；P-14"领域约束真相，用户的检索对象组织视图"——在提出区块前，用三句话填空："我来这里是为了找到每一个 ___""对每一项，我需要不点第二次就看到 ___""我只把 ___ 用作过滤/溯源/历史调查"。

层模型文件还定义了四种真实发生的跨模型误判及各自的防御：从界面反推实现模型（最贵、最隐形，防御是每次直接 grounding 实现模型）；用实现模型搭建表象模型（Cooper 的核心病症，防御是"对每个状态问它强制谁做什么，对每个动作问它产生什么"）；渲染实现模型没有的东西（防御是打 NEW 标签）；从另外两个模型推断心智模型（没人察觉自己在做，防御是把"用户相信什么"当作必须论证或观察的论断，而非断言）。

五、冷启动示例：模板机制的完整运转

worked-example.md 记录了种子会话的完整轨迹——"看一下我们的主页，没人往里面投入设计思考，它上面真正该有什么？"——这个诉求不是 bug、不是规格、不是需求列表，而是一种感觉，模板的九节正是把感觉转成可构建物的装置。其现实核对日志留下了九个假设、九行 overturned、全部 NEW 的记录，例如：

假设	什么是真的	判定	模式
界面上只有 agent 错误	业务建模四种消息，只展示了一种	overturned	NEW → P-04
paused 意味着用户暂停了它	意味着有人在阻塞 agent——待审批，是页面上最紧急的状态	overturned	NEW → P-01
"Request changes" 只是留评论	它重派 agent：解决条目并以评论为输入重跑	overturned	NEW → P-02
"Accept task" 是真实动作	指派即时且单边，不存在"待接受"状态——按钮意味着可以拒绝，而你不能	overturned	NEW → P-05
存在 project 概念	不存在。名为"Project"的区块是知识库	overturned	NEW → P-03

九行全 NEW 即"冷启动签名"；成熟的运行应大多为 confirmed、配一两个 NEW。该示例还留下了两条通用结论：最大的收益往往是一个被关掉的既有能力而非新能力（先查它，再发明任何东西）；每一轮原型都应被领域证伪——若一轮只移动像素，说明 grounding 被跳过了，那是在装饰而非设计。

六、使用路径小结

从仓库结构看，这份模板的使用闭环是：在 Discover/Frame 模式下按 SKILL.md 的六步（Ground 业务模型 → Frame 用户视图模型 → Diagnose 结构性错误 → Align 依赖排序的决策 → 必要时 Prototype → 诚实 Scope）推进；当用户明确要求规范文档时，以 design-spec.md 为骨架落盘九节内容；spec 内部嵌入按 trace-schema.md 填写的现实核对日志与覆盖度记录；对意外发现先对照 canon.md 与 pattern-base.md，仅在获得仓库编辑授权、且候选去重可评审后，才将普适性经验追加进模式库。这套机制把"设计规范"从一份静态格式，变成了一条从业务语义出发、以证据日志收尾、可持续自我修正的设计流水线。