LobeHub product-design 技能深度解析：Cooper 三层模型如何约束「实现模型、表现模型与心智模型」

LobeHub 仓库内置的 product-design Agent 技能以 Cooper《About Face》的三层模型（implementation / represented / mental model）为核心骨架，用来解决一个反复出现的产品设计问题：团队习惯用错误的证据回答错误层级的问题。本文完整继承该技能的 layer-model 参考文档，逐层拆解三模型的定义与权威归属、四类跨模型误判的诊断与防线、finding 的模型标注规则与按模型维度的覆盖度判定，并结合 LobeHub 自身的领域类型（BriefType、TaskStatus）说明这些规则在真实代码库中如何落地。

一、Layer Model 在 SCLPT 体系中的位置

layer-model 文档开头即点明自己的身份：「The L of SCLPT」（SCLPT 是 product-design 技能的一套方法论缩写）。技能明确声明：

我们不发明自己的层模型；Cooper 早已写下了正确的那一个，而且它经受住了二十五年的考验。

也就是说，这套技能不追求理论创新，而是把 Cooper 的三模型框架当作「脊柱」，再在其上生长出模式库（Pattern Base，即 SCLPT 的 P）与证据追踪（Trace Schema，即 T）。

从仓库结构看，这一引用关系是显式的：

• 技能主文件 SKILL.md 要求：「对于一次完整的产品设计运行，请完整阅读 references/pattern-base.md 和 references/layer-model.md」；
• pattern-base.md 将「Cooper 的三模型」列为全书脊柱，并注明「The frame is Cooper's, unmodified — see layer-model.md」；
• trace-schema.md 中 Reality-check log 的 Model 字段直接标注「这是关于 Cooper 三模型中哪一个的事实（见 layer-model.md）」。

因此 layer-model 不是可选阅读材料，而是整套证据标注体系的坐标系：没有它，finding 就不知道自己属于哪一层，也就无法决定自己「授权」什么结论。

二、三个模型：定义、证据与权威归属

文档给出的核心是一张四列对照表，每一列都有独立含义：

模型	它是什么	它的证据来源	谁拥有权威
实现模型（Implementation model）	产品实际如何工作：它的概念、状态、事件、义务	领域模型、状态机	系统本身，不可争论
表现模型（Represented model）	界面声称产品是什么	界面表面（surface）、原型	设计——这是唯一由我们创作（author）的模型
心智模型（Mental model）	用户相信产品是什么	用户的言语与行为	用户——无法从前两个模型推断出来

表格中「权威归属」一列是最容易被忽略、却最关键的一列：实现模型由系统说了算（代码与领域模型是事实），表现模型由设计师说了算（它是唯一被「创作」出来的模型），而心智模型既不由代码也不由界面说了算——它只能来自用户本人。

紧接着，文档引用 Cooper 的目标作为「全部工作在一线里的压缩」：

表现模型应尽可能贴近心智模型，并尽可能远离实现模型——在必要范围之内远离。

文档对此有一句斩钉截铁的判词：

Pattern Base 中的每一个模式，都是一次「没能守住这条线」的失败。

这句话把 layer-model 与模式库的关系说透了：P-01 到 P-14 不是散乱的经验清单，而是同一层错位在不同症状下的表现（模式库把这类失败进一步细分为 A「语义≠标签」、B「表现与实现不一致」、C「注意力组织」、D「范围与诚实」、E「人类判断与机器证据」五类，可在 pattern-base.md 中对照阅读）。

三、实现模型写在哪里：领域模型，以及「业务含义过滤器」

文档对「去哪里读实现模型」给出了明确回答：写在领域模型里——那些概念、状态与事件。并且特别强调，理由不是「实现本身重要」（该技能对软件如何构建毫无意见），而是因为领域模型是公司关于「它相信什么存在」的最诚实的陈述：

• 营销文案是愿景性的（aspirational）；
• 路线图是愿景性的；
• 只有领域模型是产品实际承诺的东西。

把它当一份领域文档来读。

由此推出文档中最具操作性的一条过滤器（corollary filter）：

