Anthropic最新分享:AI 原生的软件开发手册

在 Coding Agent 出现之前，六步都按人的速度走，Build 那一截耗时最长、投入人力也最多。

现在，再多的功能，Build 的投入也是一条细缝。但是，对于很多团队来说，Plan、Design、Test、Deploy、Maintain 还没变，人仍要盯需求、做测试、review、点放行。最后空出来的那一块，图上标成 cycle time reclaimed。时间省下来了，流程没跟着改，省下的时间就会还得拿来排队。

传统软件开发大概六步：Plan、Design、Build、Test、Deploy、Maintain。每一步换一拨人。

产品写需求，架构出设计，工程师做开发，QA 验，发布组上线，运维盯线上。中间靠会议、文档、工单、签字进行传递。

这套东西是为另一个年代设计的，那时候工程师最多，coding 最贵、最慢。

因此，出现了 PRD、工时、排期、安全 review，都是为了在几周到半年的时间周期内，把人和人的工作对齐。控制手段也默认每一步都是人做的：一行行审 diff。

这套东西，在现在 Coding Agent 负责产出大量代码之后，它就跟不上了。

现在，瓶颈变成开发的左边和右边，速度还是人的速度。控制跟不上实现，人审不完代码。甚至每周、每月才开一次的会，变成了最大的阻碍和成本。

Anthropic 在手册里用安全举了个例子。安全团队还是老样子，但是 Agent 把单位时间内的代码量翻了上百倍，只剩两条路：慢慢排队 review，或者只能不审了。受监管的公司不敢做后者，所以安全检查也得跟上 Agent 的速度。

左边是传统流程，一条线，从 Plan 到 Maintain 从上到下。绕回去一次，就是一轮新发布。

右边是手册里的 AI 原生软件工程：一个圈，Agent 在中间，人在圈上面。人发起、决策、把关，圈自己转，一轮大循环按小时计算。

每一步结束，往 repo 里提交一些内容东西，下一轮循环，紧接着就开工。

前面几步主要是产出 markdown 文档，产品负责人和 Agent 读同一份文件，对同一份文件动手。从开发阶段开始，产物变成代码和记录。commit 历史本身就是最清晰的轨迹：谁要的，Agent 写了什么，谁提交的。

人还是要对需要判断的决定负责，只是人看的东西变了。不再看每一行代码，而是看 Review Agent、QA Agent 标出来的问题。

刚开始，先用人 + Agent 走这个循环的每一步。走到后来，逐步增加条件，让每一个环节的产出文件，能自动触发下个环节：intent.md定稿了，就做需求和设计；spec.md定稿了，就进 plan mode；PR merge 进去，就跑 pipeline；线上指标越线，再写一份新的intent.md。圈继续转。

手册里，Anthropic 把做法拆成一组 play，可以从任何一个环节开始。

橙色那一排没有前置依赖：Capture intent、CLAUDE.md、Feedback loop、Hooks、Plan mode，可以从任意一处启动。

黑块是后续环节，Skills、Subagents、Evals、PR review、CI/CD。

最后才是 Closing the loop。

有了这个手册，每个软件团队，就可以先改损耗最大、痛点最强的那一个环节。

下面按手册本身的六步写。例子都来自原文。

以前一个想法要过待办、用户故事、故事点、评审会，才能有人动手。传到工程师手里，已经离提出的人隔了好几层，每交一次手，信息就损耗一部分。

现在提出的人（可以是一线员工）用自己的话跟 Agent 聊：现在缺什么，谁受影响，更好的形态是什么，什么不在范围内。

不必上来就写正式需求，Agent 会分析并提问：范围、用户、限制、怎样算做成。

聊清楚了，让 Agent 按团队模板写成intent.md，提出的人改掉它理解错的地方，再提交到大家共用的地方，接下来就是产品负责人的活。

只要搭好了项目仓库，定下来谁能写、写到哪儿，所有人都可以使用，哪怕不会用 git 的人，也可以让 Agent 代为 commit。

原文例子：理赔状态自助查询的 intent，作者是理赔运营岗位的 J. Ortiz。

痛点是：客户打电话问案子到哪了，坐席大约三分之一通话时间耗在这类状态问题上。Ortiz 希望客户能在门户里看见自己的状态、下一步、预计日期。约束是：门户会话里不加新的个人敏感信息，只用现有登录。Ortiz 还留了一个开放问题，第三方人员要不要也能看到这个状态。

产品负责人收下这份文件，就可以进入 Design。如果拒收也没关系，不管是 merge 还是 close，都算一笔账。

