什么是 Spec-First 开发？（完整指南）

Source: Dev.to

1. 为什么团队常常做错

当不止一个角色依赖答案时，问题就出现了。
产品想要速度，工程想要边界，QA 想要可测试性，运维想要能够在不即兴的情况下回滚的方案。如果规范从未解决这些张力，工作就会在下游以返工的形式出现。

规范‑优先背后的真正决策是 所有权。谁批准边界？谁验证验收标准？谁可以阻止上线？如果这些答案没有以书面形式确定，团队就会在模糊的责任下交付。

2. 一个具体的交付情境

用一个真实的交付路径来检验你的规范。思考：

• 审核者可以 拒绝 什么？
• 测试人员可以 验证 什么？
• 运维人员可以 回滚 什么？

如果文档无法回答这三个维度，它就还没有准备好。不要再问团队是否“理解这个想法”，而是要问书面的规范是否能在交接时经受考验。

3. 规范需要大声说出的内容

更强的规范并不是偶然变长——它在项目容易漂移的地方变得更明确。最低要求包括：

• 预期结果、明确的 非目标，以及范围变更的决策所有者
• 可以在没有部落知识的情况下判断 通过或失败 的验收标准
• 失败行为、回退路径，以及发布后哪些日志或指标会呈现这些信息

4. 消除猜测的验收标准

Given the approved scope and dependencies
When the team executes the primary flow
Then success can be verified with a concrete result and observable evidence

Given an exception, retry, or permission boundary is hit
When the system takes the fallback path
Then the user‑facing behavior and operational response remain explicit

目标不是强迫每个团队使用相同的措辞，而是迫使在仍有时间廉价改道时，对 输入、触发条件和预期行为 做出决策。

5. 实施前的审查问题

• 对于第一次看到变更的审阅者，哪项决策仍然 模糊？
• QA 能否在不采访作者的情况下推导出主流程、失败路径和回归案例？
• 如果发布失败，文档是否告诉运维该监控什么以及何时停止？

如果你必须进行侧面对话才能回答这些问题，草稿仍然携带未定价的未知风险。

6. 上线、监控与回滚

好的规范不会止步于合并准备就绪。它们告诉团队如何安全发布：

• 首先面向 最小有用受众 做分阶段发布——不要把审查批准当作运行时证据的替代品
• 在发布前设定 止损阈值：错误率、延迟、数据不匹配或覆盖量
• 记录回滚的实际含义：代码回退、配置切换、任务暂停或数据修复

7. 常见错误

• 把范围视为显而易见，而把真正的策略决策留给实现评审
• 用模糊的词汇如 reasonable、friendly 或 handled elsewhere 隐藏风险边缘行为
• 发布看似完整的文档，却从未说明成功或回滚如何评判

8. 何时深入，何时保持轻量

恰当的细节量是能够防止后期昂贵发明的量。如果缺少的一句话会迫使工程、QA 或运维去猜测——那句话就应该写进规范。

关键不在于文档的长度，而在于文档是否能阻止团队在实现、测试和发布评审时重新发现同样的决策。

9. 最后收获

规范‑优先开发在规范足够早地指出风险决策并让人能够挑战时会变得更容易。这就是其实用价值：减少即兴发挥，降低审查时的惊喜，并在交付时提供更清晰的证据。