LobeHub product-design 技能解析：SCLPT 证据链如何把"这个页面感觉不对"变成可交付的产品设计

本文围绕 LobeHub 仓库中的 Agent 技能文件 .agents/skills/product-design/SKILL.md 展开，讲解它如何指导 AI Agent 在动手画界面之前，先确立业务语义与用户任务，再通过一套 SCLPT 参考库（规范、三层模型、模式库、追踪日志、设计规格模板）把模糊的产品诉求落成有证据支撑的设计决策。读完后，你应当能理解这套"先 Ground 业务模型、再 Frame 视图模型"的方法论，以及 P-01 至 P-14 这些模式如何对应 LobeHub 产品中真实的 Agent 收件箱、交付验收等场景。

一、技能定位：先决定"做什么、为什么"，再谈间距

LobeHub 是一个"首席 Agent 运营者"——它把 AI Agent 组织起来做 7×24 的雇佣、调度和汇报。在这种产品里，界面承载的不是简单内容，而是大量机器产生、需要人来裁决的信号（Agent 等待审批、交付物待验收、运行失败等）。什么时候该建什么、为什么建，比间距和配色更值得先想清楚。

product-design 技能正是为此而设，它的一句话主张是：

Decide what to build and why before arguing about spacing. （先决定要构建什么、为什么，再去争论间距。）

技能文件中写了两条不可妥协的规则（SKILL.md 第 10–17 行）：

Never design from the surface. Establish what the business actually models first. （绝不从界面反推。先弄清业务到底建模了什么。）

Never turn the business model into the information architecture. The domain constrains what the surface may claim; the user's retrieval and decision task determines how the surface is organized. (P-14) （绝不把业务模型直接当信息架构。领域约束界面"能声称什么"，而用户的检索与决策任务决定界面"如何组织"。）

换句话说，业务模型划定界面可以说的真话的边界，用户任务决定这些真话怎么摆——两者都不能互相替代。

与兄弟技能的分工

技能文件明确了自己与相邻技能的边界，避免越界产出：

技能	回答的问题	使用时机
product-design（本技能）	这个界面应该是什么，为什么？	框定问题之前或之中
ux（位于 .agents/skills/ 下）	交互应该是什么行为和手感？	设计或开发过程中
ux-audit	已建成的界面是否遵守了这些规则？	界面已经存在之后
design-prototype	实体化交互如何被测试？	原型确实有用的时候

这条分工线配了一条自检测试：

Strip out every framework, table and component name: if no product insight remains, the finding belongs in an engineering skill. （把框架、表名、组件名全部剥掉，如果剩下的不是产品洞见，那它就属于工程技能。）

这条测试贯穿全技能——它同时是判断"该不该用这个技能"和"该不该把结论写进模式库"的过滤器。

SCLPT：五个文件组成的参考库

这个技能目录的组织方式是"主文件 + 参考库 + 模板"：

文件	角色	内容
SKILL.md	入口	两条铁律、运行模式、六步工作流、产出物与反模式
references/canon.md	外部基准（C）	该引用哪些经典著作，各自负责哪类判断
references/layer-model.md	三层模型（L）	Cooper 的三种模型、四类跨模型误判、发现打标法
references/pattern-base.md	模式库（P）	P-01 至 P-14，本产品的失败模式实例集
references/trace-schema.md	追踪日志（T）	reality-check log 的字段、读法与覆盖度记录
templates/design-spec.md	设计规格模板（S）	九节式 spec 骨架

从各文件自身的标注看，layer-model、pattern-base、trace-schema、canon 分别自称 "SCLPT" 中的 L、P、T 和基准文件，design-spec 模板则承担产出物规格的角色（这一对应关系由文件结构推断）。其中"规范"（canon）与"模式库"（pattern base）的分工尤其值得注意：

