Spec Kit 教程：规范驱动开发怎么做，Kiro 怎么选

目标不是多写文档，而是形成一份简短的共识：创始人能据此否定不符合预期的功能行为，工程师能质疑设计方案，评审者也能明确代码合并前需要哪些验证证据。

第一次尝试时，就在现有仓库里选一个边界清楚的小功能。数据导出、审批规则或通知偏好设置，都比让智能体为整个应用编写规范，更容易体现这套方法的价值。

什么是规范驱动开发？

在 AI 编程中，规范驱动开发是先评审一份对预期行为的描述，再用它指导方案设计、任务拆分、实现和验证。 规范说明“必须做什么、为什么做”；方案说明“现有应用怎样实现”；任务则把方案拆成可以逐项检查的工作。

在 AI 出现之前，相关的规范驱动实践就已经会把规范写成可执行测试，行为驱动开发就是一例。这种传统与本文的流程并不冲突，但一份 Markdown 规范本身并不是可执行测试。参见 Cucumber 的 BDD 文档。

如今的实际变化在于，编程智能体可以在整个实现过程中持续使用这些文档。GitHub Spec Kit 是为智能体工作提供结构的开源工具包，在现有智能体周围搭起流程；AWS 的编程环境 Kiro 则把规范工作流直接集成进产品。无论选哪一个，客户最终应该获得怎样的体验，仍然需要人来判断。

文档核验日期：2026 年 10 月 13 日。 下文的命令名称、文件路径和能力说明，均来自当时的 GitHub、Kiro、Anthropic 和 OpenAI 官方文档。文中的功能演练是示例，不代表已经在生产环境部署，也不是经过测量的生产力实验。

对开发者而言，这意味着缩小实现范围：智能体应复用功能周围已有的应用结构，而不是重新设计一遍。对运营负责人和创始人而言，最有价值的评审被提前了：先决定谁有权导出数据，再看导出按钮。对采购决策者而言，采用这套方法不等于让所有开发者换编辑器。先用现有智能体；等维护这些文档本身成了问题，再为更完善的流程支持付费。

Spec Kit 教程：先走通规范驱动开发流程

规范、方案、任务和验证材料要各自独立，因为它们回答的问题不同。架构图补不了缺失的产品规则，任务清单也不能证明功能已经可用。

功能行为由创始人或产品负责人拍板，设计是否适合现有系统由工程负责人把关。智能体可以起草两者，但文字写得流畅，并不能证明决策正确。

规范驱动开发工具怎么选？先看哪里需要协作

选择工具，要看协作在哪个环节出了问题。如果希望围绕现有智能体，在仓库中建立可重复执行的流程，可以用 GitHub Spec Kit。如果希望在编程环境里完成需求、设计和任务执行，可以考虑 Kiro。如果只是试做第一个功能，或者团队已经有可靠的评审习惯，普通文档文件就够用。

GitHub Spec Kit 教程：命令怎么用，文件看哪些？

GitHub Spec Kit 提供可复用的指令、模板和辅助脚本，实际工作由你选择的编程智能体完成。当前 README 明确列出了核心顺序：建立项目原则、定义功能、制定方案、拆分任务、实现，再检查是否还有遗漏。

当前 README 要求 Python 3.11 或更新版本、Python 包安装工具 uv，以及受支持的智能体。安装示例使用的是 GitHub 的编程助手 GitHub Copilot。在终端中执行：

uv tool install specify-cli
specify init my-project --integration copilot
cd my-project

随后在该目录启动编程智能体。各条工作流指令应在智能体的聊天界面中运行，每一步都先评审输出，再继续。它们不是 shell 命令。

命令的写法不能混用。README 使用 Copilot 默认的 skills 语法 /speckit-specify；详细命令参考使用点号形式 /speckit.specify；Codex 的 skills 集成则使用 $speckit-specify。请按所安装集成的语法输入，标点不能互换。参见集成参考文档。

这些名称和职责来自 GitHub 的 Agentic SDD 参考文档。Clarify、checklist 和 analyze 是额外的质量检查环节。Constitution 用来建立长期适用的项目规则，不必每做一个小功能就重写一次。

以导出功能为例，specify 指令应说明谁可以导出、哪些记录符合条件、文件包含什么，以及失败时如何处理。已有技术栈和仓库约束则交给 plan 阶段。务必明确要求生成验收测试：tasks 命令的文档说明，它会在用户提出要求时生成测试，因此仅有一份自动生成的任务清单，并不能证明其中已经包含合适的测试。

需要重点评审的文件包括：

