写代码已不是瓶颈：阿里AI Native研发范式实践手册精读

9 月 19 日，阿里发布了一份 68 页的 《AI Native 研发范式实践手册》 ：19 位作者，来自多个一线团队，免费电子版。市面上讲 AI 编程的内容大多停在观点层，这份册子的价值在于它是实践复盘——有实测数据、有踩坑记录，也有「上线后效果低于预期」的自我否定。

这篇跳过组织变革的部分（数字员工、组织配套），只拆 AI 实践 ：三个团队实际怎么干、效果怎么量化、基建长什么样。先说清楚：以下数据均为手册自报口径，没有对照组，看趋势、别照抄数字。

一、先看一个时间构成：编码 1 小时，上线 3 周

手册里最扎眼的是一个小案例：一个 C 端交互实验需求，编码加本地验证 1 小时搞定；从代码完成到线上生效，3 周。

拆开看：影响面分析与评审 1~2 天，联调环境准备 2~3 天，多平台联调 5~7 天，发布审批 3~4 天，灰度观察 2~3 天，封网与合规检查 7~10 天。编码占全链路 不到 1% 。放到整个研发投入上看，阿里给的口径是编码占 20~30%。

阿姆达尔定律在这里很简单：占三成的环节就算被压到零，整体收益也有天花板；编码被 AI 解决得越彻底，需求理解、环境构建、测试验证、发布运维就越成为新瓶颈。

为什么偏偏是编码先被 AI 解决？手册给出的规律值得记住： AI 总是优先解决「对错机器自己能判」的领域 ——编译过没过、测试绿不绿，跑一下就知道。而企业内部系统没有公开反馈，验证一次成本很高。

既然 AI 的能力边界由「可验证的反馈」决定，要做的就不是等更强的模型，而是主动把研发工作流改造成「有反馈、可验证」的环境。

二、三个团队的实测数据

① 数字投手（阿里国际站广告，6 人小队）

演进分三个阶段。 超级个体期 ：1 人指挥 3~5 个会话，一人干出两三人的活，但很快撞上两堵墙——消化障碍（Token 堆出来的中间产物没人看得完，同事之间讲不清设计，只能把问题抛回给 Agent）和复用障碍（会话里的知识最难沉淀成 Skill，最有效的办法竟是保留整个会话和工作区）。 数字员工期 ：上云上运行时，产品、研发、评测、数据分析都有数字员工，人转做目标设定和验收；新问题是人成了调度员，验收花的功夫不比执行省下的少。 云上 Scrum ：给数字员工配上协作协议，跑出两条 Loop——经验 Loop 把策略发现和工程化拆给两个数字员工、以结构化契约交接；手脚 Loop 把线上失败轨迹直接转成能力建设需求。结果：策略交付周期从 10 天压到 2 天，约 80% 的核心能力完成 Skill 化。

最有价值的是复盘：第一版架构上线后「实际调控效果低于预期」——它解决了「能不能做」，没解决「做得对不对」。转向数据闭环后才改善。

② 千问用增 Agent（3 个月）

用户增长投放系统，五个岗位全栈 AI Coding（运营/产品/全栈/数据/质量）。2026 年 5~8 月：平均交付周期缩短一半，千行代码缺陷率下降 70%，变更失败率下降 90%+。

比数字更有用的是四条可复用经验： 项目地图 （文档与代码图谱先行）； Spec 规范化 （复杂需求写清边界与验收条件）； 可验证反馈 （测试覆盖需求边界、关键分支和已知故障模式，而不是刷覆盖率）； 统一 TraceId 排障 （先收集结构化日志和调用链证据，不猜根因；证据不足再升级给有完整代码上下文的 Agent）。

③ 万有无界（人与 Agent 协作平台）

