Anthropic 实操指南：AI 原生软件开发生命周期（AI-Native SDLC）

作者：Anthropic Applied AI 团队（Jim Blackhurst, Will Steuk, Jamal Arif） 原文：The AI-Native SDLC playbook

核心矛盾：代码编写不再是研发瓶颈

过去一年中，企业借助 AI 生成代码的速度达到了前所未有的水平。然而，围绕代码构建的组织流程并没有跟上这种节奏。

许多工程团队依然保留着旧有的审批关卡、人工评审、跨团队交接和冗长流程。这使得 Claude Code 等智能体编程方案带来的生产力提升，在流程断层中被大幅稀释。

软件开发生命周期（SDLC）是将软件从构思推向生产的完整流程。绝大多数组织都遵循着类似的六个阶段：规划（Plan）、设计（Design）、构建（Build）、测试（Test）、部署（Deploy）与维护（Maintain）。

在传统模式下，每个阶段都是由特定角色独立负责的离散环节：

• 产品经理撰写需求；
• 技术架构师转化为设计；
• 工程师进行代码实现；
• QA 与合规团队验证质量；
• 发布团队安排上线；
• 运维团队监控线上运行。

工作在这些阶段之间流转，高度依赖文档传递、工单记录与人工签字审批。

这种流程之所以繁琐厚重，初衷是为了在关键节点控制风险并明确权责。但必须看清的前提是：传统 SDLC 设计的出发点，是写代码最耗时、最昂贵的时代。详尽的 PRD、估算会议以及多轮安全评审，都是为了在数周、数月甚至数季度的漫长开发周期中强制拉齐认知。

同时，传统 SDLC 的所有管控手段都默认「每一步均由人类手工执行」。而当智能体在几小时内就能生成大量代码时，原有的流程平衡被彻底打破：

1. 瓶颈向构建阶段的左右两侧转移：需求规划（Plan）、评审测试（Review/Test）与上线部署（Deploy）依然以人类步调运行，成为整体效率的新瓶颈。
2. 人工管控机制在海量代码面前失效：过去逐行审查代码是可行的，因为代码是人一行行写出来的；当大部分代码由 Agent 产出时，人工逐行审查既不现实，也极易造成积压。
3. 治理成本急剧攀升：例外情况依然需要等待周会或月度委员会审议，决策节奏完全脱节。

以安全审查为例：安全团队的编制通常按人类产出规模配置。当 Agent 带来成倍的代码产出时，要么审查队列严重积压延误发布，要么代码在未充分审查的情况下仓促上线。对于受监管行业的企业而言，这两种结果都不可接受。

要真正释放智能体 AI 的价值并确保安全合规，整个 SDLC 的流程形态需要经历与编码阶段同等深度的重塑。

什么是 AI 原生 SDLC？

AI 原生 SDLC（AI-Native SDLC）并非简单的「在旧流程中加入 AI 插件」，而是将原有的控制目标与新的执行机制相结合，把线性的单向流程转变为由 AI 贯穿每个节点的闭环回路（Loop）。

它通过标准化、可版本化的工件，实现阶段之间的自动衔接与后续打法（Plays）的自动触发，消除了传统跨角色交接时的摩擦与信息损耗。

传统 SDLC 与 AI 原生 SDLC 的核心演进

贯穿右侧 AI 原生流程的核心是已提交的工件（Committed Artifacts）。

每个阶段都以向版本控制系统提交标准工件结束（如 intent.md、spec.md、plan.md、代码 Diff 及测试、带审查结论的 PR、生产事件记录），下一个阶段则以读取该工件作为输入开始：

• 在前期阶段，Markdown 文件是核心工件，因为产品负责人和 Agent 都能无歧义地读取和编辑同一个文件；
• 从 Build 阶段开始，工件转为代码及关联记录。

这条提交链构成了完整的审计追踪（Audit Trail）：谁提出了诉求、Agent 生成了什么、谁审核并批准了该结果。人类依然对所有需要价值判断的决策负最终责任，只是人类的精力转移到了对工件的审查与把关上。

