AI-Native SDLC：代码变快后，先重做交接

先说结论

AI 把写代码压缩到小时级后，交付不一定更快。需求仍靠会议转述、测试仍在末尾排队、部署仍等人工逐行审查时，瓶颈只会从 Build 移到它前后的交接。真正值得改造的是：每个阶段都产出下一阶段能直接读取、由人明确接受的版本化工件。

原文解决什么

Anthropic 把软件生命周期拆成 Plan、Design、Build、Test、Deploy、Maintain 六个非线性阶段。它关注的不是“让 Agent 多写多少代码”，而是如何保留原有控制目标，同时用自动触发、持续检查和可审计工件替代丢信息的文档转手。

核心机制

• Plan 把问题、目标、约束和未知项固定为可审阅的意图工件；Design 再把已接受意图变成需求与设计，并显式暴露冲突。
• Build 先形成可执行计划，再生成代码和测试；团队约定、Skill 与确定性 guardrail 分别承担上下文、可复用流程和强制约束。
• Test 不再只做阶段末验收，而是让实现持续获得测试与 eval 反馈。
• Deploy 组合多层自动审查，把人工注意力留给高风险、受监管或需要判断的变更。
• Maintain 用线上信号发现异常，形成新的问题工件，重新进入规划，而不是让修复停在告警或聊天里。
• intent、spec、plan、diff、测试、评审和事故记录组成交接链。关键不是文件名，而是来源唯一、状态明确、下一阶段能消费。

和 Zero-to-AI 及日常开发如何接上

Zero-to-AI 已把手写 Markdown 当源真相，把格式、链接和构建结果当派生验证。日常小改动可以沿用更轻的工件链：任务描述说明“为什么与不做什么”，实现前写受影响路径和验收，完成后用 diff、命令退出码与人工检查交接。不要为一处文案改动照搬六套模板；只保留会改变下一步决定的记录。

对真实开发更重要的是区分接受与自动触发：Agent 写出计划不等于工程师批准，测试通过不等于 owner 接受，合并也不等于线上行为正确。每个阶段的门要绑定真实责任人和证据。

一个低成本实验

输入： 选择一个能在半天内完成、涉及需求说明、代码修改和验证的小任务。

步骤：

1. 在任务记录中写四项：问题、期望结果、约束、未知项，并由执行者确认。
2. 实现前补一份短计划，只列目标文件、风险和验收命令。
3. 修改后保存 diff、最小测试结果和仍未覆盖的行为，交给未参与实现的人复核。
4. 记录每次返工来自哪个交接缺口，不先建设自动化平台。

成功证据： 复核者不用回看聊天就能说清需求、改动与验证；任务从确认到验收没有因缺少输入而退回，且工件能在 Git 历史中对应起来。

停止线： 工件维护时间已超过任务本身，或同一事实出现两个互相冲突的源真相；停止扩模板，先指定权威记录并删掉重复交接。

常见误区

• 把 AI-native 理解为无人负责：自动化可以搬运证据，风险接受仍是人的判断。
• 每阶段都生成长文档：工件的价值在可执行和可追溯，不在页数。
• 代码生成变快就并行更多任务：评审与验收跟不上时，只会放大在制品和风险。

原文与证据边界

六阶段做法、工件触发方式和组织收益预期来自 Anthropic 的实践建议与客户经验，本站未在完整组织流程中复现，也不能据此证明周期缩短或治理成本下降。上面的实验只检验一次小任务的交接质量。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。