The canon gives the theory — why the failure happens, in any product. The Pattern Base gives the instances — what it looks like in this product, in our vocabulary, with the case that taught us. （Canon 给理论：这类失败在什么产品里为什么发生。Pattern Base 给实例：它在本产品里长什么样、用什么词汇、由哪个案例教会我们。）

每个新模式落库前必须回答一个问题："这是 canon 已命名事物的一个实例，还是真正的新东西？"答案几乎总是前者——这才是正确结果，因为这让模式库保持为"判断系统"而不是"事故日记"。

二、选择最小的运行模式

技能要求先选"最小充分"的运行模式，而不是每次都走全流程：

模式	终点
Discover	证据地图、业务模型、用户模型假设、结构性诊断
Frame	Discover 的产出 + 视图模型、信息架构、范围与未决问题
Materialize	Frame 的产出 + 被要求的 spec 和/或原型

配套两条纪律：

• 除非用户明确要求设计产出物、原型或仓库改动，否则不创建、不修改任何产物。
• 对于一次"实质性的"（substantial）运行，必须完整读 pattern-base.md 和 layer-model.md；对于窄问题，只查相关模式，并声明检查了哪些范围。

三、六步工作流

第 1 步 — 夯实业务模型（Ground the business model）

先确立"什么是真的"，再诊断界面。对大仓库，可并行收集相互独立的证据区域（在可以委派时），但主 Agent 负责调和矛盾。这一步要求产出六类东西：

• 概念、角色与状态，包括当前界面隐藏掉的变体（P-04）；
• 谁产生终态业务事实、什么让生命周期闭合（P-12）；
• 每个状态迫使谁去做什么（P-01）；
• 每个动作产生什么业务事件（P-02）；
• 业务没有的概念（P-06）；
• 证据来源、矛盾点与置信度。

技能对此强调了两条认识论约束：

1. 领域类型和状态机是强证据，但不是唯一真相。 要交叉核对服务行为、权限、策略、生产事实与用户证据——"Code can be stale, accidental or incomplete."（代码可能过时、偶然或残缺。）
2. 绝不从团队"以为的产品模型"出发。 团队的心智模型在被领域证据和用户证据验证之前，只是假设。

第 2 步 — 框定用户视图模型（Frame the view model）

夯实约束了产品"可以声称什么"，但不决定"人应该怎么看到它"。这一步要求把观察到的用户证据与设计假设分开陈述，并产出六个要素：

• Circumstance and job（情境与任务）："当我打开它时，我需要……"
• Lookup objects（检索对象）：用户会反复扫描、比较、查看的稳定对象；
• Attached proof（附着证据）：每个对象无需重新拼接关联即可自证的材料；
• First scan（首扫）：不点击就能回答的 2–4 个问题；
• Secondary dimensions（次级维度）：时间线、来源、运行记录、内部状态——除非任务是执行审计，否则保持为过滤器或钻取项；
• Evidence and confidence（证据与置信度）：每条论断标注 observed / reported / inferred，并说明关键假设如何验证。

三个模型在设计中的角色被固定为：

模型	在设计中的角色
Business/domain model（业务/领域模型）	定义真相、有效性、完整性与红线
User view model（用户视图模型）	定义分组、排序、标签与默认展开
Execution model（执行模型）	提供来源与审计细节；永远不白得整个页面

并给了一条硬性门槛：当拟定的顶层分区还只是 runs、reports、证据版本或表名这类领域/执行名词时，不许往下走——必须改写成用户想找的对象（P-14）。

第 3 步 — 诊断结构性错误

诊断必须"无论口味如何都站得住"，技能给了三个范例级别的错误：

• 一个"决策收件箱"只展示错误，于是被读成错误日志（P-04）；
• 一个按钮承诺了一个不存在的业务事件（P-05）；
• 一个页面同时当分诊台和阅览室，两边都做不好（P-07）。

反直觉但重要的纪律是：如果找不到有证据支撑的结构性错误，就如实报告"找不到"，而不是硬编一个诊断。

第 4 步 — 按依赖对齐决策

