Vibe Coding v.s. Spec Coding
Vibe Coding（氛围编程），即：仅凭借感觉和聊天驱动 AI 编程，强调即时性和程序员的直觉。
- 及时性：立即就让 AI 写代码，不需要任何前期准备。
- 程序员的直觉：通过经验转化的直觉来提需求，让 AI 做事情。
优点：快，及时实现你的需求，不用多想全凭直觉； 缺点：需求仅存在于聊天记录，需求描述不规范、不清晰、不可追溯，需求质量全凭程序员经验高低。 适用场景：小需求、小修改，例如：让 AI 临时写个小脚本。统称为 AI 辅助编程场景。
Vibe Coding 的核心痛点：需求一旦复杂，单靠对话描述很容易产生理解偏差，最后得到的代码和预期相差甚远，甚至根本没法直接用。
Spec Coding（规格编程），即：先想好之后再让 AI 编程，强调整体性、规划性和规范性。
- 整体性：从整个项目/系统的角度出发，整体考虑'人、事、物'三个维度。
- 规划性：先写好你的需求描述文档，并规划好要如何设计、实现、测试、交付你的需求。
- 规范性：所有人遵守同一套软件工程规范的约束，使得项目需求可观测、可追溯、可解析、可控制、可移交。
优点：需求清晰合规、软件质量有保障。 缺点：前期规划需要投入较多的'脑力'和时间。 适用场景：AI 驱动的大型生产项目，例如：AI 连续编程 24 小时。统称为 AI 原生（自主）编程场景。
Spec Coding —— AI 编程新范式
核心思维：
- I ship code I don't read（我发布我不读的代码）—— OpenClaw 创始人 Steinberger，一个月内没写一行代码，却'写完了'40w 行代码。
- 我们正在从'代码是真理之源'转向'意图是真理之源'。
- AI 应用工程师，而非程序员；写提示词，而非代码。
面对 2 大难题（一头一尾）：
- 需求：如何让 AI 真正理解我们的意图，并按照预期的方式工作？
- 质量：如何保证质量？
大型软件系统的本质，是确定性和稳定性！而 AI 本质上是一个概率模型，这是它的数学本质。懂得基于 AI 构建确定性系统的工程师，将是 AI 时代不可替代的能力。
方法
软件工程方法论
软件工程方法论，指用于指导、管理和执行'软件需求、设计、开发、测试、交付、运维'的过程的结构化方法、框架、原则和实践。
发展脉络和历史：
- 1970 年代：瀑布模型，迭代开发。
- 特点：稳定、保质、却慢，跟不上客户需求变化。
- 详细：强调预先详尽规划、严格的阶段性划分（需求 -> 设计 -> 开发 -> 测试 -> 交付 -> 运维）、文档驱动、变更控制严格、线性/顺序推进。目标是按计划、在预算内交付符合最初规格的软件。
- 2000 年后：敏捷开发，小步快跑。
- 特点：一味只求快、适应需求大爆发且变化快的时代背景。质量保证需要结合 CI 自动化工具和 CMMI 等质量改进框架。
- 详细：强调适应性、迭代和增量开发、快速交付可工作软件、客户协作、响应变化、个体和互动高于流程和工具。通过 Scrum 短周期迭代（Sprint）不断获取反馈并调整方向。
- 2010 年后：DevOps，开发 - 测试 - 运维一体化。
- 特点：强调弥合开发、测试、运维之间的鸿沟、强调跨部门协作，并通过自动化技术，既快又保质。
- 详细：基于'Kubernetes+ 微服务 + 云原生'技术底座之上的 CI/CD 自动化流水线。CI 包括：Code Review、单元测试覆盖率、自动化测试、自动化代码扫描；CD 包括：灰度发布、滚动升级、快速回滚。
- 2025 年开始：AI 原生开发。
- 特点：Spec Coding 重塑软件工程方法论。
SDD（规格驱动开发）模式
SDD（Specification‑Driven Development，规格驱动开发），用结构化的规格文档来指导和约束 AI 编程。规格文档作为 AI 唯一的可信源（Single Source of Truth），贯穿软件工程的整个生命周期。只要规则文档清晰、准确，AI 就能更稳定、更高效、更持久、更广泛地发挥。
一个典型的 SDD 流程如下：
- Brainstorm（头脑风暴）：和 AI 讨论请求需求。
- Map（地图）：根据头脑风暴产出需求的 PRD 规格文档，并拆解为敏捷开发的 Epic 和 Story 进行管理。
- Act（行动）：AI 循环处理这些 Epic 和 Story。
- Develop（开发）：AI 进行根据 PRD 规格文档进行实际的代码生成。
这样产出的代码是可追溯的、可验证的。每一行代码都能回溯到它对应的 Story，每个 Story 都能回溯到 PRD，PRD 能回溯到最初的需求。没有这条可追溯的信息链，就不是在做软件工程。
SDD 核心原则
- 规格是唯一真相：
- 所有计划都对齐规格
- 需求变更先改规格
- AI 按照规格调整代码
- 规格先行（规格模版内容）：
- 业务场景
- 用户故事
- 输入输出
- 边界条件
- 约束
- 非功能性需求
- 验收标准
- 规格可执行可验证
- 结构化 Markdown 和 YAML
- 驱动生成技术方案
- 派生测试用例
- 决策检查点
- 规格：人类审阅
- 计划：人类审阅
- 任务：人类审阅
- 实现：人类审阅
- 测试回归：人类审阅
SDD 三个层次
- Spec-First（规范优先）：先写好 spec，再交给 AI 实现。任务完成后 spec 不再维护。
- Spec-Anchored（规范锚定）：Spec 持续存在于仓库中，随功能演进同步更新，是系统意图的长期记录。
- Spec-as-Source（规范即源码）：人类只编辑 spec，代码完全由 AI 生成。规范本身就是'源文件'。
TDD（测试驱动开发）模式
AI 生成代码的速度是人类的万倍，但也可能在万分之一秒内引入致命漏洞。这时候，测试不再仅仅是质量保障，它是 AI 自动化迭代的闭环信号。
TDD（测试驱动开发）的思想是'测试代码优先，质量优先'，即：先编写测试用例，通过测试用例来反向约束实际功能代码。测试用例就是需求和质量的约束。
TDD 的核心循环：红 -> 绿 -> 重构
- 红（Red）：编写一个会失败的单元测试用例，要求对应一个具体的、粒度微小的新需求、新功能来编写。
- 绿（Green）：编写功能代码让单元测试用例通过，如果单元测试用例不通过，则表示功能不满足需求。在敏捷开发的场景中，要求最小化开发，避免过渡设计，能通过单元测试用例就行。
- 重构（Refactor）：绿阶段的代码未必是最优的，最后重构代码以达到设计良好且整洁的状态，并且能够通过测试用例。目标是消除重复、改善可读性、应用设计模式、优化结构，提升代码的整体质量。
- 回到第一步，写下个测试。
STDD（规格 - 测试驱动开发）
TDD 和 SDD 可以自然的融合起来。SDD 通过 Markdown 文档强调需求，TDD 通过 TestCase 强调质量。
ODD (Observability-Driven，可观测)
AI 生成的代码往往是'黑盒'。ODD 要求工程师在设计阶段就植入埋点、追踪（Tracing）和度量（Metrics）。开发者需要确保了这段 AI 代码在运行时的透明度，当它发生性能抖动或逻辑偏移时，系统能第一时间通过观测数据发出警报。
工具
Spec‑Kit
Spec‑Kit 是 GitHub 在 2025 年专为 SDD 设计的开发工具包，用来帮你在各种 AI 编码环境中（如 Copilot、Cursor 等）按 SDD 的方式工作。它把'写规格、做计划、拆任务、实现和审查'这一整套流程固化成可复用的命令和模板。
Spec‑Kit 的典型工作流：宪法 → 规格 → 计划 → 任务 → 实现 → 审查 & 测试 Spec‑Kit Prompt 模板：针对产品、架构、开发、测试等不同'角色'预置好提示词； Spec‑Kit CLI 工具：用于初始化项目、生成目录和基础文件。 Spec‑Kit 可以集成在 Claude Code 等环境中使用，提供了多个 Slash（斜杆）命令。如下：
- /speckit.constitution：编辑 CONSTITUTION.md 项目宪法文件，全局约束、开发准则。包括：代码质量标准、测试规范、用户体验一致性要求、性能要求等。
- /speckit.specify：编辑 spec.md 功能规范文件。包括：用户故事（谁、要什么、为什么）、功能需求、不涉及技术栈（关注 what 和 why）。
- /speckit.plan：编辑 plan.md 技术规划文件。包括：技术栈选择、架构选择、API 契约。
- /speckit.tasks：编辑 tasks.md 任务分解文件，从 plan.md 中提取的具体任务清单。
- /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
其他指令：
- /speckit.clarify：澄清规范中不明确的地方（推荐在 /speckit.plan 前使用）。
- /speckit.analyze：跨工件一致性和覆盖率分析（在 /speckit.tasks 后、/speckit.implement 前使用）
- /speckit.checklist：生成自定义质量检查清单。
NOTE：值得注意的是，Spec-Kit 在头脑风暴和方案设计方面的支持是严重不足的，需要结合 Claude Code Plan mode 或 Superpower 头脑风暴来进行补全。
OpenSpec
OpenSpec 是一个由 Fission‑AI 团队开源的轻量级 SDD 框架，主打：
- 灵活的、可自定义的工作流；
- 对已有项目更友好；
- 流程极简；
定位：比 Spec‑Kit 更轻，但比 IDE（如 Claude Code）自带的简单 Plan Mode 更有结构。
OpenSpec 定义了一套面向 SDD 的 OPSX 工作流，用'提案 → 审查 → 实现 → 归档'替代传统开发的'需求、设计、开发…'，实现了更灵活的迭代协作。OPSX 是一套结构化的、行动导向的代码变更管理流程，旨在通过规范化和可追溯的方式，将需求、设计、实现与验证串联为完整生命周期。
OPSX 的典型工作流：
- /opsx:explore：探索想法，思考问题（可选）
- /opsx:new：开始新的变更（创建 proposal）
- /opsx:continue：逐步创建工件（specs、design、tasks）
- /opsx:apply：实施阶段，执行任务并更新工件
- /opsx:archive：归档完成的功能到知识库
- /opsx:ff：快速前进，一次性创建所有规划工件
- /opsx:sync：同步到主分支（可选）
┌───────────────────────────────────────────────────────────────────┐
│ OPSX Workflow │
│ (灵活动作，迭代流动） │
├────────────────────────────────────────────────────────────────────┤
│ /opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive │
│ │ │
│ │ │
│ │ │
│ └───────────────┴───────────────┴──────────────┘ │
│ 创建工件 逐步实施 归档 │
└───────────────────────────────────────────────────────────────────┘
安装：
# 方式一：全局安装（推荐）
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：
- 项目现状：从 0 到 1 的项目。
- 项目规模：多人协作大型项目，把'宪法、规格、计划、任务'一次性搭好，团队即可围绕着这些文件进行讨论和迭代。
- 成本投入：大，涵盖完整的软件工程流程，每个需求走一个完整工作流程。
- 质量控制：高。
OpenSpec：
- 项目现状：适用于现有项目，擅长在已有项目上做小步快跑。
- 项目规模：个人、小团队项目。
- 成本投入：每次改动都对应一个 Proposal，轻松上手，不必为一个小需求走一个完整的 Spec‑Kit 全流程。
- 质量控制：较低。
Superpowers
Superpowers 是由 Jesse Vincent 开发的 AI 编程方法论和 Skills 集合，是一套让 AI 更高效、更可靠地执行编码任务的最佳实践集合。通过 Skills 引导 AI 像高级工程师一样工作，每个 Skill 都是一个强制性的检查点，不是'建议你这样做'，而是'必须这样做'。例如：AI 想写代码？先把需求理清楚。想提交代码？先过测试。
Superpowers = 开发速度 -30%，代码稳定性 +50%，测试覆盖率 =92%！
┌─────────────────────────────────────────────────────────┐
│ Superpowers 方法论 │
├─────────────────────────────────────────────────────────┤
│ 🧪 TDD-First │ 强制 AI 先写测试，再写实现 │
├─────────────────────────────────────────────────────────┤
│ 🤖 Sub-Agents │ 拆分复杂任务给专门的子代理 │
├─────────────────────────────────────────────────────────┤
│ 📝 Code Review │ 实现后自动触发代码审查 │
├─────────────────────────────────────────────────────────┤
│ 🔍 Exploration │ 实现前先充分探索代码库 │
├─────────────────────────────────────────────────────────┤
│ ✅ Verification │ 每步都要验证，不盲目前进 │
└─────────────────────────────────────────────────────────┘
Superpowers 把软件开发拆成了 7 个阶段，每个阶段都有对应的技能：
- 头脑风暴（Brainstorming）：和 AI 先讨论清楚要做什么，形成设计文档。
- 工作树隔离（Git Worktrees）：创建独立的开发环境，互不干扰。
- 编写计划（Writing Plans）：把大任务分解成 2-5 分钟能完成的小任务。
- 子代理开发（Subagent Development）：每个任务由独立的 Agent 处理。
- 测试驱动开发（TDD）：先写测试，再写代码，必须通过。
- 代码审查（Code Review）：双重检查：功能符合性 + 代码质量。
- 完成分支（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 个命令就说明安装成功。
# 更新 Superpowers
cd ~/.claude/superpowers git 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 保存下载的计划初稿文件，然后进行整合。
BMAD 多 Agent 虚拟团队
BMAD 采用 Multi-Agent 协作模式，模拟完整软件开发团队的角色分工和协作流程，号称是最复杂的 SDD 框架。它解决的是：在只有一个人、或者一个小团队的情况下，怎么把 AI 组织成一套相对稳定的研发流程。
BMAD 覆盖了典型敏捷团队中的关键角色，提供了 21 个专业化 Agent，例如：
- Product Owner：目标定义、方案决策、门禁规则与风险控制。
- PM Agent：负责产品规划，输出 story.md
- Architect Agent：负责技术方案，输出 arch.md
- Developer Agent：负责编码实现，输出 dev.md
- QA Agent：负责测试验证，输出 qa.md
- 业务分析师
- UX 专家
- Scrum Master（敏捷教练）
BMAD 定义了一套 BMAD-METHOD（Breakthrough Method of Agile AI-Driven Development，敏捷 AI 驱动开发的突破性方法），是一套明确约束人和 AI 如何协作的开发方式。
BMAD-METHOD 把整个开发过程稳定地拆成 4 个要素：
- 人：负责设计、决策、兜底。
- AI：负责执行。
- 流程：约束什么时候做什么事。
- 工件：把每一步结果落成可追溯的产出。
让项目是被流程推动的，而不是被对话推着走。
并且，在 BMAD 的设计里，不要把 AI 当成'万能助手'，而是把 AI 当成多个有分工的角色。
- 有的 AI 只负责分析需求
- 有的只负责写计划和拆任务
- 有的只负责实现和测试
- 有的只做检查和验收
在写任何代码之前，先把谁负责什么、要交付什么说清楚。每个角色只在自己的阶段工作，不跨界、不抢活。角色建模的目的在于，将复杂问题拆分并分配到合适的职责单元。
角色既可以由人类承担，也可以由 AI 智能体承担，但职责边界必须清晰。
在 BMAD 中，谁定义目标、谁产出补丁、谁负责审核与验收，都需要在流程起点明确；每一次改动都必须以工件形式落地，而非停留在对话框中。
BMAD 明确要求所有关键活动都要产出可持久化工件，包括：
- 计划工件：需求分析、范围说明、任务拆解（CSV / 表格）
- 实现工件：补丁（Patch）、接口契约、配置与脚手架
- 验证工件：测试用例、联调记录、性能与安全检查
- 交付工件：上线清单、回滚方案、监控与告警配置
安装：
npx bmad-method install
指令：
/analyst # 分析需求
/pm # 写 PRD
/architect # 设计架构
/sm # 拆用户故事
/dev # 写代码 + 测试
AWS Kiro（SDD-Native IDE）
AWS 于 2025 年 7 月推出的首款 SDD 原生 IDE，由 Code OSS（VS Code 同源）分支构建，将 SDD 流程嵌入到 IDE 的核心模块。
核心特性：
- Spec MVP：在 Spec 创建阶段，可以把测试等任务标记为可选项，优先聚焦核心功能，同时保留完整任务列表的可见性。
- Hooks 机制驱动的自动化：比如在保存文件、提交代码等事件触发时，自动更新测试、文档、安全扫描等任务，实现真正的全程自动化。
- 属性测试（Property-Based Testing）：单元测试就像老师出了三道例题让你对答案，只要这三道题对了就算通过；而 PBT 你只需要告诉它一条规则，它就会自动生成几百道随机题来反复验证这条规则有没有被打破。
SDD 实践
注重文档
以前文档是给人看的，为了让新同事上手。现在文档是给 AI 看的，为了让 Agent 理解上下文。
如果文档不完备，AI 就会瞎猜（幻觉）；如果文档写得好，AI 就能深度理解项目。Agent 每次执行前，都会花 10-15 分钟'阅读'文档，这是高质量产出的前提。
团队开发
你不再是盯着屏幕敲键盘的工人，而是指挥官。你不断在各个 Agent 间切换，检查结果、微调指令、再启动新任务。 多 Agent 并行（Multi-Agent Parallelism）：同时运行 5-10 个 AI Agent。
闭环开发（Closing the Loop）
为什么 AI 写代码比写文章强？因为代码可以被验证。代码有天然的反馈循环（编译、测试、运行），而文章没有。这种开发模式强迫开发者设计更清晰、更易验证的系统架构，因为只有这样，AI 才能介入工作。
原子化提交
日均 124 次提交，平均每 11 分钟一次。这并没有导致代码库混乱，反而带来了极高的稳定性。
每个 Commit 只解决一个问题。哪怕错了，回滚也只影响局部，不会牵一发而动全身。
对抗验收（交叉验证）
质量控制的核心已经从'写代码'转移到了'设计 + 验收'。
最常见于 Code Review 阶段，只用一个 Agent 来开发加 Code Review，这样的质量是不够的。要让不同的 Agent 进行对抗验收，彼此制衡。两个不同架构、不同训练数据的模型，犯同一个错误的概率远低于单个模型。
例如：
- Claude Code 做原型与粗活，负责创建和开发 Story，快速出初版代码。
- CodeX 5.3 做 Code Review 审查未提交的修改，逐条提出 P0/P1/P2 级别的问题。在这个过程中，需要人类的判断力介入，判断 Codex 哪些问题要修，哪些是误报。如果你认为是误报而非 Bug，或者错误理解了你的设计意图，就让它写清楚注释，更新设计文档，防止以后重复误报。
- 就进入来回对抗的环节。让 Claude 来 Review CodeX 的修改，评价它的 Review 结果。然后不断反复，如有分歧，继续对抗，直到达成共识。
