AI原生SDLC：Claude驱动的开发部署闭环

当App Store销售额迎来十年来首次下滑时，一个时代正式落幕——我们所说的"香草时代"，也就是依赖传统流水线式软件开发的模式，已经走到了尽头。

软件开发生命周期（SDLC）指的是从一个创意到上线产品的完整过程，传统模式通常被拆分为规划、设计、构建、测试、部署、运维六个独立环节，每个阶段都有专人负责，依靠文档、工单和签批完成跨环节流转。

如今AI代码生成工具已经大幅提升了开发速度，但绝大多数团队的开发流程并没有同步升级，传统的审批门禁、代码审查、人工交接和合规策略，反而成了效率提升的阻碍。

传统SDLC的设计前提是代码编写和实现是最耗时耗钱的阶段，因此每个环节都设置了严格的管控流程来确保质量。但当AI能够快速生成代码后，这个前提已经不再成立：PRD文档、估时会议、产品安全审查这类环节，反而成了拖慢整体进度的瓶颈。

当代码不再是开发瓶颈，构建速度远超传统流程的承载能力时，三个关键变化开始显现：

以安全审查为例，安全团队的人力配置是按照人类代码产出量设计的，但当AI将代码产出量提升数倍后，要么审查队列越积越长，要么代码未经审查就上线，这两种结果对于受监管的组织来说都无法接受，安全和合规检查必须能够跟上AI的开发速度。

AI原生软件开发全流程

AI原生SDLC是一套重新设计的开发流程，它将传统的管控目标与现代AI执行能力相结合，把原本线性的流程转变为循环模式，让AI嵌入到每个环节当中。这种新模式推动了自动化交接和后续步骤的自动触发，解决了传统SDLC各阶段之间手动、笨重的衔接问题。

AI原生SDLC的核心概念是提交的产物：每个阶段结束时，都会向版本控制系统中写入一个标准化产物，包括intent.md、spec.md、plan.md、代码变更及测试、带审查结论的PR、事故记录等，下一个阶段将从读取该产物开始工作。

在早期阶段，主要的产物是Markdown格式的文档，因为产品负责人和AI代理都能够读取和处理这些内容。从构建阶段往后，产物则转变为代码及其相关记录。这条提交链本身就构成了完整的审计链，可以清晰记录谁提出了需求、AI生成了哪些内容、谁批准了最终变更。

在这种模式下，人类仍然对所有需要判断力的决策负责，人们的注意力会随着需要审查的产物一起转移，而不是全程参与每个细节。

全流程各阶段实践

本指南的核心内容按照软件开发生命周期的六个非线性阶段分组，覆盖完整开发流程。每个阶段的实践都包含：核心变化、启动方式、具体实施步骤、治理考量、效果衡量方法。

这些实践步骤是模块化的，组织可以根据自身需求优先改造不同阶段。一个阶段在提交产物时结束，此次提交会自动启动下一阶段工作。通过审核的intent.md会触发需求和设计环节，通过审核的spec.md会启动规划模式，合并的PR会触发流水线部署，当线上监控指标突破控制阈值时会自动生成新的intent.md，让整个流程形成闭环。

初始阶段可以手动触发每个环节，最终目标是让每个通过审核的产物自动触发下一个流程门禁。此时人类的注意力将集中在门禁审批上，只需要审查AI标记出来的重点内容，无需从头开始每个阶段的工作。

用intent.md捕获开发意图

intent.md是整个软件开发流程的起点，可以通过多种方式触发：当团队成员有了新的创意、收到用户工单，或是系统告警触发了事故修复需求时，都可以创建对应的intent.md文档。

当一个人有了开发想法时，可以与AI助手一起头脑风暴，产出一份Markdown格式的初步方案。在传统流程中，接下来需要说服产品团队帮忙撰写正式文档，但AI生成的初步方案本身就是人类可读且可版本控制的，可以直接供下一阶段使用。

