Anthropic发布AI开发手册！核心瓶颈不在代码，而在流程协同改造

上周，Anthropic 发布了《The AI-Native SDLC Playbook》。我最近把这份手册完整读了一遍，收获很大。过去我们讨论 AI 开发，注意力经常停留在模型能写多少代码，这份手册把问题推进到了代码之外

这份手册讨论的核心，是怎样把一次次临时对话变成可以持续运行的项目系统。需求要被记录，计划要在写代码之前接受审查，Agent 必须验证自己的工作，生产环境继续保留人的决定

传统软件开发流程建立在一个长期成立的前提上，写代码通常是最耗时的阶段。一个功能可能需要几周才能完成，PRD、估时和安全审查围绕这个速度安排。Agent 改变了代码生产的时间尺度。构建阶段被大幅压缩，构建前后的流程却没有同步变化。一个没有说清楚的目标，可以迅速变成大量已经写完的代码

审查也会被同一种速度差拖住。过去逐行检查合理，因为代码由人逐行写出。Agent 开始生成大部分改动以后，人工审查速度无法和代码产量一起增长，审查队列会不断累积。部署与治理面临相同压力。例外仍然等待每周或每月的会议，安全团队的配置也来自过去的人类产出量。代码量被放大以后，原有审批节奏已经承接不了相同的控制目标

Anthropic 因此提出，传统软件开发生命周期需要经历一次与代码实现阶段同等程度的改造。DORA 在 2025 年的研究中也把 AI 称为组织能力的放大器，流程清楚的团队得到加速，原有问题同样会被放大。团队不能再把提交了多少代码当作主要进展，影响交付的是有效需求通过审查、验证和部署的速度

生成速度不会自动缩短项目周期。需求仍在等待人整理，测试结果要到几天以后才能返回，Agent 节省下来的时间就会重新消耗在等待中。更糟的情况是，团队同时启动更多任务，最后得到更长的审查队列和更多没有验证的改动。代码数量上升，并不代表产品价值同步上升

AI Native 要改造的是从想法出现到线上反馈回来的一整条工作链

AI Native SDLC 把线性流程改成循环，AI 被放进规划、设计和构建环节，后续的测试、部署与运维也由同一套产物继续推动。开始时，人可以手动提示每个阶段。边界稳定以后，上一个产物被接受这件事，就能自动触发下一个任务

贯穿流程的是一条提交产物链

intent.md → spec.md → plan.md → 代码与测试 → PR 与审查结论 → 事故记录或新的 intent.md

每个阶段先读取上一个产物，再提交下一个产物。通过审核的 intent.md 触发设计，spec.md 被接受以后进入实施计划，合并后的 PR 进入部署。线上指标出现异常时，系统生成新的 intent.md，流程回到起点。产物链先解决交接问题。已经确认的意图与约束进入版本控制，下一个角色和 Agent 可以直接从确定结果继续工作，不需要重新翻阅全部聊天记录

它也承担触发和审计。谁提出需求，Agent 生成了什么，计划修改过哪些地方，最后由谁批准，都留在同一条历史里。团队不必把 Jira 或 Figma 全部迁移成 Markdown，但每一种产物要指定唯一的事实来源，其他系统只保存副本或链接。早期阶段常用 Markdown，是因为产品负责人和 Agent 都能直接读取并修改，进入构建以后，代码、测试结果和 PR 继续接在同一条链上。人的责任没有被删除。Agent 负责生成和执行，涉及意图、风险与是否进入下一阶段的决定仍然由人承担

产品负责人负责对照原始意图审查规格，检查它是否解决了最初的问题。Agent 无法满足的要求与规则冲突必须被标出来，不能在进入开发以后再依靠工程师猜测。高风险内容由技术负责人共同判断。只有人接受 spec.md，项目才进入构建

spec.md 因此不只是一份写得更完整的 PRD。它要把原始问题转成可以实施和验收的设计，并把尚未解决的矛盾继续带到决策者面前。Agent 可以生成规格，不能替产品负责人决定哪个取舍值得承担

我现在所在公司的一个大型开发项目只有五个人，团队角色是产品经理和开发工程师，不再设置独立设计师。PRD 初稿和代码都由 AI 生成，人负责修改、批准、测试和验收。这只是我们当前项目的组织方式。项目不再设置独立设计师，不代表用户体验责任也一起消失。用户路径、交互约束和完成标准需要更早进入 intent.md 与 spec.md，产品经理和工程师再对最终结果负责。否则 AI 会按照不完整的要求快速执行，把前期遗漏变成后期返工

Auto Mode 适合规格清楚、影响范围较小，并且已经有测试覆盖的常规工作。高风险任务仍然需要更多人工检查。自主程度跟着护栏成熟度增加，团队不会因为 Agent 能够连续工作，就立刻放开所有权限

需要跨任务复用的组织经验可以写成 Skill，由团队统一维护。安全标准或前端规范发生变化时，团队修改同一个版本，下一次相关任务会自动加载。Skill 仍然属于建议，必须执行的限制要交给 Hook，例如保护不能修改的路径，或者在代码变更后自动运行格式检查。Hook 要保持快速，完整测试等重检查留到提交或 PR 阶段

计划把任务拆开以后，工程师可以在不同 worktree 中同时运行多个会话。手册建议从两到三个开始，重复而边界清楚的验证工作可以交给 subagent。并行数量取决于人的审查能力。工程师可靠审查不了的产出，只会变成新的等待队列

验证信号来得越晚，需要人工检查的 Agent 产物就越多，工程师很快会成为新的瓶颈。证据先到。完成声明放在后面

