AI 原生 SDLC 怎么落地：产物、门禁与基础设施

代码写得更快之后，团队往往先撞上另一堵墙：需求还在会议里补，设计决策散在聊天记录里，安全审查排到合并前，发布仍依赖少数熟悉环境的人。

开发 Agent 缩短了写代码的时间，却没有自动缩短代码前后的等待。规划、审查、发布和治理开始成为新的瓶颈。

图 1：编码 Agent 转移了瓶颈，没有替代完整交付体系。本图为原创重绘，概念参考 Anthropic AI-Native SDLC Playbook。

Anthropic 的 AI-Native SDLC Playbook 给出了一条清晰思路。这门 14 课的 Claude Academy 课程覆盖规划、设计、开发、测试、部署和运维。本文沿用其中“可提交产物”的主线，再补上团队落地时绕不开的知识归属、API 权限、预算、隔离执行和运行证据。它是一篇独立实践指南，不是逐课翻译。

什么是 AI 原生 SDLC？

AI 原生软件开发生命周期是一套交付循环：Agent 参与规划、实现、测试、审查和运维，人继续负责目标、风险判断和生产授权。

连接这套循环的是提交到版本控制的产物：

intent.md → spec.md → plan.md → code + tests → reviewed PR → release record
    ↑                                                        ↓
    └──────────── incident / metric / user feedback ─────────┘

每个阶段都写下一份能追踪版本的结果，下一阶段先读取它再动手。聊天记录可以解释思路，却不适合充当事实源。提交记录至少能回答四个问题：谁提出需求、依据是什么、Agent 改了什么、谁批准了结果。

这六个阶段也不是单向流水线。测试失败可以退回计划，线上告警可以生成新的 intent.md。重点是每次流转都有明确输入、可审查输出和负责人。

图 2：发布记录把生产证据和下一轮意图连接起来。本图为原创重绘，概念参考 Anthropic 课程。

六个阶段要留下什么

阶段	提交的产物	Agent 可以做什么	人要保留什么判断
规划	intent.md	汇总原始资料、找出缺失约束、草拟成功标准	问题是否值得解决，范围是否正确
设计	spec.md、接口约定、原型	读取现有系统、生成设计、标出规则冲突	方案取舍、风险接受、体验标准
开发	plan.md、代码、测试	分析仓库、拆解步骤、实现并运行检查	是否接受计划，敏感操作是否放行
测试	测试结果、Eval、审查意见	复现缺陷、执行确定性检查、按书面规则审查	行为是否符合需求，剩余风险能否接受
部署	发布记录、审批、回滚锚点	准备产物、核对门禁、执行已获准步骤	生产时间和最终授权
运维	指标、事故记录、新的 intent.md	诊断异常、整理证据、准备修复变更	是否回滚、是否升级事故、是否进入下一轮开发

先写一份能用的 intent.md

一句功能描述不足以让 Agent 判断范围。第一份产物不必写成长篇 PRD，但要说清五件事：现在有什么问题、结果要变成什么样、影响谁、哪些条件不能破坏、还有什么没决定。

# Intent: 用户自助查看退款状态

负责人：支付产品组
状态：草稿

## 问题
客服每天需要人工查询退款进度。用户无法判断款项仍在处理，
还是已经退回。

## 预期结果
订单页显示退款状态、预计到账时间，以及超时后的处理入口。

## 影响范围
订单前端、退款服务、支付机构状态同步、客服后台。

## 约束
- 不向用户暴露支付机构原始错误。
- 沿用现有登录和订单权限。
- 用户端和客服端使用同一套状态口径。

## 未决问题
- 部分退款如何展示？
- 超过预计时间后由谁接手？

产品负责人修正并接受这份文件后，再让 Agent 进入设计。方向不对时，团队只需修改短文档，不用等到 PR 快完成才发现目标错了。

团队要维护三类共享资产

编码助手可以让一个工程师更快。要让整个团队稳定复用，还需要能跨会话、跨项目保存的共享资产。