落地打法（Plays）总览与依赖路径

Playbook 将整套转型拆解为六个非线性阶段的模块化打法。组织无需一次性重构全部环节，可以根据自身瓶颈按需推进。

每个阶段以提交一个工件结束，该提交随即触发下一阶段：

• 确认 intent.md → 触发需求与设计分析；
• 批准 spec.md → 触发计划模式（Plan Mode）；
• 合并 PR → 触发部署流水线；
• 生产指标异常 → 自动生成新的 intent.md，使回路循环自洽。

初期可以通过人工提示词按部就班推进，随着基础设施完善，逐步演化为工件驱动的自动化流水线。

01. Plan（规划阶段）

核心变化：想法不再需要等待专人撰写整理。需求发起人直接用自己的业务语言与 Claude 对话，一次性沉淀为版本可控、下一阶段可直接消费的 intent.md。

将需求沉淀为 intent.md

无论需求来自业务人员的新想法、用户提交的工单，还是线上监控告警（见阶段 06），都可以通过标准化的 intent.md 切入流程。

• 传统模式：想法需要经过需求池排期、用户故事拆分、故事点估算与多轮需求评审。信息在层层传递中损耗，到达研发团队时往往与发起人的初衷产生偏差。
• AI 原生模式：发起人与 Claude 进行头脑风暴，生成一份包含诉求、背景、约束条件的 intent.md（原型规格）。产品负责人审核修改后提交入库。

• 前置依赖：无。
• 基础设施：
  • 为非研发人员开通 Claude（如 claude.ai 或 Cowork）；
  • 统一的 intent.md 模板；
  • 共享的版本控制仓库（如单产品仓库中的 intent/ 目录，通过 GitHub 连接器让非技术人员无需直接操作 Git 即可提交）。

1. 业务发起人向 Claude 描述问题：用自然语言表达当前痛点、受影响人群、期望效果与范围边界，无需专业的软件工程术语。
2. 多轮风暴细化：Claude 主动扮演业务分析师的角色，针对边界、受众、系统约束与成功标准进行追问。
3. 输出标准化 intent.md：Claude 根据组织的模板（可封装为 Skill）生成包含问题、目标、系统影响、约束与未决问题的 Markdown 文档。
4. 发起人确认校对：发起人检查并纠正理解偏差。
5. 提交至共享仓库：记录作者与时间戳，由产品负责人跟进处理。

# Intent: 理赔状态自助查询
Author: J. Ortiz (理赔运营组). Status: draft.

## 问题现状
客户频繁致电客服中心询问理赔进度。
坐席约有三分之一的通话时间仅用于同步状态信息。

## 期望结果
客户可以在用户端门户中自主查看理赔状态、下一步操作及预计完成日期。

## 涉及人员与系统
理赔专员、用户门户前端团队、理赔核心 API。

## 约束条件
会话过程中不得在门户引入新的 PII 数据；沿用现有身份认证机制。

## 待确认问题
第三方公估人员是否也需要访问此接口？

• 治理依据：提交到 Git 的 intent.md 包含作者、时间与完整修订历史；产品负责人的合并或关闭操作即为审批记录。
• 前导指标（Leading）：从首次提出诉求到 intent.md 正式提交的耗时（预期从传统数周缩短至几小时）。
• 滞后指标（Lagging）：intent.md 被产品负责人采纳进入 Design 阶段的比例（存活率）；首个 spec.md 提交后 intent.md 发生的变更次数。

02. Design（设计阶段）

核心变化：需求澄清与系统设计压缩在同一次会话中完成。品牌、合规、安全等组织规范在编写 Spec 时即时注入，无需等到数周后的评审环节才暴露冲突。

需求与技术设计的协同推导

在产品负责人确认 intent.md 后，Claude 会结合企业沉淀的规范 Skills（涵盖安全、品牌、UX、架构等），直接生成需求与技术规格说明（spec.md），并显式标记潜在冲突与风险点。

