AI 编程新范式：Spec Coding 方法与工具

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

发展脉络和历史：

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 能回溯到最初的需求。没有这条可追溯的信息链，就不是在做软件工程。

SDD 核心原则

1. 规格是唯一真相：
   1. 所有计划都对齐规格
   2. 需求变更先改规格
   3. AI 按照规格调整代码
2. 规格先行（规格模版内容）：
   1. 业务场景
   2. 用户故事
   3. 输入输出
   4. 边界条件
   5. 约束
   6. 非功能性需求
   7. 验收标准
3. 规格可执行可验证
   1. 结构化 Markdown 和 YAML
   2. 驱动生成技术方案
   3. 派生测试用例
4. 决策检查点
   1. 规格：人类审阅
   2. 计划：人类审阅
   3. 任务：人类审阅
   4. 实现：人类审阅
   5. 测试回归：人类审阅

SDD 三个层次

1. Spec-First（规范优先）：先写好 spec，再交给 AI 实现。任务完成后 spec 不再维护。
2. Spec-Anchored（规范锚定）：Spec 持续存在于仓库中，随功能演进同步更新，是系统意图的长期记录。
3. Spec-as-Source（规范即源码）：人类只编辑 spec，代码完全由 AI 生成。规范本身就是'源文件'。

TDD（测试驱动开发）模式

AI 生成代码的速度是人类的万倍，但也可能在万分之一秒内引入致命漏洞。这时候，测试不再仅仅是质量保障，它是 AI 自动化迭代的闭环信号。

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

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

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

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 的方式工作。它把'写规格、做计划、拆任务、实现和审查'这一整套流程固化成可复用的命令和模板。

• 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 定义了一套面向 SDD 的 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：同步到主分支（可选）

┌───────────────────────────────────────────────────────────────────┐
│ 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：

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 个命令就说明安装成功。
# 更新 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 个要素：

1. 人：负责设计、决策、兜底。
2. AI：负责执行。
3. 流程：约束什么时候做什么事。
4. 工件：把每一步结果落成可追溯的产出。

让项目是被流程推动的，而不是被对话推着走。

并且，在 BMAD 的设计里，不要把 AI 当成'万能助手'，而是把 AI 当成多个有分工的角色。

• 有的 AI 只负责分析需求
• 有的只负责写计划和拆任务
• 有的只负责实现和测试
• 有的只做检查和验收

在写任何代码之前，先把谁负责什么、要交付什么说清楚。每个角色只在自己的阶段工作，不跨界、不抢活。角色建模的目的在于，将复杂问题拆分并分配到合适的职责单元。

角色既可以由人类承担，也可以由 AI 智能体承担，但职责边界必须清晰。

在 BMAD 中，谁定义目标、谁产出补丁、谁负责审核与验收，都需要在流程起点明确；每一次改动都必须以工件形式落地，而非停留在对话框中。

BMAD 明确要求所有关键活动都要产出可持久化工件，包括：

1. 计划工件：需求分析、范围说明、任务拆解（CSV / 表格）
2. 实现工件：补丁（Patch）、接口契约、配置与脚手架
3. 验证工件：测试用例、联调记录、性能与安全检查
4. 交付工件：上线清单、回滚方案、监控与告警配置

安装：

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 的核心模块。

核心特性：

1. Spec MVP：在 Spec 创建阶段，可以把测试等任务标记为可选项，优先聚焦核心功能，同时保留完整任务列表的可见性。
2. Hooks 机制驱动的自动化：比如在保存文件、提交代码等事件触发时，自动更新测试、文档、安全扫描等任务，实现真正的全程自动化。
3. 属性测试（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 进行对抗验收，彼此制衡。两个不同架构、不同训练数据的模型，犯同一个错误的概率远低于单个模型。

例如：

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