LobeHub 产品设计实战复盘：如何把一个模糊抱怨变成"决策收件箱"

本文以 LobeHub 仓库内 product-design 技能附带的完整案例档案 worked-example.md 为主线，逐段复盘一次真实的产品设计会话：从一句"我们的首页毫无设计感"的模糊抱怨出发，经过 Ground（落地事实）→ Frame（用户视图模型）→ Diagnose（结构诊断）→ Align（对齐决策）→ Prototype（原型证伪）→ Scope（诚实定界）六个步骤，最终把一个原本可能被当作"错误日志美化"的页面，重新定性为一个"四个通道关掉三个的决策收件箱"。读完后你能掌握这套以业务语义为锚点的设计方法：如何从领域模型中读出界面没有暴露的能力，如何用现实核查日志（reality-check log）量化一次设计会话的质量，以及如何用 ✅/⚠️/❌ 三桶法划定一个"业务已经相信"的可交付切片。

案例背景：一次为 Pattern Base 播种的会话

这个案例并非虚构的演示，而是 LobeHub 设计体系里被明确标注为"播种了 Pattern Base 的那次会话"——案例中的每一个错误都是真实发生的：

One complete trace. This is the session that seeded the Pattern Base, so every mistake in it is real. —— worked-example.md

要理解这个案例的分量，先要理解它所在的技能体系。SKILL.md 定义了 product-design 技能的两条不可协商规则：

Never design from the surface. Establish what the business actually models first.（绝不从界面出发设计，先建立业务实际建模了什么。）

Never turn the business model into the information architecture.（绝不把业务模型直接变成信息架构。）

整个技能体系围绕 SCLPT 展开，其中 L 是 Cooper 的三层模型（见 layer-model.md）：

模型	是什么	权威归谁
实现模型（Implementation model）	产品实际如何工作：概念、状态、事件、义务	系统，不可争辩
表现模型（Represented model）	界面声称产品是什么	设计，唯一由我们撰写的层
心智模型（Mental model）	用户相信它是什么	用户，无法从另外两层推断

Cooper 的目标一句话概括了整个设计工作：表现模型要尽可能贴近心智模型，并尽可能远离实现模型。 Pattern Base 中的每一条模式（P-01 至 P-14）都是守住这条线失败的一个实例，而这个案例正是这些模式最初的来源。

原始任务：一个"感觉"，不是需求

案例的起点（The ask）被完整保留下来：

"Look at our home surface. Nobody has put any design thought into it. What should actually be there?" （看看我们的首页。没人对它投入过任何设计思考，上面到底应该有什么？）

文档特意强调了这个任务不是什么：不是 bug，不是规格说明，不是需求清单——它是一个感觉。下文全部工作，就是把这种"感觉"转化为可构建的东西。这正是 product-design 技能与 ux、ux-audit、design-prototype 等技能的分界线（见 SKILL.md 的技能关系表）：本技能回答"这个界面应该是什么、为什么"，而不在像素层面争论。

Step 1 — Ground：先建立业务事实，再谈界面

发现一：一个关掉三通道的决策收件箱（P-04）

界面上显示的是 agent 错误。于是团队一直在把它当错误日志来推理——"我们怎么让错误列表更好看？"

落地（Grounding）领域模型后，这个判断被整个颠倒过来：业务建模了四种 agent 对人类的 message，并且每天都在生产环境中产生全部四种：

类型	在业务中的含义
decision	agent 在工作中途暂停，需要人类就某事做出裁决
result	agent 产出了交付物，正在等待被验收
insight	agent 发现了值得知道的事情，无需任何决策
error	运行失败

每一种都带有优先级、一组可能的响应动作、以及各自的关联交付物，每一种都有完整的 seen → answered（已见 → 已答） 生命周期。

四种类型里有三种从未展示给任何人。