• 传统模式：分析师将想法转化为需求文档，设计师和架构师再解析为具体设计。分阶段虽为明确职责，但过程缓慢且容易失真。
• AI 原生模式：在单次会话中完成。以前端为例，产品负责人可基于 intent.md 在 Claude Design 中快速生成界面原型并迭代，确认后直接导出给 Claude Code 开发。

1. 产品负责人开启会话，加载组织规范 Skills 并挂载 intent.md。
2. 输入提示词，要求结合现有代码库生成 spec.md，并标明政策冲突与风险点（后续可固化为组织 Slash Command 或通过 CI 自动触发）。
3. 产品负责人对照原始目标审查 Spec，确认核心诉求是否得到解决、开放问题是否已妥善处理。
4. 针对 Agent 标记的关注点（Areas of Concern），产品负责人提前与相应合规/安全负责人协同确认。
5. 将 spec.md 提交至与 intent.md 相同的路径中，记录决策链条。
6. 产品负责人（高风险项目联合技术负责人）审批通过，正式进入 Build 阶段。

请阅读附带的 intent.md，并结合我们现有的代码库生成一份需求与设计规格说明书（spec.md）。
请应用可用的 Skills，确保方案符合我们的品牌规范、安全策略和 UX 标准。
将完整的规格说明记录为 spec.md，以便直接交付给研发团队。
请清晰标明所有关注点（Areas of Concern），尤其是存在策略冲突的地方。

• 治理依据：组织策略通过 Skill 作为硬性约束输入，Prompt 版本、Skill 版本与生成的 Spec 均纳入版本管理，由产品及策略负责人签字。
• 前导指标：从 intent.md 提交到 spec.md 提交的流转耗时。
• 滞后指标：Build 阶段启动后的需求返工率（即 plan.md 提交后 spec.md 再次修改的提交次数）。

03. Build（构建阶段）

核心变化：未获批准的 Plan 不写一行代码。组织经验沉淀为 Agent 必读的上下文文件，安全与工程护栏转化为自动化代码而非口头习惯。

1. 以 Claude Code 计划模式（Plan Mode）作为默认起点

在进入编码前，工程师在 Plan Mode 下启动 Claude Code。在该模式下，Claude 可以读取代码库但无法修改任何文件。

• 传统模式：工程师阅读设计后直接开始编码，具体涉及哪些文件、改动顺序、测试如何覆盖全在脑中，评审人只能在看到最终 PR 的庞大 Diff 时才能介入，发现方向偏差后返工成本极高。
• AI 原生模式：Claude 在 Plan Mode 下生成清晰的实施计划，列出影响的文件、步骤与测试用例。工程师审查甚至反复推敲方案，确认无误后提交为 plan.md，随后再由 Claude 依计划执行。

# Plan: 理赔状态自助查询 (基于 2026-06-02 intent.md)

## 涉及变更的文件
portal/src/claims/StatusPanel.tsx (新建), 
claims-api/routes/status.py,
claims-api/tests/test_status.py

## 实施顺序
1. 在既有认证体系下新增状态查询端点。
2. 编写 StatusPanel 组件对接该端点。
3. 将组件挂载到用户门户主导航。

## 风险与应对
理赔核心 API 限制为 50 rps；前端面板必须增加缓存策略。

## 验证依据
test_status.py 覆盖四种理赔状态；界面截图与已批准的原型严格一致。

1. 在 Plan Mode 下输入 intent.md 与 spec.md，要求输出包含受影响文件、步骤顺序与验证依据的方案。
2. 深度质询计划：询问可能的破坏性变更、最高风险步骤以及放弃的备选方案。
3. 持续调整，直至未参与讨论的工程师仅凭该计划就能独立实现。
4. 将确认后的计划提交为 plan.md，作为后续 PR 审查的核对依据。
5. 批准方案，让 Claude 一次性完成代码实现。