这些问题没有让我们退回原来的开发方式。它们说明代码生成能力与验证能力必须一起建设

单个任务的反馈回路只能证明这一次修改通过检查。模型升级或者 Prompt 变化以后，Agent 的整体行为也可能改变，Skill 与 Hook 的调整同样需要回归测试。Anthropic 把这套回归测试称为持续 Eval。手册建议从近期工作中收集二十到五十个真实任务，保存已经接受的结果，再写清测试、行为和规则方面的完成标准。Agent 配置变化时，Eval 在持续集成中重新运行，表现下降的改动需要重新审查

Claude 处理审查意见以后可以再次运行检查，直到 PR 只等待代码负责人批准。审查中第二次出现的错误继续写回 CLAUDE.md，下一次生成和审查都会读取它。一次返工因此获得了长期价值

机械检查交给 AI，人判断实现是否符合原始意图，以及剩余风险能否被接受

AI Native 团队扩大 Agent 的执行范围以后，生产权限需要一条清楚边界。Agent 可以完成发布前的准备，最后一次生产部署仍然需要指定人员授权。Hook 可以在部署前暂停操作并等待批准。团队先列出必须保留的人工门禁，再把它们写成每次都会执行的规则。无法协商的门禁由平台管理员控制，项目成员不能在本地关闭。门禁阻止操作时还要说明原因与授权路径，Agent 不必猜测下一步

权限还要跟着环境变化。Agent 在开发环境可以拥有更高自主权，预发布环境开始收紧。到了生产环境，它只负责准备发布。自动化任务运行在沙箱中，使用范围受限的短期凭证。分支保护确保 Agent 的改动只能通过 PR 进入主分支，没有直接修改线上代码的路径

每次非交互式运行还要使用 Agent 自己的身份。流水线日志因此能够分开记录 Agent 做了什么，以及哪位工程师触发了这次运行。权限越大，操作来源越需要可以追溯

团队可以通过 MCP 把部署、状态查询和回滚封装成独立工具，再按环境开放。Agent 获得的是一份工具允许列表，不是一段携带完整凭证的任意脚本。即使它判断出错，影响范围也被限制在允许使用的工具内。回滚要在故障发生以前完成演练。手册建议把它做成一条 Agent 可以直接运行的命令，并定期在预发布环境验证

线上故障发生时，团队没有时间让 Agent 临时阅读一份复杂手册，再猜测哪个步骤仍然有效。先恢复服务。已经演练的回滚命令让 Agent 在授权范围内执行确定动作，后续诊断再进入正常审查流程

部署完成以后，确定性脚本持续监控测试失败率或服务错误率，检测本身不交给模型。指标越过预先设定的范围，Claude 才会被调用。轻微偏移只留下记录，进一步偏移让 Claude 进行只读诊断。严重异常允许 Agent 开一个 PR，或者触发事先批准过的回滚流程

例如服务错误率在一次发布后突破控制范围，Agent 可以启动已经演练的回滚流水线，再把异常证据与待确认问题写入新的 intent.md。小修复作为 PR 回到审查门禁，范围更大的问题重新进入规划阶段。负责人决定立即修复、排期处理或关闭问题，事故案例则进入 Eval

响应等级保存在版本控制中，团队可以审查每一级允许 Agent 做什么。检测脚本只负责判断指标是否越界，Claude 在触发以后负责诊断和提出行动。这个顺序把概率判断放在确定性触发器之后，避免模型自己决定什么时候应该介入生产环境

一个想法可以启动 intent.md，一次线上异常也可以重新启动它。循环继续运行，人的判断始终留在意图、风险和生产授权这些位置

Anthropic 的手册主要写给已经使用 Claude Code 的大型企业，尤其是需要处理治理和合规要求的组织。创业团队通常没有平台工程师，也承担不起一次建设完整 Eval 平台与分级门禁的成本。手册中的各项实践本来就是模块化的，小团队可以先建立最小循环，再根据真实错误增加规则

小团队不需要从二十到五十个 Eval 案例起步，也不需要第一天就实现自动运维。先让每次需求留下相同产物，让 Agent 能够运行验证命令，再守住生产授权，已经可以改变项目的基本运行方式。小团队先做到可重复

这四步把开发前的意图、开发中的约束和完成后的验证接在一起。团队开始时可以手动触发每一步，等交接边界稳定后再自动运行。最小版本的目标是减少重复解释和重复犯错，不是追求第一天就实现无人自治

这是我基于实践形成的判断，不是 Anthropic 的官方结论。对于正在 AI 产品市场里用有限资金争取验证窗口的创业公司，AI Native 已经关系到团队的生存能力。创业团队最缺的是时间和现金，每一次方向错误都会消耗有限的产品验证窗口。使用 AI 生成代码只是起点。需求继续依赖反复转述，测试和审查继续由人排队完成，团队得到的主要是更多代码，原有瓶颈依然存在

小团队等不起。一个版本多花一周才能确认方向，会增加开发成本，也会减少下一轮用户反馈和现金耗尽前能够完成的学习次数。AI Native 的竞争优势最终落在同一笔资金能够支持多少次可靠验证

我们说项目开发方式接近百分之百由 AI 驱动，指的是 PRD 初稿和代码生成方式。人仍然修改和批准产物，也负责测试与验收。AI Native 提高的是执行纯度，没有取消人的责任

AI Native 团队不会因为购买了更多工具自然出现。它来自一条可以持续运行的工作链，每次错误都能写回下一次执行。AI 扩大执行能力并提供验证证据，人决定解决什么问题，并对风险和生产结果负责

愿我们永远对世界保持好奇