• 只浮出会改变答案形状的决策；每条给出建议、证据与后果；
• 先解决上游决策，再解决被它约束的下游决策；
• 阻塞性问题单独提，独立问题合并进一份备忘；
• 用户授权自主推进时，按推荐默认值继续，并显式标注假设；
• 永远不问那些现有证据已经能回答的问题；
• 对评审/审批/验收类界面，先弄清"系统还是人来闭合生命周期"（P-12）。

第 5 步 — 只在原型能消解不确定性时才做

只有两种情况才动用 design-prototype 技能：用户明确要求原型，或交互、密度、层级在书面框架里无法诚实地解决。规则包括：

• 使用合理的数据，并包含空态、受阻态和规模化态；
• 任何业务不支撑的内容，在原型图本身上打 NEW 标签；
• 把用户的纠正当作证据——只有当教训能泛化到当前界面之外时，它才成为 Pattern Base 候选。

值得一提的是，LobeHub 仓库里确实配套了这套原型工具链：design-prototype 技能生成单文件 HTML 交互原型，运行时直接从本仓库 node_modules 打包真实的 @lobehub/ui + antd + antd-style，保证原型使用的 token 和组件与生产一致（见 design-prototype/SKILL.md）。这解释了为什么"用真实设计系统做原型、把纠正当证据"在 LobeHub 的工作流里是可执行的，而不是口号。

第 6 步 — 诚实地划定范围

范围按"业务是否已经建模"分成三桶：

桶	含义
✅ 已建模、已暴露	只是重排现有能力
⚠️ 已建模、未暴露	领域风险较低，但工程成本仍需验证
❌ 尚未建模	需要领域扩展，并做显式的成本/风险评估

选择原则：当一个连贯的 ✅ + ⚠️ 切片能解决完整的用户任务时，优先选它。不要仅仅因为某个概念"已经存在"就发布一个不完整或有误导性的切片；反过来，当价值、安全或语义完整性所要求时，❌ 能力也可以是正确的一笔先头投资（P-10）。所有 ❌ 项必须按名字写进 spec 并附上可能的成本驱动因素（P-11）——不许悄悄丢掉，也不许假装成本能从领域模型直接推出。

收尾 — 记录覆盖度、提出学习

1. 产出 spec 时包含 trace-schema.md 定义的 reality-check log；只读工作时改为在回复中报告关键假设与证据，不落文件；
2. 把意外发现与 canon.md 对照，只有教训足够普及时才提议模式候选；
3. 只有获得仓库写权限且候选去重、可评审后，才把条目追加进 pattern-base.md；
4. 记录覆盖度信号：查过哪些来源和生命周期区域、哪些证据拿不到、哪些论断仍低置信、是否发现新缺口。

技能对"零缺口"给了一个冷静的注解：

Zero new gaps means only that none were found within the inspected scope. It does not prove that the implementation or mental model is exhausted. （零新缺口只说明在被检查的范围内没找到，不等于实现或心智模型已被穷尽。）

四、Layer Model 纵深：三种模型与四类"跨模型误判"

layer-model.md 是整套方法的理论地基，它直接采用 Cooper（《About Face》）的三种模型，原文自述"Cooper already wrote the right one, and it has held up for twenty-five years"：

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

Cooper 的目标被压缩成一句话，也是整个技能的"任务定义"：

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

模式库里的每一条，本质上都是"没守住这条线"的失败。文件进一步把"用 A 模型证据回答 B 模型问题"的四种典型误判逐一列出，这是 layer-model 真正的使用说明书：

