AI-Native SDLC playbook

AI-Native SDLC playbook

如何借助 AI 逐阶段改造你的软件开发生命周期。

代码不再是瓶颈

各组织已经开始用 AI 以一年前难以想象的速度编写代码，但围绕代码本身的流程却没能以同样的速度改变。

许多工程团队仍沿用相同的审批关卡、评审、交接与策略，导致采用 Claude Code 这类智能体编码方案所获的生产力提升被白白消耗。

软件开发生命周期（SDLC）是将软件从想法带到生产环境的过程。多数组织运行着大同小异的六个阶段，覆盖软件的规划、设计、构建、测试、部署与运维。传统上，每个阶段都是归属于不同角色的离散环节：产品经理写需求，技术架构师将其转化为设计，工程师按设计构建，受监管企业的 QA 团队负责验收，发布团队负责上线，运维团队监控运行中的系统。各阶段之间通过文档、工单与签核来流转。

传统软件开发生命周期（SDLC）流程繁复，是为了在每一步都确保问责与控制。然而，传统 SDLC 是在“最耗时、最昂贵的阶段是编写与实现代码”的时代为最大化效率而设计的——而如今已不再是这样。PRD、估算仪式、产品安全评审，统统是为了在可能长达数周、数月乃至数季度的开发过程中强行对齐而存在的。

传统 SDLC 还带有一些假设“每一步都由人类执行”的控制手段。那些创造最大价值的组织，已经围绕智能体 AI 现在能做到的事情重建了流程，同时确保人类始终在环。在本指南中，我们将结合服务客户的心得，带你走一遍 Applied AI 团队在 SDLC 各阶段内部集成 Claude 的若干最佳实践，以加速开发、让流程跑得更快。

当代码不再是瓶颈，且构建阶段比传统 SDLC 所能容纳的速度更快时，以下三件事会变成现实：

• 瓶颈转移到了构建阶段左右两侧的环节，主要是规划、评审/测试与部署——这些环节仍以人类速度运转。
• 控制手段不再贴合现实，变得难以驾驭。逐行人工审查在“代码由人写就”时尚有意义，可一旦智能体写完了大部分 diff，它就跟不上了。
• 治理成本上升，因为例外情况仍要经由每周或每月才开一次的会议与委员会来流转。

构建不再是约束——它周围以人类速度运转的环节才是。人类速度的环节保持原有长度，而构建被压缩到数小时。

以安全瓶颈为例。安全团队的规模是按人类产出配置的，因此当智能体让代码产出成倍增加时，要么评审队列堆积，要么代码在未经充分评审的情况下就被发布。受监管的组织无法接受这两种结果，因此其安全与策略检查必须跟上智能体的节奏。

为了更好地释放智能体 AI 的生产力并保障其安全，传统 SDLC 生命周期所需要的变革程度，应与实现阶段已经历的变革相当。

什么是 AI-Native SDLC？

AI-Native SDLC 是一种被重新构想的流程，它将旧的控制目标与新的执行方式结合在一起。它不再是线性流转，而是变成一个循环，AI 被嵌入到每一个节点。AI-Native SDLC 倡导后续 Play 的自动化交接与触发，从而缓解传统 SDLC 各阶段之间手工、笨拙的交接问题。

转变

下表对比了传统 SDLC 与 AI-Native SDLC 两个极端之间的差异（由 Claude 支撑）。多数组织处于这两列之间的某个位置。

贯穿右列的主线，是“已提交的产物（committed artifact）”。每个阶段结束时都会向版本控制提交一个产物（包括 intent.md、spec.md、plan.md、diff 及其测试、带评审结论的 PR，以及事件记录），下一阶段则通过读取它来开始。在较早的阶段，.md 文件是主要的产物形态，因为产品负责人与智能体都能读取并基于同一份文件行动。从构建阶段开始，产物变成代码及其记录。而这条提交链本身，就是审计线索：谁要求了什么、智能体产出了什么、谁做了审批。

凡是需要判断的决策，人类始终负有责任。在智能体 SDLC 的世界里，人类的注意力会随“必须被评审的产物”一同转移。

Plays（核心实践）

Plays 是这本实操手册的核心，它们被归入六个非线性的阶段（Plan、Design、Build、Test、Deploy、Maintain），合在一起覆盖完整的生命周期。

每个 Play 都涵盖：

• 改变了什么；
• 如何上手；
• 具体的落地步骤；
• 治理考量；以及
• 如何衡量它是否奏效。

这些步骤是模块化的，各组织可根据自身独特需求，选择在不同时间优先改造不同阶段。每个 Play 都会在“前置条件（Prerequisites）”下列出自己的依赖项，依赖关系图会进一步加以说明。

一个阶段以提交一个产物结束，而该次提交会触发下一阶段：一份被接受的 intent.md 触发需求与设计环节，一份被批准的 spec.md 触发规划模式，一个被合并的 PR 触发流水线，而生产环境中被突破的控制带（control band）则会写下下一份 intent.md——如此循环往复。

首先，你手动提示每一步，最终状态是一个循环：每个被接受的产物都会触发下一个关卡。人类的注意力集中在各个关卡上，评审智能体所标记的内容，而不是从零开始每个阶段。

各 Play 按阶段列出；箭头表示建议的采用顺序。两者并不相同。从任意一个没有前置依赖的 Play 开始——没有任何箭头指向它，因此无需先做什么。对于其他任何 Play，指向它的箭头所代表的，就是应当先于它采用的 Play。

