Vibe Coding v.s. Spec Coding

Vibe Coding（氛围编程），即：仅凭借感觉和聊天驱动 AI 编程，强调即时性和程序员的直觉。

• 及时性：立即就让 AI 写代码，不需要任何前期准备。
• 程序员的直觉：通过经验转化的直觉来提需求，让 AI 做事情。

优点：快，及时实现你的需求，不用多想全凭直觉；

缺点：需求仅存在于聊天记录，需求描述不规范、不清晰、不可追溯，需求质量全凭程序员经验高低。 适用场景：小需求、小修改，例如：让 AI 临时写个小脚本。统称为 AI 副驾（copilot）编程场景。

Vibe Coding 的核心痛点：需求一旦复杂，单靠对话描述很容易产生理解偏差，最后得到的代码和预期相差甚远，甚至根本没法直接用。

Spec Coding（规格编程），即：先想好之后再让 AI 编程，强调整体性、规划性和规范性。

• 整体性：从整个项目/系统的角度出发，整体考虑 “人、事、物” 三个维度。
• 规划性：先写好你的需求描述文档，并规划好要如何设计、实现、测试、交付你的需求。
• 规范性：所有人遵守同一套软件工程规范的约束，使得项目需求可观测、可追溯、可解析、可控制、可移交。

优点：需求清晰合规、软件质量有保障。

缺点：前期规划需要投入较多的 “脑力” 和时间。 适用场景：AI 驱动的大型生产项目，例如：AI 连续编程 24 小时。统称为 AI 原生（自主）编程场景。

Spec Coding —— AI 编程新范式

核心思维：

• I ship code I don’t read（我发布我不读的代码）—— OpenClaw 创始人 Steinberger，一个月内没写一行代码，却 “写完了” 40w 行代码。
• 我们正在从 “代码是真理之源” 转向 “意图是真理之源”。
• AI 应用工程师，而非程序员；写提示词，而非代码。

面对 2 大难题（一头一尾）：

1. 需求：如何让 AI 真正理解我们的意图，并按照预期的方式工作？
2. 质量：如何保证质量？

大型软件系统的本质，是确定性和稳定性！而 AI 本质上是一个概率模型，这是它的数学本质。懂得基于 AI 构建确定性系统的工程师，将是 AI 时代不可替代的能力。

方法

软件工程方法论

软件工程方法论，指用于指导、管理和执行 “软件需求、设计、开发、测试、交付、运维” 的过程的结构化方法、框架、原则和实践。

发展脉络和历史：

1. 1970 年代：瀑布模型，迭代开发。

• 特点：稳定、保质、却慢，跟不上客户需求变化。
• 详细：强调预先详尽规划、严格的阶段性划分（需求 -> 设计 -> 开发 -> 测试 ->  交付 -> 运维）、文档驱动、变更控制严格、线性/顺序推进。目标是按计划、在预算内交付符合最初规格的软件。

2. 2000 年后：敏捷开发，小步快跑。

• 特点：一味只求快、适应需求大爆发且变化快的时代背景。质量保证需要结合 CI 自动化工具和 CMMI 等质量改进框架。
• 详细：强调适应性、迭代和增量开发、快速交付可工作软件、客户协作、响应变化、个体和互动高于流程和工具。通过 Scrum 短周期迭代（Sprint）不断获取反馈并调整方向。

3. 2010 年后：DevOps，开发-测试-运维一体化。

• 特点：强调弥合开发、测试、运维之间的鸿沟、强调跨部门协作，并通过自动化技术，既快又保质。
• 详细：基于 “Kubernetes+微服务+云原生” 技术底座之上的 CI/CD 自动化流水线。CI 包括：Code Review、单元测试覆盖率、自动化测试、自动化代码扫描；CD 包括：灰度发布、滚动升级、快速回滚。

4. 2025 年开始：AI 原生开发。

• 特点：Spec Coding 重塑软件工程方法轮。

SDD（规格驱动开发）模式

SDD（Specification‑Driven Development，规格驱动开发），用结构化的规格文档来指导和约束 AI 编程。规格文档作为 AI 唯一的可信源（Single Source of Truth），贯穿软件工程的整个生命周期。只要规则文档清晰、准确，AI 就能更稳定、更高效、更持久、更广泛地发挥。

一个典型的 SDD 流程如下：

1. Brainstorm（头脑风暴）：和 AI 讨论请求需求。
2. Map（地图）：根据头脑风暴产出需求的 PRD 规格文档，并拆解为敏捷开发的 Epic 和 Story 进行管理。
3. Act（行动）：AI 循环处理这些 Epic 和 Story。
4. Develop（开发）：AI 进行根据 PRD 规格文档进行实际的代码生成。

