AIGC标识 AI Native 流派汇总

AI 编码流程地图

调研摘要 · 2026-10 · Markdown 主文档

一句话结论：人负责要什么和验没验，agent 负责怎么做；规格与计划进仓库；可靠性来自确定性护栏，而不是模型自觉。

本版在原有内容基础上新增两章深入章节：SDD 深入用法（工具实操、渐进式采用、棕地打法、失败模式）与 AI-native SDLC 深入用法（六阶段循环、门禁设计、分级自治、验证体系、运维闭环）。

目录

  • 一、七个流派：一张地图
  • 二、SDD 深入用法
  • 三、AI-native SDLC 深入用法
  • 四、争议与边界
  • 五、共识与组合用法
  • 六、来源

一、七个流派：一张地图

SDD 只是“规格派”一家。按“流程重心”划分，2026 年被反复提及的做法有七个。它们不互斥，但发源的问题不同：有的解决意图说不清，有的解决验证跟不上，有的只是换个地方把执行外包出去。

quadrantChart title 流派定位：流程重量 × 自主程度 x-axis 轻流程 --> 重流程 y-axis 低自主 --> 高自主 quadrant-1 重流程 · 高自主 quadrant-2 轻流程 · 高自主 quadrant-3 轻流程 · 人主导 quadrant-4 重流程 · 人主导 循环派: [0.22, 0.90] 委派派: [0.58, 0.82] 组织派: [0.93, 0.68] 技能派: [0.45, 0.52] 规格派: [0.85, 0.42] 计划派: [0.20, 0.38] 人本派: [0.08, 0.25]

（若你的编辑器不渲染 Mermaid：横向为流程/文档的重量，左轻右重；纵向为 agent 的自主程度，下低上高。定位提炼自各流派公开论述，用于示意。）

流派 核心机制 代表 最适合 别用在
规格派 SDD spec/plan/tasks 作为长期资产 Spec Kit、Kiro、OpenSpec、Tessl 0→1 系统、复杂 feature、受监管、多 agent 契约 小改动、原型、需求高速变化、大型棕地
计划派 一次性计划，用完即弃 Claude Code 计划模式、Cursor Plan 几乎所有日常开发 几乎没有，代价最低
技能派 方法论写成按情境触发的技能包 Superpowers、Matt Pocock Skills 个人和小团队要工程纪律 一次性脚本、原型
循环派 Bash 循环 + 文件系统当记忆 Ralph Loop 机械任务：迁移、批量重构、刷测试 架构决策、安全代码、模糊需求
委派派 Issue 派给云端 agent，交回 PR Copilot coding agent、Codex/Claude 云会话 低中复杂度、测试良好的库 大型多文件重构、紧迭代
人本派 不靠流程，靠人的判断力 Vibe / Augmented Engineering 资深个人快速迭代 无经验团队
组织派 多角色 agent 敏捷团队 BMAD、AI-native SDLC 0→1 产品、要完整敏捷模拟的团队 小项目会被流程本体淹没

各流派的记忆点：

  • 规格派：Spec Kit 用 /speckit.converge 定期让代码和规格对账，等于承认漂移必然发生。
  • 计划派：改动超过 3 个文件、或不熟悉代码库，就先计划；一行修复则跳过。
  • 技能派 · Superpowers：元规则是“只要有 1% 可能适用某个技能，就必须调用”；连续 3 次修不好问题，强制触发架构层复盘。
  • 循环派：while :; do cat PROMPT.md | claude-code ; done——每轮全新上下文、每轮只做一件事、必须设迭代上限，成本约 $10/小时。
  • 委派派：执行被委派出去后，code review 成为交付瓶颈；团队要同步投资 review 容量与 CI 可靠性。
  • 人本派：Kent Beck 说“90% 的技能刚归零，10% 的涨了 1000 倍”；他还警告 AI 会偷偷删测试来让自己通过。
  • 组织派：BMad Loop 可无人值守跑迭代，遇到做不了的决策就停下来通知人。

技能派的两副面孔

这一格现在有两个流行代表，取向正好相反：