1. 从表征模型推断实现模型——"界面没显示它，所以产品大概不做它。"最贵也最隐蔽，因为它感觉像观察而不是推断。真实案例：界面只显示 Agent 错误，于是全团队把它当错误日志来讨论；而产品实际每天产出四类 Agent-对人消息，其中三类从未被界面呈现过。
2. 用实现模型拼出表征模型——Cooper 所说的"核心病灶"：界面照抄机器的词汇（比如一个叫 paused 的状态，实际含义是"人在阻塞 Agent"）、机器的分组（按产生者而非按所需动作）和机器的形状。
3. 表征实现模型里不存在的东西——前者的镜像，以"戏剧"形式出货：在一个本来已被单方指派的工作上加"Accept task"按钮，暗示了一个产品并未建模的"待接受"状态。
4. 从另外两个模型推随心智模型——"没人意识到自己在做"的那一类。"产品建模了四种消息，所以用户也按四种想"——不成立；"界面一直是错误日志，所以用户预期如此"——也不成立。心智模型只能来自用户，"说没有发现"不等于"没有问题"。

发现要按模型打标

文件给出了打标表：每条发现先声明"它是关于哪个模型的事实"，标签决定这条发现能授权什么样的动作。摘录几行最能说明问题：

发现	模型	它能授权什么
"产品建模了四类 Agent 消息，界面显示一类"	implementation	一次范围机会——可能是一次重设计
"paused 意味着人要复核，而非'已挂起'"	implementation	一个队列，而不是"稍后"桶
"会话没有'属于某个人'的概念"	implementation	一条红线——这是领域变更，不是布局选择
"摘要长到没法扫、短到替代不了原文"	represented	一个密度决策
"没人会打开两次 dashboard"	mental	一个论断。要论证或观察，不许断言
"这个转圈动画用 SVG 画的"	—（无）	不是发现。无业务含义，丢弃

最后一行就是层模型自带的过滤器：能从代码库里学到的大部分东西不是产品发现，放任它们进入，模式库就会退化成 changelog。文件还要求按模型分别记录覆盖度：实现模型可能有界（可以饱和），表征模型靠验证稳定，心智模型永远是临时的——必须分开标注 observed / reported / inferred 并记录验证缺口。

五、Pattern Base：P-01 到 P-14 的本产品失败模式

pattern-base.md 是"模式库"，条目只收业务语义层面的教训：产品实际建模了什么、状态意味着什么、动作对业务做了什么。"复用现有 spinner 组件"这类实现语义明确被排除在外。库把 14 条模式分成五类（A–E），前四类都是"同一个病灶的不同症状"，E 类补充人机判断与机器证据的关系。

Class A — 业务含义与名字不符

• P-01 状态的业务含义不是它的标签。 任务状态 paused 被读成"用户暂停了"，实际含义是**"Agent 完成一步、正等待人批准"（pending review）**——它是页面上最紧急的事，而不是"稍后处理"桶。检测方法：对每个要上屏的状态问"这个状态迫使谁做什么？"若答案是"人必须行动"，它就是队列。
• P-02 动作的业务后果不是它的标签。 "Request changes" 看起来像"留个评论"，实际后果是结单并让 Agent 带着评论重跑——一次重新派工（re-tasking），不是反馈。检测方法：补全句子"点击之后，业务变成了……"；补不出，说明你并不知道自己要设计的那个按钮在干什么。
• P-03 名字和概念已经漂移。 侧边栏叫 Project 的区域渲染的是知识库——业务里根本没有"项目"这个概念；@ 提及菜单里叫 member 的分类解析出来是 Agent 而不是人。检测方法：绝不接受"名字"作为"概念"的证据，追问"它实际产生什么业务事件？"。

Class B — 表征模型与实现模型不一致

