# Spec Kit 驱动的 Vibe 开发：用规格约束，驯服"氛围编程"的失控

> 当自然语言成为编程界面，纪律比天赋更重要

---

## 一、从一个"脆弱开发者"说起

我在上一篇文章里聊过 **Vibe Working**——"让 AI 替你干活"比"让 AI 替你写代码"更广阔的范式。但凡是真在 Vibe 里干过活的人，都会遇到同样问题：

> **速度上来了，质量掉下去了；Demo 跑通了，没人敢改第二行。**

2025 年下半年，Ahmed Fawzy 等人在 *"Vibe Coding in Practice"*（arXiv 2510.00328）里分析了 101 个从业者来源、518 段一手行为描述，得出一个**速度-质量悖论**：绝大多数 Vibe Coder 被速度裹挟，跳过了测试与验证环节，制造出论文里称为**"脆弱开发者"（Fragile Developer）**的群体——能快速堆出产品，一旦出问题却无法独立调试。

更现实的是漂移。你让 Agent "加个小功能"，它顺手改了三处全局状态；你没察觉，两周后另一个功能莫名崩了。Vibe Coding 的"忘记代码存在"听起来很浪漫，但生产环境里，"忘记"等于"失控"。我自己早期通过GEM体系以注入提示词方式进行约束的方法，做常规的Vibe没什么问题，但是如果开发任务迭代次数多，或者本身复杂，一致性依然很难保证。

**那么问题来了：当我们把开发交给Vibe，靠什么不翻车？**

经过一段时间的研究和实践，我发现可以把"规格"（Spec）变成可执行的第一公约。GitHub上有一套现成工具——**Spec Kit**。本文不讲概念，直接带你在我每天用的 WorkBuddy 里，把 Spec Kit 跑成一条**门控确认的规格驱动开发流水线**，并分享我基于它做的几处关键优化。

---

## 二、Spec Kit 是什么

