用 AI 写代码久了，你会发现一个规律：一开始 "vibe coding" 确实很爽——自然语言一顿输出，模型哗哗吐代码，跑起来就留，跑不起来继续聊。但项目稍微复杂一点，问题就来了：需求散在聊天记录里，改着改着忘了最初要什么；团队协作时，review 只能盯着 diff 猜"你到底改了啥"。

解决思路其实不复杂：先把 What/Why 写清楚，再让 AI 去写 How。把规范当成你和 AI 之间的"收据"，双方先对齐，再动手。这样写出来的代码更可控，后期复盘也有据可查。

本章介绍两种不同层级的方案：

• 入门：Trae 原生的 Spec 模式 + Plan 模式，开箱即用
• 进阶：spec-kit（从 0 到 1 创建新项目） + OpenSpec（从 1 到 N 的长期迭代）

规范驱动开发（SDD）的核心思想

规范驱动开发（Spec-Driven Development）翻转了传统的 AI 编程范式。与其让 AI 猜测你想要什么，不如在写代码前就和 AI 达成一致：用可执行的、活生生的规范作为共同的理解基础。每个阶段的职责不是随便指挥一下，而是验证、反思、修正。

通常分为三部分：

• 规范（Spec）：用户旅程、需求、验收标准（What / Why）
• 计划（Plan）：技术栈、架构决策、约束条件（How 的框架）
• 任务（Tasks）：可执行的原子任务清单（怎么一步步落地）

关键点在于：每一步都有检查点。不是让 AI 一把梭，而是让 AI 先把东西写出来，我们审清楚，再让它写代码。这一步对团队协作尤其有用：因为你 review 的不只是代码，还能检查这次到底要改什么。

SDD 相比 Vibe 编程的核心优势

入门：Trae 原生 Spec + Plan 模式

Trae 内置了两种项目管理模式，无需额外安装工具。

在 Trae 的 Solo 模式中 使用 /plan、/spec 开启两种模式。

Spec和Plan两种模式的区别

• Spec 重流程，需求大纲(spec.md)->任务列表(task.md)-> 验收清单(checkList.md)
• Plan 重计划，偏粗粒度，最大的作用是帮你把需求和实现对明白
• Spec 的能力 包括了 Plan,也就是 Spec 可以代替 Plan

这两种模式的优势是零配置，直接在对话中使用。适合快速启动、轻量级管理；劣势是功能有限，缺乏审查、归档功能，无法处理复杂的项目管理场景。

进阶：spec-kit + OpenSpec 模式

spec-kit：适合 0→1 阶段的初次开发

如果要从零开始创建一个新项目，可以试试 spec-kit。它的长项在于能快速把一个模糊的想法，通过 Constitution → Specify → Plan → Tasks 这一套组合，拉成一个可执行的计划。

安装并初始化

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

# 创建一个新项目（会生成一个文件夹）
specify init <PROJECT_NAME>

# 或在现有项目中初始化
specify init . --ai claude
# or
specify init --here --ai claude

# 检查已安装的工具
specify check

注：specify init . --ai 后面可以接任何 ai agent，具体可见：支持的 AI 代理

怎么使用？

命令

基本命令：

可选命令

用于提升质量和验证的附加命令：

流程演示

1. 确立项目原则

使用 /speckit.constitution 命令来创建项目的指导原则和开发准则，这些原则将指导所有后续的开发工作。

/speckit.constitution 以"离线可复现 + 双入口共用同一套 Python 逻辑 + menu.json 单一事实源 + 严格校验与规范化写回 + 先过滤后抽样(闭区间) + seed 记录可复现 + 权重非法值在校验阶段拦截 + 候选为空必须有明确错误提示(CLI 非 0 退出/GUI 提示卡片) + CLI/GUI 在同菜单同区间同 seed 下必须抽中同一条目"为核心，制定项目开发准则与验收红线，并要求所有变更必须保持一致性与可解释性(记录 seed、区间、候选数等)。

2. 创建规格说明书

使用 /speckit.specify 命令来描述你想要构建的内容。重点关注做什么和为什么做，而不是技术栈。

/speckit.specify 做一个离线奶茶抽签小工具：用户输入 min/max 价格区间(闭区间)，系统从本地 menu.json 里的候选饮品中先过滤再按 weight 抽出一杯，并展示结果。工具必须同时提供 CLI 与 GUI 两种入口，且两者共用同一套 Python 业务逻辑，保证同一份菜单+同价格区间+同 seed 时结果完全一致。抽签结果需要记录 seed 与选中条目的 id/name(建议同时记录 brand/price、min/max、algorithm、过滤后候选数量)，用于复现与解释结果变化。禁止联网抓取真实门店菜单与实时价格，本次以本地 menu.json 为唯一数据源。

3. 制定技术实施方案

使用 /speckit.plan 命令来提供你的技术栈和架构选择。

/speckit.plan Python 3.12 + uv；将"菜单读取/校验/规范化导出/价格过滤/基于 seed 的加权抽样/菜单 CRUD 写回(含备份)"做成同一套可复用的 Python 核心模块，CLI 与 GUI 都只做薄封装以确保一致性。CLI 用 Typer 实现并至少提供 milktea validate、milktea export、milktea spin 以及菜单增删改查命令；GUI 用 pywebview 加载 frontend/index.html，前端通过 window.pywebview.api 调用 Python 侧 API 完成读取菜单、编辑写回与抽签；也允许改用本地 FastAPI 提供 CRUD 与抽签接口但必须复用同一套核心逻辑。抽签算法严格遵循：先按 min<=price<=max 过滤，候选为空时 CLI 非 0 退出且 stderr 提示、GUI 给明确提示；过滤后按 weight(缺省 1) 抽样，非法 weight 在校验阶段拦截；seed 可由用户提供或系统生成但必须记录并展示。环境安装：uv venv --python 3.12；uv pip install typer pywebview fastapi。

