据麦肯锡发布的《The state of AI in 2025》全球调研报告揭示， 88% 的企业已在至少一个业务职能中常规使用 AI（如 IT、营销、知识管理），但 62% 仍处于实验或试点阶段，仅有少量实现企业级的规模化部署。我们可以理解为，当下企业的 AI 落地正呈现“高采用、低价值”的典型特征，多数企业卡在试点到规模化之间。
麦肯锡《The state of AI in 2025》报告
AI 应用进入深水区，竞争的核心已经转向规模化的落地能力，而非技术本身。这也指向一个重要问题：当下的 CIO 群体，想真正实践 AI 大模型在企业的有效落地，实现规模化价值，要化解过程中的诸多坑点与难点。
本文整理自阿里云智能集团副总裁、 CIO 蒋林泉在 AICon 2025 年 8 月所分享的 “阿里云大模型应用落地实践之路”，并完整呈现他对企业 AI 落地的经典方法论“RIDE”和数字人案例。文中，通过规模化上线的 28 个数字人的成功实践经验，分享从组织共识挑战、业务机会识别，到 AI 指标衡量，再到产品工程落地的体系化思考，以蒋林泉的第一视角，解析企业 AI 真实落地的系统路径。
第一视角观察
这是我自担任阿里云 CIO 三年以来，第一次对外发表演讲。此次分享浓缩我过去三年在阿里云带领团队推进数字化与智能化进程中沉淀的案例与经验。
在担任 CIO 之前，我主要负责阿里云飞天核心系统的产品和研发工作，当时对外的演讲内容更多围绕飞天和阿里云的产品，角色也更偏向于“乙方”的产研身份。而今天，以阿里云 CIO 的身份首次对外演讲，更多是站在“应用开发者”的角度，分享如何在企业内部场景中推进数字化和智能化落地的一些实践与体会。
阿里云智能集团副总裁、 CIO 蒋林泉
过去两三年，我带领团队致力于推动 AI 大模型在企业各类场景中的落地应用，在这个过程中有很多感触。想先谈一下，在这个阶段里的一些观察和思考。
在当今时代，我们常常会思考一个问题：一个人或者一个组织发展得这么好，到底是时代的原因，还是自己努力的原因？其实最主要还是时代的原因。我们能够发展到今天，很大程度上是因为坐在了一个很好的“电梯”。比如搭上了中国这个电梯，中国互联网的电梯，以及我所在的阿里巴巴这个平台的电梯。平台本身发展得很好，在上面自然也发展得很好。
换句话说，在电梯里做俯卧撑，还是在平地上做俯卧撑？两者达到的高度是不一样的。个人努力固然重要，但更重要的是平台。我认为，在这个时代，AI 就是那个最大的电梯。无论是组织还是个人，有没有搭上 AI 这趟电梯，将直接决定在未来能够达到的高度。
ARK INVEST 报告
根据 ARK INVEST 以往的一份调研报告预测，到 2030 年，算力性能相较于现在将增长 1000 倍。这是什么概念？在 AI 时代之前，我们常常讲摩尔定律，技术性能大约每 18 个月翻一番。而在 AI 时代，技术发展的速度被极大地加快了。如果不能及时搭上 AI 这趟高速电梯，大概率会落后于时代。
基于这样的认识，我们发现，无论是企业还是个人，都开始逐渐意识到 AI 的重要性。意识到这一点后，许多企业，包括 CEO 和业务部门，开始变得焦虑起来。
这就涉及到，这一轮科技革命与以往的科技革命最大的不同之处。
在整个信息技术产业中，无论是 PC 互联网还是移动互联网时代，技术在企业中的应用过程是一个渐进的过程，非常循序渐进。那个时候，企业的 CEO 看到业界的炒作、厂商的炒作，都比较冷静，可以慢慢来。
然而，这一次的情况却截然不同。我觉得这是第一次，企业 CEO 和业务部门比 IT 团队、比供应商还“上头”。因此，我们可以说，现在企业内部最大的矛盾，就是业务部门在社交媒体、PR 渠道里看到的 AI，往往呈现出一些“炸裂”、“梦幻”的效果，而 IT 部门或者说 CIO，在实际生产力上的发展却是不均衡、不充分的。这种矛盾体现得非常突出。
在阿里巴巴集团内部，以及我与业界几十位 CIO 交流的过程中，观察到，在企业内部，这种现象大量存在。企业中会涌现出很多 Idea，做出很多 Demo，上线很多技术平台，一个团队里，恨不得要搭好几套 Dify 平台，各种智能体平台都在搭建。但是，在这些过程中，还是技术主导比较突出，更多是拿着平台去做 Demo，业务方的参与往往比较浅层。这类现象在企业里是比较过剩的，可以说整个企业都充斥着类似的情况。
与此同时，我在企业中普遍观察到，很多方面的投入都严重不足：是否真正深入到业务本身去做价值识别，或去正确地定义产品，以及如何开展知识工程（注意，这里我们不再仅仅是传统的软件工程，而是知识工程），还有我们强调的业务专家知识动员。
因此，我们认为，如果要在企业里真正用好 AI，并且产生实际的业务结果，就要做非常大的投入。恰好，在这个领域，我们做了很多探索和实践。
阿里云企业大模型应用实践落地
接下来，想向大家展示阿里云内部企业 AI 大模型业务落地的全景图。
在这张图中，我们可以看到很多“数字人”，无论是在阿里云的官方网站、CRM（客户关系管理系统）、业务支撑系统，还是在内容管理系统、人事管理系统中，这些数字人都已经广泛地落地应用，并在原来的业务中发挥真实的效果。
在过程中，我们已经落地了大约 28 个数字人项目，从中挑几个有代表性的例子来分享，让大家更有体感。
AI 翻译数字人
大家都知道，翻译是大模型非常擅长的事情。
但在阿里云，我们遇到过很大的挑战。作为一家公共云服务提供商，为客户提供服务时，文档的作用至关重要（ ToB 的服务非常依赖文档）。阿里云拥有 300 多个产品，十几万篇文档，涉及上亿文字。其中有一个非常大的痛点在于“出海”，我们要出海到日本、美国、欧洲、印尼，还有土耳其，而我们的开发者要高度依赖文档，来操作云计算服务。
问题在于，我们缺乏既懂本地语言，又懂云计算的人才，技术类的翻译必须同时具备这两方面的能力。但即使有足够的资金，也很难招聘到这样的人才。过去，我们只能选择“忍”，仅翻译了英文文档，以及部分日文文档，而其他语言的翻译工作基本停滞不前，这也导致海外开发者的反馈不佳。
在这一轮 AI 技术突破之前，我们尝试过用传统 NLP 来做翻译，但效果根本不行。到了 ChatGPT 3.5 版本，我们发现自然语言处理技术，仍然无法满足我们的需求。而到了 ChatGPT 4 版本，我们再次尝试发现，翻译质量终于能和那些“既懂技术又懂本地语言”的专业译者打平。
而且，当时也做了计算（时间在一年多前），每篇文档的翻译成本，仅为当初专业技术翻译团队的 1/200。从那时起，我们开始大量使用大模型进行翻译工作，到现在，我们已经完成了印尼语的全部翻译工作。这意味着，解决了原本靠资金也无法解决的组织问题。
如果用专业的评分来看，过去，用懂本地语言、懂技术的专业翻译团队来翻译，评分大约为 4.12 分（满分 5 分）。现在，我们用 AI 来翻译，评分能够达到 4.68 分。在海外市场，我们发现海外网站的用户体验以及 NPS（净推荐值）都得到了显著提升。因此，这不仅仅是一个成本问题，更是通过 AI 解决了过去无法解决的难题。
技术文档验证数字人
刚才提到，阿里云有十几万篇文档，覆盖三百多个产品。其中，有一半是操作指南和解决方案，客户需要完全依照这些文档进行操作。
这里一个很大的问题是：传统 IT 产品可能是半年或一年一个版本，文档和产品可以同步开发。但我们是互联网模式的 IT 系统，我们的情况是，线上功能不停迭代，功能的迭代和我们文档的一致性，就要实时保证。
原来，也是依赖外包团队进行文档验证和测试，由于“带宽”限制，只能解决中文文档的验证问题。每六个月会把所有文档“跑”一遍，去验证它们和线上功能是否一致，经常会发现有很多版本不一致的问题。但这个过程本身就有很大问题：首先一轮验证就需要六个月时间，当第一个月验证并修复好的内容，到第六个月，验证可能又变得不一致了。原来，我们一直没能把这个问题解决，导致客户经常会遇到功能与文档不符而操作不下去的问题，这就要求我们提供最新内容。
现在我们是怎么做的呢？用 AI 来模拟这个过程：它会左边打开技术文档，右边操作浏览器里同步打开阿里云网站，然后严格按照文档里的步骤进行操作。过程中，AI 一旦卡住或无法继续，就大概率意味着文档和实际功能不匹配。虽然少数情况是云产品控制台本身的问题，但绝大部分的确是文档与功能不一致。当 AI 发现不一致时，它会立刻把不一致的“单拎”出来，并自动创建一个 Aone 需求单。
我们后续还有一个“文档修复数字人”，它会“接手”这个 Aone 需求单，分析实际情况与文档描述的差异，并做修复。然后，它会把这个修复好的文档，给到我们 technical writer 做确认，确认后就能上线了。
这之后，过去需要六个月才能完成一轮的验证工作，现在只要一个星期。同时，我们现在也把这套验证机制应用到日文、英文以及其他语种上，确保国际站的功能和文档也能保持一致。
过去靠人工验证时，一致率到底是多少？验证质量好不好？覆盖度够不够？这些其实都是一个“unknown”的状态。而现在，一切都变得清晰、可量化了。
网站 AI 助理数字人
第三个案例是网站 AI 助理。阿里云有几百万客户，那我们的自服务模式是怎样的呢？
我们来看一组数字：每天大约 97% 的客户访问阿里云，都是通过自助操作，只有 3% 的客户会选择“提工单”。而在这 3%的客户中，百分之七八十的任务也还是由自己解决的，只有极少数最终会变成需要人工介入的工单。所以，我们的客户绝大部分是自服务的。
但即便如此，由于我们的客户基数太大，这“漏”进来的一小部分工单，依然需要我们服务团队投入大量人力去处理。在这些工单里，有一半都属于“咨询工单”。什么是咨询工单呢？就是客户遇到问题直接提问，我们的小二在后台查文档、翻知识库（Knowledge Base），找到答案再回复给他。这类工单纯粹是信息问答，不涉及操作。
这类工单主要有几个问题：第一是一半的工单服务成本很高，第二是个时效问题。我们统计过，过去一个咨询工单的平均关闭时间，绝大部分要到 5 个小时左右。也就是说，一个客户平均想要解决这种咨询问题，需要花费大量时间才能解决。
网站 AI 助理上线后，大量的咨询问题已经由 AI 直接回答了，而平均响应时间是 10 秒左右。
目前，我们正在和服务团队合作，与服务团队共同承担全年工单降量，我们一起努力，希望通过 AI 在网站自服务的深入应用和渗透来实质拓展服务带宽，更重要的是，能够一起提升阿里云的客户服务体验。
智能电销辅助数字人
刚才讲的是服务，探讨了如何帮助客户解决咨询工单和自助诊断的问题，把服务体验提升了。现在来看另一个场景：销售。
阿里云要服务上百万的企业，无法对每一家企业都用直销的方式去覆盖。因此，我们有很大一块业务是面向中小企业（SMB），通过电话销售来帮助我们客户实现售前咨询，以及售前购买的问题。
电话销售小二的日常工作，主要分为话前、话中、话后三个环节。话前： 小二需要做计划，规划当天要打哪些电话、了解客户的商机、准备话术，并排好优先级。需要这样一个准备过程，才能保证一天的工作有序高效；话中： 就是与客户的实际沟通；话后： 需要复盘，记录通话小结，整理哪些需要 follow-up，哪些需要申请折扣。需要处理的问题都要记下来，这样才能闭环到后续的业务处理，形成一个完整闭环。
现在，我们在这三个环节都提供了 AI 数字人。
● 在“话前”，由 AI 来完成通话计划，包括怎么打，话术是什么。过去小二自己排计划要花半个多小时，现在一上班，计划就已经生成好了，可以直接开工。
● 在“话中”，我们提供了一个智能辅助提醒。当小二与客户通话时，系统会根据对话内容，在工作台右侧实时提醒他如何回答，比如客户在说他想要这个，建议你这么回答。目前已经在辅助小二去解答客户非常复杂的一些云计算咨询问题。目前话中提示小二的采纳率已经达到了 50%。
● 在“话后”，像通话复盘、撰写小记、follow up，包括后续的通话质检，这些工作都交给了一个自动化的 AI 数字人来完成。
通过这种方式，我们的小二可以从繁杂的事务性工作中解放出来，集中精力在真正的销售沟通上，大幅拓宽了我们销售的服务带宽。同时，AI 的智能计划、实时辅助和后续复盘，也极大地提升了我们服务客户的质量。
智能质检数字人
AI 应用到电话质检之前，这几乎是一个原理上无解的事情。
原来我们大规模的外呼电话作业过程，是非常难被知晓的。比如中间过程是否按照公司的作业规范进行？与客户的沟通是否足够礼貌？更有时候，有的外呼人员可能会把客户引导到私下公司去联系、去成交。但原来，我们是很难去做这个电话质检的，因为这是语音作业，很难管理。
而现在，我们用 AI 把所有的电话语音全部智能化，从而识别里面所有的这些问题，再通过统一的质检标准，就能够得到一个规模化的质检。于是，这个 AI 质检能够大规模地提升我们的服务质量与效率，覆盖全量业务场景，关键还能控制我们的业务风险（避免产生额外的风险）。
可以说，这件事我们原来几乎是无法搞定的，因为原来是靠抽样，也就是人工抽样去听那些电话录音，如果抽样抽到了问题，再去一个个处罚，但效率是非常非常低的。它的抽样完整性、抽样覆盖度都几乎是没法被使用的（覆盖度仅有 2%），不同质检员的判断差异也很大，对人力的消耗也很厉害。所以，现在通过 AI 质检数字人，能够让覆盖度提升到 100%，质检的准确率也远高从前，带来的最终效果是非常好的，这使得整个服务质量能够规模化地提升上去。
智能外呼数字人
刚才我们讲到 AI 如何辅助做事，这里则是一个能直接进行智能外呼的数字人。
众所了解，云计算本身是非常复杂的，如何招聘到足够多的外呼坐席人员，让他们既具备相关技能，又熟悉云计算知识，同时还能够耐心地每天坐在工位打一天的电话，这对我们来说是一个巨大的痛点。因为招聘和能力培养难度很大，人员流动率非常高，这使得无论是销售服务，还是电话服务的质量，都存在明显的短板。
本质来看，这是一个短线影响业务增长，长线影响服务满意度与企业品牌塑造的问题。
我们在前期已经有一定的知识积累，包括语音、多模态等方面的经验，因此，我们通过 AI 的方式直接引入智能外呼。它直接上场，与我们的客户沟通，挖掘销售商机，交付给服务团队去做主动的服务。
目前，在潜在客户的线索清洗、免费试用、转生产、以及产品即将到期的续费提醒等主动外呼场景中，这个数字人已经上线运行了。目前，我们还在开发场景包括产品到期的主动关怀、NPS 调研等，上线后，预计可以拓展出“能交付结果的”上百个 HC 的服务带宽。
数字 AI 客服的外呼，还有些不一样的特征。首先，它可以灵活、快速地按需扩容，而且，它的声音可以做得更甜美，也可以做得更有情商。更重要的是，在技术的不断加持下，这个 AI 小二解决问题的能力，可能已经超过了原来人类员工的平均水平，而且还在不停地提升。目前，我们的智能外呼数字人可以像“金牌销售”一样工作，非常接近真人体验。未来会有更多的想象空间，让它能够更好地服务阿里云客户，提升我们的服务质量。
直销辅助数字人
分享了很多电销案例，这里谈谈“直销”场景。
在阿里云的直销业务中，我们面临着一个核心挑战：销售如何变得更加专业和高效，促进公司业绩增长？在实际工作中，我们的销售团队遇到了两大业务痛点。
第一个痛点：云计算销售要求高、招聘难、培养成本高。
云计算销售不仅需要具备良好的客户拓展能力，还需要深入理解云计算技术与行业应用场景。复合型人才稀缺，招聘难度大、周期长，新人从入门到胜任，需要经历数月的培训与实战积累，培养成本居高不下。
第二个痛点：销售运营专业服务带宽不足。
销售运营、数据 BI、财务、法务等运营中台的服务带宽，无法充分支撑前线销售需求，难以及时响应每一位销售人员的专业支持诉求。
为了解决这些问题，我们将整个销售流程分为“拜访前”和“拜访后”两个关键环节，在每个环节都提供 AI 数字人的全方位支持。核心围绕销售作业的有效性展开，让直销过程实现“在线化”，全面提升销售过程的辅助效率。
拜访前：销售“一键”获取客户“谈参”，了解客户用云信息、技术类型、解决方案、竞对情况等全面画像。过去，销售自己从各渠道去查询要花 1 个多小时，现在，10 分钟就能查询到，而且信息质量更优、内容更全面，有效促进了与客户 key person 的高质量拜访。
拜访后：我们提供 AI 对拜访过程的全方位复盘，包括商机要点是什么，客户对阿里云品牌表现出的情感倾向是什么，建议后续怎么推进客户成单。
通过 AI 软硬结合的优势，我们让直销的销售过程实现“在线化”，高质量拜访小记达到 100%全面覆盖，新销售也能通过高质量在线信息资产快速学习，上手周期缩短 50%，大幅降低新人培养成本。
这种方式，相当于拓展数百位专业销售运营为销售团队“贴身辅助”，销售人员得以从繁琐的流程性工作中解放出来，能够更专业、更高效地服务客户，大幅提升了销售有效性，有力促进了公司业绩增长。
合同风险审核数字人
ToB 业务的一大特征，是有大量的政企和大客户，他们通常不会使用我们的标准合同。这些合同金额巨大，需要进行严格的风险审核，涵盖财税法、风控、信控等多个方面的风险。
过去，要完成这样的风险审核，我们需要专业的法务、财务等领域的精英人士，他们大多来自国际四大会计师事务所。然而，鉴于我们业务规模庞大，不可能招聘到足够多的精英来从事这项工作。因此，我们在合同风险审核方面遇到了巨大瓶颈，审核时间过长，最长甚至可达 5 个月，平均也需要两周到一个月。这极大地拖累了业务效率，包括服务大客户的效率。
为了解决这一问题，我们培养了一大批“数字人”，包括财务数字人、信控数字人和法务数字人。并且，把这些数字人送到合同撰写端，让他们在销售和客户沟通、合同拟定的瞬间，就能够实时识别潜在风险并提示谈判方案，而不是等到审核端后才发现问题，再回过头去处理。
在合同审核端，我们通过审核标准数字化、专家经验数字化，用统一的标准执行，极大提升了准确率。而 AI 也正是实现知识工作线下流程线上化的体现。
通过 AI 技术，我们不断拓展中后台的服务带宽，解决商业拓展流程中的效率瓶颈。后续，我们也期望它在风险拦截上的能力，能够持续提升。
员工服务数字人
为什么特别提到员工服务数字人？
因为大型企业里，HR 系统有一个显著特征，就是非常分散。比如请假、体检、福利、在职证明等，各式各样的流程和服务都散落在不同的系统里。与此同时，各类政策也同样分散，包括公司内部的福利政策、外部的人才政策等等。
员工在需要获取这些信息或使用这些系统时，会遇到两个难点：第一，这些服务是低频使用的；第二，它们分散在不同地方，获取难度非常大。由于是低频服务，无法配备一个庞大的服务团队来支持，所以 HR 团队的负担很重，而员工的服务体验也不足。
为了解决这一问题，我们将这些低频、分散的服务全部整合到一个智能体中，通过钉钉平台打造了一个“云小宝”（数字人），为员工提供统一的智能服务。
我们发现，通过引入智能体，折算下来相当于节省或新增了几十名员工在为大家服务。更重要的是，员工的体验得到了极大提升，比如，我们服务员工的响应时长已经从平均 7.2 分钟缩减到 5 秒。再比如，员工只需要用自然语言输入，如“下周一请假”、“国庆前后两天请假”或“为父亲预约体检”，系统就能迅速响应并完成操作。
面试智能辅助数字人
还有一个场景，我们聊聊招聘。
首先，我们对外招聘，核心是描述我们需要什么样的人。从这个角度出发，前置是 OKR，我们通过 AI 分析每个部门日常在做什么，目标是什么，根据日常目标和事情，去看清楚招聘的 JD（职位描述）是不是合理。
再者，从 JD 开始，根据岗位要求，再结合当前的候选人简历信息，在面试的时候就会生成面试计划。面试时，结合岗位要求，面试官应该问哪些问题？根据最佳实践，怎么去考察候选人？这些专业问题在面试前，已经帮面试官提供好。面试中，通过对话过程，发现应该追问哪些问题，以及面试后，怎么总结面试过程中候选人是不是 qualified 这个岗位。
通过 AI，我们可以更结构化、体系化地来做这件事，使得面试过程管理，面试质量，以及对面试人评价的客观性，都得到很大的提升。这也彻底改变了原来仅仅通过电话形式的面试，因为它的过程是一个黑盒逻辑，而“黑盒”最大的问题是无法提升过程的质量，包括保持长期的、闭环的有效性。
对一家公司来说，招聘是件非常严肃的事情，我们经常讲，如果招错一个人，会导致后面的事情是非常糟糕的。所以本质上来讲，面试智能辅助数字人，提升了我们整个组织在招聘进人方面的有效性。这不只是效率问题，而是能够规模化促使我们在面试过程中的专业性、面试评价的专业性得到质的提升。
28 个数字人全面上岗，真正产生业务价值
目前，我们有二十几个场景实现了数字人的智能化服务，这里只是挑选了 10 个来举例。
这些数字人应用背后的评估衡量，有一个共同逻辑：
一是折算拓展了多少人力；
二是业务效率提升了多少；
三是业务效果提升了多少。
我们非常注重这一结构，因为每一个数字人上线落地，都必须衡量其对原来业务是否真正拓展了服务带宽 ，并且，是否比原来人工操作的效率和效果更好，这是非常关键的，与外界所谓的众多智能体最大的区别，就在于此。
这些智能体最终都是在对应的岗位上实际工作的。在我们的 HR 系统中，这些数字人被分配到对应的业务部门，向对应的业务团队汇报工作，与我们从外部招聘的员工没有任何区别。所以，它们必须在对应的岗位和业务团队中，发挥超过一定人数的实际任务执行作用，才能真正融入团队。
在我们的钉钉系统以及内部工作系统中，这些数字人与普通员工一样，拥有工号和头像。唯一的区别在于，它们的工号以“AI”开头，如 AI001、AI002，目前我们已经有大概 28 个智能体上线，后续还有更多智能体在排队等待上线。
当然，在过去两年，带领团队推进业务落地的过程中，我也深刻体会到，真正将技术应用于业务并取得成效，没有那么简单。特别是，真正在业务中产生价值和仅仅做出一个 Demo 之间，是天壤之别。
接下来，想和大家进一步分享，我们在这一过程中遇到的困难，以及总结出的一些解决方法，希望能对大家有所帮助。
大模型 E2E 落地坑点与解法 —— RIDE
大家可能听过红杉提出的一个概念叫 RaaS，即“结果即服务”。这一概念的核心在于，如果仅仅提供工具和产品，让企业自行落地是不够的。所以，我们特别重视真正上线，并产生业务结果的项目。
我作为 CIO 所带的团队，在企业内部为业务部门提供的，就是这种 “以交付结果为导向的服务”。在推进 RaaS 的过程中，也总结出一套方法论，叫 RIDE。
RIDE 包括四个关键步骤：Reorganize（重组组织与生产关系）、Identify（识别业务痛点与 AI 机会）、Define（定义指标与运营体系）、和 Execute（推进数据建设与工程落地）。
首先是 Reorganize。在 AI 时代，新的生产力下，原来的生产关系是非常不适应新生产力的发展，这种不适应会在每个毛孔里面表现出来，然后阻碍 AI 的发展和落地，所以要求我们要重新调整生产关系。第二，是 Identify。也就是我们需要精准地识别出企业中哪些问题适合用 AI 来解决，这要求我们首先明确问题的定义，然后结合 AI 的能力和业务需求，确定哪些问题可以通过 AI 得到有效的解决。然后是 Define。在明确了问题和 AI 的能力之后，我们需要精准地定义产品及其运营指标，进行准确的指标跟踪。最后才是 Execute。执行阶段是一个金字塔结构，上面是业务目标，下面是工程数据和评测，中间是工程应用算法。
当然，这套我们称之为 RIDE 的方法论，并非在做 AI 转型的第一天就有了，而是在二十多个智能体真正有效落地业务的过程中，我们发现，如果不遵循方法论中的这些步骤，项目很可能会失败。遵循这些步骤，虽然不能保证 100% 的成功，但至少可以提高成功的概率。这是一套用两年时间、用血泪经验总结出来的方法。
Reorganize ｜重组组织与生产关系
书同文、车同轨 ：AI 时代的通识教育
我们首先从 Reorganize 开始讲。
在落地第一年，我发现了一个问题：无论是业务团队还是我们自己的团队，对大模型的能力边界、发展程度、具体原理等基本概念的理解都存在差异，甚至在我自己的团队，产品经理、算法、工程团队内部都无法拉齐概念认知。
为了解决这一问题，我们发起了一个行动，叫 “书同文、车同轨”。 我们要求全员参加 AI 大模型的认证培训。最主要的原因，是要解决大家在基本功和认知逻辑上的差异。我称之为 “AI 时代的通识教育”，相当于要在团队里重新走一遍“高中的教育”。
这一培训分为两类：大模型 ACA 认证（面向非技术人员）、 大模型 ACP 认证（面向技术人员），因为我们不仅需要技术人员之间能够对齐话语，也希望非技术人员和技术人员对齐话语。
这种通识教育对于团队的协作至关重要，首先在我们 CIO 线内部已经完成了全员的认证，后面，我们的业务方，也就是我们的财务、人力、销售、中后台等都在做 全员认证。
目前，整个阿里巴巴集团都在用这个方法来做 AI 转型的基础教育，重新建立大家的基础认知。不然就会出现这种情况：大家都在谈论同一个概念，但其实理解的内容和现实完全不同。如果没有做过深入工作，很难体会到那种无力感，一旦通过通识教育统一认知，沟通效率就会显著提升。
阿里云大模型 ACA 认证：
https://edu.aliyun.com/certification/aca13?spm=a2cwt.28380597.J_1564692210.17.28813487dUqGKW
阿里云大模型 ACP 认证：https://edu.aliyun.com/certification/acp26?spm=a2cwt.28380597.J_1564692210.18.28813487dUqGKW
「企业免费体验」大模型认证：https://edu.aliyun.com/learning/topic/llm-free-trial
这样的基础上，又设计了两个比赛。一个是产研提效比赛，一个是业务提效比赛。和其他大赛最大的不一样，我们的比赛是真正以 E2E 为衡量标准的。
比如产研比赛，我们要看的，是原来 E2E 同样粒度的一个需求，需要多少“人月”完成，而现在能减少到多少人月。而不是看代码采用率，因为代码采用率很容易“灌水”，而且它往往只能补全那些最容易写的代码，最难的代码可不容易补全。
在业务 E2E 方面，我们的比赛就是要真正进入业务场景，帮助业务去拓展，而且效果和效率都要超过原来。所以，这两件事非常重要，第一，是做“书同文，车同轨”的通识教育，因为 AI 时代的知识在不断发生巨变，每个月都在变，现实的实践知识和原来的基础知识都有大量的不同；第二，是“以赛促练”，整个组织通过正确目标下的比赛，大家会发现短板，发现相互之间可以学习的地方，就能够激发组织不断地去创新、去提效。
数字员工 ：业务方与 IT 方 联合培养
再说说我们的数字员工。
有一个非常关键的安排：我们的这些数字人最后都是汇报给业务部门的。这不仅关乎形式，更重要的是心理。我们不能让业务部门觉得，AI 技术会威胁到他们的工作，而是要让他们明白，AI 技术是来帮助提效的。如果这个关系没处理好，就会遇到无数的暗礁。
所以，我们把自己定位为数字人供应商，业务部门是 AI 先进组织，业务部门可以雇佣我们的数字员工，并与我们一起联合培养。 这样，业务部门会更愿意接受 AI 技术，减少阻力。所以这是第一点，我们把自己退到一个外包供应商的位置上。
第二点，我们还发现，AI 数字员工是不能扛责任的，也不能给它打“3.25”（低绩效）。这意味着，数字员工在系统里执行任务出了问题，谁来承担的问题。我们将 AI 数字员工汇报到业务部门，属于业务部门的人（让他们放心），并一起参与 AI 员工的培养过程，同时数字员工也会受到正式员工的监督，来承担相应业务领域的责任。
定标准 ：AI 要与人比，不与“神”比
另外，我们经常听到一句话：ToC 还好，但 ToB 的大模型有幻觉，做不到 100% 正确。但实践经验告诉我们，其实人也有幻觉，而且人的幻觉还很大。如果认真看，在很多任务里，人其实也是不靠谱的，也经常会失败，只是企业没发现而已。
我们强调的一点是：如果 AI 项目和业务部门真正达成了共识，并且通过培养逐步磨合，就必须认真回头来看，AI 的要求标准到底是什么？
如果要求 100% 正确，其实就是把 AI 拿来和“神”比。但如果是和原来人做事的效果和准确率去对比，那就是和“人”比。所以，追求比人做得更好、更准，才是真正有意义的对标。
那怎么避免和“神”比呢？回到前面所说，解决生产关系的问题，处理好内部业务的逻辑、目标和关系，这样才能真正实现 AI 和人比，而不是和“神”比。
在整个 Reorganize 的过程中，我们还发现，要把数字人汇报到业务部门，对 HR 部门来说，这就等同一个“正式员工”。注意，我们是真的把它当作正式员工来看待的，用它能否产出真正的业务结果来度量。
所以我们在内部与 CPO（HR 负责人）沟通时，讨论过：怎么去度量 AI 数字人是否真的发挥了一个正式员工的效果？最后，我们确定了一个方向：AI 数字人必须有一个目标，就是在原有具体的业务流程里，接管一个重复且有价值的任务，并且能够折算出“相当于拓展出多少人力”，这就是唯一的目标。
但要 真正让数字员工上线、上岗，必须满足两个标准条件： 一是数字人执行原来任务的效率，一定要比原来提升一定百分比，一定要比原来执行任务的人效率高；二是数字人执行任务的效果，同样，也要比原来提升一定百分比。只有当数字人做到效率高、效果好时，才能“正式上岗”，进入业务部门工作。
Identify ｜识别业务痛点与 AI 机会
从三个特征，挖掘 AI 机会
刚才讲的是 Reorganize，如果不解决 Reorganize 的组织问题就会不断遇到暗礁，甚至没法往前走。但解决了组织的问题后，业务部门会说，好，我们来联合培养数字员工。那从哪里开始呢？
所以第一件事就是业务机会的识别（Identify）。
这轮 AI 革命的核心其实是 LLM（large language model），所以，我们在内部有一个逻辑：所有以 language 为中心的工作，都将被大模型深刻影响。比如电销、客服、招聘、OKR、文档、翻译、合同审核，还有研发类的 C language、Java language、SQL language 等，这轮以 language 为中心的工作受影响最大。所以第一个特征是 Language 类 工作。
第二个特征是被重复执行、规模化执行。因为 AI 是自动化的，越大规模、越重复的任务，AI 越有机会去做。第三个特征是，如果本身缺人，甚至有人投诉效率低，那这个地方就是个大的机会。
这三个特征，是我们与业务部门一起来 Identify，识别哪些业务是可以着手的。这也是我们在内部形成共识后，如何去识别机会、定义机会的关键点。因为只有把问题定义清楚了，后面做事才会顺畅。如果解决错了问题，那投入就白白浪费了。
数字员工，以“单任务”为核心换算
另外，我们刚才讲到，数字员工要在对应的任务里拓展目标，也就是拓展对应岗位的人力，实际面对各种场景具体怎么处理，又怎么核算？
我们的经验是，首先，有些“单任务岗位”，比如技术翻译，我们是按字收费的，那么，AI 翻译一个字多少钱，就可以直接线性替换了。一个人一天的产能可能是翻译 2 万字，那我们就差不多折算成 “2 万字的产能”等同于“一个人”。
如果是“多任务岗位”，比如产品经理，他一会儿做 PRD，一会儿分析工单，一会儿画 Demo，一会儿又去客户那里访谈。这种多任务岗位，我们发现往往有些任务是重复的、繁琐的，也不是高价值的。为了提效，非常适合将这些低价值任务，拆分成一个个“单任务岗位”，如工单分析岗位、产品原型设计岗位等，让数字员工去做。
这样，原岗位上的人就从繁琐工作中卸载出来，可以聚焦在更高价值的主线工作上，他们的幸福感也会爆棚。在换算方面，最终也都是”以单任务岗位为核心进行 HC 换算”，逻辑清晰明了。
这种方式原先主要是由外包承接，但受制于外包员工管理难度大、成本构成多、招聘周期长、稳定性低、用工风险高、能力上限低（薪资因素）等诸多原因，多方面都受到约束，无法大面积展开。当我们有了数字员工之后，自然解锁了这些约束， 这件事就变得更加切实可行。
Define ｜AI 的产品度量与运营度量
准确率是 AI 产品核心
过了 Identify 这一步，下面就是 Define。
这个时代和以前做产品有很大不同。我们前面提到的一些产品大多都类似，比如都有交互、体验。在这个流程里，其实和上一轮移动互联网的产品没有区别。但 AI 产品有一个特别关键的点，就是“准确率”。 当然，除了准确率之外，还有响应时效性和安全合规等非功能性指标，比如在电销过程中，和客户实时对话，延迟必须非常低，不然客户会觉得交流效率不高，像机器人说话一样。
因此，实时性和准确性非常关键。如果准确性不够好，客户根本无法使用，也根本不可能真正上岗。所以，准确率是 AI 项目的第一核心指标，整个项目组都必须盯住它，这也是产品定义中最核心的部分，必须重新去 Redefine。
运营与产品指标「协同度量」，才不掉坑
此外，运营指标同样至关重要。如果只有产品指标和准确率指标，那大概率会掉到“坑里”。即使是在对内的业务项目里，原来移动互联网那些基本功也不能丢，比如：
DAU（每日活跃用户数）；
用户提问数；
渗透率，即目标客户的覆盖率；
留存率（最关键）。
如果同一个客户今天用了，下周还愿意继续用，说明这个 AI 智能体真正帮他解决了问题。如果客户只用了一次就不再回来，那么无论前面的产品指标再漂亮，都没有意义，那可能就是定义错了问题。运营指标就是用来兜底的，如果不紧盯这些指标，很容易让产品、工程和算法团队陷入“自嗨”。什么叫自嗨？就是他们说“我的指标很好”，结果客户根本不用。
举个例子，在阿里云官网的 AI 助理中，我们就设定了这样的度量方式。
如下图所示，左图展示了准确度的度量指标，时间线大约覆盖从去年到今年的一年时间。蓝色区域代表表现良好的部分（精准解决了客户的咨询问题和任务），黄色区域为中等水平（虽解决了任务，但伴有大量无关信息），红色区域则是表现差劲的部分（回答与客户问题完全不相关）。中间图展示了 DAU 和客户问题数，右图则是留存率。
目前，我们的留存率实际上已经达到了一个相当高的水平（PPT 中并未刷新数字）。从图中可以清晰看到，随着准确度的持续提升，DAU 和留存率也在稳步上升。但是反之，如果 DAU 和留存率始终停滞不前甚至下滑，即使你的工程和算法团队声称准确率很高，那无疑是自欺欺人的。
实际上，很多工程算法团队成员，可能并未意识到上述这一点。之所以能明确指出，是因为在左图的准确度指标上，我也曾经被多次误导，但这也并非团队有意为之。在如今的信息环境中，随便搜索公众号就能发现大量类似“用这一招，你的准确率能提升到 95%”的文章，但这些文章往往存在误导性，它背后都有一个前提条件，即在某个狭窄的小场景下，准确率能够达到 95%，然而在面对海量问题时，这一指标却难以提升（这一点稍后会详细分享）。
Execute ｜推进数据建设与工程落地
掌握「产品研发工程金字塔」
定义好了产品和运营指标（Define），往下走才是执行（Exectute）阶段。
Exectute 阶段的关键在于：一定要用产品和业务目标来拉动。因为在牵引拉动的过程中，才能充分动员领域知识专家的参与和评测。
如果没有知识专家的深度参与和强大的评测能力，大模型的应用上限是很难提升的，这是第一点。第二，如果项目目标缺乏价值，或者没有真正的痛点，那么会发现得不到资源的“祝福”。也就是说，一方面难以获得其他团队的配合，另一方面自身团队的价值感也难以维持，这将直接影响项目的推进。
在整个执行逻辑中，金字塔最下面是工程的数据与评测，我把这个放成最大的一块底座，因为这是基石——业务数据、业务 API 以及评测能力是大模型应用的基础，对这一部分的投入必须充足。
在这一基础上，才是工程应用算法、预训练（Pre-training）、RAG 以及微调等等，这些在媒体报道里面出现的技术热词，并非不重要，但这些只是 “必要条件”。我观察到，大多数产研团队在这部分（工程 - 应用与算法）投入了 80% 至 90% 的时间。
但想强调的是：这些只是必要条件，仅靠这些无法解决企业 E2E 落地的问题。哪怕你在必要条件上投入再多，再加 10 倍的努力，也无法实现真正的 E2E 落地。因此，必须设法补齐真正实现 E2E 落地所需的充分条件。 如果无法做到这一点，项目成功的希望将十分渺茫。
常见的 LLM AI 应用范式：翻译、Agent
在与业务团队沟通以及处理各种复杂问题的过程中，我们总结出了几种常见的模式： 首先是基础设施层面，涉及知识和数据的构建；中间是编排和调度，无论是大家熟悉的工作流编排，还是智能体自主规划编排，或是两者的结合；最上面是对客的产品与运营。
这里，重点讲述图中深蓝色部分的两种模式：第一个是翻译模式，第二个是 Agent 模式，我认为主要分为这两种典型的应用模式。其中，翻译模式最容易取得成效，因为它相对简单；而智能体模式则较为复杂。
翻译模式：关键在“蛋糕坯”
先谈谈翻译模式。 在公司内部，我们将所有翻译类模式统称为 AI 领域的“低垂果实”，这类模式相对容易实现。
这一轮的大型语言模型背后的算法是 Transformer。Transformer 最早是 Google 为了翻译任务而开发，在不停做翻译的过程中衍生出了 Transformer 算法。随后，预训练模型如 BERT 也大量应用于翻译领域。所以，大模型的原理 Transformer 特别擅长做翻译。
翻译又可以分为狭义翻译和广义翻译。
狭义翻译指的是中译英、英译中等语言之间的转换。而广义翻译则涵盖更广泛的形式，比如：自然语音转成文本，再转成语音；自然语言转成 SQL 语言；自然语言转成 Java 语言；甚至让一篇论文用自然语言“翻译”成中学生能听懂的表述，这些都属于广义翻译范畴。无论是狭义翻译还是广义翻译，Transformer 都特别擅长，因此这是最容易出结果的地方。
但这里有一个坑： 虽然（图中）左边的翻译能力已经具备，但如果右边原有的系统还没准备好（not ready），就会出现问题。
以 Chat BI 来说，为什么 Chat BI 在企业里没什么成功的案例呢？其实很大一部分原因在于，Chat BI 的逻辑无外乎就是：用自然语言翻译成 SQL，然后在后台的数据库或大数据系统里执行，再把执行结果取出来，再翻译成自然语言返回给人。
Chat BI 的实质，就是自然语言 → SQL → 执行结果 → 自然语言，这本质上还是一种翻译。
但我们会发现一个很有意思的问题：很多企业说要上 Chat BI，但如果原本数据库和里面的业务逻辑、数据口径积累不足，甚至连人都写不出对应的 SQL 来，那自然语言也一样翻译不出来。因为后台本身没有可执行的基础。
所以我认为，企业里绝大部分在 Chat BI 上踩的坑，都来自于一开始就想做一个过于“宽”的东西。但是做了这个翻译之后，如果原来的系统 API 没准备好，数据没准备好，甚至连原来的人都无法执行这些操作，那自然语言翻译也没法落地。这就是最大的误区。
因此我们在内部的逻辑是：要先 Identify 原系统具备哪些能力。比如，如果你原来的 ODPS、数据库和数据中台本身已经有 BI 和运营，能够在某个领域里不断取数、用 SQL 分析数据，而且业务场景也很丰富，那么，那些高频的 SQL 语句才是真正值得作为翻译目标的部分，而不是盲目地去做一个 Chat BI。
所以很关键的是要分成两个部分 ：一部分是翻译，一部分是原来系统的语言处理能力。我习惯这么来形容：原来的系统就是“蛋糕坯”，大模型翻译就是上面的“樱桃”。如果你现有的蛋糕坯是 ready 的，我放一个樱桃上去，你就可以吃樱桃蛋糕了。但是如果原来的蛋糕坯都没有，你让我做一个樱桃蛋糕，是做不出来的。
这里非常重要的一点是：要能够识别出原来的蛋糕坯是不是 ready ，然后在上面放上你的樱桃，而不是直接拿一个樱桃就装作是樱桃蛋糕。这个地方往往就是个误区。
翻译模式是“低垂的果实”，容易做，但里面其实有非常多的坑。
Agent 模式：关键在意图与知识空间
再说 Agent 应用模式。
大家可以注意这样一句话：所有的 Agent 应用模式都是始于用户意图，终于意图满足。
如果你不是从用户意图出发，最后又不是以是否满足客户意图来作为度量标准，去看待你的智能体，那一定会失败，没有任何成功的可能性。
这是我发现团队，甚至整个业界，最容易出现的问题。因此我们引出了一个方法，这是我在内部做智能体时，一定要去践行的方法。
第一件事情，要找到这个领域的“意图空间”。 当一个客户在智能体里和你交互时，他一定是带着意图的。那么这些意图都有哪些？比如客服场景里，客户会提出各种咨询问题，这些问题本质上就是一个空间、集合。所以，第一步就是要搞清楚这个集合的 边界和完整性。如果你不知道它的完整性，就无法去度量。只有在建立了完整的意图空间之后，才能继续往下做。
于是，第一件事要建立意图空间。然后，当清楚地知道了意图空间，就要基于这个意图空间来准备 知识工程。也就是说，你的知识、文档是否完备？API 和结构化数据是否具备？能否真正满足客户的这些意图？我认为这是最基础的必要条件。
再者，有了知识、意图空间，接下来才能带着意图去做评测。 因为既知道用户的意图，也掌握了知识，这样才能真正开展工作。如果意图不清楚、知识不具备，其实就是“空转”。
我们的经验是：在客服场景里构建意图空间，从原来就在满足意图的领域出发，从 工单 里去分析和构建意图空间。有了意图空间之后，就可以对意图进行分类。分类完成后，再根据不同类别去检查和补全知识，做好知识工程。
这样，当 意图空间 和 知识空间 都建立好了，才有可能开展评测，也才知道如何去度量你的 Agent。只有具备了度量能力，才有可能进一步做工程和算法迭代，这个是原理决定的。这也是我们在内部做智能体的一个必修课。
这里，简单总结一下两个模式： 翻译模式是樱桃，一定要先找到原来的蛋糕坯在哪里，再把樱桃放上去。如果蛋糕坯不 ready，只放个樱桃一定会失败。而 Agent 模式的关键则是：始于用户意图，终于意图满足。 这是一系列完整的逻辑方法。
Agent 落地要点：意图空间、品味 &评测
接下来，我们就展开讲这个稍微复杂一些的 Agent 模式，看看在业务体系里实现 E2E 落地的一些关键要点。
第一，对意图空间的投入进行 ROI 评估。做一个 Agent，它的 ROI 高不高？这取决于意图空间的大小。如果工程所需的知识量庞大，意图也非常多、非常宽，那么所需要的投资就会非常大。意图空间越大，为满足这些意图所需要的知识、工程和迭代的投入也就越大。
所以有一个非常清晰的结论：第一件事情，就是要控制意图空间的规模。如果不控制规模，会导致失败，因为后续的投入很难支撑。这里要记住一句话：如何去控制一个智能体的意图空间？如果没有控制好，或者不清晰，那么 ROI 根本算不出来。而一个算不出 ROI 的项目，成功的可能性将大打折扣。
第二， 我们经常讲，最近大家肯定也听说过，在 AI 领域里经常提到一个词叫“品味”。AI 时代里，品味非常重要。 那么品味来源于哪里？我自己猜测，要追溯到 1995 年乔布斯（Jobs）的一次采访。当时记者说：听说你比较粗暴、独裁，你怎么知道你的决定就是对的？乔布斯想了大约 10 秒，回答道：“归根结底，最后是品味决定的。”
品味和这一轮 AI 的关键问题——评测——高度相关。
这一轮和上一轮 AI 革命最大的区别在哪里？
上一轮深度学习主要是计算机视觉。那时候的数据评测怎么做？一张图给猫、狗、交通灯、汽车、人等等打圈，数据打标就是这么来的。所以评测时，只需要看分类对不对（猫有没有被错分成狗？对了就好）。ImageNet 就是这样做的，李飞飞当年找了很多外包团队来做标注，这种标注工作很适合外包，找普通人就能做。原因很简单，猫狗识别不难，就算是一些专家领域，比如故障识别、次品检测，标注也相对容易。
但这一轮情况完全不同。
大模型的输入是小作文，输出也是小作文。在专业领域尤其如此，很难直接度量。这就是为什么要强调品味——因为没有标准答案。我们都是经历过高考的。高考作文有没有标准答案？没有。开放题，比如写一篇中心思想总结，有没有标准答案？也没有。
大模型的评测正是如此。所以，这一轮大模型最关键的区别在于：度量数据、评测没有标准答案。既然这是没有标准答案的，意味着成本最高，也就成为落地的瓶颈。 如何解决这个瓶颈？只能重投入。
Agent 落地要点：如何做好「评测」
当然，这里讲的“品味”，就是如何做评测的问题。
我们怎么去评测？评测是一件非常重的事情，这包括业务效果的评测能力，也包括评测本身的工程化。
具体来说，在人工评测中，我们如何去解决分类的标准问题？什么是“好”，什么是“中”，什么是“差”？如何能够确保，评测对真实业务意图的覆盖度是足够的？如果覆盖度足够好，标准也足够清晰，我们又如何通过工程化的方式，对系统的迭代和变动进行自动化评测？
由于人工评测和度量，很多时候就像写一篇小作文，它是非标的，是没有标准答案的东西。相反，为什么现在编程发展很快？因为数学和编程都有标准答案，可以被编辑器校验，但是纯文本是没有标准答案的。
所以，评测这项工作非常耗时，也很容易成为整个项目的瓶颈，是需要极大加强的。如果不去加强，那么整个项目的基石就可能动摇。
在评测的过程中有一个非常重要的点，叫 E2E 归因。因为在智能体的过程中会有非常多的环节，在这么多工作流和智能体的编排逻辑中，如果一个意图没有被满足，我们必须要有能力确定这个 Bad case 的问题到底出在哪个环节。当每一个 Badcase 都应该归因到工程里的具体环节，才能对具体的原因进行聚类和改进。
如果从产品宏观功能体系来看，体系的最底层，必须要有两样东西：第一，是业务评测；第二，是全链路的归因分析能力。我把这两项放在最底层，就是因为它们太重要了。
下图这是个大概率的经验总结，也就是说，如果具备度量能力，会发现 大部分问题都出现在数据层面，出现在非结构化、结构化数据 API。如果基本能力不具备，这就是智能体失败的主要原因。部分问题可能出现在知识预处理、意图识别、上下文检索，以及后续的意图识别总结等环节。数据极为重要，但没有评测也就谈不上数据。
引出一个经常被讨论的问题：是否需要引入模型训练？
我们的观点非常明确：必须在白盒方式下使用基模 API，注重评测和数据，并进行 E2E 归因迭代。只有当数据质量和评测能力具备时，才能引入训练。
原因很简单，如果数据和评测能力不 Ready，投入在训练上的每一分钱都是浪费。如果数据不够好，那就是“garbage in, garbage out”。这些问题，都不是训练本身能够帮助解决的。
而且，训练的周期长、成本高、迭代速度慢，如果没有能力评估训练结果的好坏，也没有足够的数据进行训练，这种投入是不明智的。因此，只有在必须使用训练，且基模无法解决问题时，我们才会引入预训练。
写在最后：AI+云的「大电梯」
最后，为大家回顾一下。
我们在阿里云内部推进 AI 转型，本质上是需要为业务提供 Result as a Service（RaaS）。我们也是当前时点为数不多的，能够真正大规模实现 E2E 落地，给业务交付结果的实践团队。
而我们实现 Result as a Service 的方法叫 RIDE，RIDE 分别代表 Reorganize、Identify、Define 和 Execute。
需要特别注意的是，在必要条件上再努力，也解决不了充分条件的问题，所以这个 RIDE 方法论的核心是在提醒大家：只有把落地所需要的充分条件补齐，才能真正开展 AI 企业有效落地的工作。
呼应最开始讲的“电梯”，想表达的是，冰山之上，我带着团队一直在做业务的数字化转型，之所以能够实现，是因为冰山之下，有强大的阿里云作为底座。
无论是涵盖通义千问在内各种模型服务的 MaaS 百炼，还是 PAI，ODPS，数据库等 PAAS 服务、或是底层 IaaS 比如 ECS、灵骏、存储、网络服务，都是我们依赖的企业应用的有力支撑武器。而且，这些能力的成本在不断下降，功能也在持续拓展。
所以，当企业选择了一个强大的技术底座，随着技术水平的增长和成本的下降，企业的数字化转型也就能够搭上一部更好的“电梯”。我自己认为，阿里云就是这样一部“大电梯”，企业上云后，这部电梯持续为企业实现数字化转型，提供源源不断的上升动力。