• P-04 不要把界面当产品的证据。 首页只显示 Agent 错误，团队就把它当错误日志去优化；而业务实际建模了四类 Agent-对人消息——decision（Agent 暂停等待裁决）、result（产出物待验收）、insight（值得知道、无需决策）、error（运行失败）——且每天全部在生产。界面不是需要打磨的错误日志，而是"四个通道关掉三个的决策收件箱"。检测方法：对界面涉及的每个概念，枚举产品里它的全部变体，再问"界面忽略了哪些，为什么？"答案常常是"没有为什么——没人顾上"。
• P-05 界面承诺了不存在的业务事件。 在"已被指派"的工作上放"Accept task"按钮：此业务里指派是即时且单方的，不存在"待接受"中间态。诚实的动作是能说出业务事件的那些——Start（变为进行中）或 Reassign（变为别人的）。检测方法：为每个按钮命名它产生的业务事件（不是数据变更）；命名不出，就是戏，删掉，或者明说"我在提议改业务模型"。
• P-06 业务没有这个概念，所以这不是设计决策。 想做"团队在讨论什么"的 feed，但业务对会话没有"我的 vs 团队的"概念——把它做出来是隐私事故，不是丑陋布局。更小一号的同类："未读"只是会话的全局属性，做按成员的未读徽标等于要求一个新业务概念。检测方法：想展示某个东西前，先问"业务有没有'谁拥有它/谁看过它/谁能对它行动'的概念？"没有，那你是在提议领域变更，必须大声说（P-11），因为它会让成本量级变化。

Class C — 注意力如何被组织

• P-07 首页是分诊台，不是 dashboard。 收件箱式界面只回答一个问题："这事是不是该我处理？"阅读、分析、浏览发生在点击之后。被否决的替代方案是团队 dashboard（用量趋势、排行榜、吞吐量图表）——它的结局可预测。测试：对页面上每个元素问"如果用户永远不点它，会不会有什么东西卡住？"不会，它就不属于这里。
• P-08 密度跟随决策成本。 条目在屏上的尺寸应匹配它需要多少思考，而不是生产者写了多少字：需要我决策的 → 展开（标题 + 一句话推理 + 动作）；只需知会的 → 一行（标题、来源、时间，点击看细节）；不需要我做的 → 折叠成计数。被否决的替代是"把所有卡片做紧凑一点"——原界面的真正失败是段落级摘要"短到替代不了原文、长到扫不进去"，修复方式不是缩短，而是按条目逐条决定形态。
• P-09 按所需动作分组，而不是按产生者分组。 Agent 说"我卡住了，你裁决一下"和同僚说"@你看这个"，对接收者来说是同一个信号。推论：按"真正在阻塞什么"排序，而不是按优先级字段——卡住的决策现在就在阻塞工作，失败的运行已经停下可以等等，所以失败即便优先级字段写着 urgent 也沉底——因为"urgent"是生产者写的，"blocking"是关于世界的事实。

Class D — 范围与诚实

• P-10 优先连贯的、领域风险更低的价值。 就是第二节的三桶模型。真实案例：一次宏大的团队协作愿景需要 mentions、annotations、presence 和一个"项目"概念——全部是 ❌；但核心的注意力收件箱全部是 ✅ + ⚠️（四类消息已在生产、运行中/未读工作已是业务概念），于是那一子集先上线了。昂贵的那一半，至今仍在正确地被争论。
• P-11 说清你不建什么、以及它的代价。 每个 ❌ 能力都要按名字写进 spec 并给出原因——沉默会被读成遗漏。真实案例：原型上显示了每次运行的耗时，但业务根本不建模"运行时长"这个概念。把它写下来之后，讨论从"你忘了放时间戳"变成了"我们知道，这是它的价格"。

Class E — 人的判断与机器产生的证据

