Anthropic 发布《The AI-Native SDLC Playbook》，揭示 AI 开发的核心瓶颈不在代码生成，而在流程协同。本文深入拆解 intent.md 到部署的产物链机制，探讨产品经理价值上升、审查前置等关键转变，为 AI 从业者提供一套可落地的项目系统改造思路。

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

Agent 已经可以在很短时间里生成大量代码，规划、审查和部署却还在按照人类速度运行。代码变快，项目没有一起变快，团队依然会被等待和返工拖住。我建议每一个 AI 从业者都去读原文，带团队的人可以用它检查完整开发流程，独立开发者也能用它建立一套不会随着会话消失的工作方法

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

代码变快以后，项目为什么没有一起变快

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

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

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

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

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

AI Native 团队靠什么协作

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

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

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

聊天记录承担不了这条链的责任。一次会话结束以后，重要判断可能埋在几十轮对话中，下一个 Agent 也未必拿到相同上下文。被接受的文件把当前结论固定下来，同时保留作者、时间和修改记录。后面的团队读取的是已经做出的决定，不需要重新猜测讨论过程

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

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

把问题定义清楚

流程从 intent.md 开始。发起人先用自己的语言向 Claude 描述问题，Claude 继续追问用户、范围与约束，直到模糊想法变成可以被后续阶段读取的意图文件。文件需要保留期望结果、受影响对象和尚未解决的问题。发起人修正理解偏差，产品负责人决定这份意图能否进入设计。通过审核以后，Claude 根据 intent.md 生成 spec.md，并读取团队已经写好的品牌、安全和用户体验规则

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

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

产品经理的价值为什么会上升

AI 可以快速生成 PRD 和设计规格，写文档占用的时间开始下降。产品经理需要把更多精力放到问题是否值得解决、约束有没有遗漏，以及生成结果能否满足用户需求。实现越快，一个错误判断进入代码的速度也越快。文档生产的价值在下降，产品判断的价值在上升

判断没有被外包。过去产品经理可能把大量时间用于整理文档和推动交接，现在 Agent 接手了这些生产动作，产品经理更需要持续检查原始问题有没有变化，并在生成结果偏离用户时及时停止。职位价值来自取舍与责任，不来自 PRD 的页数

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

这个案例不能推出所有项目都应该取消设计岗位。它能说明的是，当 AI 承担文档与实现的大量生产工作以后，角色数量可以减少，原来分散在不同岗位里的判断却需要被重新分配。谁定义用户体验，谁审查生成结果，谁对上线后的问题负责，必须比过去写得更清楚

先审查计划，再生成代码

通过审核的 spec.md 到了工程师手里，构建仍然不会立即开始。工程师先在 Plan Mode 中让 Claude 阅读意图、规格和代码库，再生成 plan.md。这份计划要写清改动哪些文件、按照什么顺序实施，还要给出证明结果的测试。工程师继续追问改动可能破坏什么，风险最高的步骤在哪里，以及 Claude 放弃过哪些方案

计划反复修改，直到一个没有参与前面对话的工程师也能只依靠它完成任务。在计划被接受以前，Claude 只能读取代码，不能修改文件。设计审查因此发生在代码生成之前，计划的每次修改和最终接受者也会留下记录。此时改变方向仍然只需要编辑一份文档

计划通过后，Agent 才开始实施。项目规则和测试能力成熟以后，常规任务可以进入 Auto Mode，工程师的注意力从逐次确认文件编辑转向审查完整产物

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

把团队经验写进 Agent 的工作环境

CLAUDE.md 保存一名新成员第一天需要知道的项目上下文，包括构建命令和架构边界，也记录 Agent 经常犯的错误。手册给出一条直接规则，同一种错误出现两次，纠正方式就写进这个文件。它最好控制在一页以内，因为每次会话开始时都会读取。过期内容会直接占用 Agent 的上下文

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

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