维度 Superpowers Matt Pocock Skills
形态 一套完整方法论做成技能包 一个工具箱，按四类失败模式组织
流程感 七步闭环加“1% 元规则”，带着你走 不接管工作流，自己组合
对齐方式 头脑风暴产出经验证的 spec /grill-me 逐题审问，对齐优先于规格

Matt Pocock（Total TypeScript 作者）的完整管道是 Grill → Spec → Tickets → Implement → Review，形似 SDD，但有一个关键分歧：对齐是目的，PRD 是副产品。他认为计划文档是劣质的对齐代理——读者分不清“我们达成一致”和“LLM 总结得像个样子”；grilling 胜过 plan mode 和规格文档，他甚至不看自己生成的 PRD。技能按四类翻车模式组织：不听指令、话太多、代码跑不通、代码变泥球；哲学上是“人本派”的近亲——DDD、ADR、术语表、深模块、严格 TDD（红-绿-重构、垂直切片），并按“smart zone”（约 10 万 token）管理上下文。2026 年 4 月开源，现为该流派最流行的代表之一；社区有中文翻译版。

二、SDD 深入用法

2.1 核心循环（以 Spec Kit 为参照）

flowchart LR A[constitution 项目宪法] --> B[specify 规格] B --> C[clarify 澄清] C --> D[plan 技术方案] D --> E[tasks 任务清单] E --> F[implement 实现] F --> G{converge 对账} G -- 有缺口，追加任务 --> E G -- 收敛 --> H[完成]

七个命令做三件事：定原则（constitution，一次）、定义意图（specify / clarify）、翻译成执行（plan / tasks / implement），最后 converge 对账——对照规格检查代码，有缺口就追加任务重跑，直到收敛。此外还有两个可选质量门：/speckit.checklist 为需求生成定制检查清单（本质是“给需求写的单元测试”），/speckit.analyze 对 spec、plan、tasks 三份产物做只读的一致性检查。

2.2 产物长什么样

以 feature 为单位编号存放，规格与代码同仓：

specs/001-feature-invite/
├── spec.md          # 做什么：用户旅程、验收标准，模糊处标 [NEEDS CLARIFICATION]
├── plan.md          # 怎么做：技术选型、架构、约束
├── tasks.md         # 原子任务清单，[P] 标记可并行项
├── data-model.md    # 数据模型（plan 阶段产出）
├── contracts/       # 接口契约（plan 阶段产出）
├── research.md      # 技术调研记录
└── quickstart.md    # 验证场景

两条硬规则让这些文件不沦为摆设：

  1. 产物进仓库、进 PR。review 从“挑代码毛病”变成“确认意图正确”——这是 SDD 派认为最值钱的变化。
  2. 任务粒度的判据是可测试。“创建注册接口并校验邮箱格式”合格；“实现认证”不合格。

2.3 四大工具实操对照

Spec Kit（标准派，重流程）

完整七步 + 质量门；项目宪法自动注入每个命令；支持 38 个 AI agent 集成、150+ 社区扩展与预设，含治理检查与 token/成本跟踪。适合：新项目、大团队、需要把合规编码进流程的场景。代价：上下文税（斜杠命令、模板、宪法都吃上下文），棕地改造不友好。

Kiro（IDE 集成派）

用 EARS 语法写需求（源自 Rolls-Royce，专治“含糊措辞”和“缺触发条件”），五种句式：

句式 模板 用途
通用 The system SHALL [行为] 永远成立的需求
事件驱动 WHEN [触发] THE SYSTEM SHALL [行为] 对事件响应
状态驱动 WHILE [状态] THE SYSTEM SHALL [行为] 持续状态下的行为
可选特性 WHERE [特性启用] THE SYSTEM SHALL [行为] 条件化行为
异常处理 IF [触发] THEN THE SYSTEM SHALL [行为] 错误与例外

一个真实例子（团队邀请功能）：

THE SYSTEM SHALL restrict invite creation to users with the `admin` role.
WHEN an admin submits an invite form with a valid email THE SYSTEM SHALL
  create an invite record and send an email containing a signed link.
IF the email already belongs to a workspace member THEN THE SYSTEM SHALL
  return "User already in workspace" without creating an invite.