这部分的搭建是一次性的工作，由平台或工程团队完成。仓库搭建完成后，没有Git使用经验的人员不需要直接操作Git，可以通过连接到代码仓库的连接器，让AI助手在专属平台中代为提交Markdown文件。

具体执行步骤

1. 发起人用自己的语言向AI助手描述问题，不需要使用正式的专业术语
2. 通过多轮头脑风暴让想法具体化，AI助手会提出分析师会问的典型问题，比如项目范围、目标用户、约束条件、成功衡量标准等
3. 让AI助手按照组织统一模板将讨论结果整理为intent.md文件，模板可以预先编码为可复用的技能
4. 发起人修正AI助手理解有误的内容
5. 将最终的intent.md提交到共享代码仓库，系统会自动记录作者和提交时间戳

一份典型的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文件，其中包含了完整的作者信息、时间戳和修订历史，记录在Git仓库的提交历史中。产品负责人负责审批该文档，接受或拒绝的决定会被记录为合并或关闭审查请求。

需求与设计阶段

产品负责人批准intent.md后，AI助手将基于该文档生成需求和设计规格说明。这个过程会遵循组织预先定义的技能规则，涵盖品牌规范、安全要求、合规标准和用户体验设计原则。

产品负责人负责审查这份规格说明，但无需亲自撰写。该流程的目标是产出一份工程团队可以据此开展工作的详细规格文档，同时标记出需要重点关注的内容。

前端开发是最直观的例子：当intent.md通过审核后，产品负责人可以在AI设计工具中基于该文档创建界面原型，经过多轮迭代后，再导出到AI编码工具中直接进入构建阶段。

具体执行步骤

1. 产品负责人打开加载了组织预设技能的AI会话，上传intent.md文件作为参考
2. 向AI发送提示词，明确要求基于文档内容列出约束条件并标记潜在关注点，初始阶段可以手动执行，后续可以编码为组织级别的快捷命令
3. 最终可以设置为：当intent.md在仓库中被接受时自动触发该流程
4. 产品负责人对照原始需求审查生成的规格文档，先处理AI标记的关注点，在交付工程团队前，与对应策略负责人一起解决所有冲突
5. 将最终的spec.md与intent.md一起提交到代码仓库
6. 产品负责人决定spec和intent是否可以进入构建阶段，对于涉及高风险的内容，需要咨询技术负责人，该决策始终由人类做出

提示词示例

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.

治理考量

组织的技能规则会作为约束条件应用在规格文档生成过程中。这样可以避免在几周后的审查中才发现政策冲突，而是在规格编写阶段就直接应用现行策略。规格文档、生成它的提示词以及生效的技能版本，都会被完整记录在版本控制系统中。

构建阶段

以Claude Code Plan Mode作为默认起点

工程师可以在规划模式下启动Claude Code会话，上传第二阶段生成的spec.md文件，让AI助手提出问题、展开讨论并反复迭代开发计划，直到工程师对方案完全满意。

工程师可以将intent.md和spec.md一起提供给AI助手，要求生成详细的实施计划：列出需要修改的文件、工作执行顺序、验证功能正常的测试方法。同时可以质询该计划：询问这个改动可能破坏哪些现有功能、哪一步风险最高、AI为什么没有选择其他方案。经过多轮迭代后，即使是从未看过这段对话的工程师，也能够仅凭这份计划完成开发工作。

将通过审核的计划保存为plan.md文件，确认计划无误后，就可以让AI助手直接实施开发。有了扎实的计划作为基础，开发工作通常可以一次完成。

一份典型的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. Build the status display panel against the endpoint.
3. Integrate the panel into the portal navigation.
## Risks
The claims-core API rate-limits at 50 rps; the panel must implement caching.
## Proof
test_status.py covers the four claim states; screenshot matches the approved mock.