并行会话彼此没有共享记忆，每个会话都在独立工作区完成自己的任务，工程师是它们之间唯一的连接点。subagent 则运行在单个会话内部，用新的上下文完成范围明确的检查。工程师的工作开始从亲手修改每一处代码，转向分配任务、补充上下文和接受结果

让 AI 先证明自己做对了

Agent 报告任务完成没有证明力。每个会话都要获得一条可以反复运行的反馈回路，在工程师看到结果以前先运行测试和构建，界面任务还要完成截图或浏览器验证。验证命令与健康结果写进 CLAUDE.md。Agent 拿出测试输出、构建日志或截图差异以后，才能报告任务完成。失败就继续修改并重新运行，工程师看到的是已经完成第一轮自检的产物

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

修复 Bug 时，Claude 先写出能够复现问题的失败测试，确认它因为预期原因失败，再提交测试。接下来只允许它修改代码，Hook 阻止测试文件被改写，避免 Agent 通过降低检查标准让结果变绿。界面任务需要另一种证据，Claude 打开实际页面，对照设计结果反复截图和调整。手册认为两到三轮视觉检查很正常

我们遇到的问题，都需要进入反馈系统

在我们的五人项目里，AI 会理解错需求，也会在修复一个功能时损伤相邻流程。界面看上去已经完成，真正操作时仍然会暴露体验缺陷。长会话还会丢失上下文，自动化测试全部通过也不代表真实使用成立。前面没有被发现的偏差，最后进入工程师的审查队列，变成返工

这些问题发生在不同位置。需求误解来自输入没有说清楚，相邻功能受损说明回归范围太窄，界面问题暴露了静态检查和真实操作之间的差距。上下文丢失需要稳定的提交产物，测试通过但真实使用失败，则要求团队把真实场景继续写进验收与 Eval。最后剩下的审查压力，不能继续全部交给人逐行消化

需求理解偏差要回到 intent.md、spec.md 和 plan.md 修改。相邻功能需要纳入验证，界面则要进入浏览器操作。长任务通过提交产物保留已经确认的上下文，再由独立 verifier 用新的上下文完成最终检查。反馈回路贯穿整个任务，verifier 只在会话认为完成以后做一次独立判断，两者承担的责任不同

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

Eval 检查 Agent 的工作标准

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

生产事故也要进入 Eval，并长期留在测试套件里。同一种问题下次出现时，系统应该先于用户发现它。进入 PR 阶段以后，Claude 可以按照 REVIEW.md 审查代码，也可以处理自己收到的审查意见。REVIEW.md 写清检查哪些问题、怎样区分严重程度，还要排除自动生成文件和持续集成已经检查的内容。写代码的 Agent 没有批准权限，分支保护仍然要求代码负责人确认

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

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

让 Agent 到达生产门禁，但不能越过

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 能够运行验证命令，再守住生产授权，已经可以改变项目的基本运行方式。小团队先做到可重复

1. 每个需求留下 intent.md，再让 AI 生成 spec.md 和 plan.md。产品经理接受问题与完成标准，工程师接受实施计划
2. 把测试和构建变成 Agent 可以直接运行的命令。涉及界面时，让它进入浏览器验证真实流程
3. 用简短的 CLAUDE.md 保存项目规则，必须执行的限制交给 Hook。生产发布保留人工授权，并提前演练回滚
4. 同一种错误出现两次就写回规则，线上事故进入 Eval。先从真实问题增加控制，再逐步扩大自动化范围

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

AI Native 已经关系到创业公司的生存能力

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

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

能够把意图、生成和验证连成循环的团队，会更早发现方向错误，并在投入扩大以前停止无效实现。有限的时间和资金会持续放大这种学习速度的差距。我们的项目已经把 PRD 初稿和代码生成交给 AI，五个人承担产品与工程工作，项目不再设置独立设计师。过程中仍会出现需求误解、上下文丢失与体验问题，这些问题属于必须建设的反馈系统，不构成退回旧流程的理由

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

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

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