实战笔记

安装 spec-kit

powershell 安装执行

# 1. 安装 uv
irm https://astral.sh/uv/install.ps1 | iex

# 2. 重新打开 PowerShell

# 3. 验证 uv
uv --version

# 4. 安装 Spec-Kit CLI
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 5. 验证安装
specify --help

输出下面的信息代表成功

> specify --help
                                                                    ███████╗██████╗ ███████╗ ██████╗██╗███████╗██╗   ██╗
                                                                    ██╔════╝██╔══██╗██╔════╝██╔════╝██║██╔════╝╚██╗ ██╔╝
                                                                    ███████╗██████╔╝█████╗  ██║     ██║█████╗   ╚████╔╝
                                                                    ╚════██║██╔═══╝ ██╔══╝  ██║     ██║██╔══╝    ╚██╔╝
                                                                    ███████║██║     ███████╗╚██████╗██║██║        ██║
                                                                    ╚══════╝╚═╝     ╚══════╝ ╚═════╝╚═╝╚═╝        ╚═╝

                                                                     GitHub Spec Kit - Spec-Driven Development Toolkit

AI 编辑器中使用

如果你使用的是 cursor，可以

specify init --here --ai cursor --force

我这里是基于 vscode 的其他编辑器，比如 Trae 之类的

8 大文件

你看到的这一套，其实就是 SDD 的标准流水线：

需求 -> 理解 -> 规划 -> 拆解 -> 实现 -> 检查

对应关系如下：

文件 核心作用 通俗理解
speckit.constitution.md 项目总宪法 项目的最高原则：风格、架构、禁区
speckit.specify.md 需求规范化 把模糊想法变成“可执行需求”
speckit.clarify.md 澄清问题 查漏补缺：有没有矛盾、模糊点
speckit.plan.md 实现方案 技术路径设计，怎么做
speckit.tasks.md 任务拆解 拆成可执行步骤
speckit.analyze.md 影响分析 风险、影响范围评估
speckit.implement.md 正式编码 开始写代码
speckit.checklist.md 验收清单 自检/回归确认

Trae 如何操作？

这里参考 TRAE × Spec Kit 实战：五步构建流式 AI 对话 Web 应用

此处选择 GLM4.6+Builder 模式

制定项目宪章 - /speckit.constitution

目的：建立项目的核心治理原则和开发标准

配置建议：TRAE 配置使用 GPT-5 + Builder

执行命令：

注意⚠️：speckit.constitution.md 是通过 #号添加的 speckit.constitution.md 文件

#speckit.constitution.md  制定以代码质量、测试标准、用户体验一致性及性能要求为核心的原则

输出成果：生成 constitution.md 文件：

需求规格说明 - /speckit.specify

目的：描述要构建什么，专注于 what 和 why，而非技术实现

执行命令：

注意⚠️ ： # speckit.specify.md 是通过 #号添加的 speckit.specify.md 文件

#speckit.specify.md  我想做一个类似DeepSeek 的AI 深度思考，流式文字返回的 AI 对话 Web 应用，用户可以输入问题，AI 思考之后回答。可以查看、删除 AI 和  用户的对话历史，用户也可以建立新AI对话。

输出成果：生成 001-streaming-ai-chat 目录：

技术实现规划 - /speckit.plan

目的：指定实现技术栈、框架和架构设计

执行命令：

注意⚠️：# speckit.plan.md 需要用#号 选中 speckit.plan.md 文件

#speckit.plan.md 用vite react 实现前端页面。 glm4.6 的API 说明可以参考 https://docs.bigmodel.cn/cn/guide/models/text/glm-4.6

输出成果：生成包括 plan.md 文件的一些文档

任务分解 - /speckit.tasks

目的：将实现计划分解为详细的可执行任务

执行命令：

注意⚠️：# speckit.tasks.md 是通过#号 选中的 speckit.tasks.md 文件

  #speckit.tasks.md

输出成果：生成 tasks.md 文件

代码实现 - /speckit.implement

目的：根据任务列表执行具体的代码实现

配置建议：模型切换到 Claude-4 以获得更好的代码生成能力

执行命令：

注意⚠️ ： # speckit.implement.md 是通过#好选中 speckit.implement.md 文件

#speckit.implement.md

TRAE 会自动初始化环境：编辑 .gitignore，创建 vite react 环境。 （需要在终端按回车）