这样产出的代码是可追溯的、可验证的。每一行代码都能回溯到它对应的 Story，每个 Story 都能回溯到 PRD，PRD 能回溯到最初的需求。没有这条可追溯的信息链，就不是在做软件工程。

TDD（测试驱动开发）模式

TDD（测试驱动开发）的思想是 “测试代码优先，质量优先”，即：先编写测试用例，通过测试用例来反向约束实际功能代码。测试用例就是需求和质量的约束。

TDD 的核心循环：红 -> 绿 -> 重构

1. 红（Red）：编写一个会失败的单元测试用例，要求对应一个具体的、粒度微小的新需求、新功能来编写。
2. 绿（Green）：编写功能代码让单元测试用例通过，如果单元测试用例不通过，则表示功能不满足需求。在敏捷开发的场景中，要求最小化开发，避免过渡设计，能通过单元测试用例就行。
3. 重构（Refactor）：绿阶段的代码未必是最优的，最后重构代码以达到设计良好且整洁的状态，并且能够通过测试用例。目标是消除重复、改善可读性、应用设计模式、优化结构，提升代码的整体质量。
4. 回到第一步，写下个测试。

STDD（规格-测试驱动开发）

TDD 和 SDD 可以自然的融合起来。SDD 通过 Markdown 文档强调需求，TDD 通过 TestCase 强调质量。

工具

Spec‑Kit

Spec‑Kit 是 GitHub 在 2025 年专为 SDD 设计的开发工具包，用来帮你在各种 AI 编码环境中（如 Copilot、Cursor 等）按 SDD 的方式工作。它把 “写规格、做计划、拆任务、实现和审查” 这一整套流程固化成可复用的命令和模板。

• https://github.com/github/spec-kit

Spec‑Kit 的典型工作流：宪法 → 规格 → 计划 → 任务 → 实现 → 审查 & 测试 Spec‑Kit Prompt 模板：针对产品、架构、开发、测试等不同 “角色” 预置好提示词； Spec‑Kit CLI 工具：用于初始化项目、生成目录和基础文件。 Spec‑Kit 可以集成在 Claude Code 等环境中使用，提供了多个 Slash（斜杆）命令。如下：

1. /speckit.constitution：编辑 CONSTITUTION.md 项目宪法文件，全局约束、开发准则。包括：代码质量标准、测试规范、用户体验一致性要求、性能要求等。
2. /speckit.specify：编辑 spec.md 功能规范文件。包括：用户故事（谁、要什么、为什么）、功能需求、不涉及技术栈（关注 what 和 why）。
3. /speckit.plan：编辑 plan.md 技术规划文件。包括：技术栈选择、架构选择、API 契约。
4. /speckit.tasks：编辑 tasks.md 任务分解文件，从 plan.md 中提取的具体任务清单。
5. /speckit.implement：执行开发。

安装：

# 1. 安装 uv（如果还没有）curl -LsSf https://astral.sh/uv/install.sh | sh# 2. 安装 Specify CLI（持久安装，推荐）uv tool install specify-cli --from git+https://github.com/github/spec-kit.git# 3. 验证安装specify check

项目初始化：

# 创建新项目specify init my-project --ai claude# 在当前目录初始化specify init . --ai claude# 或使用 --here 标志specify init --here --ai claude# 强制初始化（跳过确认）specify init . --force --ai claude

初始化后的目录结构：

your-project/├── .specify/│   ├── memory/│   │   └── constitution.md    # 项目宪法│   ├── scripts/               # 内置脚本│   ├── specs/                 # 功能规范目录│   └── templates/             # 模板文件│       ├── plan-template.md│       ├── spec-template.md│       └── tasks-template.md└── CLAUDE.md                  # AI 助手配置（根据选择的 AI 而定）

使用：假设要开发一个团队协作应用 Taskify。