治理考量：设计审查会在任何代码生成前完成，此时调整开发方向只需要修改文档即可。Plan Mode本身就强制执行了这一流程，因为在工程师批准计划之前，AI助手不能编辑任何代码文件。

Claude Code Auto Mode

Claude Code也可以在自动模式下运行。工程师批准开发计划后，AI助手会自动逐个应用代码变更，无需每次编辑都获得人工确认。随着后续流程的防护措施成熟，比如完善的CLAUDE.md文件、编码了策略的技能规则、拦截不安全操作的钩子、AI可以独立运行的测试套件等，自动接受变更将成为常规开发的默认模式。

此时团队的注意力重心将从"监督AI执行每一次编辑"，转变为"在较长的自主会话后审查最终产物"。

CLAUDE.md文件

CLAUDE.md文件相当于给AI助手的新员工入职指南，包含了团队的代码规范、常用命令、项目架构、常见错误等信息。原本存储在工程师脑海中和Wiki上的知识，现在变成了AI每次会话开始时都会读取的文件，由整个团队共同维护，每出现一次错误就迭代更新一次文档。

在仓库中运行/init命令，AI助手会从现有代码中自动生成初始版本的CLAUDE.md文件，之后可以精简到仅保留新人第一天需要了解的内容。有一个实用原则：当AI两次犯同一个错误时，就将纠正方法加入CLAUDE.md，并保持文档控制在一页以内。

一份典型的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/.

Skills：机构知识的可执行化

Skills是组织让内部知识真正发挥作用的方式。这些指令是显式的、可版本控制的、广泛适用的，当策略发生变化时可以集中更新。经验法则：需要一致性执行的机构知识应该编写为skill。

可以选择一条当前执行不一致的知识，编写为skill文件，存放在仓库的.claude/skills/目录中，随代码一起分发。当策略发生变化时，只需要修改skill文件，工程师在下一次会话中会自动获取新版本。

一个安全API审查的skill示例如下：

--- 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是一种建议性的管控手段。对于必须无条件执行的策略，需要在skill背后增加一层确定性的检查机制，比如钩子。Skill可以让违规行为变得少见，而钩子可以让违规几乎不可能发生。

Hooks：构建阶段的防护机制

Skill是建议性的管控措施，而钩子是背后的确定性防护层。AI助手在构建阶段的大部分操作都是文件编辑和Shell命令，因此这一阶段是钩子触发最频繁的环节。

构建阶段的钩子可以实现多种功能：阻止对受保护路径的编辑（比如自动生成的代码或已冻结的包）、在文件编辑后自动运行格式化和代码检查工具、防止凭证信息被提交到代码仓库等。

钩子会在每个匹配的操作上运行，因此构建阶段的钩子需要保持快速执行，并且只限定在改动过的文件范围内。更繁重的检查（比如运行完整的测试套件）应该放在提交或PR审查阶段执行。

并行会话和子Agent

一名工程师可以同时推进多个开发工作流。

并行会话指的是多个独立的Claude Code实例，各自在Git工作树中处理不同的任务。每个独立会话互不感知对方的存在，工程师是它们唯一的共享协调点。

子Agent（subagent）运行在单个会话内部，拥有独立的上下文窗口和工具权限，适合处理多个任务中重复出现的工作，比如验证应用是否按预期运行。

可以基于第三阶段规划模式生成的计划，将开发工作拆分为修改不同文件的任务。每个并行任务可以使用独立的工作树，比如在一个终端中运行`claude --worktree feature-auth`，在另一个终端中运行`claude --worktree fix-rate-limit`。初始阶段可以从两到三个并行会话开始。

可以将重复性工作封装为子Agent，定义在.claude/agents/目录下的Markdown文件中：

--- 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.

为AI助手设置反馈回路

始终要为AI助手提供验证自身工作的方式，无论是通过测试、构建还是截图对比。让会话能够自我检查工作成果，自动修正错误，然后再将结果呈现给工程师。