评审材料从文档变成 可运行原型 ——评审者直接进页面检查正常态、空态、异常态和权限，50%+ 的产品经理在用这套流程，近四个版本约 80% 的交互类需求靠原型承接。设计师直接在分支里用工程 Skill 写页面，单月活跃近 20 天；缺陷工单自带现场（版本、环境、复现步骤、请求日志），信息充足的云端沙箱即时自动修复，需要业务判断的周期集中处理。结果：视觉问题一次修复率 89%，线上千行代码缺陷率千分之 0.01。

三、共性挑战里最值钱的三条

1. Spec 的新写法：分清「约束」和「假设」

「数据不能出域、接口必须向后兼容、延迟不超阈值」是 约束 ——长期保存、尽可能自动检查；「用不用缓存、先单体后拆」是 假设 ——允许 AI 根据实现和运行反馈自己调整。Spec 负责划定「什么算对」的边界，不负责规定实现路径。

2. 平台要换到 Agent 视角

面向人设计的研发平台对 Agent 有三个失效：进不去（认证方式各异、页面跳转、浏览器 Session）；上下文残缺（人「点一下」的背后是十几个隐式事实——这是哪个应用、默认分支是什么、建 CR 用哪个 codeModuleId）；只报状态不推进任务（告诉你流水线挂了，不告诉你挂在哪层、下一步能做什么）。MCP 解决了「怎么调工具」，没解决「知道该操作哪个对象」——工具越多，选择空间反而越大。阿里的解法是 a1 CLI：给 Agent 一层能稳定进入、稳定理解、稳定推进任务的操作面，每天有数万工程师的 Agent 在用。

3. 度量三层，缺一不可

L1 效能层（Session、Token、AI 行、Skill/MCP 使用）证明 AI 进入了过程；L2 质量层（千行缺陷率、回滚返工、MTTR）证明质量守得住；L3 交付层（交付周期、发布频率、AI vs 非 AI 对比）证明结果有改善。归因链 Session→Commit→Change→Workitem，任何一环断掉指标就失真。只看 L1 会鼓励「为了 AI 而 AI」。手册也诚实承认：目前还无法严格区分改善来自 AI、流程调整，还是需求本身变简单了。

四、基建清单：可以直接对照自查

Harness 分工。 Anthropic 对 40 万次 Claude Code 会话的分析：用户承担约 70% 的规划决策，Agent 承担约 80% 的执行决策。安全与质量门禁必须由程序控制——规则加载方式固定不等于模型一定遵守，「记得遵守」不是门禁。

工具三分。 MCP 管协议互通（注意：OAuth 登录通过 ≠ 逐工具逐资源授权完成）；CLI 管执行（参数明确、标准输出可被消费、退出码可判断成败）；Skill 管方法（什么时候调什么、前置条件、完成标准）。CLI 没有统一授权标准，身份、短期凭证、命令级权限必须由平台统一解决，不能留给每个命令自己实现。

Sandbox 四条边界。 TTL 到期回收，防孤儿实例；出站默认拒绝、按任务放行；凭据只给占位值，代理按「域名+路径+方法」匹配后注入认证头，Agent 永远读不到真实密钥；凭据状态不进快照，环境恢复后由控制面重新注入。

Guardrail 三态。 Agent 对每个检查项提交 PASS / BLOCKED / UNKNOWN 加证据（Evidence），规则版本化并固化 digest；UNKNOWN 不可能被聚合为 PASS。发布系统执行批次恢复前，先查门控结果、再校验现场，全部满足才放行。

五、带走四条

1. 量一下自己的链路 ：从代码完成到线上生效要多久？瓶颈不在编码，就别再把力气花在编码上。

2. 起步四件套 ：项目地图、规范化需求、可验证反馈、线上事实链——手册明说不需要一次性建全套。

3. 把度量问题从「AI 用了多少」换成「AI 改变了什么」 。

4. 把目标从「让 AI 做更多」换成「让 AI 稳定做对」 。

手册全文可以在「阿里技术」公众号免费领取。68 页里还有数字员工身份、组织 execution graph 等章节，这篇略过——它们更像是给管理者的考卷，工程师先把自己桌上的四条做掉。