Spec-Driven Production

让产品、设计、研发和测试围绕同一套规格协作，从需求澄清走到有证据的交付。

将一个功能的目标、体验、实现、评审与验收串联起来。你可以从一句想法开始，也可以带着已有需求、设计稿或代码，只完成当前需要的阶段。

能力与价值

| 你遇到的问题 | Skill 如何帮助 | 得到什么 | | --- | --- | --- | | 需求模糊，范围反复变化 | 按首轮模板明确目标、非目标、场景、功能需求与验收标准 | 可讨论的需求基线，以及明确的待确认项 | | 设计意图与研发理解不一致 | 分开描述视觉交互与代码约束，核对状态、数据和接口是否衔接 | 职责清楚、相互引用的体验规格与研发规格 | | 评审意见零散，结论难追踪 | 从产品、设计、研发、测试视角核对方案，归并问题并记录依据 | 有位置、影响、责任和关闭证据的评审记录 | | 开发任务脱离需求，完成标准含糊 | 把任务连回需求编号、验收标准和工程条款 | 有依赖、完成条件与状态的任务清单 | | 需求变化后容易漏改 | 分析关联的体验、接口、任务与验证，只更新受影响部分 | 变更影响范围、待决事项和需要重新验证的内容 | | 文档写完却无法判断是否交付 | 区分方案、实现、测试证据与人工签收 | 可以追溯到具体规格和版本的验收记录 |

适合新功能规划、跨角色方案对齐、已有 Spec 评审、开发任务拆解、需求变更与交付验收。普通小修复不默认套用完整流程。

核心结构

三份规格定义约束，评审记录决策，任务和验收连接实际交付。

| 产出文档 | 主责角色 | 回答的问题 | | --- | --- | --- | | requirements-spec.md | 产品 | 为什么做、为谁做、做哪些、怎样算满足需求？ | | design-spec.md | 设计师 | 用户看到什么、如何操作、各种状态怎样反馈和恢复？ | | engineering-spec.md | 技术负责人 / 研发 | 架构和代码如何组织，数据、接口与工程约束是什么？ | | spec-review.md | 产品 / 设计 / 研发 / 测试 | 三份规格是否一致，哪些问题需要解决，实际结论是什么？ | | tasks.md | 研发，相关角色参与 | 先做什么、依赖什么、怎样验证一项任务完成？ | | verification.md | 测试，设计 / 研发 / 产品参与 | 需求、体验和工程约束是否满足，有什么实际证据？ |

需求 → 体验设计与研发规格（相互核对）→ 联合评审 → 任务与实现 → 验证与验收。

设计与研发规格并行完善：design-spec.md 专注视觉、交互与体验；架构、代码规范和接口契约写入 engineering-spec.md。评审引用规格正文，不再维护一套重复方案。需求编号 FR、验收编号 AC 和任务编号贯通各阶段，变更时同步关联内容。

默认产出目录为 specs/<feature-slug>/，已有项目沿用现有位置。按需创建文档；小功能的验收记录可合并进 tasks.md。一个人可以承担多个角色，使用本 Skill 不要求启动多个 Agent。

两个规定模板

首轮需求输入模板：保留 0–8 节，覆盖背景、目标与非目标、用户场景、范围、模块关系、功能需求、数据依赖和 Given / When / Then 验收标准。
Spec 评审模板：保留 0–6 节，覆盖需求回溯、设计方案、技术方案、接口契约、检查清单和真实评审记录。

使用方法

1. 提供目标、材料和本次范围

告诉 Agent：你要解决什么问题，当前有哪些需求、设计稿、代码或评审材料，以及这次需要交付到哪一步。已有资料直接复用；未明确的信息标记待确认。

2. 从当前阶段开始

安装完整技能包后，在支持 Skill 的 Agent 中选择本 Skill，或使用自然语言指定。可直接复制下面的示例并替换功能与材料位置。

从想法整理需求

使用 spec-driven-production。
我想给文章列表增加收藏功能，请按首轮模板整理需求。
本次只输出 requirements-spec.md 和待确认项，暂不开发。

分别补齐设计与研发方案

使用 spec-driven-production，读取已有需求和项目规范。
分别编写 design-spec.md 与 engineering-spec.md，
核对界面状态、失败恢复与接口支持；未验证的现有能力请标明。

检查现有方案

使用 spec-driven-production，从产品、设计、研发、测试视角评审这三份规格。
按规定模板输出 spec-review.md，列出问题、影响和建议。
没有真实团队结论时，保持待评审。

分析变更或推进实施

使用 spec-driven-production，分析“单文件上传改为批量上传”的影响。
先说明受影响的需求、体验、接口、任务和验收，暂不修改正式基线。

使用 spec-driven-production，依据已确认的规格版本拆解开发任务。
列明每项任务的依据、依赖和完成条件，本次交付 tasks.md。

3. 按证据继续推进

每次交付会说明当前阶段、已更新文件、待确认项及验证状态。需要修改时先更新对应规格，再同步评审、任务和验收。实际开发与测试需有相关项目文件、执行工具和用户授权。

运行条件与能力边界

核心文档流程不依赖 Python、Node.js、MCP、外部 API 或凭证；需要宿主能读取随包 Markdown、模板和用户材料。
有文件写入能力时保存到业务项目；否则按文件名交付 Markdown 并注明待保存。跨产品安装说明见 README。
AI 角色自检不等于团队批准；测试计划、模拟演示或已生成文档不等于真实验收通过。缺少证据的部分明确标为未验证。

Agent 执行入口

执行本 Skill 时，先读取工作流程与执行规则的通用约束与本次阶段。该指南保留需求模板填写、来源与版本、授权边界、评审状态和变更处理规则；不可仅依据上方介绍生成交付。

再按任务读取相应资源，不默认加载全部文件：

| 当前任务 | 所需材料 | | --- | --- | | 需求整理 | 工作流程第 1 节 + 首轮需求输入模板 | | 体验设计 | 设计规格规则；涉及交互时加体验行为指南 | | 研发方案 | 研发规格规则 + 可读的实际代码与项目约定 | | 联合评审 | 工作流程第 4 节 + Spec 评审模板 + 角色评审指南 + 三份规格正文 | | 任务、实现、验收或变更 | 执行与变更指南 + 相关规格、评审结论及实际证据 |

仅交付用户要求的阶段；原模板保持只读，未知事实不编造，沿用已有编号和版本。流程来源与定制边界见参考依据。