因此，这个界面不是"需要美化的错误日志"，而是一个四个通道关掉三个的决策收件箱（对应模式 P-04）。这一个发现的价值超过整个重新设计中其他所有发现加起来的总和——而且没有任何一种盯着截图看的方法能产生它。

这一发现对应的完整模式记录在 pattern-base.md 的 P-04 一节："Don't read the surface as evidence about the product"。其检测方法是：对界面触碰的每个概念，枚举它在产品中的所有变体，然后问"界面忽略了哪些，有没有理由？"——答案常常是"没理由，只是没人顾得上"。在发明任何新东西之前先检查这一点，因为它是最便宜、也最容易错过的胜利。

发现二：状态和业务动作都不是它们名字的意思（P-01 / P-02）

同一次 Ground 中还有两个发现，都关乎含义而非机制：

• 一个叫 paused 的任务状态，意思不是"用户暂停了它"，而是一个 agent 被阻塞、正在等待人类——这是页面上最紧急的事情（P-01）。
• 一个标着"Request changes"的动作，并不会留下评论，它会重新派发任务（re-task）给 agent，把评论作为新输入喂回去（P-02）。

这两个发现分别对应 Pattern Base 中的两条模式，其检测手法值得单独拎出来：

• P-01 的检测法：对屏幕上放出的每一个状态，问"这个状态强迫谁去做什么？"——而不是"这个词在英语里是什么意思"。如果答案是"什么都不必做"，它就不值得单独展示；如果答案是"必须有人类采取行动"，那它就是一条队列。按 P-01 记录，该产品实际上把 paused 呈现为 Pending review，看板上对应列叫 Needs input——若按"paused = 用户挂起"来设计，它会被扔进"稍后"桶，而它实际是全页面最紧急的信号。
• P-02 的检测法：对每一个动作，补全句子"点了它之后，业务处于……状态"。如果补不出来，说明你并不知道这个按钮到底做什么，而你即将设计出的产品和真实存在的产品不是同一个。

SKILL.md 对这一阶段的总要求与此一致：产出的不只是概念、角色和状态清单，还包括"谁产生终态业务事实、什么关闭生命周期（P-12）""每个状态强迫谁做什么（P-01）""每个动作产生什么业务事件（P-02）""业务没有哪些概念（P-06）"。同时它警告：领域类型和状态机是强证据但不是唯一真相源，代码可能过时、偶然或不完整，必须用服务端行为、权限、策略和用户证据去对账。

Step 2 — Frame：框定用户的视图模型

初始的用户视图模型是一个假设，而不是用户事实：某个人打开首页，是为了找到那些阻塞在自己注意力上的工作。被反复查找的对象（lookup object）是需要响应的信号，并附带其来源与后果。

这一步有两条方法论约束。第一，它由领域义务支撑，但仍需用户验证——案例后来确实等到了直接的用户证据：人类对"以任务组织"的纠正（见 Step 4）。第二，它必须与业务模型严格分层，这是 SKILL.md 中 Step 2 的核心表格：

模型	在设计中的角色
业务/领域模型	定义真相、合法性、完整性与红线
用户视图模型	定义分组、排序、标签和默认展开方式
执行模型	提供来源与审计细节，永远不白得整个页面

同时禁止在"顶层分区只是领域名词或执行名词"（如 runs、reports、表名）时继续推进，必须改写成用户试图查找的对象（P-14，详见 pattern-base.md）。

Step 3 — Diagnose：诊断出三个结构性错误

诊断的原则是"不论品味如何，指出什么是错的"。本次会话诊断出三个结构性错误，没有一个与审美有关：

1. 一个决策收件箱被当作错误日志在用。（见 Step 1。）
2. 界面同时是分诊台（triage desk）又是阅览室（reading room），两者都失败了。 每张卡片都带一段"段落长度"的摘要——太短以至于替代不了文档，太长以至于无法快速扫读。用户既没有读它，也没有干净利落地跳过它（P-07、P-08）。
3. 信号按"谁产生的"分组，而不是按"它要求什么"分组。 用户需要知道的是*"什么被我阻塞了"，而不是"agent 说了什么"*（P-09）。