• P-12 闭合生命周期的角色定义界面。 症状：一个名为"报告"的界面以系统裁决、摘要、计数、执行史开场，而真正产生终态业务结果的人的动作缺席或靠边。真实案例：交付验收有富验证运行和生成报告，于是第一版设计把它当"完成报告 + 附件"；但在业务里，只有用户点击 Accept delivery，验收才成为终态——验证器的 passed 是建议，用户的接受才是事件。诚实的界面是决策工作区：什么可以安全接受、什么变了、什么仍值得复核、支撑判断所需的证据，以及最后那个动作；完整报告是钻取，不是页面的组织原则。检测：对每个评审/审批/验收界面问"谁有权把它变成终态？那个动作产生什么事件？"
• P-13 执行历史是审计模型，不是默认评审模型。 症状：attempts、runs、证据版本占据首屏，因为它们是存储里最清楚的结构。真实案例：多次运行的验收最初被表示成 Check × Run 矩阵加"证据演化"画廊——都准确、都有用，但都要求用户重建真正的决策（什么修好了、什么仍危险、能不能验收）。首屏需要的是异常与决策相关变化：failed → fixed 的证明、缺失或过期的证据、未重跑直接沿用的项；稳定的检查项及其完整运行台账留作审计细节。
• P-14 领域约束真相，用户的检索对象组织视图。 症状：每个分区语义都正确，但用户仍要翻译领域语言、拼接多个模块才能找到他要的东西。真实案例：一个验收界面从"报告摘要"→"证据画廊"→"Check × Run 台账"→"异常优先的决策卡"逐步修正，业务语义越来越准，但用户要的其实更朴素——按熟悉类别分组的验收 Check 项全集，每项的最终证据直接挂在它下面（"Web 交互有没有截图？"应该扫一眼 Web 检查就能回答，而不是去解读系统判断、证据演化模块或运行矩阵）。检测方法：动手分区前先补全三句话——"我进来是为了找到所有____""每一项我需要不点就看见____""____我只用来过滤、解释来源或查历史"。第一句的空是重复项契约，第二句直接附着在每项上，第三句降级。

这 14 条模式的共同写法是 Symptom（症状）/ The real case（真实案例）/ Why it happens（成因）/ Detect（下次怎么发现），每条的"Detect"都是可直接执行的提问脚本——这正是它作为 Agent 技能的关键设计：模式不是供人欣赏的理论，而是供 Agent 在下次运行时逐条执行的检查清单。

六、Trace Schema：reality-check log——给"系统"看的第三份产物

trace-schema.md 定义了一次设计会话留下的三份产物中最容易被跳过的那份：

产物	读者	目的
Design spec	评审者	决定了什么，为什么
Prototype	评审者	手感如何
Reality-check log	技能本身	业务推翻了什么——喂给 Pattern Base

日志的 schema 是每行一个"撞上业务模型的假设"，五个字段：

字段	含义
Assumption	原以为什么，用当时的原话
What is true	推翻它的业务事实，必须用领域语言（"业务建模了四类消息"，而不是"枚举有四个值"）
Model	这是关于 Cooper 三种模型中哪一种的事实
Verdict	overturned | confirmed | refined
Pattern	若已有模式预测到它写 P-nn，没有则写 NEW

两条保持诚实的规则：

1. "What is true" 必须写成领域语言——如果你不提到表名就说不清这个事实，那它大概根本不是产品发现；
2. NEW 才是重点——每一行 NEW 都是模式库上的一个洞，由收尾步骤去补。

日志的"形状"本身就是对这次会话的诊断：

形状	含义
大量 overturned，全是 NEW	冷启动。模式库在这里是盲的——采收它
大量 overturned，全都引用 P-nn	检查相关模式是否被读过、被应用；可能是流程缺口
大多 confirmed，一两个 NEW	健康。系统在正常工作
零行	要么是无聊界面，要么——更可能——没人做任何夯实。保持怀疑
一个有记录的轮次里零 NEW	检查范围内没发现新缺口；转投别处前先核对覆盖度

此外还有两个配套机制：覆盖度记录（查过哪些来源和生命周期区域、哪些证据拿不到、哪些论断低置信——没有它，"零发现"是未决结论而不是饱和信号）；以及在原型图上标债：任何业务撑不起的展示元素，直接在 mock 上画 NEW 标签（例如 Total time on this: 11h 06m [NEW] ← 业务不建模运行时长），因为"这是防 P-05 类戏剧的最廉价防御：说不出某个元素背后的业务事件，就必须画标签。"

七、完整案例：一次 Agent Inbox 重设计如何催生整个模式库

