Spec-First AI 工作流

Spec Skills 在 Spec-First 工作流中的用法

Spec Skills 更适合作为受约束的规格草拟与评审工作台，而不是一个泛聊天入口。给它工单、模板和评审规则，期待它输出规格草稿、验收标准、风险和待确认问题，再交给人做批准或驳回。

使用场景：先结构化，再实现

1. 应该放在哪一步

  • 实现前：工单还存在歧义时。
  • PR 前：AI 生成代码需要证据时。
  • API 发布前：消费者需要清晰契约时。
  • 事故后：团队需要定位规格缺口时。

2. 应该给它哪些输入

  • 原始工单或 PRD 片段。
  • 输出必须遵守的模板字段。
  • 已知非目标、依赖方和责任人。
  • 涉及契约时，补充 API 或 schema 片段。

3. 哪些输出值得保留

  • 带明确待确认问题的规格草稿。
  • Given/When/Then 格式的验收标准。
  • 包含责任人、影响、缓解措施的风险登记。
  • 与发布证据绑定的评审清单。

4. 人工复核边界

  • Spec Skills 可以起草，但不能批准范围。
  • 它可以提出风险，但责任人仍需接受或驳回。
  • 它可以总结契约差异，兼容性仍由工程判断。
  • 它可以提出测试思路，失败证据仍应阻断发布。

5. 什么时候不该用

  • 产品责任人还没确定时。
  • 输入包含密钥、生产令牌或敏感数据时。
  • 团队想跳过评审直接批准时。
  • 任务足够小，用短清单即可解决时。

6. 采用前测试

连续两周观察三个信号：澄清评论是否减少，验收测试是否更早成形，PR 评审是否少出现意外问题。如果没有改善，先收窄工作流，不要扩大自动化范围。

实际工作流

从工单到可评审规格

好的 Spec Skills 工作流从一个边界清楚的产物开始，以可被评论的规格结束。输出不应该是一篇漂亮文章，而应该是包含决策、假设、缺失输入和测试点的草稿。

输入：
- 工单：“为 workspace 管理员增加批量禁用用户”
- 模板：feature-spec.md
- 必填章节：目标、非目标、角色、API 行为、审计日志、回滚、验收标准

期望输出：
- 标出未决问题的规格草稿
- 8-12 条 Given/When/Then 验收标准
- 权限误用、部分失败、审计缺口的风险登记
- 产品、后端、QA、支持四类评审清单
阅读工作流指南 使用评审清单

编辑说明：本页只说明 Spec Coding 会如何把 Spec Skills 放进 Spec-First 交付流程。正式采用前，请根据你的团队流程改写这些模式。

1 先选择一个有边界的工作流。
4 产品、工程、QA、支持四类评审角色。
0 不允许绕过人工复核自动批准。

1. Prompt 边界

  • 明确 Spec Skills 可以使用哪些来源材料。
  • 禁止编造需求和隐藏实现选择。
  • 要求所有假设进入“待确认问题”。
  • 输出必须遵守团队已有评审模板。

2. 可评审输出

  • 规格：目标、非目标、决策、API/数据影响。
  • 验收标准：主流程、失败流程、边界流程。
  • 风险登记：责任人、缓解措施、证据、回滚触发器。
  • 问题清单：实现前必须回答的阻塞项。

3. 团队控制点

  • 把批准过的 prompt 存到仓库。
  • 规格保留 Markdown，避免被工具锁死。
  • AI 生成代码必须附 PR 证据。
  • 记录每份草稿来自哪个 prompt 版本。

4. 采用判断

只有当 Spec Skills 改善了评审真正需要的产物时，才值得纳入流程。如果团队只是得到更多文字，而不是更清楚的决策，说明工作流太宽了。先缩小到一个可重复交接点，再衡量评审意见是否变得更具体。

有用的问题不是草稿听起来好不好，而是另一个工程师能不能少问几轮澄清就开始实现。

采用前检查清单

先选一个工作流：工单转规格、API diff 转评审意见、事故转复盘草稿，或验收标准重写。不要第一天就自动化整个交付流程。

两周后应该衡量什么

看规格是否少了澄清评论，QA 是否更早写出测试，AI 生成 PR 是否带证据，评审者是否能在实现前发现遗漏风险。

什么时候应该暂停

当输出开始编造需求、隐藏未决问题、绕过产品或安全评审，或无法追溯到 prompt 与源材料时，应暂停采用。

来源门禁

运行工作流前，先列出 Spec Skills 可以使用的来源材料：工单链接、产品说明、现有规格、API schema、错误表或事故时间线。任何不在来源材料里的要求，都应该被标成假设，而不是写成已批准范围。

输出门禁

接受草稿前，检查每个章节是否对应一个评审动作。产品能否批准范围，工程能否检查 API 或数据行为，QA 能否直接写测试，支持团队能否看懂用户可见失败状态。

发布门禁

AI 生成代码上线前，必须把证据接回规格：测试通过、API diff 已评审、迁移回滚已说明、功能开关状态明确，并且有能证明上线后健康的指标或告警。

Spec Skills 能替代技术规格吗？

不能。它可以起草和批注规格，但被批准的产物仍需要人工责任人、版本历史和测试证据。

第一个工作流应该选什么？

建议从工单转规格开始。输入清楚、输出可见、评审问题明确，团队能很快判断质量是否真的提升。

怎样避免输出变成通用套话？

要求引用源材料、列出假设、给出具体例子，并对“快速”“稳健”“简单”“顺滑”这类词做二次驳回。

什么时候不应该继续扩大使用范围？

当一个小流程还无法稳定产出可评审结果时，不要继续接入更多系统。先修输入模板、复核规则和证据要求。

团队最容易漏掉什么？

最容易漏掉复核和回滚：谁检查输出，出错时如何恢复，日志是否足够定位问题。这些问题比模型能力本身更影响长期使用。

带着规格边界使用 Spec Skills

把 Spec Skills 和可复用模板、评审清单一起用，才能让 AI 输出贴近团队真正需要批准的决策。

打开功能规格模板 阅读 Spec Skills 指南

备注：Spec Skills 是 Spec Coding 的工作流视角，不构成第三方产品功能承诺。

最近更新：2026 年 4 月 28 日