从模糊需求到可验证行为#

直接把一句需求交给 AI，通常会留下许多未决问题：边界条件是什么、接口如何变化、旧用户是否兼容、失败时如何处理、验收标准又是什么。

以“为登录系统加入二次验证”为例，规格不应止步于功能名称，而应描述可观察行为：

1
Requirement:
2
已开启二次验证的用户，必须完成第二因素验证后才能登录。
3

4
Scenario:
5
WHEN 用户提交正确的用户名和密码
6
AND 该用户已开启二次验证
7
THEN 系统要求输入一次性验证码
8
AND 验证通过后才返回登录会话

Spec 不是愿望清单

好的规格要写清行为、边界和场景，并能转化为验收测试。它约束的是结果，而非单纯罗列实现方式。

一个可复用的工作流#

1
Intent → Specification → Design / Plan → Implementation → Verification

这里最容易混淆的是 Plan 和 Spec：Plan 是完成当前改动的临时执行路线；Spec 是系统行为的长期描述。前者回答“怎么做”，后者回答“应该做成什么样”。

规格应该包含什么#

一份轻量但有效的 Spec 通常覆盖以下内容：

1. 范围与非目标：本次要做什么，明确不做什么。
2. 用户可观察的行为：正常路径、错误路径和边界条件。
3. 兼容性约束：已有接口、数据和用户流程是否受影响。
4. 验收方式：哪些自动化测试、手工步骤或指标能证明完成。

先写最小规格

不需要为每个小改动写长文档。先列出能消除关键歧义的场景与验收条件；复杂需求再逐步补充分支和设计决策。

工具与方法论的分工#

在 AI 编程工作流中，规格管理工具和 Agent 工作流框架常被一起使用，但职责不同：

例如 OpenSpec 一类工具适合沉淀“当前系统行为”和“待合并变更”；Superpowers 一类工作流适合规范 brainstorm、计划、TDD、评审与验证。它们可以组合，但都不能代替对需求本身的判断。

练习方式#

下一次让 AI 修改代码前，先写下三件事：

1
1. 用户最终能看到什么变化？
2
2. 哪些旧行为必须保持不变？
3
3. 用什么证据确认它真的完成了？

这三问足以将多数模糊 Prompt 转化为可执行的规格，也是开始实践 Spec Coding 最小、最有价值的一步。