worked-example.md 记录了"播种整个 Pattern Base 的那次会话"，是理解全套方法的最佳入口。

诉求（The ask）："看看我们的首页。没人往里面放任何设计思考。那里到底应该有什么？"——注意它不是 bug、不是 spec、不是需求清单，而是一种感觉。剩下的全部工作，就是把这种感觉变成可构建的东西。

第 1 步 Ground：界面只显示 Agent 错误，团队一直按错误日志的思路讨论（"怎么让错误列表更好看？"）。夯实领域后结论被翻转：业务建模了四类 Agent-对人消息（decision / result / insight / error，各自带优先级、可响应动作、关联交付物，且有完整的 seen → answered 生命周期），且四类每天都在生产，只有一类被显示出来。"一个关掉三个通道的决策收件箱"这一条发现，比整个重设计里其他所有东西加起来都值钱——而且盯截图永远得不到它。同一轮还得到：paused 实为"人正在阻塞 Agent"（P-01）、"Request changes"实为重新派工（P-02）。

第 2 步 Frame：初始视图模型被明确标为假设而非用户事实——"有人打开首页是为了找阻塞在自己注意力上的工作"，重复检索对象是"需要回应的信号 + 其来源与后果"。这一假设后来得到用户直接纠正（把"围绕 tasks 组织"改为"围绕 work、attention and goals 组织"）补上了 reported 证据。

第 3 步 Diagnose：三个结构性错误，都不关乎口味：决策收件箱被当错误日志（P-04）；分诊台和阅览室挤在一页、两边都做不好（每张卡片一段落级摘要，P-07/P-08）；信号按产生者分组而不是按所需动作分组（P-09）。

第 4 步 Align：逐条浮出改变答案形状的决策：主轴是 attention（该我需要什么）还是 progress（什么在动）？→ attention。Agent 信号与人信号一个收件箱还是两个？→ 一个（P-09）。用户在这里推翻了第一版框架——"围绕 work、attention 和 goals 组织，而不是围绕某一种实体类型"——这条纠正最终成了 P-09。

第 5 步 Prototype：在真实设计系统里过了六轮，每一轮都被业务推翻：

轮次	原型声称了什么	业务说了什么
v3	自造状态词汇	paused 本来就是 pending review（P-01）
v4	"Request changes" = 评论框	它是重新派工（P-02）
v5	"Accept task"按钮	指派是即时的，没有可接受的状态（P-05）
v6	每次运行的耗时	业务根本不建模运行时长（P-11）

技能由此提炼出原型的定义："The prototype's job is not to be right. It is to be wrong in ways the business can correct.（原型的任务不是正确，而是以业务能纠正的方式出错。）"只挪像素的轮次意味着夯实被跳过了。

第 6 步 Scope：

桶	能力
✅ 已建模、已暴露	错误通道、既有响应动作
⚠️ 已建模、从未暴露	另外三类消息、运行中工作、未读的已完成工作、消息所属任务
❌ 业务还没有的概念	人的提及、批注、presence、"项目"、运行时长

推荐并上线的是 ✅ + ⚠️——它们共同构成一个连贯的"个人收件箱"任务；❌ 列每一项都按名字、带成本写进了 spec（P-11）。这个以宏大团队协作愿景开场的设计，最终以聚焦的个人收件箱上线——"不是因为退缩，而是因为那部分才是业务已经相信的"（P-10）。

收尾：九条假设全部被推翻、全部 NEW——正是"冷启动签名"。而案例最后给出真正的判决：九行全是实现模型层面的发现，没有一行触及心智模型——"能在桌面上完成的那一半做得很好，需要用户的那一半完全没做。下一轮的预算应该花在那里。"

案例末尾的三条可泛化结论值得单独记住：最大的赢面往往是**"被关掉的既有能力"而不是新能力**（查它永远排在发明新东西之前，因为它是"最便宜的赢面，也是最容易被漏掉的"）；每一轮原型都应该被领域证伪，否则是在装饰而不是在设计；"业务已经相信什么？"是把愿景变成能上线的东西的那个问题。