• .specify/memory/constitution.md：项目原则。参见 Constitution 模板。
• specs/<feature-directory>/spec.md：功能行为。功能目录通常放在 specs/ 下，目录名由工具生成或通过配置指定。参见 Specify 模板。
• 功能目录中的 plan.md 和 tasks.md：实现设计与任务拆分。规划阶段还会生成 research.md、data-model.md 和 quickstart.md；涉及外部接口时，还会使用 contracts/。参见方案模板和任务参考文档。

实现完成后，converge 会将代码库与规范、方案和任务进行对照。如果发现缺口，它会把新增工作追加到 tasks.md，但不会自行修复代码。完成新增任务后，再检查一次。“Converged” 结果可以辅助评审，不能代替测试或人工批准。

对于已有应用，GitHub 的接入指南 要求先保留基线，再在原目录中初始化。命令是 specify init --here --force --integration <key>，其中 <key> 应替换为文档中的集成标识，例如 claude 或 codex。指南提醒，--force 可能覆盖存在冲突的受管理文件，因此要检查初始化后的差异。为应用的下一次改动编写规范，并不要求先为整个应用补齐规范。

局限： Spec Kit 能找出文档之间的矛盾，却仍可能接受一条在所有文档中都保持一致、但本身就是错的业务规则。只有当多个人或多次会话需要遵循同一份约定时，维护这些额外文件才值得。

Kiro 教程：分清 Specs、Steering 和 Hooks

Kiro 将功能意图、长期项目指导和自动操作分开处理：specs 用于当前功能，steering 用于整个仓库的约定，hooks 用于重复执行的检查。

在 Kiro 的代码编辑器 IDE 中，点击 Specs 下的 +，或在聊天中选择 Spec。接着选择 Feature，再选 Requirements-First。先评审需求，再接受技术设计和任务拆分。生成的功能目录中包含 .kiro/specs/<feature-name>/requirements.md、design.md 和 tasks.md。评审任务后，再从任务界面启动执行。参见 Kiro specs 文档。

Kiro 使用 EARS（Easy Approach to Requirements Syntax，即一种简明的需求表述语法）来描述触发条件及预期系统行为。对本文的示例，可以写成：“当普通成员请求导出时，系统应拒绝该请求，且不返回导出文件。”这样的表述足够具体，可以转化为测试。参见 Feature Specs 文档。

Kiro 还提供 Design-First 和 Quick Spec。Design-First 从技术设计开始；Quick Spec 则跳过中间的批准环节，直接生成相关文档。如果你是创始人，而智能体总是理解错意图，就选 Requirements-First，并认真做这些评审。省掉评审，也就省掉了流程中真正针对这一问题的部分。

Steering 通过 .kiro/steering/ 下的 Markdown 文件提供长期上下文。基础文件是 product.md、tech.md 和 structure.md，分别说明产品、技术栈和仓库组织。在 IDE 中使用 Generate Steering Docs 可以生成初始内容，随后要对照仓库核查。“复用现有成员身份授权策略”如果适用于多个功能，就应写在这里；“仅所有者可以导出”则应写进导出功能规范。参见 Steering 文档。

Hooks 会在事件发生时运行 shell 命令或智能体提示词。当前项目级 hook 文件位于 .kiro/hooks/<id>.json；PostFileSave 是文档中列出的触发事件之一。一个职责明确的 hook，可以在相关源文件变化时运行已有的导出测试。同时应把这些检查放进持续集成，也就是对待合并代码改动进行的自动检查中，避免测试只在本地 hook 中运行。Kiro 当前的能力表显示，IDE 和 CLI 支持 hooks，Web 和 Mobile 不支持。参见 Hooks 文档。

局限： 自动生成的需求，可能把从未有人批准的假设写成正式规则。进入设计前，应先评审权限、空结果和失败行为。规范模式能提供结构，却不能替你补上缺失的产品判断。

用 Claude Code 实践规范驱动开发

Anthropic 的编程智能体 Claude Code 可以配合功能规范和 Plan Mode 完成这套流程。想先试试这套方法，并不需要安装规范框架。

可以自己编写 specs/workspace-export/spec.md，也可以先让智能体起草，再由你评审。然后以规划模式启动终端会话：

claude --permission-mode plan

让 Claude 阅读该文件，检查已有代码中与导出相关的部分，并围绕验收标准提出实现方案。批准实现之前，要求它列出尚未解决的问题，以及准备执行的具体检查。

Plan Mode 用于调查情况和提出方案。Anthropic 文档也说明了一个例外：在可使用 bypass 权限的交互式终端会话中，规划模式的编辑阻止机制不会强制生效。如果希望批准环节真正起到约束作用，启动时就不要启用 bypass。参见权限模式文档。

