第 2 章 Spec Kit 到底是什么？

上一章结尾我们给失控的短链接项目开了一张药方，意图要持久化，What 和 How 要分开，歧义要在动手前问出来，验收要先于代码存在，实现过程要能持续对照原始意图。这一章把药方落到一个具体工具上。Spec Kit 是 GitHub 在 2025 年开源的规格驱动开发工具包，2026 年 8 月发布了 1.0.0，本章基于 1.0.x 版本写作，它的命令和目录结构在小版本之间仍可能调整，跟着你手上的版本对一遍即可。

这一章要回答四个问题，SDD 这个方法论到底主张什么，Spec Kit 在其中扮演什么角色，它由哪几部分组成，以及初始化之后你的项目里会多出什么。后半章会把安装、初始化和完整工作流实际走一遍，让后续章节用到的每个文件和命令都先有个落点。

一、Spec-Driven Development 的核心思想

Spec Kit 的官方文档把 SDD 的核心称为一次"权力反转"（power inversion）。过去几十年，代码是王，规格是脚手架，PRD 写完用来指导开发，设计文档画完用来对齐理解，然后代码一动身，这些东西很快掉队，再也追不上。资产和实现是同一个东西，你没法拿着一份掉队的文档重新生成系统，只能继续在代码上改。SDD 把这个关系倒过来，规格成为主要产物和真相来源，代码退居为规格在某个语言、某个框架下的一次具体表达。

"代码服务于规格"这句话听起来像口号，它真正的技术含义是，规格和实现之间不再有需要人手工填补的鸿沟，只有一次又一次的转换。规格足够精确、完整、无歧义之后，实现可以被生成，也可以被重新生成。维护软件变成了演进规格，修 bug 首先是修那份生成了错误代码的规格，重构变成了把规格重新组织得更清楚。开发团队的精力从逐行翻译需求，上移到意图、取舍和批判性思考。

这里有一个容易被忽略的前提，规格必须是"可执行的"。传统 PRD 之所以掉队，不是因为团队懒，而是因为文档和代码之间没有机械联系，文档再正确也无法约束代码，同步全靠人自觉。可执行规格的意思是，它的结构精确到 AI Agent 可以直接消费，用户故事映射成接口，验收场景映射成测试，技术约束映射成实现时必须通过的检查项。规格不只是被阅读，它驱动生成，也反过来驱动验证。这也是为什么 SDD 在今天才成立，不是因为规格这个想法是新的，而是因为自然语言规格到可运行代码之间的翻译成本，第一次被 AI 压到了接近零。

同时要把上一章提过的边界再钉一遍。SDD 不保证规格正确，人照样会写出错误的、自相矛盾的规格，它保证的是错误从埋在代码里变成摆在纸面上，可以审查，可以回归，可以在生成下一层产物之前被拦住。Spec Kit 提供的是让这套思想落地的结构和工具，不是正确性本身。

二、Spec Kit 的定位与适用场景

理解了 SDD，再看 Spec Kit 是什么就很直接了。它是 SDD 方法论的一个开源实现，由三样东西组成，一个叫 specify 的命令行工具，一套随项目落地的 Markdown 模板和脚本，以及一组安装到你正在用的 AI Coding Agent 里的命令。它本身不是 AI，不调用模型，不生成代码，生成动作全部由你的 Agent 完成，Spec Kit 负责的是规定生成的顺序、每一步的输入输出、产物存放的位置，以及产物之间互相核对的规则。

这个定位决定了它的两个关键特性。第一，Agent 无关，官方支持的集成有四十种左右，Claude Code、GitHub Copilot、Gemini CLI、Codex、Cursor、Cline、opencode 都在列表里，甚至有一个 generic 集成可以接入任何支持自定义命令的 Agent。规格产物是普通的 Markdown 文件，不绑定任何一家模型，今天用一个 Agent 生成，明天换一个 Agent 接着做，读的是同一套文件。第二，它工作在仓库内部而不是云端服务，初始化之后，所有规格、计划、任务都在你自己的项目目录里，跟着 Git 走，可以评审、可以分支、可以合并，规格的评审和代码评审用的是同一套机制。

