作者｜Cynthia
编辑｜郑玄
9 月 22 日上午，阿里巴巴集团 CEO 吴泳铭站在云栖大会主论坛上讲到 AI 时，又一次用了电力作为参照。
今天回头来看，电几乎成为了现代社会最重要的基础设施生产力。
但 1882 年，即便是最负盛名的科学家与商人爱迪生，所能想到的事情也不过是在纽约珍珠街建起一个电站，点亮 400 盏电灯。甚至在当时为了推广电灯，还不得不用免费赠送半年电力的方式来吸引用户。
今天的 AI Coding，很可能也只是「电灯」——它已经能替代一部分旧工作，帮人写代码、写报告，但站在 1882 年的电灯下面，人们永远也想象不出后来改变了整个人类社会运行的电气世界，究竟是什么样子。
不过，关于这个故事，其实还有个没讲完的下半段。
此后十多年时间里，电力已经进入工厂，但生产率却并没有立刻起飞。因为早期工厂接入电力时，大部分企业的做法是直接拆掉蒸汽机，换上一台大型电动机。厂房中央的传动轴没有消失，皮带和齿轮也没有消失，动力与组织的生产上限，仍然沿着蒸汽时代留下来的结构传到每一台机器。
直到后来，小型电机可以直接装到不同机器旁边，工厂才逐渐摆脱中央动力轴。机器不用再围着一根轴排列，设备位置、物流、工序乃至厂房结构都可以重新设计，第二次工业革命才正式拉开序幕。
今天的企业也处在类似的情况中。
模型已经进公司了。工程师开始用 AI 写代码，销售用它找客户，HR 用它筛选信息……可审批不会因为模型升级自动缩短，部门边界不会因为 Token 变便宜自己消失。一个岗位突然快了十倍，带给下一个环节的，可能只是无穷无尽的加班与延期。
所以，当天上午主论坛讨论完机器智能之后，下午的云栖大会 AI Native 组织论坛就立刻接棒，将 AI 时代的组织变革作为讨论核心。
这并不是云栖大会上第一次分享相关话题，但却是第一次由阿里 CPO 和 CIO 两条线共同完成的讨论。
过去，业务系统怎么搭建是一类问题，岗位、协作、人才和文化怎么调整是另一类问题；AI 真正落地生产流程以后，两件事已经很难各自解决。
率先上台的阿里巴巴集团首席人才官蒋芳，先分享了一个思考：AI Native 组织到底只是一个被热炒的概念，还是组织必然会走向的方向？
AI Native 的组织到底是怎么运作的？
AI native 组织是一个必然的进化方向，但不同企业产生的化学反应并不相同，这已经成为了新的管理共识。
而在过去一年的观察和实践中，蒋芳逐渐总结出了一个规律：通常来说，那些一号位真的理解 AI，而且愿意亲自动手；或者原本的工作已经高度数据化；团队规模比较小；核心团队高度互信，是最容易完成 AI Native 时代组织转型的企业。
但偏偏，阿里本身已经成长为了一个拥有十几万名员工的庞大组织，并且组织内部业务形态差异巨大，协作关系复杂，甚至还有大量决策没有完整进入数据链路。想先在总部画好一套未来组织，再要求十几万人一起完成切换，几乎是天方夜谭。
并且，在真正尝试转型之前，阿里已经先感受到了另一层落差。蒋芳发现，过去一两年时间里，AI 加速下，组织里已经出现了一群超级个体，但是将这些超级个体放在一起，并不会自然得到一个超级组织。
阿里云 CIO 蒋林泉，过去一年在产研团队里，试图解决的正是这种落差。
于是，团队把整个研发过程剖析了一遍。
数据显示，开发人员真正用于写代码的时间，大约只有工作耗时的 20%。剩下的大量时间花在需求沟通、设计、测试、Review、上线、运维以及不同角色之间的协作上。即使只看代码，AI 最难处理的涉及老系统兼容、核心逻辑、安全和线上稳定性的核心代码、复杂代码，占比也只有 30%（甚至更少），而这部分任务仍然压在经验最丰富的人身上，并占据他们 80% 的时间。
有时候甚至还会出现：年轻工程师借助 AI，半天时间迅速产生过去几天才能写完的代码，导致团队里那些能 review 代码的骨干，被翻倍的平庸代码「DDoS」，效率被卡住。如果 AI 只提升吞吐，对 E2E 的时间消耗甚至会产生负价值，而缺少价值与质量约束的代码越多，存量系统负担越重。
这也是软件工程经典著作《人月神话》里讨论过一个著名问题：一个延期的软件项目，如果继续加人，往往不会因此变快。新人需要理解上下文，老人要重新拆任务、解释和带人，团队规模越大，沟通链路也会迅速增加。
但到了 AI 时代，其中两个条件开始变化。
第一，给一个工程师增加几个 Agent，不会同时增加几条人际协作关系，单节点效率提升之外，还会减少组织中的沟通节点。
第二，AI 也在大幅降低一个人学习相邻技能的门槛。通常来说，一个岗位要跨到另一个专业，需要很长时间的训练，现在学习成本可以下降到原先的 10%，甚至 1%，这直接改变了产研组织原来的分工方式。
过去，产品、设计、前端、后端、测试、运维、架构之所以被拆成不同岗位，很大程度上是因为专业技能稀缺，一个人很难同时掌握多项能力。
但是借助 AI，个体的能力边界拓宽可以直接带来组织分工的重构。
蒋林泉团队最先变动的是测试和运维。过去研发不愿意花大量时间补测试，一个现实原因就是投入高；AI Coding 出现以后，检查覆盖度、补 Case、生成日志和观测代码都快了很多，而研发又掌握最完整的业务上下文。于是，一部分原本放在后面的测试和运维职责，被重新收到研发环节。
需求阶段也发生了类似变化。过去产品经理先写 PRD，再交给设计和研发理解。问题在于，一份文档很难保证几个人脑中的产品完全一致。现在产品、设计甚至客户自己都可以先做出 Demo，一旦需求理解出现偏差，当场就能暴露。很多过去要等到开发后期才发现的返工，被提到了最左端。
于是，产品经理、设计和前端合并成 PDFE 岗，从用户意图一直负责到用户界面架构；后端和架构也合并成 ABE 岗，从数据结构一直负责到系统稳定性；两边用 API 契约完成衔接。这被称为 Half-Stack 的人才新结构，让整体的交互链路大幅提效。
由此蒋林泉发现，现在的组织结构已经不再是以技能为中心，因为 AI 让大家做成一件事变得简单，技能已经大幅通胀。对应发生的是品味的通缩，这对团队来说是定义问题的能力——他鼓励团队在文化上「左移」，走到客户那里去找价值和答案。
但随之而来的一个新问题是：CIO 的产研组织可以这样实践，但一个大组织架构真的可以按照这个模式大刀阔斧地直接变革吗？
02
大组织没有办法齐步走，
那就让一部分人先成为「特区」
在蒋芳分享中，她讲到一个故事。
今年有业务团队去硅谷学习，其中一个产品一号位起初并不想去。他手里正盯着几个关键项目，觉得自己这个阶段离不开，甚至申请过希望留下来。
但从硅谷回来以后，他做的第一件事，反而是把那些过去觉得不盯着就不放心的事情全部交给下属。随后，他从团队里挑了七八个年轻人，跟他们一起研究怎么让 AI 更好地参与工作：什么信息应该交给 AI，什么步骤可以删掉，人应该留在哪些地方。
负责人自己先改变工作方式以后，团队里的其他人才也开始跟着检查原来的流程。
蒋芳因此把「Leader 先下水」列为组织 AI native 转型的第一条。管理者如果没有真正用 AI 完成过一段完整工作，只看下面报上来的使用率、Token 数和 Demo，很难判断哪些动作只是被工具加速了，哪些流程已经到了应该拿掉重做的时候。
但阿里的规模也决定了，变化不可能等所有管理者同时下水。
所以她的经验第二条是「开特区」。
Qoder 团队就是其中一个样本。五个人、七天做出 QoderWork，方案当天讨论、当天决策、当天修改；团队内部能决定的事情，不再向外拉一圈人开会。行业里可能需要几个月验证的想法，他们先在一周里跑完一轮，再根据结果继续迭代优化。
那么如何找到适合被开特区的团队与业务？阿里云智能集团 HR 副总裁袁亦敏的经验是「先找到那些自带裁判的业务。」
但更进一步，如何把这种组织转型的特区表现变成一种常态？在公共云业务侧，阿里云智能集团 HR 副总裁包晨星的经验是：想办法让员工主动跨过岗位边界。
比赛本身的根本目的在于打破束缚，让人越来越全栈，让岗位的界限越来越模糊。也只有这样，组织中原本那些为了交接而存在的环节与不必要的流程，才能真正被省略。
03
人与 AI 的能力变化之后，
组织的系统也要同步变化
在演讲中，蒋芳反复谈到一个观点是：超级个体的集合并不意味着超级组织的形成。
原因之一就在于，具体到业务中，旧的业务系统本身，其实是按照旧的工作方式设计出来的。
今年通用智能体迅速普及以后，蒋林泉发现 CIO 团队负责的业务系统多了一批 Agent 使用者。
但过去这些系统是给人设计的。人的速度有限，即使某个流程有些绕、不同系统里的数据定义略有差异，人也可以凭经验把事情继续做下去。
Agent 不一样。
它会自己打开浏览器，一次失败马上重试，再失败继续重试。多个 Agent 同时工作以后，调用频率和操作量远远超过人工，一些原来运行正常的业务系统甚至很快被这种使用方式「打爆」。
与此同时，权限和安全问题也出现了：如果 Agent 没有继承背后真实员工的身份和权限，它短时间内完成远超过人工规模的数据操作背后，也意味着更大的安全风险。
因此，从今年二月开始，蒋林泉的团队开始为即将爆发的通用智能体做业务系统开放准备。
但如果只是多开放几个 MCP 并不能解决问题。两个业务系统如果对同一个对象有不同定义，人可以通过沟通理解，但 Agent 自动编排可能会制造混乱。而且，过去没有「线上化」的流程、散落在不同地方的数据、长期依靠员工自己判断的步骤，也都会在机器真正接手任务以后暴露出来。
为此，CIO 团队只能先把流程倒回来重做：回到真实业务，梳理工作流、统一业务概念；把原来藏在人脑中的经验显性化、线上化，再把这些能力做成 Agent 可以调用的 Skill。
完成这样一套底座的重构，从开放后的云业务系统调用数据可以发现：四个月的时间，通用智能体调用量迅速超过了 GUI 交互和原有一方 Agent，通用调用量增长了1000 倍。
与此同时，越来越多业务人员开始自己用自然语言做 Agent，再跑来问 CIO 团队：「这个系统能不能给我 MCP？」其实，这些需求过去一直存在，只是没有正式进入 IT 的需求池。
现在，系统被开放，沉压已久的需求被充分释放。于是，CIO 团队的职责也随之变化：一个维度，在系统开放后，简单需求逐渐由业务部门自行闭环，CIO 团队聚焦复杂专项；另一个现实维度，团队要集中补下面的底座：摸排各种数据是不是一致，身份和权限是不是清楚，Agent 的操作能不能审计；是否存在线下流程或个人经验并未线上化沉淀，对此来分别「补课」。他们把团队的第二角色描述为「开发者运营」，业务团队是新的「开发者」，甚至为每个业务团队配置一位开发者运营，帮助其解决开发中的困难。
在公司内部做深做实之后，一套经验，乃至成熟的产品体系，也就沉淀了下来：此前，阿里云内部已经定运行着 28 类数字员工，折算约等于两千多个 HC。后来，其中一部分已经跑成熟的方法和技术继续打磨，沉淀成一套可对外交付的睿系列产品，比如面向翻译场景的睿译宝，以及面向外呼场景的睿呼宝。
其中，今年云栖大会现场负责全程翻译的「睿译宝」，就来自阿里云自己的全球化业务打磨——是基于阿里云内部十几万量级的技术文档和大量 GTM 内容，迭代了两年产生的。它等同资深翻译，同声传译准确率达 95%，能把 GTM 内容从按周交付压缩到 10 分钟，总成本却只有人工成本的 1/5~1/10。
睿呼宝则来自阿里云内部的真实电销业务。目前采用与人类坐席使用相同业务指标考核的情况下，它在续费提醒、试用转付费和线索清洗场景下的表现已经追平甚至超越人工，但成本只有人工坐席的 1/5。在蒋林泉看来，合格上岗的数字员工，必须满足既要像真人，又要交付真结果。
04
当技能越来越便宜，
人会变得更加宝贵
岗位可以重做，系统可以开放，越来越多执行工作也可以交给数字员工。但最终所有的问题都还是会回到人。
蒋芳也把演讲最后一部分留给了人。两个月前阿里又有一组同事去硅谷学习。回来以后，有两件事让她印象深刻。
据这些同事回来后的分享，NVIDIA 至今仍然非常重视员工的价值观表现；Anthropic 对内部面试官也有严格训练，不只是训练他们怎样判断技术能力，还要学习怎样判断候选人的价值观与公司使命是否匹配。
因为在 AI 时代中，一个组织中个体今天非常稀缺的一项技能，可能在下一轮模型升级后迅速变成很多人都能掌握的能力。
而 AI 可以迅速降低技能门槛，却没有办法自动给一个团队带来信任。
比如，包晨星一开始其实并不看好「管理者数字分身」的产品，觉得最多只能模仿一个管理者说话的语气。
直到后来团队把管理者过去的材料和工作经验蒸馏进去，再通过 Harness 工程让数字分身进入真实场景，每天开始有几百名员工主动找它交流：客户碰到这个问题应该怎么办，项目卡住了应该怎么判断。
管理者一天还是只有二十四小时，但过去必须依赖本人才能传播的一部分经验，第一次可以被更多人同时调用。
再后来，包晨星自己也做过一次尝试。因为组织安排，一个季度他要给二十多名员工写 OKR 反馈。过去时间不够，很多反馈只能留下短短一两句话。这一次，他让千问办公读取员工过去的工作材料，帮助整理，再由自己检查后先发给同事确认。
有员工告诉他，这是自己进阿里以后收到过最好的一次反馈，因为过去的 OKR 反馈总是很模糊的一笔带过，但这一次里面有了数据，有了具体的人在做什么具体的事情，一线的工作真正被看到了。
所以，蒋芳把 AI Native 组织拆成了组织、人才和文化三个维度。
组织层面，不能只是给每个岗位塞一个工具，而要先设计端到端工作流，再重新思考人应该出现在哪里；人的能力会越来越泛化和全栈化，因此岗位边界会继续模糊；到了文化层面，则要拥抱不确定性，也要学会 move on ——不能等工具完全成熟以后才开始，也不能因为一套方法刚刚跑通，就假设它还能一直有效。
这也是为什么，不同行业最终不会得到同一张组织图。
比如，大组织没办法一次完成变革，就让一号位先下水，让小团队先跑，再根据真实结果决定哪些经验应该被泛化，最后，每个组织都会找到属于自己的 AI Native 变革方式。
「Life, finds a way.」
生命总会找到自己的出路。
这是在演讲的最后，蒋芳借用的《侏罗纪公园》里的一句话，也是所有组织 AI Native 转型的共同写照。
* 头图来源：视觉中国
本文为极客公园原创文章，转载请联系极客君微信 geekparkGO
极客一问
Agent 和人使用业务系统有什么本质差别，
带来了哪些新挑战？