# 步骤一：建立项目宪法# 这会在 .specify/memory/constitution.md 中创建项目的治理原则。/speckit.constitution 建立代码质量、TDD 开发模式、MVP 原型、测试标准和用户体验一致性的原则# 步骤二：创建功能规范（What & Why）/speckit.specify 开发 GPU 运营管理平台，这是一个能够让启动训练和推理任务的用户能够知道自己的 GPU 集群的利用率是好还是坏，以及怎么好怎么坏的平台。你还要参考我头脑风暴的产出材料 docs/mvp-plan.md。# 步骤三：创建技术计划/speckit.plan 详细地参考 @docs/ 目录下的文件，里面有详细的技术方案和计划。# 步骤四：分解任务/speckit.tasks 分解为前端和后端两大块任务组，每个任务组下面再细分各自的任务。因为这样的话后面我的 AgentTeam 就可以各自工作和配合了。# 步骤五：执行实现/speckit.implement 请组建一个团队（AgentTeam） 来进行开发：成员和分工包括一个 UI 设计大师负责 UI 设计的检查和校对，一个前端开发专家负责前端开发，一个后端开发专家负责后端开发，一个负责测试专家负责编写测试用例保障产品质量。请作为你作为 Tech Lead 分配和协调工作，采用 TDD 开发模式。使用 Superpower 提供的 skills 来支持开发工作。# 结果.specify/├── memory/│   └── constitution.md├── specs/│   └── 001-create-taskify/│       ├── spec.md              # 功能规范│       ├── plan.md              # 技术计划│       ├── tasks.md             # 任务清单│       ├── research.md          # 技术研究│       ├── data-model.md        # 数据模型│       ├── quickstart.md        # 快速开始指南│       └── contracts/│           ├── api-spec.json    # API 契约│           └── signalr-spec.md  # SignalR 规范└── templates/    ├── plan-template.md    ├── spec-template.md    └── tasks-template.m

其他指令：

1. /speckit.clarify：澄清规范中不明确的地方（推荐在 /speckit.plan 前使用）。
2. /speckit.analyze：跨工件一致性和覆盖率分析（在 /speckit.tasks 后、/speckit.implement 前使用）
3. /speckit.checklist：生成自定义质量检查清单。

NOTE：值得注意的是，Spec-Kit 在头脑风暴和方案设计方面的支持是严重不足的，需要结合 Claude Code Plan mode 或 Superpower 头脑风暴来进行补全。

OpenSpec

OpenSpec 是一个由 Fission‑AI 团队开源的轻量级 SDD 框架，主打：

1. 灵活的、可自定义的工作流；
2. 对已有项目更友好；
3. 流程极简；

定位：比 Spec‑Kit 更轻，但比 IDE（如 Claude Code）自带的简单 Plan Mode 更有结构。

• https://github.com/Fission-AI/OpenSpec

OpenSpec 定义了一套面向 SSD 的 OPSX 工作流，用 “提案 → 审查 → 实现 → 归档” 替代传统开发的 “需求、设计、开发….”，实现了更灵活的迭代协作。OPSX 是一套结构化的、行动导向的代码变更管理流程，旨在通过规范化和可追溯的方式，将需求、设计、实现与验证串联为完整生命周期。

OPSX 的典型工作流：

1. /opsx:explore：探索想法，思考问题（可选）
2. /opsx:new：开始新的变更（创建 proposal）
3. /opsx:continue：逐步创建工件（specs、design、tasks）
4. /opsx:apply：实施阶段，执行任务并更新工件
5. /opsx:archive：归档完成的功能到知识库
6. /opsx:ff：快速前进，一次性创建所有规划工件
7. /opsx:sync：同步到主分支（可选）

安装：

# 方式一：全局安装（推荐）npm install -g @fission-ai/openspec@latest# 方式二：项目级安装npm install --save-dev @fission-ai/openspec# 方式三：使用 npx 直接运行npx @fission-ai/openspec init

初始化项目：

# 在项目根目录运行openspec init# 这会创建以下结构：# your-project/# ├── .openspec/# │   ├── changes/            # 活跃变更（OPSX workflow）# │   ├── changes/archive/     # 归档的变更（知识库）# │   ├── config.yaml         # 项目配置（可选）# │   └── schemas/           # 自定义工作流模式（可选）# └── .claude/skills/openspec-*  # 自动生成的技能# 配置文件（可选）$ vim openspec/config.yaml# 默认工作流模式（当前为 spec-driven）schema: spec-driven # 项目上下文，会注入到所有工件context: |  Tech stack: TypeScript, React, Node.js  API conventions: RESTful, JSON responses  Testing: Vitest for unit tests, Playwright for e2e  Style: ESLint with Prettier, strict TypeScript# 每个工件的具体规则rules:  proposal:    - Include rollback plan    - Identify affected teams  specs:    - Use Given/When/Then format for scenarios  design:    - Include sequence diagrams for complex flows

使用：

