github/spec-kit 入门指南 + 进阶最佳实践

下面是一份面向具体开源项目 github/spec-kit 的“入门指南 + 进阶最佳实践”整理与扩展，结合其仓库现有 README、文档结构与 Spec‑Driven Development（SDD）方法论进行体系化梳理，帮助你快速、规范、可持续地使用它。

1. 项目定位速览

Spec Kit 旨在把“规格（Spec）”置于开发核心：先沉淀项目原则与功能需求，再逐步澄清、规划、分解、实现，减少“一句话→直接写代码→返工”的低效模式。它通过一组 slash 命令与模板驱动你的 AI 编码代理（Copilot / Claude Code / Gemini CLI / Cursor 等）执行结构化过程，而不是一次性大模型代码生成。

核心价值：

意图优先：先写清楚“做什么 / 为什么”，再讨论“怎么做”
分阶段细化：constitution → spec → clarify → plan → tasks → analyze → implement
自动化生成并维护规范目录与实现工件
促进多人协作、分支化特性开发与可追溯

2. 安装与快速启动

2.1 先决条件

Linux / macOS / WSL2
Python 3.11+
uv（Python 包与工具管理）
Git
选用的 AI 代理（如：GitHub Copilot、Claude Code、Gemini CLI、Cursor、Qwen、Windsurf 等）

2.2 安装 Specify CLI（推荐持久安装）

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

检查：

specify check

一次性使用：

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

2.3 初始化项目

specify init my-app --ai copilot
# 当前目录：
specify init --here --ai copilot
# 非空目录强制合并
specify init --here --force --ai copilot

常用可选参数：

--ai <agent>：选定代理
--script sh|ps：脚本风格
--no-git：跳过 git init
--ignore-agent-tools：不检测代理工具
--github-token <token>：企业/配额场景
--debug：调试输出

3. 核心 Slash 命令职责矩阵

命令	目标产物	关键文件	说明
`/constitution`	项目治理/原则	`.specify/memory/constitution.md`	价值观、质量/性能/测试/演进守则
`/specify`	功能规格（用户故事+需求）	`specs/<feature>/spec.md`	只讨论“做什么与为什么”
`/clarify`	需求澄清答案集合	`spec.md` Clarifications 区/或附录	覆盖未决点，减少后期返工
`/plan`	技术实现计划 + 模块/数据/契约	`plan.md`, `data-model.md`, `contracts/*`	定栈、架构、API/事件等
`/tasks`	可执行任务分解	`tasks.md`	标注依赖、并行、测试策略
`/analyze`	跨文档一致性与覆盖分析	更新分析报告（通常写入 CLAUDE.md 或 spec 末）	确认无遗漏/冲突
`/implement`	代码+测试生成与迭代	代码树 + 更新任务状态	严格按 tasks 顺序执行

最佳实践：

/clarify 必须在 /plan 之前（除非显式说明跳过）
/analyze 在 /tasks 后、/implement 前，起“质检闸门”作用
每个特性使用独立特性分支与编号（例如：001-create-taskify）

4. 目录结构理解

初始化后常见结构（精简示例）：

.specify/
  memory/
    constitution.md
  scripts/
    create-new-feature.sh
    setup-plan.sh
    update-claude-md.sh
  specs/
    001-create-taskify/
      spec.md
      plan.md
      tasks.md
      data-model.md
      research.md
      quickstart.md
      contracts/
        api-spec.json
        signalr-spec.md
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
CLAUDE.md (或代理专属上下文)

要点：

specs/<编号-特性名> 下分离“功能意图（spec）”与“技术细化（plan / data-model / contracts）”
research.md 支撑快速演进技术领域（例如 .NET Aspire、前端库）
contracts/ 用于协议 / API / 实时通道说明（REST / WebSocket / SignalR 等）
tasks.md 驱动实现时序与 TDD 节奏

5. 规范编号策略