适用场景上，它最适合的是需求需要跨多次会话、多个参与者才能完成的功能。一个功能要做几天，中间会开新会话，会有同事接手，会经历需求澄清和方案评审，这种情况下持久化的规格收益最大。反过来，改个错别字、调个配置项这种一次性改动，跑完整流程纯属负担，Spec Kit 官方也提供了轻量用法，第 15 章会专门讨论什么项目不值得跑完整流程。

还有一点要提前说清楚，Spec Kit 不替代 PRD 评审、技术评审这些人的活动，它替代的是这些活动产出物的载体和它们之间的同步成本。产品决定仍然要人做，它只是确保"过期链接能不能跳转"这种问题在写代码之前被某个人明确回答过，而不是被模型在生成时静默填掉。

三、CLI、模板与 AI Coding Agent 的关系

第一次接触 Spec Kit 的人最容易混淆的是它的三层结构，因为安装之后你几乎不直接碰 CLI，每天在用的是 Agent 里的斜杠命令。这三层各管一件事，拆开看就清楚了。

CLI 是 specify 命令，由 Python 包 specify-cli 提供，它只在少数几个时刻出场，初始化项目、管理集成、安装扩展和预设、升级自身。它是一次性的脚手架工具和包管理器，不参与日常的规格写作。初始化完成之后，你可以几周不再运行它。

模板和脚本位于项目的 .specify/ 目录，是整个机制的固定装置。模板是五个 Markdown 骨架，规格、项目原则、计划、任务、检查清单各一份，定义了每类产物必须回答哪些问题。脚本是 PowerShell、Bash 和 Python 三套等价实现，负责创建功能目录、解析模板路径、准备计划和任务阶段的文件结构。这些脚本不调用模型，只做确定性的文件操作，所以同一条命令在任何 Agent 里产出的目录结构都一样。

第三层是 Agent 命令，也就是 /speckit.specify、/speckit.plan 这一组斜杠命令。初始化时 CLI 会按照你选择的集成，把对应的命令定义文件写进 Agent 的约定目录，比如 Copilot 对应 .github/skills/，Claude Code 对应 .claude/skills/。每个命令本质上是一份给 Agent 的详细指令，告诉它这一步读哪些文件、套用哪个模板、产出什么、不能做什么。你在对话框里敲下命令，Agent 读取指令，调用 .specify/scripts/ 里的脚本建好文件，再按照模板把内容生成出来。

三者的关系可以这样概括，CLI 把模板、脚本和 Agent 命令装进项目，模板约束产物的结构，脚本保证文件操作确定可复现，Agent 命令把模型的一次自由生成约束成流程中的一个固定环节。模型负责理解和写作，Spec Kit 负责流程和位置，这也解释了它为什么能做到 Agent 无关，所有 Agent 特定的东西只有那一层命令定义，核心的模板和脚本是共用的。

四、安装并初始化 Spec Kit

下面实际走一遍安装和初始化。Spec Kit 的运行环境只需要 Python 生态的 uv 和一个你日常使用的 AI Coding Agent，uv 是 Astral 出品的 Python 包管理器，安装方式见其官方文档。装好 uv 之后，官方推荐从 GitHub 的发布标签安装，把下面的版本号换成 Releases 页面上最新的标签，注意保留开头的 v。

powershell 复制代码

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v1.0.6

不指定版本、直接从 PyPI 安装也行，PyPI 上的 specify-cli 包由官方同步发布，适合不想追踪标签的读者。本书的命令输出来自这种方式安装的 1.0.6。

powershell 复制代码

uv tool install specify-cli
specify --version

