Spec-Kit：AI驱动的软件开发全流程管理工具套件

Spec-Kit 是一套专为AI辅助开发场景设计的命令行工具套件，提供了从需求规格到代码实现的标准化工作流程。通过8个核心命令，它确保软件开发的每个环节都保持高质量和一致性。

核心理念

端到端管理：覆盖需求规格化、架构设计、任务分解、代码实现全流程
AI优化设计：专为与Claude等AI助手协作而优化
质量保证：内置多层次验证机制
知识沉淀：项目宪法、设计决策完整记录

这篇文章主要是想记录下spec-kit的核心command具体在干嘛。所以翻译了下所有的command（按照实际使用顺序），以便阅读。

八大核心工具详解

1. /speckit.constitution - 项目宪法管理

description: 从交互式或提供的原则输入创建或更新项目宪法，确保所有依赖模板保持同步。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

概述

你正在更新 .specify/memory/constitution.md 的项目宪法。此文件是一个包含方括号中占位符标记的模板（例如，[PROJECT_NAME]、[PRINCIPLE_1_NAME]）。你的工作是（a）收集/派生具体值，（b）精确填充模板，以及（c）跨依赖项传播任何修订。

遵循此执行流程：

加载现有宪法模板：
- 加载 .specify/memory/constitution.md 的现有宪法模板
- 识别 [ALL_CAPS_IDENTIFIER] 形式的每个占位符标记
- 重要：用户可能需要比模板中使用的原则更少或更多。如果指定了数字，请尊重它 - 遵循一般模板。你将相应地更新文档。
收集/派生占位符的值：
- 如果用户输入（对话）提供值，则使用它
- 否则从现有仓库上下文（README、文档、先前的宪法版本（如果嵌入））推断
- 对于治理日期：RATIFICATION_DATE 是原始采用日期（如果未知询问或标记 TODO），LAST_AMENDED_DATE 是今天如果进行了更改，否则保留先前的
- CONSTITUTION_VERSION 必须根据语义版本控制规则递增：
  - 主要：向后不兼容的治理/原则删除或重新定义
  - 次要：新原则/部分添加或实质性扩展指导
  - 补丁：澄清、措辞、拼写修复、非语义优化
