Anthropic公开AI Native手册，从需求到上线讲透了！

Anthropic 内部约80%的代码由 Claude 生成，工程师的人均产出是过去的8倍。

但一个反常的现象出现了：代码写得越来越快，软件交付速度并没有同步变快。

原因是最慢的环节已经转移到代码之外的场景了。Anthropic 重做了编码之外的所有事情，从需求到上线的整条流水线。他们把做法整理成了一份公开手册，如下：

https://claude.com/blog/the-ai-native-sdlc-playbook
姊妹篇：
https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle
https://claude.com/blog/running-an-ai-native-engineering-org

本篇不逐条翻译，我们跟一条需求走一遍：它怎么变成文件，流程怎么自己跑，人在哪几道门前守，事故从哪回来。

代码不再是最贵的环节，旧流程反而开始卡人

过去的开发流程，全部建立在一个前提上：编码最贵、最慢。

所以产品经理要先写清需求，架构师要先做设计，工程师再动手，测试团队验证，发布团队上线。工作靠文档、工单、评审会和层层签批，在不同角色之间传递。这套流程本来有它的道理。人写代码的时代，提前对齐需求能省下几个月的返工。

但当 AI 能批量生成代码，前提变了，问题也变了。

第一，瓶颈转移。构建阶段被压到小时级，规划、审查、测试、部署还在按人的速度运转。

第二，管控失配。人写的代码，逐行审查还能跟得上。AI 一次生成几十个文件，再靠人逐行看，审查队列只会越积越长。

第三，治理成本变高。高风险操作和例外事项还在等委员会开会，代码却每天都在变，周会月会追不上。

Anthropic 的解法没有直接砍掉这些流程，而是把流程里所有靠人工交接的部分全部换掉了。

交接的不再是文档，而是制品

制品是指这套流程里每个阶段留下的正式文件。人可以看，同时被机器用，还能当审计记录。这篇文章里出现的 intent.md、plan.md、代码和事故记录，都是制品。

传统流程里，需求靠会议和文档，在人之间一棒一棒传。每一棒都可能丢信息，传到最后，离最初的想法已经很远。

Anthropic 的做法是：每个阶段结束时，把一份制品写进版本控制。下一阶段不从开会开始，直接从这份制品开始。

我们拿官方手册里的例子来看：一家保险公司，客服每天都在电话里回答同一个问题："我的理赔到哪一步了？"接线员约三分之一的时间，花在这种纯查询上。

放在过去，这个想法要变成用户故事、故事点、排期会，几经转手才能到工程师手里。现在，理赔部门那位同事直接在聊天窗口里，用自己的话把这个想法告诉 Claude。AI 像分析师一样追问：影响哪些用户、牵扯哪些系统、有什么约束。问清之后，一份 intent.md 就写出来了：

# Intent: 理赔状态自助查询
要解决的问题
客户打电话来问理赔进度，接线员约三分之一时间花在纯状态查询上。
期望的结果
客户在门户网站直接看到理赔状态、下一步和时间预期。
约束
门户会话不新增任何个人敏感信息，沿用现有登录。

提出人校对一遍，提交进版本控制。谁提的需求、讨论后改了什么、什么时候确认，都留在提交记录里。

这份文件通过后，设计阶段自动开始。AI 读着 intent.md，再读团队已有的品牌、安全、合规规则，生成 spec.md。官方手册把这一步的提示词原样贴了出来：

读一下附上的 intent.md，产出一份把它接入现有代码库的需求与设计规格。
用上你可用的所有 Skill，让方案符合我们的品牌规范、安全策略和用户体验标准。
把规格完整写成 spec.md，交给工程团队可以直接开工。
哪些地方有顾虑，尤其是相互冲突的规则你满足不了的地方，明确标出来。

产品负责人不写这份规格，但要审它。

spec.md 要写清：展示哪些字段、数据从哪取、接口超时怎么办、第三方理赔人员能看到什么。发现顾虑，负责人和对应的策略、合规、安全团队一起解决，最后再由人确认提交。

