AI-Native SDLC 深度解析与落地指南

Play: Capture as intent.md 起点 play

核心：想法不再排队等产品经理代写。提出者用自己的语言与 Claude 头脑风暴，Claude 像分析师一样追问（范围、用户、约束、成功标准），产出 proto-spec 存为 intent.md，提交到产品仓库的 intent/ 目录。

落地要点：

• intent 的三个入口等价处理：人的想法、ticket、生产告警（Stage 6 回写）。无论来源，产品负责人都要在提交前审校。
• 非工程师无需碰 git：通过 GitHub connector 让 Claude 从 claude.ai/Cowork 代提交。
• intent 模板编码为 skill，由技术成员编写、负责人签核。
• intent 仓库选址：单产品放产品仓库 intent/ 目录（工件链贴着代码）；跨多仓库才值得独立 intent 仓库。

示例 —— intent.md（原文示例的中译，理赔状态自助查询）：

# Intent：理赔状态自助查询
作者：J. Ortiz（理赔运营）。状态：草稿。

## 问题
客户致电客服中心询问理赔进度。
坐席约三分之一的通话时间花在纯状态查询上。

## 期望结果
客户在门户中看到理赔状态、下一步骤和预计日期。

## 受影响的用户和系统
理赔坐席、门户团队、理赔核心 API。

## 约束
门户会话中不引入新的 PII。仅使用现有认证。

## 开放问题
第三方公估行是否也需要访问权限？

度量：领先——首次对话到 intent.md 提交的时间（期望：数周 → 数小时）；滞后——intent 存活率（被接受到 Design 的比例）+ spec 提交后 intent 还被修改的次数。

Play: Requirements & design（需求与设计合并为一次会话）

核心：产品负责人带着 intent.md 开会话，组织政策（品牌/安全/合规/UX）以 skills 形式在场，Claude 产出 spec.md 并主动标记顾虑区域（尤其是政策互相冲突之处）。产品负责人评审但不撰写；标记的顾虑在工程介入前就与各政策负责人解决。

落地要点：

• 先手工跑 prompt，固化后编码为组织级 slash command，最终把"intent.md 被接受"设为触发器，由非交互 job 自动跑设计 pass 并以 PR 提交 spec.md——此后产品负责人的首次介入就是评审。
• 前端工作可叠加 Claude Design：从 intent.md 出 mock，迭代后导出给 Claude Code 构建。
• spec.md 与 intent.md 成对提交：一个记录要什么，一个记录决定了什么。

示例 —— 设计 pass 的 prompt（原文示例的中译）：

阅读附上的 intent.md，产出一份将其集成进现有代码库的需求与设计规格。
应用你可用的 skills，使方案符合我们的品牌指南、安全政策和 UX 标准。
将规格完整记录为 spec.md，可以直接交付工程团队。
清楚地描述所有顾虑区域，尤其是当你无法同时满足互相冲突的政策时。

度量：领先——intent.md 与 spec.md 两次 commit 的时间差；滞后——build 开始后的需求返工（plan.md 首次提交之后的 spec.md 提交数，git log 直接可查）。

Play: Plan mode as default 起点 play

核心：没有经批准的计划就不写代码。工程师以 plan mode 开会话（Claude 只读代码库、不能改文件），给 Claude intent.md + spec.md，要求产出注明变更文件、工作顺序、验证测试的 plan，并拷问计划（会打破什么？哪步最险？放弃了哪些方案？），迭代到"没看过对话的人也能照计划实现"为止，然后提交 plan.md。

落地要点：实现偏离计划时，在同一 commit 更新 plan.md（可用 hook 强制同步）；guardrails 成熟后常规工作切 auto mode——紧的 spec、小的爆炸半径、有测试覆盖。评审对象从"逐行动作"转向"工件"。

示例 —— plan.md（原文示例的中译）：

# 计划：理赔状态自助查询（源自 intent.md 2026-06-02）

## 变更文件
portal/src/claims/StatusPanel.tsx（新建）、claims-api/routes/status.py、
claims-api/tests/test_status.py

## 工作顺序
1. 在现有认证之后新增状态查询端点。
2. 面板对接该端点。
3. 接入门户导航。

## 风险
理赔核心 API 限流 50 rps；面板必须做缓存。

## 验证
test_status.py 覆盖四种理赔状态；截图与已批准的 mock 一致。

度量：领先——一次实现即合并的比例、plan 批准到 PR 合并的时间；滞后——每个变更的返工轮数、合并 diff 与 plan.md 的一致率。

