主题
Vibe Coding 中的 Spec（规格说明书）
📚 适合碎片化学习，预计总学习时长：2-3小时
Spec 是 Vibe Coding 的灵魂 —— 你不再写代码，而是写「需求规格」，让 AI 把你的想法变成可运行的软件
目录
1. 基础理论
🎯 核心知识点
1.1 什么是 Vibe Coding？
Vibe Coding（氛围编程） 是 Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 总监）在 2025 年 2 月提出的概念，指一种全新的编程范式：
"你完全沉浸在氛围中，拥抱指数级增长，忘掉代码的存在。" —— Andrej Karpathy
┌─────────────────────────────────────────────────────────────────┐
│ 编程范式的演变 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 传统编程 → 低代码/无代码 → Vibe Coding │
│ ───────── ───────────── ────────── │
│ 手写每一行代码 拖拽组件 用自然语言描述需求 │
│ 人类是执行者 人类是配置者 人类是指挥者 │
│ 需要精通语法 需要了解平台 只需清晰表达意图 │
│ 调试靠经验 调试靠文档 调试靠对话迭代 │
│ │
│ 核心技能: 核心技能: 核心技能: │
│ 编程语言 + 算法 平台操作 Spec 编写 + Prompt │
│ │
└─────────────────────────────────────────────────────────────────┘1.2 什么是 Spec？
Spec（Specification，规格说明书） 是 Vibe Coding 中最核心的产出物。它是你用结构化的自然语言写给 AI 的一份"需求蓝图"，让 AI 据此生成完整、可运行的代码。
┌─────────────────────────────────────────────────────────────────┐
│ Spec 在 Vibe Coding 中的位置 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 开发者 Spec AI │
│ ┌──────┐ ┌──────────┐ ┌──────────┐ │
│ │ 想法 │ ──写作──→ │ 规格说明 │ ──输入──→ │ 代码生成 │ │
│ │ 需求 │ │ 约束条件 │ │ 项目构建 │ │
│ │ 愿景 │ │ 技术选型 │ │ 测试验证 │ │
│ └──────┘ └──────────┘ └──────────┘ │
│ │ │ │
│ │ 反馈循环 │ │
│ ◄───────────────────────┘ │
│ (根据结果迭代 Spec) │
│ │
└─────────────────────────────────────────────────────────────────┘一句话定义：Spec 就是你和 AI 之间的「合同」—— 你明确写出想要什么，AI 负责交付。
1.3 Spec 与传统文档的区别
| 维度 | 传统需求文档 (PRD/SRS) | Vibe Coding Spec |
|---|---|---|
| 读者 | 人类开发者 | AI 编码代理 |
| 精确度 | 允许模糊，靠沟通补齐 | 必须精确，模糊 = 错误输出 |
| 格式 | Word/Confluence 长文 | Markdown 结构化短文 |
| 粒度 | 宏观描述 + 细节留给开发者 | 既有宏观架构，也有微观约束 |
| 迭代方式 | 会议评审 → 修改 → 再评审 | 生成 → 验证 → 修改 Spec → 再生成 |
| 生命周期 | 写完就归档 | 持续演进，是项目的「活文档」 |
1.4 为什么 Spec 如此重要？
┌─────────────────────────────────────────────────────────────────┐
│ Spec 质量 vs 产出质量 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 产出质量 ▲ │
│ │ ★ │
│ │ ╱ │
│ │ ╱ │
│ │ ╱ │
│ │ ╱ ← 好的 Spec │
│ │ ╱ │
│ │ ╱ │
│ │╱ │
│ ├─────────── · · · · · · · · · · ──→ │
│ │· · · · · · · · Spec 详细程度 │
│ │ ↑ │
│ │ 模糊的 Spec │
│ │ = 随机输出 │
│ │ │
└─────────────────────────────────────────────────────────────────┘
核心规律：Spec 的质量决定了 AI 产出的上限
✅ 好 Spec：明确、结构化、有约束 → 一次生成可用代码
❌ 差 Spec：模糊、发散、无边界 → 反复返工，浪费时间2. Spec 的核心要素
2.1 Spec 的六大组成部分
一个完整的 Spec 通常包含以下要素（不是每个都必须，按需组合）：
┌─────────────────────────────────────────────────────────────────┐
│ Spec 的六大要素 │
├──────────┬──────────────────────────────────────────────────────┤
│ ① 目标 │ 这个项目/功能要解决什么问题？最终形态是什么？ │
├──────────┼──────────────────────────────────────────────────────┤
│ ② 技术栈 │ 使用什么语言、框架、工具？版本要求是什么？ │
├──────────┼──────────────────────────────────────────────────────┤
│ ③ 功能点 │ 具体要实现哪些功能？输入输出是什么？ │
├──────────┼──────────────────────────────────────────────────────┤
│ ④ 约束 │ 不能做什么？性能要求？安全限制？代码风格？ │
├──────────┼──────────────────────────────────────────────────────┤
│ ⑤ 结构 │ 目录结构？模块划分？文件命名规范？ │
├──────────┼──────────────────────────────────────────────────────┤
│ ⑥ 示例 │ 输入输出示例？参考项目？API 格式样例？ │
└──────────┴──────────────────────────────────────────────────────┘2.2 各要素详解
① 目标（Goal）
目标是 Spec 的锚点，决定了所有后续决策的方向。
markdown
## 目标（Good ✅）
构建一个计算机知识问答智能 Agent，能够：
- 回答计算机科学基础问题（数据结构、算法、OS、网络、DB）
- 提供代码示例辅助说明
- 对不确定的问题诚实告知
## 目标（Bad ❌）
做一个 AI 聊天机器人原则：目标要回答 "What"（做什么）和 "Why"（为什么），但不需要回答 "How"（怎么做）。
② 技术栈（Tech Stack）
明确指定技术选型，避免 AI 自由发挥。
markdown
## 技术栈（Good ✅）
- Agent 框架: tRPC-Agent-Go
- 编程语言: Go 1.21+
- LLM 模型: 支持 OpenAI/DeepSeek 兼容 API
- 依赖管理: Go Modules
## 技术栈（Bad ❌）
用 Go 写一个后端服务③ 功能点（Features）
将功能拆解为可独立验证的单元。
markdown
## 功能需求（Good ✅）
### 2.1 知识问答能力
- 回答计算机科学基础知识（数据结构、算法、操作系统、计算机网络、数据库等）
- 回答编程语言相关问题（Go、Python、Java、C/C++、JavaScript 等）
### 2.2 工具集成
- 代码执行工具：验证和运行代码片段
### 2.3 Agent 系统指令
你是一个专业的计算机知识问答助手，具备以下能力：
1. 精通计算机科学基础知识
2. 熟悉主流编程语言
3. 能够提供清晰的代码示例和详细的解释
4. 对于不确定的问题，诚实告知并建议查阅权威资料④ 约束（Constraints）
约束告诉 AI「不能做什么」，往往比「要做什么」更重要。
markdown
## 约束条件（Good ✅）
- 所有代码生成任务禁止 Leader 自己完成，必须委派给专业成员
- 禁止连续重复调用 classify_codegen_type 工具
- 必须使用中文回答用户问题
- 不暴露内部决策过程，只输出最终结果
## 约束条件（Bad ❌）
代码要写得好一点⑤ 结构（Structure）
预定义项目骨架，避免 AI 生成混乱的目录结构。
markdown
## 项目结构（Good ✅）
project/
├── cmd/
│ └── server/
│ └── main.go # 入口文件
├── internal/
│ ├── agent/
│ │ └── agent.go # Agent 核心逻辑
│ └── tools/
│ └── code_executor.go # 代码执行工具
├── configs/
│ └── config.yaml # 配置文件
├── go.mod
└── go.sum⑥ 示例（Examples）
用具体示例消除歧义，这是最有效的沟通方式之一。
markdown
## API 示例（Good ✅）
### 请求
POST /api/chat
Content-Type: application/json
{
"message": "什么是快速排序？",
"session_id": "abc-123"
}
### 响应
{
"reply": "快速排序是一种分治算法...",
"code_example": "func quickSort(arr []int) []int { ... }",
"confidence": 0.95
}3. Spec 的分类与层级
3.1 按作用范围分类
┌─────────────────────────────────────────────────────────────────┐
│ Spec 的三个层级 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 项目级 Spec（Project Spec） │ │
│ │ 定义整个项目的架构、技术栈、目录结构、全局约束 │ │
│ │ 通常对应 Cursor Rules / .cursorrules 文件 │ │
│ │ 或 AGENTS.md / CLAUDE.md 等项目根目录文件 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 模块级 Spec（Module Spec） │ │
│ │ 定义单个模块/服务的职责、接口、依赖关系 │ │
│ │ 通常对应 Agent 的 System Prompt 或模块 README │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 任务级 Spec（Task Spec） │ │
│ │ 定义单次对话/任务的具体需求 │ │
│ │ 通常就是你发给 AI 的那条消息（Prompt） │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘3.2 各层级详解与示例
项目级 Spec
项目级 Spec 定义全局规则，影响所有模块和任务。常见载体：
| 工具 | Spec 文件 | 作用 |
|---|---|---|
| Cursor | .cursorrules / .cursor/rules/*.md | IDE 级别的全局指令 |
| Claude Code | CLAUDE.md | 项目根目录的全局约束 |
| Windsurf | .windsurfrules | 项目级 AI 行为配置 |
| GitHub Copilot | .github/copilot-instructions.md | 代码生成的全局规则 |
| 自定义 Agent | AGENTS.md / System Prompt | Agent 的行为边界定义 |
模块级 Spec
对应你附件中的场景——一个多 Agent 系统中每个 Agent 的职责定义：
┌──────────────────────────────────────────────────────────────────┐
│ 多 Agent 系统的 Spec 架构（以 codegen_agent 为例） │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Leader Agent Spec │ │
│ │ · 职责：任务分类 + 路由分发 │ │
│ │ · 约束：禁止自己写代码 │ │
│ │ · 路由表：语言 × 类型 → 专家 │ │
│ └──────────┬──────────────────────────────┘ │
│ │ 委派 │
│ ┌────────┼────────┬──────────┐ │
│ ▼ ▼ ▼ ▼ │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌──────────┐ │
│ │Go专家│ │Cpp │ │Py │ │项目检查 │ │
│ │Spec │ │专家 │ │专家 │ │专家 Spec │ │
│ └─────┘ │Spec │ │Spec │ └──────────┘ │
│ └─────┘ └─────┘ │
│ │
│ 每个成员 Agent 都有自己的 Spec（System Prompt）， │
│ 定义了该 Agent 的专业能力边界和行为规范 │
│ │
└──────────────────────────────────────────────────────────────────┘任务级 Spec
就是你每次发给 AI 的具体请求，也需要结构化：
markdown
## 任务级 Spec 示例
使用 tRPC-Agent-Go 框架构建一个专业的计算机知识问答智能 Agent 机器人
1. 技术框架要求
- Agent 框架: tRPC-Agent-Go
- 编程语言: Go 1.21+
- LLM 模型: 支持 OpenAI/DeepSeek 等兼容 API 的模型
2. 功能需求
2.1 知识问答能力
- 回答计算机科学基础知识
- 回答编程语言相关问题
2.2 工具集成
- 代码执行工具：验证和运行代码片段
2.3 Agent 系统指令
（具体的 system prompt 内容）4. Spec 编写实践
4.1 Spec 编写的 CRAFT 原则
┌─────────────────────────────────────────────────────────────────┐
│ CRAFT 原则 │
├──────────┬──────────────────────────────────────────────────────┤
│ C-Clear │ 清晰：每句话只表达一个意思，避免歧义 │
│ │ ❌ "做个好用的系统" │
│ │ ✅ "响应时间 < 200ms，支持 1000 并发" │
├──────────┼──────────────────────────────────────────────────────┤
│ R-Rich │ 丰富：提供足够的上下文和背景信息 │
│ │ ❌ "加个登录功能" │
│ │ ✅ "使用 JWT 实现登录，token 有效期 24h，支持刷新" │
├──────────┼──────────────────────────────────────────────────────┤
│ A-Action │ 可执行：每个需求都能被 AI 直接转化为代码 │
│ │ ❌ "用户体验要好" │
│ │ ✅ "错误信息用中文展示，包含错误码和解决建议" │
├──────────┼──────────────────────────────────────────────────────┤
│ F-Finite │ 有边界：明确定义范围，告诉 AI 不需要做什么 │
│ │ ❌ "支持各种数据库" │
│ │ ✅ "仅支持 MySQL 8.0+，不需要 Redis 缓存层" │
├──────────┼──────────────────────────────────────────────────────┤
│ T-Test │ 可验证：定义怎么判断任务完成了 │
│ │ ❌ "代码能跑就行" │
│ │ ✅ "通过所有单元测试，go test ./... 返回 PASS" │
└──────────┴──────────────────────────────────────────────────────┘4.2 从模糊想法到可用 Spec 的四步法
┌─────────────────────────────────────────────────────────────────┐
│ 四步精炼法 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Step 1: 写下模糊想法 │
│ ───────────────────── │
│ "我想做一个 AI 聊天机器人" │
│ │
│ ↓ 追问：解决什么问题？谁在用？ │
│ │
│ Step 2: 明确目标和用户 │
│ ───────────────────────── │
│ "为计算机专业学生提供一个知识问答 Agent， │
│ 能回答 CS 基础问题并提供代码示例" │
│ │
│ ↓ 追问：用什么技术？有什么限制？ │
│ │
│ Step 3: 添加技术约束 │
│ ───────────────────── │
│ "使用 tRPC-Agent-Go 框架，Go 1.21+， │
│ 支持 OpenAI API，包含代码执行工具" │
│ │
│ ↓ 追问：具体功能列表？验收标准？ │
│ │
│ Step 4: 形成完整 Spec │
│ ───────────────────── │
│ （结构化的完整规格说明书） │
│ │
└─────────────────────────────────────────────────────────────────┘4.3 Spec 模板
以下是一个通用的 Spec 模板，可根据项目类型裁剪：
markdown
# [项目名称] Spec
## 1. 项目目标
[一句话描述项目要解决的核心问题]
## 2. 技术要求
- 语言：[Go 1.21+ / Python 3.11+ / ...]
- 框架：[tRPC-Go / FastAPI / ...]
- 依赖：[列出关键第三方库]
- 部署：[Docker / K8s / 裸机 / ...]
## 3. 功能需求
### 3.1 [功能模块 A]
- [具体功能点 1]
- [具体功能点 2]
### 3.2 [功能模块 B]
- [具体功能点 1]
## 4. 约束条件
- [性能约束]
- [安全约束]
- [代码风格约束]
## 5. 项目结构
[预定义的目录树]
## 6. 接口示例
[输入输出的 JSON 示例]
## 7. 验收标准
- [ ] [标准 1：编译通过]
- [ ] [标准 2：测试通过]
- [ ] [标准 3：功能可用]5. Spec 驱动开发流程
5.1 Spec-First 开发流程
┌─────────────────────────────────────────────────────────────────┐
│ Spec 驱动开发的完整流程 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 构思 │───→│ 写 Spec │───→│ AI 生成 │───→│ 验证 │ │
│ │ Ideate │ │ Draft │ │ Generate │ │ Verify │ │
│ └─────────┘ └─────────┘ └─────────┘ └────┬────┘ │
│ │ │
│ ┌──────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────┐ │
│ │ 通过？ │ │
│ └──────┬─────┘ │
│ Yes │ No │
│ │ │ │
│ ▼ ▼ │
│ ┌──────┐ ┌──────────┐ │
│ │ 完成 │ │ 迭代 Spec │──→ 回到 "AI 生成" │
│ │ Done │ │ Refine │ │
│ └──────┘ └──────────┘ │
│ │
│ 关键洞察：在这个流程中，Spec 是唯一需要人类深度参与的环节 │
│ 其他步骤可以大幅自动化 │
│ │
└─────────────────────────────────────────────────────────────────┘5.2 Spec 的迭代策略
当 AI 的产出不符合预期时，不要修改代码，而是修改 Spec：
┌─────────────────────────────────────────────────────────────────┐
│ Spec 迭代的三种策略 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 策略 1：增补型迭代 │
│ ────────────────── │
│ 原 Spec: "实现用户登录功能" │
│ 问题：AI 没有做输入验证 │
│ 迭代：追加 "登录时需校验邮箱格式，密码长度 8-32 位" │
│ │
│ 策略 2：纠偏型迭代 │
│ ────────────────── │
│ 原 Spec: "使用数据库存储" │
│ 问题：AI 选了 SQLite，但你要 MySQL │
│ 迭代：修改为 "使用 MySQL 8.0+，通过 GORM 操作" │
│ │
│ 策略 3：拆分型迭代 │
│ ────────────────── │
│ 原 Spec: "构建完整的电商系统" │
│ 问题：Spec 太大，AI 输出质量下降 │
│ 迭代：拆成 "用户模块 Spec" + "商品模块 Spec" + "订单模块 Spec" │
│ │
└─────────────────────────────────────────────────────────────────┘5.3 Spec 与 AI 工具的对接
不同 AI 编码工具对 Spec 的消费方式不同：
| AI 工具 | Spec 输入方式 | 持久化位置 |
|---|---|---|
| Cursor | Chat 对话 / Rules 文件 | .cursor/rules/ |
| Claude Code | 对话 / CLAUDE.md | 项目根目录 CLAUDE.md |
| GitHub Copilot Workspace | Issue 描述 → 自动生成 Spec | GitHub Issue + PR |
| Windsurf | Chat 对话 / Rules 文件 | .windsurfrules |
| Bolt / Lovable | 对话框直接输入 | 项目内存 |
| 自定义 Agent（tRPC-Agent 等） | System Prompt | Agent 配置文件 |
6. 真实案例解析
6.1 案例：多 Agent 代码生成系统的 Spec
以下是从你的项目日志中提取的真实 Spec 结构分析（codegen_agent 的 Leader Agent System Prompt）：
┌─────────────────────────────────────────────────────────────────┐
│ Leader Agent Spec 结构解析 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─ 角色定义 ─────────────────────────────────────────────┐ │
│ │ "你是一个智能代码助手，擅长处理各种代码相关的任务" │ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌─ 职责边界 ─────────────────────────────────────────────┐ │
│ │ 简单任务自己处理 / 复杂任务必须委派 │ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌─ 分类规则（决策树）────────────────────────────────────┐ │
│ │ 类型A: 非编程 → 直接回复 │ │
│ │ 类型B: 新项目 → 路由规则 │ │
│ │ 类型C: 代码修改 → 委派 code_modify_agent │ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌─ 路由表（详细映射）────────────────────────────────────┐ │
│ │ tRPC? → 语言? → 工具分类? → 委派具体专家 │ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌─ 约束条件 ─────────────────────────────────────────────┐ │
│ │ 禁止自己写代码 / 禁止重复调用工具 / 中文回复 │ │
│ └────────────────────────────────────────────────────────┘ │
│ ┌─ 成员列表 ─────────────────────────────────────────────┐ │
│ │ 13 个专家 Agent 及其职责描述 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Spec 设计亮点： │
│ ✅ 明确的决策树（不靠 AI 猜，靠规则走） │
│ ✅ 强约束（"禁止"、"必须" 等硬性规则） │
│ ✅ 完整的路由表（语言 × 场景 → 专家） │
│ ✅ 工具调用规范（必须调工具，禁止自行推断） │
│ │
└─────────────────────────────────────────────────────────────────┘6.2 这个 Spec 中值得学习的技巧
技巧 1：用决策树替代自由判断
markdown
## 坏的写法 ❌
"根据用户需求，选择合适的专家来处理"
## 好的写法 ✅
### 第一步：判断是否为 tRPC 项目
- 非 tRPC 项目 → 委派给 non_trpc_codegen_agent
- tRPC 项目 → 进入第二步
### 第二步：检查编程语言
1. 用户未指定语言 → 询问
2. 不支持的语言 → 告知限制
3. Go/Cpp/Python → 进入第三步
### 第三步：调用工具分类
⚠️ 必须调用 classify_codegen_type 工具！禁止自行推断！技巧 2：用正反例消除歧义
markdown
- ❌ 错误做法：根据用户描述自己判断"没有上传 proto 文件"
- ✅ 正确做法：先调用 classify_codegen_type 工具，根据工具返回值进行路由技巧 3：明确的输出格式约束
markdown
## 输出要求
- 使用中文回复
- 只输出最终结果，不暴露内部决策过程
- 如果是新项目生成，只有在 project_check_agent 完成检查后，
才能向用户输出新项目生成的最终结果7. 常见问题与最佳实践
7.1 常见误区
┌──────────────────────────────────────────────────────────────────┐
│ Spec 编写常见误区 │
├──────┬───────────────────────┬───────────────────────────────────┤
│ 编号 │ 误区 │ 正确做法 │
├──────┼───────────────────────┼───────────────────────────────────┤
│ 1 │ Spec 越长越好 │ 精炼胜于冗长，每句话都应该 │
│ │ │ 传递有效信息 │
├──────┼───────────────────────┼───────────────────────────────────┤
│ 2 │ 一次写完不改 │ Spec 是迭代产物，每次 AI 反馈 │
│ │ │ 后都应回顾和修正 │
├──────┼───────────────────────┼───────────────────────────────────┤
│ 3 │ 只写功能不写约束 │ 约束和功能同等重要， │
│ │ │ "不做什么"跟"做什么"一样关键 │
├──────┼───────────────────────┼───────────────────────────────────┤
│ 4 │ 不给示例 │ 一个好示例胜过一段描述， │
│ │ │ AI 非常擅长从示例中学习 │
├──────┼───────────────────────┼───────────────────────────────────┤
│ 5 │ 把 Spec 当代码注释写 │ Spec 面向 AI，应该是完整的、 │
│ │ │ 自包含的说明书 │
├──────┼───────────────────────┼───────────────────────────────────┤
│ 6 │ 所有细节一股脑塞进去 │ 分层编写：项目级规则放 Rules， │
│ │ │ 任务级需求放对话，不要混在一起 │
└──────┴───────────────────────┴───────────────────────────────────┘7.2 最佳实践清单
✅ Spec 编写检查清单
□ 目标明确：能否一句话说清楚要做什么？
□ 技术确定：语言、框架、版本号是否都指定了？
□ 功能可拆：每个功能是否可以独立实现和验证？
□ 约束清晰：是否列出了"不做什么"？
□ 有示例：关键接口是否提供了输入输出样例？
□ 可验收：是否定义了"怎么算完成"？
□ 不矛盾：各条规则之间是否存在冲突？
□ 分层合理：全局规则和任务规则是否分开了？7.3 Spec 的演进趋势
┌─────────────────────────────────────────────────────────────────┐
│ Spec 的未来演进 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 当前阶段（2025-2026） │
│ ───────────────────── │
│ · 人类手写 Spec → AI 生成代码 │
│ · Spec 是纯文本（Markdown） │
│ · 一次对话生成一个项目/功能 │
│ │
│ 近期趋势 │
│ ───────── │
│ · AI 辅助生成 Spec（你说想法，AI 帮你写 Spec） │
│ · Spec 模板化、可复用（像 npm 包一样分享 Spec） │
│ · 可视化 Spec 编辑器（拖拽 + 表单 → 生成 Spec） │
│ │
│ 远期趋势 │
│ ───────── │
│ · Spec 即代码（Spec as Code），版本管理 + CI/CD │
│ · AI 自主探索 + 人类仅审批关键 Spec 节点 │
│ · 多 Agent 协作时，Spec 成为 Agent 间的"协议" │
│ （正如你的 codegen_agent 已经在做的事情） │
│ │
└─────────────────────────────────────────────────────────────────┘8. 学习资源
8.1 关键文章与视频
| 资源 | 说明 |
|---|---|
| Andrej Karpathy 的 Vibe Coding 推文 | Vibe Coding 概念的诞生地 |
| Pieter Levels 的实践分享 | Vibe Coding 最成功的实践者之一 |
| Cursor Rules 社区 | 大量现成的项目级 Spec 模板 |
| Harper Reed 的 Spec 驱动方法论 | 系统化的 Spec-First 工作流 |
8.2 推荐工具
| 工具 | 用途 | Spec 支持方式 |
|---|---|---|
| Cursor | AI-native IDE | Rules 文件 + Chat |
| Claude Code | 终端 AI 编码 | CLAUDE.md + 对话 |
| GitHub Copilot Workspace | 云端 AI 开发 | Issue → Spec → PR |
| tRPC-Agent | 多 Agent 框架 | System Prompt |
8.3 核心要点速记
┌─────────────────────────────────────────────────────────────────┐
│ Spec 速记卡片 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 📌 Spec = 你和 AI 之间的合同 │
│ │
│ 📌 Spec 六要素 = 目标 + 技术栈 + 功能 + 约束 + 结构 + 示例 │
│ │
│ 📌 Spec 三层级 = 项目级 + 模块级 + 任务级 │
│ │
│ 📌 CRAFT 原则 = Clear + Rich + Actionable + Finite + Testable │
│ │
│ 📌 核心规律：不要修改代码，修改 Spec │
│ │
│ 📌 Vibe Coding 的本质：你的价值不在于写代码， │
│ 而在于写出精准的 Spec │
│ │
└─────────────────────────────────────────────────────────────────┘