# 步骤一：探索想法# 这是一个思考伙伴，帮助澄清想法、比较选项、明确需求。/opsx:explore# 步骤二：创建新变更# AI 会询问：你想构建什么？你想构建什么？/opsx:new Add user profile page# 生成的工件结构：openspec/changes/add-user-profile-page/├── proposal.md           # 变更提案（为什么、范围、方法）├── specs/                # 功能规范│   └── spec.md├── design.md             # 技术设计└── tasks.md              # 实施任务清单# 步骤三：逐步创建工件# 每次调用会：检查哪些工件已准备好、创建一个工件、显示解锁的下一个工件/opsx:continue# 步骤四：快速前进# 使用场景：当你已经清楚要构建什么，想要快速启动时。一次性创建所有规划工件/opsx:ff add-user-profile-page# 步骤五：实施# AI 会：遍历 tasks.md 中的任务、逐一实现、实时更新任务状态、如有问题，更新 specs/ 或 design/。/opsx:apply# 步骤六：归档# 将变更移动到知识库：openspec/changes/archive/2025-02-12-add-user-profile-page//opsx:archive add-user-profile-page

查看当前变更状态：

$ openspec status --change add-user-profile-page --json{  "artifacts": [    {"id": "proposal", "status": "done"},    {"id": "specs", "status": "ready"},    {"id": "design", "status": "ready"},    {"id": "tasks", "status": "in_progress"}  ]}

Spec-Kit v.s. OpenSpec

Spec‑Kit：

1. 项目现状：从 0 到 1 的项目。
2. 项目规模：多人协作大型项目，把 “宪法、规格、计划、任务” 一次性搭好，团队即可围绕着这些文件进行讨论和迭代。
3. 成本投入：大，涵盖完整的软件工程流程，每个需求走一个完整工作流程。
4. 质量控制：高。

OpenSpec：

1. 项目现状：适用于现有项目，擅长在已有项目上做小步快跑。
2. 项目规模：个人、小团队项目。
3. 成本投入：每次改动都对应一个 Proposal，轻松上手，不必为一个小需求走一个完整的 Spec‑Kit 全流程。
4. 质量控制：较低。

Superpowers

Superpowers 是由 Jesse Vincent 开发的 AI 编程方法论和 Skills 集合，是一套让 AI 更高效、更可靠地执行编码任务的最佳实践集合。通过 Skills 引导 AI 像高级工程师一样工作，每个 Skill 都是一个强制性的检查点，不是 “建议你这样做”，而是 “必须这样做”。例如：AI 想写代码？先把需求理清楚。想提交代码？先过测试。

Superpowers = 开发速度 -30%，代码稳定性 +50%，测试覆盖率 =92%！

• https://github.com/obra/superpowers

┌─────────────────────────────────────────────────────────┐│                    Superpowers 方法论                    │├─────────────────────────────────────────────────────────┤│  🧪 TDD-First      │ 强制 AI 先写测试，再写实现             │├─────────────────────────────────────────────────────────┤│  🤖 Sub-Agents     │ 拆分复杂任务给专门的子代理             │├─────────────────────────────────────────────────────────┤│  📝 Code Review    │ 实现后自动触发代码审查                 │├─────────────────────────────────────────────────────────┤│  🔍 Exploration    │ 实现前先充分探索代码库                 │├─────────────────────────────────────────────────────────┤│  ✅ Verification   │ 每步都要验证，不盲目前进               │└─────────────────────────────────────────────────────────┘

Superpowers 把软件开发拆成了 7 个阶段，每个阶段都有对应的技能：

1. 头脑风暴（Brainstorming）：和 AI 先讨论清楚要做什么，形成设计文档。
2. 工作树隔离（Git Worktrees）：创建独立的开发环境，互不干扰。
3. 编写计划（Writing Plans）：把大任务分解成 2-5 分钟能完成的小任务。
4. 子代理开发（Subagent Development）：每个任务由独立的 Agent 处理。
5. 测试驱动开发（TDD）：先写测试，再写代码，必须通过。
6. 代码审查（Code Review）：双重检查：功能符合性 + 代码质量。
7. 完成分支（Finishing Branch）：合并代码或创建 PR。

Superpowers 的 Skills 集合：