Play: The CLAUDE.md 起点 play

核心：给 Claude 一份"新人第一天所需"的文件：命令、约定、架构、团队最常踩的坑。机构知识从人脑和 wiki 变成 agent 每次会话都读、全团队维护的版本化文件。

落地要点：/init 起步 → 砍到一页以内（全文每次会话都占上下文，过时内容纯浪费）→ 入 git 根目录、像代码一样评审 → 工作规则：Claude 同一个错犯两次，纠正就进 CLAUDE.md。

示例 —— CLAUDE.md（原文支付服务示例的中译）：

# 支付服务

## 命令
- 构建：make build
- 测试：make test（单元）、make itest（集成，需要 docker）
- Lint：make lint（CI 中运行；推送前修复）

## 约定
- Java 21，Spring Boot 3。不再新增 Lombok。
- 金额一律用 BigDecimal，禁止 double。
- 每个端点都需要 src/itest 下的集成测试。

## 架构
- api/ 放 REST 控制器，core/ 放领域逻辑，
  adapters/ 对接外部系统。
- Kafka 事件定义在 schemas/；永远不要编辑生成的类。

## Claude 常犯的错
- 不要升级依赖版本；平台团队统一管理。
- 遗留 v1/ 包已冻结；改动进 v2/。

度量：领先——CLAUDE.md 本应抓住的错误复发率；滞后——新成员首个 PR 合并时间。

Play: Skills as institutional knowledge 依赖 CLAUDE.md（可选）

核心：把"执行不一致"的政策逐条编码为 skill（SKILL.md：frontmatter 写触发时机，正文写怎么做），放 .claude/skills/ 随代码分发，或经 plugin marketplace 组织级分发。

落地要点：经验法则——需要被一致应用的机构知识写成 skill；属于 CLAUDE.md 或 prompt 的东西不要写成 skill。写完后要换着花样让 Claude 做相关任务、确认 skill 每次都被触发。政策变更 = 改 skill + 政策负责人签核，工程师下个会话自动获得新版。

示例 —— .claude/skills/secure-api-review/SKILL.md（原文示例的中译）：

---
name: secure-api-review
description: 应用 API 安全标准。创建或修改对外端点、
  评审 API 代码、生成 OpenAPI 规格时使用。
---
# 安全 API 评审

创建或变更 API 端点时：
1. 认证：每个端点都要求网关 JWT；
   /health 之外不允许匿名路由。
2. 输入校验：按 OpenAPI schema 校验请求体，拒绝未知字段。
3. 审计：每个改变状态的端点都要发出审计事件，包含
   操作者、动作、实体和时间戳。
4. 数据分级：schema 中标记为 pii 的字段绝不允许
   出现在日志或错误信息中。

运行 scripts/check-endpoints.sh，并把输出附在你的总结里。

度量：领先——政策批准到 skill 合并的时间；滞后——PR 评审中引用该政策的 finding 数（应趋零；不趋零则 skill 没触发或文本已漂移）。

Play: Hooks as build-time guardrails

核心：skill 背后的确定性层。Build 期 hook 要快且只作用于变更的文件：阻止改冻结目录/生成代码、编辑后跑 formatter/linter、把凭证挡在 diff 外。重的检查（全量测试）留给 commit 和 PR。

Play: Parallel sessions & subagents

核心：一个工程师同时驱动多条工作流。并行会话 = 独立 Claude Code 实例 + 独立 git worktree（互不感知，工程师是唯一共享点）；subagent = 会话内的有界助手（独立上下文窗口 + 工具限制），封装重复性工作（verifier、simplifier、researcher），定义在 .claude/agents/ 并入 git。

落地要点：任务按"动不同文件"切分（动相同文件的任务串行放同一会话）；两三路并行起步，上限 = 一个人能认真评审的流数；控制来自仓库里的配置（hooks + permissions 对所有会话生效）。

示例 —— .claude/agents/verifier.md（原文示例的中译）：

---
name: verifier
description: 在会话报告完成前运行应用并检查变更是否生效
tools: Bash, Read
---
用 make run 启动应用。演练变更的行为以及相邻的两个流程。
报告你运行了什么、看到了什么、以及任何与 plan.md 不符的行为。
不要修任何东西；只报告。

度量：领先——评审质量不降级前提下的并发会话数、"操舵 vs 等待"的时间占比；滞后——人均每周合并变更数 × 返工率。

Play: Feedback loop 起点 play