如果验证工作需要一系列命令和环境知识，可以将其封装为标准目标，比如`make test`或`npm test`，当验证失败时返回非零退出码。在CLAUDE.md的Commands部分列出每个命令和成功运行的示例输出。

修复bug时应该先编写失败的测试用例：让AI助手将bug复现为测试，运行该测试确认它因预期的原因失败，提交该测试用例，然后再让AI助手在不修改测试的前提下修复代码问题。一个在修复前就存在、AI无法改写的测试，就是bug已经被修复的有力证据。

反馈回路本身也需要保护：修复代码的AI助手不应该同时削弱对该段代码的检查。可以通过钩子实现，在修复任务期间阻止编辑测试文件。

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.

测试阶段

CI中的持续评估

评估（Eval）是AI原生开发模式中的阶段门禁式质量保证。具体来说，就是在AI代理的配置发生变化时运行的测试套件。当更换了新的模型或修改了提示词时，评估套件可以帮助团队确认AI代理是否还能保持原有的工作标准。

平台工程师可以从近期的工作中收集20到50个真实任务及其预期的成功结果，将每个任务编写为一个评估项：包含提示词和定义"可接受结果"的检查标准，比如测试通过、代码检查干净、行为符合预期、策略得到遵守等。每一次生产事故都应该转化为一个评估项，作为回归测试永久保留在套件中。

一个持续评估的CI配置示例如下：

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

AI参与PR审查

AI助手既可以作为审查者，也可以作为被审查者。它可以按照组织策略审查传入的PR，同时处理针对自己提交的PR的审查意见。工程师可以将PR审查的注意力集中在行为判断和风险评估上。

技术负责人可以将审查策略编写为仓库根目录下的REVIEW.md文件，分为组织关心的几个维度：代码缺陷和逻辑错误、安全漏洞、是否符合设计规格。REVIEW.md文件还需要定义什么是重要问题、什么是次要问题、以及哪些内容可以跳过审查。

当审查者或作者在审查评论中@AI助手时，AI助手会自动处理评论并推送修复代码。对于AI助手自己提交的PR，还可以进一步配置让AI助手自动看管PR直到合并：扫描未解决的审查评论和失败的检查项，自动处理并推送修复，循环往复直到PR通过所有检查、只等待代码所有者批准为止。

审查结论会反馈到CLAUDE.md文件中。当同一个错误第二次被审查标记时，应该在此次审查中直接将纠正方法写入CLAUDE.md。由于后续的审查流程会读取CLAUDE.md文件，从下一个PR开始，这类错误就会被提前捕获。

一个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.

治理考量：职责分离原则得到保持。编写代码的AI助手没有权限批准自己的代码。审查策略对所有PR生效，最终批准仍然由人类通过分支保护机制完成，决策依据是审查结论。

部署阶段

使用钩子作为审批门禁

构建阶段的钩子是开发过程中的防护机制，可以允许或阻止特定操作，无需人工介入。但钩子也可以暂停操作，直到获得特定人员的批准，这正是发布门禁所需要的功能。

工程领导层应该与变更管理和合规团队一起，列出必须保留的人工审批门禁。平台工程师可以将每个门禁表达为钩子规则：团队级别的钩子可以存放在Git仓库的.claude/settings.json文件中，而不可协商的强制钩子则由平台管理员管理，普通工程师无法关闭。

一个.claude/settings.json配置示例：

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

对应的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
  fi
fi
exit 0

治理考量：钩子本身就是审批门禁。门禁条件会在每次执行时验证，对所有用户统一生效。允许或阻止操作的决定都会带有时间戳记录。

CI/CD集成与部署

可以在CI/CD流水线中非交互式地运行Claude Code，通过沙箱化执行确保长时间运行的AI代理的安全性，通过模型上下文协议（MCP）暴露部署能力，并在AI代理真正需要使用生产环境前预先演练回滚流程。