spec.md 被确认，进入计划阶段。AI 读代码库，产出plan.md：改哪些文件、按什么顺序、风险在哪、拿什么证明完成。计划没被接受之前，AI 一行代码都不能写。

到这里，这条需求的一生已经有三个节点。需求从"人告诉人"，变成了"制品告诉制品"。

还有一步：接受一份制品，就触发下一阶段。

intent.md 被批准，设计自动开始。spec.md 被确认，实现才被允许。plan.md 被接受，AI 才能动手改代码。代码合并，流水线自动跑起来。生产出问题，新的 intent.md 自动生成，流程回到起点。

过去靠项目经理催、靠会议推的事，现在由制品状态自己驱动。

到这一步，可以先做一个对比。

市面上已经有不少团队，用 AI 把单个任务跑出了流水线。比如腾讯云开发者团队把一个服务重构任务拆成五步：链路分析、方案审查、编码、代码评审、自动化测试。每一步都有明确的输入产出，有 Skill 承载知识，有验证循环兜底。

但它仍然是任务级流水线。五步的每一棒，都是人发起命令、AI 执行、人审查通过，再进入下一步。还是人站在每一个交接点上。

Anthropic 的区别就在这里：人从交接点退到了门外，只守需要判断力的位置。链条内部的传递，交给制品和触发器。这是组织级闭环和任务级流水线的分界线。

让流程自己跑的，是三台发动机

制品链解决"信息怎么传"。流程要真的自己跑起来，还需要三层机制。这三层各有各的模板，官方手册都给了样例，团队照着改就能用。

第一层，上下文：让 AI 知道该怎么做。

CLAUDE.md 放在项目根目录，记录构建和测试命令、各目录负责什么、哪些地方不能碰，还有 AI 反复犯过的错误。手册给的样例如下，一个支付服务的项目，文件长这样：

# 支付服务

命令
构建：make build
测试：make test（单元）、make itest（集成，需 Docker）
检查：make lint（CI 里跑，推送前必须通过）

约定
Java 21，Spring Boot 3，不再引入 Lombok。
金额一律用 BigDecimal，不用 double。
每个接口都要有集成测试。

架构
api/ 放控制器，core/ 放领域逻辑，adapters/ 对接外部系统。
Claude 常犯的错
不要升级依赖版本，平台团队统一管理。
v1/ 已冻结，改动一律进 v2/。

维护原则只有一条：同一个错误犯两次，就把纠正方法写进去。文件控制在一页以内，因为 AI 每次会话开始都要读它，塞多了反而稀释注意力。

Skills 更聚焦，把某一类反复出现的任务沉淀成可复用的步骤。比如 API 安全标准，手册里就有个现成模板，文件开头写清什么时候触发：

name: secure-api-review
description: 创建或修改对外接口、审查 API 代码、生成接口文档时，用这套 API 安全标准。
每个接口必须做到：
认证：一律走网关 JWT，除了 /health 之外没有匿名路由。
入参校验：请求体必须对照接口文档校验，拒绝未知字段。
审计：每个改状态的接口都要留一条审计事件，带执行人、动作、对象和时间。
数据分级：接口文档里标了个人敏感信息的字段，绝不能出现在日志和报错信息里。

安全规范就这样写进 Skills，AI 生成代码时就会遵守，而不是等评审时才发现问题。

第二层，证据：AI 说"完成"不算数。

AI 必须自己跑测试、执行构建、比对结果，改到真正通过为止。为了避开"自己检查自己"的盲区，最后还要开一个全新会话只做复核。这个复核者的定义，手册里也有模板：

name: verifier
description: 在会话汇报完成之前，把应用跑起来，确认改动真的能用。
可用工具：Bash、Read
用 make run 启动应用。把改动的行为和它旁边最近的两条流程都跑一遍。报告你跑了什么、看到了什么、哪些行为和 plan.md 对不上。不要修任何东西，只报告。

它只报告，不动代码，专门用来防止"写出代码的 AI 自己检查自己"。