这三条分别对应 Pattern Base 中的判断规则：

• P-07 — 首页是分诊台，不是仪表盘：收件箱类界面只回答一个问题——"这是不是我要处理的？"其测试法是：对页面上的每个元素问"如果用户从不点击它，会有东西被卡住吗？"若否，它不属于这个界面，它属于某个有人专门会去的页面。被否决的替代方案是团队仪表盘（用量趋势、成员排行榜、吞吐图表），其命运是可预测的：管理者看两周，成员一次都不会看——"发生了什么"的界面没有拉力，"什么被卡在我身上"的界面才有，因为不看的代价是真实的。
• P-08 — 密度服从决策成本：一个项目在屏幕上占多大，应该匹配它需要多少思考，而不是它的生产者恰好写了多少文字。需要我决策的信号展开为"标题 + 一句话理由 + 动作"；只需知晓的压缩为一行（标题、来源、时间），细节点击才出现；什么都不需要的折叠成一个计数。原界面的真实失败不是"摘要太长"，修复方式也不是把它缩短——而是逐项决定"这个条目需要多少思考"，让答案决定形态。
• P-09 — 按所需动作分组，而不是按产生实体分组：agent 说"我卡住了，裁决一下"和同事说"@你，看看这个"，对接收者来说是同一个信号，应该进同一个列表。按实体形状分组是系统看世界的方式，按动作形状分组才是用户的方式。其推论同样来自该模式：排序要按"什么真的在阻塞"，而不是优先级字段——卡住的决策此刻正在阻塞工作，而失败的运行已经停下来了可以等等，所以失败项即使优先级字段写着"紧急"也要沉到队列底部，因为"紧急"是生产者写的，"阻塞中"是世界的事实。

如果没有任何结构性错误能被证据支撑，SKILL.md 的要求是：报告"没有结构性错误"，而不是硬造一个诊断。

Step 4 — Align：只对齐会改变答案形状的决策

原则是：一次只暴露一个决策，且只暴露那些会改变答案形状的决策。本例中真正改变了形状的有两个：

• 主轴是注意力（什么需要我）还是进度（什么在推进）？ → 注意力。 进度是背景上下文，注意力才是打开这个页面的理由本身。
• agent 信号和人类信号进一个收件箱还是两个？ → 一个。 agent 说"我卡住了"和同事说"@你"，对接收者来说是同一种信号（P-09）。

这一回合最有价值的部分是人类推翻（overrule）了 agent 的第一版框架：agent 提议把一切都围绕 tasks（任务） 组织；人类的回复大意是——"围绕工作来组织，围绕注意力和目标来组织——而不是围绕某一个实体类型。" 这次纠正直接成为 P-09。

这个细节揭示了整套方法的一个关键机制：Align 阶段的每一次推翻都不是返工，而是证据。trace-schema.md 明确规定现实核查日志中每一行被推翻的假设都要记录"假设的原话 / 业务事实 / 所属模型 / 结论 / 命中的模式"，而 NEW（没有既有模式能预测它）的行正是 Pattern Base 的缺口——Step 6（收尾）负责把它补上。

Step 5 — Prototype：让原型以"业务能纠正的方式"犯错

原型在真实设计系统中进行了六轮。每一轮，业务都推翻了其中的某一部分：

轮次	原型声称了什么	业务说了什么
v3	自造了一套状态词汇	paused 已经意味着等待审查——是一个人类在阻塞 agent（P-01）
v4	"Request changes" = 一个评论框	它是重新派发任务给 agent（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. （原型的职责不是正确，而是以业务能够纠正的方式犯错。） 如果某一轮只是在挪像素，说明 Ground 被跳过了。

两条对应的模式细节值得展开：