需求	建议	示例
严格序列	统一三位或四位递增	`001-login`, `002-kanban`
并行探索	派生分支加后缀	`010-kanban-alt-a`, `010-kanban-alt-b`
变更迭代	使用补丁标识	`001-login-v2` 或在 spec 内维护 Changelog
作废	保留目录+在 spec 顶部标注 Deprecated	`DEPRECATED: superseded by 014-auth-refactor`

6. 高质量 Specification 写法准则

维度	好的示例	常见反模式
用户故事	“作为项目成员，我可以拖拽任务以更新其状态，以减少点击操作”	“实现拖拽功能”
验收标准	条目化、可验证（Given/When/Then 或 bullet）	模糊形容词（快速、友好、简单）
范围界限	“不含：外部 OAuth 登录；不做移动端适配”	未说明不做什么，后期不断追加
术语表	明确“任务、项目、成员、看板列”	词语复用概念漂移
权限/限制	“评论仅作者可编辑/删除”	等到实现时才讨论权限
数据约束	“任务标题 ≤ 120 字符；评论不支持 Markdown”	全靠实现阶段临时决定

7. Clarify 阶段最佳实践

先让模型列“未明确清单”（Unknowns matrix）
限制一轮问答数量（例如每批 5～10 个），防止上下文漂移
对回答写入 spec.md 的 Clarifications 区域（保持可追溯）
未回答的标记 TODO，避免 /plan 误读
触发再澄清的典型信号：
- 数据实体之间的关系不完整
- 任务状态生命周期未闭合
- 错误/失败场景缺失
- 并发或并行场景模糊

8. Plan 阶段结构建议

在 plan.md 中添加固定分区：

架构简图（文字/ASCII/引用外部图）
模块边界（Boundary Contexts）
数据模型摘要（与 data-model.md 互相引用）
合同契约（API/事件/实时通道）
非功能需求映射（性能、可观测性、可测试性）
风险与假设
迭代与裁剪策略（MVP vs 后续增强）

契约文件（如 api-spec.json）后期可用于：

Mock 生成
回归校验
文档站点（后续可接入 Redoc、Stoplight 之类）

9. 任务分解（/tasks）设计建议

任务编排字段（可在 tasks.md 中用结构化标记）：

- [ ] T01 Schema 定义 (deps: -) (type: core) (test: unit + migration script)
- [ ] T02 API: POST /tasks (deps: T01) (test: contract + unit)
- [ ] T03 UI: 看板拖拽交互 (deps: T02) (test: e2e)
- [ ] T04 权限规则 & 审计 (deps: T02) (test: security)
- [ ] T05 性能初步基准 & 指标埋点 (deps: T02) (test: perf smoke)

最佳实践：

明确依赖（deps）→ /implement 能正确排序
标注测试类型（unit/contract/e2e/security/perf）
大任务拆 ≤ 1～2 小时交付的粒度，减少上下文丢失
并行任务标记（如 parallel: true）给 AI 代理优化执行顺序

10. Analyze 阶段作用

核对：

检查项	说明
Spec vs Plan 一致性	是否出现未在 spec 提及的“幽灵需求”
Tasks 覆盖	每个关键需求/约束是否至少映射一个任务
数据模型冲突	命名/主键/关系是否与用户故事矛盾
风险空白	高风险区域（并发、持久化、权限）是否有研究/测试任务
非功能映射	性能/安全/可观测性是否体现在 tasks 中

11. Implementation（/implement）阶段控制点

执行前自检（可人工或让代理回答）：

Constitution 已存在且不为空
Clarifications 已处理（无大量 TODO）
Plan 中未留“待定（TBD）”关键段
Tasks 全部具备测试策略标注
契约文件语法有效（若是 JSON/YAML 的 API Spec）

运行中：

监控是否出现“过度生成”（添加你未要求的第三方库／模块）
反复提示“遵循任务顺序，不要跳级或合并无关任务”
生成的测试必须先于或同步代码（保持 TDD/ATDD）