规划（Plan）

以 intent.md 捕获需求

作为起点的 intent.md 可以通过不同途径进入流程：有人产生了想法、有人提交了工单，或者某个告警暴露了一起事件（见阶段 6：运维）。

当有人产生想法时，他会与 Claude 一起头脑风暴，产出一份 markdown 原型规格。在传统 SDLC 中，同一个人还必须说服产品团队的一员，由对方（或代其）把这想法写成文档。

由 Claude 生成的原型规格是人类可读、受版本控制、且下一阶段可立即消费的。这份原型规格被保存为 intent.md。

无论需求是来自事件触发还是来自智能体，以下步骤都适用：产品负责人在 intent.md 提交前，对智能体写就的 intent.md 进行评审与修正。

搭建这套机制对平台或工程团队而言是一项一次性任务。技术团队成员需要把“意图家园（intent home）”立起来，并决定谁可以写入其中，因为许多贡献者会来自组织各处。

一旦代码仓库就位，没有 git 经验的贡献者无需直接使用 git。相反，一个通往版本控制系统的连接器（如 GitHub）能让 Claude 代表他们，从 claude.ai 或 Cowork 提交 markdown 文件。

如何执行

• 发起者用自己的话向 Claude 描述问题。发起者可以描述“今天做不到什么”、受该想法影响的是谁、“更好的状态”是什么，或者哪些不在范围内。无需使用正式语言。
• 头脑风暴，直到想法变得具体。Claude 会像分析师那样提问：范围、用户、约束，以及成功长什么样。
• 让 Claude 用组织的模板把结果写成 intent.md——该模板可由技术团队成员编写为 skill 并由负责人签核。它可以覆盖问题、预期结果、受影响的用户与系统、约束，以及待解决问题。
• 发起者修正任何 Claude 误解的地方。
• 将 intent.md 提交到共享家园。作者与时间戳进入记录，产品负责人从那里接手这个想法。

# Intent: claims status self-service
 Author: J. Ortiz (claims operations). Status: draft.
 ## Problem
 Customers phone the contact center to ask where their claim is.
 Handlers spend roughly a third of call time on status-only queries.
 ## Proposed outcome
 Customers see claim status, next step and expected date in the portal.
 ## Affected users and systems
 Claims handlers, portal team, claims-core API.
 ## Constraints
 No new PII in the portal session. Existing authentication only.
 ## Open questions
 Do third-party loss adjusters need access too?

治理考量

证据就是那份被提交的 intent.md，它列出了作者、时间戳与完整的修订历史。它被记录在 intent home 的 git 历史中。产品负责人予以批准，而“接受或拒绝、从而将 intent 送入阶段 2：设计”的决策，则作为合并或收尾评审被记录下来。

设计（Design）

需求与设计

一旦经产品负责人批准，Claude 会接收被接受的 intent.md，并产出一份需求与设计规格。这一过程由组织在品牌、安全、合规与 UX 方面的 skills 所引导。

产品负责人评审这份规格，但不亲自撰写。这一流程的目标，是产出一份工程团队可以据此做规划、并标出关切点的规格。

前端工作是最直观的例子。一旦 intent.md 被接受，产品负责人便基于 intent.md 在 Claude Design（beta）中把设计稿做出来，对稿子迭代，再导出到 Claude Code 去构建。

如何执行

• 产品负责人开启一个会话，加载组织的 skills，并附上 intent.md。
• 产品负责人的提示词指向 intent.md，点名约束，并要求标出关切点。先手动跑一遍，再将其固化为组织级的斜杠命令。进而，把“intent home 中接受 intent.md”作为触发器，用一个在合并时触发的非交互式任务来运行该环节、加载组织的 skills，并将 spec.md 作为 PR 提交（阶段 5：部署中的 CI/CD 实践会涵盖其管道细节）。从那以后，产品负责人的第一次介入就是评审。
• 同一位产品负责人将规格与想法对照评审：规格是否解决了所陈述的问题？intent.md 中的待解决问题是被回答了，还是被延续了下去？
• 先处理被标出的关切点，因为它们正是分析师会升级的问题。产品负责人在工程师看到规格之前，与相应的策略负责人逐一解决。
• 将 spec.md 与 intent.md 一同提交。这对文件记录了“被要求了什么”与“决定了什么”。
• 产品负责人决定规格与 intent 是否进入构建，对组织归类为更高风险的任何事项咨询技术负责人。这一决定总是由人类队友做出，而接受规格，正是启动阶段 3：构建中“规划模式”实践的起点。

实际效果（提示词）

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

治理考量

策略不再是在数周后的评审中才被发现，而是在规格被撰写的同时就被读取并应用。组织的 skills 作为对规格的约束被施加。spec.md、生成它的提示词，以及生效中的 skill 版本，全部被记录在版本控制中。产品负责人签核规格，并将标出的关切点路由给对应的策略负责人。

构建（Build）

以 Claude Code 规划模式作为默认起点

工程师在规划模式（plan mode）下开启 Claude Code 会话，把阶段 2：设计中那份被批准的 spec.md 交给 Claude，让它对自己进行“访谈”，并在计划上反复迭代，直到工程师满意。

如何执行