4. 拆分为具体任务

使用 /speckit.tasks 根据您的实施计划创建可操作的任务列表。

/speckit.tasks

5. 执行实施方案

使用 /speckit.implement 来执行所有任务，并根据计划构建您的功能特性。

/speckit.implement

OpenSpec：适合 1→n 的长期迭代

再来看 OpenSpec，它非常适合 1→n 阶段。GitHub 仓库：OpenSpec

OpenSpec: 1 → n 阶段的开发范式演进

❌ 传统开发（意图散失）

• 变更意图：散落在聊天记录中，过两天就丢，无法溯源
• 影响评估：改动了哪些能力、哪些边界？说不清，全凭经验猜
• 评审盲区：Review 只能翻代码 diff，看不见"需求到底变了什么"

✅ OpenSpec（规格真相）

• openspec/specs/ 沉淀当前真相，它是系统能力的唯一索引
• openspec/changes/ 容纳变更提案，让每一次演进意图显性化
• 先审需求，后写代码：通过后 Archive 合回 Specs，规格越用越完整

安装

OpenSpec 官方前置条件是 Node.js >= 20.19.0，先 node --version 看一眼。

npm install -g @fission-ai/openspec@latest

验证安装：

openspec --version

在项目中初始化 OpenSpec

cd my-project
openspec init

初始化时它会引导你选择要集成的 AI 工具，并在项目里生成 openspec/ 结构、以及必要的 agent 指令。

设置完成后会出现一段提示，类似于：

Next steps - Copy these prompts to Codex:
────────────────────────────────────────────────────────────

1. Populate your project context:
   "Please read openspec/project.md and help me fill it out
    with details about my project, tech stack, and conventions"

2. Create your first change proposal:
   "I want to add [YOUR FEATURE HERE]. Please create an
    OpenSpec change proposal for this feature"

3. Learn the OpenSpec workflow:
   "Please explain the OpenSpec workflow from openspec/AGENTS.md
    and how I should work with you on this project"

翻译：

下一步操作 - 将这些提示复制到 codex：
────────────────────────────────────────────────────────────

1. 填充项目上下文：
请阅读 openspec/project.md 并协助我完成内容填写
包含我的项目详情、技术栈及规范"

2. 创建您的首个变更提案：
我想添加[在此处填写您的功能]。请创建一个
OpenSpec 对此功能的变更提案

3. 学习 OpenSpec 工作流：
请解释来自 openspec/AGENTS.md 的 OpenSpec 工作流。
以及我该如何与你共同推进这个项目

按照这个步骤进行就可以了。

具体使用方式

OpenSpec 最好的一点是它足够的轻量化，不止可以通过斜杠命令启动，也可以使用自然语言调用。下面展示一个具体的使用流程。

流程演示

1. 起草提案

首先要求您的 AI 创建变更提案：

您: 创建 无论是在 CLI 还是 GUI 中抽中条目后，不仅仅展示结果，而是生成一张"数字化小票"。GUI 表现：弹出一张由 HTML/CSS 渲染的精美小票卡片，包含店铺 Logo、饮品名称、价格、以及底部的"防伪码"。CLI 表现：使用 ASCII Art 或 rich 库的 Panel 组件，在终端打印出一张长条形的小票样式 的 OpenSpec 变更提案
     (斜杠命令工具的快捷方式: /openspec:proposal add-milktea-offline-picker)

AI: 我将为 add-milktea-offline-picker 创建 OpenSpec 变更提案。
     *在 openspec/changes/add-milktea-offline-picker/ 中搭建 proposal.md、tasks.md 和规范增量(spec.md 等)*

2. 验证与审查

检查变更是否正确创建并审查提案：

$ openspec list                             # 确认变更文件夹存在
$ openspec validate add-profile-filters     # 验证规范格式
$ openspec show add-profile-filters         # 审查提案、任务和规范增量

3. 完善规范

反复迭代规范，直到满足您的需求：

您: 为这个小票增加：记录种子与哈希，生成可复现的防伪数字凭证。

AI: 我将更新规范增量与 tasks，补充以下场景：
     *编辑 openspec/changes/add-milktea-offline-picker/specs/... 与 tasks.md*

4. 实施变更

一旦规范看起来不错，开始实施：

您: 规范看起来不错。让我们实施这个变更。
     (斜杠命令工具的快捷方式: /openspec:apply add-milktea-offline-picker)

AI: 我将处理 add-milktea-offline-picker 变更中的任务。
     *按 tasks.md 实施：核心模块 -> CLI(Typer) -> GUI(pywebview 桥/FastAPI) -> 测试与复现用例*
     *逐项标记任务完成*

5. 归档已完成的变更

实施完成后，归档变更：

AI:  所有任务已完成。实施已准备就绪。

您: 请归档变更
     (斜杠命令工具的快捷方式: /openspec:archive add-profile-filters)

AI: 我将归档 add-profile-filters 变更。
    *运行: openspec-cn archive add-profile-filters --yes*
     ✓ 变更成功归档。规范已更新。准备下一个功能！

或者在终端中自己运行命令：

$ openspec archive add-profile-filters --yes  # 无提示归档已完成的变更

什么时候用哪个？

三种方案的选择逻辑：

spec-kit 和 OpenSpec 对比：