在这个环节中，团队能采集到两类指标：

后一项高了，说明 intent 配套的 agent 需要加强提问和澄清能力。

intent 收下之后，Agent 可以按公司的品牌、安全、合规、体验规则，写出需求和设计说明。这些规则都是团队预先写好的 skill。产品负责人不用每次都自己去审核思考。

设计到实现的工作更简单：在 Design Agent 里对着 intent 出稿，改完交给 Coding Agent 去做。

在这个过程中，产品规则也是前置的，不需要等到几周后 review 才提出来。一开始就用 skill 发现和执行这些规则，遇到问题、说不清楚、规则打架的地方，都可以更早发现。

产品负责人要问自己两句。这份文档里解决的问题对吗？intent 里的开放问题，如何决策？

高风险的事还可以拉上技术负责人一起来决策，并决定进入下一步。

在这个环节中，主要采集的指标：

通过这个数据，来优化对应的 Agent 和 skills。

工程师打开 Agent，先走 plan mode，对着已经收下的 intent 和 spec，问它三件事：要改哪些文件，什么顺序，用什么 test 。还要追问可能弄坏什么、哪一步风险最大、还有哪些可选方案。

plan 能让没参加过前面环节沟通对话的人独立完成，产出plan.md，然后才开始动手开发。

原文中的理赔例子，产出了这样一个 plan：

如果发生了偏离，可以对 plan 进行修改，也可以用 hook 机制确保 plan 和不要偏离。

如果是常规改动，工程师自己就可以完成 plan；如果 Agent 发现是高风险环节，还可以交给技术负责人去定，并发起设计 review 对文档进行修改。

手册里还提到了 auto mode。Agent 基于 plan 开始执行后，不必每改一个文件都问人，可以在 AGENTS.md、skill 里规定好团队的规则，用 hook 拦截危险动作，让 Agents 自己去跑测试。

人不用再看每一行代码，而是跑完之后交出来的总结和意见。

工程配套成熟后，一个工程师可以同时开好几个任务。互相隔离的任务各开一个 worktree，逻辑接近共享文件的也可以放在同一路里按顺序做。

刚开始，可以先开 2、3 个并行任务，让一个人还审得过来。如果有反复出现的活做成 subagent，比如一个验证 subagent：它只启动应用，执行修改后的业务代码，对照plan.md，总结情况。

习惯不再停留在经验里和 wiki 里，而是变成仓库内的 AGENTS.md、skills。Agent 每次开工都会先读它，里面写上所有新人上岗都需要知道的规则：怎么 build、test、lint，哪些约定动不得，架构怎么分层，以及它常犯的错。

原文例子：一个支付服务的 AGENTS.md 的内容：Java 21，Spring Boot 3，不准新上 Lombok；钱必须用 BigDecimal，不准用 double；每个接口都要有 integration test；依赖版本不归它涨，归平台组；老的 v1 包冻结，改动去 v2。

如果犯过两次的错误，就把纠正写进去。同时控制长度，移除古早的问题，很多早期问题随着模型进步，已经不会再出现。

团队里，做事执行的规矩，写成 skill。必须执行的，再加 hook，比如不准改 generated 文件，改完立刻跑 formatter，凭证不许进 diff。

需要人审批的 hook，不要放在开发过程当中。否则效率就起不来。把这种需要人审批的节点 hook，放到 deploy那一步。

老系统也可以充分利用：工单可能在 Jira，日志有别的工具，设计在 Figma。

每一种产物，确定一个初始源头，其余的用好链接。你可以做成以仓库为准，老系统只引用；也可以做成 Jira 说了算，仓库里的文档只做副本，并且保证同一轮 Agent 任务里要同步回去 Jira。最低限度是互相记录引用：文件里写记录编号，老记录里写 commit SHA。

这样就能保证新老系统同时跑起来。

如果开发环节不能马上测试，下一步的人，就得把 Agent 的产出全看一遍。让这个环节重新变成瓶颈。

所以，每次 Agent 会话内，都要尽量完成自检：跑 test，跑 构建，对截图。先自己改好，再交给下一环。

在 AGENTS.md 里写清楚，比如：怎样的输出算健康、test 全绿，截图对得上设计稿，接口返回 200 并且带上新字段，等等。

修 bug 时，要用 TDD 的方式，先写成会失败的 test，让它复现，确认失败原因是准确的。

先 commit 这份 test，再让 Agent 改代码，并且不许 Agent 在过程里改 test。可以用 hook 可以在修复任务里锁住 test 文件。一份 Agent 改不了的旧 test，才是 bug 消失的证据。