WHILE an invite is unaccepted and within 7 days of creation THE SYSTEM
  SHALL allow the invitee to complete signup and join the workspace.

修复类需求用变体句式 WHEN [条件] THEN the system SHALL CONTINUE TO [既有行为]，语义是回归保护。每行 EARS 直接对应一个测试的前置条件和断言；官方建议一轮迭代控制在 10–15 条需求。另外两个关键机制：steering 文件（.kiro/steering/，默认 product.md / tech.md / structure.md，按包含模式自动注入每次推理，解决“开会话就失忆”）；hooks（事件驱动：onSave 跑安全扫描、onCommit 自动更新设计图、任务完成后自动跑单测并自纠）。Kiro 还分 Spec session 和 Vibe session 两档，并且官方明确列了跳过条件：改错字、清 lint、单文件重构、纯文档、已知修复的热修——都不值得走规格流程。

OpenSpec（轻量派）

流程：openspec init → /opsx:explore（先让 AI 读你要动的代码）→ /opsx:propose <一个小而真实的变更> → /opsx:apply → /opsx:archive。

核心是 delta spec：新增功能不重写整个产品规格，只写“本次变更增加/修改/删除了什么”：

## ADDED Requirements
## MODIFIED Requirements      # 每条附 (Previously: ...)
## REMOVED Requirements       # 每条附 (Deprecated: ...)

两条实战经验：MODIFIED 要原地修改现有代码（最常见错误是当成 ADDED 新建文件）；REMOVED 必须连带删净代码和测试。还有 50KB 上下文硬上限，防止规格本身把上下文吃光。Thoughtworks 技术雷达收录，定位是“想要结构但不要重流程”的团队。

Tessl（激进派，spec-as-source）

规格是唯一的手工编辑对象，代码是生成物：

每个需求有稳定 ID（如 REQ-AUTH-001）和至少一个 [@test]
spec 的 targets 字段声明它拥有哪些文件
改动 target 文件必须在同一提交里改其所属 spec
生成文件头部带 // GENERATED FROM SPEC - DO NOT EDIT
CI 检查 spec、targets、测试三者不允许分叉

tessl document 还能从既有代码反向生成规格（棕地入场用）。注意：Fowler 团队实测发现同一规格重复生成，代码依然不同（LLM 非确定性），它承受的是“模型驱动开发的不灵活 + LLM 的不确定”双重风险，尚未被验证。

2.4 渐进式采用：从一次小改动开始

不要一步跳进重流程。社区共识的渐进路径（OpenSpec 是典型载体）：

explore（可选）→ propose → 人工审查门禁 → apply → review → test → verify → archive

propose 阶段产出四件套：proposal.md（为什么做、做什么）、specs/（delta，用 GIVEN/WHEN/THEN 或 SHALL/MUST 描述可测试行为）、design.md（文件结构、测试策略）、tasks.md（原子任务）。三条被反复强调的执行纪律：

  1. AI 必须先调研现有代码（带出处），不允许凭空设计；
  2. 澄清问题一次只问一个（不是一次甩 10 个），未澄清项清零前不进入编码；
  3. 审查重点排序：tasks.md 最关键——每个任务应恰好包含一个 TDD 阶段、RED/GREEN 严格交替；发现“RED+GREEN 合并成一个任务”要手动拆开。

成熟度三级当作光谱用，不必选边：spec-first（设计文档，写完即漂移）→ spec-anchored（持续维护，忙起来就漂移）→ spec-as-source（改代码前必须先改规格，漂移在结构上不可能）。

2.5 棕地怎么打

前提认知：只写增量，不写全量。给 8 万行的存量系统补全套规格是“大前置文档”，和“大前置设计”一样注定失败。规格随一次次变更累积，某个领域改过几次之后，它的规格自然变详细。

两种流派，按团队情况选：

  • 纯 delta 派（OpenSpec 式）：不建基线，从“一个你本来就要做的小改动”开始跑 propose → apply → archive，规格被动生长。
  • 基线派（重一点）：先用只读的发现阶段反向生成现状文档（代码地图、as-is 规格、架构与 ADR 基线），再进入常规开发。适合需要交接、审计的团队。