• 工程师在规划模式下与 Claude 开启会话。
• 工程师把 intent.md 与 spec.md 交给 Claude，要求它产出一份实现计划，点名会变更的文件、工作顺序，以及证明它有效的测试。
• 对计划进行拷问：问它这次变更可能破坏什么、哪一步风险最高、它选择了哪些其它备选方案。
• 反复迭代，直到一个从未看过这段对话的工程师也能仅凭计划独立完成变更。
• 把被批准的计划作为 plan.md 提交。计划加入审计线索，而 PR 评审实践（阶段 5：部署）会将最终的 diff 与之对照。
• 接受计划，让 Claude 去实现。有了扎实的计划，实现往往一次就过。
• 当实现偏离计划时，在同一笔提交中更新 plan.md。可以考虑用一个 hook 来强制二者同步。

实际效果（plan.md）

# Plan: claims status self-service (from intent.md 2026-06-02)
 ## Files that change
 portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
 claims-api/tests/test_status.py
 ## Order of work
 1. Add the status endpoint behind existing auth.
 2. Panel against the endpoint.
 3. Wire into the portal nav.
 ## Risks
 The claims-core API rate-limits at 50 rps; the panel must cache.
 ## Proof
 test_status.py covers the four claim states; screenshot matches the
 approved mock.

治理考量

设计评审发生在任何代码生成之前——此时改变方向还只是编辑一份文档的事。规划模式本身就能强制执行这一点，因为 Claude 在工程师接受计划之前无法编辑文件。计划及其修订都会被记录，并注明是谁接受了它。常规变更由工程师批准，而组织归类为更高风险的任何事项则上报给技术负责人或架构师。

Claude Code 自动模式

Claude Code 也可以运行在自动模式（auto mode）下：工程师批准计划，并在满意且充分迭代后，Claude 便自行应用每一处变更，而无需逐次编辑都征求确认。随着后续 Play 中的护栏日趋成熟（调校良好的 CLAUDE.md、把策略编码进来的 skills、阻止不安全动作的 hooks，以及 Claude 可以运行的测试套件），自动接受会成为日常工作的默认方式：一份紧凑的 spec.md、一个小的爆炸半径（blast radius），以及测试已经覆盖的代码。

转变的方向，正从“用户盯着智能体做编辑、审查其动作”，走向“在更长自主会话之后评审产物”。自动接受模式进一步借助 worktree 实现了个人与团队层面的并行，也是阶段性运行 SDLC 并实现闭环（如阶段 6：运维所述）的基础。

遗留系统与事实来源

这适用于流程所产生的每一个产物。现有的 SDLC 流程很可能已经在跟踪产物，只是不用 markdown 文件。工作项可能在 Jira 里，需求在一个内置监管可追溯性的工具里，设计在 Figma 里，变更审批在变更委员会那里。这些系统很难被替换，因为审计方与监管方已经认可它们，其他团队也依赖它们——所以 AI-Native SDLC 必须围绕既有的东西来适配。在向 AI-Native SDLC 迁移时，对于流程所产生的每一个产物，都要指定一个系统作为“事实来源（source of truth）”，其余一切只持有副本或对原件的链接。下面的配置即体现了这一点。

CLAUDE.md

CLAUDE.md 为 Claude 提供一位新成员所需具备的上下文，涵盖约定、命令、架构，以及团队最常犯的错误。那些曾经存在于人脑和 wiki 里的知识，变成了一份文件——智能体在每个会话开始时都会读取它，由整个团队共同维护，并在每次出错时被迭代更新。

如何执行

• 在代码仓库中运行 /init。Claude 会根据它发现的内容生成一份初始 CLAUDE.md。
• 把生成的文件精简到“新人第一天就需要”的程度。保留构建、测试与 lint 命令，重要的约定，以及 Claude 反复出错的地方。
• 将 CLAUDE.md 以 git 形式检入仓库根目录，这样整个团队共享同一版本，变更也像代码一样被评审。
• 这里有个好用的经验法则：当 Claude 犯了两次同样的错误，就把纠正写进 CLAUDE.md。
• 把它控制在一页以内，因为 Claude 会在会话开始时读取全部内容，任何陈旧的内容都只是在白白占用上下文。

实际效果（CLAUDE.md）

# Payments service
 ## Commands
 - Build: make build
 - Test: make test (unit), make itest (integration, needs docker)
 - Lint: make lint (runs in CI; fix before pushing)
 ## Conventions
 - Java 21, Spring Boot 3. No new Lombok.
 - Money is always BigDecimal, never double.
 - Every endpoint needs an integration test in src/itest.
 ## Architecture
 - api/ holds REST controllers, core/ holds domain logic,
   adapters/ talks to external systems.
 - Kafka events are defined in schemas/; never edit generated classes.
 ## Things Claude gets wrong
 - Do not bump dependency versions; the platform team owns them.
 - The legacy v1/ package is frozen; changes go in v2/.

治理考量

CLAUDE.md 受版本控制，因此智能体所遵循的指令是可评审、可审计的。团队约定通过该文件施加，对它的变更被记录在 git 历史中，并由代码所有者（code owner）在 PR 评审中批准。

作为机构知识沉淀的 Skills

Skills 是组织将其机构知识变得“可操作”的方式。指令是显式的、受版本控制的、被广泛应用的，并在策略变更时集中更新。经验法则：为“必须被一致应用”的机构知识编写 skill；不要为“应属于 CLAUDE.md 或提示词”的组件编写 skill。

如何执行