uv tool install 会把 specify 命令装到用户级的工具目录里，不需要虚拟环境，也不污染系统 Python。装完用 specify --version 验证，能打印出版本号就说明 PATH 已经配好。如果将来要升级，CLI 自带自管理命令，specify self check 只读地检查是否有新版本，specify self upgrade --dry-run 预览升级动作，确认后用 specify self upgrade 原地升级。

初始化在你放项目的父目录里执行，--integration 指定要接入的 Agent。

powershell 复制代码

specify init shortlink --integration copilot
cd shortlink

交互式终端里不加参数也可以，CLI 会弹出选择器让你挑集成。如果是在 CI 或者某些无法发送方向键的 Agent 终端里，加上 --non-interactive 让它永远使用默认值而不是挂起等待。已有的非空目录要用 --here --force 初始化，这是第 11 章接入存量代码库的入口，这里先记住有这个选项。初始化过程不需要联网，模板和脚本都打包在 CLI 包里，装出来的文件与 CLI 版本严格对应。

初始化结束时终端会打印一份命令速览，分成核心命令和增强命令两组。这个时候项目目录里还没有任何业务代码，只有 Spec Kit 自己的骨架，下一节我们逐个看这些文件是什么。

五、初始化后的项目结构

以 Copilot 集成为例，初始化之后目录里有两个顶层目录，.specify/ 和 .github/。如果选的是 Claude Code，第二个目录会换成 .claude/，其余结构完全相同。下面是一份按功能整理过的结构，省略了文件内部的细节。

text 复制代码

shortlink/
├── .specify/
│   ├── memory/
│   │   ├── constitution.md            # 项目原则，初始是待填写的占位模板
│   │   └── .constitution-template.json
│   ├── templates/                     # 五类产物的 Markdown 模板
│   │   ├── constitution-template.md
│   │   ├── spec-template.md
│   │   ├── plan-template.md
│   │   ├── tasks-template.md
│   │   └── checklist-template.md
│   ├── scripts/
│   │   └── powershell/                # 按平台只装一套，包内另有 bash、python 等价实现
│   │       ├── check-prerequisites.ps1
│   │       ├── create-new-feature.ps1
│   │       ├── resolve-template.ps1
│   │       ├── setup-plan.ps1
│   │       └── setup-tasks.ps1
│   ├── workflows/                     # 可编排的自动化工作流
│   ├── integrations/                  # 集成清单
│   ├── init-options.json              # 本次初始化的全部选项
│   ├── integration.json               # 已安装集成的状态
│   └── .gitignore
└── .github/
    └── skills/                        # Copilot 的命令定义，十个技能
        ├── speckit-constitution/SKILL.md
        ├── speckit-specify/SKILL.md
        ├── speckit-clarify/SKILL.md
        ├── speckit-plan/SKILL.md
        ├── speckit-tasks/SKILL.md
        ├── speckit-analyze/SKILL.md
        ├── speckit-implement/SKILL.md
        ├── speckit-converge/SKILL.md
        ├── speckit-checklist/SKILL.md
        └── speckit-taskstoissues/SKILL.md

.specify/memory/constitution.md 是项目原则的落点，初始化时它还是一份带占位符的模板，等第一次运行 /speckit.constitution 时由 Agent 和你一起填实。它是唯一跨功能共享的产物，后面每个功能的技术计划都要对照它做合规检查，第 4 章专门讲它。

templates/ 里的五份模板是这套机制里约束最硬的部分。它们不是空表格，而是带着明确指令的提示骨架，比如规格模板会在开头要求只描述 What 和 Why、禁止写技术选型，并要求把所有拿不准的地方标成 [NEEDS CLARIFICATION] 而不是猜一个答案。模板在运行时被解析，允许项目级覆盖，这是第 14 章定制能力的基础。

scripts/ 里的脚本对应流程中的确定性动作。create-new-feature.ps1 负责分配功能编号、生成功能目录和 spec.md，setup-plan.ps1 和 setup-tasks.ps1 负责在计划和任务阶段准备文件。CLI 包里带着 PowerShell、Bash、Python 三套等价实现，初始化时按你的平台只装一套，所以 Windows 上看到的是 .ps1，换到 macOS 或 Linux 上是 .sh，行为一致。