完成后：

运行本地测试 & 手工验证关键路径
对运行日志/浏览器 console 错误进行“二次对话”修复
生成初始 CHANGELOG（可在 feature spec 或单独 CHANGELOG.md）

12. 日常工作流（单人或小团队）

频率	动作	说明
每个新特性	`/constitution`（第一次）→ `/specify` → `/clarify`	建立清晰意图与边界
Clarify 完成后	`/plan` → 复审 → `/tasks`	保证覆盖与粒度
实施前	`/analyze`	形成“通过/阻塞”门
实施中	`/implement` 分段执行	中途可人工插入研究任务
完成后	回顾 spec & plan	标记偏差与下轮改进
每周	审查活跃特性目录	归档已合并，清理废弃编号

13. 与 Git 分支策略结合

分支类型	命名	触发	合并策略
主干	`main`	稳定、可发布	PR + 审阅
特性	`NNN-<slug>`	`/specify` 之后	Rebase / Squash
探索/实验	`exp-<topic>`	创意/对比方案	不保证合并
修正	`fix-<issue>`	缺陷修复	快速审阅后合并

最佳实践：

在 spec 顶部记录：Branch: 001-create-taskify
PR 描述引用：Implements specs/001-create-taskify/spec.md

14. 质量提升扩展（仓库暂未内置但可叠加）

方向	可行实践
契约测试	引入 `Schemathesis`／`Dredd` 读取 `contracts/api-spec.json`
架构防腐	ADR（Architecture Decision Records）与 plan 互链
安全	静态依赖扫描集成（如 `pip-audit`, `npm audit`）+ “安全限制”部分写入 constitution
可观测性	在 plan 中加入指标表（API p95、错误率、启动时间）
回归审查	Feature 合并后生成“Spec vs 实际产物差异报告”
变更控制	Commit lint 强制引用 spec 编号（如 `feat(001): add drag&drop`）

15. 常见陷阱与规避策略

陷阱	症状	预防
跳过 Clarify	后期大量返工	设立“Clarify 完成”门（未完成不得 `/plan`）
Plan 过度堆叠	生成超出 MVP 的“未来功能”	Constitution 中增加“范围控制”原则
Tasks 粒度过大	`/implement` 生成卡住或上下文丢失	单任务 ≤ 100 行改动/≤2 小时
Spec 与实现脱节	代码新增未更新 spec	合并前执行“Spec 覆盖核对”脚本
代理过度自作主张	引入不必要框架/库	明确提示“最小依赖集”“拒绝未授权技术栈”
研究漂移	Research 写成百科漫谈	Prompt：限定“列出不确定点→针对点搜索→更新 research.md”

16. 评价度量（可自建轻量脚本）

指标	说明	采集方式
Clarification Completion Rate	Clarify 项完成占比	解析 spec Clarifications 段
Task Traceability	Task 是否链接需求编号或用户故事	在 tasks.md 增加 `ref:` 标签
Spec Drift	合并后实现与 spec 不一致条目数	运行静态/契约对比脚本
Over-Spec Ratio	Spec 中未实现条目 / 总条目	统计勾选状态
Implementation Latency	`/plan` → `/implement` 完成平均时长	Git 提交时间差
Churn per Feature	Feature 分支重复回滚/重写次数	Git log 分析

17. 环境变量 / 非分支模式工作

SPECIFY_FEATURE：

在没有 Git 分支（或临时目录演练）下，手动指向当前特性目录
流程：设定 → 运行代理 → 执行 /tasks 或 /implement

示例：

export SPECIFY_FEATURE=001-create-taskify

18. 针对已有项目“渐进式接入”策略

