产品设计方法

唯一信条

产品是「问题被解决」之后自然沉淀的产物，不是起点。

设计的对象从来不是「做什么功能」，而是「回答什么问题」。任何功能开工前必须先改写成契约。

契约：动词 → 三行

每个功能只允许是这三行，超出即臃肿：

答不出第 3 行 = 这个功能没有存在理由，写进 docs/roadmap.md 的「明确不做」，不写进产品。

形态无关：Web 的一屏、App 的一个页面、CLI 的一个命令、库的一个函数、抽象产品的一个环节，套的是同一个契约。变的只是「输出怎么呈现」，契约本身不变。

原则层

1. 单一权威源：契约表是唯一权威，别处不重复定义同一个功能。重复定义 = 漂移的起点。
2. 语义分层：界面只引用语义（「结论」「警示」「危险」），不写死样式值；消费方永远不碰原始值。
3. 缺失 ≠ 要补：缺一个字段 / 颜色 / 功能，先用最接近的既有答案顶上，而不是加一个新的。补进来的东西要有「设计负责人批准」级别的理由。
4. 责任分离：一个界面 / 环节只回答一个问题，不越界干别的。
5. 例外走显式流程：想加任何东西，先写进 docs/roadmap.md 的「明确不做」区，再走过滤问题决定要不要进产品。

方法层（每次迭代都执行）

外部基准（默认步骤，先于契约确认）

用户提出功能构想时，先做轻量市场基准，再确认契约三行：

1. 问一句：同类成熟产品如何回答同一个问题（它的 问题→输出→决定）？国际 / 中文 / 开源各覆盖 1–2 个方向，定向检索。功能名只是检索词——先重写成三行让用户确认，再继续。检索不可用（离线 / 无网络）时，改问用户要 1–2 个他熟悉的同类产品代替；仍没有就跳过基准，并在契约备注里标注「基准未做」——基准是输入不是门禁。
2. 收敛成参考：把「别人的 问题→输出→决定」压缩成一段外部基准（附来源），随契约落盘为一行备注。外部阈值与口径不可移植，只借鉴「回答了什么问题、输出了什么、驱动什么决定」的结构。
3. 边界：不建研究账本、不做多路并行、不设交付格式门——基准是契约的输入，不是独立项目。

过滤问题（唯一的砍刀）

想加任何功能、字段、图表、按钮、命令、参数，先问一句：

它服务契约表里哪个决定？没有它，那个决定还做得出来吗？

• 答不上 → 写进 docs/roadmap.md 的「明确不做」，不进产品。
• 做得出来 → 砍掉，它此刻就是臃肿。
• 做不出来 → 保留，它是刚需。

不需要 RICE、Kano、优先级框架来「排序」——排序是等它进来之后的事，砍刀只需要这一句。

结论前置

默认只显示「触发决定的那个结果」（结论数字），明细、图表、表格全部「点开才有」。臃肿几乎总是「把明细默认铺开」造成的。

显示导致决定的数字，不是原始数据。比如显示「储蓄率 38%」，而不是「年支出 20 万」——前者直接触发决定，后者还要用户心算。

「明确不做」仪式

每次想加东西，先写进 docs/roadmap.md 的「明确不做」区（有地方安放，不憋着），再走过滤问题：确认不要的留在该区；被判定为刚需的，从该区移进对应里程碑的功能表。这份清单同时是「想加的东西有去处」的安放处和「迷茫时的方向标」。

与 init 的协作

init 技能阶段 2（领域深挖）在项目形态是面向用户的产品时，应调用本技能做一次契约访谈，把收敛结果落进 docs/goals.md 和 docs/roadmap.md 的「明确不做」。本技能是独立技能，可单独调用，也可被 init 引用，两者各自演进。

反模式（这些写法等于没写）

• 用「以后可能用到」作为保留理由 → 直接砍。加回来的成本近零，方向错的成本不可逆。
• 为还不存在的需求预建字段 / 目录 / 接口 → 砍。