- 如果版本递增类型模糊，在最终确定前提出推理
起草更新的宪法内容：
- 用具体文本替换每个占位符（除非项目选择尚未定义而故意保留的模板槽，否则不留方括号标记------明确说明任何留下的标记）
- 保留标题层次结构和注释，一旦替换就可以删除，除非它们仍然增加澄清指导
- 确保每个原则部分：简洁的名称行，捕获不可协商规则的段落（或项目符号列表），如果不明显则提供明确理由
- 确保治理部分列出修订程序、版本控制策略和合规审查期望
一致性传播检查清单（将先前的检查清单转换为主动验证）：
- 读取 .specify/templates/plan-template.md 并确保任何"宪法检查"或规则与更新的原则对齐
- 读取 .specify/templates/spec-template.md 进行范围/需求对齐------如果宪法添加/删除强制性部分或约束则更新
- 读取 .specify/templates/tasks-template.md 并确保任务分类反映新的或删除的原则驱动的任务类型（例如，可观察性、版本控制、测试纪律）
- 读取 .specify/templates/commands/*.md 中的每个命令文件（包括此文件）以验证当需要通用指导时不存在过时引用（特定于代理的名称如 CLAUDE 仅）
- 读取任何运行时指导文档（例如，README.md、docs/quickstart.md 或如果存在则特定于代理的指导文件）。更新对更改的原则的引用
生成同步影响报告（在更新后作为 HTML 注释前置到宪法文件顶部）：
- 版本更改：旧 → 新
- 修改的原则列表（如果重命名则为旧标题 → 新标题）
- 添加的部分
- 删除的部分
- 需要更新的模板（✅ 已更新 / ⚠ 待处理）带文件路径
- 如果有故意推迟的占位符，则为后续 TODO
最终输出前的验证：
- 没有剩余的未解释方括号标记
- 版本行与报告匹配
- 日期 ISO 格式 YYYY-MM-DD
- 原则是声明性的、可测试的，没有模糊语言（"应该" → 在适当时替换为 MUST/SHOULD 理由）
写回更新的宪法：
- 将完成的宪法写回 .specify/memory/constitution.md（覆盖）
输出最终摘要，包含：
- 新版本和递增理由
- 标记为手动后续的任何文件
- 建议的提交消息（例如，docs: 将宪法修订为 vX.Y.Z（原则添加 + 治理更新））

格式和样式要求

使用模板中的 Markdown 标题完全一致（不要降级/提升级别）
换行长理由行以保持可读性（理想 <100 个字符），但不要用尴尬的换行硬性强制
在部分之间保持单个空行
避免尾随空格

2. /speckit.specify - 功能规格创建

description: 从自然语言功能描述创建或更新功能规格。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

概述

用户在触发消息中 /speckit.specify 后输入的文本就是功能描述。假设你始终在对话中可用，即使下面的 $ARGUMENTS 是字面意思。除非用户提供了空命令，否则不要要求用户重复。

鉴于该功能描述，执行此操作：

创建新功能分支和规格文件：
- 从仓库根目录运行脚本 .specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" 并解析其 JSON 输出中的 BRANCH_NAME 和 SPEC_FILE
- 所有文件路径必须是绝对的
- 重要你必须只运行此脚本一次。JSON 在终端中作为输出提供 - 始终引用它以获取你正在寻找的实际内容
加载规格模板：
- 加载 .specify/templates/spec-template.md 以了解必需的部分
遵循执行流程：
1. 从输入解析用户描述：
  - 如果为空：错误"未提供功能描述"
2. 从描述中提取关键概念：
  - 识别：行动者、操作、数据、约束
3. 处理不清晰的方面：
  - 基于上下文和行业标准做出有根据的猜测
  - 仅在以下情况下标记为 [需要澄清：具体问题]：
    - 选择显著影响功能范围或用户体验
    - 存在多个合理的解释具有不同的含义
    - 没有合理的默认值
  - 限制：总共最多 3 个 [需要澄清] 标记
  - 按影响优先级排序：范围 > 安全/隐私 > 用户体验 > 技术细节
4. 填充用户场景和测试部分：
  - 如果没有清晰的用户流程：错误"无法确定用户场景"
5. 生成功能需求：
  - 每个需求必须是可测试的
  - 为未指定的细节使用合理的默认值（在假设部分记录假设）
6. 定义成功标准：
  - 创建可测量的、技术无关的结果
  - 包括定量指标（时间、性能、数量）和定性措施（用户满意度、任务完成）
  - 每个标准必须可以在不知道实施细节的情况下验证
7. 识别关键实体（如果涉及数据）
8. 返回：成功（规格准备好规划）
写入规格文件：
- 使用模板结构将规格写入 SPEC_FILE，用从功能描述（参数）派生的具体细节替换占位符，同时保留部分顺序和标题
规格质量验证：编写初始规格后，根据质量标准验证它：

a. 创建规格质量检查清单：
- 使用检查清单模板结构在 FEATURE_DIR/checklists/requirements.md 生成检查清单文件
- 包含验证项目：内容质量、需求完整性、功能准备就绪等
b. 运行验证检查：
- 根据每个检查清单项目审查规格
- 对于每个项目，确定是否通过或失败
- 记录发现的具体问题（引用相关规格部分）
c. 处理验证结果：
- 如果所有项目通过：标记检查清单完成并继续到步骤 6
- 如果项目失败 ：
  1. 列出失败项目和具体问题
  2. 更新规格以解决每个问题
  3. 重新运行验证直到所有项目通过（最多 3 次迭代）
- 如果 [需要澄清] 标记保留 ：
  1. 从规格中提取所有 [需要澄清：...] 标记
  2. 限制检查：如果存在超过 3 个标记，只保留 3 个最关键的
  3. 向用户按格式呈现选项（问题表、建议答案等）
  4. 通过用用户选择或提供的答案替换每个 [需要澄清] 标记来更新规格
  5. 在解决所有澄清后重新运行验证
报告完成：
- 报告分支名称、规格文件路径、检查清单结果以及下一阶段（/speckit.clarify 或 /speckit.plan）的就绪状态

一般指南

快速指南

专注于用户需要什么 和为什么
避免如何实施（无技术栈、API、代码结构）
为业务利益相关者编写，而不是开发者
不要创建任何嵌入在规格中的检查清单。那将是一个单独的命令

部分要求

强制性部分：必须为每个功能完成
可选部分：仅在与功能相关时包括
当部分不适用时，完全删除它（不要保留为"不适用"）

对于 AI 生成

1. 做出有根据的猜测：

使用上下文、行业标准和通用模式填补空白

2. 记录假设：

在假设部分记录合理的默认值

3. 限制澄清：

最多 3 个 [需要澄清] 标记 - 仅用于关键决策：
- 显著影响功能范围或用户体验
- 具有多个合理的解释具有不同的含义
- 缺乏任何合理的默认值

4. 优先级排序澄清：

范围 > 安全/隐私 > 用户体验 > 技术细节

5. 像测试人员一样思考：

每个模糊的需求都应该在"可测试和明确"检查清单项目上失败

6. 常见需要澄清的领域（仅当没有合理的默认值存在时）：

功能范围和边界（包括/排除特定用例）
用户类型和权限（如果存在多个冲突的解释可能）
安全/合规需求（当法律/财务上有重大意义时）

合理默认值的示例（不要询问这些）

数据保留：该行业的行业标准实践
性能目标：标准 web/移动应用期望，除非另有说明
错误处理：用户友好的消息与适当的回退
身份验证方法：基于标准会话或 web 应用的 OAuth2
集成模式：RESTful API，除非另有说明

成功标准指南

成功标准必须是：

可测量的：包括具体指标（时间、百分比、数量、速率）
技术无关的：不提及框架、语言、数据库或工具
以用户为中心的：从用户/业务角度描述结果，而不是系统内部
可验证的：可以在不知道实施细节的情况下测试/验证

好的示例：

"用户可以在 3 分钟内完成结账"
"系统支持 10,000 个并发用户"
"95% 的搜索在 1 秒内返回结果"
"任务完成率提高 40%"

坏的示例（实施重点）：

"API 响应时间在 200ms 以下"（太技术化，使用"用户立即看到结果"）
"数据库可以处理 1000 TPS"（实施细节，使用面向用户的指标）
"React 组件高效渲染"（框架特定）
"Redis 缓存命中率超过 80%"（技术特定）

3. /speckit.clarify - 需求澄清工作流

description: 通过询问最多5个高度针对性的澄清问题并将答案编码回规格中，识别当前功能规格中规格不足的区域。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

概述

目标：检测并减少活动功能规格中的模糊性或缺失决策点，并将澄清直接记录在规格文件中。

注意：此澄清工作流预期在调用 /speckit.plan 之前运行（并完成）。如果用户明确表示他们跳过澄清（例如，探索性刺探），你可以继续，但必须警告下游返工风险增加。

执行步骤

检查先决条件：
- 从仓库根目录运行 .specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly 一次
- 解析最小 JSON 负载字段：FEATURE_DIR、FEATURE_SPEC、（可选捕获 IMPL_PLAN、TASKS）
- 如果 JSON 解析失败，中止并指示用户重新运行 /speckit.specify 或验证功能分支环境
结构化模糊性和覆盖扫描：
- 加载当前规格文件，使用此分类法执行结构化模糊性和覆盖扫描
- 对于每个类别，标记状态：清晰/部分/缺失
- 生成用于优先级排序的内部覆盖映射（除非不问问题，否则不要输出原始映射）
扫描类别包括：
- 功能范围和行为：核心用户目标、成功标准、明确超出范围声明、用户角色区分
- 领域和数据模型：实体属性关系、身份唯一性规则、生命周期状态转换、数据量假设
- 交互和 UX 流程：关键用户旅程、错误空加载状态、可访问性本地化说明
- 非功能质量属性：性能延迟吞吐量、可扩展性、可靠性可用性、可观察性、安全性隐私、合规约束
- 集成和外部依赖项：外部服务API故障模式、数据导入导出格式、协议版本假设
- 边缘情况和故障处理：负面场景、速率限制节流、冲突解决
- 约束和权衡：技术约束、明确权衡或拒绝替代方案
- 术语和一致性：规范词汇表、避免同义词弃用术语
- 完成信号：验收标准可测试性、可测量完成定义指标
- 杂项占位符：TODO标记、缺乏量化的模糊形容词
生成优先排序的澄清问题队列：
- 生成（内部）优先排序的候选澄清问题队列（最多 5 个）
- 应用约束：
  - 整个会话最多 10 个问题
  - 每个问题必须可以用：简短多项选择（2-5个选项）或一个词/短词组答案（≤5个词）
  - 仅包括答案实质性影响架构、数据建模、任务分解、测试设计、UX行为、运营准备或合规验证的问题
  - 确保类别覆盖平衡，优先覆盖最高影响的未解决类别
  - 排除已经回答的问题、琐碎风格偏好或规划级别执行细节
  - 优先选择减少下游返工风险或防止错误对齐验收测试的澄清
  - 如果超过 5 个类别仍未解决，选择前 5 个按（影响 * 不确定性）启发式方法
顺序问题循环（交互式）：
- 一次只呈现一个问题
- 对于多项选择问题，将选项呈现为 Markdown 表格：
  
  | 选项 | 描述 |
  |-----|------------------|---------------------|
  | A | <选项 A 描述> |
  | B | <选项 B 描述> |
  | C | <选项 C 描述> | （根据需要添加 D/E，最多 5 个） |
  | 自定义 | 提供不同的简短答案（≤5 个词） |
- 对于简短答案样式，在问题后输出单行：格式：简短答案（≤5 个词）
- 用户回答后：
  - 验证答案映射到一个选项或符合 ≤5 个词约束
  - 如果模糊，要求快速消除歧义（计数仍属于同一问题；不要推进）
  - 一旦满意，在工作记忆中记录它（尚未写入磁盘）并移动到下一个排队问题
- 停止询问条件：
  - 所有关键模糊性早期解决
  - 用户发出完成信号
  - 你达到 5 个询问的问题
- 永远不要提前透露未来排队的问题
- 如果开始时没有有效问题，立即报告没有关键模糊性
增量更新方法（每个接受答案后）：
- 维护规格的内存表示（开始时加载一次）加上原始文件内容
- 对于此会话中的第一个集成答案：
  - 确保存在 ## 澄清 部分（如果缺失，在规格模板的最高级别上下文/概述部分之后创建它）
  - 在其下，创建今天的 ### 会话 YYYY-MM-DD 子标题
- 接受后立即追加项目符号行：- 问：<问题> → 答：<最终答案>
- 立即将澄清应用于最合适的部分：
  - 功能模糊性 → 更新或添加功能需求中的项目符号
  - 用户交互/行动者区别 → 更新用户故事或行动者子部分
  - 数据形状/实体 → 更新数据模型（添加字段、类型、关系），保留排序
  - 非功能约束 → 添加/修改可测量标准（将模糊形容词转换为指标或明确目标）
  - 边缘情况/负面流程 → 添加新项目符号
  - 术语冲突 → 跨规格规范化术语；仅在必要时保留原始术语
- 如果澄清使较早的模糊陈述无效，则替换该陈述而不是重复
- 在每次集成后保存规格文件以最小化上下文丢失风险（原子覆盖）
- 保留格式：不要重新排序不相关的部分；保持标题层次结构完整
- 保持每个插入的澄清最小且可测试（避免叙事漂移）
验证（每次写入后加上最终执行）：
- 澄清会话包含每个接受答案的确切一个项目符号（无重复）
- 总询问（接受）问题 ≤ 5
- 更新的部分不包含剩余模糊占位符
- 不存在矛盾的较早陈述
- Markdown 结构有效；只允许新标题：## 澄清、### 会话 YYYY-MM-DD
- 术语一致性：所有更新部分使用相同的规范术语
写回更新的规格：
- 将更新的规格写回 FEATURE_SPEC
报告完成：
- 询问和回答的问题数量
- 更新规格的路径
- 接触的部分（列出名称）
- 覆盖摘要表，列出每个分类类别，状态：已解决、推迟、清晰、突出
- 如果任何突出或推迟仍然存在，建议是否继续到 /speckit.plan 或稍后在规划后再次运行 /speckit.clarify
- 建议的下一个命令

行为规则

如果没有发现有意义的模糊性，回应："没有检测到值得正式澄清的关键模糊性。"并建议继续
如果规格文件缺失，指示用户先运行 /speckit.specify
永远不要超过总共 5 个询问问题（单个问题的澄清重试不计为新问题）
避免推测性技术栈问题，除非缺失阻塞功能清晰性
尊重用户早期终止信号（"停止"、"完成"、"继续"）
如果由于全覆盖而没有问问题，输出紧凑的覆盖摘要然后建议推进
如果配额达到但仍有关键影响类别未解决，在推迟下明确标记它们并附上理由

4. /speckit.plan - 架构设计工作流

description: 使用计划模板执行实施规划工作流以生成设计文档。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

概述

设置：
- 从仓库根目录运行 .specify/scripts/powershell/setup-plan.ps1 -Json
- 并解析 JSON 中的 FEATURE_SPEC、IMPL_PLAN、SPECS_DIR、BRANCH
加载上下文：
- 读取 FEATURE_SPEC 和 .specify/memory/constitution.md
- 加载 IMPL_PLAN 模板（已复制）
执行计划工作流：
- 按照 IMPL_PLAN 模板中的结构：
  - 填充技术上下文（将未知标记为"需要澄清"）
  - 从宪法填充宪法检查部分
  - 评估门（如果违规无正当理由则错误）
  - 阶段 0：生成 research.md（解决所有需要澄清）
  - 阶段 1：生成 data-model.md、contracts/、quickstart.md
  - 阶段 1：通过运行代理脚本更新代理上下文
  - 设计后重新评估宪法检查
停止并报告：
- 命令在阶段 2 规划后结束
- 报告分支、IMPL_PLAN 路径和生成的文档

阶段

阶段 0：大纲和研究

从技术上下文中提取未知项：
- 对于每个需要澄清 → 研究任务
- 对于每个依赖项 → 最佳实践任务
- 对于每个集成 → 模式任务

生成和调度研究代理：

arduino 复制代码

对于技术上下文中的每个未知项：
  任务："为{功能上下文}研究{未知项}"
对于每个技术选择：
  任务："在{域}中找到{技术}的最佳实践"

整合发现到 research.md：
- 决策：[选择了什么]
- 理由：[为什么选择]
- 考虑的替代方案：[还评估了什么]

输出：research.md 解决所有需要澄清

阶段 1：设计和合约

先决条件 ：research.md 完成

从功能规格提取实体 → data-model.md：
- 实体名称、字段、关系
- 来自需求的验证规则
- 状态转换（如果适用）
从功能需求生成 API 合约：
- 对于每个用户操作 → 端点
- 使用标准 REST/GraphQL 模式
- 将 OpenAPI/GraphQL 模式输出到 /contracts/
代理上下文更新：
- 运行 .specify/scripts/powershell/update-agent-context.ps1 -AgentType claude
- 这些脚本检测正在使用哪个 AI 代理
- 更新适当的特定于代理的上下文文件
- 仅添加当前计划中的新技术
- 在标记之间保留手动添加

输出：data-model.md、/contracts/*、quickstart.md、特定于代理的文件

关键规则

使用绝对路径
门失败或未解决的澄清时错误

5. /speckit.tasks - 任务分解生成

description: 基于可用的设计文档为功能生成可操作的、依赖性排序的 tasks.md。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

概述

设置：
- 从仓库根目录运行 .specify/scripts/powershell/check-prerequisites.ps1 -Json
- 并解析 FEATURE_DIR 和 AVAILABLE_DOCS 列表
- 所有路径必须是绝对的
加载设计文档：
- 必需：plan.md（技术栈、库、结构），spec.md（带优先级的用户故事）
- 可选：data-model.md（实体），contracts/（API 端点），research.md（决策），quickstart.md（测试场景）
- 注意：不是所有项目都有所有文档。基于可用的内容生成任务
执行任务生成工作流（遵循模板结构）：
- 加载 plan.md 并提取技术栈、库、项目结构
- 加载 spec.md 并提取带优先级的用户故事（P1、P2、P3 等）
- 如果 data-model.md 存在：提取实体 → 映射到用户故事
- 如果 contracts/ 存在：每个文件 → 映射端点到用户故事
- 如果 research.md 存在：提取决策 → 生成设置任务
- 按用户故事组织生成任务 ：
  - 设置任务（所有故事需要的共享基础设施）
  - 基础任务（必须在任何用户故事可以开始之前完成的先决条件）
  - 对于每个用户故事（按优先级顺序 P1、P2、P3...）：
    - 分组完成该故事所需的所有任务
    - 包括该故事特定的模型、服务、端点、UI 组件
    - 标记哪些任务是 [P] 可并行的
    - 如果请求了测试：包括该故事特定的测试
  - 完善/集成任务（横切关注点）
- 测试是可选的：仅当功能规格中明确请求或用户要求 TDD 方法时生成测试任务
- 应用任务规则：
  - 不同文件 = 标记 [P] 用于并行
  - 相同文件 = 顺序（无 [P]）
  - 如果请求了测试：实施前的测试（TDD 顺序）
- 顺序编号任务（T001、T002...）
- 生成显示用户故事完成顺序的依赖关系图
- 为每个用户故事创建并行执行示例
- 验证任务完整性（每个用户故事都有所有需要的任务，独立可测试）
生成 tasks.md：
- 使用 .specify.specify/templates/tasks-template.md 作为结构，填充：
  - plan.md 中的正确功能名称
  - 阶段 1：设置任务（项目初始化）
  - 阶段 2：基础任务（所有用户故事的阻塞先决条件）
  - 阶段 3+：每个用户故事一个阶段（按规格中的优先级顺序）
    - 每个阶段包括：故事目标、独立测试标准、测试（如果请求）、实施任务
    - 清晰的 [故事] 标签（US1、US2、US3...）用于每个任务
    - 每个故事内可并行任务的 [P] 标记
    - 每个故事阶段后的检查点标记
  - 最终阶段：完善和横切关注点
  - 执行顺序的编号任务（T001、T002...）
  - 每个任务的清晰文件路径
  - 显示故事完成顺序的依赖项部分
  - 每个故事的并行执行示例
  - 实施策略部分（MVP 优先，增量交付）
报告：
- 输出生成的 tasks.md 路径和摘要：
  - 总任务计数
  - 每个用户故事的任务计数
  - 识别的并行机会
  - 每个故事的独立测试标准
  - 建议的 MVP 范围（通常只是用户故事 1）

tasks.md 应该是立即可执行的 - 每个任务必须足够具体，以便 LLM 可以在没有额外上下文的情况下完成它。

任务生成规则

重要：测试是可选的。仅当用户明确请求测试或 TDD 方法时生成测试任务。

关键：任务必须按用户故事组织以启用独立实施和测试。

1. 来自用户故事（spec.md）- 主要组织

每个用户故事（P1、P2、P3...）获得自己的阶段
将所有相关组件映射到它们的故事：
- 该故事需要的模型
- 该故事需要的服务
- 该故事需要的端点/UI
- 如果请求了测试：该故事特定的测试
标记故事依赖项（大多数故事应该是独立的）

2. 来自合约

将每个合约/端点 → 映射到它服务的用户故事
如果请求了测试：每个合约 → 合约测试任务 [P] 在该故事阶段的实施之前

3. 来自数据模型

将每个实体 → 映射到需要它的用户故事
如果实体服务多个故事：放在最早的故事或设置阶段
关系 → 适当故事阶段中的服务层任务

4. 来自设置/基础设施

共享基础设施 → 设置阶段（阶段 1）
基础/阻塞任务 → 基础阶段（阶段 2）
- 示例：数据库模式设置、身份验证框架、核心库、基础配置
- 这些必须在任何用户故事可以实施之前完成
故事特定设置 → 在该故事的阶段内

5. 排序

阶段 1：设置（项目初始化）
阶段 2：基础（阻塞先决条件 - 必须在用户故事之前完成）
阶段 3+：按优先级顺序的用户故事（P1、P2、P3...）
- 每个故事内：测试（如果请求）→ 模型 → 服务 → 端点 → 集成
最终阶段：完善和横切关注点
每个用户故事阶段应该是一个完整的、独立可测试的增量

6. /speckit.analyze - 跨文档一致性分析

description: 在任务生成后，对 spec.md、plan.md 和 tasks.md 执行非破坏性的跨文档一致性和质量分析。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

目标

在实施之前，识别三个核心文档（spec.md、plan.md、tasks.md）之间的不一致、重复、模糊和未指定项。此命令必须仅在 /tasks 成功生成完整的 tasks.md 后运行。

操作约束

严格只读 ：不要修改任何文件。输出结构化的分析报告。提供可选的修复计划（用户必须明确批准后才会手动调用任何后续编辑命令）。

宪法权威 ：项目宪法（.specify/memory/constitution.md）在此分析范围内是不可协商的 。宪法冲突自动为关键级别，需要调整规格、计划或任务------而不是稀释、重新解释或默默忽略该原则。如果某个原则本身需要更改，必须在 /analyze 之外进行单独、明确的宪法更新。

执行步骤

1. 初始化分析上下文

从仓库根目录运行一次 .specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
解析 JSON 中的 FEATURE_DIR 和 AVAILABLE_DOCS
推导绝对路径：
- SPEC = FEATURE_DIR/spec.md
- PLAN = FEATURE_DIR/plan.md
- TASKS = FEATURE_DIR/tasks.md
如果任何必需文件缺失，则中止并显示错误消息（指示用户运行缺失的先决条件命令）

2. 加载文档（渐进式披露）

仅从每个文档加载最小的必要上下文：

从 spec.md：

概述/上下文
功能需求
非功能需求
用户故事
边缘情况（如果存在）

从 plan.md：

架构/技术栈选择
数据模型引用
阶段
技术约束

从 tasks.md：

任务 ID
描述
阶段分组
并行标记 [P]
引用的文件路径

从宪法：

加载 .specify/memory/constitution.md 进行原则验证

3. 构建语义模型

创建内部表示（不要在输出中包含原始文档）：

需求清单 ：每个功能和非功能需求，具有稳定的键（基于祈使短语派生 slug；例如，"User can upload file" → user-can-upload-file）
用户故事/操作清单：具有验收标准的离散用户操作
任务覆盖映射：将每个任务映射到一个或多个需求或故事（通过关键字/显式引用模式如 ID 或关键短语推断）
宪法规则集：提取原则名称和 MUST/SHOULD 规范性陈述

4. 检测扫描（Token 高效分析）

专注于高信号发现。限制总共 50 个发现；在溢出摘要中聚合其余部分。

A. 重复检测

识别近乎重复的需求
标记较低质量的措辞以进行合并

B. 模糊性检测

标记缺乏可测量标准的模糊形容词（快速、可扩展、安全、直观、健壮）
标记未解决的占位符（TODO、TKTK、???、<placeholder> 等）

C. 规格不足

有动词但缺少对象或可测量结果的需求
缺少验收标准对齐的用户故事
引用规格/计划中未定义文件或组件的任务

D. 宪法对齐

任何与 MUST 原则冲突的需求或计划元素
宪法中缺失的强制性部分或质量门

E. 覆盖缺口

没有关联任务的需求
没有映射需求/故事的任务
未在任务中反映的非功能需求（例如，性能、安全性）

F. 不一致性

术语漂移（相同概念在不同文件中命名不同）
计划中引用但规格中缺失的数据实体（或反之）
任务排序矛盾（例如，集成任务在基础设置任务之前而没有依赖说明）
冲突的需求（例如，一个要求 Next.js 而另一个指定 Vue）

5. 严重性分配

使用此启发式方法对发现进行优先级排序：

关键：违反宪法 MUST、缺失核心规格文档或零覆盖的需求阻塞基线功能
高：重复或冲突的需求、模糊的安全/性能属性、不可测试的验收标准
中：术语漂移、缺少非功能任务覆盖、规格不足的边缘情况
低：样式/措辞改进、不影响执行顺序的轻微冗余

6. 生成紧凑分析报告

输出 Markdown 报告（不写入文件），具有以下结构：

规格分析报告

ID	类别	严重性	位置	摘要	建议
A1	重复	高	spec.md:L120-134	两个相似的需求...	合并措辞；保留更清晰的版本

（为每个发现添加一行；生成以类别首字母为前缀的稳定 ID。）

覆盖摘要表：

需求键	有任务？	任务 ID	备注

宪法对齐问题：（如果有）

未映射任务：（如果有）

指标：

总需求数
总任务数
覆盖百分比（具有 >=1 个任务的需求）
模糊性计数
重复计数
关键问题计数

7. 提供下一步行动

在报告末尾，输出简洁的下一步行动块：

如果存在关键问题：建议在 /implement 之前解决
如果只有低/中级别：用户可以继续，但提供改进建议
提供明确的命令建议：例如，"运行 /specify 进行优化"、"运行 /plan 调整架构"、"手动编辑 tasks.md 为 'performance-metrics' 添加覆盖"

8. 提供修复

询问用户："你想让我为前 N 个问题建议具体的修复编辑吗？"（不要自动应用它们。）

操作原则

上下文效率

最小高信号 token：专注于可行的发现，而不是详尽的文档
渐进式披露：增量加载文档；不要将所有内容转储到分析中
Token 高效输出：限制发现表为 50 行；总结溢出
确定性结果：在没有更改的情况下重新运行应产生一致的 ID 和计数

分析指南

永远不要修改文件（这是只读分析）
永远不要虚构缺失部分（如果不存在，准确报告）
优先处理宪法违规（这些总是关键级别）
使用示例而不是详尽规则（引用具体实例，而不是通用模式）
优雅地报告零问题（发出带有覆盖统计的成功报告）

7. /speckit.implement - 实现计划执行

description: 通过处理和执行 tasks.md 中定义的所有任务来执行实施计划。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

概述

检查先决条件：
- 从仓库根目录运行 .specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
- 并解析 FEATURE_DIR 和 AVAILABLE_DOCS 列表
- 所有路径必须是绝对的
检查检查清单状态（如果 FEATURE_DIR/checklists/ 存在）：
- 扫描 checklists/ 目录中的所有检查清单文件
- 对于每个检查清单，计算：
  - 总项目数：所有匹配 - [ ] 或 - [X] 或 - [x] 的行
  - 已完成项目数：匹配 - [X] 或 - [x] 的行
  - 未完成项目数：匹配 - [ ] 的行
- 创建状态表：
  
  检查清单总数已完成未完成状态
  
  ux.md 12 12 0 ✓ 通过
  
  test.md 8 5 3 ✗ 失败
  
  security.md 6 6 0 ✓ 通过
- 计算整体状态：
  - 通过：所有检查清单都有 0 个未完成项目
  - 失败：一个或多个检查清单有未完成项目
- 如果任何检查清单不完整：
  - 显示带有未完成项目计数的表
  - 停止并询问："一些检查清单不完整。你是否要继续实施？（是/否）"
  - 在继续前等待用户响应
  - 如果用户说"否"或"等待"或"停止"，则停止执行
  - 如果用户说"是"或"继续"或"进行"，则继续到步骤 3
- 如果所有检查清单都完成：
  - 显示显示所有检查清单通过的表
  - 自动继续到步骤 3
加载和分析实施上下文：
- 必需：读取 tasks.md 获取完整任务列表和执行计划
- 必需：读取 plan.md 获取技术栈、架构和文件结构
- 如果存在：读取 data-model.md 获取实体和关系
- 如果存在：读取 contracts/ 获取 API 规格和测试需求
- 如果存在：读取 research.md 获取技术决策和约束
- 如果存在：读取 quickstart.md 获取集成场景
解析 tasks.md 结构：
- 任务阶段：设置、测试、核心、集成、完善
- 任务依赖项：顺序与并行执行规则
- 任务细节：ID、描述、文件路径、并行标记 [P]
- 执行流程：顺序和依赖项要求
按照任务计划执行实施：
- 分阶段执行：在移动到下一个阶段之前完成每个阶段
- 尊重依赖项：按顺序运行顺序任务，并行任务 [P] 可以一起运行
- 遵循 TDD 方法：在相应的实施任务之前执行测试任务
- 基于文件的协调：影响相同文件的任务必须顺序运行
- 验证检查点：在继续之前验证每个阶段完成
实施执行规则：
- 设置优先：初始化项目结构、依赖项、配置
- 代码之前的测试：如果你需要为合约、实体和集成场景编写测试
- 核心开发：实施模型、服务、CLI 命令、端点
- 集成工作：数据库连接、中间件、日志记录、外部服务
- 完善和验证：单元测试、性能优化、文档
进度跟踪和错误处理：
- 在每个完成的任务后报告进度
- 如果任何非并行任务失败则停止执行
- 对于并行任务 [P]，继续成功的任务，报告失败的任务
- 提供带有调试上下文的清晰错误消息
- 如果实施无法继续则建议下一步骤
- 重要对于已完成的任务，确保在任务文件中将任务标记为 [X]
完成验证：
- 验证所有必需任务已完成
- 检查实施的功能是否与原始规格匹配
- 验证测试通过并且覆盖满足需求
- 确认实施遵循技术计划
- 报告带有已完成工作摘要的最终状态

检查清单	总数	已完成	未完成	状态
ux.md	12	12	0	✓ 通过
test.md	8	5	3	✗ 失败
security.md	6	6	0	✓ 通过

注意：此命令假设 tasks.md 中存在完整的任务分解。如果任务不完整或缺失，建议先运行 /tasks 重新生成任务列表。

8. /speckit.review - 检查清单管理

注意：这个命令实际上对应之前的 speckit.checklist - 需求质量检查清单生成工具

description: 根据用户需求为当前功能生成自定义检查清单。

检查清单目的："英语的单元测试"

关键概念 ：检查清单是需求写作的单元测试 - 它们验证给定领域中需求的质量、清晰度和完整性。

不用于验证/测试：

❌ 不是"验证按钮点击正确"
❌ 不是"测试错误处理正常工作"
❌ 不是"确认 API 返回 200"
❌ 不检查代码/实现是否与规格匹配

用于需求质量验证：

✅ "是否为所有卡片类型定义了视觉层次需求？"（完整性）
✅ "'突出显示'是否通过具体尺寸/位置进行量化？"（清晰度）
✅ "所有交互元素的悬停状态需求是否一致？"（一致性）
✅ "是否为键盘导航定义了可访问性需求？"（覆盖性）
✅ "规格是否定义了标志图像加载失败时会发生什么？"（边缘情况）

比喻：如果你的规格是用英语编写的代码，那么检查清单就是它的单元测试套件。你在测试需求是否编写良好、完整、明确并准备好实施 - 而不是实施是否正常工作。

用户输入

bash 复制代码

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

执行步骤

设置：
- 从仓库根目录运行 .specify/scripts/powershell/check-prerequisites.ps1 -Json
- 并解析 JSON 中的 FEATURE_DIR 和 AVAILABLE_DOCS 列表
- 所有文件路径必须是绝对的
澄清意图（动态）：
- 派生最多三个初始上下文澄清问题（无预制目录）
- 它们必须：
  - 从用户的措辞 + 从规格/计划/任务中提取的信号生成
  - 只询问实质性改变检查清单内容的信息
  - 如果在 $ARGUMENTS 中已经明确，则单独跳过
  - 优先精确性而不是广度
生成算法：
1. 提取信号：功能域关键词（例如，认证、延迟、UX、API）、风险指标（"关键"、"必须"、"合规"）、利益相关者提示（"QA"、"审查"、"安全团队"）和明确的交付物（"a11y"、"回滚"、"合约"）
2. 将信号聚类为候选焦点区域（最多 4 个），按相关性排序
3. 如果没有明确，检测可能的受众和时间（作者、审查者、QA、发布）
4. 检测缺失维度：范围广度、深度/严谨性、风险重点、排除边界、可测量验收标准
5. 从这些原型中制定问题：
  - 范围细化（例如，"这应该包括与 X 和 Y 的集成接触点还是仅限于本地模块正确性？"）
  - 风险优先级排序（例如，"这些潜在风险区域中哪些应该接收强制性门控检查？"）
  - 深度校准（例如，"这是轻量级预提交理智列表还是正式发布门？"）
  - 受众框架（例如，"这将仅由作者使用还是 PR 审查期间的同行使用？"）
  - 边界排除（例如，"我们本轮是否明确排除性能调整项目？"）
  - 场景类别缺口（例如，"未检测到恢复流程------回滚/部分失败路径在范围内吗？"）
问题格式化规则：
- 如果提供选项，生成包含列的紧凑表格：选项 | 候选 | 为何重要
- 最多限制到 A-E 选项；如果自由形式答案更清晰，则省略表格
- 永远不要要求用户重述他们已经说过的内容
- 避免推测类别（无虚构）。如果不确定，明确询问："确认 X 是否属于范围。"
无法交互时的默认值：
- 深度：标准
- 受众：如果与代码相关则为审查者（PR）；否则为作者
- 焦点：前 2 个相关性聚类
输出问题（标记为 Q1/Q2/Q3）。回答后：如果仍有 ≥2 个场景类别（替代/异常/恢复/非功能域）不清楚，你可以再问最多两个有针对性的后续问题（Q4/Q5），每个有一行理由。如果用户明确拒绝更多，则不要升级。
理解用户请求：
- 结合 $ARGUMENTS + 澄清答案
- 推导检查清单主题（例如，安全、审查、部署、ux）
- 整合用户提及的明确必须项目
- 将焦点选择映射到类别脚手架
- 从规格/计划/任务中推断任何缺失上下文（不要虚构）
加载功能上下文：
- 从 FEATURE_DIR 读取：
  - spec.md：功能需求和范围
  - plan.md（如果存在）：技术细节、依赖项
  - tasks.md（如果存在）：实施任务
上下文加载策略：
- 仅加载与活动焦点区域相关的必要部分（避免全文件转储）
- 优先将长部分总结为简洁的场景/需求项目符号
- 使用渐进式披露：仅在检测到缺口时添加后续检索
- 如果源文档很大，生成中间摘要项目而不是嵌入原始文本
生成检查清单 - 创建"需求的单元测试"：
- 如果 FEATURE_DIR/checklists/ 目录不存在，则创建它
- 生成唯一的检查清单文件名：
  - 使用基于域的简短描述性名称（例如，ux.md、api.md、security.md）
  - 格式：[domain].md
  - 如果文件存在，则附加到现有文件
- 从 CHK001 开始顺序编号项目
- 每次 /speckit.review 运行都会创建新文件（永不覆盖现有检查清单）
核心原则 - 测试需求，而不是实施：每个检查清单项目必须评估需求本身，用于：
- 完整性：是否存在所有必要的需求？
- 清晰度：需求是否明确和具体？
- 一致性：需求是否相互对齐？
- 可测量性：需求是否可以客观验证？
- 覆盖性：是否处理了所有场景/边缘情况？
类别结构 - 按需求质量维度分组项目：
- 需求完整性（是否记录了所有必要的需求？）
- 需求清晰度（需求是否具体和明确？）
- 需求一致性（需求是否无冲突地对齐？）
- 验收标准质量（成功标准是否可测量？）
- 场景覆盖（是否处理了所有流程/情况？）
- 边缘情况覆盖（是否定义了边界条件？）
- 非功能需求（性能、安全性、可访问性等 - 是否指定？）
- 依赖项和假设（是否记录和验证？）
- 模糊性和冲突（什么需要澄清？）
如何编写检查清单项目 - "英语的单元测试"：

❌ 错误（测试实施）：
- "验证着陆页显示 3 个剧集卡片"
- "测试桌面上的悬停状态正常工作"
- "确认标志点击导航到主页"
✅ 正确（测试需求质量）：
- "是否明确指定了特色剧集的数量和布局？" [完整性]
- "'突出显示'是否通过具体尺寸/位置进行量化？" [清晰度]
- "所有交互元素的悬停状态需求是否一致？" [一致性]
- "是否为所有交互 UI 定义了键盘导航需求？" [覆盖性]
- "是否指定了标志图像加载失败时的回退行为？" [边缘情况]
- "是否为异步剧集数据定义了加载状态需求？" [完整性]
- "规格是否为竞争性 UI 元素定义了视觉层次？" [清晰度]
项目结构：每个项目应遵循此模式：
- 询问需求质量的问题格式
- 专注于规格/计划中写入的（或未写入的）内容
- 在括号中包含质量维度 [完整性/清晰度/一致性等]
- 检查现有需求时引用规格部分 [规格 §X.Y]
- 检查缺失需求时使用 [缺口] 标记
按质量维度的示例：

完整性：
- "是否为所有 API 故障模式定义了错误处理需求？" [缺口]
- "是否为所有交互元素指定了可访问性需求？" [完整性]
- "是否为响应式布局定义了移动断点需求？" [缺口]
清晰度：
- "'快速加载'是否通过具体时间阈值进行量化？" [清晰度, 规格 §NFR-2]
- "'相关剧集'选择标准是否明确定义？" [清晰度, 规格 §FR-5]
- "'突出'是否通过可测量的视觉属性定义？" [模糊性, 规格 §FR-4]
一致性：
- "所有页面的导航需求是否对齐？" [一致性, 规格 §FR-10]
- "着陆页和详情页之间的卡片组件需求是否一致？" [一致性]
覆盖性：
- "是否为零状态场景（无剧集）定义了需求？" [覆盖性, 边缘情况]
- "是否处理了并发用户交互场景？" [覆盖性, 缺口]
- "是否为部分数据加载故障指定了需求？" [覆盖性, 异常流程]
可测量性：
- "视觉层次需求是否可测量/可测试？" [验收标准, 规格 §FR-1]
- "'平衡视觉权重'是否可以客观验证？" [可测量性, 规格 §FR-2]
场景分类和覆盖（需求质量焦点）：
- 检查是否存在以下需求：主要、替代、异常/错误、恢复、非功能场景
- 对于每个场景类别，询问："[场景类型]需求是否完整、清晰和一致？"
- 如果场景类别缺失："[场景类型]需求是故意排除还是缺失？" [缺口]
- 当状态突变发生时包括弹性/回滚："是否为迁移故障定义了回滚需求？" [缺口]
可追溯性要求：
- 最少：≥80% 的项目必须包含至少一个可追溯性引用
- 每个项目应引用：规格部分 [规格 §X.Y]，或使用标记：[缺口]、[模糊性]、[冲突]、[假设]
- 如果没有 ID 系统："是否建立了需求和验收标准 ID 方案？" [可追溯性]
Surface 并解决 Issues（需求质量问题）：询问关于需求本身的问题：
- 模糊性："术语'快速'是否通过具体指标量化？" [模糊性, 规格 §NFR-1]
- 冲突："§FR-10 和 §FR-10a 之间的导航需求是否冲突？" [冲突]
- 假设："始终可用的播客 API'假设是否经过验证？" [假设]
- 依赖项："外部播客 API 需求是否已记录？" [依赖项, 缺口]
- 缺失定义："'视觉层次'是否通过可测量标准定义？" [缺口]
内容整合：
- 软限制：如果原始候选项目 > 40，按风险/影响优先级排序
- 合并近乎重复的检查相同需求方面的项目
- 如果 >5 个低影响边缘情况，创建一个项目："是否在需求中解决了边缘情况 X、Y、Z？" [覆盖性]
🚫 绝对禁止 - 这些使其成为实施测试，而不是需求测试：
- ❌ 任何以"验证"、"测试"、"确认"、"检查" + 实施行为开始的项目
- ❌ 对代码执行、用户操作、系统行为的引用
- ❌ "正确显示"、"正常工作"、"按预期运行"
- ❌ "点击"、"导航"、"渲染"、"加载"、"执行"
- ❌ 测试用例、测试计划、QA 程序
- ❌ 实施细节（框架、API、算法）
✅ 必需模式 - 这些测试需求质量：
- ✅ "是否为[场景]定义/指定/记录了[需求类型]？"
- ✅ "[模糊术语]是否通过具体标准量化/澄清？"
- ✅ "[部分 A] 和 [部分 B] 之间的需求是否一致？"
- ✅ "[需求]是否可以客观测量/验证？"
- ✅ "是否在需求中解决了[边缘情况/场景]？"
- ✅ "规格是否定义了[缺失方面]？"
结构引用：
- 按照 .specify/templates/checklist-template.md 中的规范模板生成检查清单
- 包括标题、meta 部分、类别标题和 ID 格式化
- 如果模板不可用，使用：H1 标题、目的/创建 meta 行、包含 - [ ] CHK### <需求项目> 行的 ## 类别部分，从 CHK001 开始全局递增 ID
报告：
- 输出创建的检查清单的完整路径、项目计数
- 提醒用户每次运行都会创建新文件
- 总结：
  - 选择的焦点区域
  - 深度级别
  - 行动者/时间
  - 任何明确指定的用户必须项目

重要：每次 /speckit.review 命令调用都会创建使用简短描述性名称的检查清单文件，除非文件已存在。这允许：

不同类型的多个检查清单（例如，ux.md、test.md、security.md）
简单、易记的文件名，指示检查清单目的
在 checklists/ 文件夹中轻松识别和导航

为避免杂乱，使用描述性类型并在完成后清理过时的检查清单。

检查清单类型和项目示例

UX 需求质量 ：ux.md

示例项目（测试需求，而不是实施）：

"是否通过可测量标准定义了视觉层次需求？" [清晰度, 规格 §FR-1]
"是否明确指定了 UI 元素的数量和位置？" [完整性, 规格 §FR-1]
"交互状态需求（悬停、焦点、活动）是否一致定义？" [一致性]
"是否为所有交互元素指定了可访问性需求？" [覆盖性, 缺口]
"是否在图像加载失败时定义了回退行为？" [边缘情况, 缺口]
"'突出显示'是否可以客观测量？" [可测量性, 规格 §FR-4]

API 需求质量 ：api.md

示例项目：

"是否为所有故障场景指定了错误响应格式？" [完整性]
"是否通过具体阈值量化了速率限制需求？" [清晰度]
"所有端点的身份验证需求是否一致？" [一致性]
"是否为外部依赖项定义了重试/超时需求？" [覆盖性, 缺口]
"是否在需求中记录了版本控制策略？" [缺口]

性能需求质量 ：performance.md

示例项目：

"是否通过具体指标量化了性能需求？" [清晰度]
"是否为所有关键用户旅程定义了性能目标？" [覆盖性]
"是否指定了不同负载条件下的性能需求？" [完整性]
"性能需求是否可以客观测量？" [可测量性]
"是否为高负载场景定义了降级需求？" [边缘情况, 缺口]

安全需求质量 ：security.md

示例项目：

"是否为所有受保护资源指定了身份验证需求？" [覆盖性]
"是否为敏感信息定义了数据保护需求？" [完整性]
"是否记录了威胁模型并使需求与其对齐？" [可追溯性]
"安全需求是否与合规义务一致？" [一致性]
"是否定义了安全故障/违规响应需求？" [缺口, 异常流程]

反示例：什么不该做

❌ 错误 - 这些测试实施，而不是需求：

markdown 复制代码

- [ ] CHK001 - 验证着陆页显示 3 个剧集卡片 [规格 §FR-001]
- [ ] CHK002 - 测试桌面上的悬停状态正确工作 [规格 §FR-003]
- [ ] CHK003 - 确认标志点击导航到主页 [规格 §FR-010]
- [ ] CHK004 - 检查相关剧集部分显示 3-5 个项目 [规格 §FR-005]

✅ 正确 - 这些测试需求质量：

markdown 复制代码

- [ ] CHK001 - 是否明确指定了特色剧集的数量和布局？" [完整性, 规格 §FR-001]
- [ ] CHK002 - 是否为所有交互元素一致定义了悬停状态需求？" [一致性, 规格 §FR-003]
- [ ] CHK003 - 是否为所有可点击品牌元素清晰地定义了导航需求？" [清晰度, 规格 §FR-010]
- [ ] CHK004 - 是否记录了相关剧集的选择标准？" [缺口, 规格 §FR-005]
- [ ] CHK005 - 是否为异步剧集数据定义了加载状态需求？" [缺口]
- [ ] CHK006 - "视觉层次"需求是否可以客观测量？" [可测量性, 规格 §FR-001]

关键区别：

错误：测试系统是否正常工作
正确：测试需求是否正确编写
错误：行为验证
正确：需求质量验证
错误："它是否做 X？"
正确："X 是否明确指定？"

总结

Spec-Kit 提供了完整的 AI 辅助开发工作流程，通过以下标准化顺序确保软件开发的高质量和一致性：

🔧 标准命令执行顺序：

/speckit.constitution - 项目宪法管理（设置治理原则）
/speckit.specify - 功能规格创建（从需求到规格）
/speckit.clarify - 需求澄清工作流（解决模糊性）
/speckit.plan - 架构设计工作流（技术设计）
/speckit.tasks - 任务分解生成（可执行任务）
/speckit.analyze - 跨文档一致性分析（质量检查）
/speckit.implement - 实现计划执行（代码实现）
/speckit.review - 检查清单管理（质量验证）

💡 核心价值：

端到端管理：覆盖需求规格化到代码实现全流程
AI优化设计：专为与Claude等AI助手协作而优化
质量保证：内置多层次验证机制确保交付质量
知识沉淀：项目宪法、设计决策完整记录
效率提升：标准化流程减少沟通成本，加速开发迭代

立即开始使用 Spec-Kit，体验 AI 驱动的高效软件开发新范式！

#AI辅助开发 #软件开发 #项目管理 #SpecKit #工具推荐