• 挑选一块今天执行得不一致的知识。它可以是一条安全标准、一个 API 设计约定，或一条品牌规则。
• 把它写成一个 skill——一个包含 SKILL.md 的文件夹，其 frontmatter 说明触发条件，正文说明该怎么做。工程师基于策略负责人的“事实来源”来编写，并可请 Claude 协助。
• 把 skill 放在仓库的 .claude/skills/<name>/ 下，使其随代码一同发布；或者通过 plugin 在组织范围内分发。
• 测试 skill 是否能正确触发。用不同方式让 Claude 去做相关任务，并确认每次都加载了该 skill。
• 当策略变更时，修改 skill，并由策略负责人签核这次变更。
• 工程师在下一个会话中会自动拿到新版本。

实际效果（.claude/skills/secure-api-review/SKILL.md）

---
 name: secure-api-review
 description: Apply the API security standard. Use whenever creating or
 modifying an external-facing endpoint, reviewing API code, or
 generating an OpenAPI spec.
 ---
 # Secure API review
 When you create or change an API endpoint:
 1. Authentication: every endpoint requires the gateway JWT;
    no anonymous routes outside /health.
 2. Input validation: validate request bodies against the OpenAPI
    schema and reject unknown fields.
 3. Audit: every state-changing endpoint emits an audit event with
    actor, action, entity and timestamp.
 4. Data classification: fields tagged pii in the schema must never
    appear in logs or error messages.
 Run scripts/check-endpoints.sh and include its output in your summary.

治理考量

Skill 是一种控制手段，尽管是“建议性”的。它让 Claude 在代码被写就的同时“大概率”会应用该策略，但没有任何东西能强制某个会话遵守它。一条“必须始终成立”的策略，需要在 skill 背后有确定性的东西，例如一个阻止该动作的 hook，或是在 PR 处重新检查该策略的评审环节。Skill 让违规变得罕见，hook 则让其几乎不可能发生。Skill 的调用被记录在会话轨迹中，策略负责人像审代码一样评审 skill 的变更。

作为构建期护栏的 Hooks

Skill 是建议性的控制，而 hook 则是它背后确定性的那一层。Claude 的大部分动作都是实现阶段的文件编辑与 shell 命令，因此构建阶段正是 hook 最常被触发的地方。

构建期 hook 可以：

• 阻止对受保护路径（如生成的类或某个被冻结的包）的编辑；
• 在文件编辑后运行格式化与 lint，使漂移永不发生；
• 把凭证挡在 diff 之外。

任何“策略必须无条件成立”的 skill，都要用 hook 来兜底。Hook 会在每一个匹配它的动作上运行，因此构建期 hook 应当快、且限定在“发生变更的那个文件”上。更重的检查（如完整测试套件）应放在提交或 PR 处。

需要向人类请求批准的 hook，应当和阶段 5：部署中的那些关卡放在一起——因为在构建期间弹出一个批准提示，会把一个人重新推回所有并行运行会话的关键路径上。

并行会话与子代理

一名工程师可以同时驱动好几条工作流。

并行会话（parallel session）是另一个完整的 Claude Code 实例，在自己的 git worktree 中处理一项独立任务。每个独立会话对其它会话一无所知，而驾驭它们的工程师，是它们唯一共享的东西。

子代理（subagent）在单个会话内部作为一个有边界的助手运行，拥有自己的上下文窗口与工具限制，适合那些在多个任务中反复出现的作业——例如验证应用是否按预期运行。

并行会话提高了工程师可同时在途的任务数量，而子代理让每个会话专注于自己的任务。工程师的工作，就是驾驭并评审它们全部。

如何执行

• 工程师把工作拆成“触及不同文件”的任务，借助规划模式实践（阶段 3：构建）中的计划来识别工作在何处相互独立。共享文件的任务，放在单个会话中依次运行。
• 每个并行任务都有自己的 worktree，例如在某个终端运行 claude --worktree feature-auth，在另一个终端运行 claude --worktree fix-rate-limit。Worktree 是各自分支上的独立检出，能避免会话在文件上相撞。
• 两到三个会话是一个合理的起点。实际的 ceilings 取决于一个人能 proper 评审多少条流，所以只有在评审跟得上的时候才增加会话。
• 把重复性的工作变成子代理，定义为 .claude/agents/ 下的 markdown 文件，每个都带有名称、使用时机说明，以及可触及的工具。例子包括：在主代理完成后剥离多余复杂度的“代码简化器”、运行应用并检查行为的“验证器”、探索代码库并回报而不冲爆主上下文的“研究员”。把这些定义检入 git，让整个团队共享。

实际效果（.claude/agents/verifier.md）

---
 name: verifier
 description: Runs the app and checks the change works before the session
 reports done
 tools: Bash, Read
 ---
 Start the app with make run. Exercise the changed behavior and the two
 nearest neighboring flows. Report what you ran, what you saw, and any
 behavior that does not match plan.md. Do not fix anything; report only.

治理考量

更多的会话意味着更多的产出，因此控制手段必须来自仓库中的配置。那里的 hooks 与权限设置对所有会话生效，而某个会话做过什么，会被记录并归因到运行它的工程师身上。

给 Claude 一个反馈闭环

永远给 Claude 一种自我验证工作的方式，无论是测试、构建，还是截图 diff。会话会在工程师看到之前，自行检查并修正自己的错误。