任何不携带业务含义的事实——哪个组件画了 spinner、某个模块如何接线——根本不是实现模型层面的 finding。它是关于_代码_的事实，是完全不同的另一回事，不进入这套系统。

这条过滤器在 pattern-base.md 中被进一步锻造成一个可执行的测试：

删掉所有框架、表名和组件名，还剩产品洞察吗？ 如果没有，它就是一份伪装成设计的工程笔记。

四、跨模型误判：真正会发生的四种

文档称这是层模型「存在的目的」（this is what the layer model is for）。每一种都是用 A 模型的证据去回答属于 B 模型的问题。

1. 从表现模型推断实现模型

典型句式：「界面上没显示它，所以产品一定没做这件事。」

文档评价这是代价最高、也最隐形的一种——因为它感觉起来像在观察，而不是在推断。文档给出的真实案例：某个界面只展示了 agent 的错误，于是整个团队把它当作错误日志来讨论。而产品实际上建模了四种 agent 到人的消息，每天四种都在产出；其中三种只是从未被界面上来而已。

文档特意区分了「普通」与「不普通」的部分：

• 普通的部分：这些场景先于界面被设计和构建出来，这在节奏上再正常不过。
• 不普通的部分：团队对整个产品的模型竟然完全由「盯着屏幕」塑造而成。

防线（Guard）：永远不要把界面当作关于产品的证据；每一次都要直接把实现模型落回地面（ground，对应模式 P-04）。

2. 用实现模型去构建表现模型

Cooper 所称的「中心疾病」。界面镜像了机器：它继承了机器的词汇（例如 paused——其真实含义其实是「一个人类正在阻塞一个 agent」）、机器的分组（按产出实体分组，而不是按要求的动作分组）、乃至机器的形状。

防线：表现模型是被创作的，不是被推导的。对每一个状态，问它迫使某人去做什么（obliges）；对每一个动作，问它产出了什么。从那里出发设计，而不是从名字出发（对应 P-01、P-02、P-09）。

3. 表现实现模型中不存在的东西

与第 2 种互为镜像，文档称之为「以戏剧化方式上线（ships as theatre）」：在一个已经被单方面分配给你的任务上放一个「Accept task（接受任务）」按钮。这个可供性（affordance）暗示了一个产品根本没有建模的选择。

防线：为每一个界面元素命名它背后的业务事件。如果你命名不出来，就在原型本身上标一个可见的 NEW 标记——这是一笔可见的债务，而不是一句无声的谎言（对应 P-05、P-06）。

4. 从其余两个模型推断心智模型

文档强调：这是没人意识到自己在做的那种。

两个否定式例子：

• 「产品建模了四种消息，所以用户按四种来思考。」——不对。
• 「界面一直是错误日志，所以用户期待的就是错误日志。」——也不对。

心智模型是唯一无法被落地（cannot be grounded）的模型：既不能落在领域上，也不能落在屏幕上。它来自用户，且不来自任何其他地方。

防线：关于「用户相信什么、想要什么」的陈述是断言（claim），必须被论证或被观察——绝不能从 schema 或截图里断言出来。当一次工作对心智模型零发现时，明说「零发现」：那不是一个健康证明，而是一层未被审视的盲区。

五、Finding 的模型标注：标签决定授权

文档规定：trace-schema.md 定义的 reality-check log 中，每一行 finding 都要打上「它是关于哪个模型的事实」的标签。标签决定该 finding 授权什么结论。 原文的标注示例表如下（完整继承）：

Finding（发现）	模型	它授权什么
「产品建模了四种 agent 消息；界面只显示一种」	implementation	一个范围机会——甚至可能是整次重设计
「paused 迫使人类去审查；它的意思不是『被挂起』」	implementation	设计成队列，而不是『稍后处理』桶
「『Request changes』会让 agent 重新受任务；它不是评论」	implementation	设计重派任务流程，而不是评论框
「不存在『已提供、等待接受』的状态」	implementation	删掉 Accept 按钮——那是戏剧
「对话没有『归属于某个人』的概念」	implementation	一条红线——是领域变更，而不是布局选择
「摘要长到扫不完、短到替代不了文档」	represented	一个密度决策
「没人会打开仪表盘两次」	mental	一个断言。论证它或观察它——绝不断言
「这个 spinner 是用 SVG 动画画的」	—	不是 finding。 没有业务含义。丢弃