平台工程师应该从只读的判断步骤开始：在流水线任务中使用`claude -p`命令来分类失败的构建、总结不稳定测试的原因、或起草变更日志。在现有门禁机制后增加写入步骤，AI助手生成的任何内容都需要通过分支保护机制作为PR提交，AI代理没有直接推送到main分支的权限。

通过MCP协议暴露部署能力：将部署、状态查询和回滚操作封装为工具，并按环境限定使用范围。可以根据环境分级设置自主权：在开发环境中AI代理可以自由部署；在预发布环境中需要部分人工审批；在生产环境中，AI代理只能准备发布包，最终需要发布经理授权才能完成部署。

回滚流程应该是流水线中演练最多的路径：将其封装为可执行命令，让AI代理能够运行，并在预发布环境中定期演练。

一个流水线步骤示例：

- 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

治理原则：AI代理可以完成到生产门禁之前的所有步骤，但不能越过门禁。所有AI生成的内容都需要通过PR流程。生产部署钩子会在发布经理授权前阻止部署操作。每次非交互式运行都会以AI代理自身的身份执行，流水线日志会将AI代理的操作与触发该流程的工程师操作明确区分开。

运维与闭环阶段

到目前为止，每个阶段都需要人类启动初始步骤。这个阶段的重点是让AI助手自主运行，实现整个流程的闭环。

比如，一个持续运行的监控代理可以在收到bug工单时自动创建intent.md文件，然后让需求、规划、构建、测试和审查阶段自动流转。第六阶段可以无人值守运行，各个阶段之间设置独立的信心门禁，决定当前阶段的产出是继续流转还是升级给人工处理。

实现流程闭环

可以通过确定性脚本监控生产环境，当指标突破控制范围时自动调用AI助手。

服务负责人或平台工程师可以选择一个有稳定滚动基线的指标，比如CI测试失败率、部署后5xx错误率、或PR周期时间。编写检测脚本：通常基于滚动窗口的均值和标准差，结合Western Electric或类似的异常检测规则。检测层完全由确定性逻辑组成，不涉及AI模型。

在版本控制的配置文件中定义响应分级：1σ偏差只记录日志；2σ偏差调用AI助手进行只读诊断；3σ偏差允许AI助手采取行动，但只能通过创建PR进入审查门禁或触发预先批准的运行手册。

一个bands.yaml配置示例（监控CI测试失败率）：

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] }

AI代理会按照第一阶段的格式将诊断结果编写为intent.md文件，包含异常情况及其证据、预期结果、受影响的系统、待解答的问题。从这一步开始，发现的问题将和其他任何开发需求一样，进入完整的开发流水线。

几个实际应用场景：

Claude Tag：AI随叫随到

事故响应也可以通过Slack或Teams等工作通讯工具触发。Claude Tag（目前在Slack中开放Beta测试）可以让AI助手以独立身份加入沟通频道，为每个新事故提供第一响应支持。

对话和机构知识都会保留在频道中，任何团队成员都可以测试假设、探索解决方案、实时开展调查，频道历史记录也提供了完整的可审计性。通过MCP协议访问，AI助手可以验证指标是否回到基线范围并在频道中确认，同时将事后复盘记录写入版本控制的经验文档中。

事故处理并不是Claude Tag唯一的应用场景：小型的、边界清晰的修复可以作为PR提交到审查门禁，而更大规模的工作会被编写为intent.md文件进入第一阶段流程，让整个开发循环实现自我驱动。

频道本身就构成了完整的审计链：请求、诊断、人类授权和修复操作，全部保留在事故处理的沟通记录中。

总结

随着AI模型和开发框架的不断成熟，组织现在不仅可以改造代码编写方式，更可以重构整个软件开发生命周期。

这种改造将人类的判断力放在流程的中心位置，同时兼顾了大型企业组织的治理和合规要求。本指南整合了相关团队为客户实施的真实最佳实践，希望能为你的组织提供参考。