Agent 命令这一层，Copilot 和 Claude Code 在 1.0 版本默认安装为"技能"形态，目录里是 SKILL.md。不同 Agent 调用命令的语法有细微差别，多数 Agent 使用 /speckit.xxx 形式的斜杠命令，Codex CLI 等少数 Agent 用 $speckit-xxx，Copilot CLI 则通过 /agents 选择对应 Agent 或直接在提示词中点名。本书为统一叙述，一律用 /speckit.xxx 指代这些命令，你在自己的 Agent 里按对应的语法敲即可。

还有两个暂时看不到、但第一次跑功能时就会出现的位置。功能产物不在 .specify/ 里，而在仓库根目录的 specs/ 下，每个功能一个编号目录。.specify/feature.json 是一个本机指针，记录"当前正在做哪个功能"，它被 .gitignore 排除，不进版本库，因为它是每个工作副本各自的状态。在我们的实测里，运行功能创建脚本后得到的就是下面这样的目录和指针内容。

text 复制代码

specs/
└── 001-short-url/
    └── spec.md

json 复制代码

{"feature_directory":"specs\\001-short-url"}

编号默认采用三位顺序号，扫描 specs/ 里已有目录取下一个，超过 999 会自动扩位，创建功能时加上时间戳参数也可以改用 YYYYMMDD-HHMMSS 形式的前缀。目录名由功能描述提炼成两到四个词的短名，你也可以用参数显式指定。功能目录和 Git 分支是两个独立概念，目录名不强制等于分支名，是否为每个功能开分支由你决定，Spec Kit 也提供了可选的 Git 扩展在创建功能时自动建分支。

六、从需求到代码的完整工作流

骨架就位之后，一个功能从想法到收敛要经过的环节如下图。它把第 1 章结尾设想的顺序和 Spec Kit 的实际命令对应起来，也是本书第二篇章的章节主线。
#mermaid-svg-zkcjrkXz0ZiWdyQS{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-zkcjrkXz0ZiWdyQS .error-icon{fill:#552222;}#mermaid-svg-zkcjrkXz0ZiWdyQS .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-zkcjrkXz0ZiWdyQS .marker{fill:#333333;stroke:#333333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .marker.cross{stroke:#333333;}#mermaid-svg-zkcjrkXz0ZiWdyQS svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-zkcjrkXz0ZiWdyQS p{margin:0;}#mermaid-svg-zkcjrkXz0ZiWdyQS .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .cluster-label text{fill:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .cluster-label span{color:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .cluster-label span p{background-color:transparent;}#mermaid-svg-zkcjrkXz0ZiWdyQS .label text,#mermaid-svg-zkcjrkXz0ZiWdyQS span{fill:#333;color:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .node rect,#mermaid-svg-zkcjrkXz0ZiWdyQS .node circle,#mermaid-svg-zkcjrkXz0ZiWdyQS .node ellipse,#mermaid-svg-zkcjrkXz0ZiWdyQS .node polygon,#mermaid-svg-zkcjrkXz0ZiWdyQS .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .rough-node .label text,#mermaid-svg-zkcjrkXz0ZiWdyQS .node .label text,#mermaid-svg-zkcjrkXz0ZiWdyQS .image-shape .label,#mermaid-svg-zkcjrkXz0ZiWdyQS .icon-shape .label{text-anchor:middle;}#mermaid-svg-zkcjrkXz0ZiWdyQS .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .rough-node .label,#mermaid-svg-zkcjrkXz0ZiWdyQS .node .label,#mermaid-svg-zkcjrkXz0ZiWdyQS .image-shape .label,#mermaid-svg-zkcjrkXz0ZiWdyQS .icon-shape .label{text-align:center;}#mermaid-svg-zkcjrkXz0ZiWdyQS .node.clickable{cursor:pointer;}#mermaid-svg-zkcjrkXz0ZiWdyQS .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .arrowheadPath{fill:#333333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-zkcjrkXz0ZiWdyQS .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-zkcjrkXz0ZiWdyQS .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-zkcjrkXz0ZiWdyQS .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-zkcjrkXz0ZiWdyQS .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .cluster text{fill:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS .cluster span{color:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-zkcjrkXz0ZiWdyQS .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-zkcjrkXz0ZiWdyQS rect.text{fill:none;stroke-width:0;}#mermaid-svg-zkcjrkXz0ZiWdyQS .icon-shape,#mermaid-svg-zkcjrkXz0ZiWdyQS .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-zkcjrkXz0ZiWdyQS .icon-shape p,#mermaid-svg-zkcjrkXz0ZiWdyQS .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-zkcjrkXz0ZiWdyQS .icon-shape .label rect,#mermaid-svg-zkcjrkXz0ZiWdyQS .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-zkcjrkXz0ZiWdyQS .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-zkcjrkXz0ZiWdyQS .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-zkcjrkXz0ZiWdyQS :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 仍有缺口
Converged
/speckit.constitution