棕地的安全网是特征测试（characterization test）：先写一批“捕获当前行为、立即通过”的测试，作为改造前的回归网。归档是收尾的负载性动作：delta 合并回事实源（openspec/specs/），变更文件夹移入带日期的 archive——一次变更只有归档了才算完成。三条义务守住这个体系：归档每次变更；审查每个生成产物（AI 起草，人拥有意图）；没有 GIVEN/WHEN/THEN 场景的需求不允许提出——场景名字直接用作测试名，保证可追溯。

2.6 团队协作与多 agent

  • 对齐发生在规格层，而不是代码写完之后。审查门禁放在 propose 之后：先审 proposal 的行为列表与边界情况，再审 design 的结构与测试策略，最后逐条审 tasks。
  • 规格是 agent 之间的契约。一个流行的组合是 OpenSpec + Superpowers：“一个管写什么，一个管怎么做”——OpenSpec 管意图与变更，Superpowers 管 TDD、调试、审查的工程纪律，串成 6 步的规格驱动 TDD 闭环。
  • 两阶段审查：每个任务完成后，先查“是否符合规格”，再查“代码质量”；通过才勾选任务进入下一个。一个实测案例：12 个原子 TDD 任务（6 组 RED+GREEN）触发了 34 次子代理调用。
  • 中断可恢复：流程被 IDE 崩溃或 token 限制打断后，重跑会检查已有产出并从断点续跑，进度报告附 TODO 清单（位置、说明、优先级）。

2.7 自动化档位：人当检查点，还是全自动

同一条流程有两个档位，按风险选：

  • 每个产物之间设人工检查点：人审完 proposal 才进 design，审完 design 才进 apply——最稳，适合高风险模块。
  • spec 写完就走开：apply 后自动实现、测试、多层验证，最后产出 review 报告供人阅读——最快，适合信任度高的常规变更。

2.8 常见失败模式与规避

失败模式 表现 规避
GIGO 规格模糊，越往下游越离谱 clarify 流程 + [NEEDS CLARIFICATION] 标记清零后才放行
Markdown 官僚化 一个日期功能产出 1300 行文档 跳过条件清单 + 轻量工具（OpenSpec）+ 按模块混用轻重
宪法锁死局部最优 随手定的约束硬化成铁律，否决更好的架构 把“做出否决的是宪法”当信号，定期修订 constitution
双份 review 规格里的代码示例和实现都要审 spec review 聚焦意图，code review 聚焦实现；用 analyze 做一致性自动检查
漂移 代码变了规格没变 converge 对账 / archive 义务；要结构性解决只能上 spec-as-source
退化成任务脚本 规格实为“需求→计划→任务”的详细任务书，需求一变全崩 保持意图层（是什么、为什么），技术细节留在 plan 层

2.9 什么时候跳过 SDD

改错字、清 lint、单文件重构、纯文档改动、已知修复的热修、探索性原型、一次性脚本、纯算法调优——都不值得走规格流程。工具官方自己也这么说（Kiro 的跳过清单是最明确的）。

三、AI-native SDLC 深入用法

SDD 管的是“Plan/Design 阶段怎么把意图说清楚”，但一只脚还留在 Build。把镜头拉到整个软件生命周期，Anthropic 的 AI-native SDLC playbook（2026-08）给出了目前最完整的一张蓝图：当 agent 写掉大部分代码之后，生命周期该怎么设计。

3.1 六阶段循环：每个阶段结一个产物

flowchart LR P[Plan<br/>intent.md] --> D[Design<br/>spec.md · plan.md] D --> B[Build<br/>diff + 它的测试] B --> T[Test<br/>验证与 evals] T --> R[Deploy<br/>PR + 审查结论] R --> M[Maintain<br/>incident record] M -- 诊断写成新的 intent.md --> P

变化的原因：agent 把 Build 从数周压缩到数小时，而计划、评审、部署这些周边阶段还是人的速度——瓶颈整体移到了 plan / review / deploy。同时，逐行人审“agent 写了 90%”的 diff 已经不可行。于是流程设计的重心从“怎么写代码”变成“在哪设门”。

3.2 门禁设计：hook 管确定性，人管部署