换模型、改规则时，再用一组固定任务做持续评测，确认没有退步。线上出过的每个事故，都要写成一个评测用例，防止下次升级再踩同一个坑。

AI 的完成声明不可信，只有工具链的输出才算证据。验收标准写进 CLAUDE.md，比如"测试全绿、构建成功、截图和设计稿一致"，AI 交活前必须自己先跑一遍，把输出贴出来。

第三层，边界：有些事不能做，得拦下。

这里用到的机制叫 Hooks。你就当它是个程序卡口：AI 每执行一个动作前，系统先过一遍卡口，三种结果，放行、拦下、停下来等人授权。

AI 改受保护文件、读敏感信息、执行发布命令，卡口立即检查，不符合就直接拦下。手册给了一个生产门禁脚本，逻辑只有几行：

#!/bin/bash
# 生产发布必须拿到指定的发布授权
如果命令里同时包含 deploy 和 production，但环境里没有 RELEASE_APPROVAL 授权：
打印"生产发布需要发布授权"，然后拦截这条命令。

卡口拦下时会把原因告诉 AI，AI 就知道这条路走不通。

三层机制的分工，一句话就能说清。上下文让 AI 更可能做对。证据让 AI 必须证明做对。边界让 AI 不能做错某些事。它们的共同点是全部写成代码、版本化、可以被审查。

人没有退出，只是从执行者变成守门人

在任务级流水线里，人站在每一棒的交接处。在 Anthropic 的模型里，人只守四道门。

第一道门在入口。产品负责人确认意图：intent.md 有没有理解错需求，这个问题值不值得做。回到理赔那个例子，产品负责人要在合并前回答：门户加这个查询，值不值；"第三方理赔人员要不要看"这个开放问题，是当场回答还是继续挂着。

第二道门在动工前。工程师和技术负责人质询 plan.md：最大风险是什么，有没有更简单的方案。理赔例子的计划里就有一条风险：核心接口有每秒 50 次的限流，前端必须做缓存。这类判断，方案没被接受之前就得摆上台面。

第三道门在上线前。发布必须经过具名负责人授权，刚才那道 Hook 会拦住发布命令，直到授权发生。这是 AI 自治的终点。

第四道门在运行期。治理的人抽样复核 AI 的自动审批，检查 Skill 有没有过时，观察整个闭环是不是还在正常运转。

人的价值，从"完成事情"变成了"判断事情该不该这样完成"。代码可以交给机器，流程可以让系统自己跑，但每道门都要有人签字。

生产事故不是终点，是下一轮需求的起点

这条链的最后一环，在线上。

监控系统持续观察错误率、延迟这些指标，越界分三档处理：轻微异常只记录；明显异常，AI 进来诊断；严重异常，AI 可以提修复 PR，或者触发预批准的回滚。

这里有个顺序问题。确定性的监控先发现越界，AI 再进来分析和提议。"感觉不对"这种判断，轮不到 AI 自己做。

诊断结果被写成新的 intent.md，流程重新启动。

JOTO 企业落地观察

• 对企业部署意味着，AI Native 流程并非“一键替换”，而是一套需深度嵌入现有研发资产（如 CI/CD、权限体系、监控告警）的协同框架。企业若缺乏标准化制品定义能力与版本控制文化，强行引入易导致制品链断裂。
• 这类系统的取舍在于：是否愿意将“流程控制权”从项目经理移交至代码化的触发器与钩子（Hooks）。这要求组织具备将治理规则转化为可执行代码的能力，而非仅依赖会议与审批。
• 对 RAG 知识工程而言，CLAUDE.md 与 Skills 文件本质是结构化知识源，其有效性高度依赖人工持续提炼与验证。RAG 若仅索引静态文档，无法替代这种动态演进的上下文供给机制。
• AI 安全治理的关键落点从“代码审查”前移到“意图校验”与“边界拦截”。企业需将安全策略显式编码为 Hooks 和 Skills，而非事后审计，这对安全团队的工程化能力提出新要求。