当代码不再是瓶颈，产品交付如何重写

当实现一项功能从两周缩短到两小时，团队并不会自动快十倍。需求仍然说不清，评审仍然排队，安全检查仍然滞后，线上事故也仍然需要人解释。代码生成把“Build”压缩后，真正的瓶颈会显露在它的两侧：定义、验证和发布判断。

The AI-Native SDLC playbook 给出了一条很值得借鉴的路线：不取消传统 SDLC 的控制目标，而是用新的、可运行的产物链替换低效交接。

原文的六阶段，不是把六个 Agent 串起来#

它保留 Plan、Design、Build、Test、Deploy、Maintain 六个阶段，但改变每段的交接方式。Plan 不再只产出会议结论，而是形成能被机器读取的 intent；Design 在同一工作会话里把需求与约束合并为 spec；Build 先形成可审查的 plan；Test 不再只在阶段末排队；Deploy 用分层自动 review 和 hook 管理批准；Maintain 从生产控制带触发下一轮 intent。

这里最关键的机制是“接受一个产物，触发下一个产物”。例如被接受的 intent 触发 spec，批准的 spec 触发 plan，合并的 PR 触发流水线，生产监测越过控制带后再写入新的 intent。它把线性流程改成一条由证据驱动的回路，而不是用 Agent 把每个阶段简单提速。

交付物不是文档负担，而是下一步的输入#

我会把最小链路写成：

intent.md → spec.md → plan.md → diff + tests → review findings → incident record

它的价值不在 .md 后缀，而在每个阶段都留下下一阶段能读取、能质疑、能审计的事实。

产物	回答的问题	谁必须判断
intent.md	为什么做、为谁做、什么不能做	产品负责人
spec.md	方案如何满足约束、哪里仍有冲突	产品与风险负责人
plan.md	哪些文件、步骤、测试会证明完成	工程负责人
diff + tests	实际改了什么、是否可验证	CI 与代码所有者
incident record	线上哪里违背了预期	责任团队

这样，Agent 不只是接收一句模糊指令，而是在读取一串被接受过的决策。人也不必从头复述背景，而把注意力放在少数真正需要判断的门口。

产品定义应该先于自动化#

最早的产物不是 PRD，而是包含问题、目标用户、约束、开放问题的 intent.md。这一步尤其适合 AI 协助，但不能交出最终判断：Agent 可以把口语化想法结构化，产品负责人要纠正误解、决定范围，并确认什么结果算成功。

我会要求每份意图至少写出一个反证条件。例如“若用户仍需要人工确认三次以上，说明自助流程没有真正减少任务成本”。有了反证，后面的测试和埋点才不会只为证明原决定正确而服务。

测试变成贯穿式证据，不再是阶段末尾的队列#

AI Native SDLC 不意味着不测试，恰恰相反：因为代码产出更快，测试必须更连续。测试分成三层最清楚：

• 机械证据：构建、测试、lint、schema，交给确定性工具；
• 任务证据：关键流程是否完成、错误是否可恢复，交给端到端用例；
• 判断证据：体验、风险与产品取舍，交给独立评审与人类验收。

每一次模型、Skill、Hook 或工具配置变更，都可能改变 Agent 行为，应该像改代码一样触发回归。线上事故也不应只留在复盘文档里，而要抽象成新的失败样本与回归用例。

原文给出了哪些可量化的检查点#

这篇 playbook 不只给流程图，也为不同阶段给出可观察指标。Plan 阶段看从第一次对话到 intent 提交的时间，以及 intent 被产品负责人接受进入下一阶段的比例；Design 阶段看 intent 到 spec 的间隔、首次 plan 之后的需求返工；Build 阶段看首轮实现后合并的比例、每项变更的返工次数，以及最终 diff 与已批准计划的一致度。

在 Test 环节，作者建议从近期真实工作中收集 20 到 50 个任务，每个任务写成“prompt + 可接受检查”的 eval，并在 CLAUDE.md、Skill 或 hook 变更时在 CI 中回归。指标包括 Agent 变更的首轮 CI 成功率、每个 PR 的 review 时间、以及生产变更失败率。这个设计很重要：它不把“模型版本”当作唯一会回归的变量，而把整个 Agent 配置当作一个可发布的软件对象。

人的工作从逐行审查，转向定义门槛#

人仍然负责，但负责的位置变了：

1. 接受意图与规格，防止团队高效地做错事；
2. 决定哪些风险可以自动化，哪些必须升级；
3. 审查异常、冲突和高影响变更，而不是机械地阅读全部 diff；
4. 维护成功标准，让它随着真实使用而更新。

这是一种更高杠杆的“人在回路中”。它不是看着 Agent 每次点击，而是设计 Agent 何时可以前进、何时必须停下。

用数据证明流程真的变好了#

不要只报“代码量变多”或“平均耗时变短”。我会同时跟踪：从意图到首个可测版本的时间、一次通过 CI 的比例、需求在开工后发生的大改次数、每次变更的回滚率，以及生产事故进入回归集的周期。

如果交付更快，却让 rework、事故或审批等待激增，就说明只是把瓶颈转移了。

来源与边界#

• 方法链路和阶段观点参考 The AI-Native SDLC playbook。
• 文中的反证条件、三层证据与指标组合，是我为 AI 产品交付做的延展；并非 Anthropic 宣称的统一实践标准。