这是整个 playbook 里最可迁移的一条设计：

  • skills 是概率性的，hooks 是确定性的。“skill 让违规变稀有，hook 让它近乎不可能”——任何必须每次都成立的政策，背后必须站一个 hook 或 PR 重检，而不是一条写在文档里的规矩。
  • Build 阶段只放快速 allow/block 检查：受保护路径、格式化/lint、凭据泄漏——它们几乎在每次编辑上触发，必须快。不要把人工审批放进 Build：并行会话下，一个 ask 会同时卡住所有会话，把人重新塞回关键路径，恰好抵消了并行省出来的时间。
  • 人工审批门放在 Deploy：动作稀少、后果重大（发布、变更单、迁移、基础设施）。Commit/PR 阶段则可以承载较重的确定性检查。
  • hook 被拦下时必须解释自己，并给出申诉路径——拒绝要可对话，否则团队会绕过整个机制。

3.3 分级自治：每个环境一套权限

原则一句话：agent 可以行动到生产门之前，但过不去。

  • 分支保护：agent 写的一切都只能成为 PR，没有直通 main 的路。
  • 按环境分级：开发环境 agent 自由部署；staging 居中；生产环境 agent 只负责准备发布，由具名 release manager 授权后才放行（由 hook 强制执行）。
  • 沙箱执行：网络策略 + 短时 scoped token，默认不持有生产凭据。
  • 部署经 MCP 暴露：deploy / status / rollback 作为环境域内的工具（白名单），而不是把带凭据的 shell 脚本交给 agent。
  • 回滚是最常演练的路径：一条命令，在 staging 反复练过，由 Maintain 阶段在控制带被击穿时调用。
  • hook 分层：团队约定放 .claude/settings.json，不可协商的放 managed settings（如 allowManagedHooksOnly）。

3.4 验证体系：三条独立回路

  1. 即时反馈循环：测试、构建、截图对比，agent 干活期间持续跑。
  2. verifier 子代理：干净上下文，只在最后跑一次，只报告、绝不修改——写代码的 agent 无权批准自己的产出，审查结论也不自动批准或阻塞，最终合并权在人。
  3. 持续 evals：20–50 个真实任务作为回归集，agent 配置或模型一变就重跑——这是“换模型/改提示词”之后唯一能证明没有变坏的手段。