步骤	动作	目标
1	选择一个即将开发的新功能	避免一次性重构旧需求
2	初始化 Spec Kit 环境	引入脚手架与模板
3	手动补写 `.specify/memory/constitution.md`	定义统一风格与质量门槛
4	为此新功能走完整流程（spec→clarify→plan→tasks→implement）	试点验证
5	复盘：记录痛点与改进点	形成团队约定
6	为下一个特性复制成功模板	渐进推广
7	回填历史核心模块最低限度 spec	提升可追溯范围
8	引入指标脚本+预提交或 CI 钩子	形成质量闭环

19. 进阶补充：如何写出高复用的 “Constitution”

推荐固定章节：

使命与范围声明（Mission & Scope）
风格与代码规范（引用已有 lint / formatter）
测试金字塔策略（何时写单测、契约、e2e、性能）
性能预算（首屏渲染 / API p95 / 资源上限）
安全与权限（最小权限、输入消毒、审计日志）
依赖策略（允许 vs 禁止的库清单；版本升级节奏）
可观测性（日志结构、指标命名、错误分级）
变更治理（需求 → 任务 → 实现的强制回链）
风险应对（快速回滚标准 / 探索性分支策略）

20. 示例：高质量特性目录（抽象化）

specs/
  012-kanban-dnd/
    spec.md               # 用户故事 + Clarifications + 验收清单
    plan.md               # 架构/模块/数据流/接口/性能策略
    data-model.md         # ER/字段约束
    contracts/
      api-spec.json       # 任务 CRUD / 列表 / 状态更新
      events.md           # 可选：实时更新事件
    research.md           # 针对拖拽库/状态同步策略
    tasks.md              # 可执行任务流水线+测试策略
    quickstart.md         # 针对新成员/测试人员

21. 快速核对清单（可放入根目录 `SPEC-KIT-CHECKLIST.md`）

项	是否达成
有 constitution 并引用于后续 prompt
最新特性 spec 有 Clarifications（无大量 TODO）
Plan 未出现“待定”关键段（如数据库选型）
Tasks 均带测试策略标记
Contracts 已验证（无语法错误）
`/analyze` 报告通过（无严重冲突）
实现完成后 PR 描述引用对应 spec 路径
Merge 前手动或自动生成变更说明（Changelog 或 Release Note）

22. 总结

Spec Kit 把“构思 → 澄清 → 设计 → 分解 → 执行”嵌入一个可重复、可审查、可升级的循环。成功的关键不只是运行命令，而是：

建立严格的信息分层（what/why 与 how 分离）
用 Clarify 阶段拉平不确定性
用 Analyze 做一致性护栏
用可观察的任务清单驱动真正的“结构化 AI 协作”
将质量/性能/安全升级为显式条款（constitution 化）

只要坚持这一套节奏，你会发现：

返工率下降
需求浮动更容易被识别
新成员可在数分钟内理解上下文
AI 生成代码更贴近意图，少“跑偏”

如果你已经在某个现有仓库里想加入 Spec Kit，可以直接从“一个新特性试点”开始，再逐步回填历史核心模块的 spec。也可以把你当前的目录或特性想法贴出来，我再帮你落地映射与裁剪策略。祝使用顺利！

下面给出“使用 Spec Kit” vs “不使用 Spec Kit” 的系统化对比，从流程、产出、风险、效率、适用场景与潜在代价多个维度分析，帮助评估价值与采纳策略。

1. 总览对比速览