评审提案后，将认可的方案保存到 specs/workspace-export/plan.md，将检查清单保存到 tasks.md，然后授权实现。这些路径是本文建议采用的约定，并不是 Plan Mode 承诺自动创建的文件。Claude Code Plan Mode 指南 介绍了相关控制方式，以及如何从规划切换到批准实现。

仓库中长期有效的指令应放在 CLAUDE.md，具体可参考团队记忆指南；仅针对某个功能的行为则放在该功能的规范里。否则，一项临时导出需求可能变成影响其他工作的长期指令。

局限： 只留在对话中的方案，很容易丢失，或在后续工作中被推翻。保存成文件也只是第一步，后续实现和评审还必须明确以它为依据。

Codex：让 Plan Mode 使用同一份规范

OpenAI 的编程智能体 Codex 也支持这种轻量交接方式。在空闲的 CLI 聊天会话中，输入 /plan 即可开始规划，也可以在命令后直接附上请求。参见官方命令文档。

可以这样提要求：“阅读 specs/workspace-export/spec.md。检查现有成员身份策略、任务查询和测试。提出满足所有需求的最小实现方案。在开始实现前，指出还缺哪些决策。”

评审方案、保存达成共识的文件，然后让 Codex 执行任务，并提交逐项对应需求与测试的完成报告。仓库的长期指令放在 AGENTS.md；可以用 /init 生成初始文件。Codex CLI 配置指南 介绍了初始环境的设置。

OpenAI 的文档也介绍了在较长任务中用 Markdown 保存规范、方案和进度的做法。关键价值在于，后续会话可以重新打开同一份约定。局限： Plan Mode 不会自动维护独立的功能规范；更新规范应成为改动评审的一部分。参见 OpenAI 文档中的工作流。

规范驱动开发示例：工作区 CSV 导出

一个小型 CSV 导出功能，也就是把记录下载为逗号分隔值文件，就能说明：先确定行为，为什么能减少多个文件之间的返工。只说“加一个 CSV 导出”，等于让智能体自行猜测用户角色、数据范围、分页方式和文件格式。按钮再漂亮，也可能掩盖这些问题上的所有错误决定。

下面以一个已有的任务管理应用为例，走完这套流程。文中的路径、需求编号和建议测试都是教学示例，不代表本文已经在某个仓库中测试或合并了这些改动。

先写一页功能规范

将以下内容保存为该功能的 spec.md，或把同样的行为要求写入 Kiro 的 requirements.md：

注意 R2 中容易被忽视的决策：“所有匹配结果”和“当前可见页面”并不是一回事。在实现前明确这一点，查询方案和测试计划就会随之调整；等演示后再明确，两者可能都得重做。

R4 刻意指出了一项必须用具体示例来确定的决策。批准规范之前，要敲定如何处理电子表格公式输入，并记录相应示例。如果只写一句“确保导出安全”，就等于让智能体替你选择策略。

制定方案：接入已有应用

方案应复用现有会话与成员身份策略，抽取或复用任务列表的筛选逻辑，并在不改动列表响应的前提下新增导出响应。导出请求必须经过服务器端的授权检查。先根据已认证的成员身份确定可访问的工作区，再在这个范围内应用请求中的筛选条件。

如果仓库已有 CSV 序列化工具，就沿用它。写明内容与下载相关的响应头、字段安全策略、错误行为和测试方案。导出按钮也应使用应用现有的加载状态与错误状态。

方案还必须将预期结果规模与应用已有的请求和内存限制进行对照。如果无法在这些限制内导出全部结果，就把冲突交回功能负责人决定：是限制导出范围，还是另行界定后台处理的工作范围。智能体不应擅自编造数量上限，也不应违反 R6，自行加入任务系统。

拆分任务：每项改动都能验收

把方案转成评审者能辨认、能检查的工作：

1. 用回归检查固定现有任务列表行为和共用筛选规则。
2. 增加请求授权测试，覆盖所有者、普通成员、已被移除的所有者以及跨工作区访问。
3. 按约定的字段策略，实现有明确数据范围的查询和 CSV 响应。
4. 增加导出控件、加载状态和失败提示。
5. 完成验收检查，并检查代码差异中是否混入本功能范围外的改动。

这只是本示例的一种任务拆法。工具包可能生成不同清单；判断标准应是它是否覆盖了已达成共识的要求。

对于 TypeScript 应用，可供评审的代码改动可能包括：在 server/exports/tasks.ts 中处理授权、筛选和响应；在 ui/tasks/ExportButton.tsx 中实现交互；在 tests/task-export.test.ts 中编写验收用例。这些只是示例路径，并非框架强制约定。如果改动中出现新的队列 worker 或数据库迁移，就说明范围发生了变化，需要在合并前解决。

