一小时写完，三周上线：读阿里《AI Native 研发范式实践手册》
周末把阿里技术出的《AI Native 研发范式实践手册》翻完了，六十多页，三个业务案例、五个挑战、一整章基础设施。
先说结论：这是今年我读过的国内 AI 研发材料里最老实的一份。老实的意思是，它把好几处没跑通的地方原样写了出来，而且这些没跑通的地方，比它跑通的地方更有参考价值。
下面不做摘要，只挑我读的时候停下来想了很久的几处。
那张「编码 <1%」的图
手册第二章有张图让我盯了很久。一个 C 端交互实验需求，编码加本地验证 1 小时，然后是跨团队影响分析 1-2 天、联调环境准备 2-3 天、多平台联调 5-7 天、发布审批 3-4 天、灰度 2-3 天、封网期等待 7-10 天。合计三周左右，编码占比不到 1%。
第一反应是：这不就是阿姆达尔定律吗，谁都知道。
但多想一步，这张图其实在讲一件更扎心的事。那三周在有 AI 之前就存在，只是以前编码要写三天，三天对三周，大家觉得「开发慢」是个说得过去的理由。现在编码压到一小时，剩下那二十天就再也没地方藏了。
AI 没有制造这些摩擦，它只是把摩擦照亮了。
手册里有段访谈记录我很喜欢，大意是：人既是协作的瓶颈，也是协作的兜底。一份不完整的需求、一个没注释的接口、一段口头传下来的潜规则，系统之所以还能转，是因为有人在用经验悄悄补。开个会、问一下老王、跑个预发试试，这些动作太自然了，我们从来不把它们算成「工作」。
换成 Agent 来干，这些补丁全部失效。Agent 不会去问老王。
所以我读这一章的感受是，AI Native 转型的第一阶段产出，可能根本不是效率提升，而是一份「原来我们靠人肉兜了这么多东西」的清单。这份清单本身就值钱。
手册自己的一处矛盾，和我的理解
2.1 节有个判断：把 AI 嵌进既有研发流程、每个节点局部提效，是一种过渡形态。它用了电气化的类比，工厂早期只是拿电动机替换蒸汽机，传动轴、皮带、机器布局都没变，真正的生产率跃升发生在「每台机器有独立电机」之后，工厂按生产流程重新布局。
类比很漂亮。但回头看案例一，数字投手那个团队恰恰是反过来做的：他们一开始就没用纯 ReAct，而是把系统拆成经验、手脚、头脑三块，把状态、权限、参数约束这些确定性的东西提前算好，只给 Agent 一个限定好的可操作清单。他们自己总结的原则里有一句：确定性的部分尽量交给工程，推理只发生在可控空间内。
这不就是 workflow 吗？
我一开始以为这是手册前后打架，后来又翻了一遍，发现作者其实给了答案，只是藏在一句话里：Workflow 仍然存在，但负责调度、权限、状态、审计和高风险检查，不规定 Agent 每一步怎么思考。
我的理解是，要看 workflow 管的是什么，而不是要不要 workflow。管步骤的 workflow 是过渡形态，因为它把「人怎么协作」固化给了 AI；管边界和验证的 workflow 会一直在，而且会越来越厚。案例一的「手脚」和「评测」就是后一种。
这个区分对我挺有用。我们团队之前写过一些把需求→方案→编码→测试串成固定流水线的 Skill，跑起来总觉得别扭：测试挂了，根因可能在需求，但流水线只能退回上一步重来。现在想想，问题出在我们规定了路径，却没规定什么算对。目标驱动循环那篇里说的「完成合同」，其实就是后一种 workflow 的雏形。
最该抄的一个设计：UNKNOWN
整本手册技术细节最多的是 Guardrail 那节，讲 Agent 怎么参与生产发布的批次恢复。架构不复杂：规则维护者写一份版本化的 Spec，规定要检查什么；Agent 自己选工具去查日志、监控、告警，给每一项检查交一个结果和证据；Guardrail 不理解业务，只机械地聚合。
关键在结果是三态的：PASS、BLOCKED、UNKNOWN。
UNKNOWN 的定义是：查询失败、证据不足、或者事实没法解释。规则写死了两条，一是 Agent 遇到规则没法同时满足的情况必须交 UNKNOWN，不许自己挑一个更宽松的解释；二是 UNKNOWN 永远不会被当成 PASS。
我读到这里的时候想起了过去半年被 Agent 坑的所有场景。几乎每一次，模式都一样：它查不到东西，或者查到的东西对不上，然后给出一个听起来合理的结论，最后一句是「已修复」。模型不是在撒谎，它只是没有「我不知道」这个出口。二态的世界里，不确定会被悄悄四舍五入成确定。
三态这个设计，本质上是给「不知道」开了一个合法的出口，并且规定这个出口通向人。
这东西不需要阿里的基础设施就能抄。我打算先在两个地方用：
- 代码评审 Skill 的输出，每条结论标 PASS / BLOCKED / UNKNOWN，UNKNOWN 必须写清缺什么证据；
- 线上排查的收尾报告，根因那一栏不许空着不写，也不许写「可能是」，要么给证据链，要么明确写 UNKNOWN。
成本几乎为零，改的是 prompt 和输出格式。
他们自己的数据，打了自己一下
案例三（万有无界）里有一组数字，我反复看了好几遍。
视觉类缺陷的 auto bug fix 一次成功率 89%，整体 auto bug fix 的占比到了 60% 以上。听起来很猛。但紧接着一句：bug 日清率没有太大变化，从 53% 到最高 63%。原因他们也写了：整体的触发依赖人，其他确定性流程也依赖人来推动。
一个节点被自动化到六成，端到端指标只动了十个点。
这组数据刚好是手册第三章度量那一节的最佳注脚。那节说得很清楚：AI 写了代码不等于代码进了提交，进了提交不等于变更成功发布，发布了不等于需求真正交付。所以他们搭了三层指标，L1 看 AI 用得多不多，L2 看质量有没有守住，L3 看交付有没有变快，要求三层串起来看。
我很佩服他们把这两个数字放在一起写。很多团队的 AI 周报只会写前一个。
对我自己的提醒是：我们团队现在盯的还是 L1，谁用了、用了多少 token、AI 生成的代码占比。这些数在冷启动阶段有用，能看出大家动没动起来。但再往下盯，就会出现手册里说的那种情况，大家开始关心「我的占比够不够高」，而不关心需求是不是更快上线了。
最小可行的做法我想的是：先别搭完整的数仓链路，挑一个指标把 session 和 commit 连起来，就看 AI 参与的变更，回滚率和非 AI 变更比有没有差别。一个数，能回答「AI 有没有把质量搞坏」，比十个使用量指标都有用。
小团队别抄的部分
手册第三章那张基础设施大图，Harness、知识库、Skill Hub、MCP 接入层、CLI 接入层、Guardrail、沙箱层、Sidecar 凭据管理、身份服务，全部画齐了。
这张图是对的，但它是几千人研发组织的答案。我们这种几十人、不少系统还是 PHP 存量的团队，照着图去建，大概率建到一半就烂尾了。
我的取舍是这样的：
| 手册里的东西 | 小团队的替代 | 理由 |
|---|---|---|
| OpenSandbox + 生命周期控制面 | docker compose + 一份 seed 数据 | 要解决的是「环境可重建」，不是「环境可调度」 |
| Agent Ground 环境定义 | 仓库根目录一份 YAML，写运行时、依赖、网络白名单、验证命令 | 手册 3.2.2 那份示例 YAML 可以直接照抄结构 |
| a1 CLI | 给最常用的三五个内部操作包一层 CLI | Agent 用 CLI 比用 Web UI 稳得多，这点跟规模无关 |
| Identity & Policy 全套 | 先做一件事：长期凭证不进 Agent 进程 | 手册原则四，性价比最高的一条 |
| L1/L2/L3 度量链路 | 一个指标：AI 变更 vs 非 AI 变更的回滚率 | 上一节说过 |
里面我最想强调的是环境定义那一条。手册 3.2.2 讲了个例子：Agent 改完订单取消规则、单测也过了，一启动服务连撞三堵墙，缺配置项、表里没字段、库存服务被网络策略拒绝。开发者可以逐项修好，但修完只留在那台机器上，下一个 Agent 进来再撞一遍。
这个场景我们太熟了。老项目最大的问题从来不是代码难懂，是「能跑起来」这件事只存在于某个老员工的笔记本里。之前写存量项目落地 AI Coding的时候，我说规范先于工具。现在想补一句：环境定义先于规范。Agent 连跑都跑不起来，规范写得再好也只是一份没人执行的文档。
最后说一个手册没答好的问题
2.5 节有一小段叫「转型的真实代价」，讲蒸馏焦虑：员工每写一份 SOP、每教 AI 一个流程，都是在把自己的知识导出到组织资产里。看起来是合作，结构上接近替代。结果就是关键知识开始藏起来，而 Harness 恰恰需要员工说出那些隐性约定。
手册的态度是「我们不假装有完美方案」，给了几个方向：讲清楚 AI 红利怎么分、建接住的通道、评价体系要跟着变。
都对，但我觉得漏了一个很具体的抓手：谁写的 Skill、谁维护的 AGENTS.md，就归谁。不是挂个名，是真的算产出，出问题找他，改动要他点头，季度回顾里单列。我准备先在自己团队这么试。
逻辑很简单：如果写 SOP 等于被替代，没人会写；如果写 SOP 等于拥有一块别人绕不过去的地盘，大家会抢着写。组织即上下文那篇里说过，谁拥有那个文件夹，谁就拥有组织主权。这句话放到团队内部也成立，只是文件夹要切得更细，每一块都有主人。
这招能不能解决 day 1 断档的问题，我不知道。新人进来 AI 已经在写代码了，他该干嘛，这个我也没有答案。我目前的猜测是验证，让新人从写测试、做评审、写 UNKNOWN 报告开始，因为验证是这本手册从头到尾反复说的新主战场。但这只是猜测，得跑一年才知道。
结语
整本手册我最认同的一句话在 2.1 节：Coding 被最先解决，不是因为它简单，而是因为它是少有的「对错机器自己就能判」的领域。编译过没过、测试过没过，跑一下就知道。
反过来说，AI 的能力边界，就是你能给它提供多少可验证的反馈。
所以如果只从这本手册里带走一个动作，我的建议是：挑你们团队最常见的一类需求，把它从需求启动到线上生效的每一天记下来，画一张跟手册里一样的时间构成图。编码之外占比最大的那一段，就是你下一步该给 Agent 修的路。