确立项目原则（每项目一次）
/speckit.specify

写功能规格 spec.md
/speckit.clarify

澄清高影响歧义，写回 spec.md
/speckit.plan

技术计划 plan.md 及研究、契约
/speckit.tasks

拆解任务 tasks.md
/speckit.analyze

跨产物一致性检查（只读）
/speckit.implement

按任务实现
/speckit.converge

对照规格检查缺口，追加任务
功能完成

流程从项目原则开始，但项目原则是每个项目只做一次的事，不属于任何单个功能。它把代码质量、测试标准、兼容性、安全这些跨功能的工程原则定下来，后续所有计划都要过它这一关。

每个功能自身的起点是 /speckit.specify。你给它一句自然语言描述，和第 1 章那句短链接 Prompt 差不多，但这次它不会直接产出代码，而是生成 specs/NNN-名称/spec.md，内容包括用户场景、按 P1、P2、P3 排好优先级的用户故事、Given--When--Then 形式的验收场景、功能需求、边界条件、实体和假设。模板强制它只谈 What 和 Why，拿不准的地方必须显式标记，不许猜。

紧接着是 /speckit.clarify，这是上一章"歧义必须由人做决定"那条约束的落点。Agent 阅读规格，挑出影响面大的歧义向你提问，你回答之后结论被写回 spec.md，那些 [NEEDS CLARIFICATION] 标记一个个消失。它是可选命令，但官方建议在计划之前始终跑一次。

规格稳定之后才进入 How。/speckit.plan 接收你补充的技术上下文，用什么语言、框架、存储、测试环境，产出 plan.md，内容包括技术选型及理由、分阶段实施、数据模型、接口契约、对照项目原则的合规检查和复杂度追踪。计划阶段还会按需生成 research.md、data-model.md、contracts/ 和 quickstart.md，第 7 章会逐个讲。

/speckit.tasks 把计划翻译成带编号、带依赖关系的任务清单 tasks.md，任务按用户故事分阶段组织，互相不阻塞的任务打上 [P] 标记允许并行，P1 故事的任务单独构成可以交付的 MVP 切片。到这里，开工前的产物就齐了。

动手之前还有一道可选但强烈推荐的关卡，/speckit.analyze。它是严格只读的，不修改任何文件，只做跨产物核对，规格里的每条需求有没有任务对应，计划里的接口和数据模型是否自洽，任务是否覆盖了验收场景，有没有违反项目原则。它把第 1 章说的"产物互相打架"拦在编码之前，发现的问题按严重程度分级，修不修由你决定，但问题不会再沉默着溜进实现阶段。