最后一行就是第三节的过滤器在实际标注中的样子。文档补了一句警示：

你能从一个代码库里学到的大多数东西都不是产品 finding；把它们放进来，Pattern Base 就会退化成一份 changelog。

这套标注机制在 trace-schema.md 中有对应的字段实现：Reality-check log 每行包含 Assumption / What is true / Model / Verdict / Pattern 五个字段，其中 Model 字段正是三模型之一。

六、按模型维度度量覆盖度

文档最后一节规定：覆盖度（coverage）必须按模型分别度量。一轮没有新发现的巡检，只有在其「检查过的信息源」和「生命周期区域」被记录下来时才有意义。三条分模型规则：

1. 实现模型通常是有界的。一次彻底排查可能已经找到大多数相关概念；一轮零新缺口，可以正当化把精力转向用户证据，但它只证明在被记录的范围内没找到，不证明模型已穷尽。
2. 表现模型通过验证来稳定。持续变化可以反映学习过程；应当记录变化的原因，而不是从修正次数推断流程质量。
3. 心智模型保持暂定（provisional）。grounding 无法确立它。必须把 observed（观察到）、reported（用户口述）、inferred（推断）三类声明分开标注，并记录验证缺口。

这条规则与 trace-schema.md 的「Reading the log」表直接联动：「整轮零 NEW」的含义被明确限定为「检查范围内没有新缺口；在转移精力之前先检查覆盖度」。

七、源码印证：这些「案例」在 LobeHub 仓库中是真实类型

layer-model 文档中反复引用的案例并非抽象寓言，LobeHub 的领域类型里可以找到直接对应物，这正说明「读实现模型 = 读领域模型」在仓库内部是可执行的。

七.1 「四种 agent 到人的消息」就是 BriefType

packages/types/src/brief/index.ts 中定义了：

/** Brief type — must match DEFAULT_BRIEF_ACTIONS keys and DB schema comment */
export type BriefType = 'decision' | 'error' | 'insight' | 'result';

/**
 * Brief types with nothing to decide — the home "news" digest. Shared between
 * the server day-feed query and the client feed split so the two can never
 * disagree on what counts as news.
 */
export const NEWS_BRIEF_TYPES: BriefType[] = ['insight', 'result'];

四种类型——decision（agent 暂停并等待裁决）、result（等待验收的交付物）、insight（值得知道、无需决策）、error（运行失败）——与 worked-example 中「决策收件箱有四个信道」的描述逐一对应。同一文件还给出了每种类型默认动作（DEFAULT_BRIEF_ACTIONS）：

export const DEFAULT_BRIEF_ACTIONS: Record<string, BriefAction[]> = {
  decision: [
    { key: 'approve', label: '✅ Confirm', type: 'resolve' },
    { key: 'feedback', label: '💬 Request changes', type: 'comment' },
  ],
  error: [
    { key: 'retry', label: '🔄 Retry', type: 'resolve' },
    { key: 'feedback', label: '💬 Feedback', type: 'comment' },
  ],
  insight: [{ key: 'acknowledge', label: '👍 Acknowledged', type: 'resolve' }],
};

这里恰好能看到第四种误判的反例形态：decision 类型的 feedback 动作在类型层被声明为 type: 'comment'（提示文本输入后 resolve），而 pattern-base 中 P-02 的结论是「Request changes 的业务后果是重派任务（re-tasking），不是留评论」——动作的标签（comment）与它对业务产生的事件之间正是层模型所警告的缝隙。类型文件顶部对 BriefAction.type 的注释（resolve / comment / link 三种机制）描述的是交互机制，而「点击后业务变成了什么」属于实现模型问题，必须到服务层去查证——这正是「代码是强证据而非唯一证据」（见 SKILL.md Step 1）的具体含义。