• P-05（界面承诺了一个不存在的业务事件）："Accept task" 按钮从其他产品（Jira 式的 accept/decline）被移植过来，但本业务中派发是即时且单方面的——同事派发的瞬间任务就是你的，不存在"已提供、待接受"状态。这个按钮是一句谎言：它暗示你可以拒绝，而你不能。诚实的动作是映射到真实业务事件的那两个：Start（它成为活跃工作）或 Reassign（它变成别人的）。检测法：为每个按钮命名它产生的业务事件，命名不出来，这个按钮就是剧场（theatre），删掉它——或者大声承认你其实在提议修改业务模型。
• P-11（把没建的概念写进规格）：v6 展示了每次运行的耗时，而业务在任何地方都没有建模运行时长。把这句话写进规格，就把"你怎么忘了时间戳"变成了"我们知道，这里是代价"。

此外，trace-schema.md 还规定：凡是原型中画了、业务却撑不住的东西，必须在 mock 上打上可见的 NEW 标签，而不只是写进规格文档——评审者看一张图时，必须能分辨哪些部分是真实的。文中给出的示例：

Total time on this: 11h 06m   [NEW]   ← 业务没有建模运行时长

Step 6 — Scope：诚实定界，只交付业务已经相信的部分

定界（Scope）把全部能力按"业务是否已建模"分三桶：

桶	能力
✅ 已建模且已暴露	error 通道、已有的响应动作
⚠️ 已建模、从未暴露	其余三种 message 类型、运行中的工作、未读的已完成工作、每条 message 所属的任务
❌ 业务中还不存在的概念	对某个人的 @提及、批注、在线状态、项目（project）、运行时长

本例推荐并实际交付的切片：✅ + ⚠️。 它们合起来构成一个自洽的"个人收件箱"职责。❌ 列中没有任何一项是这个切片所必需的。每一个被排除的项都以名字写进了规格，并附上其代价（P-11）。

案例给出的结论性判断值得原样保留：这场以宏大的团队协作愿景开始的重设计，最终交付为一个聚焦的个人收件箱——这不是退缩，而是因为那才是业务已经相信的部分（P-10）。昂贵的那一半，仍然在（正确地）被争论着。

对应 pattern-base.md 中 P-10 的完整规则：优先选择"✅ + ⚠️"的自洽切片，当它完成用户的完整职责时；不要仅仅因为某些概念已存在就交付一个不完整或误导性的切片；而某个 ❌ 项在价值、安全性或语义完整性要求时，可以成为正确的第一笔投资。

Close — 记录覆盖率，并提出学习

案例的收尾部分回答了两个问题：这次会话学到了什么，以及这次会话还差什么。

冷启动签名：九条假设，九条被推翻

Nine assumptions overturned, nine NEW → the entire Pattern Base.（九条假设被推翻，九条 NEW，构成了整个 Pattern Base。）

这正是 trace-schema.md 定义的冷启动（cold-start）签名。该文件中的示例行与本案例一一对应：

假设	真实情况（业务事实）	模型	结论	模式
界面上只有 agent 错误	业务建模了四种 agent 对人类的 message——待裁决、待验收、洞察、错误。四种每天都在产生，只展示了一种	implementation	overturned	NEW → P-04
paused 意味着用户暂停了它	它意味着一个人类正在阻塞 agent——等待审查，是全页面最紧急的状态	implementation	overturned	NEW → P-01
"Request changes" 留下评论	它重新派发任务给 agent：解决该条目并用评论作为输入重跑	implementation	overturned	NEW → P-02
"Accept task" 是一个真实动作	派发是即时且单方面的，不存在"待接受"状态——按钮暗示可以拒绝，而你不能	implementation	overturned	NEW → P-05
存在 project 概念	不存在。叫 "Project" 的分区其实是知识库	implementation	overturned	NEW → P-03
可以展示团队正在讨论什么	对话没有"属于某个成员"的概念，展示它是领域变更，不是布局选择	implementation	overturned	NEW → P-06
按成员的未读徽标是 UI 决策	"未读"是对话的属性，不是人的属性	implementation	overturned	NEW → P-06
暴露未建模的工作需要新的管道	业务已经建模了"运行中"和"未读"的工作，只是从来没人要求过	implementation	overturned	NEW → P-10
可以展示每次运行的耗时	业务根本没有建模运行的时长	implementation	overturned	NEW → P-11