核心：永远给 Claude 一个自我验证的手段（测试/构建/截图 diff），让会话在人看到之前就自查自修。信号到得越晚，检查 agent 产出的人就越成为瓶颈。

落地要点：

• 把验证收敛为单命令（make test，非零退出），并在 CLAUDE.md 里附上健康输出样例。
• 目标要可量化、无需问人："test_status.py 全绿"、"截图与 mock 一致"、"端点返回 200 且带新字段"。
• 修 bug 先写失败测试并提交，再让 Claude 在不许改测试的约束下修代码（测试文件保护 hook 强制执行）——先于修复存在且 agent 改不动的测试，是 bug 已修复的证据。
• UI 工作用浏览器/截图工具闭环：实现 → 截图 → 对比 → 调整，两三轮属正常。
• 区分两个概念：feedback loop 贯穿任务全程反复运行；verifier subagent 是任务结束后的全新上下文终检，结论不被产生代码时的假设污染。

示例 —— CLAUDE.md 中的验证块（原文示例的中译）：

## 验证你的工作

- 构建：make build（必须以 "Build succeeded" 结束）
- 测试：make test（全绿；永远不要跳过或删除失败的测试）
- Lint：make lint（零警告）

报告任何任务完成之前运行以上全部三项，并粘贴输出。
如果测试失败，修代码，而不是修测试。

度量：领先——agent 产出的首次 CI 通过率；滞后——单 PR 评审时长、变更失败率。

Play: Continuous evals in CI 依赖 CLAUDE.md + Feedback loop

核心：eval 是 AI 原生的 stage-gate QA——agent 的配置（CLAUDE.md/skills/hooks）引导它的行为，因此要得到和代码同级的回归测试。换模型、改 prompt 时，eval 套件回答"agent 还能按原标准干活吗"。

落地要点：收集 20–50 个带期望结果的真实任务写成 eval（prompt + 可接受性检查）；CI 定时跑 + 配置变更时跑（pull_request.paths: ['CLAUDE.md', '.claude/**']）；通过率下降的配置变更必须评审后才能合并；每个生产事故都变成一条常驻 eval。套件是活的：模型变强后，失去区分度的用例要淘汰，新用例来自持续监控。

示例 —— .github/workflows/agent-evals.yml（原文示例，注释为中译）：

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']   # agent 配置变更时触发回归
  schedule:
    - cron: '0 2 * * *'                  # 每日定时跑
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: 运行 eval 套件
        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

度量：领先——eval 通过率随时间变化、事故转化为常驻 eval 的耗时；滞后——CI 拦住的回归 vs 漏到生产的回归。

Play: AI in the PR review loop 依赖 CLAUDE.md + Skills + Subagents + Evals

核心：评审双向运行——Claude 按 REVIEW.md 政策评审传入的 PR（多 pass、按严重度排序），也在自己的 PR 上响应 @claude 评审意见并推修复。人只看一件事：变更是否做了 plan 声称要做的事、风险是否可接受。

落地要点：

• REVIEW.md 定义 pass（bugs / security / compliance-against-spec-plan）、Important 与 Nit 的界限、nit 上限（每次评审最多 5 条）、不报什么（生成代码、CI 已强制的项）。
• finding 不自行批准/阻塞 PR；分支保护仍要求 code owner 人类批准——写代码的 agent 无法批准代码，职责分离保留。
• 评审 finding 回流 CLAUDE.md：同一错误被评审抓到第二次，纠正就进 CLAUDE.md，下个 PR 起被自动拦住。
• 技术负责人每月调优：给 finding 打分、在 REVIEW.md 里压 nit 量。

示例 —— REVIEW.md（原文示例的中译）：

# 评审指令

## 评审 Pass
跑三个 pass，每条 finding 标注所属 pass：
- Bugs：逻辑错误、边界情况失效、隐蔽回归
- Security：注入风险、认证缺口、日志中的 PII
- Compliance：变更与 spec.md、plan.md 及设计原则一致

## 这里 Important 的含义
Important 只留给会破坏行为、泄漏数据或违反政策的 finding。
风格和命名属于 nit。

## 限制 nit 数量
每次评审最多报告 5 条 nit；其余的汇总为一个计数。

## 不要报告
src/gen/ 下的生成文件，以及 CI 已强制的任何事项。

度量：领先——首次评审耗时（应降到分钟级）、无需人碰分支就解决的评审意见占比；滞后——合并前拦住的缺陷 vs 逃逸到生产的缺陷。

Play: Hooks as approval gates 起点 play

