《AI Native 研发范式实践手册》里有一个案例：某个 C 端用户动线改造需求，编码和本地验证大概 1 小时完成，从代码写完到线上真正生效，用了约 3 周。手册把这段时间拆开，编码在整条链路里的占比不到 1%。
这本手册由阿里团队编写，主编许晓斌，68 页，记录的是他们内部三个业务团队做 AI Native 研发的过程。它不提供标准答案，很多做法还在验证中。但它给出的这个反差，值得每个正在推 AI 提效的人停下来看一眼：我们量的是编码段，还是从一个想法被提出到它真正上线的整段时间。
一个需求：代码 1 小时，上线 3 周
手册把那个案例的时间构成列得很细。编码加本地验证 1 小时；跨团队影响分析与方案评审 1-2 天；联调环境准备 2-3 天；多平台联调 5-7 天；发布审批与编排 3-4 天；灰度验证与观察 2-3 天；封网期等待与合规检查 7-10 天。加起来约 3 周。
编码段那 1 小时放在这条时间条上，几乎看不见。
手册还给了另一个口径：按团队内部的粗略统计，生成代码只占整个研发链路的两三成，甚至更低。两个数字要分开看——不到 1% 是手册举的个案样本，20%~30% 是他们观察到的整体比例，都不是全行业基准。
行业侧的信号指向同一处。手册提到，主流模型在 SWE-bench Verified 上的通过率两年内从不足 30% 升到 80% 左右，在 Terminal-Bench 2.1 这类更接近真实工程的评测上，多个模型突破 85%。同一时间，研发生命周期里 70%~80% 的环节仍然花在需求理解、环境构建、测试验证、发布运维上。
代码写得越来越快，交付没有等比例变快。
为什么偏偏是 Coding 先被解决
这个问题手册回答得很直接：优先解决可规模化验证的问题。
表面答案是有海量公开代码、公开 issue 和公开评测。更深一层是验证成本。代码能不能编译、测试能不能通过，跑一下就知道，对错由机器自己判定。手册说 Coding 和数学最先被突破，不是因为它们简单，而是因为它们是少有的「对错机器自己就能判」的领域。
企业内部的环节正好相反。当前代码仓库对应哪个应用、当前目录属于哪个项目、工作项挂在哪个项目空间、默认 trunk 是什么、创建变更请求用哪个 codeModuleId——答案散在各套内部系统里，没有公开反馈，验证一次的成本很高。
手册在这里接了一句 1992 年的老判断：Jack Reeves 在《Code as Design》里说源代码才是软件真正的设计，文档只是设计过程中的摘要。放到今天读，代码生成会快到近乎免费，可把模糊的业务意图变成完整、精确、能跑起来的表达，并验证它符合预期，仍然是核心挑战。
接着是阿姆达尔定律。手册的用法很朴素：当一个只占三成的环节被压缩到接近零，整个系统能获得的收益依然有明显上限。编码被解决得越彻底，它之外的需求理解、领域知识、构建测试、发布变更、权限与环境操作，越会成为新的瓶颈。
副作用也写得很具体：AI 写完的代码堵在交付流水线上。持续集成、测试、发布、运维没有同步提效，总效率不会有本质变化。
换个动力源，还是重排生产线
手册用电气化做了一个类比，这个类比是全文的支点。
电气化早期，很多工厂只是用发电机和大型电动机替换蒸汽机，传动轴、皮带和机器布局原样不动。这种做法容易实施、见效快，但旧系统里的能量损耗、设备联动、局部故障导致大面积停工的问题一个都没解决。真正的生产率跃升发生在「单元驱动」普及之后：每台机器有独立电机，设备不再围绕传动轴布局，可以按生产流程重新组织，工厂空间、流水线、材料搬运和管理方式随之重做。
手册的结论是，电气化最大的价值不是电动机比蒸汽机效率更高，而是电力成为生产系统的基础设施。
对应到 AI，现在的主流做法是把 AI 嵌进既有研发流程：PRD、方案、任务拆解、生码、测试，每个节点局部提效，整体仍沿着人设计的 workflow 运转。手册把 SDD、Agent Skills、Superpowers 都归到这条路线里，并给了一个判断：这是过渡形态，因为它优化的是「人如何使用 AI」，而不是「AI 如何使用研发环境」。
这里要替手册补一句它自己写明的边界：workflow 没有过时。调度、权限、状态、审计和高风险检查仍然要由 workflow 承担，它不该规定的是 Agent 每一步该怎么思考。手册也承认反方观点成立——真实研发不是线性的，一次测试失败可能来自需求、设计、代码、数据或环境，简单回退到上一个节点重跑，既低效，也容易把已经正确的判断推翻。
真正要区分的，是两类方案：给每个节点加一个 AI 助手，还是让一个 Agent 端到端持有目标、拿到验证信号、自己决定下一步。
价值重心正在迁移到环境与验证
手册给了一张趋势图，用四类工作在软件工程价值中的占比变化来说明方向。
2024 年及以前：编码 50%~60%，测试 15%~20%，部署发布 10%~15%，环境与验证 10%~15%。2027 年往后：编码降到 5%~10%，测试升到 20%~25%，部署发布升到 20%~25%，环境与验证升到 40%~50%。
四个驱动因素解释了这次迁移：头部模型能力趋同、代码生成成本趋近于零、企业自己的业务逻辑和发布体系无法被复制、系统规模和合规要求让验证难度持续上升。手册的判断是，未来的核心竞争力不是更会写代码，而是拥有更强的环境与验证体系，让每一代模型都能释放更大价值。
方向落到具体建设上，有五件事：业务领域知识构建、可复现可调用的研发环境、分层验证体系、端到端研发系统打通、Spec 与技术方案的新写法。
其中两件对产品经理最直接。
一是分层验证体系。秒级反馈包括编译、类型检查、单元测试，适合 Agent 高频自主迭代；分钟级反馈包括集成测试、契约测试、浏览器自动化，覆盖更真实的行为；人工判断只保留给机器无法可靠裁决的部分，比如业务价值、用户体验和伦理边界。按手册的这个分层，Agent 的自主区间基本由秒级和分钟级反馈的覆盖范围决定。
二是 Spec 的写法：区分「约束」和「假设」。数据不能出域、接口必须向后兼容、延迟不能超过某个阈值，这些是约束，要长期保存并尽可能自动检查；用微服务还是单体、选哪种缓存策略，这些是有待验证的假设，应该允许 AI 根据实现和运行中的反馈自己调整。Spec 负责划定「什么算对」的边界，不负责规定实现路径。
三个案例，同一个结论
手册里的三个案例切入点完全不同，但都指向编码之外的环节。
AIDC 数字投手是一个 6 人小队，从「超级个体」（一个人指挥 3~5 个会话，产能锁在个人电脑里）走到数字员工，再走到云上 Scrum。他们没走纯 ReAct 路线，而是把投手拆成经验、手脚、头脑和评测四块，用预计算收拢复杂度，再用经验 Loop 和手脚 Loop 把策略交付周期从约 10 天压到 2 天，约 80% 的核心能力做了 Skill 化。
团队自己的结论是：AI Native 不是无人化，而是重新划分系统、AI 和人的职责边界。
千问用增 Agent 走的是工程流程。
三个多月里，他们先鼓励约 15 名服务端工程师分头探索，再把有效方法标准化，最后把 AI Coding 的能力收到四个环节：项目理解（Code Docs、Code Graph、Rules）、需求理解（让 AI 主动追问隐含决策，沉淀成可追溯的 Spec 和 Tasks）、可靠编码（用 TDD 把「代码是否正确」变成可重复的执行反馈）、线上排障（统一 TraceId 打通日志、上下游状态和代码调用关系）。
2026 年 5 到 8 月，平均交付周期缩短一半，千行代码缺陷率下降 70%，变更失败率下降 90% 以上。他们的结论是：AI Coding 的上限，很大程度取决于基础设施是否足够 AI 友好。
万有无界做的是需求与验证链路。近四个版本里，约 80% 的交互体验类需求用基于 Git 的可交互原型承接，产品经理在评审前就交出一个能点的方案；设计师在真实工程里完成页面并交接；测试环节用现场采集加自动修复，在手册限定的「上下文充分的视觉类缺陷样本」中，自动修复的一次成功率约 89%，当前统计范围内的线上千行代码缺陷率是千分之 0.01。但他们也给出了一个诚实的数字：自动修复比例到 60% 以上时，bug 日清率变化不大，从 53% 到最高 63%，因为整件事的触发仍然依赖人或其他确定性流程。
三个案例的数据都来自阿里内部手册，属于内部统计，学的是机制而不是数字。
给产品经理的三个问题和一张表
回到自己的团队，这份手册可以压成三个问题。
第一，这个方案压缩的是不是当前的瓶颈环节。如果编码已经不是瓶颈，把它再快一倍，收益也有限。
第二，这个环节有没有可规模化的机器反馈。有反馈，Agent 才有可能自主推进；没有反馈，就要明确写出谁来兜最后的判断。
第三，Spec 和文档里，哪些是约束、哪些是假设。约束写成能自动检查的规则，假设留给 AI 按反馈调整。
度量上，手册给了三层指标，不能挑着看。L1 是 AI 效能层：覆盖率、Session、Token、AI 采纳行数、Skill、MCP、上下文资产，作用是牵引团队用起来并定位工具与上下文问题——手册明确警告，这层指标一旦走个人排名，团队就会开始优化指标本身。
L2 是工程质量层：AI 缺陷率、回滚返工、自修复缺陷、风险事件，作用是约束 L1 的增长不能以质量恶化为代价。L3 是价值交付层：需求交付周期、变更周期、发布频率、AI 与非 AI 交付的对比，作用是验证业务是否真的更快更稳。
比 Token 数更值得投入的是五类上下文资产：Skill 是方法，MCP 是接口，SPEC 是约束，README 和 runbook 是入口与排障经验，模板和 checklist 是评审、发布、回滚、安全检查的固定动作。手册对此的判断是，可规模化的组织不是让每个人都更会提问，而是让上下文能被复用、更新、验证，并被接进 Agent 的会话。
最后是手册自己写下的限制：这不是成熟方法论，案例全部来自一家公司的内部实践，其中的技术架构可能半年后就需要重新审视。它提供的不是答案，而是一份可以对照检查的清单——包括那些它还没解决的问题。
（本文解读的《AI Native 研发范式实践手册》由阿里团队编写，主编许晓斌，2026 年。手册中的内部数据仅代表其团队实践。同系列下一篇会把手册的五个挑战与八类基础设施逐项拆开。）
系列导航
- 系列：AI 原生研发范式（第 01 篇，共 2 篇）
- 下一篇：阿里 68 页 AI 研发手册，拆成一张对照清单
- 公开系列页尚未创建；如需回看上一篇，可在站内按「体系」分类检索。
参考资料
- 《AI Native 研发范式实践手册》，阿里团队编写，主编许晓斌，2026 年，共 68 页、署名作者 19 人（含主编）。本文基于该 PDF 的逐页 OCR 文本整理，手册未提供公开链接。
信息边界
本文采用 source-only 模式，只基于该手册整理。手册自述不是成熟方法论，其中案例数据均为其内部统计，不代表行业基准；文中标注为「趋势判断」「本文归纳」的部分是观点或转译，不是已验证结论。