product-design

产品设计

先决定要构建什么以及为什么，再讨论间距。

有两条不可妥协的规则：

绝不要从表面开始设计。先弄清业务实际建模的是什么。

绝不要把业务模型变成信息架构。领域约束界面可以表达什么；用户的检索与决策任务决定界面如何组织。（P-14）

这项技能优先处理产品含义。它可以将有依据的框架交给 ux 或 design-prototype，但探索并不需要实现或原型。 去掉所有框架、表格和组件名称：如果没有留下任何产品洞见， 那这个发现就属于工程技能。

与其他技能的关系

技能	问题	适用时机
product-design	这个界面应该是什么，为什么？	定义框架之前或期间
ux	交互应该如何运作、给人什么感受？	设计或构建期间
ux-audit	已构建的界面是否遵循这些规则？	界面构建完成后
design-prototype	如何测试已实现的交互？	原型有用时

选择最小的运行模式

模式	完成标准
Discover	证据图谱、业务模型、用户模型假设和结构诊断
Frame	Discover + 视图模型、信息架构、范围和待决事项
Materialize	Frame + 所请求的规范和／或原型

除非用户要求设计产物、原型或仓库变更，否则不要创建或修改任何产物。

对于实质性的运行，请完整阅读 references/pattern-base.md 和 references/layer-model.md。对于范围较窄的问题， 只检查相关模式，并说明检查了哪些范围。

第 1 步 — 弄清业务模型

先确定哪些内容属实，再诊断界面。对于大型仓库， 如果可以且有帮助，可并行调查相互独立的证据领域； 主要 Agent 仍负责协调并解决矛盾。

产出：

• 概念、角色和状态，包括当前界面隐藏的变体（P-04）。
• 谁产生最终业务事实，以及什么会结束生命周期（P-12）。
• 每种状态要求某人做什么（P-01）。
• 每项操作会产生什么业务事件（P-02）。
• 业务中不存在的概念（P-06）。
• 证据来源、矛盾和置信度。

将领域类型和状态机视为强有力的证据，但不要把它们视为唯一真相。 如有相关信息，请检查服务行为、权限、策略、生产事实和用户证据。 代码可能已经过时、源于偶然情况或并不完整。

切勿依据团队假定的产品模型继续推进。在与领域及用户证据核对之前， 都应将其视为假设。

第 2 步 — 构建用户视图模型

事实依据约束产品可以声称什么，但不会决定用户应该如何看待它。将观察到的用户证据与设计假设分开：

• 情境与任务 —“当我打开它时，我需要……”
• 查找对象 —用户会扫描、比较或检查的稳定事物。
• 附带证据 —用于验证每个对象的内容，无需重新拼接关联数据。
• 首次浏览 —无需点击即可回答的 2–4 个问题。
• 次要维度 —时间顺序、来源、运行和内部状态；除非任务是执行审计，否则将它们保留为筛选条件或下钻项。
• 证据与置信度 —将声明标记为观察所得、他人报告或推断；说明如何验证影响重大的假设。

模型	在设计中的作用
业务／领域模型	定义真实性、有效性、完整性和不可逾越的界限
用户视图模型	定义分组、排序、标签和默认展开方式
执行模型	提供来源信息和审计细节；不能不费吹灰之力就占据页面

如果拟议的顶层分区仍只是领域或执行相关的名词，例如 runs、reports、证据版本或表名，就不要继续。应改用用户试图查找的对象来组织（P-14）。

第 3 步 — 诊断结构性错误

指出一个不论个人偏好如何都存在的问题，例如：

• 决策收件箱只显示错误，因此看起来像错误日志（P-04）。
• 某个按钮承诺了一个并不存在的业务事件（P-05）。
• 一个页面既是分流台又是阅览室，结果两者都做不好（P-07）。

如果没有证据支持任何结构性错误，就如实说明，而不是凭空捏造诊断。

第 4 步 — 按依赖关系确定决策

只提出会改变答案结构的决策。对每项决策，给出建议、证据和后果。先解决上游决策，再处理受其制约的下游决策。

如果某个问题的答案会实质性改变工作，就单独提出这个阻塞性问题；将相互独立的决策归入同一份备忘录。用户授权自主推进时，采用建议的默认方案继续，并标明假设。切勿向用户询问可通过事实依据获取的信息。

对于审查、批准或验收界面，首先确定由系统还是人工决策来结束生命周期（P-12）。

第 5 步 — 在有助于消除不确定性时制作原型

仅当用户要求原型，或无法通过书面框架如实确定交互、信息密度或层级时，才使用 design-prototype。这属于 Materialize 模式。

• 使用合理可信的数据，并涵盖空状态、受阻状态和大规模状态。
• 对任何缺乏业务依据的内容，在模拟稿上标记 NEW。
• 将修正视为证据。只有当它们适用于当前界面之外的场景时，才可成为 Pattern Base 候选项。

步骤 6 — 诚实评估范围

类别	含义
✅ 已建模并已开放使用	重新编排现有能力
⚠️ 已建模，但未开放使用	领域风险较低；仍需验证工程成本
❌ 尚未建模	需要扩展领域，并明确评估成本／风险

如果一个连贯的 ✅ + ⚠️ 范围能够解决完整的用户任务，就优先选择它。不要仅仅因为相关概念已经存在，就交付不完整或具有误导性的范围。如果某项 ❌ 能力是实现价值、安全性或语义完整性所必需的（P-10），它也可能是最值得优先投入的事项。

在规范中列出每一项 ❌ 及其可能的成本因素（P-11）。不要悄悄将其略去，但也不要假装仅凭领域模型就能推断其成本。

收尾 — 记录覆盖情况并提出学习建议

在用户授权的范围内收尾：

1. 如果要产出规范，请纳入 references/trace-schema.md 中的现实核查日志。对于只读工作，请在回复中报告重要假设和证据，而不是写入文件。
2. 将意外发现与 references/canon.md 进行比较，仅当经验具有普遍性时，才提出 Pattern Base 候选项。
3. 只有在获准修改仓库，且候选项已去重并可供审查时，才追加到 references/pattern-base.md。
4. 记录覆盖情况：已检查的来源和生命周期领域、无法获取的证据、仍然置信度较低的主张，以及是否发现新的缺口。

没有发现新缺口，仅表示在已检查的范围内没有发现缺口。这并不能证明实现或心智模型已穷尽。

交付物

产物	适用时机	模板／位置
设计规范	在物化模式下提出请求	templates/design-spec.md；使用用户指定的路径，或向用户询问
交互式原型	用户提出请求，或需要原型来消除不确定性	与规范放在同一目录，通过 design-prototype 创建
现实核查日志	纳入产出的规范中	references/trace-schema.md
Pattern 候选项	出现具有普遍性的意外经验	写入规范／回复；仅在审查并获准后追加

反模式

• 根据截图进行设计，或将领域模型当作站点地图。
• 根据标签而非义务或事件来解读状态或操作。
• 从代码推断用户模型，并将其说成是观察到的事实。
• 将缺失的概念当作布局问题。
• 提出已有证据足以回答的问题。
• 将概念的存在视为工程成本估算。
• 自动创建原型、编写规范或修改 Pattern Base。
• 将局部修正或工程发现添加到共享产品指南中。

如需完整示例，请阅读 references/worked-example.md。