核心：hook 不止 allow/block，还能 ask——暂停动作直到具名的人批准，这就是发布门。团队级 hook 进 .claude/settings.json（入 git）；不可协商的 hook 进 managed settings，由平台/IT 持有，工程师无法关闭。block 必须自解释：原因和获得批准的路径要出现在 Claude 的输出里。

示例 —— 生产发布门（原文示例，注释为中译）：

.claude/settings.json 中注册 hook：

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

门本体 .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 "生产部署需要发布授权。" >&2
     exit 2 # exit 2 阻止该动作；消息会返回给 Claude
   fi
fi
exit 0

治理（受监管企业的 managed settings 示例）：每一行都对应一个控制目标——

Play: CI/CD integration 依赖 PR review + Hooks + Plan mode

核心：把 Claude 非交互地放进流水线，接管需要判断的步骤（triage 失败的构建、总结 flaky test、起草 changelog），在沙箱 + 短时令牌下运行；部署能力经 MCP 暴露为按环境分权的工具；按环境分层自治——dev 自由部署，staging 居中，production 由 agent 备好发布、发布经理授权、hook 把门。

落地要点：先做只读判断步骤，再做门内的写入步骤；agent 写的一切经分支保护以 PR 到达、无直连 main 的路径；回滚必须是流水线里演练最充分的路径——单命令、agent 可调用、在 staging 定期演习（Stage 6 最高自治层会调它）。

示例 —— 流水线中的 triage 步骤（原文示例的中译）：

- name: 分诊失败的构建
  if: failure()
  run: >
    claude -p "读取 out/build.log 的构建日志。指出最可能的原因，
    判断失败是 flaky 还是真实问题，并为 PR 讨论串写三行摘要。"
    >> triage.md

度量：领先——不惊动人就完成 triage 的流水线失败占比；滞后——DORA 四项指标。

Play: Closing the loop 依赖 intent 格式 + PR review + Hooks + CI/CD 回滚路径

核心：环闭合，调用路径上没有人。确定性检测脚本盯着有稳定滚动基线的指标（CI 测试失败率、部署后 5xx 率、PR 周期），越界即触发 Claude；按 sigma 分层响应，全部定义在版本化的 bands.yaml 里：

示例 —— bands.yaml（原文示例，注释为中译）：

metric: ci_test_failure_rate      # 监控指标：CI 测试失败率
baseline: rolling_30d             # 基线：30 天滚动窗口
rules: western_electric           # 判定规则：Western Electric
tiers:
  1sigma: { action: log }         # 1σ：只记录日志
  2sigma: { action: diagnose,     # 2σ：调用 Claude 只读诊断
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,      # 3σ：可行动，但只走受门控路径
            routes: [pull_request, runbook:rollback-deploy] }

落地要点：

• 检测永远确定性（滚动均值/标准差 + Western Electric 规则，能抓慢漂移也能抓尖峰），脚本版本化且有单元测试，模型不参与检测。
• Claude 的诊断写成 Stage 1 格式的 intent.md（异常+证据、期望结果、受影响系统、开放问题），随后像任何 intent 一样走完整流水线。
• 服务负责人/on-call 分拣队列：立即修 / 排期 / 驳回。驳回用于调 band 降噪声。修复上线后把事故变成常驻 eval。
• Claude 以无状态、非交互方式运行（CI runner 或 Agent SDK 沙箱服务）——环可以在无人启动的情况下开始和结束。

度量：领先——越界到 intent.md 进分拣队列的时间；滞后——发现转化为合并修复的比例、同类事故复发率（应随 eval 累积而下降）。

Play: Recurring codebase scans（Claude Security）

核心：安全扫描是"某代码库 × 某模型"在某时刻的快照，两半都会过期——代码每周在变，每一代模型都能找到上一代找不到的漏洞。答案是把扫描排上日程、调用路径上没有人、发现走与其他变更相同的门。小到一个 PR 的修复走评审门；架构级弱点写成 intent.md 从 Plan 重新开始。每次驳回必须带理由，使扫描历史本身就是"发现了什么、修了什么、有意识地接受了什么"的审计记录。

Play: Claude on call（Claude Tag）

核心：事故也从 Slack/Teams 到达。Claude 以自己的身份驻留事故频道：诊断、在人授权后执行（如已演练的回滚）、经 MCP 验证指标回归基线、把 post-mortem 写进版本化的 lessons 文件。频道即审计轨迹：请求、诊断、人类授权、修复全部留在事故发生地。