图 3：基础实践先支撑任务委派和评测，再进入自动化交付。这是一种建设顺序，不是强制产品清单；概念来源为 Anthropic Claude Academy。

Agent 能力资产

Skills、工具说明、仓库指令、Hooks 和小型脚本，负责告诉 Agent 在特定环境里应该怎么做。

• Skill 保存可重复执行的方法，例如外部 API 审查、发布验收和事故排查。
• MCP 可以把代码托管、文档、日志、监控和工单系统作为受权限控制的工具交给 Agent。
• Hook 可以阻止禁用命令、扫描密钥，或在生产操作前要求审批。
• 仓库指令记录构建命令、架构边界，以及团队已经纠正过的错误。

它们不能互相替代。Skill 说明做法，Hook 或 CI 执行硬规则。提示词不能代替权限控制、分支保护和发布门禁。

CLAUDE.md 和 Claude Code Hooks 是 Anthropic 工具链的具体实现。其他编码 Agent 有各自的仓库指令和命令控制。方法可以迁移，具体功能要按工具分别说明。

产研知识资产

Agent 需要当前的项目事实，不需要更大的一堆文档。需求、业务规则、接口、数据口径、测试证据、发布记录和事故复盘都应该有负责人，并能关联到对应代码版本。

一份实用的知识索引会记录负责人、影响系统、风险、正式资料、代码链接和最后复核时间。文档里的事实还要分清来源：

1. 供应商文档和合同声明。
2. 源码或配置确认的实现事实。
3. 在具体版本和环境中观察到的运行结果。

Agent 可以补链接、找缺项、起草更新。正式记录仍由系统负责人确认。

交付规则

流程把能力和知识连起来。普通文案改动可能只需要一页说明、一次构建和页面截图。支付改动还需要安全设计、接口测试、数据迁移、审批和回滚演练。

第一版用 Git、代码托管平台、CI 和人工审批就够了。团队先跑通一条真实流程，再决定是否建设统一平台。

AI 基础设施已经是开发流程的一部分

把模型 API 接进编辑器，只解决了单次调用。团队同时运行本地会话、CI 任务、客服 Agent 和生产自动化后，会遇到另一组问题。

层级	最小能力	解决的问题
模型接入	统一端点、模型目录、路由、超时和故障处理	工具不必为每个模型供应商分别接入
身份与权限	人员、CI、Agent 使用独立 Key；限制模型、IP、有效期和操作	单个身份泄露或死循环时可以单独撤销
预算与计费	团队统一资金，按成员、项目、Key 或任务分配额度和告警	费用能归属，异常任务不会耗尽全部预算
上下文与检索	版本化资料、权限继承、引用来源、复核日期	Agent 能区分现行事实、过期资料和无权内容
执行环境	沙箱、独立 Worktree、网络规则、命令白名单、密钥隔离	并行任务不互相覆盖，高风险命令有边界
质量控制	单元测试、集成测试、Evals、策略扫描、人工审查	模型、提示或 Skill 变化后可以检查退化
交付与观测	CI/CD、审批、回滚、调用日志、延迟、错误和成本	每次变更可以追踪、定位和恢复

团队预算需要单独设计。开发者本地会话、CI 和生产 Agent 不应共用一个不受限的 Key。它们可以从同一个团队账户取用资金，但每个调用方都要有独立身份、模型权限、有效期、额度和成本记录。

硬门禁要交给确定性检查

Agent 可以审查 Agent 写的代码，但不能成为唯一发布门禁。编译、类型检查、单元测试、接口契约、密钥扫描、分支保护和生产审批，都应该产出可由另一个系统复核的结果。

验收条件应尽量可运行：

• 修复缺陷时，先写能复现问题的失败测试。
• 前端改动同时检查构建和真实交互，并保留截图供视觉验收。
• API 改动检查鉴权、成功响应、错误响应和计费记录。
• 发布记录源码 Commit、产物校验值、活动版本和回滚版本。