七.2 paused 状态确实存在于任务状态机中

P-01 案例的主角 paused 出现在 packages/types/src/task/index.ts：

export type TaskStatus =
  'backlog' | 'canceled' | 'completed' | 'failed' | 'paused' | 'running' | 'scheduled';

从源码结构看，paused 只是七值联合类型中一个按字母序排列的枚举成员——它自己不会告诉你「这是一个人类正在阻塞 agent 的待审状态」。同文件的注释还提到任务会被「failure fuse（故障熔断）」自动暂停（第 228 行附近）。这正演示了层模型的第一类误判风险：状态名由最早创建它的人（通常是机器侧）选定，随时间漂移，而没有人改名；只有结合服务行为（谁产生这个状态、哪个动作消费它）才能恢复其业务含义。

七.3 标注机制在 trace-schema 中的闭环

layer-model 的「每行 finding 打模型标签」不是孤立规定。trace-schema.md 记录了种子会话的十行 reality-check log：九行被推翻的假设全部标为 implementation 模型、全部 NEW——文档将其称为「冷启动签名」（cold-start signature）。其结语值得与 layer-model 第四节对照阅读：

九行全部是实现模型层面的 finding，没有一行关于心智模型。这是对该次会话真正的判决：能在桌前完成的那一半做得很好，而需要用户的那一半完全没有做。下一轮预算应投向那里。

这与「心智模型是唯一无法 grounded 的模型」是同一枚硬币的两面：按模型度量覆盖度，才能暴露出「整轮工作零心智模型发现」这种最容易被自满掩盖的盲区。

八、实操要点：在 LobeHub 仓库中如何使用层模型

结合 SKILL.md 的工作流，layer-model 提供的是每一步的「防误用坐标」，可以浓缩为一张速查表：

设计环节	层模型要求	违规信号
Step 1 落地业务模型	证据必须来自领域模型/状态机/服务行为，不得来自界面	用截图里的字段当产品事实
Step 2 构建视图模型	表现模型是 author 出来的；每个状态问「迫使谁做什么」，每个动作问「产出什么事件」	界面词汇、分组、形状照抄机器
Step 3 诊断结构错误	为每个界面元素命名业务事件；命名不出就 NEW	按钮暗示业务没有建模的选择
Step 6 诚实定范围	缺失概念 ≠ 布局问题，是领域变更（红线级）	把「对话无归属概念」当 UI 调整
Close 记录覆盖度	按三个模型分别记录：检查过的源、生命周期区域、零 NEW 的限定范围	把「这轮没发现」写成「模型已穷尽」
心智模型相关结论	一律标 claim：observed / reported / inferred 分开	「用户大概认为……」无来源地断言

需要说明的适用前提：layer-model 及整套 product-design 技能存放在 .agents/skills/product-design/ 下，是 LobeHub 仓库为 Agent 协作准备的方法论文档，其案例（如 agent 收件箱重设计）来自该团队真实的设计会话（完整轨迹见 worked-example.md）。文章中的代码对照（BriefType、TaskStatus）以当前仓库快照为准；若领域类型演进，应以 packages/types/src/brief/index.ts 与 packages/types/src/task/index.ts 的最新内容重新核对。

九、小结

LobeHub product-design 技能的 layer-model 文档用不到两页篇幅完成了一件结构性的事：给「产品事实」建立坐标系。三模型表格划定了每类证据的权威归属；「业务含义过滤器」把工程噪音挡在系统之外；四类跨模型误判把「用错层证据」从模糊的直觉变成可检测的模式；finding 标注与按模型度量覆盖度则让「不知道」本身也成为可记录、可度量的结论。对阅读 LobeHub 这类 Agent 产品代码库的开发者而言，这套模型还有一个直接的副产品：当你看到 paused、decision、Request changes 这样的名字时，先问「它背后的业务事件是什么」，再决定相信什么——这既是层模型的设计纪律，也是读懂这份代码库的最短路径。