维度	使用 Spec Kit	不使用 Spec Kit（传统“边想边写”或松散文档）
工作流结构	明确 7 阶段：constitution → specify → clarify → plan → tasks → analyze → implement	常见：需求口头/issue 片段 → 直接写代码 → 事后补文档
需求质量	有 Clarifications 阶段，系统补全未知点	隐性假设多，差异理解延迟浮现
需求→实现追溯	通过编号目录 + 文件（spec/plan/tasks）建立显式映射	Commit message 偶尔引用 issue；细粒度追溯缺失
AI 协作效果	通过模板与 slash 命令减少“跑题”与过度臆测	Prompt 质量参差；经常“过度工程”或遗漏边界
任务分解	tasks.md 结构化（依赖、并行、测试策略）	任务零散在脑中 / TODO / issue，顺序和依赖不清
设计一致性	/analyze 阶段做覆盖和冲突评估	直至集成或测试时才发现不一致
契约与接口	contracts 文件夹提前固化	API 频繁改动导致前后端/客户端打补丁
不确定性处理	Clarify 阶段先集中收敛	实施期频繁中断询问或临时返工
文档可演化性	Spec 即活文档，可迭代	规格往往滞后或弃用
新成员上手	通过 spec 目录树快速再现决策轨迹	需要口头传递或代码逆向理解
变更影响评估	Diff spec 目录 & plan 结构即可映射风险	影响半径靠资深工程师经验判断
非功能（性能/安全）	可在 constitution / plan 明确条目	常被延后或遗漏，补偿成本高
复盘能力	可比对预期（spec）与产出（实现）差异	难以量化“偏离需求”程度
指标量化	可采集 Clarify 完成率、Spec Drift、Coverage	指标体系难建立（缺乏结构化源）
可并行探索	不同 feature 编号 / 分支并行不干扰	容易混入同一分支或上下文冲突
风险前移	结构要求 => 早期暴露不确定性	风险在后端实现/集成阶段集中爆发
代码质量驱动	TDD / 任务粒度内置在 tasks	事后补测或测试不足
AI 滥用防控	Constitution 约束：技术栈、依赖、风格守则	大模型可能引入未评估栈/框架
审批与治理	Spec / Plan 可评审后再 implement	PR 大量“设计 + 实现”混合，难审
规模化适配	更适合 >3 人多并行特性团队	小项目尚可，但规模扩张后 friction 激增
学习曲线	初期需要流程纪律	上手快但后期代价累计

2. 典型开发流程对比

2.1 新功能（Greenfield）

步骤	使用 Spec Kit	不用 Spec Kit
需求收集	`/specify` 写完整意图；Clarify 补缺	会议/聊天记录散落
设计	`/plan` 与 data-model/contracts 分离	在脑中或直接编码中演化
任务划分	`/tasks` 明确依赖/测试策略	即兴 TODO；常遗漏边界条件
执行	`/implement` 按序生成+测试	边写边调；测试后置
回顾	Analyze + spec diff	凭印象总结

2.2 迭代增强（Brownfield）

问题	使用 Spec Kit	不用 Spec Kit
判断影响范围	查相关 feature 目录 vs plan	全局 grep / 人脑记忆
防止回归	契约/验收标准显式	回归集不足
控制范围膨胀	Constitution + Spec 范围声明	需求蔓延（Scope Creeping）

2.3 并行探索（多技术方案）

目标	使用 Spec Kit	不用 Spec Kit
两种技术对比	`010-x-a` / `010-x-b` 目录并行	同分支反复覆盖，历史丢失
决策记录	spec/plan 中保留抉择理由	只在口头或散乱文档里

3. 关键痛点与化解映射

传统痛点	后果	Spec Kit 化解点
需求漂移	返工 / 期望不一致	Clarify 提前消化未知
过度工程	时间浪费	Constitution 约束“最小可行”
设计缺失	架构补丁式生长	plan/data-model/contracts 分层
任务混乱	顺序错误 / 阻塞	tasks 依赖图
测试滞后	缺陷后置成本高	TDD 嵌入 tasks 元数据
新成员慢	需大量口头交接	规格目录即“语义地图”
风险集成期爆发	紧急加班	Analyze 前移一致性验证
AI 输出不稳	跑题/加库	Slash 命令约束上下文结构

4. 成本与收益模型（定性/半定量）

