构建之前

before-you-build

分类编程

作者Agentic Awesome Skills 社区

许可MIT

评分4.40/5

使用10.0K

Before You Build (构建前思考)

概述

Before You Build 旨在让 AI 编码工作流在进入实现阶段前暂停，检查该功能、产品或工具是否值得构建。它关注的是产品风险而非代码结构：谁需要这个东西，他们目前使用什么，为什么会切换，分发渠道如何，以及什么样的证据能让项目启动变得更安全。

该上游项目提供了一个独立的技能仓库，以及适用于多种编码助手的 npx 安装程序。

何时使用此技能

当用户要求 AI 编码助手构建新应用、功能、内部工具、SaaS 或侧边项目时。

当想法听起来可行，但买家、工作流、分发路径或切换理由仍然模糊时。

在编写代码之前使用，以便助手将请求转化为更明确的假设、风险检查和验证步骤。

工作原理

第一步：识别构建赌注 (Build Bet)

用一句具体的话重新陈述该产品或功能。明确目标用户、他们试图完成的任务，以及目前的替代方案或竞争对手。

第二步：检查主要风险

从需求、工作流适配度、切换意愿、分发、定价、数据访问和运维负担等方面审查该想法。倾向于提出具体的质疑，而非泛泛的头脑风暴。

第三步：决定下一个微小测试

在实现之前，建议一个最小且有用的验证步骤。这可以是与买家的对话、落地页测试、手动礼宾服务工作流、原型、候补名单、付费试点或小范围内部试用。

第四步：继续或停止

如果风险可控，则在记录假设的前提下进入实现阶段。如果风险较高或证据不足，建议进行小型实验而非构建完整版本。

示例

示例 1：SaaS 功能请求

text

用户：构建一个 AI 趋势监控仪表盘。
编码前检查：
哪个角色每周需要这个仪表盘？

他们目前使用什么来源？

因为这个仪表盘，什么样的决策会发生改变？

他们会为提醒、报告或工作流集成付费吗？

能够证明重复使用需求的最小手动报告是什么？

示例 2：内部工具

text

用户：为我们的小团队构建一个内部 CRM。
编码前检查：
当前的电子表格或现有 CRM 在哪里出了问题？

每天会有多少人使用？

哪些数据必须导入或保持同步？

上线后需要进行什么样的流程变更？

能否先用无代码工作流证明需求？

最佳实践

✅ 在实现前询问用户、任务、当前替代方案和切换理由。

✅ 将产品风险与工程风险分开，避免团队“高效地解决了错误的问题”。

✅ 当想法缺乏需求证据时，推荐小规模验证步骤。

✅ 确保产品名称、数字和主张基于用户提供的信息。

❌ 不要将泛泛的检查清单作为想法已验证的证明。

❌ 不要凭空捏造 (fabr... [此处原文截断])

市场规模、营收、竞争对手进展或买家报价。

局限性

本技能不能替代客户调研、法律审查、财务建议或领域专家评审。

它本身无法证明需求；其作用是帮助助手挖掘假设，并选择一个更小的验证步骤。

如果用户已拥有强有力的证据和清晰的规格说明，请保持评审简短并直接进入实施阶段。

安全与保障注意事项

本技能作为规划层运行是安全的，因为它不需要凭据、外部网络访问或文件变更。

如果与安装程序或仓库获取功能配合使用，请仅从您信任的上游仓库或 npm 包进行安装。

常见误区

问题： 助手只是重复产品推介，而没有挑战其假设。

解决方案： 询问当前的替代方案、切换触发点，以及在编写代码之前的验证步骤。

问题： 评审过于宽泛，阻碍了进度。

解决方案： 挑选风险最高的假设，并首先仅对其进行测试。

问题： 即使是一个小型内部工作流，也被当作初创公司项目来对待。

解决方案： 根据项目规模调整风险评审，仅询问那些会影响构建决策的问题。