用验收证据决定是否合并

需要的是功能行为的证据，而不只是智能体修改过哪些文件。拉取请求说明应将需求与具体检查对应起来，例如：

评审者应对照规范检查这些验证项，阅读授权和查询代码，并在项目正常的评审环境中走一遍约定的用户流程。如果实现和测试都由同一个智能体编写，还要独立审视测试的预期结果。测试也可能只是忠实验证了代码中同一个错误假设。

例如，评审发现接口只读取当前页。如果功能负责人仍然要求导出全部匹配结果，就保留 R2、修正查询，并增加一个当前页之外仍有匹配记录的测试。如果负责人决定修改范围，就在批准之前同步更新 R2、方案和测试。

证据与约定一致时，再合并功能： 将评审后的规范、最终方案、已完成的任务记录、实现和测试放在同一个拉取请求中。任何已接受的范围调整，也记录在这里。合并后，要么把规范维护为现行约定，要么明确标记为历史功能记录。旧规范如果看起来仍然有效，就会埋下下一轮混乱。

真正的收益，是在权限和分页的假设扩散到实现各处之前，先把它们确定下来。合并后，规范、测试和代码保存的也就是同一个决定。

成本怎么算，什么时候值得？

这套方法的成本包括评审和维护时间，以及智能体起草文档、编写实现所产生的用量。Spec Kit 虽然开源，但接入的编程智能体仍有自己的使用条款。普通 Markdown 文件不会增加单独的规范工具订阅费，却也不会让模型调用免费。

Kiro 的标准商业定价中，Free 为每月 $0，含 50 credits；Pro 为每用户每月 $20，含 1,000 credits，均未计适用税费。因此，四份 Pro 订阅的费用是 4 × $20 = $80 每月，还不包含额外 credits 和税费。这只是席位费用的计算，不是在预测能交付多少功能。参见 Kiro 官方定价页。

付费增购的 credits 为每个 $0.04。Kiro 说明，规范细化、任务执行和智能体 hook 执行都会消耗 credits；复杂的规范任务可能消耗不止一个 credit。如果不观察实际工作负载，就无法有依据地把 credits 换算成“完成的功能数”。参见 Kiro credits 说明。

判断是否划算，标准很直接：编写规范、评审和维护功能增加的成本，必须低于它所避免的返工成本。应在自己的流程中记录这些成本。如果只是多了文档，关键决策仍然拖到代码评审时才做，这些额外工作就没有体现价值。

哪些承诺被夸大了，哪些场景没必要用？

被夸大的承诺是：只要文档足够详细，智能体就能稳定做对。事实并非如此。规范本身可能有错，实现可能无视规范，测试也可能重复其中的错误假设。

真正要分清的是写明意图与落实行为约束。需求写着“普通成员不能导出”，服务器端检查及其测试才有助于落实这条规则。需求检查清单检查的是描述，并不会运行应用。把两者混为一谈，只会带来虚假的把握。

另一种常见问题是文档与实现脱节。开发者如果改了权限行为却只更新代码，下一个智能体可能会按照过时规范，把应用“修复”回去。行为发生变化时，应同步更新相关约定，或明确将其归档。长期上下文只有保持准确才有帮助。

现在就可以用：如果智能体反复遗漏权限、边界情况、集成要求或验收标准，就选一个歧义会影响多个组件或多位评审者的功能，试用这套流程。

先别急着写正式规范：如果还在验证是否有人需要这个功能，就先做一个用完可丢弃的原型，或调查未知问题。为未经验证的想法写出一份精美规范，可能让错误的投入看起来已经有了定论。

小改动就按小改动处理：如果目标明确、影响局部，例如修正错别字、按既有风格调整样式，或修复一个有明确回归测试的小缺陷，只需说明预期行为并验证。完整走一遍 constitution、方案和任务流程，可能比改动本身更耗费精力。

判断依据不是代码行数，而是：如果没有规范，智能体需要自行做出多少个影响重大的假设。

第一周怎么开始规范驱动开发？

从待办列表中选一个小功能，让功能负责人批准一页行为规范，其中包括不做什么，以及失败时怎么办。用现有智能体的规划模式，或对应的 Spec Kit、Kiro 流程，提出一份基于实际仓库的方案。

实现前先评审问题清单，再要求任务清单与需求逐项关联。到了拉取请求阶段，仍按同一份约定检查证据，并记录发生变化的决策。流程做到多细，应取决于有多少歧义需要消除。

订阅通讯，了解用 AI 构建产品和开展运营的实用方法。