**Spec Kit**（[github.com/github/spec-kit](https://github.com/github/spec-kit)）是 GitHub 开源的**规格驱动开发（Spec-Driven Development, SDD）**工具包。它的核心主张只有一句话：

> **让规格（Specification）成为可执行的东西，直接生成可工作的实现，而不是写完就丢的脚手架。**

传统开发里，文档是"开工前的废纸"；Spec Kit 反过来——你先定义"要建什么、为什么建"，AI Agent 再把规格转成可运行的代码。它提供一组结构化 slash 命令：

| 命令 | 作用 | 你在流程中的位置 |
|------|------|----------------|
| `/speckit.constitution` | 建立项目治理原则与开发规范 | 地基 |
| `/speckit.specify` | 定义要构建什么（需求 + 用户故事），只讲 what/why | 需求 |
| `/speckit.clarify` | 通过结构化提问澄清模糊点 | 需求校验 |
| `/speckit.checklist` | 生成质量检查清单（"英文的单元测试"） | 需求校验 |
| `/speckit.plan` | 选定技术栈、产出技术实现计划 | 设计 |
| `/speckit.tasks` | 把计划拆成可执行任务清单 | 拆解 |
| `/speckit.analyze` | 跨产物一致性 & 覆盖度分析 | 实现前把关 |
| `/speckit.implement` | 按计划执行所有任务，生成代码 | 实现 |

底层是一个 `specify` CLI。装好之后跑一次：

```bash
# 官方持久化安装
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 初始化一个项目，并接入你的 AI 编码 Agent
specify init my-project --ai codebuddy
```

关键是 `--ai codebuddy` 这个 flag——**Spec Kit 官方支持 CodeBuddy/WorkBuddy**。这意味着它能在初始化时，把上面那组 `/speckit.*` 命令直接写进你的 Agent 命令目录。换句话说，你不需要自己造轮子，GitHub 已经把"结构化开发指令"做成了一套可加载的技能。

**我这篇文章要做的，就是在这套上游技能之上，叠加几个中国开发者真正用得上的优化。**

---

## 三、为什么 Vibe Coding 需要接 Spec Kit

让我们对比一下：

| 维度 | 纯 Vibe Coding | Spec Kit 驱动的 Vibe 开发 |
|------|---------------|--------------------------|
| **意图来源** | 一句话 prompt，随想随改 | 一份可评审、可版本化的 Spec |
| **过程可见性** | 黑盒，改完才知道 | 每阶段有产物（constitution/spec/plan/tasks） |
| **漂移风险** | 高，全局状态常被顺手改 | 低，计划与任务锁定边界 |
| **可维护性** | "脆弱开发者"陷阱 | 规格即文档，后人能接 |
| **人的角色** | 反复救火 | 在门控点做战略决策 |

Spec Kit 解决的，正是 Vibe Coding 最致命的两个问题：**意图不明确**和**过程不可控**。这个和人类开发的时候瀑布流、敏捷开发的逻辑是不同的，这是一套面向大模型的敏捷开发范式，更多的基于规格文档和样例。

但原版 Spec Kit 是为英文环境、类 Unix shell、以及"信任 Agent 一路跑到底"的假设设计的。在我这个 Windows + 中文 + 需要人工把关的真实工作流里，直接用会踩坑。下面是我做的六处优化。

![GEM 体系 × Spec Kit 架构关系](https://developer.qcloudimg.com/http-save/yehe-4862070/fb27bc2a275e3832e5968cde8ef963ad.png)
*图 1：上游技能 Spec Kit 如何嵌入原有的 GEM 三层（Gene 触发 / Executive 路由 / Memory 沉淀 + 晶体回流），每个 SDD 阶段都设门控确认点 G1–G7。*

---

## 四、我的优化：把 Spec Kit 改造成"中国开发者友好 + 门控确认"

这些优化已经沉淀进我的 GEM 工作体系（Gene 2 / Gene 4 / Gene 14），任何人 clone 我的 `SOUL.md` 即可获得。逐条说明：

### 优化 1：Windows / PowerShell 化初始化

原版默认生成 Bash 脚本。在 Windows 上跑 Vibe 开发，得强制 PowerShell：

```bash
specify init --here --integration codebuddy --script ps --ignore-agent-tools --force
```

- `--script ps`：生成 PowerShell 变体，Windows/跨平台通用
- `--ignore-agent-tools`：跳过对 Claude Code 等 Agent 工具的检查（我们用 WorkBuddy）
- `--force`：在当前非空目录强制合并，跳过确认
- `--here`：在当前目录初始化，而不是新建子目录

> 注：社区版 CLI 接入 CodeBuddy 的 flag 写作 `--ai codebuddy`，我这套环境里用的是 `--integration codebuddy`（CodeBuddy 集成变体），两者指向同一能力。你按自己环境的 CLI 版本选其一即可。

### 优化 2：门控确认 SDD（每阶段暂停等人确认）

这是最重要的一环。原版流程鼓励 Agent 一口气跑完 `specify → plan → tasks → implement`。但在真实项目里，我**不允许**它自动连跑——每个阶段产出后，必须停下来等我明确说"通过 / 继续 / OK"，才进入下一阶段。

为什么？因为规格驱动的真正价值，不在于"AI 写得快"，而在于**人在关键节点做不可逆决策前的最后一次纠偏**。一个错误的 constitution，会在后续所有阶段被放大十倍。门控确认把"失控"掐死在萌芽。

### 优化 3：Spec 全中文

所有 Spec 文档（constitution / spec / plan / tasks）一律用简体中文书写。原因很朴素：需求方、评审方、未来的维护者都在说中文，用英文写规格反而制造了一层无谓的翻译损耗。中文 Spec 也倒逼你把需求想清楚——含糊的东西，中文写下来会更刺眼。

### 优化 4：本地优先测试

规则只有一条：**所有测试在本地完成、通过后才发版**。不把未验证的代码推上生产，也不依赖"云端 Agent 跑通就算数"。本地跑通是发版的硬门槛。

### 优化 5：复杂度分级

不是所有需求都值得走完整 SDD 流程。我按复杂度分三档：

| 级别 | 判断标准 | 流程 |
|------|---------|------|
| 小修改 | ≤1 文件，改字段 / 修简单 bug | 直接改，说明方案即可 |
| 中等功能 | 2–5 文件 | plan + 一页轻量 Spec |
| 大型 / 多模块 | >5 文件、含支付 / 权限 / 数据 | **spec-kit 全流程**：constitution→specify→clarify→plan→tasks→analyze→implement |

Spec Kit 是重型武器，用在刀刃上。改个文案别开 constitution。

### 优化 6：GEM 架构集成

Spec Kit 不是孤立运行的。它嵌在我的 GEM 体系里：Gene 层提供策略模板（何时走 SDD、何时直改），Executive 层做调度路由，Memory 层把每次开发的 Spec / 决策 / 踩坑沉淀为可复用记忆。一次开发结束后，产生的 constitution 和 spec 会变成团队晶体知识，下次类似需求直接复用。

---

## 五、实战：在 WorkBuddy 跑通一个完整需求

下面用一个真实体量的例子走一遍：**给团队做一个内部"任务看板（Kanban）小工具"**，支持创建项目、成员协作、任务拖拽、进度跟踪。

### Step 0：安装与初始化

```bash
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init --here --integration codebuddy --script ps --ignore-agent-tools --force
```

执行后，WorkBuddy 的命令目录里会出现 `.codebuddy/commands/` 与 `.specify/` 两套结构，`/speckit.*` 命令全部就位。**（门控点 G0：确认命令就位，再继续）**

### Step 1：立规矩 —— `/speckit.constitution`

在对话框里：

```
/speckit.constitution
本项目遵循"库优先"原则：功能先实现为独立模块。
严格使用 TDD；优先函数式风格；所有用户输入必须校验。
```

产出 `.specify/memory/constitution.md`。**这是地基，后面所有阶段都受它约束。（门控点 G1：我审一遍原则，确认无误）**

### Step 2：写需求 —— `/speckit.specify`（中文）

```
/speckit.specify
开发一个团队任务看板：用户可以创建项目、添加成员、用看板列管理任务状态
（待办/进行中/评审/完成），支持拖拽切换状态，任务卡片可评论。
首期不做登录，预设 5 个用户（1 PM + 4 工程师）、3 个示例项目。
```

注意：这里**只讲要什么、为什么，不讲技术栈**。技术决策留给 plan 阶段。**（门控点 G2：需求是否覆盖真实场景？有歧义先打回）**

### Step 3：澄清与质检 —— `/speckit.clarify` + `/speckit.checklist`

```
/speckit.clarify
聚焦：任务卡片的字段定义、拖拽的边界情况、评论的存储方式
/speckit.checklist
```

`clarify` 会针对模糊点追问，`checklist` 生成一份需求完整性清单（论文里形容它是"英文的单元测试"）。**先清歧义、再过清单，再进设计——这是避免后期返工的关键。（门控点 G3）**

### Step 4：定方案 —— `/speckit.plan`

```
/speckit.plan
前端用 Vite + React + TypeScript，后端 Node.js + Express，
数据存 SQLite（本地优先），状态管理用 Zustand。
```

产出技术实现计划，明确架构与框架。**（门控点 G4：技术选型我拍板，不甩给 Agent）**

### Step 5：拆任务 —— `/speckit.tasks`

```
/speckit.tasks
```

把计划拆成可执行的任务清单（建表、API、组件、拖拽交互……）。**（门控点 G5：任务粒度是否合适，能否独立验证？）**

### Step 6：一致性把关 —— `/speckit.analyze`

```
/speckit.analyze
```

跨 constitution / spec / plan / tasks 做一致性与覆盖度分析。**这一步必须在 implement 之前跑**——此刻发现 gap 还能改计划，进了实现再改就是重写。（门控点 G6）

### Step 7：实现 —— `/speckit.implement`

```
/speckit.implement
```

Agent 按计划逐任务执行。每个任务完成后，**本地跑测试，通过才进下一个**。全部跑通、本地验证 OK，才视为交付。（门控点 G7：本地测试通过，发版）

---

## 六、真实效果：从"脆弱"到"可接"

这套流程我在多个真实项目里跑过。最直观的变化有三个：

1. **返工率断崖下降**。歧义在 `clarify`/`checklist` 阶段就被吃掉，不再带着错误需求冲进实现。
2. **交接零成本**。constitution + spec 就是活文档，同事接手不用我口述背景。
3. **敢改了**。任务清单锁定了边界，Agent 不会顺手改全局状态；真要改，也有 plan 可追溯。

它没有改变 Vibe 开发的本质——我依然用自然语言下指令、依然"沉浸氛围"。它只是在氛围之下，铺了一层**规格的钢筋**。

---

## 七、心法总结

- **Spec Kit 是上游的"别人家的技能"，别重造。** `specify init --ai codebuddy` 一行接入，slash 命令白送。
- **优化的本质，是让工具适配你的真实约束**：Windows 用 PowerShell、中文写 Spec、人工在门控点把关、本地优先测试。
- **复杂度分级，别滥用重型流程。** 改文案别开 constitution。
- **门控确认是纪律，不是拖慢。** 它在不可逆决策前给你最后一次纠偏机会。
- **沉淀进体系。** 每次开发的 Spec 与决策，都是未来可复用的晶体。

Vibe Coding 的浪漫不该是"忘记代码存在"，而该是"忘记重复劳动的存在"。Spec Kit 驱动的 Vibe 开发，让我们既享受氛围，又不被氛围反噬。

![image.png](https://developer.qcloudimg.com/http-save/yehe-4862070/868ac1af147ca54b575d17fcc3e15da6.png)
*图 2：从一句话意图到可维护交付、再到体系自增强的完整闭环 —— 门控确认是循环里最关键的反噬刹车。*




我在上一篇文章里聊过 Vibe Working——"让 AI 替你干活"比"让 AI 替你写代码"更广阔的范式。但凡是真在 Vibe 里干过活的人，都会遇到同样问题：

Spec Kit 驱动的 Vibe 开发：用规格约束，驯服"氛围编程"的失控

当自然语言成为编程界面，纪律比天赋更重要

咖啡消灭机

编程语言

开发工具

人工智能

SpecKit驱动的Vibe开发通过规格约束解决AI编程的质量失控问题。文章介绍如何将GitHub开源的SpecKit工具与中国开发者工作流结合，通过6项关键优化实现门控确认式开发。从项目初始化到需求实现，每个阶段设置人工确认点，确保AI生成代码符合规格要求。实战演示了从constitution到implement的完整流程，帮助开发者既享受Vibe编程的高效，又避免"脆弱开发者"陷阱。

单元测试

敏捷开发

代码解释

TypeScript

WorkBuddy 

Windows

路由

GitHub

Kanban

SQLite

Agent

ReAct 

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SpecKit驱动的Vibe开发通过规格约束解决AI编程的质量失控问题。文章介绍如何将GitHub开源的SpecKit工具与中国开发者工作流结合，通过6项关键优化实现门控确认式开发。从项目初始化到需求实现，每个阶段设置人工确认点，确保AI生成代码符合规格要求。实战演示了从constitution到implement的完...

Spec Kit 驱动的 Vibe 开发：用规格约束，驯服"氛围编程"的失控-腾讯云开发者社区-腾讯云

Spec Kit 驱动的 Vibe 开发：用规格约束，驯服"氛围编程"的失控

Spec Kit 驱动的 Vibe 开发：用规格约束，驯服"氛围编程"的失控

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