/speckit.implement 按任务清单实施，Agent 在这一步才开始写业务代码。它读取的上下文不是你的一句话，而是 spec.md、plan.md、tasks.md 和项目原则四份产物，修改范围被任务清单约束。实现之后跑 /speckit.converge，它对照三份产物检查代码库，把没做、做了一半、与规格不符的部分作为新任务追加到 tasks.md 末尾，然后再实现、再检查，直到它报告 Converged。这个 implement 到 converge 的回路，就是"代码向规格收敛"的字面含义，也是它和"生成完就算交付"最大的区别。

七、核心命令及其产物

最后把这一章出现过的命令收成一张对照表，方便后面章节回查。产物一列只列主要文件，实际还可能有 quickstart.md、checklist 报告等派生内容。

命令	阶段	主要产物	可写性
`/speckit.constitution`	立项，每项目一次	`.specify/memory/constitution.md`	写项目原则一个文件
`/speckit.specify`	需求	`specs/NNN-名称/spec.md`	新建功能目录和规格
`/speckit.clarify`	澄清	改写 spec.md，消除歧义标记	只改规格
`/speckit.plan`	技术方案	`plan.md`，按需附 `research.md`、`data-model.md`、`contracts/`、`quickstart.md`	写计划类文件
`/speckit.tasks`	任务拆解	`tasks.md`	写任务文件
`/speckit.analyze`	实现前检查	终端中的分级分析报告	严格只读
`/speckit.implement`	编码	业务代码和测试	按任务改代码库
`/speckit.converge`	收敛检查	向 tasks.md 追加 Convergence 任务段	只追加任务，不改代码
`/speckit.checklist`	质量检查	自定义质量检查清单	生成清单
`/speckit.taskstoissues`	协作对接	GitHub Issues	把任务发布成 Issue

前八个命令构成主干，后两个是增强能力。checklist 被官方形容为"给英文写的单元测试"，用来校验需求的完整性和一致性，taskstoissues 则把任务清单接到 GitHub Issues 上，解决多人协作时的追踪问题，第 13 章会用到它。

这张表真正要看的是产物之间的方向关系。信息从上往下流动，项目原则约束规格，规格约束计划，计划约束任务，任务约束代码。而检查方向从下往上，analyze 和 converge 拿着上游产物核对下游现实。每一层产物都是普通 Markdown，进 Git，能 diff，能评审，这让"需求到代码的可追溯链路"不再是一句流程口号，而是仓库里一条条实际存在的文件引用。

另外，CLI 侧还有一组不常直接用、但需要知道存在的命令。specify check 检查本机依赖是否齐全，specify integration list 列出当前版本支持的全部 Agent 集成，specify extension、specify preset、specify bundle 管理扩展体系，specify workflow 运行把 specify 到 implement 串起来的自动化工作流。扩展、预设和 Bundle 是第 14 章的主题，现在只需要记住，初始化得到的主干流程可以被这些机制改造，但核心的产物分层不变。

八、小结

这一章把第 1 章的药方落到了实物。SDD 的核心是权力反转，规格从用完即弃的脚手架变成主要产物，代码成为规格在具体技术栈下的一次表达，而规格必须精确、完整、无歧义到可以被 Agent 直接消费。Spec Kit 是这套方法论的开源实现，它自己不生成任何代码，生成由你的 AI Coding Agent 完成，它负责的是流程、模板、文件位置和产物之间的核对规则。

我们实际安装了 specify-cli 1.0.6，初始化了一个项目，看清了三层结构，CLI 负责一次性装配，.specify/ 里的模板和脚本提供确定性骨架，Agent 命令把模型约束进固定环节。我们也走完了从项目原则、规格、澄清、计划、任务、分析到实现和收敛的完整链路，并把每个命令的产物列成了表。

下一章进入这条链路的第一份产物。很多团队第一次写规格会不自觉地把它写成 PRD 或者技术方案，结果 What、Why 和 How 又混回了一起。第 3 章就来掰扯清楚，Specification 到底是什么、不是什么，以及一份模糊需求怎样才能变成可测试、可验证的规格。