不要把反馈闭环与验证器子代理（阶段 3：构建）混为一谈。反馈闭环贯穿整个任务、运行次数与工作量相当；而验证器子代理，是在会话认为工作已完成时、用一个新的上下文窗口打包最终检查的一种方式——这样结论就不会被“产生这段代码时的假设”所影响。

如何执行

• 如果今天检查工作要一连串命令加一些环境知识，就把它包成一个单一目标，例如 make test 或 npm test，失败时以非零退出。
• 在 CLAUDE.md 的 Commands 一节中，列出每条命令及其健康输出的示例。
• 给出一个目标并使其可量化，让 Claude 无需请教你就能检查工作，例如：“test_status.py 中所有测试通过”“截图与所附稿子一致”，或“端点返回 200 并带有新字段”。
• 对于缺陷修复，先写失败的测试。让 Claude 把该 bug 写成一个测试、运行它，并确认它因你预期的原因而失败。提交该测试。只有在这之后，才让 Claude 在不改动测试的前提下让它通过，并由最后一步的“测试文件 hook”来强制执行这一限制。一个在修复之前就存在、且智能体无法重写的测试，就是 bug 已消除的证据。
• 对于 UI 工作，用视觉检查来闭合循环。给 Claude 一个浏览器或截图工具，把稿子交给它，让它迭代。实现、截图、对比、调整。两到三轮是常态，且结果应逐轮变好。
• 把验证变成“完成”的一部分。指令写在 CLAUDE.md 中。在报告任务完成前运行测试，并展示输出。
• 最后，循环本身也需要被保护，因为一个修正代码的智能体绝不可以削弱针对那段代码的检查。一个在修复任务期间阻止编辑测试文件的 hook 就能做到这一点。替代方案是在评审时检查 diff，并拒绝任何触碰测试的变更。

实际效果（CLAUDE.md 验证块）

## Verifying your work
 - Build: make build (must finish with "Build succeeded")
 - Test: make test (all green; never skip or delete a failing test)
 - Lint: make lint (zero warnings)
 Run all three before reporting any task complete, and paste the output.
 If a test fails, fix the code, not the test.

治理考量

强制执行的是什么：在报告任务完成前的验证，以及“修复期间禁止智能体编辑测试文件”的阻断——在希望其得到保证的组织中，二者都以 hook 实现。证据是什么：Claude 运行并粘贴的 make test 字面输出、构建日志，或截图 diff，因此证据来自工具链本身。记录在哪里：在会话转录中（OpenTelemetry 导出会转发到组织的可观测性栈），以及 PR 的检查运行中（评审者与任何后续审计者都能看到）。谁批准：评审 PR 的代码所有者，由于机械性证据已经附上，他可以把注意力集中在意图与风险上。如何衡量：先行指标——智能体所写变更的首次 CI 通过率（CI 系统已支持）；滞后指标——每个 PR 的评审耗时（来自 PR 元数据，一旦测试接手了原本由评审者做的事，它应下降），以及来自事件追踪器的变更失败率。

在 CI 中持续做评估

评估应当被视作一套“活”的套件。随着模型进步，曾经能区分优劣的用例会逐渐失效，必须从持续监控中补充新的用例。

根据用例不同，一些团队可能更倾向于按固定节奏离线运行这些评估，而不是在每次变更时都跑。下面的步骤针对的是“持续评估”。

如何执行

• 平台工程师从近期工作中收集 20 到 50 个真实任务，及其预期/可接受的结果。
• 把每个任务写成一个 eval，即“提示词 + 定义‘可接受’的检查项”（测试通过、lint 干净、行为不变、遵循策略）。
• 该套件在 CI 中按日程、并在 CLAUDE.md、skills 或 hooks 发生任何变更时非交互式运行——因为这些配置在引导智能体，理应获得代码所享有的回归测试。
• 把配置变更用结果来设门。一个导致通过率下降的 skill 变更，在合并前要先被评审。
• 每起生产事件都对应一个 eval，由负责该事件的团队编写，并作为回归测试留在套件中。

实际效果（.github/workflows/agent-evals.yml）

