01 / 24
代码提效的真实边界
需求从提出到上线,编码只占其中一部分;AI 最容易生成的常规代码,又只是编码工时的一部分。把局部速度直接当成整体提效,容易高估收益。
学习解读 · 带走的思考
展开这一主题的完整发言 ↓衡量 AI 的价值,应该回到端到端交付,而不是生成了多少代码。
从代码提效的边界出发,进入岗位协作、系统开放与数字员工。学习解读与完整发言按主题相连。
完整发言按主题保留整理稿的第一人称叙述,经过语句整理,并非逐字录音稿。
需求从提出到上线,编码只占其中一部分;AI 最容易生成的常规代码,又只是编码工时的一部分。把局部速度直接当成整体提效,容易高估收益。
衡量 AI 的价值,应该回到端到端交付,而不是生成了多少代码。
生成代码变容易后,评审、测试、上线和维护没有同步消失。低价值功能若更快进入系统,还会增加复杂度。
效率要和质量、使用价值一起看,否则只是把瓶颈往后推。
发言整理稿 · 对应上方 PPT
我们先看需求从提出到上线的整个过程。编码大约只占总耗时的 20%,其余 80% 花在需求、设计、方案、联调、测试和修复等环节。再把编码拆开看,AI 最擅长生成的常规代码,虽然约占代码量的 80%,却只占编码时间的不到 35%。核心代码和非功能性关键代码需要与存量系统融合,并保证稳定性与安全性,耗时远高于它的代码量占比。
因此,在其他环节不变的前提下,AI 容易覆盖的编码工作,折算到端到端交付时间还不到 7%。这里的 7% 是可以触及的时间范围,不等于整体效率已经提升了 7%。有些团队看到几个百分点的端到端改善,也有团队发现,AI 用得越多,骨干工程师反而越忙。初级同事借助 AI 生成了大量代码,仍要等骨干评审、测试并承担上线责任,骨干就成了新的瓶颈。
如果跳过评审,低质量代码会更快进入系统;如果认真把关,评审、测试和上线验证的能力又会限制吞吐。没有价值和质量约束,AI 还可能让低价值功能更快上线,消耗客户注意力,同时增加系统复杂度和长期维护成本。所以,讨论 AI 提效,不能只计算生成了多少代码,而要看完整需求的交付结果。
回看这一组 PPT ↑项目延期时增加人手,往往带来更多沟通与上下文传递。一个人借助 Agent 执行任务,改变的是协作链条的形状。
值得先寻找那些因交接而等待的环节,再讨论岗位与团队如何调整。
发言整理稿 · 对应上方 PPT
《人月神话》提醒我们:一个已经延期的项目,继续加人往往会更慢。新人需要理解项目上下文,老成员要拆任务、讲背景、同步接口,人与人之间的沟通链随之增加。AI 时代有了两个值得重新审视的变化。
第一个变化,是给一个人增加 Agent,不会像增加一名同事那样,新增一整条人际沟通链。它可以在同一个人的上下文里执行任务,提升单点的交付能力。第二个变化,是一个人借助 AI 学习并实际使用相邻岗位技能的门槛大幅下降。以前我们围绕稀缺的专业技能设置岗位,让设计、前端、后端、测试等不同角色共同完成一件事;现在,一些原本必须跨岗位反复交接的工作,有机会在更少的人之间完成。
这不是说人人立刻都能胜任所有岗位,也不是简单减少人数。真正的机会是重新审视:哪些岗位边界只是过去技能稀缺的产物,哪些沟通和等待能通过一人加 Agent 的方式消除。团队规模与交互节点下降,项目上下文也更容易保持完整。
回看这一组 PPT ↑AI 降低了补测试、看覆盖和分析问题的成本。开发者可以在仍掌握上下文时提前发现缺口,而不是把质量问题留到末端。
提早验证不是减少质量要求,而是让反馈更接近问题发生的地方。
分享提出 PDFE 与 ABE 两类更完整的责任单元:一侧贴近客户体验,一侧负责工程质量。两侧先通过 API 契约与模拟接口对齐。
角色边界可以变化,但客户判断与工程判断都需要有人负责。
发言整理稿 · 对应上方 PPT
第一件可以推动的事,是测试和观测左移。过去让研发人员写测试、兼顾运维,大家不一定愿意,也确实有成本。AI 改变了投入产出比:开发者可以更快分析覆盖情况,补齐缺失用例,在最了解实现与业务上下文的时候把问题找出来。质量责任因此可以更早进入研发过程,而不是等后面的岗位来兜底。
第二件事是需求确认左移。纸面的 PRD 很难让人准确感知软件真正用起来是什么样。借助 AI 快速做出可操作的 Live Demo,让客户和业务负责人提前体验、反馈、修正,比只围绕文档讨论更容易看清真实需求。需求越早被看准,后面因方向偏差造成的返工就越少。当然,Demo 要进入真实系统,仍然要遵守现有系统的 API 契约、数据结构和质量约束。
这两种左移会带来岗位职责的归并。面向客户的一侧,可以逐步贯通产品、设计与前端,PPT 把它称为 PDFE;工程一侧,让架构、后端、测试与运维围绕质量责任协作,PPT 称为 ABE。两侧通过 API 契约和 Mock API 先行对齐,再做真实联调。我们希望把过去一个项目里六类岗位的交接,逐步收敛成两个更完整的责任单元。减少的核心是沟通链路和等待,并非绕开专业判断。
回看这一组 PPT ↑AI 能加速 Demo 与编码,却不会自动统一老系统中冲突的业务概念、字段和规则。局部生成的规范也可能各说各话。
真正费力的地方,常是跨系统把同一件事讲清楚。
先从现有代码、模型和流程提取事实,再由人裁决术语与边界,形成可共享的 Spec。AI 才能依据同一套概念实施与校验。
规范的价值在于形成共同理解,不在于文档数量。
发言整理稿 · 对应上方 PPT
但组织和流程调整还不够。AI 可以降低 Demo 和编码成本,却不能自动消除存量软件的根本复杂性。老系统里,不同组件对同一业务对象可能有不同名称、不同字段、不同接口和不同规则。让 AI 分别读取这些局部信息,再各写一份 Spec,结果仍可能是每个组件各说各话。
《人月神话》还有一个重要判断:没有银弹。对于复杂系统,关键是概念完整性。需要有人从跨业务域的视角定义边界、统一术语和数据字典,把冲突的口径裁决清楚,再用数据结构、API 契约和共享规范把它表达出来。架构师的作用正体现在这种跨域取舍中。
规范驱动开发可以帮助我们利用 AI:先从现有代码、模型、文档和界面中提取事实,由人确认并维护统一的 Spec,再让 AI 按这一共享规范执行和校验。没有统一概念,只是多写 Spec,协作成本仍会回来。
回看这一组 PPT ↑产出能力上升后,需求选择会成为更显眼的瓶颈。分享建议在开发前说清目标客户与真实问题,上线后再看是否被使用。
速度改善必须带来客户结果,才算真正的进步。
当许多技能可以被 AI 辅助获得,识别真问题、做取舍、完成体验的判断力变得更重要。
团队需要接近真实客户,而不是只把需求池清得更快。
发言整理稿 · 对应上方 PPT
当同样的需求只需要过去一半,甚至三分之一的人力时,问题会转到另一个地方:这些需求到底值不值得做?吞吐量提升以后,组织尤其要避免把低价值需求更快地送进系统。
我们在产品评审时,要求先讲清目标客户、真实问题和预期结果。可以借鉴 PR/FAQ 的方式,在开发前先设想面向客户的发布说明:解决了谁的什么痛点,客户为什么要使用。上线后再看目标客户的实际使用渗透率,并回访问题有没有被解决、结果是否达到预期。这样,产品的价值不是上线时的一句宣称,而是事后能够验证的结果。
AI 会让许多技能的供给变得更充足,随之稀缺的是“品味”:能否识别真问题,能否在多个需求之间做出好的取舍,能否把完整体验做好。团队文化也应鼓励大家走向真实客户和真实场景,让组织能力随瓶颈一起转移。
回看这一组 PPT ↑员工开始希望智能体继续完成系统里的真实工作。仅靠模拟点击界面,成本、稳定性和权限控制都难以支撑规模化。
系统需要提供面向任务的能力入口,才能让智能体真正参与业务。
智能体在界面上反复尝试和重试,可能消耗大量资源,也可能触碰不该访问的数据。人的操作路径不天然适合机器。
开放能力时,要同时设计成本边界和安全边界。
把底层接口直接暴露给智能体,可能把原本矛盾的字段与规则一起放大。演讲强调先整理业务概念,再形成可调用的能力。
接口越多并不必然越好;一致的业务语义更重要。
替员工办事的智能体,应继承委托人的原有业务权限。能力开放不意味着获得额外的数据和操作范围。
权限边界不是后补的限制,而是业务系统可被放心调用的前提。
发言整理稿 · 对应上方 PPT
接下来谈业务系统开放。通用智能体已经能帮员工写文档、做周报,但业务同学很快希望它继续完成系统里的真实工作。我们的系统原来主要面向人类点击使用。智能体通过 Browser Use、Computer Use 去操作界面时,会反复尝试、不断重试,Token 和系统资源消耗都可能远超人工操作。我们遇到过业务系统因此承受异常高负载的情况,也必须正视权限和数据安全问题。
所以,我们开始把业务能力以适合智能体调用的方式开放出来。但开放前要先统一业务概念,再整理接口和规则,而不是把彼此矛盾的底层能力直接暴露出去。对于代员工办事的智能体,有一条硬原则:它只能沿用委托人的原有业务权限。能力接口开放得多,不意味着任何人都获得超出自身权限的数据和操作。
我们没有要求一次开放全部能力,而是先处理使用量最高、最有代表性的部分,再和业务团队围绕具体场景逐个推进。阿里云在 2026 年 5 月将相关业务系统能力面向业务团队的智能体开放。随后几个月,调用增长很快,演讲中提到部分调用量已超过人工使用,也出现了大量以前难以排期的长尾需求。这个变化提醒我们:过去不是没有需求,而是传统交付方式让不少需求无法被表达和满足。
回看这一组 PPT ↑业务团队提出接口需求后,往往发现真正卡住的是线下流程、分散数据与未标准化的经验规则。智能体让这些旧问题更清晰地暴露。
补齐业务基础,比单纯增加工具调用更有长期价值。
简单、垂直的需求可以由业务团队借助智能体闭环;平台团队则负责跨域能力、权限治理与接入支持。
开发者的范围扩大了,平台的服务和治理职责也要跟着变化。
通用智能体适合快速探索低频需求;当某类需求反复得到验证,就可以沉淀为稳定的一方 Agent 或平台能力。
先让需求出现,再决定哪些值得产品化。
从集中接单和排期,转向维护开放平台、支持复杂协同、治理数据与权限,并帮助业务同事接入和排障。
组织结构的变化,应跟随需求产生和解决方式的变化。
发言整理稿 · 对应上方 PPT
业务团队拿到智能体后,往往会提出“给我开放某个 MCP 能力”的请求。但真正进入作业链路,我们发现阻碍未必在接口:有些关键流程还在线下,系统无法连续执行;有些数据分散、标识不统一,无法串联;有些规则依赖个人经验,没有形成可复用的标准。这些历史欠账,过去被人工协作掩盖,智能体一来就暴露出来。
我们的做法是和业务团队一起补齐流程、数据和规则。通用智能体适合探索长尾、一次性的需求;当某些需求被反复验证、使用频率足够高,就应把共性能力沉淀为更稳定、成本更可控的一方 Agent 或平台产品。其余合理的长尾需求仍可由通用智能体承接。
这也改变了 CIO 团队的工作方式。过去很多需求集中交给 CIO 团队排期;现在,业务团队可以自己闭环简单、垂直的需求,并对业务结果负责。CIO 团队继续支持复杂、跨域的协同,同时承担系统开放平台的维护、权限与数据治理,以及面向业务团队的开发者运营。新时代的“开发者”不只是在代码仓库里写程序的工程师,也包括用自然语言和智能体组合业务能力的同事。我们要帮助他们接入、培训、排障,并把共性问题带回平台建设。
回看这一组 PPT ↑分享回顾了已进入真实业务的数字员工实践,并以覆盖工作量说明规模。关键标准仍是能否承担任务、交付结果,而不是能否完成演示。
评价智能体,应该用同一业务结果衡量,而非只看对话表现。
RIDE 从重组关系、识别任务、定义产品到真实执行,要求任务有可衡量目标,并在运行中持续评测。
方法的起点是找准重复发生的真实任务;终点是验证结果。
跨行业交流中,许多企业认可方向,却仍面临数据、评测和交付门槛。演讲把这些反馈作为继续产品化的原因。
一个框架要产生作用,需要与具体业务场景和运行条件接上。
“睿系列”RaaS 试图把内部复杂业务中验证过的能力产品化,同时强调自然交互与真实业务结果。
产品化的难点,是让能力能在不同组织里稳定运行。
发言整理稿 · 对应上方 PPT
回看更早的实践,我们已经让 28 类数字员工进入真实业务场景,PPT 标示其覆盖的工作量折合 2000 多个 HC。这里的数字员工,不是能演示一段对话就算“上岗”。它必须承担原本由人完成的真实任务,接受相同业务结果的检验;在效果与效率上达到或超过相应岗位,才有资格被当作生产力使用。
在这些实践和近百场跨行业交流中,我们把方法沉淀为 RIDE:Reorganize,重新理解组织和 AI 的生产关系;Identify,寻找重复发生、原本由人执行且能清楚衡量的任务;Define,把任务定义为产品,明确业务目标与运营指标;Execute,在真实业务中执行、评测、改进。数据与评测贯穿落地过程。如果没有足够的任务数据,也无法判断完成质量,方法看起来再合理,都很难稳定复制。
很多企业认可这些原则,却仍觉得落地有门槛。因此,我们把阿里云自身复杂业务中反复验证的能力继续产品化,在这次分享中发布“睿系列”RaaS 产品,目标是“拟真人效果,交付真结果”。面向需要和人打交道的工作,交互必须自然;面向复杂作业,智能体必须能完成多步骤任务,并与真实员工的业务结果直接比较。我们希望把场景中的技术和方法沉淀下来,让企业客户也能使用。
回看这一组 PPT ↑演讲把大模型应用、AI 编程、业务系统开放与数字员工产品化放在一条演进线上。每一次能力变化,都会让原有组织安排再次受到检验。
路线图可以帮助回看方向,但不该代替眼前业务的验证。
这里的 AI Native 更像一种持续跟踪能力边界、识别旧流程瓶颈、再用组织变革释放价值的方式。
它不是一次改造后的标签,而是不断重做判断的能力。
分享以 CIO 团队自身的变化收束:模型升级后,旧脚手架和做法也可能失效。是否有人使用、是否解决问题,仍是最终判断。
把变化当作常态,持续检验结果,比维护一套固定答案更重要。
发言整理稿 · 对应上方 PPT
回顾这几年的变化,我们先经历大模型进入企业,再看到 AI 编程改变产研协作,随后是通用智能体推动业务系统开放,今天又把部分实践沉淀为对外的产品。技术能力持续变化,组织也不能停在某一次调整上。
我对 AI Native 组织的理解,不在于它给自己贴了什么标签,而在于它是否持续追踪 AI 的能力边界,识别阻碍这些能力发挥的旧流程和旧习惯,并愿意用组织变革打通瓶颈。最终的衡量标准,仍然是企业内外的真实业务价值。如果做出许多软件,却没有人使用,也没有解决问题,就谈不上有效的 AI 转型。
我们自己的 CIO 团队也还在这个过程中。模型升级时,过去搭建的一些脚手架可能很快失效,原有做法要不断更新。因此,AI Native 不是一次性到达的终点,而是持续理解能力、调整组织、验证价值的过程。我希望我们既能向内推动阿里云的业务组织转型,也能向外分享方法和产品。今天的分享就到这里,谢谢大家。
回看这一组 PPT ↑把组织拆成架构、信息、决策、学习、人员与支撑环境,再看它们怎样协同产生超出个体之和的智能。
完整发言保留校订逐字稿的口语与听辨存疑标记,省去重复的时间和姓名标签。
这场分享借用大模型架构来重新看组织:个体的知识和经验形成能力,而组织需要让这些能力产生大于简单相加的智能。
好的组织设计,关键不只是拥有更多强个体,还要让他们能共同学习。
演讲用能量消耗作比喻,说明 AI 与人的计算方式不同。这里更值得带走的,是人机分工不能只理解为工时替换。
应从任务性质与协作方式出发,寻找两种能力的互补。
校订逐字稿 · 对应上方 PPT
去年我们就在说,每个人都是一个大模型。那为什么这么说呢?想想看,我们每个人的预训练其实从五千年文明就开始了。我们开口说的语言,遵循的每一个常识,在学校里学的那些公式和定理,没有一项是我们自己发明的。文明的存量其实早就已经提前写进了你的库存,而在这之上的才是你自己的那一份。你从小到大接受的教育,你的家庭环境,你读过的书,见过的人,对吧?
这一点一滴都在促成你看待问题的方式和你判断事物的直觉。就没有一个人是凭空而来的。每一个人都是文明的压缩文件,区别只在于你被什么样的数据和经历训练过。那你走出家庭,走入职场,是对你第二份训练的开始。你接受的每一次培训,在公司文化里浸泡的每一天,你跟着你的团队学会的做事方式、说话方式、协作方式,都是在给你做什么?
后训练对齐。大模型的后训练是让模型按照人们需要的方式去输出,而你的后训练就是让你按照这个组织需要的方式去工作,去协作,去做判断。那从文明到教育到职场,每个人就是这样一层一层地被训练出来。所以你的权重不是天生的,是你的经历一笔一笔写进去的。这就是说为什么人人都是一个大模型。那我给大家算一笔账,就是人这个大模型,我们知道模型都很耗能量,对吧?
那人这个大模型要消耗多大的能量呢?一个成年人一天消耗能量 2000 大卡,换算成电能就是 2.3 度电。那这是什么概念?一张英伟达 B200 的芯片,满载功耗 1000 瓦,2.3 度电就够它跑两个半小时。就是说你一天吃进去的所有能量的总和,相当于一张高性能的 AI 算力卡跑两个半小时。而在这两个半小时里面,这张卡可以处理的数据量要远远大于你一辈子可以阅读的信息量的总和。不是十倍,不是百倍,是几个数量级的差距。
所以 AI 的本质从来都不是替代人,也不仅仅是 7×24 小时不知疲倦的数字劳动力。AI 真正在做的事情,是用同等的能量,[现场旁人插话遮盖了部分主讲语句]驱动截然不同的算力,而且它所产出的密度更加稳定,不疲劳,不情绪化,不被遗忘。所以今天早上主论坛,无独有偶,我们的 CEO 吴永明,我们叫他吴妈,说的到底是人工智能还是机器智能?
AI 本质上是完全不同的。那我们再来看组织。组织就是围绕着一个共同的目标集合在一起的一群人,对吧?所以传统意义上一个好的组织是什么?是能够产出远大于个体加总的生产力,这个是管理学一百年来的共识。但 AI 组织是什么?大家想一想,刚才我们的 CEO 蒋芳女士,我们叫她姐姐也说了,超级个体加总在一起不一定等于超级组织。
如果你真正是一个 AI 组织,一定能够产出远大于个体加总的智能。这个是我们说的 AI 组织。所以你其实不必特别纠结于,你是来自一个传统行业,还是来自一个从 Day One 开始就是 AI 原生的业务;或者你是一个几个人、几十人的组织,还是现在已经是一个几千、上万人的组织。当然我们必须——
要承认,在现在的背景之下,过去几千、上万人组织所积累的这些运行规则可能都不适用,所以要付出更大的努力去做一些切换。那么 AI 组织就是能够产出远大于个体加总的智能。既然我们不必纠结于此,就要回到组织的本质,用大模型架构里的这些核心机制,一个一个地去映射到 AI 组织的基本要素上。
回看这一组 PPT ↑架构、信息、决策、学习、人员与支撑环境不是六个孤立模块。它们像一个生命体的骨骼、感官、判断、反馈、执行与底座。
改一个环节时,要看它能否让其他环节一起运转。
校订逐字稿 · 对应上方 PPT
首先,组织的六个基本要素,它不是六块拼图,它是一条链,是一个生命体。那生命体首先要有骨骼,骨骼决定你的形状,哪块肌肉连着哪块。映射到组织就是你的架构:谁和谁协作,分工的界面在哪里。有了骨骼之后要有什么?感官和神经,对吧?眼睛看,耳朵听。[末尾一句转写不清。]
这就是组织信息、数据和上下文怎么产生,怎么传递,怎么去做沉淀。有了信息之后,进入到大脑还要做判断、做决策。做完判断以后,身体还得知道对不对,烫了要松手,这就是反射弧。所以组织也是一样,要靠行动和得到反馈来进行进化和纠错。有了学习之后,执行这一切的是人员,是组织能力和进化的载体。
那让前面所有这一切能够顺利地运转起来,我们还需要有支撑环境。刚才蒋明泉先生说的,我们需要有算力,我们需要有权限,我们需要有安全,我们需要有工具。那大模型这一路走过来的每一个架构答案,包括怎么去做分工,怎么去传递信息,怎么做决策,怎么去学习,怎么部署和运行,就是 AI 组织的架构方式。要像训练一个大模型一样去设置你的 AI 组织。
我所在的阿里云国际业务,是一个既包括了产研,又包括了销售的事业部型组织。我可以非常真切地感受到,在产研组织里面,AI 化是很自然而然的。大家想想看,一行行代码就是你的工作语言,也是你的工作产出,同时也是我们刚刚说的上下文。但是在销售组织里面,有非常多的线下场景,非在线化的、非结构化的数据,所以智能化的产生并不是自然而然的。
我想在座的各个企业都有自己的销售组织。今天我就拿我们在阿里云国际业务销售组织的一些实践,为大家一一去解构组织的这几个基本要素。组织也在进化,成为一个新的物种,成为一个大模型,成为一个能够产出大于个体加总智能的新的生物。
回看这一组 PPT ↑先把不同团队指向同一业务结果,再根据任务选择更合适的专家与路径。分享用市场活动、线上投放和市场情报说明动态分工。
局部指标都完成,却没人负责最终转化,是组织架构需要警惕的信号。
校订逐字稿 · 对应上方 PPT
首先是架构。传统做法是什么?是先有分工,再有组合。每个模块都是独立训练的,各自优化自己的局部指标,最后推理的时候再拼接在一起。传统组织也是这么建的。AI 组织恰恰相反。传统组织是先画组织架构图,产品、研发、销售各有其位,然后再把各自的目标层层分解到各个部门的 KPI 或 OKR 上。部门之间是靠接口来协作的,包括会议、交接、文档。
但 AI 组织恰恰是相反的,先有一个共同的目标函数,分工是在共同的训练当中自然找出来的。所以说每一个专家,如果我们去做这些 Agents,每一个专家在接受训练的过程当中,所接受的梯度反馈,并不是你在自己这个领域做的局部打分,而是你对最终的结果到底有多大贡献的全局信号。这样自然而然形成的是专家之间的互补性分工。[现场旁人插话遮盖了数秒主讲语句,随后提到“梯度收益最大化”。]
但如果把它搬运到组织,当所有人都被指向一个最终的衡量指标的时候,分工就是在比较优势里面自然涌现出来的,而不是在组织架构里面人为去切割出来的。这就是大模型训练的 MoE 架构。拿我们在国际业务的实践做例子,比方说开源这件事情,过去是分散在好几个部门手里,而且每个部门都有自己的 OKR。市场部看的是市场活动产生的 Pipeline 蓄水。
市场洞察看的是拿回来的市场情报的数量跟质量,官网部看的是线上投放拿回来的有效线索数。每一个部门最后完成的指标看起来都不错,但是最终这些线索到底对我们整体的业务结果产生多大影响,谁也说不清楚。局部指标都有人负责,最终指标没有人负责。那在一个 AI 组织里面,并不是这样的。线上投放、线下活动、市场情报,不再是三个独立的部门。
它们都是面向同一个目标函数,就是线索转化的 ROI,在同一个路由器下产生的三个开源专家。一个任务进来的时候,路由器就会按照每一个专家在线索转化上的 ROI,把它分配到相应的专家身上。比方说,如果我们要做的是存量客户搬站的 Upsell,这个时候最先激活的是线下活动专家,因为它需要深度的建连、深度的信任和现场交互。
如果我们要做的是新模型迅速上量,这个时候要求的是规模和速度,最先激活的很有可能是线上投放这个专家。再比如说,如果我们要进入一个新的行业,比方说覆盖全球具身智能这个领域,行业地图都还没有建立,所以我们需要先激活的是什么?市场情报这个专家。这个时候认知要先于最终转化。而且路由器其实是根据每一轮、每一个专家在每一项任务上表现得怎么样、擅长什么,这些回流的数据学习出来的。也就是说,把任务派给某个专家的路由——
同样也是在接受梯度,跟专家一起演化的。任务分派并不是写死在职责说明书里。这就是我想说的。AI 组织往往能够突破组织承载的边界,把单次任务的成本跟组织的总容量解耦。让这个组织有很多专家,能力储备很广,上限很高,但每件事情都可以跑得很轻。架构之后是信息。我们都知道,智能的前提是数据。
回看这一组 PPT ↑CRM 字段记录的是已提炼的事实,许多关键判断却藏在拜访、会议和客户犹豫的现场。AI 降低了记录成本,也让这些材料能进入检索、记忆和流程。
信息成为资产,需要被组织再次调用,而不只是被存放。
校订逐字稿 · 对应上方 PPT
传统企业无法真正实现智能化,最大的障碍从来都不是算法,而是数据。但这里要做一个关键性的区分:企业过去花几十年积累的 CRM 系统、报表系统,沉淀的大多数都是我们说的 Facts,就是那些被定义、被抽取、被压缩成字段的结构化结论。而决策真正依赖的是上下文,是那些 Fact 还没有被抽取出来的原始现场。它们一直停留在会议室,在拜访的路上,在客户的犹豫中,从来没有经过系统。
企业级数据的在线化,露出水面的只是冰山一角,水面以下的山体才是 Context。那问题就来了,为什么过去解决不了?因为过去把这些 Context 写入系统要依靠人。开完会花半个小时填写 CRM,这笔税太重了,重到数据必然是失真的。填进去的是老板想看的,不是真实发生的。但现在这个问题为什么可以被解决?
因为两个变量同时在发生变化。首先,采集成本趋近于零,听记、转写、摘要,都是大模型自己完成的。其次,这些 Context 终于有了去处:它可以进检索库,可以进 Agent 记忆和流程,甚至可以进到后训练当中。拿我们在国际业务的实践举例,接收到这些 Context 的传感器,就是每一个销售人员、每一个售前架构师、每一个交付和运维同事。
传感器又分成两部分:[采集方的名称听辨不清]负责采集原始业务,每一次会议拜访,每一次技术方案评审,听记、小记,眼观六路、耳听八方,被动、完整、不带立场;人去负责标注什么是关键、重要的,客户的犹豫意味着什么,哪次转折改变了方向。所以采集层是宽而客观的,而标注层是窄而主观的,这就是多模态训练的数据配方。其实跟大模型训练[中间一句转写不清]一样,多模态融合,把人对物理世界的理解接入到模型系统。
组织的下半场也是如此,把人对物理世界的感知接入到组织系统,让组织真正长出多模态的感官。组织过去只有[转写不清],现在终于有了上下文。所以你得到的不再是一个客户在某个时间切片上的 CRM 字段,或者报表快照,而是一个客户、一个市场在时间轴上的立体记忆。两个组织调用同样的计算模型,区别就在于它们的后训练数据。
公共数据是共享的,而只有企业私有、独有的这些非结构化 Context,才是你独有的。后训练就是把这些独有的 Context 抽取进组织这个大模型权重的过程。大家想想看,留在员工脑海里、留在本地电脑里的,都是个人终端上的私有权重,人走权重就清零了。剩下的只有你对客户的理解,而理解本身也不是资产。被写进组织这个大模型里的理解,才是真正的壁垒。
写入有三层,壁垒是递增的。第一层是写入检索库,能被搜到;第二层是写入 Agent 记忆和流程,能被自动调用;第三层是写入后训练,让权重成为职业本能。有了感官之后,就要做决策,这是关键问题。刚才我们的 CIO 蒋明泉先生也说到注意力分散的问题。
回看这一组 PPT ↑常规事项可由规则处理,例外事项交给少数关键人,管理者先看压缩视图;战略问题才展开全量讨论。
不是每个决定都需要所有人参与,关键是为不同风险配置合适的注意力。
校订逐字稿 · 对应上方 PPT
组织里面最昂贵的隐性成本就是注意力:谁应该关注谁,多少人应该参与一个决策。刚才他也说到,延期的项目里面加人会拖慢节奏,这是 Brooks 定律[术语据语境校订]。因为注意力的开销是非线性的。n 个人参与决策不是 n 条链路。五个人参与评审是十条链路,十五个人参与评审是多少条链路?
是一百零五条链路。这和全注意力机制的复杂度是同一个数量级。在传统组织里面,默认都是全注意力机制,而不是合理分配。为什么?因为所有人都避免独立担责,所以一切决策默认向上升级、向外扩散。拉所有人对齐是最保险的个人策略,这就是组织里面的默认升级偏差。而在模型里面,注意力的分层分叉是架构确定的;在组织里面,我们必须把它显性化出来。
在我们的国际业务,确定的是四层决策机制,分别需要不同的注意力。第零级是线性注意力,比如标品目录价、授权范围内的报价和续签,系统规则自动放行,理想状态是没人注意,不需要人参与。第一级是稀疏路由,比如超授权折扣、非标的商务条款,这时候需要形成结构化的 one page:客户历史、当前方案、报价请求、毛利影响,路由到一到两个关键审批人。
审批人的注意力被锁在这个结构化模板当中,不多不少。第二级是 MLA 低秩压缩,比如商机管道评审,几十上百个商机不可能逐条过,那就压缩成低秩的视图:头部商机、风险异动、决策请求。管理者只需要阅读这一页的管理视图,必要时才下钻看全量。同样被压缩的还有客户上下文,两万 Token 的客户往来历史可以被压缩成五百 Token 的卡片,带宽直接砍掉四十倍。
这一级的纪律就是只允许传递异常和请求,不允许传递叙事。第三级是全注意力锚点,比如新赛道进入、战略大单、破例定价[末例结合 PPT 校订],这时候所有相关方都需要参与。全量的数据、深度的数据全部展开,不许压缩。[后一句短语转写不清。]这个锚点产出的是一份决策文档,随后要降秩,成为下一级行动的压缩依据。组织当中的判断力不取决于有多少人参与了决策,而取决于每一级决策是否恰好得到了它所需要的注意力。
回看这一组 PPT ↑对标和复盘只能提供线索;对照实验更能判断策略是否真的有效。结果可验证、反馈快、试错成本低的业务,适合先建立学习闭环。
让组织学得更快,要先找到能清楚给出反馈的场景。
校订逐字稿 · 对应上方 PPT
多一分是浪费,少一分会是失忆。有了决策之后,组织还需要知道对不对,要有持续学习的能力。答案就是长程强化学习。但要注意,对标本身不是学习,只是模仿。没有对照组,是把相关性当成因果。所以学习唯一的行动标志就是对照实验。把“策略上线,业绩变好,归因于我”的迷信,变成“策略上线,相较对照组提升,因果成立”这样的知识。
强化学习的死穴全世界都一样,就是奖励信号从哪里来?传统业务大多数验证周期很长,成败要等很久,充满噪声。这时候企业就会自己去造一个裁判。老板拍脑袋决定,这相当于训练了一个昂贵又不能够 Scale 的偏好模型,而且一定会被 Hack[据语境校订]:考核什么,下面就表演什么。而推理模型这一轮真正的突破在于换了一条路,它不是把奖励工程出来,而是把它发现出来。
数学和代码这两个领域,答案是天生可验证的,所以是免费的奖励函数。回到组织,答案是一样的:别造裁判,去找你组织里面自带的裁判。什么叫自带裁判?有三个先决条件,大家可以对照一下。第一个,结果可自动验证,不依赖权威打分;第二个,反馈周期短,成败信号清晰;第三个,单次试错成本低,允许高频重复。你们组织里有没有这样的环节?
如果有,它就是你的 Coding,你的免费奖励函数,你的自举支点。拿我们在国际业务举例,我们是电销、网销业务先行。验证一个商业化策略的时候,去拿电销、网销投放引流,激活 Upsell,再到[转写不清]触达,全面都是数据闭环。每一轮的 ROI 和转化率都能自动计算,小时级观测。策略上线,跑一周,数据说话,迭代再上线。每一轮的积累都是因果,而不是幻觉。
Agent 一出现,就把这个闭环再推高了一层,[关于 Human 与 Agent 分工的一句转写不清]。人退回到了调度中心。所以自带裁判的业务,其实不仅仅点燃的是这一个业务。推理模型是在数学和代码这两个领域里面练出了通用推理能力,组织也是一样。要先在这些自带裁判的业务里面练出因果思维和实验纪律,再把它们放大到那些反馈相对模糊的业务上去。
回看这一组 PPT ↑分享把选人比作预训练:过往真实环境塑造判断力;面对尚无成熟路径的新工作,还需要观察一个人自我更新的速度。
履历标签之外,更应看他如何在真实难题中形成能力。
校订逐字稿 · 对应上方 PPT
效率的升级形态不是做得快,而是学得快。自带裁判的业务,就是组织里的一个学习引擎。学习、执行这一切的,还是要靠人。回到人员,最核心的两个问题:人怎么选,怎么育。后训练不是扩容,模型如此,人也如此。产品、工具、流程、组织是教得会的,但判断力、推理能力、学习速度,组织教不会,只能筛。
这三年半,我同时负责阿里整体的招聘工作,越来越确信一件事情:AI 组织的杠杆在于招聘端的蒸馏质量。要找到那些已经被高质量环境预训练过的人,而不是幻想通过入职以后培养,把不合适的人[转写不清]。你会发现,被强环境蒸馏过的人,入职以后只需要很轻量级的对齐,就可以接近满血。在传统组织里面,弱个体会被流程稀释,招错一个人,有 SOP 去缓冲。
但是在 AI 组织里面,一个人加一组 Agent 再加上算力,就相当于一个团队,强者的产出更是放大十倍、百倍。反过来也是一样的,杠杆越高,招聘错误也越贵。拿我们在国际业务招人的标准来举例。比如 FDE,前沿部署工程师,必须经历过在特定行业和技术领域里深度、真实的训练环境,这是不可以被压缩和跳过的预训练。
所以你看这个人过去两份工作做了什么,有没有打过端到端的硬仗,就知道他的预训练权重值不值。比如招 BD,我们需要招有技术背景、具备动手能力的 BD。因为一个有动手能力的 BD,自己说出去的承诺可以先验证一遍,是个低幻觉率的 BD;而只会说的 BD,承诺跟现实之间的差值,往往需要整个组织来还。
再比如,在培训部,我们有三项招人的通用特质:创业思维、逆向思考、AI 原生。大家要注意,这不是培训出来的能力标签,这是在特定环境之下预训练出来的权重结构。一个曾经因为在模糊中交付而被奖励的人,和一个曾经因为遵守规则而被奖励的人,他们的权重结构长得完全不一样。所以面谈时要看他曾经被什么环境奖励过,而不是他自己声称自己有什么标签。
当然,AI 原生的工作方式,其实全球都没有成熟的训练环境,也没有人带着现成的权重来。所以对于最前沿的位置,还需要把存量权重筛选变成学习率筛选。不是看他已经装了什么,而是看他自我蒸馏的速度有多快。存量权重筛选解决当下,而学习率筛选解决未来。那如果前面五个要素是组织这个模型的架构,第六个要素——支撑环境——就是让这个模型能够跑起来的运行底座。
回看这一组 PPT ↑云与算力提供能量,Harness 让模型具备执行能力,身份、权限和数据边界构成安全护栏。三者共同决定智能体能否进入核心业务。
能力、工具与治理要一起设计,才能从演示走向运行。
校订逐字稿 · 对应上方 PPT
如果没有运行底座,模型再漂亮也只是论文。它是一个三级火箭。第一级是云基础设施,包括 GPU、CPU、云和通算云。一切智能跑在云上是默认的运行环境,而不是某个 AI 业务专用的云。第二级是 Harness。模型本身只能续写 Token,是 Harness、工程工具调用、CLI、上下文工程和执行循环,才让模型真正长出了手脚,变成能够干活的智能体。
第三级是安全护栏,前面也提到过的权限、身份、数据主权。组织敢不敢把核心智能交出去,取决于这道边界。[此处一句转写不清。]能干活、放心用,组织智能才能真正从演示间进入核心业务。如果类比到身体,云和算力基础设施就是能量系统,Harness 是运动系统,安全护栏是免疫系统。能量供得上,手脚动得了,免疫系统不失防又不过激,这才是一个真正能上场干活的智能体。
组织的前五个要素与第六个要素之间不是先后关系,它们是相互支撑的。组织设计为运行底座提需求,运行底座也为组织设计定边界。所以组织正在进化成一个新的物种,一个大模型。这个大模型在今天之前只是一个比喻,而在今天,它真正成为一个可以设计、可以工程化实现的东西。接下来,我就用我们在国际业务的 Agent 平台 IAH,为大家直观展示构建一个 AI 销售组织所依赖的硬性载体。
德国的工程知识场景优先,安全团队还需要确认数据边界。
回看这一组 PPT ↑组织智能不是把六项实践逐个打勾,而是在有限能力、算力与时间下,持续调整它们的关系。
单点优化若不能改善整体产出,仍可能只是换了一种瓶颈。
收束页把焦点放在单位投入所产生的智能。真正的变化,要把分工、信息、决策、学习与人员选择写入日常运行。
判断 AI 组织是否成立,可以回到它在约束下交出的结果。
校订逐字稿 · 对应上方 PPT
好,组织的这六个基本要素,其实不是六个独立的最佳实践。回到我们一开始说的,AI 组织的本质,其实是以最高的效率产生最大的智能。本质上它是围绕一个共同的约束写出来的一个联立方程。这个约束就是在有限的能力、算力、时间下,要把单位投入的智能产出做到极致。很多 AI 组织其实只是在旧架构上外挂了一些 AI 工具,把旧车换了新的涡轮。
但真正的 AI 组织,是要深入思考怎么把这些稀疏、融合、压缩、闭环、蒸馏、[最后一个并列词转写不清],写入到组织这个大模型架构里面。未来的区分点完全不在于用不用 AI,这已经不是一个要讨论的问题,而在于你的组织是不是始终以效率、以性能为目标。如果是,资源越受限,你的组织反而会越强;如果不是,资源一旦收紧,就可能[句尾转写不清]。
[承接上文]以效率为第一性原理的联立方程组。我是来自阿里人力资源部的袁亦敏。希望刚才的分享能给大家在走向 AI [转写不清]的道路上获得一些启发。感谢聆听,谢谢!
回看这一组 PPT ↑本页合并现场 PPT、学习解读和两份完整发言材料。卡片中的概述与“带走的思考”属于整理者的学习解读;展开后的正文来自原稿。蒋林泉一篇是经过语句整理的发言稿,袁亦敏一篇为校订逐字稿。图片保留现场拍摄原貌。
第二场资料中本人自述及原始页面均写作“袁亦敏”,本页据此采用该姓名。校订稿中的听辨存疑提示随正文保留,原始时间索引与整理说明可在下载稿中核对。