Back to Details

before-you-build

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Before You Build

动手构建前

Run a compact pre-mortem before implementation. The goal is not to block building; it is to identify the highest-risk assumption, the smallest validation step, and the build scope that should be delayed until evidence improves.
在启动实施前开展一次简洁的预演失败分析。我们的目标并非阻止构建，而是识别出风险最高的假设、最小化的验证步骤，以及应等待证据充分后再推进的构建范围。

When To Use

适用场景

Use this skill when a user asks to build or ship:
  • A new product, MVP, prototype, landing page, SaaS app, marketplace, content site, agent workflow, or internal tool
  • A major feature with unclear adoption, revenue, retention, trust, or distribution impact
  • A public launch asset where weak positioning could waste development or promotion effort
Skip this skill when the task is a narrow implementation fix, refactor, test repair, dependency update, or already-validated change with clear acceptance criteria.
当用户要求构建或发布以下内容时，可使用本技能：
  • 新产品、MVP、原型、落地页、SaaS应用、交易平台、内容网站、Agent工作流或内部工具
  • 对用户采用率、营收、留存、信任或获客影响不明的重要功能
  • 若定位模糊可能浪费开发或推广资源的公开发布资产
当任务为狭义的实施修复、重构、测试修复、依赖更新，或已有明确验收标准的已验证变更时，无需使用本技能。

Risk Checklist

风险检查清单

Review the idea across these risks:
  • Demand: Is there evidence that a specific buyer or user urgently wants this?
  • Positioning: Can the target user understand what it is and why it matters in one sentence?
  • Monetization: Is there a credible path to payment, budget, or strategic value?
  • Retention: Is there a reason users would return after the first try?
  • Trust: Does the product require credibility, data access, integrations, or behavior change that users may resist?
  • Distribution: Is there a repeatable way to reach the target user?
  • Feature adoption: For feature work, will the feature change user behavior or just add surface area?
If the verdict is not obvious, use 
references/risk-checklist.md
for deeper questions.
从以下维度评审创意：
  • 需求： 是否有证据表明特定买家或用户迫切需要该产品/功能？
  • 定位： 目标用户能否用一句话理解它是什么以及它的价值？
  • 变现： 是否存在可信的付费、预算支持或战略价值路径？
  • 留存： 用户首次使用后是否有理由再次回归？
  • 信任： 该产品是否需要用户信任、数据访问、集成或行为改变，而用户可能对此存在抵触？
  • 获客： 是否有可重复触达目标用户的方式？
  • 功能采用： 针对功能开发，该功能是否会改变用户行为，还是仅仅增加功能表面？
若结论不明确，可参考
references/risk-checklist.md
获取更深入的问题。

Output Format

输出格式

Keep the response short and decision-oriented:
  1. Risk verdict: Low, medium, or high risk, with one sentence explaining why.
  2. Main assumption: The single assumption most likely to break the project.
  3. Evidence to find first: The smallest useful signal before building more.
  4. Do next: One concrete validation step or reduced build scope.
  5. Delay: What not to build yet.
保持回复简洁且以决策为导向：
  1. 风险判定： 低、中或高风险，并用一句话解释原因。
  2. 核心假设： 最可能导致项目失败的单一假设。
  3. 优先验证证据： 在进一步构建前需获取的最小有效信号。
  4. 下一步行动： 一个具体的验证步骤或缩小后的构建范围。
  5. 暂缓事项： 目前不应构建的内容。

Guidance

指导原则

  • Be direct about weak evidence, but avoid dismissing the user's idea.
  • Prefer smaller validation steps over large research plans.
  • Separate product risk from engineering difficulty.
  • If the idea is already validated, say what evidence makes it lower risk and suggest the smallest implementation slice.
  • If facts are missing, name the missing evidence instead of inventing market claims.
  • 直接指出证据不足的问题，但避免否定用户的创意。
  • 优先选择小型验证步骤，而非大型研究计划。
  • 将产品风险与工程难度区分开。
  • 若创意已得到验证，说明哪些证据使其风险较低，并建议最小化的实施范围。
  • 若缺少事实依据，明确指出缺失的证据，而非编造市场主张。