Anthropic 在《AI-Native SDLC Playbook》中提出了一个重要判断AI 大幅压缩了编码时间软件开发的瓶颈正在向需求、评审、测试和发布转移。这意味着过去围绕“怎样把代码写出来”建立的流程需要重新审视。人的注意力是有限的。一个工程师可以同时让多个 AI 生成代码却无法同时认真判断多个需求的目标、边界和风险。AI 扩大了执行能力却没有扩大人的判断能力。因此AI 时代的开发规范不应继续监督每一步编码而应解决一个更根本的问题怎样把人的有限注意力集中在关键判断上并保证这些判断在后续开发中不被重新解释。一、为什么旧开发方式开始失效假设产品提出一个需求用户说“订单号”时系统应该能识别这是字段order_id。AI 很快找到元数据构建逻辑增加字段同义词补充测试。两小时后代码通过编译测试全部通过。第二天联调时团队却发现初筛阶段可以识别“订单号”但同义词经过数据集筛选和虚拟表转换后丢失了。代码没有明显错误测试也没有失败需求却没有真正完成。原因在于产品、开发者和 AI 对“完成”的理解不同。有人认为提示词中出现“订单号”就算完成有人认为初筛能够识别就算完成产品真正想要的却是字段同义词在所有必要的元数据链路中保持一致。团队共享了一句话却没有共享同一个目标。过去这类问题也存在但通常会在漫长的编码过程中暴露。开发者不断遇到阻力只能回头确认数据来源、影响范围和验收标准。AI 缩短了实现时间也削弱了这种被动澄清机制。模糊需求可以迅速变成结构完整的代码。代码越完整人越容易相信方向已经正确。于是新的风险不再表现为“代码写不出来”而是代码写得很好只是解决了错误的问题。如果要求人逐行监督 AI又会失去自动化带来的效率。代码生成越快人越不可能检查所有过程。所以新规范不能把人放回每一次文件修改和命令执行中而应让人只关注少数不可替代的判断。二、新规范究竟管理什么软件开发无论采用什么工具最终都必须回答三个问题判断要回答的问题对应产物目标判断为什么做、做到什么程度Intent、Proposal、Spec执行判断准备怎样做、风险在哪里Design、Plan完成判断实际证明了什么、能否交付Verification、Review、Status新规范的核心不是增加八份文档而是把目标、执行和证据分开。先固定目标避免实现反向定义需求intent.md保存原始问题、影响用户、期望结果、约束和非目标。在字段同义词需求中Intent 应表达“让模型稳定理解用户配置的字段同义词”而不是“给 Markdown 增加一列”。前者是业务目标后者只是当前实现方式。意图确认后proposal.md再确定本次 Change 做多少、依赖什么、明确不处理什么。这样整个用户问题是否解决就不会和某个局部 Change 是否完成混为一谈。spec.md则定义长期有效的行为标准。例如同义词需要去重并保持稳定顺序经过必要的数据转换后不能丢失没有同义词时不能破坏原有行为。Spec 不描述类名和调用链因为技术实现可以变化系统行为必须稳定。再评审执行路径降低返工成本行为确定后design.md说明怎样实现plan.md说明按什么顺序实现、修改哪些位置、怎样测试、风险和停止条件是什么。Plan 的价值不在于给 AI 一份机械清单而在于让工程师在代码出现前检查方向。修改一份 Plan 的成本很低等错误方向变成几十个文件后再调整就是返工。如果实现必须偏离 Plan应当同步更新而不是让计划继续描述一个已经不存在的实现。最后用证据定义完成代码生成结束只能说明实现动作结束不能说明需求完成。verification.md应记录实际运行了哪些测试、使用什么环境、得到什么结果以及哪些验证尚未执行。如果单元测试通过但测试环境不可用结论就只能是“代码级验证通过运行时行为尚未确认”。这不是示弱而是在准确划定已知和未知。review.md再把 Intent、Spec、Plan、代码和验证证据连接起来判断实现是否仍然忠于目标。Reviewer 最好没有参与实现过程。它只相信正式产物和证据不依赖开发过程中的口头解释。status.yaml最后保存阶段、批准人、批准时间和对应 Commit。批准必须指向明确版本不能只存在于聊天口令中。由此开发过程形成了一条连续的责任链目标被确认 → 行为被定义 → 方案被评审 → AI 执行 → 结果被验证 → 人决定是否交付人的注意力不再消耗在监督每一行代码而是集中在目标、风险和证据上。三、怎样落地而不制造文档负担新规范最危险的落地方式是发动一次全仓库文档运动。如果一开始就迁移历史需求、设计复杂目录、建设 Hook、CI 和 Evals团队很可能花几个月维护规范却没有证明它能改善一次真实交付。更稳妥的方式是选择下一个尚未开始的真实需求人工跑通一次闭环。从需求发起人的原话形成 Intent确认范围和 Spec评审 Plan再让 AI 实现。完成后记录 Verification并由独立 Reviewer 对照前面的产物检查结果。第一次试点只观察几个问题实现开始后需求又修改了多少次代码偏离 Plan 的原因是什么测试第一次通过时是否已满足真实场景Review 发现的是代码错误还是更早阶段遗漏的判断增加的流程成本是否换来了更少的返工。跑过真实需求后团队才能知道哪些内容是必要证据哪些只是形式。随后再把稳定、重复、不能依赖自觉的规则交给自动化。例如未批准的 Plan 不允许进入实现Spec 场景必须关联测试证据敏感文件不能被读取生产发布必须获得具名授权。自动化应该固化已经被实践证明有效的规则而不是提前把未经验证的流程变成新的负担。归根结底AI-Native SDLC 不是让 AI 接管整个软件生命周期而是重新安排人与 AI 的分工。AI 负责读取已确认的产物、执行计划、运行验证并提供证据人负责判断目标是否正确、风险是否可接受以及是否允许进入下一阶段。人的注意力是有限的所以不应浪费在监督 AI 的每次操作上。代码可以越来越快但目标不能在速度中丢失AI 可以承担更多执行工作但人的判断必须始终位于这条循环之上。