不要让负责修复的 Agent 删除失败测试来换取通过。关键测试可以由仓库权限、Hook 或独立只读验证任务保护。

把真实失败变成 Evals

Eval 用来检查模型、提示、仓库规则或 Skill 变化后，Agent 是否还遵守原来的工作标准。第一批用例可以直接来自近期任务：一条反复出现的评审意见、一个真实缺陷、一次生产事故。

每个用例至少包含输入、允许使用的工具、预期行为和机器可检查的结果。除了通过率，还要记录失败类型、人工接管、一次通过率和成本。只有一个总分，很难知道哪里退化了。

用四周跑完第一轮

第 1 周：建立事实源

选一个代码库和一个正在发生的需求。写下最小仓库指令：构建和测试命令、目录边界、敏感操作、验收标准。再提交一份有负责人和未决问题的 intent.md。

第 2 周：跑通产物链

让同一个需求走完 intent.md → spec.md → plan.md → PR → release record。每个阶段只写下游真正会读的内容。记录等待时间、返工点，以及 Agent 因上下文不足而停下来的位置。

第 3 周：固化重复纠错

把重复出现的做法写进 Skill 或仓库指令。不可协商的规则交给 Hook 或 CI。再把一个真实缺陷加入测试或 Eval。

第 4 周：拆分权限和费用

给人员、CI 和 Agent 分配独立身份，设置模型权限、有效期和预算。确认日志能按项目和调用方查询，并演练 Key 撤销、任务终止和发布回滚。

跑完以后，团队才有证据判断是否需要流程平台。没跑过真实闭环之前，这个决定大多靠猜。

衡量交付，不衡量代码产量

生成了多少行代码、消耗了多少 Token，只能说明系统很忙。它们不能说明软件是否更快、更稳地交付。

方向	更有用的指标
交付	从意图确认到生产上线的时间，各阶段等待时间
质量	一次通过率、回归缺陷、回滚次数、事故恢复时间
知识	正式资料覆盖、索引失效、过期文档、因缺上下文产生的人工接管
Agent	任务完成率、失败类型、人工接管率、每个成功任务的模型成本

不同风险使用不同门禁。低风险文字改动不必走支付迁移的流程；高风险改动也不能因为代码生成得快，就省掉证据和审批。

常见问题

AI 原生 SDLC 会让 Agent 自己发布代码吗？

不会。Agent 可以执行更多步骤，但生产授权、职责分离和风险接受仍由组织规定。开发环境可以放宽操作范围，生产环境应为敏感变更保留明确审批。

必须使用 Claude Code 吗？

不必。Anthropic 课程使用 Claude Code、CLAUDE.md、Skills 和 Hooks 展示具体做法。可提交产物、确定性检查、独立身份和人工门禁同样适用于其他编码 Agent。

已经有知识库，为什么还要把 Markdown 放进版本控制？

Agent 需要知道哪一版有效，以及资料和代码变更如何对应。版本控制提供差异、作者、时间和回滚。只要知识库能保留这些关系，它仍然可以作为阅读入口。

什么时候需要统一 AI 平台？

当多个项目反复需要相同的模型接入、身份、预算、检索、Eval 和审计能力时，统一平台才开始有价值。先用 Git 和 CI 跑完一条产物链，再根据暴露出来的约束决定自建还是采购。

团队怎么控制多个 Agent 的费用？

为人员、CI、项目和 Agent 分配独立 Key，分别设置模型范围、有效期和预算。资金可以统一管理，用量要按调用方记录；异常循环应在耗尽剩余预算前自动停止。

参考资料

• The AI-Native SDLC Playbook，Anthropic Claude Academy
• Claude Code 概览，Anthropic 文档
• Model Context Protocol 文档

第一次试行时，选一个正在发生的需求，提交它的 intent.md，再跟着它走完设计、开发、审查、发布和线上反馈。途中记录的等待、返工和人工接管，才是下一轮需要改的地方。