目录文章目录目录Vibe Coding v.s. Spec CodingSpec Coding —— AI 编程新范式方法软件工程方法论SDD规格驱动开发模式SDD 核心原则SDD 三个层度TDD测试驱动开发模式STDD规格-测试驱动开发ODD (Observability-Driven可观测)工具Spec‑KitOpenSpecSpec-Kit v.s. OpenSpecSuperpowersSpec-Kit v.s. OpenSpec v.s. SuperpowersBMAD 多 Agent 虚拟团队AWS KiroSDD-Native IDESDD 实践注重文档团队开发闭环开发Closing the Loop原子化提交对抗验收交叉验证Vibe Coding v.s. Spec CodingVibe Coding氛围编程即仅凭借感觉和聊天驱动 AI 编程强调即时性和程序员的直觉。及时性立即就让 AI 写代码不需要任何前期准备。程序员的直觉通过经验转化的直觉来提需求让 AI 做事情。优点快及时实现你的需求不用多想全凭直觉缺点需求仅存在于聊天记录需求描述不规范、不清晰、不可追述需求质量全凭程序员经验高低。适用场景小需求、小修改例如让 AI 临时写个小脚本。统称为 AI 副驾copilot编程场景。Vibe Coding 的核心痛点需求一旦复杂单靠对话描述很容易产生理解偏差最后得到的代码和预期相差甚远甚至根本没法直接用。Spec Coding规格编程即先想好之后再让 AI 编程强调整体性、规划性和规范性。整体性从整个项目/系统的角度出发整体考虑 “人、事、物” 三个维度。规划性先写好你的需求描述文档并规划好要如何设计、实现、测试、交付你的需求。规范性所有人遵守同一套软件工程规范的约束使得项目需求可观测、可追溯、可解析、可控制、可移交。优点需求清晰合规、软件质量有保障。缺点前期规划需要投入较多的 “脑力” 和时间。适用场景AI 驱动的大型生产项目例如AI 连续编程 24 小时https://36kr.com/p/3560921828998273。统称为 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规格驱动开发模式SDDSpecification‑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 都能回溯到 PRDPRD 能回溯到最初的需求。没有这条可追溯的信息链就不是在做软件工程。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‑KitSpec‑Kit 是 GitHub 在 2025 年专为 SDD 设计的开发工具包用来帮你在各种 AI 编码环境中如 Copilot、Cursor 等按 SDD 的方式工作。它把 “写规格、做计划、拆任务、实现和审查” 这一整套流程固化成可复用的命令和模板。https://github.com/github/spec-kitSpec‑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-LsSfhttps://astral.sh/uv/install.sh|sh# 2. 安装 Specify CLI持久安装推荐uv toolinstallspecify-cli--fromgithttps://github.com/github/spec-kit.git# 3. 验证安装specify check项目初始化# 创建新项目specify init my-project--aiclaude# 在当前目录初始化specify init.--aiclaude# 或使用 --here 标志specify init--here--aiclaude# 强制初始化跳过确认specify init.--force--aiclaude初始化后的目录结构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# 技术研究│ ├──># 数据模型│ ├── 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 头脑风暴来进行补全。OpenSpecOpenSpec 是一个由 Fission‑AI 团队开源的轻量级 SDD 框架主打灵活的、可自定义的工作流对已有项目更友好流程极简定位比 Spec‑Kit 更轻但比 IDE如 Claude Code自带的简单 Plan Mode 更有结构。https://github.com/Fission-AI/OpenSpecOpenSpec 定义了一套面向 SSD 的 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 │ │ │ │ │ │ │ │ └───────────────┴───────────────┴──────────────┘ │ │ 创建工件 逐步实施 归档 │ └───────────────────────────────────────────────────────────────────┘安装# 方式一全局安装推荐npminstall-gfission-ai/openspeclatest# 方式二项目级安装npminstall--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-* # 自动生成的技能# 配置文件可选$vimopenspec/config.yaml# 默认工作流模式当前为 spec-drivenschema: spec-driven# 项目上下文会注入到所有工件context:|Tech stack: TypeScript, React, Node.js API conventions: RESTful, JSON responses Testing: Vitestforunit tests, Playwrightfore2e Style: ESLint with Prettier, strict TypeScript# 每个工件的具体规则rules: proposal: - Include rollback plan - Identify affected teams specs: - Use Given/When/Thenformatforscenarios design: - Include sequence diagramsforcomplex 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--changeadd-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. OpenSpecSpec‑Kit项目现状从 0 到 1 的项目。项目规模多人协作大型项目把 “宪法、规格、计划、任务” 一次性搭好团队即可围绕着这些文件进行讨论和迭代。成本投入大涵盖完整的软件工程流程每个需求走一个完整工作流程。质量控制高。OpenSpec项目现状适用于现有项目擅长在已有项目上做小步快跑。项目规模个人、小团队项目。成本投入每次改动都对应一个 Proposal轻松上手不必为一个小需求走一个完整的 Spec‑Kit 全流程。质量控制较低。SuperpowersSuperpowers 是由 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 个阶段每个阶段都有对应的技能头脑风暴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-developmentTDD 工作流测试驱动开发。硬性规定如果写了代码但没有先写测试删掉代码重新开始。verification-before-completion完成前验证每步都要验证writing-skills编写自定义技能。安装# Project 级别的安装而非全局# 1. 注册 Superpowers 市场/plugin marketplaceaddobra/superpowers-marketplace# 2. 安装 Superpowers 插件/plugininstallsuperpowerssuperpowers-marketplace# 重新进入 Claude Code# 验证安装/help# 看到 brainstorm、write-plan、execute-plan 这 3 个命令就说明安装成功。# 更新 Superpowerscd~/.claude/superpowersgitpull使用方式一 Cammands# 先搞明白要做什么/superpowers:brainstorm# 写个谁都能看懂的计划/superpowers:write-plan# 按计划一步步实现/superpowers:execute-plan使用方式二 Skills你不需要记住所有技能名称只需说出你的需求Superpowers 会自动选择合适的技能。Spec-Kit v.s. OpenSpec v.s. SuperpowersSpec-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.mdArchitect Agent负责技术方案输出 arch.mdDeveloper Agent负责编码实现输出 dev.mdQA Agent负责测试验证输出 qa.md业务分析师UX 专家Scrum Master敏捷教练BMAD 定义了一套 BMAD-METHODBreakthrough Method of Agile AI-Driven Development敏捷 AI 驱动开发的突破性方法是一套明确约束人和 AI 如何协作的开发方式。BMAD-METHOD 把整个开发过程稳定地拆成 4 个要素人负责设计、决策、兜底。AI负责执行。流程约束什么时候做什么事。工件把每一步结果落成可追溯的产出。让项目是被流程推动的而不是被对话推着走。并且在 BMAD 的设计里不要把 AI 当成 “万能助手”而是把 AI 当成多个有分工的角色。有的 AI 只负责分析需求有的只负责写计划和拆任务有的只负责实现和测试有的只做检查和验收在写任何代码之前先把谁负责什么、要交付什么说清楚。每个角色只在自己的阶段工作不跨界、不抢活。角色建模的目的在于将复杂问题拆分并分配到合适的职责单元。角色既可以由人类承担也可以由 AI 智能体承担但职责边界必须清晰。在 BMAD 中谁定义目标、谁产出补丁、谁负责审核与验收都需要在流程起点明确每一次改动都必须以工件形式落地而非停留在对话框中。BMAD 明确要求所有关键活动都要产出可持久化工件包括计划工件需求分析、范围说明、任务拆解CSV / 表格实现工件补丁Patch、接口契约、配置与脚手架验证工件测试用例、联调记录、性能与安全检查交付工件上线清单、回滚方案、监控与告警配置安装npx bmad-methodinstall指令/analyst# 分析需求/pm# 写 PRD/architect# 设计架构/sm# 拆用户故事/dev# 写代码 测试AWS KiroSDD-Native IDEAWS 于 2025 年 7 月推出的首款 SDD 原生 IDE由 Code OSSVS Code 同源分支构建将 SDD 流程嵌入到 IDE 的核心模块。核心特性Spec MVP在 Spec 创建阶段可以把测试等任务标记为可选项优先聚焦核心功能同时保留完整任务列表的可见性。Hooks 机制驱动的自动化比如在保存文件、提交代码等事件触发时自动更新测试、文档、安全扫描等任务实现真正的全程自动化。属性测试Property-Based Testing单元测试就像老师出了三道例题让你对答案只要这三道题对了就算通过而 PBT 你只需要告诉它一条规则它就会自动生成几百道随机题来反复验证这条规则有没有被打破。扩展阅读https://mp.weixin.qq.com/s/Yry4cRpEDv9uu786vC2I1Qhttps://mp.weixin.qq.com/s/hUc3HDAjXk96PzlOj7iKkgSDD 实践注重文档以前文档是给人看的为了让新同事上手。现在文档是给 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 结果。然后不断反复如有分歧继续对抗直到达成共识。
AI Coding 新范式与方法和工具（人人都是开发者）
目录文章目录目录Vibe Coding v.s. Spec CodingSpec Coding —— AI 编程新范式方法软件工程方法论SDD规格驱动开发模式SDD 核心原则SDD 三个层度TDD测试驱动开发模式STDD规格-测试驱动开发ODD (Observability-Driven可观测)工具Spec‑KitOpenSpecSpec-Kit v.s. OpenSpecSuperpowersSpec-Kit v.s. OpenSpec v.s. SuperpowersBMAD 多 Agent 虚拟团队AWS KiroSDD-Native IDESDD 实践注重文档团队开发闭环开发Closing the Loop原子化提交对抗验收交叉验证Vibe Coding v.s. Spec CodingVibe Coding氛围编程即仅凭借感觉和聊天驱动 AI 编程强调即时性和程序员的直觉。及时性立即就让 AI 写代码不需要任何前期准备。程序员的直觉通过经验转化的直觉来提需求让 AI 做事情。优点快及时实现你的需求不用多想全凭直觉缺点需求仅存在于聊天记录需求描述不规范、不清晰、不可追述需求质量全凭程序员经验高低。适用场景小需求、小修改例如让 AI 临时写个小脚本。统称为 AI 副驾copilot编程场景。Vibe Coding 的核心痛点需求一旦复杂单靠对话描述很容易产生理解偏差最后得到的代码和预期相差甚远甚至根本没法直接用。Spec Coding规格编程即先想好之后再让 AI 编程强调整体性、规划性和规范性。整体性从整个项目/系统的角度出发整体考虑 “人、事、物” 三个维度。规划性先写好你的需求描述文档并规划好要如何设计、实现、测试、交付你的需求。规范性所有人遵守同一套软件工程规范的约束使得项目需求可观测、可追溯、可解析、可控制、可移交。优点需求清晰合规、软件质量有保障。缺点前期规划需要投入较多的 “脑力” 和时间。适用场景AI 驱动的大型生产项目例如AI 连续编程 24 小时https://36kr.com/p/3560921828998273。统称为 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规格驱动开发模式SDDSpecification‑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 都能回溯到 PRDPRD 能回溯到最初的需求。没有这条可追溯的信息链就不是在做软件工程。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‑KitSpec‑Kit 是 GitHub 在 2025 年专为 SDD 设计的开发工具包用来帮你在各种 AI 编码环境中如 Copilot、Cursor 等按 SDD 的方式工作。它把 “写规格、做计划、拆任务、实现和审查” 这一整套流程固化成可复用的命令和模板。https://github.com/github/spec-kitSpec‑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-LsSfhttps://astral.sh/uv/install.sh|sh# 2. 安装 Specify CLI持久安装推荐uv toolinstallspecify-cli--fromgithttps://github.com/github/spec-kit.git# 3. 验证安装specify check项目初始化# 创建新项目specify init my-project--aiclaude# 在当前目录初始化specify init.--aiclaude# 或使用 --here 标志specify init--here--aiclaude# 强制初始化跳过确认specify init.--force--aiclaude初始化后的目录结构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# 技术研究│ ├──># 数据模型│ ├── 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 头脑风暴来进行补全。OpenSpecOpenSpec 是一个由 Fission‑AI 团队开源的轻量级 SDD 框架主打灵活的、可自定义的工作流对已有项目更友好流程极简定位比 Spec‑Kit 更轻但比 IDE如 Claude Code自带的简单 Plan Mode 更有结构。https://github.com/Fission-AI/OpenSpecOpenSpec 定义了一套面向 SSD 的 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 │ │ │ │ │ │ │ │ └───────────────┴───────────────┴──────────────┘ │ │ 创建工件 逐步实施 归档 │ └───────────────────────────────────────────────────────────────────┘安装# 方式一全局安装推荐npminstall-gfission-ai/openspeclatest# 方式二项目级安装npminstall--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-* # 自动生成的技能# 配置文件可选$vimopenspec/config.yaml# 默认工作流模式当前为 spec-drivenschema: spec-driven# 项目上下文会注入到所有工件context:|Tech stack: TypeScript, React, Node.js API conventions: RESTful, JSON responses Testing: Vitestforunit tests, Playwrightfore2e Style: ESLint with Prettier, strict TypeScript# 每个工件的具体规则rules: proposal: - Include rollback plan - Identify affected teams specs: - Use Given/When/Thenformatforscenarios design: - Include sequence diagramsforcomplex 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--changeadd-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. OpenSpecSpec‑Kit项目现状从 0 到 1 的项目。项目规模多人协作大型项目把 “宪法、规格、计划、任务” 一次性搭好团队即可围绕着这些文件进行讨论和迭代。成本投入大涵盖完整的软件工程流程每个需求走一个完整工作流程。质量控制高。OpenSpec项目现状适用于现有项目擅长在已有项目上做小步快跑。项目规模个人、小团队项目。成本投入每次改动都对应一个 Proposal轻松上手不必为一个小需求走一个完整的 Spec‑Kit 全流程。质量控制较低。SuperpowersSuperpowers 是由 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 个阶段每个阶段都有对应的技能头脑风暴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-developmentTDD 工作流测试驱动开发。硬性规定如果写了代码但没有先写测试删掉代码重新开始。verification-before-completion完成前验证每步都要验证writing-skills编写自定义技能。安装# Project 级别的安装而非全局# 1. 注册 Superpowers 市场/plugin marketplaceaddobra/superpowers-marketplace# 2. 安装 Superpowers 插件/plugininstallsuperpowerssuperpowers-marketplace# 重新进入 Claude Code# 验证安装/help# 看到 brainstorm、write-plan、execute-plan 这 3 个命令就说明安装成功。# 更新 Superpowerscd~/.claude/superpowersgitpull使用方式一 Cammands# 先搞明白要做什么/superpowers:brainstorm# 写个谁都能看懂的计划/superpowers:write-plan# 按计划一步步实现/superpowers:execute-plan使用方式二 Skills你不需要记住所有技能名称只需说出你的需求Superpowers 会自动选择合适的技能。Spec-Kit v.s. OpenSpec v.s. SuperpowersSpec-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.mdArchitect Agent负责技术方案输出 arch.mdDeveloper Agent负责编码实现输出 dev.mdQA Agent负责测试验证输出 qa.md业务分析师UX 专家Scrum Master敏捷教练BMAD 定义了一套 BMAD-METHODBreakthrough Method of Agile AI-Driven Development敏捷 AI 驱动开发的突破性方法是一套明确约束人和 AI 如何协作的开发方式。BMAD-METHOD 把整个开发过程稳定地拆成 4 个要素人负责设计、决策、兜底。AI负责执行。流程约束什么时候做什么事。工件把每一步结果落成可追溯的产出。让项目是被流程推动的而不是被对话推着走。并且在 BMAD 的设计里不要把 AI 当成 “万能助手”而是把 AI 当成多个有分工的角色。有的 AI 只负责分析需求有的只负责写计划和拆任务有的只负责实现和测试有的只做检查和验收在写任何代码之前先把谁负责什么、要交付什么说清楚。每个角色只在自己的阶段工作不跨界、不抢活。角色建模的目的在于将复杂问题拆分并分配到合适的职责单元。角色既可以由人类承担也可以由 AI 智能体承担但职责边界必须清晰。在 BMAD 中谁定义目标、谁产出补丁、谁负责审核与验收都需要在流程起点明确每一次改动都必须以工件形式落地而非停留在对话框中。BMAD 明确要求所有关键活动都要产出可持久化工件包括计划工件需求分析、范围说明、任务拆解CSV / 表格实现工件补丁Patch、接口契约、配置与脚手架验证工件测试用例、联调记录、性能与安全检查交付工件上线清单、回滚方案、监控与告警配置安装npx bmad-methodinstall指令/analyst# 分析需求/pm# 写 PRD/architect# 设计架构/sm# 拆用户故事/dev# 写代码 测试AWS KiroSDD-Native IDEAWS 于 2025 年 7 月推出的首款 SDD 原生 IDE由 Code OSSVS Code 同源分支构建将 SDD 流程嵌入到 IDE 的核心模块。核心特性Spec MVP在 Spec 创建阶段可以把测试等任务标记为可选项优先聚焦核心功能同时保留完整任务列表的可见性。Hooks 机制驱动的自动化比如在保存文件、提交代码等事件触发时自动更新测试、文档、安全扫描等任务实现真正的全程自动化。属性测试Property-Based Testing单元测试就像老师出了三道例题让你对答案只要这三道题对了就算通过而 PBT 你只需要告诉它一条规则它就会自动生成几百道随机题来反复验证这条规则有没有被打破。扩展阅读https://mp.weixin.qq.com/s/Yry4cRpEDv9uu786vC2I1Qhttps://mp.weixin.qq.com/s/hUc3HDAjXk96PzlOj7iKkgSDD 实践注重文档以前文档是给人看的为了让新同事上手。现在文档是给 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 结果。然后不断反复如有分歧继续对抗直到达成共识。