总结与实践建议

通过 Spec Kit 的五大核心命令，我们从项目宪章的制定，到需求规格的明确、技术规划的细化、任务分解的执行，直至代码实现的自动化生成，完整地构建了一个规范驱动的开发流程。

这个案例展示了 Spec Kit 如何将抽象的想法转化为可执行的 Web 应用原型，帮助开发者高效应对复杂交互场景。

8 大文件

这个问题问得非常关键，而且很多人第一次用 SDD 都会在这里“被劝退”。

先给你一个结论版：

❗不是每一个小需求都必须完整走 8 个步骤
✅ 8 个命令是一套“完整开发闭环”，可以按需求复杂度灵活裁剪

下面我用「人话 + 场景」帮你拆解。

一、这 8 个命令到底是干嘛的？

你看到的这一套，其实就是 SDD 的标准流水线：

需求 -> 理解 -> 规划 -> 拆解 -> 实现 -> 检查

对应关系如下：

文件 核心作用 通俗理解
speckit.constitution.md 项目总宪法 项目的最高原则：风格、架构、禁区
speckit.specify.md 需求规范化 把模糊想法变成“可执行需求”
speckit.clarify.md 澄清问题 查漏补缺：有没有矛盾、模糊点
speckit.plan.md 实现方案 技术路径设计，怎么做
speckit.tasks.md 任务拆解 拆成可执行步骤
speckit.analyze.md 影响分析 风险、影响范围评估
speckit.implement.md 正式编码 开始写代码
speckit.checklist.md 验收清单 自检/回归确认

二、它们的真实分工（更直观版本）

1. constitution – 项目宪法

长期存在，一般只写一次 内容包括：

  • 技术栈规范
  • 命名规则
  • 代码风格
  • 架构原则

👉 类似：项目最高法律，不是每个需求都重写。

2. specify – 把需求“说人话 → 说机器话”

作用：

  • 把：
    “加个登录限制”
    转成
    “用户连续失败5次锁定30分钟”

这是需求落地的第一步。

3. clarify – 逼问细节

作用：

  • 消灭模糊地带
  • 防止 AI 自由发挥

典型问题：

  • 锁定是按 IP 还是账号？
  • 是否需要邮件通知？
  • 管理员能否手动解锁？

4. plan – 技术路径设计

AI 或你会输出：

  • 涉及哪些模块
  • 是否新增字段
  • 接口是否调整

👉 类似技术方案说明。

5. tasks – 任务拆解

把 plan 变成执行清单，例如：

  • 修改 User 表字段
  • 新增 LockService
  • 修改登录接口逻辑
  • 增加单元测试

6. analyze – 影响分析

用于评估：

  • 是否影响已有功能？
  • 是否存在性能风险？
  • 是否有安全隐患？

适合复杂需求。

7. implement – 真正写代码

这一步才是真正产出代码。

8. checklist – 验收确认

相当于：

  • 自测清单
  • 回归检查表
  • 发布前核对

三、关键问题：每个小需求都走 8 步吗？

答案：不用，真不用。

现实推荐这样用：

✅ 小需求（改字段、加校验、加按钮）

推荐流程：

specify → implement → checklist

例如：

  • 按钮文案修改
  • 新增一个字段
  • 简单接口参数调整

✅ 中等需求（业务逻辑调整）

推荐流程：

specify → clarify → plan → tasks → implement → checklist

✅ 复杂需求 / 核心功能

完整流程：

specify → clarify → plan → tasks → analyze → implement → checklist

四、如何在 Trae + spec-kit 里“舒服地用”？

不是手动一个个翻文件，而是这样操作：

你在 Trae 输入：

按照 speckit 流程处理这个需求：新增接口访问日志分页查询

AI 会自动：

  1. 执行 specify 输出规范需求
  2. 执行 plan 输出方案
  3. 执行 tasks 输出步骤
  4. 再 implement 写代码

真正落地的方式是：
👉 把 8 步当成“工具箱”，而不是“宗教仪式”。

五、一句话总结

场景 建议
小改动 不必 8 步，全流程会拖慢你
中等功能 建议走 5~6 步
核心模块 建议完整走一遍

SDD 的目标不是让你更累，而是：

减少返工、减少 AI 幻觉、提高交付质量

参考资料

https://zhuanlan.zhihu.com/p/81614784593