ARTICLE · 988594
AI原生·软件开发生命周期#anthropic-the-ai-native-sdlc-playbook
Shadow：看完Anthropic关于AI原生软件开发的指南，非常有同感。
Mixlab一直强调的“Vibe Coding”和“从工匠到指挥官”的理念，与AI原生软件开发周期的内核高度一致。
Mixlab这些年在企业级软件开发上积累了各种复杂度的项目经验，有化工产业链的Saas、线上线下融合的商业社交Saas、苹果眼镜原生应用研发等。
我们把在企业级AI原生开发经验，提炼成核心方法，在AI训练营上，提供能力重塑和项目制学习。
能力重塑：训练营培养的不再是单纯的“代码编写者”，而是能定义问题、把控边界、整合资源的“超级节点”（产品经理+设计师+工程师+运营者）。这正是在AI原生SDLC中，人在循环之上（Above the Loop） 进行“发起、指导和治理”的新角色。
项目制学习：训练营强调在两天内从0到1完成项目上线，这与AI原生SDLC追求“小时级”快速迭代的闭环体验是一致的。
以下是 Anthropic 最近发布的指南的提炼总结：
一、什么是AI原生SDLC？
AI原生SDLC（AI-Native Software Development Lifecycle） 是将AI代理（如Claude）深度嵌入软件开发生命周期每个阶段的开发范式。它不是简单地在传统流程中“添加AI工具”，而是围绕AI的能力重新构想整个流程。
核心理念
“代码不再是瓶颈” —— 当AI能快速生成代码时，真正的限制变成了人围绕代码所做的决策、审查和协调。因此，流程必须从线性变为循环，人的角色从流程中的执行者变为流程之上的发起者、指导者和治理者。
与传统SDLC的本质区别
流程形态方面
传统方式：线性流程，阶段之间靠人工交接推进，像一条缓慢的传送带 AI原生方式：循环闭环，每个阶段产出的工件自动触发下一阶段，形成高速迭代的环路
速度方面
传统方式：迭代以“周”甚至“季度”为单位 AI原生方式：迭代以“小时”为单位，变更可以快速流转
瓶颈方面
传统方式：编码和人工审查是主要瓶颈 AI原生方式：人的判断成为核心瓶颈——意图设定、关键决策、治理
知识传递方面
传统方式：依赖文档、会议、口头传授 AI原生方式：依赖版本控制的机器可读文件（ CLAUDE.md、技能）
安全控制方面
传统方式：阶段门禁、周期性审查，滞后且效率低 AI原生方式：持续且内嵌于代理行为中（钩子、审查代理、评估）
工程师角色方面
传统方式：主要编写和审查代码 AI原生方式：担任指挥者和协调者，管理多个并行代理
审计方面
传统方式：事后追溯，依赖工单记录 AI原生方式：内置细粒度工件链，每个决策可归因、可审计
二、AI原生SDLC实施指南
以下按优先级分为入门三步和进阶优化，您可以根据组织成熟度选择性实施。
🚀 入门三步（最小可行转型）
第一步：建立代理的“入职指南”—— CLAUDE.md
目标：让AI代理理解您的代码库规范、架构和常见陷阱。
具体操作
在代码仓库根目录运行 /init命令，让Claude生成初始版本精简内容，保留新员工入职第一天所需的信息：构建/测试/检查命令、重要规范、架构概览、Claude常犯错误 将文件提交到Git，团队像审查代码一样审查更改 - 经验法则
：当Claude犯了两次同样的错误，就将修正记录到 CLAUDE.md中
示例结构
# 支付服务## 命令- 构建: make build- 测试: make test (单元测试), make itest (集成测试)- 代码检查: make lint## 规范- Java 21, Spring Boot 3- 金额统一用 BigDecimal，绝不用 double- 每个端点都需要集成测试## 架构- api/ 存放REST控制器, core/ 存放领域逻辑, adapters/ 对接外部系统## Claude常犯错误- 不要自行升级依赖版本，由平台团队统一管理- legacy v1/ 包已冻结，变更须在 v2/ 中进行治理考量
CLAUDE.md采用版本控制，代理执行的指令可审查和审计 团队规范通过该文件应用，变更记录在Git历史中 代码所有者在PR审查中批准这些变更
第二步：让AI“计划后执行”—— 计划模式（Plan Mode）
目标：在AI写代码之前先产出书面计划，让人在编码前纠正方向。
具体操作
工程师以计划模式启动Claude Code会话 将 spec.md交给Claude，要求它列出：要更改的文件、工作顺序、用于验证的测试通过以下问题审视计划： 这个变更可能破坏什么？ 哪一步风险最高？ Claude放弃了哪些替代方案？ 迭代直到满意，将计划提交为 plan.md批准计划，让Claude执行 当实际执行与计划出现偏差时，在同一个提交中更新 plan.md可考虑使用钩子强制两者保持同步
治理考量
设计评审发生在代码生成之前，此时更改方案只需编辑文档 计划模式强制执行流程——在工程师接受计划之前，Claude无法编辑文件 计划及其修订版本以及接受者都被记录在案 常规变更由工程师批准，高风险变更提交给技术主管或架构师
关键价值
传统审查看到的是最终diff，此时返工成本极高；计划模式让审查发生在编码之前，此时纠正只需编辑文档，成本极低。
第三步：给Claude反馈回路—— 让它自己验证工作
目标：让AI在工程师看到结果之前自行运行测试、构建并迭代至通过。
具体操作
将测试和构建封装为单条命令（如 make test），失败时返回非零值在 CLAUDE.md中明确写出验证命令及其正常输出示例对于Bug修复： 先让Claude编写能复现该Bug的测试用例 提交该测试用例 再让Claude在不修改测试的情况下修复代码 设置钩子阻止代理在修复任务中编辑测试文件，确保测试的完整性 对于UI设计，给Claude提供浏览器或截图工具，让它查看原型、截图、对比、迭代——两到三轮迭代是正常的
治理考量
强制执行“在报告任务完成之前进行验证” 通过钩子实现“修复期间阻止代理编辑测试文件” 证据来自工具链：测试输出、构建日志、截图差异 记录在会话记录（导出到可观测性堆栈）和PR检查运行中 审查者可以专注于意图和风险，因为技术证据已经附上
⚙️ 进阶优化（按需采用）
1. 治理编码化：技能（Skills）与钩子（Hooks）
技能（Skills）
- 定义
：编码化的机构知识，AI在相关任务中自动读取并遵循 - 适用场景
：安全标准、API设计规范、品牌规则等需要一致应用的知识 - 编写方式
：创建包含 SKILL.md文件的文件夹，开头说明触发条件，正文说明执行的操作 - 分发方式
：放入代码库的 .claude/skills/<name>/随代码发布，或通过插件在整个组织内分发 - 更新机制
：当政策发生变更时，更改技能条款，由政策持有人签署确认，工程师在下次会话中自动更新到新版本 - 治理考量
：技能调用被记录在会话跟踪中，政策所有者像审查代码一样审查技能变更
技能示例（安全API审查）：
---name: secure-api-reviewdescription: 创建或修改对外端点时应用API安全标准---# 安全API审查创建或更改API端点时：1. 认证：每个端点都需要网关JWT，/health除外2. 输入验证：对照OpenAPI schema验证请求体，拒绝未知字段3. 审计：每个状态变更端点都发出审计事件（操作者、动作、实体、时间戳）4. 数据分类：schema中标记为pii的字段绝不能出现在日志或错误消息中钩子（Hooks）
- 定义
：确定性执行的控制点，在关键操作前运行脚本，可允许、询问或阻止 - 适用场景
：必须无一例外执行的策略 - 常见用途
： 阻止对受保护路径的编辑（如生成的类或冻结的包） 文件编辑后运行格式化程序和代码检查程序 将凭据从差异分析中排除 在生产部署前强制人工授权 - 放置位置
： 团队钩子放在 .claude/settings.json中（Git管理）不可协商的钩子放在平台或IT管理员拥有的管理设置中 - 治理考量
：钩子是审批门，每次都对所有人强制执行，允许和阻止的决定都被记录并带有时间戳
钩子示例（生产部署门禁）：
#!/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 # 阻止该操作 fifiexit 0技能与钩子的关系
技能是一种建议性控制，使Claude更有可能应用策略，但无强制机制 钩子是技能背后的确定性层，使违规几乎不可能发生 技能使违规变得罕见，钩子使违规无法实现
2. 持续评估（Evals）：防止代理能力退化
目标：像回归测试代码一样，回归测试代理的配置。
具体操作
收集20到50个真实任务及其预期/接受的结果 将每个任务写成一个评估：提示 + 定义可接受性的检查（测试通过、lint干净、行为未改变、遵循策略） 在CI中按计划以非交互方式运行评估套件 在 CLAUDE.md、技能或钩子发生任何更改时触发评估运行（配置控制代理，应像代码一样进行回归测试）根据结果调整评估设置——任何导致通过率下降的技能变更都在合并前审核 每个生产事故都转化为一个评估用例，由负责团队编写，作为回归测试永久保留
治理考量
评估为质量保证提供了与代理输出保持同步的门槛 通过率阈值通过合并检查强制执行 运行过程被记录以便进行长期结果比较 由负责配置变更的团队进行审批
3. AI驱动的PR审查与并行会话
AI PR审查
Claude根据组织政策审查收到的PR，也能处理自身PR上的审查评论 所有PR经过一套相同的审核流程，结果按严重程度排序 技术负责人编写代码审查策略，存放在 REVIEW.md中审查策略涵盖：缺陷和逻辑错误、安全性和漏洞、是否符合规范和计划 多轮审查（Bug pass、Security pass、Compliance pass）并行进行 审查结果反馈到 CLAUDE.md——当审查第二次发现错误时，修正作为审查的一部分提交技术主管每月根据审查结果调整设置，限制规则数量
并行会话
工程师同时运行多个Claude会话，每个在不同工作树中执行独立任务 并行会话之间互不了解，唯一共同点是共同管理它们的工程师 两到三个会话是合理的起点，上限取决于一个人能有效审查的数量 重复性任务转换为子代理（在 .claude/agents/中定义），拥有各自的上下文和工具限制
治理考量
会话越多，输出越多，控制必须来自代码仓库中的配置 钩子和权限设置适用于所有会话 会话操作被记录并归因于运行该会话的工程师
4. 闭环监控：让监控触发新的开发循环
目标：生产异常自动唤醒AI诊断并生成新 intent.md，重新进入流程。
具体操作
选择稳定基线指标（如CI测试失败率、部署后5xx错误率） 编写确定性检测脚本，使用滚动窗口计算均值和标准差 定义响应层级： 1σ层级：仅记录日志 2σ层级：以只读方式调用Claude进行诊断 3σ层级：Claude可执行操作（但只能通过提交PR或触发预批准运行手册） 代理按 intent.md格式编写诊断报告：异常及证据、拟议解决方案、受影响的系统、未解决的问题服务负责人或值班工程师对队列进行分类（立即修复、安排处理或忽略） 当修复发布时，向评估套件添加事件评估
示例应用
CI测试失败率超3σ时，代理隔离不稳定的测试或打开回滚PR 部署后5xx错误率超3σ时，代理触发现有回滚管道 PR周期时间触发漂移规则时，代理为工程领导编写报告
治理考量
层级边界通过版本控制的配置强制执行 权限和管理设置阻止对生产环境的访问 调用、发现问题和分类决策都被记录并带有时间戳 代理可能触发的运行手册已事先获得批准
5. 定期代码库扫描
目标：按计划自动运行安全扫描，将发现的问题像任何其他变更一样通过安全机制审核。
具体操作
使用Claude Security（托管式定时扫描服务）连接GitHub代码库 按存储库、服务或团队组织成项目，明确发现结果的归属 对最重要的代码库进行首次全面扫描作为基准 为每个项目设定计划（积极开发的服务每周一次是合理默认值） 根据置信度评级对初步结果进行分类 范围限定的发现：在Claude Code on the Web中审查建议补丁，通过PR审查流程提交 更广泛的问题（架构缺陷、跨服务重复模式）：按 intent.md格式编写，从计划阶段开始修复发布后，向评估套件添加漏洞类别的评估
治理考量
扫描在组织管理控制下运行（连接的存储库、权限持有者、费用限额集中设置） 每项发现包含验证结果和置信度评级 每项排除都有理由，扫描历史是对已发现、已修复和已确认问题的审计记录 修复通过PR审核和分支保护机制进入生产，而非扫描本身
📊 各阶段实施的依赖关系
根据手册建议，采用顺序遵循以下依赖关系：
构思阶段无任何前置依赖，可以最先实施。
设计阶段依赖构思阶段产出的 intent.md 工件。
构建阶段依赖设计阶段产出的 spec.md 工件。
测试阶段可与构建阶段同步推进。
部署阶段依赖测试阶段的评估和构建阶段的钩子。
监控阶段依赖部署阶段的回滚路径和构建阶段的钩子。
治理（技能与钩子） 是横切关注点，可在任何阶段独立引入，但引入越早收益越大。
总结：转型的三个核心理念
治理即代码
将安全、合规、架构标准编码为机器可读的 CLAUDE.md 和技能，让AI在生成代码时即默认遵循。策略不再停留在文档中，而是嵌入代理的每一个行为里。
闭环持续进化
每个阶段的产出自动触发下一阶段，监控异常自动生成新需求，形成永不停止的改进循环。环路的每个节点都在学习和强化，整个系统随着时间推移变得越来越智能和稳健。
人机分工新范式
人负责意图设定、规则制定和关键审批；AI负责执行、验证和监控。人的注意力从代码细节提升到系统治理层面。核心问题不再是“人做了什么”，而是“代理做了什么，以及人批准了什么”——这本身就是一种强大的审计和治理模型。