与 LobeHub 产品脉络的对应

这个 worked example 不是抽象推演，它与 LobeHub 产品的真实演进可以对上：Agent 信号流（decision/result/insight/error 四通道）对应首页信号面板的形态，验收类界面（"Accept delivery" 决策工作区、Check × Run 审计模型）对应 Agent Tasks 的交付检查能力，这些功能在仓库的 changelog 文档中都有独立条目可查，例如 交付检查（delivery-checks）、Agent Tasks 与 Home Dashboard。技能文件里的"真实案例"、模式库里的"教训"与产品 changelog 之间的这种对应关系，正是该仓库"技能沉淀自真实设计会话"这一写作方式的直接证据。

八、产出物、反模式与适用边界

产出物清单

产物	何时产出	模板 / 位置
Design spec	Materialize 模式中被要求时	templates/design-spec.md；用用户指定路径或先询问
交互原型	被要求，或必须靠它消解不确定性	与 spec 同旁，经 design-prototype 技能
Reality-check log	在产出的 spec 内部	trace-schema.md
模式候选	出现普适且意外的教训时	写在 spec/回复里；评审与授权之后才允许追加

配套的 design-spec 模板 是一个九节骨架，其各节与本技能的方法一一对应：1 业务实际建模什么（含"业务没有哪些概念——缺失即发现，而且是最贵的那种"）、2 用户视图模型、3 诊断（"说不出结构性错误，你没有诊断，你只有观点"）、4 原则（每条原则必须附带被否决的替代方案——没有被否决替代方案的原则是装饰）、5 信息架构（逐块说明"为什么是它而不是别的"、空态与 100 倍规模下的样子）、6 三桶范围表与推荐切片、7 红线（业务没有的概念，只能作为领域变更被提议，且要加粗）、8 reality-check log 与覆盖度、9 只列改变答案形状的未决问题。

反模式清单

技能最后列出的反模式（SKILL.md）可作为使用时的反向检查表：

• 从截图设计，或把领域模型当站点地图；
• 按标签（而不是义务/事件）去读状态和动作；
• 从代码推断用户模型，然后当成观察到的事实呈现；
• 把"缺概念"当成"缺布局"；
• 问那些现有证据已经回答的问题；
• 把"概念存在"当成工程成本估算；
• 自动去建原型、写 spec 或改动 Pattern Base；
• 把局部纠正或工程发现塞进共享的产品指导文件。

适用前提与限制

需要说明几点适用边界：其一，这是一个 Agent 技能文件（带 name / description frontmatter），位于 .agents/skills/product-design/，与仓库中约四十个工程/流程类技能（如 trpc-router、zustand、ux、ux-audit 等）并列，服务对象是在本仓库上工作的编码 Agent，而非普通人类读者的教程；其二，文中 P-01～P-14 的所有"真实案例"来自 LobeHub 自身的 Agent 收件箱与交付验收等设计会话（见 worked-example.md 与 pattern-base.md），其结论绑定于"人机协作 Agent 运营"这一类产品语境，向其他类型产品迁移时需要重新夯实业务模型；其三，技能自身反复强调心智模型无法靠仓库证据夯实（"The mental model remains provisional"），因此任何仅基于本仓库文档复现的流程，其关于用户心智的结论都应视为待验证假设。

对想在自家仓库建立同类机制的团队，这份文件给出了一个可照抄的结构：一个克制的主 SKILL（两条铁律 + 最小运行模式 + 步骤纪律），加四个各司其职的参考文件（canon 定理论基准、layer-model 定证据规则、pattern-base 存本产品的实例化教训、trace-schema 管证据与自我进化），外加一个把"每条原则必须附带被否决的替代方案"写进骨架的 spec 模板——让技能在每次运行结束时都能判断自己是否在积累判断力，还是在积累日记。