• brainstorming：在任何创造性工作前先头脑风暴，理解需求后再动手。硬性规定：在用户批准设计之前，禁止写任何代码。
• 理解项目上下文：扫描现有代码库，了解项目的技术栈和架构。
• 对需求进行逐个问题澄清：一次只问一个问题，不会假设答案，根据你的回答调整后续问题。
• 提出方案：给出 2-3 个可行的实现方案，让你做选择，而不是帮你做决定。
• 保存设计文档，把讨论结果整理成文档
• writing-plans：用于编写实施计划。它会根据头脑风暴阶段的成果将计划写成一个个文件，例如：docs/plans/2026-03-05-frontend-ui-design.md。
• using-git-worktrees：使用 Git Worktree 创建隔离的工作空间。Superpowers 会为每个开发任务创建一个独立的工作目录。这样你可以同时处理多个任务，互不干扰。就算 AI 把功能 A 搞砸了，也不会影响功能 B 的代码。
• subagent-driven-development：子代理驱动开发，为每个任务派发独立子代理 + 两阶段审查。审查者是另一个独立的 AI 代理，两个代理互相制衡，质量更有保障。
• 提取所有任务到 TodoWrite
• 为每个独立任务派发子代理
• 两阶段审查：1）规格合规审查：实现是否完全符合设计文档、有没有添加需求以外的功能、有没有遗漏需求里的功能；2）代码质量审查：命名规范是否一致、测试覆盖率是否达标、是否有重复代码、是否有潜在的性能问题。
• executing-plans ：执行已制定的实施计划。
• finishing-a-development-branch：完成开发分支。合并、创建 PR 或保留。
• requesting-code-review：请求代码审查。
• 分析代码变更
• 从多个角度审查：代码质量、安全性、性能、测试覆盖率、文档完整性
• 提供具体建议
• receiving-code-review：接收并处理代码审查反馈。
• systematic-debugging：系统化调试，解决 bug 时使用。
• 复现问题
• 分析相关代码
• 定位根本原因
• 提出修复方案
• 验证修复
• test-driven-development：TDD 工作流，测试驱动开发。硬性规定：如果写了代码但没有先写测试？删掉代码，重新开始。
• verification-before-completion：完成前验证，每步都要验证
• writing-skills：编写自定义技能。

安装：

# Project 级别的安装，而非全局# 1. 注册 Superpowers 市场/plugin marketplace add obra/superpowers-marketplace# 2. 安装 Superpowers 插件/plugin install superpowers@superpowers-marketplace# 重新进入 Claude Code# 验证安装/help # 看到 brainstorm、write-plan、execute-plan 这 3 个命令就说明安装成功。# 更新 Superpowerscd ~/.claude/superpowersgit pull

使用方式一 Cammands：

# 先搞明白要做什么/superpowers:brainstorm# 写个谁都能看懂的计划/superpowers:write-plan# 按计划一步步实现/superpowers:execute-plan

使用方式二 Skills：你不需要记住所有技能名称，只需说出你的需求，Superpowers 会自动选择合适的技能。

Spec-Kit v.s. OpenSpec v.s. Superpowers

Spec-Kit 和 OpenSpec 都是 SDD 的框架性工具，是二选一的。而 Superpowers 则是作为 SDD 中软件开发这一环节的辅助工具，与两者互补。

例如：Spec-Kit 其实少了一个头脑风暴的环节，这个可以通过 CC plan mode 和 Superpower brainstorm 来进行补充。并且在 Superpower write-plan 的时候可以读取到 CC plan mode 保存下载的计划初稿文件，然后进行整合。

SDD 实践经验

注重文档质量

以前文档是给人看的，为了让新同事上手。现在文档是给 AI 看的，为了让 Agent 理解上下文。如果文档不完备，AI 就会瞎猜（幻觉）；如果文档写得好，AI 就能深度理解项目。

虚拟团队开发

你不再是盯着屏幕敲键盘的工人，而是指挥官。你不断在各个 Agent 间切换，检查结果、微调指令、再启动新任务。使用多 Agent 并行（Multi-Agent Parallelism），比如同时运行 5-10 个 AI Agent。

闭环开发

为什么 AI 写代码比写文章强？因为代码可以被验证。代码有天然的反馈循环（编译、测试、运行），而文章没有。这种开发模式强迫开发者设计更清晰、更易验证的系统架构，因为只有这样，AI 才能介入工作。

对抗验收（交叉验证）

质量控制的核心已经从 “写代码” 转移到了 “设计 + 验收”。最常见于 Code Review 阶段，只用一个 Agent 来开发加 Code Review，这样的质量是不够的。要让不同的 Agent 进行对抗验收，彼此制衡。两个不同架构、不同训练数据的模型，犯同一个错误的概率远低于单个模型。

例如：

1. Claude Code 做原型与粗活，负责创建和开发 Story，快速出初版代码。
2. CodeX 5.3 做 Code Review 审查未提交的修改，逐条提出 P0/P1/P2 级别的问题。在这个过程中，需要人类的判断力介入，判断 Codex 哪些问题要修，哪些是误报。如果你认为是误报而非 Bug，或者错误理解了你的设计意图，就让它写清楚注释，更新设计文档，防止以后重复误报。
3. 就进入来回对抗的环节。让 Claude 来 Review CodeX 的修改，评价它的 Review 结果。然后不断反复，如有分歧，继续对抗，直到达成共识。