2. 自动模式（Auto Mode）的进阶应用

当组织护栏（CLAUDE.md、Skills、Hooks 与测试套件）逐步健全后，工程师可启用 Auto Mode。在方案确认后，Claude 自动批量执行修改而无需每步人工确认。 工程师的精力从「盯着 Agent 敲代码」转向「长时间自主会话后的工件审查」，结合 Git Worktree 极大释放了并行开发能力。

3. CLAUDE.md：沉淀新员工入职级的工程上下文

CLAUDE.md 将团队习惯、架构约定、构建命令与常见坑点整理为单一文件。Claude 在每次会话开始时都会自动读取。

• 核心原则：
  1. 通过 /init 快速生成基础模板；
  2. 精简至 1 页以内，只保留构建测试命令、关键架构规范与 Claude 经常犯错的要点；
  3. 两次犯错原则：一旦发现 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. 不允许引入新的 Lombok。
- 金额计算一律使用 BigDecimal，严禁使用 double。
- 每个端点必须在 src/itest 下配备集成测试。

## Architecture
- api/ 存放 REST 控制器, core/ 存放领域核心逻辑, adapters/ 负责外部通信。
- Kafka 事件定义在 schemas/；严禁手动修改自动生成的类。

## Things Claude gets wrong
- 不要升级第三方依赖版本，统一由平台工程团队维护。
- 遗留的 v1/ 包已冻结；所有新功能改动放入 v2/。

4. Skills：将组织规范转化为可复用的制度底座

Skills 存放于 .claude/skills/<skill-name>/SKILL.md，用于对安全标准、API 规范、合规要求等必须全局统一执行的知识进行标准化定义。

---
name: secure-api-review
description: 应用 API 安全标准。在创建/修改对外端点、审查 API 代码或生成 OpenAPI Spec 时使用。
---
# Secure API Review

当创建或修改 API 端点时执行以下检查：
1. 身份认证：所有端点必须校验 Gateway JWT；除 /health 外禁止匿名访问。
2. 输入校验：严格根据 OpenAPI Schema 校验 Request Body，拒绝未知字段。
3. 审计日志：所有变更状态的操作必须输出包含操作者、动作、实体与时间戳的审计事件。
4. 数据分级：Schema 中标记为 PII 的字段绝不能打印在日志或报错信息中。

运行 scripts/check-endpoints.sh 并将结果附在总结中。

5. Hooks：构建期的确定性硬护栏

Skill 属于建议型控制，而 Hooks 是其背后的确定性执行层。 在 Build 阶段，Hooks 可以在本地毫秒级拦截不安全操作：

• 阻止修改受保护目录（如生成的代码或已冻结的遗留包）；
• 在文件保存后自动触发 Formatter 与 Linter，杜绝代码风格漂移；
• 阻止将包含 Token、密钥的文件变更加入暂存区。

6. 并行会话（Parallel Sessions）与子智能体（Subagents）

借助 Git Worktree，工程师可以在独立的终端中同时运行 2~3 个 Claude Code 实例，分别处理互不干扰的任务模块（如 claude --worktree feature-auth 与 claude --worktree fix-rate-limit）。

对于重复性工作，可沉淀为专用的 Subagent（存放于 .claude/agents/），例如精简代码的 Simplifier、只看不改的 Verifier 或专门梳理依赖的 Researcher。

---
name: verifier
description: 在主会话声明完成前，独立启动应用并验证行为是否符合预期
tools: Bash, Read
---
使用 make run 启动服务。测试本次变更涉及的核心功能以及相邻的两个关联流程。
汇报运行步骤、观测结果以及任何不符合 plan.md 的异常。
请勿自行修复任何代码，仅做结果验证与报告。

• 前导指标：首轮实现即可直接合并的代码比例；从 Plan 获批到 PR 合并的周期时长。
• 滞后指标：单次变更的返工轮次；合并的实际 Diff 与预先提交的 plan.md 的吻合程度。

