foundation-build-risk-review

构建风险审查

先别构建。首先，指出最可能导致失败的一个假设。

foundation-build-risk-review 是产品决策中一个快速的承诺前把关环节。给定一个想法、功能请求或范围变更，它会返回一份构建风险审查：最大的单一风险、支持该判断的证据、结论，以及一个具体的无代码验证步骤，然后将你引导至负责下一步工作的技能。它是一个基础枢纽：职责是分流和派发，而不是重复更深入的技能。

严格把关

不要编写代码、搭建项目框架、推荐技术栈或设计实现方案。首先回答三件事：是否应该构建、最可能导致失败的是什么，以及承诺投入前必须验证什么。

如果用户表示这项工作是为了学习、作品集或内部练习，不要以市场标准来评判；但仍要指出范围和清晰度方面的风险。

适用场景

• 一个产品想法、MVP 或新的尝试即将转为构建工作。
• 收到功能请求或范围变更，你需要区分真实需求与礼貌性请求、创始人的焦虑或模仿竞品。
• 有人想在 PRD、路线图条目或工单出现之前，快速判断“我们应该构建这个吗？”

不适用场景

如果需求是	请改用
针对已发布产品做出转向或坚持的决策，需要权衡使用情况或市场数据	iterate-pivot-decision
你已选定假设，需要设计测试	define-hypothesis
为团队或领导层阐述已确认的问题	define-problem-statement
需要完整的九宫格商业模式，而非单一风险评估	foundation-lean-canvas
需要对多个功能或计划进行排序比较	define-prioritization-framework

最重要的界限：此技能面向未来，且处于承诺投入之前（数据很少或没有数据）；iterate-pivot-decision 则是回顾过去，且处于发布之后（它会权衡已发布产品的市场反馈）。

模式（先分流；在顶部注明模式）

1. 构建前 - 尚未构建的新想法、产品或 MVP。通常的主要风险是需求和分发。
2. 功能变更 - 正在进行的产品收到功能请求、范围扩展、需求变更或竞品模仿请求。此处的主要工具是需求层级。

如果产品已经发布，而问题是是否要改变方向，请转交给 iterate-pivot-decision。如果请求过于宽泛，无法负责任地进行审查，只提出一个澄清问题（补完整这句话：“这是为了让[谁]在[什么情境]下解决[什么问题]”），然后继续。不要进行冗长的问卷调查；在限定范围的审查前，最多提两个问题。

评审（契约）

请生成一份构建风险评审，包含以下部分：

1. 最大风险（R1）。 只列出一个主要风险，并按 references/risk-taxonomy.md 中的分类标记。不要罗列一长串风险。最多再补充三到五项辅助风险（R2、R3 等）。
2. 需求等级（功能变更模式）。 按层级定位请求：L0 创始人焦虑或“竞争对手有了”；L1 有一位用户提出；L2 多次提出，但没有行为证据；L3 工作流受阻；L4 收入或留存受阻。通常只有 L3 或 L4 才足以证明现在应该构建。
3. 证据清单。 列出已有信号，并按 references/risk-taxonomy.md 中的强度阶梯为每项评级。点赞、赞美、候补名单和市场规模数字都不代表需求。真实文件、已预约的通话、付款、反复的手动使用，或从现有替代方案切换而来，才算需求证据。
4. 结论（只能选一个）：小规模构建 / 先验证 / 先转向 / 暂不构建。不要使用“终止”。
5. 验证步骤。 提出一项具体的无代码或低代码后续行动（例如：与十位做 X 的用户交谈；为其中三人手动交付结果；收取预购款、付费通话费或定金），不要给出“构建 MVP”或“做用户研究”这类笼统建议。
6. 转交。 将用户引导至负责下一步工作的技能（见下文）。

保持审慎，但提供切实帮助。务必区分“能不能构建”和“该不该构建”。不要吹捧创意，也不要默认鼓励；除非路径明确具体，否则不要说“这个创意有潜力”。

结论转交

结论	转交至
小规模构建	define-problem-statement，然后是 deliver-prd / deliver-user-stories
先验证	define-hypothesis，然后是 measure-experiment-design
先转向	foundation-lean-canvas（重新构建模型）
暂不构建	停止；或转至 discover-competitive-analysis / discover-market-sizing 检查证据
存在多个相互竞争的请求	define-prioritization-framework

完整映射（包括各风险对应的转交方式）：references/routing-map.md。

如果所转交的技能不可用，不要只给出一个孤立的指向。 该技能库通常只会安装其中一部分，因此你要转交的技能可能不存在于用户的环境中。如果无法确认该技能可用，请明确说明，并直接补上其最精简的输出，使评审仍可执行：

转交的技能不可用	改为直接提供
define-hypothesis	一条可检验的假设，采用“相信 / 面向 / 将会 / 衡量方式”的形式
measure-experiment-design	三行实验概要：一项决策指标、所需样本量或持续时间，以及实验前设定的成功／失败规则
define-problem-statement	两句话的问题界定：谁在什么情境下，被什么问题阻碍
foundation-lean-canvas	仅列出风险最高的三个模块：问题、客户细分、不公平优势
define-prioritization-framework	一份排序列表，并注明唯一真正起决定作用的标准
discover-competitive-analysis	两个最接近的替代方案，以及今天你会在哪一个方面输给各自的方案
discover-market-sizing	一项自下而上的估算：可触达账户数 × 现实的采用率 × 每个账户的年收入，并标注这三个数字各自是有来源还是假设。三个因素缺一不可：账户数 × 采用率只得到客户数，并非市场规模
deliver-prd	问题、带基线的唯一成功指标，以及明确排除在范围之外的内容
deliver-user-stories	承载风险的三个用户故事，每个故事都附带一项可能无法满足的验收标准

如果用户无法执行结论所指向的下一步，这份评审就不算完整。明确指出缺口并提供最低限度的补充，总比把用户引向无法在其环境中执行的技能要好。

输出格式

一份完整的构建风险评审文档，基于 references/TEMPLATE.md 编写。章节顺序：决策标题（结论 + 一句话理由）、最大风险（R1）、支持性风险、需求级别（功能模式）、证据台账、验证计划、路由、来源。完整示例见 references/EXAMPLE.md。

质量检查清单

• 只命名一个主要风险（R1），并标注其所属分类。
• 在功能变更模式下，将请求划分到 L0 至 L4。
• 每条证据都经过评级；点赞数、候补名单人数或市场规模数字均不计为需求。
• 只给出四种结论中的一种。
• 下一步具体且低代码或无代码，而非泛泛建议。
• 指定一个路由目标。
• 不提供代码、技术栈建议或实现设计（严格门槛已生效）。

署名

改编自 bin1874/before-you-build-skill（Apache-2.0），并调整为不偏向产品经理。已移除源技能调用外部案例记忆 API 及将内容转换为用户语言的行为。