九月二十二日，阿里 CEO 吴泳铭在云栖大会演讲，讲了一个判断。
机器正在成为思考的主力。智能本身，正在变成一种可以规模化生产的商品。他说，未来机器的思考总量，会达到人类的一千倍以上。
第二天，同一个场地，一场关于研发方式的分论坛开场。
六位嘉宾轮番上台。有阿里的研发基础设施负责人，有千问事业部的技术专家，有蚂蚁的总架构师，有飞猪的 CTO，还有复旦大学的教授，以及机器之心的主编。
这场论坛不聊新 AI工具，聊的是一个更靠后的工程问题。
代码生成越来越快之后，软件交付真正的瓶颈，转向了哪里。
一、编码只占两三成时间
第一个上台的，是阿里研发基础设施负责人许晓斌。
他先给了一组时间结构。在阿里，写代码通常只占软件交付总时长的两三成。
也就是说，卡住的往往不是 AI编程工具 的速度，而是它周围那一整套流程。
他又举了一个夸张的链路。编码不足整体工作量的百分之一，大概一小时就能写完。但从需求进来到最终交付，仍然要二十一天左右。
时间耗在哪了。影响分析，环境准备，联调，审批，灰度，还有封网。
这个案例不是真实项目的数据。但它把一件事说清楚了。局部快了，整体不一定快。
二、智能体进生产，得先有地方跑
代码生成的问题解决之后，下一个问题马上冒出来。
它在哪里运行。结果怎么验证。
阿里开源的沙箱平台 OpenSandbox，内部每周创建量已经超过千万级。它服务于智能体的运行、训练和评测。
另一套环境体系，已经支持大约两三千个应用在独立环境里完整复原。团队计划很快扩到一万个。
环境不再是开发前的准备工作。它成了智能体能不能持续干活的底层设施。
跑得起来之后，操作也开始交给它。发布护栏 Guardrail 已经在几十个应用、约百人规模的团队里用着，管灰度发布和运维。
目标写得很直白。半年之内，让一半生产系统的发布由智能体自主完成，人只做最终确认。
人没有退出链路。人留在授权和高风险决策的环节。信息收集、证据核对和标准化执行，更多地交给系统。
三、千问团队的两个低估
千问事业部的技术专家李英各，盯的是另一个落差。
个人编码效率涨得很快，团队整体交付却没有同等幅度的提速。
他把问题概括成「一个发现，一个高估，两个低估」。
发现是个人效率不会自动变成团队吞吐。高估的是编码提速的幅度，还有自由生成代码的质量。低估的是跨角色沟通的成本，返工的成本，以及验证工作的复杂度。
他的解法是一套叫 Context & Verifier Driven Developer 的方法。产品，设计，研发，还有测试，坐在同一个工作台上。需求评测智能体先把需求文档的质量抬起来。研发负责架构和方案约束，同时是代码质量的第一责任人。
统一上下文，编码循环，上线前验收，被连成一个大循环。验收成本降下来，价值才出得来。
四、平台的用户，从工程师变成了智能体
蚂蚁集团平台技术事业群的总架构师黄挺，讲的是线上问题修复。
蚂蚁把问题分派，云上智能体，隔离评测，人工发布确认，串成一条故障修复链路。
以内部工具「阿福」为例。单个故障案例的平均修复耗时，降到了原来的四分之一。人工投入从天级别，压到少于一小时。
支撑这条链路的隔离沙箱，现场披露了几个数。容器冷启动两百毫秒。单个沙箱的内存开销八兆。单集群每秒能创建八百次。日均创建量六十万次以上。
黄挺把这种变化概括成一句话。基础设施产品的用户，从工程师变成了智能体。
过去研发平台默认操作者是人。人会读提示，会在高风险操作前停下来，也能感觉到一次变更会带来什么影响。
智能体不一样。它围绕目标连续调用工具，改文件，触发流程。原先靠人的经验和谨慎守住的边界，现在要变成一套标准接口，配上权限分层和隔离环境，再加上限流和审计。
五、把 AI 放到需求入口
飞猪 CTO 陈烨的做法更靠前。他把 AI 放到了需求的入口。
飞猪用领域知识库加一道需求闸门，先检查一个需求是不是自洽，会影响哪些系统，需要哪些资源。后面的研发流程再线上化、标准化。
效果摆在数据里。平台技术团队一个需求从评审到上线的平均周期，从二到四周缩到了一周。
过去一年，平台型技术有超过三成的业务需求由 AI 流程支撑。住宿业务有超过六成的应用接进了 AI 研发流程。商旅业务的组件生产效率提升超过七成。
陈烨用阿姆达尔定律解释这个差距。假设写代码占全部工作的一半，就算把编码速度提高一百倍，整体效率也只能接近两倍。
局部环节越快，原本不起眼的等待、沟通和串行流程，越容易成为新瓶颈。
他把研发分成三个阶段。辅助工具阶段，AI 只是帮手。执行阶段，AI 开始主导干活。到了原生阶段，智能体成了团队成员，流程本身要围着它重新设计。
人的位置没有消失。它往任务定义，结果判断，还有风险决策那边移动。
代码生成提速之后真正成为瓶颈的，他归成三件事。搞清楚要做什么。判断结果对不对。把知识写下来。
他的结论是，原生不是一个技术选择，是一个组织选择。
六、用「可驾驭性」划一条边界
复旦大学计算与智能创新学院副院长彭鑫，把讨论拉回软件工程研究。
组织重构不等于所有任务都能交给 AI。一次性方案，流程明确的工具应用，还有需要长期运行的复杂系统，对 AI 的要求并不一样。
他用的判据叫可驾驭性。任务能不能被清楚定义。结果能不能被客观验证。环境能不能被智能体理解、导航和操控。
面对复杂系统，还要持续记录需求，架构，决策，还有演化的历史，形成一份和代码对应的数字孪生。
七、编辑部自己的例子
机器之心的主编李亚洲，站在非研发的视角补了一组观察。
过去报道一篇论文，两名编辑要花一上午做翻译，做整合，做校对，还要排版和发布。现在一名编辑借助智能体，一个多小时就能完成。
效率提上来之后，编辑部承接的工作量涨到了此前的三倍左右。
但他也点出了另一面。不同编辑还在用不同的工具和提示词。个人产出已经上去了，统一的工作流还没有形成。
这个案例不属于软件开发。它说明的道理却一样。个人效率不会自然变成稳定的团队流程。
八、最后指向同一条路径
六个人从六个方向讲，最后指向同一条路径。
智能体从辅助编码，走向真实生产。它进了需求，开发，测试，还有发布和运维之后，研发的关注点也从生成速度，移向了可验证交付。
上下文，测试，沙箱，还有身份和权限，成了它进生产必须具备的工程条件。团队也要重新安排人的判断和智能体的执行。
论坛现场，《AI Native 研发范式实践手册》正式发布。手册由阿里十余名工程师和不同角色的实践者共同贡献，把基础设施、开源项目和业务一线的经验，汇成可复用的方法。
回到开场那个问题。软件没有跟着代码生成一起加速，症结落在完整的交付链路上。
需求是否清楚。上下文是否连续。环境能否复现。结果能否验证。生产操作是否可治理。
这几件事放在一起，才决定了最终的速度。