时间阶段	使用 Spec Kit 额外投入	潜在节省
初期（1～2 周）	写 constitution / clarify / plan 增加 10–25% 时间	减少后期返工 20–40%
中期（多特性并行）	维护 spec 目录与编号	降低跨团队沟通成本（会议/澄清减少）
后期（迭代 / 重构）	更新已有 spec	减少“为什么当时这么做”考古时间
Bug 修复	需对照 spec/plan 定位	减少误判范围，加速修复闭环
人员流动	新人阅读成本低	降低交接损耗（缩短生产力恢复）

经验性 ROI（假设中型团队 6–8 人）：

规范后 2～3 个迭代可开始抵消初期时间投入
Feature 返工率（需求理解错误导致的重写）可从 ~15–25% 降到 <8–10%
同步沟通（澄清会议/Slack 线程）减少 20–30%

5. 指标层面对比（可用于内部评估）

指标	使用 Spec Kit（可跟踪）	不使用（常缺失或难量化）
Clarification Completion Rate	✅	❌
Spec Drift (实现 vs 规格差异)	✅	❌（缺参照）
任务执行可预测性（计划 vs 实际完结偏差）	✅（tasks 时间戳）	模糊
API 破坏性变更频率	✅（contracts diff）	只能事后感知
平均 Onboarding 时间	✅（可测减少）	少量定性访谈
缺陷类型分类（需求误解 vs 实现 bug）	✅（溯源到 spec）	混合统计

6. 不采用 Spec Kit 的适用场景（何时“够用就好”）

场景	原因	建议
一次性脚本 / 单人临时工具	需求简单，生命周期极短	可只写 README 说明
极高速“竞赛式”原型	评估可行性比结构化更重要	用最小 `/specify` 即止
重度探索 / 创意涌现阶段	方向摇摆大，结构成本难摊	先产出知识草稿，再抽象成 spec
小于 2 人微团队且领域稳定	口头同步成本低	注意随规模增长尽早迁移

7. 采用时的“最小可行子集（MVS）”建议

如果担心流程过重，可先采纳：

/constitution（精简版：编码风格 + 依赖约束 + 测试准则）
/specify + /clarify
/plan（只保留数据模型 + 模块职责 + 契约）
/tasks（轻量列表：ID + 描述 + 测试类型）
/implement

延后引入：

/analyze
research.md 深化
并行探索分支策略
性能/安全非功能模板

8. 失败/偏轨征兆与纠错

征兆	说明	纠偏措施
Spec 越写越像设计/实现细节	意图与实现混杂	把技术实现移入 plan / tasks
Clarify 输出敷衍、TODO 堆积	实际未解决不确定性	强制 Clarify 完成率阈值（>85%）
`/implement` 频繁中断	任务粒度不当/依赖缺失	重构 tasks：添加 deps 与测试策略
Plan 完成却仍大量“待定”	流程被绕过	审阅拒绝进入实现阶段
Research 漫无边界	时间被吞噬	给 research 设定问题列表与时限
AI 生成未请求的外部组件	过度工程	Constitution 添加“禁止技术栈”条款

9. 与 AI 协作深度对比

项	使用 Spec Kit	不使用
Prompt 粒度	每阶段专用上下文（模板 + 历史）	单个长 prompt 失控
输出可预测性	由结构限定范围	模型自由发挥，易偏离目标
重试成本	只需局部迭代对应文件	需重写大段 prompt
可复用性	规格与计划可迁移到相似特性	需从头再写 prompt 说明背景
失误定位	看是哪一层（spec/plan/tasks）失配	错误原因混杂难拆解

10. 落地决策自检问卷

若以下 ≥ 5 项回答“是”，强烈建议使用（或迁移到） Spec Kit：

多于 3〜4 人同时开发多个特性？
需求澄清会议后仍经常出现理解偏差？
API 变更引发下游破坏频繁？
加入新成员需要 > 数天才能独立产出？
Bug 中 >30% 与误解需求有关？
想用 AI 强化交付但经常“跑题”？
需要证明或审计“为什么这样实现”？
需要度量规格覆盖、减少暗知识？