name: Agent evals
 on:
   pull_request:
     paths: [ 'CLAUDE.md', '.claude/**' ]
   schedule:
     - cron: '0 2 * * *'
 jobs:
   evals:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
       - run: npm install -g @anthropic-ai/claude-code
       - name: Run eval suite
         env:
           ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
         run: |
           for eval in evals/*.json; do
             claude -p "$(jq -r '.prompt' $eval)" \
               --allowedTools "Read,Edit,Bash(make test)" \
               --output-format json > result.json
             ./evals/check.sh "$eval" result.json
           done

治理考量

评估给 QA 提供了一道能跟得上智能体产出的门。通过率阈值作为合并检查被强制执行，运行被记录以便随时间比较结果，而拥有该配置变更的团队负责批准它。

部署（Deploy）

AI 参与 PR 评审闭环

Claude 既给出评审，也接收评审。它依据组织策略评审 incoming 的 PR，并对自己 PR 上的评审意见作出回应。这让工程师能把注意力放在 PR 评审中的“行为”上——归根结底就是判断意图与风险。

如何执行

• 托管的 Code Review 服务是最快的上手方式。管理员启用它并选择代码仓库。当你需要控制流水线、或希望 API 调用经由自己的云协议路由时，可在自己的 CI 中用 claude-code-action 运行评审（CI/CD 实践会涵盖其管道细节）。
• 技术负责人把评审策略写成仓库根目录下的 REVIEW.md，按组织关心的“评审轮次（passes）”划分：bug 与逻辑错误；安全与漏洞；对照规格的合规性（来自需求实践的 spec.md、来自规划模式实践的 plan.md，以及设计原则）。REVIEW.md 还定义了什么是“重要（Important）”而非“吹毛求疵（Nit）”，以及什么该跳过。
• 技术负责人设定人类阈值。发现项本身不会批准或阻塞一个 PR，分支保护（branch protection）仍要求代码所有者批准。想要基于发现项来给合并设门的平台工程师，可以读取检查运行以机器可读计数形式发布的严重度统计。
• 当评审者或作者在某个评审意见上 @claude 时，Claude 会处理该意见并推送修复。PR 线程同时记录了“请求”与“变更”。这个修复循环通过 claude-code-action 运行。在托管服务中，评论 @claude review 会请求一次全新评审；而对于 Claude 自己开启的 PR，可更进一步让 Claude “看护”该 PR 直至合并。团队把这一循环包进一个自定义斜杠命令：它会扫一遍 PR 上未解决的评审意见与失败的 check，处理它们并推送修复，直到 PR 变绿、只差代码所有者批准。
• 评审发现项会回流进 CLAUDE.md。当某个错误第二次被评审标记时，纠正会作为那次评审的一部分写进 CLAUDE.md；而由于评审会读取 CLAUDE.md，该错误从下一个 PR 起就会被抓住。评审也会在变更让 CLAUDE.md 过时时报出。
• 技术负责人每月通过给发现项打分来调优设置，让评审者进步，并在 REVIEW.md 中给 Nit 数量设上限。生成路径与 CI 已经在强制的内容被排除在外。

实际效果（REVIEW.md）

# Review instructions
 ## Passes
 Run three passes and tag each finding with its pass:
 - Bugs: logic errors, broken edge cases, subtle regressions
 - Security: injection risks, authentication gaps, PII in logs
 - Compliance: the change matches spec.md, plan.md and our design principles
 ## What Important means here
 Reserve Important for findings that would break behavior, leak data
 or breach a policy. Style and naming are nits.
 ## Cap the nits
 Report at most five nits per review; summarize the rest as a count.
 ## Do not report
 Generated files under src/gen/ and anything CI already enforces.

治理考量

职责分离得以保留，因为写下代码的智能体没有任何途径去批准它。REVIEW.md 中的评审策略被应用于所有 PR，而发现项、修复、打分与批准都被记录在 PR 历史中，因此 PR 本身就是审计记录。批准来自通过分支保护的人类，并受到发现项的 informed。

作为审批闸门的 Hooks

构建阶段把 hook 用作护栏，在无人介入的情况下允许或阻止动作（阶段 3：构建）。Hook 也可以“询问”——暂停该动作，直到某个特定的人批准，而这正是发布门控所需要的。

这个实践位于阶段 5：部署，因为发布门是最清晰的案例；但 hook 并不局限于部署：它在 Claude 行动的任意位置都会运行。例如，在阶段 3：构建中，hook 可以在没有变更工单的情况下阻止对迁移与基础设施的编辑；在阶段 4：测试中，hook 可以阻止智能体在修复任务期间编辑测试文件。

如何执行

• 工程领导层联合变更管理与合规，列出必须保留的人类审批闸门，例如变更管理签核、发布授权，以及对受保护路径的编辑。
• 平台工程师把每个闸门表达为一个 hook——一个在 Claude 行动之前运行、可以允许、询问或阻止的脚本。
• 团队 hook 放在 git 中的 .claude/settings.json 里，不可协商的 hook 则放在平台或 IT 管理员拥有的托管设置（managed settings）中，个人工程师无法将其关闭。
• 阻断应当“自我解释”，因此当 hook 阻止某个动作时，原因与获批路径会出现在 Claude 的输出中。

实际效果（.claude/settings.json）

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
        ]
      }
    ]
  }
}

以及闸门本身（.claude/hooks/production-gate.sh）

#!/bin/bash
 # Production deploys require a named release authorization
 cmd=$(jq -r '.tool_input.command' < /dev/stdin)
 if [[ " $cmd " == *"deploy"* && " $cmd " == *"production"* ]]; then
   if [ -z " $RELEASE_APPROVAL " ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
 fi
 exit 0

治理考量

Hook 就是审批闸门。闸门条件对每个人、每次都强制执行。允许与阻止的决策都带有时间戳被记录。闸门还定义了“什么算作批准”——无论是一张被批准的变更工单，还是发布经理的签核。

面向受监管企业的托管设置

由平台团队通过 MDM 或管理控制台部署；工程师无法编辑或覆盖其中任何内容。

{
  "permissions": {
    "deny": [
      "Read(.env*)", "Read(./secrets/**)",
      "WebFetch", "Bash(curl *)", "Bash(wget *)"
    ],
    "allow": [
      "Bash(git *)", "Bash(make build)",
      "Bash(make test)", "Bash(make lint)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": { "allowedDomains": ["git.internal.example.com",
      "registry.npmjs.org"] },
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" }
      ],
      "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ]
    }
  },
  "allowManagedHooksOnly": true,
  "disableSideloadFlags": true,
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "example-corp/approved-plugins" }
  ],
  "requiredMinimumVersion": "2.1.193"
}

用控制术语来说：permissions.deny 让密钥不进入智能体的上下文，并阻断通过工具发起的任意网络出口；permissions.allow 预批准安全的内部循环，使 deny 列表不至于演变成“提示词疲劳”。disableBypassPermissionsMode 加上 allowManagedPermissionRulesOnly，意味着任何工程师、项目文件或命令行 flag 都无法放宽规则。沙箱（sandbox）堵住了权限无法覆盖的缺口——工具层对 WebFetch 的 deny 挡不住 shell 命令触网，而 OS 级的域名白名单能直接阻断出口。failIfUnavailable 与 allowUnsandboxedCommands 让沙箱成为一道闸门：当沙箱无法初始化时，Claude Code 拒绝启动。

CI/CD 集成与部署

在 CI/CD 流水线中非交互式运行 Claude Code，对执行做沙箱隔离以便长时智能体安全运行，通过 MCP 集成把部署能力暴露出来，并在智能体真正需要之前先把回滚路径演练纯熟。

如何执行

• 平台工程师从只读的判断类步骤入手。在流水线任务中用 claude -p 来给失败的构建做分诊、总结一个 flaky 测试，或起草变更日志。
• 把写步骤加在既有闸门之后，用于“修 lint、更新生成文档，或通过 @claude 提及来处理评审意见”这类任务。智能体写下的任何东西，都经由分支保护以 PR 形式到达，且没有任何直达 main 的路径。
• 执行被沙箱化。智能体任务在受网络策略约束的容器中运行，使用短时效的限定作用域令牌，默认不持有任何生产凭证。
• 通过 MCP 把部署能力暴露出来。部署、状态与回滚变成工具，按环境限定作用域，因此智能体的部署权限是一份“允许清单”，而非一份带着凭证的 shell 脚本。
• 按环境划分自主度。在开发环境，智能体自由部署；在生产环境，智能体准备发布、由发布经理授权，并由一个 hook 强制生产闸门。预发环境介于二者之间。
• 回滚应当是流水线中被演练得最充分的一条路径——一条智能体可以运行、并在预发环境定期演练的命令。闭环实践（阶段 6：运维）会在某个控制带被突破时调用该回滚，因此它必须提前被验证过。

实际效果（流水线步骤）

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

治理考量

治理原则在于：智能体可以行动到生产闸门为止，但无法越过它。下面的控制手段都在强制执行这一原则。

• 分支保护把智能体写下的任何东西变成 PR，没有直达 main 的路径。
• 生产部署 hook 会阻塞发布，直到一位具名的发布经理授权。每次非交互式运行都以其自身的身份行动，因此流水线日志把“智能体做了什么”与“触发它的工程师做了什么”区分开来。
• 按环境的权限层级，设定了智能体在通往闸门途中可以做多少。

运维（Maintain）

运维与闭环

至此，我们讨论了如何把 Claude 加入 SDLC 的每个阶段，而每个阶段都需要人类来启动最初的步骤。然而，这个阶段把焦点转向了“让 Claude 自主运行以闭合循环”。

例如，一个持续运行的监控智能体，可以借助“某张 bug 工单被提起”这一事件，创建一份 intent.md，并流经需求、计划、构建、测试与评审各阶段。阶段 6：运维以无头（headless）方式运行，阶段之间设有一个独立的置信闸门——一个确定性检查，或一个对抗性的评审智能体——来决定上一阶段的产出是继续，还是升级给人类。

闭环

一个确定性脚本监控生产环境，并在某个控制带被突破时调用 Claude。对“突破”的监控，是“循环自主运行”这一模式一个很好的例子；而本阶段末尾的 Claude Tag（公开 beta）一节，则涵盖了“经由不同渠道到来的工作”。

如何执行

• 服务所有者或平台工程师挑选一个具有稳定滚动基线的指标，例如 CI 测试失败率、部署后 5xx 率，或 PR 周期时间。
• 他们编写检测脚本，通常是基于滚动窗口的均值与标准差、并配以后文规则（Western Electric 或类似），让控制带既能捕捉缓慢漂移，也能捕捉尖峰。脚本受版本控制并有单元测试，检测完全确定性，不涉及任何模型。
• 响应层级定义在受版本控制的配置中（即下文的 bands.yaml）。在 1σ 时脚本只记录日志；在 2σ 时调用 Claude 以只读方式做诊断；在 3σ 时 Claude 可以行动，但只能通过“向评审闸门开启一个 PR”或“触发一个预先批准的 runbook”来行动。
• 触发层可以是 GitHub 或 GitLab 中的定时工作流、来自既有监控栈的 webhook，或网络内部的 Cron Job。Claude 以无状态方式运行——要么是 CI runner 上的一个非交互式步骤，要么是沙箱容器中的一个 Agent SDK 服务——而 CI/CD 实践涵盖了部署与模型访问选项。由于运行是无状态、非交互式的，一个循环可以在无人启动的情况下开始与结束。
• 智能体以阶段 1：规划中的 intent.md 格式写下它的诊断，覆盖异常及其证据、预期结果、受影响的系统，以及任何待解决问题。从那里起，该发现项就像其它任何东西一样流经流水线。
• 服务所有者或值班工程师对队列做分诊，把面向产品的发现项路由给产品负责人。立即修、排期，或驳回。驳回会调优控制带，并帮助降低噪声。
• 当某个修复上线时，为该事件添加一个 eval（即持续评估实践），以确保此类问题在日后得到防护。

实际效果（例如：监控 CI 测试失败率的 bands.yaml）

metric: ci_test_failure_rate
 baseline: rolling_30d
 rules: western_electric
 tiers:
   1sigma: { action: log }
   2sigma: { action: diagnose,
             tools: "Read,Grep,Bash(gh run view *)" }
   3sigma: { action: propose,
             routes: [ pull_request, runbook:rollback-deploy ] }

治理考量

层级边界由受版本控制的配置强制执行，权限与托管设置拒绝对生产的访问。调用、发现项与分诊决策都带时间戳被记录。服务所有者对发现项做分诊与批准，由此产生的变更走正常的 PR 评审闸门，而智能体可能触发的 runbook 都是事先批准过的。

示例

• 当 CI 测试失败率突破 3σ，智能体隔离那个 flaky 测试或开启一个 revert PR，由评审闸门决定。
• 当部署后 5xx 率在窗口内存在部署的情况下突破 3σ，智能体触发既有的回滚流水线。
• 当 PR 周期时间触发了漂移规则，智能体为工程领导层写一份报告——这说明该 harness 对“流程指标”与“生产指标”同样有效。

Claude Tag：随叫随到的 Claude

事件也可以经由其它渠道到达，例如 Slack 或 Teams 这类职场沟通应用。事件可能表现为“晚上 10 点在某个事件频道的紧急修复 Slack 消息”，而现在可以被立即处理。Claude Tag（目前为公开 beta，已在 Slack 中可用）让 Claude 以自身身份成为这些频道的成员，因此每起新事件都有一位第一响应者，而响应本身也成为循环的一部分，并成为未来事件的记忆。

对话与机构知识留在频道中，频道内的任何人都能引导并行动于该响应。任何团队成员都能检验假设、探索新选项，并借助频道历史实时调查，从而增强可审计性。通过对 MCP 的访问，Claude 验证指标是否回到基线并在线程中确认，再把事后复盘写入一份受版本控制的“经验教训”文件，供未来的调查读取。

事件并非 Claude Tag 接手的唯一工作。经由 MCP 在某个工单上被 @，或在频道中被问到时，Claude 会以同样的方式对 work 做分诊。一个小的、边界清晰修复，会作为 PR 穿过评审闸门到达；任何更大的事情，则被写成 intent.md 交给阶段 1：规划——到那时，循环开始自我喂养。

沟通渠道就是审计线索：请求、诊断、人工授权与修复，全部留在事件被处理的那个渠道里。

dolphin-flow-harness：把 playbook 理念工程化落地

上文的 Playbook 给出了 AI-Native SDLC 的核心思想——用“已提交的产物（committed artifact）”把各阶段串成自动触发、人类在环的闭环。dolphin-flow-harness 是我们内部对这套理念的多主机工程化实现：一个面向多主机的 AI 编码能力资产管理器，让“环”落到 G1–G7 闸门、让“提交物”落到 state file 与并发契约。

整体分为五层，自上而下是控制流、自下而上是资产回流，L4 质量层横切各闸门做兜底：

• L1 编排层（dolphin-flow.js）：只控控制流（顺序 / 扇出 fan-out / 暂停·恢复 / 预算），不感知业务细节。
• L2 协议层（每关一个 skill）：为 G1–G7 每个闸门定义协议契约——步骤、产物路径模板、自检清单。
• L3 执行层（agents/*.md）：按协议实例化执行，绑定角色身份、工具权限与边界。
• L4 质量层（gates，横切）：以 hook 自治门禁、skill 自检、schema 保底，横切各闸门做质量兜底。
• L5 资产层（artifacts）：沉淀产物（docs/、状态文件、memory），状态回读喂给 L1 形成闭环。

支撑这套五层架构跑通的三个关键机制：

• workflow：workflow 各节点自带 gate，做 pauseAt 门禁检查，人类以 HITL（Human-in-the-Loop，人在环）方式在关键节点介入与放行。
• 单源事实（state file）：用 .claude/state/dolphin-flow/*.json 记录每一阶段的产物与门禁结果，作为唯一事实源。
• 并发隔离：通过 modifies:[] 声明与 serial_group 批次，隔离同一文件的并发写入，使得“每个阶段提交可审计产物、下一阶段读取并触发”的闭环可以跨多主机可靠运行。

dolphin-flow-harness · 五层架构多主机 AI 编码能力资产管理器：编排—协议—执行—质量—资产的工程化落地控制流资产回流质量横切L1编排层dolphin-flow.js · 只控控制流，不感知业务细节顺序扇出 fan-out暂停·恢复预算调用L2协议层每关一个 skill（G1–G7 每闸门一份协议契约）步骤产物路径模板自检清单指导L3执行层agents/*.md · 按协议实例化执行角色身份工具权限边界门禁校验L4质量层gates · 横切各闸门，做质量兜底hook 自治门禁(G1)skill 自检schema 保底放行·写入L5资产层artifacts · 沉淀产物 + 状态回读，喂给 L1 闭环docs/ 产物状态文件memory状态文件：.claude/state/dolphin-flow/*.json（单源事实）状态回读 · 闭环L4 横切校验dolphin-flow-harness 五层架构：编排—协议—执行—质量—资产。控制流自上而下、资产回流自下而上，L4 质量层横切校验各闸门。