Spec 驱动开发：用验收标准替换模糊 Prompt

背景

把需求随口丢进 Agent——「把登录做好一点」「性能优化一下」——模型只能靠猜测补全意图。结果常见：改了实现、改了测试让它变绿，但真实用户流仍失败。Spec 驱动开发强调：先写可检查的规格与验收标准，再让编码助手在规格约束下改代码。

这与传统敏捷里的验收标准同源，只是在 Agent 时代更关键：模型擅长沙箱内迭代，却不擅长替你定义「什么叫完成」。规格越模糊，空转与假绿风险越高。

要点

规格元素	作用	例子
用户流	定义真实路径	打开页 → 填表 → 看到成功态
不变量	禁止破坏的行为	未登录不能写数据
验收命令	客观通过条件	pnpm test:e2e login
非目标	明确不做	本迭代不做 SSO

Definition of Done 应绑定 真实用户流或 E2E，而不是「单元测试全部通过」 alone——尤其当 Agent 有权改测试文件时。

怎么做

1. 先写一页 Spec：背景一句话、范围、非目标、验收列表（可勾选）、关键路径、错误态。
2. 把 Spec 当源文件：进 Git；Agent 的系统提示引用路径，而不是粘贴过时摘要。
3. 验收分层：静态检查 → 单测 → 关键路径 E2E；任何一层失败都算未完成。
4. 禁止偷偷改验收：规则文件写明「不得为了变绿而删除断言」；若必须改测试，PR 描述单独说明。
5. 用 Diff 做规格对齐：实现前后对比用户可见文案与状态机转移，而不只看覆盖率数字。

伪流程：

草稿 Spec → 评审验收列表 → Agent 按 Spec 实现 →
跑验收命令 → 失败则修代码（优先）而非改 Spec →
人工走一遍关键用户流 → 合并

正则与 JSON Schema 很适合把「输入约束」写死；Markdown 勾选列表适合人类可读的 DoD。两者一起用，比长散文 Prompt 稳。

和本站工具

• Markdown 预览：写 Spec / DoD 时即时预览。
• Diff：对比规格修订与实现差异。
• JSON：整理机器可读的验收清单。
• 正则：校验输入格式与路由模式。

入口：Tools 首页。

规格评审时建议固定三个问题：用户成功长什么样？失败时用户看到什么？哪些现有行为绝对不能坏？答不清就不要开工。Agent 会话开头粘贴规格锚点（文件路径 + 章节名），比粘贴整篇长文更稳，也便于规格演进后自动对齐。

若组织已有 issue 模板，把 DoD 勾选框嵌进去，构建脚本可解析勾选状态做门禁（未勾选则拒绝合并）。这样「测试变绿」不再是唯一绿灯；真实用户流与回归清单成为并列条件。长期看，规格仓库本身会成为比聊天记录更可靠的组织记忆。

最后提醒：规格不是一次性文档。产品变更时同步改 Spec 与测试，再让 Agent 跟规格走。顺序反了——先改代码再补规格——会重新滑回模糊 Prompt 时代。

小结

Spec 驱动的本质是 把完成定义外部化：可执行、可评审、可进 Git。Agent 负责在约束内搜索实现；人负责定义真实用户流与不可破坏的不变量。模糊 Prompt 省掉的五分钟，往往会在假绿里加倍还回来。