AI 原生 SDLC 全链路：从 Claude、Spotify 到真正可落地的团队工程系统
AI 进入软件研发以后，最容易犯的错误，是在原有 SDLC 的“编码”节点旁边放一个聊天机器人，然后宣布团队已经完成 AI 转型。
真正的变化更深：代码生成不再是主要稀缺资源，问题选择、上下文、验证、风险判断、发布反馈和人类注意力才是。团队如果只提高生成速度，结果通常不是更快交付，而是更多 PR、更长评审队列、更高变更风险和更快积累的技术债。
因此，AI 原生 SDLC 不是“AI 帮人写代码”，而是一套新的工程操作系统：
人类定义结果、边界和风险；Agent 在隔离环境中执行；确定性系统与独立评审生成证据；发布系统控制影响面；生产反馈再写回任务、规则、测试和组织知识。
本文基于截至 2026 年 8 月 30 日可获得的一手资料，重点参考：
- Claude Code 团队的 JIT 规划、Dogfood、专家评审和扁平 Pod；
- Anthropic Security 对 Plan、Code、Test、Deploy、Monitor、Governance 的 AI 原生安全改造；
- Spotify 的 Backstage、Golden State、Fleet Management、Honk、Verifier 与 LLM Judge；
- OpenAI 的 Harness Engineering、仓库内知识、隔离环境、Agent 可观测性与任务编排；
- DORA 2025 对平台工程、交付吞吐、稳定性和信任的研究。
文章会给出完整链路、最细阶段流程、可复制模板、风险路由、工具地图、指标体系与 90 天建设计划。
一、先说结论：AI-SDLC 管理的不是代码，而是“带证据的变更”
传统 SDLC 常把代码视为主要产物：需求进入，工程师实现，测试验证，发布上线。
AI 原生 SDLC 的最小可信产物应该升级为：
一个可追溯的用户问题
+ 明确的结果与非目标
+ 可执行的验收标准与系统不变量
+ 受控环境中的实现
+ 机器可验证的证据
+ 风险匹配的审批
+ 可回滚的发布记录
+ 生产结果与后续学习
也就是说，团队不应问“Agent 写了多少代码”，而应问：
- 这个变更解决了什么问题？
- Agent 被允许看什么、做什么？
- 哪些证据证明它满足目标且没有越界？
- 谁对合并和发布负责？
- 出错时能否快速止损、追溯和回滚？
- 这次成功或失败是否改善了下一次执行环境？
这是本文所有流程设计的起点。
二、前沿团队真正证明了什么
不同团队的工具和规模不同，但它们正在收敛到同一组工程原则。
1. Claude Code 团队：瓶颈从实现迁到验证与判断
Claude Code 与 Claude Cowork 工程负责人 Fiona Fung 在 Running an AI-native engineering org 中给出的信号很直接：写代码、写测试和重构很少再拖慢团队，验证、代码评审和安全成为新的约束。
他们的组织变化包括：
- 六个月路线图转向 Just-in-Time 规划；
- 先做原型，让内部用户真实使用，再依据反馈推进；
- Claude 处理样式、Lint、常见缺陷、测试和 PR 反馈；
- 法务、安全边界、系统演进和产品品味仍由专家判断；
- PM、设计、工程角色变宽，但最终责任没有消失；
- 小 Pod 自主选择工作方式，核心原则保持统一；
- 明确允许团队删除已经失去作用的流程。
这说明 AI-SDLC 的核心不是“取消流程”，而是删除针对旧瓶颈的流程，把门禁移动到新瓶颈。
2. Anthropic Security：安全要监控 Agent Loop，而不只是扫描代码
How Anthropic secures its AI-native software development lifecycle 把 Plan、Code、Test、Deploy、Monitor 和 Governance 串成了完整安全链。
其中最值得普通团队借鉴的不是某个内部工具，而是以下控制思想：
- 规划阶段的安全 Agent 必须连接组织政策、历史评审和相关系统上下文；
- 安全规范进入
CLAUDE.md、Skills、Hooks 与生成闭环，而不只存在于手册； - Agent 在远程 VM 或等价隔离环境中运行，网络出口白名单化；
- CI 同时使用确定性扫描、多个窄职责 Agent 和风险加权的人类复核；
- 动态安全测试的频率要跟上部署频率；
- 事故分析 Agent 可以读日志、写文档和提出修复，但不能自己部署；
- 每个 Agent 使用单一用途身份和最小权限；
- 新评审 Agent 先跑 Shadow Mode，可信后再扩大权限；
- Agent 的批准、工具调用和 Agent 间通信都要进入审计系统。
最重要的一句话可以归纳为：安全工程师从监控 Bug，转向监控自动化闭环是否仍然可靠。
3. Spotify：模型能力只有接入工程底座才会规模化
Spotify 在 Coding Is No Longer the Constraint 中披露，超过 99% 的工程师每周使用 AI 编码工具，94% 的工程师认为生产力得到提升，PR 频率增加 76%。与此同时，76% 更多 PR 也意味着更大的评审压力。
Spotify 能把背景编码 Agent 推向规模化，依赖的是多年积累的工程基础：
- Backstage 软件目录提供组件、Owner、文档和工具入口；
- Golden State 定义推荐技术和工程实践；
- Soundcheck 把标准变成可度量的组件健康规则；
- Fleet Management 负责目标识别、调度、进度和批量变更；
- Honk 在 Kubernetes 隔离环境中执行代码修改；
- MCP 与 CLI 为 Agent 暴露稳定工具接口；
- Verifier 封装构建、测试和格式化，不让 Agent 消耗上下文处理噪声；
- LLM Judge 比较原始任务与 Diff，识别越界重构或禁用测试等行为。
Spotify 在 Predictable Results Through Strong Feedback Loops 中明确区分三类失败：没有 PR、PR 过不了 CI、PR 通过 CI 但功能错误。第三类最危险，因为它会侵蚀团队对自动化的信任。
Spotify 的答案不是更长的 Prompt，而是：标准化、隔离、快速 Verifier、独立 Judge、有限权限和失败闭环。
4. OpenAI：环境不完整时，“再试一次”不是工程方案
OpenAI 在 Harness engineering: leveraging Codex in an agent-first world 中描述了一个由 Agent 生成全部代码的内部产品实验。早期速度不及预期，并不是 Agent 不会写，而是环境缺少工具、抽象、结构和可执行知识。
团队随后把工作重心转向：
- 让仓库成为代码、架构、计划、决策和技术债的系统记录；
- 用小入口和索引实现 Progressive Disclosure，而不是一个巨型指令文件；
- 用 Lint 和结构测试强制架构不变量；
- 每个 Worktree 启动独立应用、日志、指标和 Trace；
- 让 Agent 能操作 UI、读取观测数据、复现 Bug 和验证性能目标；
- 把 Agent 失败视为环境缺失信号，并补充工具、规则、文档或测试。
Symphony 又进一步把问题从“人管理多个 Agent Session”提升为“工单系统管理交付状态”：任务成为控制面，依赖成为 DAG，Agent 只领取未阻塞任务，人类关注结果而不是逐个盯 Session。
5. DORA：AI 是放大器，不是修复器
2025 DORA Report 基于近 5,000 名技术从业者的调查和超过 100 小时的定性资料，给出的结论是：AI 会放大既有团队和系统的特征。
- 90% 的受访者在工作中使用 AI；
- 超过 80% 认为生产力得到提升；
- 30% 对 AI 生成代码仍然很少或完全不信任；
- AI 采用与交付吞吐、产品表现呈正向关系；
- 但与交付稳定性仍呈负向关系；
- 高质量内部平台、清晰工作流、自动化测试和快速反馈是关键放大器。
这也提醒我们：上述公司数据是特定组织中的经验指标，不能直接当作你团队的产能承诺。真正应该迁移的是控制机制，不是宣传数字。
三、AI 原生 SDLC 的全链路
整条链路可以压缩成八个阶段和四个显式门禁：
| 阶段 | 核心问题 | 必须形成的证据 |
|---|---|---|
| 机会 | 是否存在值得解决的问题 | 用户、业务或运行信号 |
| 假设 | 什么变化可能改善结果 | 可证伪假设与成功指标 |
| 原型 | 最低成本怎样获得学习 | Dogfood、可用性或技术证据 |
| 任务 | Agent 到底要做什么 | 任务合同、风险级别、验收标准 |
| 实现 | 如何在边界内产生变更 | 隔离执行记录与最小 Diff |
| 验证 | 为什么相信变更 | 测试、安全、行为和范围证据 |
| 发布 | 怎样限制影响面 | 灰度、回滚、Owner 与审批 |
| 运行 | 结果是否真实成立 | SLO、用户行为、事故和成本信号 |
四道门不是审批表单，而是明确的停止条件：
- 价值门：没有问题证据、Owner 或成功指标，不进入实现；
- 方案门：没有边界、不变量、风险等级和退出路径，不交给 Agent；
- 合并门：没有完整证据包或存在未解释风险，不合并；
- 发布门：没有可观测性、灰度和回滚能力，不扩大流量。
生产并不是终点。运行数据必须回流为：
- 新的用户证据；
- 新的回归测试与不变量；
- 新的 Agent 规则或 Skill；
- 新的架构决策与技术债；
- 新的优先级或终止决策。
四、最细流程：从一个信号到一次可学习的生产变更
下面把一条真实团队链路拆成 14 个阶段。每个阶段都包含入口、动作、产物、Owner 和退出条件。
阶段 0：建立基线与授权边界
这一步发生在任何 Agent 自动执行之前。
入口：团队计划把 AI 从个人补全工具升级为可修改仓库、运行命令或创建 PR 的 Agent。
细分动作：
- 记录当前 Lead Time、PR 等待时间、构建耗时、变更失败率、MTTR 和 Review Toil；
- 盘点代码托管、工单、CI、Secrets、生产日志和内部文档中的数据分类；
- 定义允许和禁止输入模型的内容；
- 列出 Agent 可使用的工具和最小权限；
- 定义 R0–R3 风险级别；
- 指定安全、平台、产品、工程和 SRE Owner；
- 定义日志保留、审计、成本和供应商策略；
- 选择低风险、重复、验收清晰的首个试点；
- 为试点设置停止条件，例如逃逸缺陷、成本超标或人工返工上升；
- 所有新 Agent 默认进入 Shadow Mode 或只读模式。
产物：AI 使用政策、工具白名单、风险矩阵、基线看板、试点清单。
Owner：工程负责人最终负责；Security、Platform、Legal/Compliance 共同定义边界。
退出条件：团队能够回答“哪个 Agent 以什么身份，在什么环境，对哪些仓库和数据执行哪些动作”。
阶段 1：机会采集，不从 Prompt 开始
AI 很容易让团队过早进入方案。正确入口应该是一个可追溯信号。
信号来源：
- 客户访谈、支持工单、流失原因；
- 产品漏斗、A/B 实验、用户行为；
- SLO、告警、事故和性能回归；
- 依赖升级、安全漏洞和合规要求；
- 工程师的维护痛点、重复操作和迁移需求。
细分动作：
- AI 聚类和去重原始信号，但保留原始链接；
- 提取受影响用户、频率、严重性和时间范围；
- 将“用户说什么”与“团队推断什么”分栏；
- 搜索历史工单、事故、实验和相似实现；
- 标记证据冲突和数据缺口；
- 由 Product Owner 决定是否进入假设阶段。
产物：Problem Brief，至少包含证据、用户、影响、Owner、未知项。
退出条件：没有可追溯证据的想法只进入探索池，不进入交付队列。
阶段 2：把需求写成可证伪假设
需求不能只写“增加一个功能”，而要说明希望改变什么结果。
细分动作：
- 写出目标用户和当前行为；
- 写出期望行为变化；
- 选择一个主指标和必要护栏指标；
- 记录最危险的产品、技术和安全假设；
- 定义最小证据：原型反馈、离线分析、技术 Spike 或线上实验；
- 明确 Kill Criteria：什么结果出现时停止；
- AI 生成反例和失败场景；
- 人类 Owner 决定是否值得消耗验证和维护能力。
推荐格式：
我们观察到：<证据>
对于：<目标用户/系统>
如果：<最小变化>
那么：<主指标> 将在 <时间窗口> 内发生 <预期变化>
同时不能损害：<护栏指标/系统不变量>
若出现：<终止条件>，则停止或回退
产物：Outcome Hypothesis、主指标、护栏指标、Kill Criteria。
退出条件：无法被证伪的“需求”不得直接进入生产实现。
阶段 3：原型、Dogfood 与最低成本学习
Claude Code 团队的 JIT 规划值得借鉴，但 JIT 不是不规划，而是延迟不可逆承诺。
细分动作：
- 选择学习方式：交互原型、假门、离线脚本、数据回放、技术 Spike；
- Agent 生成多个小方案，而不是一个完整大实现；
- Product/Design 选择差异最大的 2–3 个方案；
- 在合成数据、内部环境或受控用户组中运行；
- 记录行为数据和定性反馈；
- 区分“原型代码”与“生产资产”；
- 明确删除、重写或产品化；
- 将学习写回假设，不因已经生成代码而继续投入。
产物：原型、Dogfood 反馈、保留/调整/终止决策。
退出条件：只有当证据支持继续，才投入生产级可靠性成本。
阶段 4：风险分级与轻量方案评审
每次变更在设计任务前先分级，级别决定 Agent 权限、证据深度和人工门禁。
需要评估：
- 是否涉及身份、权限、支付、隐私或合规数据；
- 是否跨服务、跨团队或跨区域；
- 是否有数据库 Schema、不可逆迁移或大规模回填；
- 是否影响核心 SLO、供应链或基础设施；
- 是否容易观测和回滚；
- 测试覆盖与组件健康度是否足够；
- Agent 将读取哪些不可信输入；
- 失败的爆炸半径有多大。
产物：风险级别、Threat Model、架构草图、数据流、回滚设计、所需专家列表。
退出条件：风险没有 Owner、回滚不可行或关键上下文缺失时，不进入自动实现。
阶段 5：把工作“编译”为任务合同
自然语言 Prompt 太容易丢失边界。团队应把任务写成结构化、可执行、可审计的合同。
id: ENG-2048
outcome: 用户可以在 2 秒内完成座位选择
problem_evidence:
- support://ticket-group/seat-timeout
- dashboard://checkout/seat-selection
scope:
include:
- web/seat-map
- api/reservation
exclude:
- pricing
- payment
acceptance:
- p95 interaction latency < 2s in staging scenario seat-map-large
- existing accessibility keyboard flow still passes
invariants:
- one seat cannot be held by two users
- user A can never read user B's reservation
risk_tier: R2
data_classification: internal-test-data-only
allowed_tools:
- repository_read_write
- test_runner
- browser_staging
- observability_staging_readonly
forbidden_actions:
- production_deploy
- dependency_major_upgrade
validation:
- typecheck
- unit
- contract
- playwright
- sast
- performance_scenario
rollout: internal -> 5% -> 25% -> 100%
rollback: disable flag seat-map-v2
owners:
product: alice
engineering: bob
security: sec-oncall
stop_conditions:
- scope change required
- invariant cannot be tested
- p95 regression > 10%
任务合同必须包含：目标、证据、范围、非目标、验收、不变量、风险、数据、工具、验证、灰度、回滚、Owner、停止条件。
退出条件：一个不了解口头讨论的工程师或 Agent，仅凭合同和仓库入口就能解释任务目标与边界。
阶段 6：上下文装配，而不是把所有资料塞进窗口
上下文应该按 Progressive Disclosure 组织。
第 1 层：稳定入口
- 仓库用途、目录地图、构建与测试入口；
AGENTS.md、CLAUDE.md或等价项目约定；- 安全、架构、代码风格和提交规则；
- Ownership 与升级路径。
第 2 层：任务相关上下文
- 相关模块、接口、Schema 和测试；
- 关联 ADR、历史 PR、事故和监控面板；
- 组件健康度、Golden Path 与允许依赖。
第 3 层：按需工具
- 通过 MCP、CLI 或 API 查询工单、CI、目录、日志和指标；
- 返回结构化摘要与深链接，避免复制整段噪声；
- 工具输出明确数据新鲜度、来源和权限。
细分动作：
- 根据任务合同解析受影响组件；
- 从软件目录获取 Owner、依赖、运行环境和文档；
- 选择相关规则与 Skills；
- 注入历史事故、不变量和已知陷阱；
- 验证链接与文档是否过期；
- 生成 Context Manifest，记录本次实际使用的来源；
- 缺失上下文时停止执行并创建补充任务。
产物：Context Manifest、可追溯来源、任务专用工具集。
退出条件：关键事实必须能从版本化资料或工具结果中重建，而不是只存在于人的记忆或聊天窗口。
阶段 7：创建隔离工作区和单一用途身份
Agent 不应直接在共享开发机或主分支上自由执行。
细分动作：
- 从明确 Commit 创建分支和 Git Worktree；
- 启动临时容器、VM、Devbox 或 Kubernetes Pod；
- 为任务分配单一用途身份和短期凭证；
- 挂载最少仓库、数据和工具；
- 默认关闭生产写权限；
- 对网络出口进行白名单或代理控制；
- 注入合成、脱敏或专用测试数据；
- 启动任务级应用、日志、指标和 Trace；
- 记录模型、Harness、规则、工具版本和基础 Commit；
- 设置时间、Token、计算和重试预算；
- 设置取消、超时和人工接管通道。
产物：可重放的 Execution Manifest 与完整审计轨迹。
退出条件：环境销毁后不残留凭证；Agent 越权时由硬边界阻止，而不是靠 Prompt 劝阻。
阶段 8：计划、实现与最小 Diff
实现阶段仍需要 Agent Loop，但 Loop 不能只有“生成—失败—重试”。
细分动作：
- Agent 先重述目标、范围、风险和验证计划；
- 扫描现有实现和测试，提出最小变更路径；
- 对 R2/R3 任务先由人批准计划；
- 小步修改，每个逻辑单元都可验证；
- 优先复用 Golden Path 和仓库既有模式；
- 不在当前任务中顺手重构；
- 新依赖必须说明必要性、许可证和供应链风险；
- 新行为必须同时增加测试和可观测信号；
- 发现范围外问题时创建后续工单，不扩大当前 Diff；
- 变更假设或不变量时立即停止并请求重新签订任务合同。
产物：最小 Diff、测试、观测、迁移与文档更新。
退出条件：Agent 能逐项映射“验收标准 → 代码 → 测试 → 证据”。
阶段 9：任务内验证闭环
验证至少分四层，不能只让生成代码的 Agent 说“看起来没问题”。
第 1 层：快速确定性 Verifier
- 格式化、Lint、类型检查；
- 编译、单元测试、契约测试；
- 结构与依赖规则；
- Secret、License、SCA、SAST；
- 受影响测试选择与变更覆盖；
- 任务声明的自定义不变量。
Verifier 应暴露统一接口并压缩输出：成功返回短摘要；失败返回最相关错误、复现命令和证据路径。
第 2 层：行为验证
- 临时环境中的 API 或 UI Journey；
- Screenshot、DOM、视觉回归和无障碍检查；
- 性能、并发、容错和数据回放；
- 迁移 Dry Run 与回滚演练；
- 任务级日志、指标和 Trace 查询。
第 3 层：独立 AI 评审
将原始任务合同、Diff 和证据包交给与实现 Agent 分离的评审 Agent：
- Scope Judge：是否做了未要求的变更；
- Correctness Reviewer：行为、边界和错误路径；
- Security Reviewer：信任边界、输入、身份和数据；
- Test Reviewer：测试是否真正覆盖验收与不变量；
- Operations Reviewer：观测、容量、发布和回滚。
不同 Reviewer 使用窄职责、独立上下文和明确输出 Schema。不要用一个“万能超级评审 Prompt”。
第 4 层：风险匹配的人类判断
人类不应重新手工检查所有机器已确定的问题，而应聚焦：
- 任务是否值得做；
- 产品体验和技术方案是否合理；
- 隐含风险是否被忽略；
- 证据是否可信；
- 是否应该合并、发布或扩大流量。
退出条件：所有必须 Verifier 通过；AI 发现已处置；风险所需专家已批准；证据包完整。
阶段 10：创建 PR 与证据包
PR 描述不应只是 Agent 生成的摘要，而应是可审计的交付清单。
## Outcome
解决的问题、预期结果和关联证据
## Scope
改了什么；明确没有改什么
## Risk
风险级别、数据分类、信任边界、爆炸半径
## Acceptance mapping
- AC-1 -> 文件/测试/运行证据
- AC-2 -> 文件/测试/运行证据
## Invariants
每个系统不变量及其验证结果
## Verification
类型、测试、安全、性能、UI、迁移与评审结果
## Rollout
内部 -> 5% -> 25% -> 100%，每阶段观察窗口和停止阈值
## Rollback
开关、版本、数据恢复与负责 Owner
## Provenance
基础 Commit、Agent/Harness、规则和工具版本、运行记录
细分动作：
- PR 自动关联任务合同；
- 展示范围、风险和受影响组件；
- 附上可点击验证结果而不是粘贴海量日志；
- 标记 AI 参与和人工接管点；
- 根据 CODEOWNERS、组件目录和风险分级路由 Reviewer；
- 修改后只重跑受影响 Verifier，并保留完整关键门禁；
- 所有批准记录输入、证据和理由；
- 超过大小、等待时间或失败次数阈值时拆分任务。
退出条件：Reviewer 不需要重建上下文就能判断风险、证据和回滚。
阶段 11：合并决策与队列治理
AI 增加 PR 到达率后，评审队列会成为系统瓶颈。必须主动限制 WIP。
建议规则：
- R0 不产生代码合并；
- R1 在所有门禁通过后可自动合并，并进行风险加权抽样；
- R2 必须由领域或系统 Owner 审批；
- R3 至少双人审批，并包含 Security/Compliance Owner；
- 数据迁移与应用发布尽量解耦；
- 同一组件同时运行的 Agent 任务受 WIP 限制；
- 等待评审超过阈值时停止生成更多相同风险 PR；
- 大批量迁移先做 Canary Repo，再扩大到组件 Fleet；
- 合并使用 Merge Queue，保证每个变更在最新主干上验证。
退出条件：主干绿、审批完整、发布 Owner 明确、回滚路径仍然有效。
阶段 12：预发布与渐进交付
细分动作：
- 构建可追溯、签名的不可变 Artifact；
- 生成 SBOM 和 Provenance；
- 部署到与生产足够相似的 Staging；
- 执行 E2E、契约、DAST、性能和恢复验证；
- 对重大变更执行外部或独立渗透测试；
- 校验 Dashboard、Alert、Runbook 和 On-call；
- 先内部用户或测试租户；
- 再按 1%/5%/25%/100% 或业务适配比例扩大；
- 每个阶段比较主指标、护栏指标、错误预算和成本；
- 触发阈值自动暂停或回滚；
- R2/R3 扩大流量需要人工确认；
- 发布完成后保留观察窗口，不立即关闭任务。
产物：发布记录、灰度证据、回滚演练、运行 Owner。
退出条件：发布成功不是“部署命令返回 0”，而是关键 Journey、SLO 和业务护栏在观察窗口内成立。
阶段 13：生产监控、事故响应与权限隔离
生产阶段可以使用 Agent 做高价值分析，但必须隔离分析和执行权限。
告警触发后的建议链路：
- Triage Agent 读取脱敏日志、指标、Trace 和最近变更；
- 建立影响范围、时间线和候选根因；
- 关联发布、Feature Flag、依赖和基础设施事件；
- 生成复现步骤与证据；
- 提出缓解或回滚建议；
- On-call 人员批准生产动作；
- 另一个修复 Agent 在隔离环境创建变更；
- 走正常验证、评审和发布门禁；
- Agent 起草 Postmortem，人类 Owner 确认责任和行动项；
- 所有 Agent 行为进入 SIEM 或等价审计系统。
关键边界：
- 读生产日志的 Agent 不应同时拥有生产部署权限；
- 能写代码的 Agent 不应自行批准自己的修复；
- Agent 间通信也是权限边界的一部分；
- “模型被指示不要做”不是硬控制；
- 生产 Emergency Path 也必须保留身份、批准和审计。
阶段 14：把结果写回系统，完成“Learned”而非“Deployed”
每个任务最终应进入 Learned 状态，而不是部署后直接关闭。
细分动作：
- 比较主指标、护栏指标和原始假设；
- 判定保留、扩大、调整、回滚或删除；
- 将逃逸缺陷转成回归测试和不变量；
- 将重复误用转成 Lint、Policy、Skill 或 Golden Path；
- 将 Agent 卡点归类为工具、上下文、规则、模型或任务合同问题；
- 更新 ADR、Runbook、目录、Owner 和组件健康度；
- 删除过期 Prompt 和互相冲突的规则；
- 评估 Agent/Reviewer 是否需要继续 Shadow Mode；
- 记录成本、人工接管和 Review Toil；
- 创建后续任务，并关闭不再值得维护的实验代码。
退出条件：团队不仅交付了变更，还让下一次相似变更更快、更安全、更少依赖人类记忆。
五、一个任务在系统里的状态机
工单应该成为控制面，而不是 Agent Session 成为控制面。推荐状态如下：
| 状态 | 进入条件 | 自动动作 | 人类动作 |
|---|---|---|---|
Signal | 捕获到原始证据 | 聚类、关联、去重 | 判断是否值得调查 |
Hypothesis | 问题与用户明确 | 生成反例、指标建议 | 定义结果和 Kill Criteria |
Prototype | 最小学习方式明确 | 生成候选原型 | Dogfood 与去留判断 |
Contracting | 决定生产化 | 装配上下文、检查缺项 | 定范围、风险和 Owner |
Ready | 任务合同完整、依赖解除 | 创建隔离工作区 | R2/R3 批准执行计划 |
Running | Agent 开始执行 | 实现、自检、Verifier | 处理升级和范围变化 |
Evidence | 代码完成 | 独立评审、生成证据包 | 专家判断残余风险 |
Review | 门禁满足 | 路由 Reviewer、Merge Queue | 批准或拒绝 |
Release | 主干可发布 | Staging、灰度、观测 | 批准扩大流量 |
Observe | 变更进入生产 | 对比指标、检测回归 | 判断保留或回滚 |
Learned | 观察窗口结束 | 更新测试/规则候选 | 确认学习与后续工作 |
Closed | 证据与知识写回完成 | 归档运行记录 | 对结果负责 |
状态机还需要四条规则：
- Agent 只领取
Ready且依赖已解除的任务； - 任务进入
Needs Human时，不用自动重试掩盖不确定性； - 每个状态有最大停留时间和 Owner；
- Session、分支和 PR 都是任务的实现细节，不是最终业务状态。
六、按风险分配 Agent 自主权
风险分级不能只按代码行数。一个三行权限修改可能比三千行测试重构危险。
| 级别 | 典型工作 | Agent 权限 | 验证与审批 | 发布 |
|---|---|---|---|---|
| R0 只读探索 | 解释代码、总结日志、生成计划 | 只读，无外部副作用 | 来源引用，人工使用结果 | 不发布 |
| R1 低风险变更 | 文档、测试、简单依赖补丁、受控重构 | 隔离写仓库，可创建 PR | 完整 CI、自动评审、风险抽样 | 可自动合并/灰度 |
| R2 业务关键 | 核心流程、跨服务、性能、可逆数据变更 | 限定工具与测试环境 | 领域专家审批、行为测试、回滚演练 | 人工批准扩大流量 |
| R3 安全与合规 | 身份、支付、隐私、生产权限、不可逆迁移 | 最小权限、强隔离、禁止自主生产动作 | Security/Compliance 双人门禁、独立测试 | 分阶段人工批准 |
自主权的扩大应该基于某个工作流的实证历史，而不是“换了一个更强模型”：
Shadow Mode
→ 只读建议
→ 创建草稿 PR
→ 自动执行、人工必审
→ 低风险自动合并、风险抽样
→ 在明确边界内扩大任务类型
每次升级都需要：
- 足够样本量；
- 明确的假阳性、假阴性和逃逸缺陷；
- 稳定的成本与完成率；
- 可用的回滚和 Kill Switch；
- Security、Platform 与业务 Owner 共同确认。
七、真正要建设的是 AI 工程平台
一个可规模化的 AI-SDLC 至少有五层。
1. 业务输入层
统一连接代码、文档、工单、观测和用户反馈。目标不是把所有数据复制进一个向量库，而是让 Agent 能发现来源、按权限查询并保留深链接。
2. 上下文层
提供软件目录、Ownership、架构地图、项目规则、Skills、Golden Path 和 MCP/CLI 工具。上下文必须可版本化、可测试、可淘汰。
3. 执行层
负责 Agent Runtime、Git Worktree、临时环境、工具调用、任务队列、超时、重试、取消和恢复。每个任务拥有独立工作区与可重放 Manifest。
4. 控制层
负责身份、权限、数据策略、网络出口、审批、审计、成本和 Kill Switch。控制应作用于工具和真实动作，而不只作用于自然语言指令。
5. 交付层
负责 PR、CI、Merge Queue、Artifact、灰度、Feature Flag、回滚、监控与事故响应。Agent 必须通过这一层进入生产，不能绕过它。
平台团队的产品目标
AI 平台不应以“接入了几个模型”为目标，而应持续提升：
- 任务可执行性；
- 上下文可发现性；
- 验证覆盖与反馈速度；
- 低风险自动化比例；
- 证据完整度；
- 人类 Review Toil；
- 生产稳定性；
- 单位学习成本。
八、工具地图：每一层可以用什么
工具会快速变化，选型应围绕接口、证据和可替换性，不要围绕单一模型绑定整条链路。
| 能力层 | 可选工具 | 主要用途 | 选型重点 |
|---|---|---|---|
| 工作与状态 | Linear、Jira、GitHub Issues、GitLab Issues | 任务合同、依赖、状态机、Owner | API、Webhook、Schema、自定义门禁 |
| 软件目录 | Backstage / Spotify Portal、自建 Service Catalog | 组件、Owner、文档、依赖、Golden Path | 数据新鲜度、MCP/CLI、评分能力 |
| 组织知识 | 仓库 Markdown/ADR、Notion、Confluence、Google Drive | 规则、历史决策、设计与运行手册 | 版本、权限、深链接、过期治理 |
| 代码检索 | Git 原生搜索、Sourcegraph、语言服务器、代码图谱 | 定位实现、引用、依赖和历史 | 召回、权限、增量索引 |
| 交互式 Agent | Claude Code、Codex CLI/App、GitHub Copilot、Cursor | 探索、计划、实现、测试、评审 | 工具权限、可观测性、可恢复性 |
| Agent SDK/Harness | Claude Agent SDK、Codex SDK/App Server、OpenAI Agents SDK、自建 Harness | 构建领域 Agent 和任务闭环 | 状态、事件、审批、沙箱、审计 |
| 并行与编排 | Claude Squad、Symphony 规范、Temporal、队列系统、自建 Orchestrator | Worktree 隔离、任务 DAG、后台执行 | 不把 Session 当业务状态、WIP 限制 |
| 大规模迁移 | Fleetshift/Honk、Codemod、OpenRewrite、Semgrep Autofix | 跨仓库/组件变更 | Canary、Verifier、Fleet 可视化 |
| 隔离环境 | Git Worktree、Dev Containers、Docker、Kubernetes、Codespaces、远程 VM | 任务级执行与爆炸半径控制 | 临时凭证、网络出口、销毁、成本 |
| CI | GitHub Actions、GitLab CI、Buildkite、CircleCI、Jenkins | 构建、测试、门禁、Artifact | 并发、缓存、可重放、机器可读结果 |
| 测试 | Jest/Vitest、pytest、JUnit、Go test、Playwright、Cypress、Pact | 单元、契约、E2E、UI 与行为验证 | 确定性、速度、场景覆盖 |
| 代码与供应链安全 | CodeQL、Semgrep、SonarQube、Snyk、Dependabot、Trivy、Syft/Grype | SAST、SCA、Secret、容器、SBOM | 可解释结果、基线、PR 集成 |
| 动态安全 | OWASP ZAP、Burp Suite、StackHawk、定制 DAST Agent | 运行态和跨服务安全验证 | 与部署节奏一致、可复现证据 |
| Policy as Code | OPA/Rego、Conftest、Kyverno、云 IAM Policy | 权限、架构、部署与合规规则 | Hard Gate、版本化、测试 |
| 发布 | Argo CD、Argo Rollouts、Flagger、LaunchDarkly、Unleash | GitOps、Canary、Feature Flag、回滚 | 自动停止、审计、环境一致性 |
| 可观测性 | OpenTelemetry、Prometheus、Grafana、Datadog、Sentry、Honeycomb | Logs、Metrics、Traces、错误和 SLO | Agent 可查询、脱敏、深链接 |
| 事故与审计 | PagerDuty、Opsgenie、SIEM、云审计日志 | 告警、响应、行为审计 | 单一用途身份、不可抵赖性 |
| Secrets 与身份 | Vault、云 IAM、短期 OIDC、Secrets Manager | 最小权限、临时凭证 | 不向 Prompt 暴露 Secret、快速吊销 |
不同规模的最小组合
个人或 3–8 人团队：
GitHub/GitLab
+ 一个主力编码 Agent
+ Git Worktree 或 Dev Container
+ CI 与核心测试
+ Playwright/契约测试
+ SAST/SCA
+ Feature Flag
+ Sentry/OpenTelemetry
20–100 人团队：
在上面基础上增加软件目录、Golden Path、临时环境、统一 Verifier、风险路由、Merge Queue、Agent 运行看板和任务级成本。
受监管或大规模团队：
增加远程受控 VM、网络出口白名单、每 Agent 身份、Policy as Code、集中审计/SIEM、签名 Artifact、SBOM、双人审批、风险抽样和持续 Red Team。
选型原则
- 先统一工作状态和证据 Schema，再买更多 Agent；
- 优先选择可通过 CLI/API/MCP 稳定调用的工具；
- 确定性检查不要交给 LLM 重做；
- 模型、Harness、工具和知识层保持可替换；
- 一个能力只保留一个主系统记录；
- 所有自动化都必须有 Owner、SLO、成本和 Kill Switch。
九、团队应该怎样分工
AI 让角色变宽，但不能让责任模糊。
| 角色 | 主要责任 | 不应外包给 Agent 的判断 |
|---|---|---|
| Product/Business Owner | 问题、优先级、指标、Kill Criteria | 是否值得做、用户结果是否成立 |
| Engineering Owner | 方案、任务合同、系统不变量、最终合并 | 技术取舍、长期 Ownership |
| Domain Expert | 领域规则、边界和例外 | 隐性业务语义与风险容忍度 |
| Security/Compliance | 风险模型、权限、政策和高风险门禁 | 法律、安全与合规责任 |
| Platform Team | 上下文、Harness、隔离、Verifier、目录和黄金路径 | 自主级别升级与平台可靠性 |
| SRE/Operations | SLO、发布、监控、事故和恢复 | 生产影响与应急决策 |
| AI Workflow Owner | Agent/Reviewer 的 Eval、版本、成本和 Shadow Mode | 是否扩大自动审批范围 |
| Agent | 检索、计划、实现、测试、总结、重复迁移 | 目标选择、风险接受、最终责任 |
推荐组织形态
- 业务 Pod：Product、Design、Engineering、领域专家共同拥有结果；
- AI Platform Team：提供统一上下文、执行、验证和治理底座；
- Risk Council：Security、Legal、SRE、Architecture 定期调整风险路由；
- Workflow Owner：每条自动化闭环都有一个具体人，而不是“平台团队共同负责”。
人类注意力应该放在哪里
优先放在：
- 问题选择；
- 冲突需求与产品品味；
- 架构和安全边界；
- 证据可信度；
- 不可逆决策；
- 生产风险与事故；
- 人才培养、反馈和团队健康。
不应长期消耗在：
- 格式、模板和重复性 PR 描述；
- 已可确定性验证的机械检查；
- 手工复制上下文；
- 盯着多个 Agent 终端等待；
- 逐仓库执行一致迁移；
- 重复解释同一类错误。
十、Definition of Ready、Done、Released 与 Learned
Definition of Ready for Agent
- 有可追溯问题证据；
- 目标结果和非目标明确；
- 验收标准可执行；
- 系统不变量已列出；
- 风险级别、数据分类和 Owner 明确；
- 上下文来源可发现；
- 允许工具和禁止动作明确；
- 依赖已解除；
- 隔离环境可创建；
- 停止和人工升级条件明确。
Definition of Done for Change
- Diff 保持在任务范围内；
- 代码、测试、文档和观测同步更新；
- 确定性 Verifier 全部通过；
- 行为、性能或迁移场景已验证；
- 独立 AI Reviewer 结论已处理；
- 证据包完整；
- 风险所需人类审批完成；
- Artifact 可重建、可追溯。
Definition of Released
- Staging 和动态验证通过；
- Feature Flag/Canary 可用；
- Dashboard、Alert、Runbook 和 On-call 就绪；
- 回滚演练可行；
- 灰度阶段和停止阈值明确；
- 关键 Journey、SLO 和业务护栏正常。
Definition of Learned
- 原始假设已被验证或否定；
- 用户和生产结果已记录；
- 逃逸问题已转成测试、规则或不变量；
- Agent 卡点已转成环境改进；
- 文档、目录、ADR 和 Runbook 已更新；
- 实验代码已产品化或删除；
- 后续任务有 Owner；
- 本次学习可被下一次任务检索。
十一、指标：不要用代码行数和 AI 占比证明成功
AI 生成代码占比、Prompt 数量和 Token 消耗只能说明采用程度，不能说明交付价值。
1. 结果指标
- 用户任务成功率；
- 主业务指标和护栏指标；
- 实验转生产率；
- 无价值工作删除率；
- 从假设到可信学习的周期。
2. 流动指标
- Lead Time for Changes；
- PR 等待时间与 Review 队列长度；
- 同时在制任务数；
- 从
Ready到证据包完成的时间； - 任务阻塞与人工升级时间；
- CI p50/p95 反馈时间。
3. 质量与稳定性指标
- 变更失败率；
- 回滚率；
- 逃逸缺陷；
- MTTR；
- SLO 与错误预算；
- 安全发现的严重性与发现阶段；
- Flaky Test 比例。
4. Agent Workflow 指标
- Agent 完成率：进入
Running后形成合格证据包的比例； - 首次验证通过率；
- Judge 否决率与修正成功率；
- Scope Drift 率；
- 人工接管率及原因；
- 每类任务的成本、耗时和重试数；
- Shadow Mode 假阳性、假阴性；
- 自动审批后的风险抽样缺陷率。
5. 人类系统指标
- 每个 PR 的人工 Review Toil 分钟数；
- 工程师等待与上下文切换时间；
- Onboarding 首次真实贡献时间；
- 开发者满意度与认知负担；
- 专家评审是否集中在真正高风险区域；
- 团队是否因为 AI 失去学习和系统理解机会。
一个更实用的北极星指标
可信学习吞吐 = 在一个时间窗口内，
完成生产验证、满足质量护栏、
并写回组织知识的有效假设数量
它同时约束速度、质量和学习，避免团队用更多代码掩盖更差结果。
十二、90 天流程建设路线
0–30 天：基线与边界
第 1 周：看清当前系统
- 画出现有 SDLC Value Stream；
- 记录 Lead Time、Review、CI、失败率和 MTTR；
- 找到真正瓶颈，而不是假设编码最慢；
- 盘点工具、数据、权限和供应商。
第 2 周：制定政策和风险分级
- 定义 R0–R3；
- 定义数据和模型使用政策；
- 定义工具白名单、身份和审计要求；
- 建立 Kill Switch 与事故处理流程。
第 3 周：准备任务合同和上下文入口
- 创建任务合同模板；
- 精简项目指令文件；
- 补齐构建、测试、Owner 和架构入口；
- 选择 2–3 类低风险、验收清晰的任务。
第 4 周：Shadow Mode 试点
- Agent 只提出计划或 Draft PR；
- 人类仍走原流程；
- 收集完成率、错误、成本、接管原因；
- 建立失败分类，不用“模型不行”作为统一结论。
阶段退出标准：政策批准、基线可见、任务合同可用、试点有 Owner 和停止阈值。
31–60 天：闭环与门禁
第 5 周：统一 Verifier
- 统一格式、类型、构建和测试接口；
- 输出机器可读结果；
- 增加 Scope Judge 和不变量检查；
- 失败自动返回实现环节。
第 6 周：隔离执行
- 每任务 Worktree/Container；
- 临时凭证和网络边界；
- 任务级 Logs/Metrics/Traces；
- 记录 Execution Manifest。
第 7 周：证据化 PR
- PR 自动生成证据包；
- CODEOWNERS 与风险路由；
- Merge Queue 和 WIP 限制；
- Reviewer 只看残余风险。
第 8 周：渐进发布
- Feature Flag/Canary；
- 自动停止和回滚阈值；
- 关键 Journey 与 SLO 看板；
- 发布后保留观察状态。
阶段退出标准：低风险任务可以在不降低稳定性的前提下形成可审计、可回滚的闭环。
61–90 天：平台与治理
第 9 周：上下文平台
- 软件目录和 Owner；
- ADR、事故、Runbook 与组件地图；
- MCP/CLI 统一查询；
- 文档新鲜度和 Docs Gardening。
第 10 周：Reviewer 与 Eval
- 建立窄职责 Reviewer；
- 使用历史 Bug、真实 Diff 和对抗样本；
- 测量假阳性、假阴性、越界与成本；
- 新 Reviewer 进入 Shadow Mode。
第 11 周：审计与运营看板
- Agent 身份、工具调用、审批和通信进入审计；
- 跟踪任务、模型、规则和工具版本；
- 建立成本、可靠性、稳定性和人工 Toil 看板；
- 定义每条 Loop 的 SLO 和 Owner。
第 12 周：扩展与复盘
- 只扩展已证明稳定的任务类型；
- 对失败工作流降级或关闭；
- 删除无效流程和重复工具；
- 发布下一季度的平台能力和风险治理计划。
90 天退出标准：团队拥有一条真实生产闭环，而不是一组个人 AI 工具许可证。
十三、典型失败模式，以及应该修改什么
1. PR 数量暴涨，但 Lead Time 变长
根因：只扩张生成能力，没有扩张验证、评审和发布能力。
改法：限制 WIP；先投资 Verifier、Merge Queue 和风险自动路由；Review 队列超阈值时停止新增同类任务。
2. Agent 经常要求补充上下文
根因：知识存在聊天、人脑和私有文档中，仓库与目录不可导航。
改法：建立小入口、架构地图、Owner、ADR 和按需工具；记录 Context Manifest；不要继续扩张巨型 Prompt。
3. Agent 通过 CI，但功能仍然错误
根因：CI 只验证语法和已有测试，没有验证任务合同、不变量和真实 Journey。
改法：增加契约、场景、性能、权限和 Scope Judge；让独立 Reviewer 比较任务与 Diff；发布时做 Canary。
4. AI Reviewer 评论很多，但团队不信任
根因：没有 Eval、证明和误报基线，Reviewer 责任过宽。
改法：拆成窄 Reviewer；要求证据；跑 Shadow Mode；统计假阳性、假阴性和风险抽样结果。
5. Agent 为了通过测试而删除或弱化测试
根因：优化目标错误，缺少测试完整性和范围约束。
改法：任务合同声明不变量；检测测试删除、Skip 和覆盖下降；Scope Judge 直接否决越界行为。
6. 多 Agent 相互污染代码和状态
根因：共享工作区、共享凭证、共享 Session，缺少任务级隔离。
改法：每任务 Worktree/Container/身份；以工单为控制面；依赖使用 DAG；同组件限制并发。
7. 安全控制只写在 Prompt 里
根因：把模型遵循指令当作权限系统。
改法：使用 IAM、沙箱、网络出口、Policy as Code 和审批硬门禁；按动作控制，而不是按模型意图控制。
8. 所有任务都追求完全自主
根因：把 Demo 自主性当作业务价值。
改法：按风险分级；低风险自动化，高风险把 Agent 用于生成证据和缩短专家判断时间。
9. 团队购买很多工具，却没有系统记录
根因：每个环节有自己的 Agent 和状态，无法追踪一个变更为何产生、如何验证和谁批准。
改法：确定工单、仓库、Artifact 和观测的主记录；所有工具围绕同一 Task ID 和 Evidence Schema 集成。
10. 自动化运行一段时间后逐渐变差
根因：规则、Skill、文档、Eval 和依赖会过期，但没有 Workflow Owner。
改法：每条 Loop 有 SLO、Owner、版本和复盘周期；持续抽样；Docs Gardening；新模型上线前回归 Eval。
十四、一套可以直接落地的团队日常节奏
每日
- Product/Engineering Owner 只把合同完整的任务移动到
Ready； - Orchestrator 领取未阻塞任务，创建隔离环境；
- 人类查看
Needs Human、高风险计划和证据包，而不是盯 Agent 输出流； - CI/Verifier 失败自动回到实现；范围或目标变化必须回到 Contracting；
- 发布按灰度和观察窗口进行；
- 事故 Agent 只负责分析和建议，生产动作由独立身份批准。
每周
- 查看交付瓶颈、Review 队列、CI p95 和稳定性；
- 分析人工接管 Top 5 原因；
- 把重复失败转成工具、规则、测试或文档；
- 抽样自动批准的变更；
- 删除失效 Prompt、重复流程和低价值任务；
- 复盘人类时间是否真正移向用户、架构和风险判断。
每月
- 对模型、Harness、Reviewer 和关键 Skill 跑回归 Eval；
- 复核 Agent 身份、权限、出口和供应商策略；
- 比较业务结果、DORA 指标、Agent 指标和团队健康；
- 决定哪些工作流升级、保持、降级或关闭；
- 更新风险矩阵与平台路线图。
每季度
- 重画 Value Stream，确认瓶颈是否已经迁移；
- 审查 AI 是否放大了架构耦合、技术债或组织不清；
- 评估是否应该减少流程，而不是继续叠加门禁；
- 对关键自动化做 Red Team、灾难恢复和 Kill Switch 演练；
- 用可信学习吞吐和用户结果决定下一阶段投资。
十五、最终建议：从一条闭环开始，而不是从“全员 AI”开始
真正可落地的顺序是：
- 找到一个低风险、重复、验收清晰的真实任务；
- 写出任务合同和风险边界；
- 建立隔离环境与最小权限；
- 先补 Verifier 和证据包；
- 用 Shadow Mode 评估 Agent 与 Reviewer；
- 接入 PR、灰度、监控和回滚；
- 把生产结果写回测试、规则和知识；
- 只有闭环稳定后，才扩大任务类型和自主权。
AI 原生 SDLC 的竞争力，不来自某一次生成了多少代码，而来自一个持续自我改善的系统：
每一次任务都留下证据，每一次失败都改善环境，每一次发布都产生学习，每一次自主权扩大都有数据依据。
做到这一点，团队才不是“用了 AI”，而是建立了能够安全吸收模型能力进步的工程组织。
参考资料
Anthropic / Claude
- Running an AI-native engineering org
- How Anthropic secures its AI-native software development lifecycle
- Building effective agents
- Effective context engineering for AI agents
Spotify
- Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify
- Background Coding Agents: Context Engineering (Honk, Part 2)
- Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3)
- Background Coding Agents: Supercharging Downstream Consumer Dataset Migrations (Honk, Part 4)
OpenAI
- Harness engineering: leveraging Codex in an agent-first world
- An open-source spec for Codex orchestration: Symphony
- How OpenAI uses Codex
- Building an AI-native engineering team