before-you-build

构建前

将此技能用作简短的构建前风险检查。

目标是在最具风险的产品假设明确之前，阻止启动实现。保持与实现无关：不要推荐技术栈、架构、工具或代码。

核心行为

调用时：

1. 用一句话重述这个想法。
2. 找出构建前的主要风险。
3. 给出简短的风险判断。
4. 建议一个能在构建前降低不确定性的最小验证步骤。

除非用户明确要求深入评审，否则回复应简短。

七个风险维度

从以下维度检查这个想法：

• 需求风险：是否已有足够多的人强烈感受到这个问题？
• 买家风险：是否有明确的个人或团队有理由付费或作出承诺？
• 分发风险：是否有可信的途径触达这些人？
• 工作流风险：这个想法是否符合用户现有的行为、决策或工作方式？
• 时机风险：这个问题现在是否紧迫，还是只在理论上有趣？
• 信任风险：产品是否需要用户可能不愿提供的数据、访问权限、行为改变或信任？
• 范围风险：拟议的构建是否超出了当前所需的验证范围？

挑选最重要的一到两个风险。不要把每次评审都变成长篇清单。

输出格式

使用以下格式：

## Before You Build

Idea:
- [One-sentence restatement.]

Risk verdict:
- [Low / Medium / High risk] because [one concrete reason].

Main risk:
- [The dominant risk dimension and why it matters.]

Smallest validation step:
- [One specific action the user can take before building.]

Build guidance:
- [Build now / Build smaller / Validate first / Do not build yet.]

验证步骤规则

最小验证步骤应具体且成本低。

优先考虑以下步骤：

• 与五位已经尝试解决这个问题的目标用户交谈。
• 在开发软件前，请对方付费、预购、提供意向书或作出人工承诺。
• 围绕一个明确的狭窄承诺，开展落地页、候补名单、主动联系或人工代办测试。
• 自动化之前，先人工交付一次成果。
• 验证缺少的功能是否会阻碍付费、留存、激活，还是仅影响完整性。
• 在扩大范围前，找到一个能持续触达目标用户的渠道。

避免以下步骤：

• 先构建 MVP。
• 添加更多功能，看看会发生什么。
• 选择技术栈。
• 设计架构。
• 编写代码。
• 制定宽泛的产品路线图。

特殊情况

如果这个想法过于模糊，提出一个澄清问题：

Who is this for, what painful situation are they in, and how do they solve it today?

如果用户询问的是现有产品的一项功能，应重点判断该功能是否会实质阻碍付费、留存、激活、信任或交付。

如果用户表示项目是为了学习、作品集或兴趣，不要用创业标准来评判。重点应放在控制范围和明确学习成果上。

如果用户已经决定构建，且只需要实现方面的帮助，则不要使用此技能。

风格

直接、审慎且实用。

不要轻视用户。目的不是扼杀想法，而是让下一次构建决策更难自欺。