界面的工作，把浏览器或截图工具权限给 Agent，让它自己能够对照稿，做、拍、比、改。两三轮很正常。「做完」必须包含验证，输出贴出来。

Agent 的配置也要像代码一样做回归。AGENTS.md、skill、hook 每次修改，就要执行一套 eval。

要从最近的真实任务中，找到 20 到 50 个任务，每个任务写明 prompt，以及怎样算过关：test 过，lint 过，行为没变，政策没破。如果通过率掉了，说明这个新配置不能合并。

线上事故更重要，变成一条长期留存的 eval，由当时负责那次事故的组来提供。

在这个环节中，团队能采集到四类指标：

让 Agent 审别人的 PR，也处理自己 PR 上的意见。人只看两件事：这次改动是不是 plan 里要的，风险能不能接受。

不允许 Agent 自己批准自己写的代码。用仓库的分支规则、Code Owner 来保证这一点

技术负责人可以把 review 政策写成仓库根目录的REVIEW.md，过三遍：逻辑错误和边角，安全和漏洞，以及改动是否对得上 spec、plan 和设计原则。什么叫重要，什么叫轻微，什么跳过，都写死。风格和命名属于轻微；会破坏行为、漏数据、破政策的，才标重要。问题最多报五条，其余只报个数。如果是 pipeline 已经会拦截的，不需要再报问题。

Review 评论中留下记录，Agent 改完推上去，也得在 PR 留下记录。它自己开的 PR 可以一直监控、循环，扫未解决的意见和失败检查，一直改到只差 Code Owner 同意。

review 中多次出现的错误，写进 AGENTS.md，下一份 PR 就不会出这个问题。技术负责人每月至少要调一次，给找出的问题打分，把轻微的量压下去。

到生产门口，hook 会停住。Agent 可以一路负责，一直到生产门口，但是接下来就不允许它操作了。手册里的例子是：命令里同时出现 deploy 和 production，又没有放行令牌，直接拦住；拦住时，告诉 Agent 是什么原因，要找谁授权。

开发环境，Agent 可以自己发。生产发布，必须放行人授权。staging 关键是掌握回滚能力，可以用一条命令，在发布之前，在 staging 环境里去演练一次版本回滚的能力。这样，后续上线一旦需要回滚，不会出现问题

pipeline 里也可以让 Agent 来参与判断工作。比如，build 失败了，读日志，判断是偶发还是要修复，评论到 PR 上。

pipeline Agent 可以补文档、改 lint、回 review 意见，但是仍然要走 PR，关掉直推 main 的路。

如果任务跑在 sandbox 里，用短时、最小的令牌，不允许任何生产的凭证。

部署、状态、回滚，要通过连接器暴露，按环境列白名单，不要让 Agent 自己生成命令。

到了维护这一步，就可以自动触发了。

日常值守不用 AI。用确定性脚本分析线上指标，选一个有稳定滚动基线的数，比如 pipeline 失败率、发布后的 5xx、PR cycle time，按滚动窗口算均值和标准差，把慢漂和尖峰都抓住。

指标超过阈值了，让 Agent 参与进来。例如：一倍标准差只记日志，两倍要进行只读诊断，三倍让 Agent 去行动。

Agent 行动必须按规则走：开一份 PR 进 review，或者触发事先批准过的 runbook，比如回滚。

Agent 可以把诊断写成一份新的intent.md，写清异常是什么、证据是什么、希望怎样、波及谁、还有哪些问号，然后重新进第一步的流程。

运维工程师自己就可以分诊：现在修、排期、或者驳回。

驳回是为了降低并发带宽，或者减少异常噪音。修完了，记得把事故处理补成一条新的 eval。

原文例子中的规则：pipeline 失败率到三倍标准差，隔离 flaky test，或者开一份 revert PR。

发布后，出现 5xx 触发三倍的阈值，并且 Agent 分析，窗口里刚发过版，触发现成的回滚规则。PR cycle time 出现漂移，Agent 给工程负责人写报告，发到 Slack 里。

这是原文里的故障频道#inc-checkout。Agent 以自己的身份在频道里。

请求、诊断、授权、修复，都留在频道里。小修复直接开 PR，更大的事写成 intent，进入下一个循环。

Anthropic 这本手册中，我们看到，AI 原生不是让公司把人裁掉。它是让人从「全程执行」变成设置合适的决策参与点，「做好每一次决策」。

intent 需要人来接收，spec 需要人来确认，plan 需要人来实施，上生产环节需要人来同意，出问题之后需要人来授权决策怎么修复。