trace-schema.md 同时给出了日志形状的判读表：大量 overturned 且全部 NEW 意味着冷启动——模式库在这里是盲的，去收割它；而一次成熟的运行应该以 confirmed 为主，夹着一两条 NEW。

覆盖率信号，与一次诚实的自我批评

案例给出了覆盖率信号：被检查的 message 变体、任务状态、响应动作与所有权概念，在推进后期没有再产生新的缺口。这证明了下一轮可以把预算转向用户证据，但并没有证明领域模型已经穷尽。

然后是整份档案最尖锐的一句判决：九行记录全部是"实现模型"层面的发现，没有一行是关于"心智模型"的。 这就是对这次会话的真实评价——能在办公桌前完成的那一半做得很好，而需要用户的那一半完全没有做。下一轮的预算应该投在那里。

这与 layer-model.md 的第 4 种跨模型误判严格对应："从另外任意一层推断心智模型"是没人意识到自己在做的事。"业务建模了四种 message，所以用户按四种思考"——不成立。"界面一直是错误日志，所以用户就是这么预期的"——也不成立。心智模型是唯一无法被落地（ground）的一层，它只能来自用户。当一次工作对心智模型的发现为零时，必须说出来——那不是健康的证明，那是一个未被审视的层。

三条可以泛化的结论

案例最后提炼出三条可迁移的结论，它们不依赖 LobeHub 的具体业务：

1. 最大的胜利是一个被关掉的能力，而不是一个新能力。 在发明任何东西之前先检查这一点——它是能买到的最便宜胜利，也最容易漏掉，因为界面正是所有人（包括构建它的人）误认为"产品"本身的东西。
2. 每一轮原型都应该被领域证伪（falsified）。 如果没有，你做的不是设计，是装饰（decorating）。
3. "业务已经相信什么？"是把愿景转化为可交付物的那个问题。

如何在自己的仓库中复现这套方法

这个案例之所以有说服力，是因为它的全部方法论都沉淀在仓库中，可以直接复用：

文件	作用
SKILL.md	六步流程的完整定义、三种运行模式（Discover / Frame / Materialize）、反模式清单
references/pattern-base.md	P-01 至 P-14 模式库，每条含 Symptom / The real case / Why it happens / How to detect it next time
references/trace-schema.md	现实核查日志的字段定义、日志形状判读表、mock 上打 NEW 标签的规则
references/layer-model.md	Cooper 三层模型、四种跨模型误判及各自的守卫（Guard）
references/canon.md	外部基准：Cooper《About Face》、Singer《Shape Up》、JTBD、Tidwell《Designing Interfaces》的分工
templates/design-spec.md	设计规格模板：业务事实、用户视图模型、诊断、原则、信息架构、三桶定界、红线、现实核查日志、开放决策

复现路径可以概括为：拿到一个模糊的"感觉"后，先按 SKILL.md 的 Step 1 从领域概念、状态机、服务行为与权限中对账出实现模型（并警惕代码过时）；用 P-01/P-02 的问句逐一翻译状态与动作；用 P-04 枚举界面隐藏的概念变体；把结构性错误写出来再谈布局；每个按钮命名其业务事件，命名不出的在 mock 上打 NEW；最后用三桶表定界，把 ❌ 项逐一点名写入规格。整个过程产出的现实核查日志会替你回答"这次会话学到了什么、还差什么"——如本例所示，那个"还差什么"（心智模型证据为零）本身就是最有价值的交付物之一。