04. Test（测试阶段）

核心变化：每个会话在交付给人类前完成自我验证；指导智能体的配置文件（CLAUDE.md、Skills、Hooks）与业务代码一样接受持续回归测试。

1. 赋予 Claude 即时反馈闭环（Feedback Loop）

为 Claude 提供一键可执行的本地校验指令（测试、构建、Lint、UI 截图比对）。在向工程师汇报完成之前，Claude 必须在本地反复自我纠错直至全部通过。

• 传统模式：代码是否生效依赖数分钟后的 CI、数天后的测试人员或数周后的生产环境，反馈链条极长，人类成为唯一的验错瓶颈。
• AI 原生模式：在会话内闭环。运行测试 → 报错 → 自动修复代码 → 再次测试。

1. 单一目标命令：将复杂的验证链路封装为单一命令（如 make test），并在 CLAUDE.md 中给出预期输出示例。
2. 量化验收标准：提供明确的判定标准（如「test_status.py 全部通过」或「接口返回 200 且包含新字段」）。
3. 针对 Bug 修复实施 TDD：先让 Claude 将 Bug 复现为一条失败的测试用例并提交，随后通过 Hook 锁定该测试文件，要求 Claude 在不改动测试用例的前提下修复业务代码。
4. 前端视觉比对：通过 MCP 接入浏览器或截图工具，让 Claude 将实际渲染截图与设计图比对调优。
5. 保护测试不被篡改：通过 Hook 禁止 Agent 在修复代码时降低测试断言标准。

## 验证标准 (CLAUDE.md)

- Build: make build (必须输出 "Build succeeded")
- Test: make test (必须全绿；严禁跳过或删除失败的测试)
- Lint: make lint (零 warning)

在报告任务完成前必须运行上述三项并附带输出结果。
如果测试失败，请修复业务代码，严禁修改测试本身。

2. CI 中的持续 Evals（Continuous Evals）

Evals 是 AI 原生时代对应传统阶段性 QA 的机制。它是一个由 20~50 个真实历史任务构成的评估套件。

• 触发时机：当模型版本升级、提示词调整、或 CLAUDE.md、Skills、Hooks 发生变更时在 CI 中自动非交互运行；
• 事故沉淀：每发生一起生产事故，就必须将其编写为一个对应的 Eval 测试用例，永久纳入回归套件。

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

• 前导指标：Agent 编写代码的 CI 首通成功率；生产事故沉淀为永久 Eval 的周期时长。
• 滞后指标：PR 审查耗时（机械性问题已在本地被拦截）；生产逃逸缺陷数。

05. Deploy（部署阶段）

核心变化：代码审查转为双向协同，治理策略在操作发生时实时生效。智能体全权负责通往生产门禁前的一切操作，但绝对无法逾越生产门禁。

1. AI 深度融入 PR 评审循环

Claude 兼具「审查代码」与「响应评审意见」的双重能力：

• 工程师通过统一的 REVIEW.md 明确审查重点（Bug、安全隐患、以及与 spec.md / plan.md 的一致性）；
• 区分关键问题（Important）与代码风格细节（Nit），并限制 Nit 数量；
• 在 PR 中 @claude，Claude 会自动拉取评论修改代码并提交更新，直至全部通过并等待代码拥有者（Code Owner）最终审批。

# Review Instructions (REVIEW.md)

## 审查维度
每次审查执行以下三个维度的检查并打上对应标签：
- Bugs: 逻辑错误、边界遗漏、潜在回归问题。
- Security: 注入风险、认证漏洞、日志中的敏感信息（PII）。
- Compliance: 代码是否与 spec.md、plan.md 以及团队设计原则保持一致。

## 严重程度定义
Important 仅保留给会导致业务中断、数据泄露或违背策略的严重问题；格式与命名归为 Nit。

## 数量限制
每次审查最多展示 5 个 Nit，其余聚合为数量统计。