11. 迁移策略对比（全量 vs 渐进）

策略	优点	风险	适合
全量重构（一次性为现有模块补 spec/plan）	统一度高	初始成本大，易拖延	模块少且时间窗口充裕
渐进：新特性用，旧模块触发式补	投入平衡，学习曲线柔和	早期规范不一致	绝大多数真实团队
关键域优先（支付/权限/核心数据）	风险高区域先受益	广度扩散慢	有清晰优先级的系统

12. 小结（决策金句）

结论表述	核心含义
Spec Kit 不是“加文档”，而是“替换散乱思考为结构化意图”	重点在认知组织
你付出的前置精力换来可预测的交付与低返工	前期写 → 后期省
它放大 AI 的靠谱性，而不是仅靠“大模型运气”	减少跑题与不可控生成
没有规模 / 没有多协作时可降配使用	成本与收益匹配规模
最大的隐性收益是知识沉淀与再利用	长期复利

13. 下一步建议（如果你准备评估）

时间	行动	产物
第 1 天	Pick 一个小但非琐碎的特性	`specs/001-<feature>/...`
第 2 天	完成 clarify + plan + tasks	Clarify 完成率 >80%
第 3 天	`/implement` + 回顾	记录偏差点
第 4～5 天	选第二个特性 → 套用模板	验证可重复性
第 2 周	设计“质量门”脚本（检查 Clarify、Task 标签）	基础自动审查
第 3 周	采集首批指标（Spec Drift / Clarify Rate）	指标 dashboard 草图

如果你愿意，我可以帮你：

为你的某个真实 feature 写一份高标准 spec.md + plan.md 模板示例；
生成一个自动检查 Clarifications 完成率的小脚本；
给出适用于前端（例如 Vite / Electron / Tauri）项目的 constitution 基础模板。

告诉我你想优先哪一项即可。需要继续深入哪部分吗？

daqi/Spec Kit “入门指南 + 进阶最佳实践”.md

1. 项目定位速览

2. 安装与快速启动

2.1 先决条件

2.2 安装 Specify CLI（推荐持久安装）

2.3 初始化项目

3. 核心 Slash 命令职责矩阵

4. 目录结构理解

5. 规范编号策略

6. 高质量 Specification 写法准则

7. Clarify 阶段最佳实践

8. Plan 阶段结构建议

9. 任务分解（/tasks）设计建议

10. Analyze 阶段作用

11. Implementation（/implement）阶段控制点

12. 日常工作流（单人或小团队）

13. 与 Git 分支策略结合

14. 质量提升扩展（仓库暂未内置但可叠加）

15. 常见陷阱与规避策略

16. 评价度量（可自建轻量脚本）

17. 环境变量 / 非分支模式工作

18. 针对已有项目“渐进式接入”策略

19. 进阶补充：如何写出高复用的 “Constitution”

20. 示例：高质量特性目录（抽象化）

21. 快速核对清单（可放入根目录 SPEC-KIT-CHECKLIST.md）

22. 总结

1. 总览对比速览

2. 典型开发流程对比

2.1 新功能（Greenfield）

2.2 迭代增强（Brownfield）

2.3 并行探索（多技术方案）

3. 关键痛点与化解映射

4. 成本与收益模型（定性/半定量）

5. 指标层面对比（可用于内部评估）

6. 不采用 Spec Kit 的适用场景（何时“够用就好”）

7. 采用时的“最小可行子集（MVS）”建议

8. 失败/偏轨征兆与纠错

9. 与 AI 协作深度对比

10. 落地决策自检问卷

11. 迁移策略对比（全量 vs 渐进）

12. 小结（决策金句）

13. 下一步建议（如果你准备评估）

21. 快速核对清单（可放入根目录 `SPEC-KIT-CHECKLIST.md`）