Bug 修复另有一条硬保护：agent 先写失败测试 → 确认失败原因正确 → 提交测试 → 修代码且不许改测试；用 PreToolUse hook 在修复任务期间拒绝对 tests/** 的写入。这样“修好”的定义不可能被偷偷放宽。

3.5 运维闭环：Maintain 阶段怎么回到 Plan

  • 检测必须确定性：一个版本化、有单测的脚本，对稳定指标（CI 失败率、部署后 5xx、PR 周期时间）做滚动均值与标准差，套 Western Electric 规则——决定“出没出问题”的环节不引入模型。
  • 响应按带分级（配置在 bands.yaml）：1σ 只记录；2σ 唤起 Claude 做只读诊断；3σ Claude 可以行动，但只能开 PR 进审查门，或触发预批 runbook。
  • 闭环是怎么合上的：agent 把诊断写成一个新的 intent.md，从 Plan 阶段重新进入流水线——生命周期因此是环，不是线。处置决定反哺 band 阈值；每次事故修复都补一条 eval；扫描必须常驻（覆盖率会随代码和模型变化衰减）。

3.6 落地顺序

  1. 分支保护 + “一切产出皆 PR”；
  2. 格式化/lint 等快速 hooks 进 Build；
  3. 测试目录写保护 + verifier 子代理；
  4. 部署门 + 在 staging 演练过的回滚；
  5. 真实任务集 evals 常驻；
  6. 运维 bands 闭环。

playbook 的原话：门禁先于 CI/CD 自动化——PR 审查和 hooks-as-gates 是前置条件，闭环还额外要求一条演练过的回滚路径。

3.7 与 SDD 的关系

两者拼起来才是完整图景：SDD 是 SDLC 在 Plan/Design 阶段的深化——intent.md / spec.md 正是这条流水线的输入；而 Deploy 门、验证回路、运维闭环这些 SDD 不管的部分，由 SDLC 蓝图补上。选型时不必对立：轻量 SDD 提供“说清楚”，AI-native SDLC 提供“管到底”。

3.8 已知的不足（诚实清单）

  • playbook 本身是厂商视角（大量引用 Anthropic 自家产品），偏规定性、没有结果数据；
  • 它的生产门示例是一个对 “deploy”/“production” 的朴素子串匹配——作为控制手段偏弱，MCP 工具或别名可绕过；
  • mabl 指出的验证缺口：从需求（intent.md/spec.md）到持久的、业务方拥有的测试覆盖没有路径；“只修代码不改测试”也没解释需求有意变更、或执行方式变化（比如按钮挪了位置）时怎么办。

它是蓝图，不是已被验证的标准——用它的时候，把上面三条当作要自己补的作业。

四、争议与边界

SDD 的反对意见来自严肃的工程博客，值得逐条摆出来：

  • 瀑布回魂。Marmelab 的批评文章标题就叫「瀑布反击」（The Waterfall Strikes Back）；Scott Logic 实测 Spec Kit 后说它“把你一路拖回过去”。
  • Markdown 官僚化。实测记录：一个“显示当前日期”的功能产出 8 个文件、1300 行文本；“创建用户资料”膨胀到 19 条验收标准、1070 行。
  • 生产力反证。Scott Logic 报告不用 SDD 反而快约 10 倍，“大量时间在审 Markdown，没有值得付出这笔开销的定性收益”。
  • 双份 review 与虚假安全感。规格里含代码示例，规格代码和最终实现都要审；有 agent 把“验证实现”标记完成，却一个测试都没写。
  • 宪法锁死局部最优。随笔写下的 5 分钟性能预算硬化成铁律，否决了更好的架构：“做出否决的是宪法，agent 只是话筒。”
  • 隐性知识写不进规格。老手看代码的直觉，像开车时预判前车刹车灯，没法前置成文本。Jeff Patton：“story 不是文档，是对话的令牌。”
  • 棕地基本不适用（传统做法）。重流程工具对大存量代码库不友好；对照实验里，普通 prompt 反而赢了。注意 2.5 的 delta 打法正是对此的修正，但那是另一套更轻的用法。

边界结论：重 SDD 的最优坐标是 0→1 系统、基础设施、跨团队大 feature、错误成本极高的模块（账本、共识算法、安全）。它的核心价值是可控性与可审计性，不是效率。成熟团队按模块混用轻重模式。

五、共识与组合用法

剥掉工具名字，2026 年的共识其实是传统软件工程加上七条新纪律：

  1. 人负责规划与验收，agent 负责执行。
  2. 规格、计划、任务清单是版本化的一等公民，进仓库、进 PR。
  3. 可靠性来自确定性护栏：测试、hooks、CI、沙箱，而不是提示词技巧。
  4. 任务粒度：一个明确结果、一个有界实现区域、一个可测试的成功条件。
  5. 小步、原子提交，随时可回滚。
  6. 上下文保持精简，大功能切换到新会话。
  7. SOLID、TDD、先设计后实现都还成立，只是执行者换了。

落到真实团队，是组合用法：

场景 做法
日常开发 计划派：改动超过 3 个文件，先出计划再动手
机械任务 循环派：迁移、批量重构、刷测试，带上迭代上限
常规 issue 委派派：派给异步 agent，人守住 PR 审查
高风险模块 TDD + hooks + 人工逐行 + 第二个模型 red-team
存量代码库改造 轻量 SDD：OpenSpec 的 delta 模式，只描述增量
0→1 新产品 重 SDD：Spec Kit 或 BMAD 全流程
全流程门禁 hooks 管确定性检查，人工审批只在 Deploy 门

六、来源

SDD 工具与文档

AI-native SDLC

批评与反方

其他流派与共识

整理自 2026 年 10 月的调研讨论，观点归属各自来源。工具与数据均在快速变化，引用前建议核对原始链接。同目录有排版阅读版：ai-coding-workflows-2026.html。

posted @ 2026-10-14 23:16  痴人指路  阅读(7)  评论(0)    收藏  举报