## 忽略范围
忽略 src/gen/ 下的自动生成代码以及 CI 已经强制检查的格式。

2. Hooks 作为人类审批门禁

与 Build 阶段静默拦截的 Hook 不同，Deploy 阶段的 Hook 负责在触发高危操作时暂停执行并拉取人类审批。

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

#!/bin/bash
# 生产部署必须携带命名授权
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "生产环境部署需要正式的发布授权（RELEASE_APPROVAL）。" >&2
     exit 2 # exit 2 阻断执行并向 Claude 返回错误说明
   fi
fi
exit 0

3. 企业受监管环境的集中托管配置范例

对于严格合规的金融或大型企业，可通过 MDM 或 Admin Console 下发不可被单机覆盖的托管配置：

{
  "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/allow：阻断敏感文件读取与任意外部网络外联，预先放行安全的本地内环命令；
• sandbox：从操作系统层面对命令执行实施沙箱隔离，限定网络访问域名；
• credentials：防止沙箱内 Shell 命令窃取本地 SSH密钥或云厂商凭证；
• strictKnownMarketplaces：强制所有 Skills、Agents、MCP 均来自企业内部审核通过的插件市场。

4. CI/CD 流水线集成

通过 claude -p 在 CI 流水线中非交互式运行，执行分析构建日志、整理测试摘要、生成 Changelog 等判断型任务； 结合 MCP 暴露部署与回滚指令，不同环境分级授权（测试环境自主部署，生产环境经审批后由 Agent 触发）。

• 前导指标：首次 PR 审查响应时间；无需人工排查的 CI 故障自动诊断比例。
• 滞后指标：DORA 核心指标（部署频率、变更失败率、平均恢复时间 MTTR）。

06. Maintain（维护与闭环阶段）

核心变化：回路正式闭合。生产异常触发 Claude 自动诊断，产出的结论作为 intent.md 重新注入 SDLC 第一阶段，实现自愈与持续演进。

1. 监控与闭环自愈

• 传统模式：维护属于被动响应阶段。线上告警需等待值班人员发现、排查、手动建单，复盘结论往往因新需求插队而无法落地到代码库。
• AI 原生模式：确定性监控脚本检测到指标异常（如 5xx 激增、测试失败率波动），自动调用无状态的 Claude 执行只读排查，并将根因与方案生成为 intent.md 提交至评审队列。

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]

• 1σ（轻微偏离）：记录日志；
• 2σ（中度偏离）：调用 Claude 结合日志进行无状态只读诊断；
• 3σ（严重偏离）：触发自动提 PR（如隔离偶发失败的测试）或触发预批准的自动回滚流水线。

2. 通过 Claude Tag 参与值班协同

在 Slack 或 Teams 等协作工具中，通过 Claude Tag 让 Claude 作为第一响应人进驻值班频道：

• 当产生告警或被 @ 提及提单时，Claude 自动在频道线程中同步排查步骤；
• 通过 MCP 验证指标是否恢复正常；
• 将故障排查经验总结为 Markdown 复盘文档归档，小修补直接提 PR，大改动转为 intent.md 注入下一轮 Plan。

• 前导指标：从指标异常到 intent.md 进入分诊队列的流转时间。
• 滞后指标：监控排查建议转化为实际修复合并的比例；同类故障的重复发生率（随着 Eval 套件的丰富持续下降）。

总结：回路持续运转，人类判断居于其上

随着模型能力与执行框架（Harness）的演进，企业不仅在改变编写代码的方式，更在重构整个软件工程的生产关系。

AI 原生 SDLC 的核心并不是消除人类，而是将人类从繁琐的机械流转、逐行校验和多头交接中解放出来，专注于最核心的高阶事务：

• 定义意图（Intent）；
• 制定策略（Policy & Skills）；
• 把控高危门禁（Approval Gates）；
• 评估系统风险与架构方向。

自动化回路在下方高速运转，人类的专业判断始终居于其上（The loop keeps running. Human judgement stays above it）。