xiaohack's Blog - 阿里云
type: channel
link: https://blog.xiaohack.org/tag/%E9%98%BF%E9%87%8C%E4%BA%91/
items: 瑞幸咖啡 x 阿里云合作共创：AI 推荐让瑞幸咖啡“更懂你
items: 为什么程序员不自己开发一个小程序赚钱
items: 逆天腾讯云用 passkey 登录还要扫码
items: 【体现撒娇稚嫩的萝莉女声，音调偏高且起伏明显，营造出黏人、做作又刻意卖萌的听觉效果】Qwen3-TTS
items: 阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具
items: 阿里云全新发布的 UModel 是什么
items: 阿里的永久免费真的可信吗
items: 云原生为基，AI为翼：回望阿里云云原生的2025年
items: 阿里云 CIO 全面深度解析：企业 AI 大模型落地实践「 RIDE 方法论」

瑞幸咖啡 x 阿里云合作共创：AI 推荐让瑞幸咖啡“更懂你
type: item
date: 2026-02-10T15:32:36+08:00
description: 在新零售不断演进的今天，用户走进瑞幸，要的不只是咖啡，更是一种“被真正理解”的体验——口味、习惯、场景，甚至那一刻的心情。作为国内领先的连锁咖啡品牌，瑞幸咖啡正从数字化迈入智能化新阶段，以人工智能技术驱动“人、货、场”核心业务平台的智能化重构，构建面向未来的智慧商业决策体系。为此，瑞幸与阿里云深度共创，基于阿里云人工智能平台PAI，共同打造了一套真正“以用户为中心”的端到端智能推荐系统。它不再依赖静态规则，而是通过理解用户的偏好和需求，为用户提供贴心的咖啡选择建议——无论是清晨提神的美式，还是周末慵懒的生椰拿铁，当你唤醒AI Lucky，“为你而选”的新品、优惠与搭配，就会送到你眼前，让每一次选择都更轻松、更安心。过去依赖人工规则的推荐方式，难以动态响应用户变化；如今，借助双方联合打磨的数据链路、算法模型与运营机制，瑞幸不仅实现了推荐精准度的跃升，也让用户获得更流畅、更贴心的服务体验。这次合作，是瑞幸AI能力体系进化的重要一步，更是与阿里云“一起设计、一起验证、一起交付、一起沉淀”的技术共创典范——不是单方面交付产品，而是共同构建面向未来的智能零售能力。从规则驱动到 AI 驱动：赋能增长新范式截至2025年第三季度，瑞幸咖啡已建立起覆盖全国超2.9万家门店的庞大网络。随着用户规模持续扩大，瑞幸咖啡也在不断探索新技术增加对于客户的理解，为客户提供更加灵活的服务，促进增长的发展。为探索AI赋能增长新范式，瑞幸致力于构建一套具备高精度、可迭代、可扩展能力的AI推荐系统。经过多轮技术评估与方案论证，瑞幸最终与阿里云大数据AI平台合作共创，采用MaxCompute+DataWorks+Flink+Hologres+PAI技术架构，以PAI-Rec作为其新一代推荐引擎，依托其强大的大数据、算法能力与全链路服务支持，开启提升用户推荐体验的智能化升级。与客户共创，助力客户能力沉淀此次合作不仅是技术产品的落地，更是一次深度的“技术共创”实践。阿里云技术团队与瑞幸技术团队紧密协作，全程参与需求分析、POC验证、系统上线与效果优化。在项目推进过程中，阿里云技术团队与瑞幸团队高效协同，高质量完成多组对比实验，并组织多次技术交流，协助瑞幸系统性地沉淀了数据处理规范、特征工程方法、模型调优策略及测试体系，为其后续自主迭代与业务扩展打下坚实基础。展望未来：AI 驱动“更懂你的咖啡”本次合作不仅为瑞幸带来了显著的业务升级，也为阿里云人工智能平台PAI在零售行业树立了标杆案例。“本次与阿里云合作的AI智能推荐场景，提供的不仅是一个工具、一个解决方案，更是一次双方共创合作经验的落地。”瑞幸技术负责人表示，“从POC到全量上线，阿里云团队展现了极强的技术实力与服务意识。我们相信，AI将成为瑞幸持续领跑行业的重要引擎。”一杯咖啡的背后，是海量数据的流转与AI模型的精准计算。随着推荐系统的持续优化，瑞幸咖啡的运营模式实现“更智能、更个性、更高效”。未来，双方还将探索大模型在用户意图理解、生成式推荐、跨场景联动等方向的创新应用，进一步释放AI在消费场景中的潜力。瑞幸咖啡 x 阿里云大数据AI平台的合作，不仅是一次技术升级，更是AI赋能实体经济的生动实践。在智能化浪潮中，AI将成为您的专属咖啡助手——从海量风味中，AI推荐为您探索意想不到的惊喜之选，让咖啡更懂你。阿里云 AI 推荐方案：打造端到端智能推荐引擎下面将重点介绍阿里云AI推荐方案在该场景中的技术亮点与应用优势。阿里云AI推荐方案是面向企业级场景的全托管推荐算法服务平台，深度融合阿里巴巴在电商、本地生活等高并发、高实时性场景下的推荐实践经验，提供从数据处理、特征工程、模型训练、测试验证到在线服务的一站式解决方案。在本次合作中，阿里云为瑞幸咖啡量身打造了覆盖“数据 → 模型 → 服务 → 迭代”的完整推荐链路：端到端系统搭建：基于全托管架构的阿里云大数据AI平台，搭建实时推荐全链路，快速构建从数据采集、实时特征计算、深度学习模型训练到在线推理的全流程系统，实现毫秒级响应的AI推荐服务。精准转化率提升：通过引入深度CTR/CVR预估模型、多目标优化（MMOE）及序列建模（如DIEN），显著提升推荐内容的相关性与转化效率。经测试验证，最终转化率较原有规则系统提升明显。全托管运维，释放技术负担：依托人工智能平台PAI的自动化运维与弹性伸缩能力，瑞幸团队得以从繁重的系统维护中解放，聚焦核心业务创新，大幅降低AI落地门槛。阿里云智能推荐系统解决方案阿里云为企业开发者提供全链路深度定制的推荐系统解决方案。方案涵盖了离线处理、在线服务、实时数据流和工程架构等多个维度，包括召回、排序、过滤和重排等功能模块，提供多种数据诊断分析、推荐结果调试和引擎发布管理等工具，通过A/B testing服务和实验报表平台提升推荐系统的迭代效率。搭…

为什么程序员不自己开发一个小程序赚钱
type: item
date: 2026-01-30T09:51:36+08:00
description: 大家好，我是凌览。个人网站：blog.code24.top去水印下载鸭：nologo.code24.top如果本文能给你提供启发或帮助，欢迎动动小手指，一键三连（点赞、评论、转发），给我一些支持和鼓励谢谢。刷到一个挺扎心的话题：程序员为什么不自己做产品赚钱。身边还真有不少人问过类似的话："你天天写代码这么厉害，怎么不自己搞个App、做个小程序？随便弄弄不就发财了？"每次听到这种问题，我都不知道该从哪儿开始解释。最近在 X 乎上看到同行的回答，看完只能说：太真实了。理想很丰满、现实很骨感首先，假装我们是程序员，某天深夜加班回家，瘫在沙发上刷手机，突然一个念头炸开——"我去，这个功能市面上根本没有！我要是做一个，肯定爆火！”。脑子里的画面瞬间清晰：产品上线、用户疯涨、投资人排队、财务自由...，满脑子都是"老子不干了，要创业"。说干就干，流程走起来：第一步：注册账号结果发现邮箱早就被自己多年前注册过，还冻结了。解冻、换邮箱，折腾一圈。第二步：想名字绞尽脑汁想了个好名字，一搜，已被占用。再想想想，终于通过。第三步：开发前端后端一把抓，不会前端？没事，Ai结伴编程一把梭。uniapp启动，一套代码多端运行，微信、QQ、抖音、快手平台全都要上。第四步：买服务器，阿里云一核两G，一年600块，付款的时候手还没抖。第五步：搞域名，随便挑一个，一年30块，便宜。第六步：备案到这里，噩梦开始了。拍照、填表、等审核，来来回回折腾。好不容易过了，提交小程序审核——"该项目类型个人不支持，需要企业认证。"卒。亏损-630元。但程序员嘛，头铁。不信邪，继续：第七步：注册公司个体户要经营场所，干脆直接注册公司。准备材料、开对公账户、刻公章，又是一顿操作。第八步：重新认证企业认证要的材料堆成山，干脆重新注册个小程序。又是想名字（原来的还要等两天才能释放）、填资料、承诺书、盖章...终于，小程序上线了。上线只是开始，赚钱才是难题。每天努力宣传、引流，结果广告收益长这样：昨日收入0.65元。对，你没看错，六毛五。折线图上的曲线在0.3元到1.8元之间反复横跳，月收入6.72元。服务器钱还没赚回来，先赔进去几百块。什么会这样？个人开发者不能收费，只能通过挂广告，而广告收入低到离谱。激励广告单价居然只有4.29元/千次展示，Banner广告更惨，几块钱千次展示。算笔账：日访问量要达到2万，才能日入500。2万UV什么概念？很多小公司的官网一天都没这么多人。推广难，小程序是个封闭生态，你不能诱导分享，否则直接封号。只能从其他平台往微信导流，但用户路径一长，流失率奇高。要开通流量主还得先引流500人，这第一道门槛就卡死不少人。审核机制让人头大，页面上文字一多，就说你涉及"内容资讯"，不给过。个人开发者经营类目受限，动不动就踩红线。不是技术问题，是商业问题程序员不做小程序赚钱，不是因为不会写代码，而是因为写代码只是万里长征第一步。做一个能赚钱的小程序，需要：产品能力：做什么？解决谁的什么问题？凭什么用你的？运营能力：流量从哪来？怎么留存？怎么变现？商业资质：公司、对公账户、各种许可证，合规成本不低；时间和精力：白天上班，晚上搞副业，服务器半夜挂了还得爬起来修。而大多数程序员，只是喜欢写代码而已。让他们去搞流量、谈商务、处理工商税务，比写一万行代码还痛苦。更扎心的是，就算你愿意干这些，小程序的红利期也早过了。2017年刚出来那会儿，确实有人靠简单工具类小程序赚到第一桶金。现在？各大平台库存量几百万个，用户注意力被某音、被红书切得稀碎，新入局者基本就是炮灰。成功案例网上经常能看到"做小程序月入过万"的帖子，但仔细看会发现，要么是卖课的，要么是有特殊资源的（比如手里有公众号矩阵导流），要么是早期入局者吃到了红利。对于普通程序员来说，接个外包项目，按时薪算可能比折腾三个月小程序赚得还多，还省心。技术只是工具，商业才是战场。会拿锤子的不一定会盖房子，会写代码的不一定能做出赚钱的产品。这不是技术问题，这是两个完全不同的赛道。最后所以，开发一个小程序到底能不能赚钱？能，但跟你关系不大。要么你有现成的流量池，比如几十万粉丝的公众号、抖音号，小程序只是变现工具；要么你有特殊资源，比如独家数据、行业资质；再要么你踩中了某个极小概率的风口，比如当年疫情期间的健康码周边工具。否则，个人开发者大概率是炮灰。写代码是确定性的事，输入逻辑输出结果；做生意是概率性的事，投入不一定有回报。 大多数人适合前者，却误以为自己能驾驭后者。你呢？有没有过"做个产品改变世界"的冲动？最后成了吗？

逆天腾讯云用 passkey 登录还要扫码
type: item
date: 2026-01-29T19:15:48+08:00
description: 腾讯云这两天全量上了 passkey 登录，刚才试了一下，登录后竟然还要微信扫码校验，太逆天了。阿里云都上了不知道多久了，而且也不需要二次校验，之前的 200M 服务器也是摸着阿里云过河，抄都不会抄真是连一根毛都比不过

【体现撒娇稚嫩的萝莉女声，音调偏高且起伏明显，营造出黏人、做作又刻意卖萌的听觉效果】Qwen3-TTS
type: item
date: 2026-01-24T06:45:56+08:00
description: 【体现撒娇稚嫩的萝莉女声，音调偏高且起伏明显，营造出黏人、做作又刻意卖萌的听觉效果】还得是阿里📌 转载信息来源： https://linux.do/t/topic/1507026原作者： Yuanjia转载时间： 2026/1/24 06:45:54

阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具
type: item
date: 2026-01-22T16:32:58+08:00
description: 作者：杨易（青风）在云原生可观测性领域，OpenTelemetry 已经成为事实上的标准。相比于 Java 拥有成熟的字节码增强技术，Go 语言作为静态编译型语言，长期以来缺乏一种成熟、低侵入的自动插桩方案。目前的现有方案主要有：eBPF：功能强大但主要偏向系统调用层面，对应用层上下文（如 HTTP Header 传播）的处理较为复杂。手动埋点：代码改动大，维护成本高，不仅要改业务代码，还得改依赖库的调用方式，显式地在各个关键节点添加 Trace 和 Metrics 逻辑。为此，阿里云可观测团队和程序语言团队探索了 Go 编译时插桩解决方案，并将其核心能力捐赠给 OpenTelemetry 社区，形成了 opentelemetry-go-compile-instrumentation [ 1] 项目。在和 Datadog、Quesma 等公司的共同努力下，我们发布了首个预览版本 v0.1.0 [ 2] 。工作原理自动插桩工具的核心在于利用 Go 编译器的 -toolexec 参数。-toolexec 会拦截 Go 编译命令，替换成我们的插桩工具。这样，在代码被编译之前，我们就有机会对它进行分析和修改。整个过程可以概括为两个阶段：1. 依赖分析在编译开始前，工具会分析应用的构建流程（go build -n），识别出项目中使用的第三方库如 net/http, grpc, redis 等。然后，它会自动生成一个文件otel.runtime.go，将对应的 Hook 代码（监测逻辑，后面用 Hook 代码表示）引入到构建依赖中。2. 代码注入当编译器处理目标函数时，工具利用 -toolexec 拦截编译，然后修改该目标函数的代码，在函数入口插入一段蹦床代码（Trampoline Code），蹦床代码会跳转到预先写好的 Hook 函数中。进入函数前（Before）：Hook 记录开始时间，提取上下文信息（如 HTTP Headers），启动 Span。函数执行：执行原有的业务逻辑。退出函数后（After）：Hook 捕获返回值或 Panic，结束 Span，记录耗时。这种方式的优点是零运行时开销（除了必要的监测逻辑执行时间），因为插桩是直接编译进二进制文件的，不需要像 eBPF 那样在内核态和用户态之间切换，也不需要像 Java Agent 那样在启动时加载。HTTP 插桩示例让我们通过一个简单的 HTTP 例子来看看它是如何使用的。package main import ... func main() { http.HandleFunc("/greet", func(w http.ResponseWriter, r *http.Request) { w.Write([ ]byte("Hello, OpenTelemetry!")) }) log.Fatal(http.ListenAndServe(":8080", nil)) }手动插桩需要手动引入 OpenTelemetry SDK，手动创建 Tracer，在 Handler 里手动 Start 和 End Span。package main import ... func initTracer() func(context.Context) error { /* ...几十行初始化代码... */ } func main() { // 1. 初始化 Tracer shutdown := initTracer() defer shutdown(context.Background()) // 2. 包装 Handler handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // 3. 手动提取 Context，开始 Span tracer := otel.Tracer("demo-server") ctx, span := tracer.Start(r.Context(), "GET /greet") // 4. 确保结束 Span defer span.End() // 5. 可能还需要手动记录属性 span.SetAttributes(attribute.String("http.method", "GET")) w.Write([]byte("Hello, OpenTelemetry!")) }) // 6. ListenAndServe 也可能需要包装... log.Fatal(http.ListenAndServe(":8080", handler)) }对于成百上千个接口的微服务，这种改造成本是灾难性的。自动插桩下载工具：到 Release 页面 [ 2] 下载编译应用：./o…

阿里云全新发布的 UModel 是什么
type: item
date: 2026-01-22T16:20:28+08:00
description: 作者：望宸每个时代基础设施的变革，都始于对“混乱”的优雅重组。19 世纪，钢铁把不可控的垂直空间变成工程秩序，城市才得以向上生长；20 世纪，电网将分散的能源重新编排，工业生产才不再被河流左右。而如今的 IT 领域，我们正面临一场新的秩序重建，即如何让海量、碎片化、动态变化的观测数据，不再是噪音，而成为可理解、可推理、可优化智能体行为的燃料？要回答这个问题，我们先简单回溯下：IT 系统的可观测体系是如何走到今天的？IT 系统中可观测体系的发展最初，企业面向单一数据类型构建监控体系，CPU 使用率、内存占用、磁盘 I/O……一个个孤立的指标就像烽火台，只能通过局部视角告诉我们“什么地方出了问题”。但随着微服务、容器技术的普及，系统复杂度呈指数级增长。企业开始意识到：单点指标无法解释全局。于是开始对孤立的数据进行抽象，抽象出 Metrics（指标）、Traces（链路追踪）和 Logs（日志），并进行关联分析：Metrics： IT 系统是否有问题；Traces： 哪里出了问题；Logs： 问题是由什么原因导致的。发展至今，成为观测体系的三大数据支柱。但从海量、异构、动态变化的数据中准确推理并定位问题，本质上是一个极其困难的逆向工程。数据只是现象，而现象与本质之间往往存在巨大的认知鸿沟 [ 1] 。Metrics、Traces 和 Logs 这看似完整的三角，实则仍停留在现象观测层面，是 L1 级智能体的典型工作流，人工设计流程节点、人工配置触发、人工调用 API，再把指标、链路、日志喂给 AI，期望它自己找出因果，结果往往是幻觉式归因：把时间上的巧合当作逻辑上的因果。为什么？因为在 AI 面前，缺少对系统本质的建模。在 AI 时代，加剧了这种模式的挑战。一是 LLM 驱动的应用带来了上下文的碎片化。运维工程师每天要在不同的控制台之间切换，手动拼凑“发生了什么”。这就像在信息高速公路上骑自行车，工具很先进，但认知方式仍是人力驱动。二是相比由工程师写的代码定义的传统 IT 系统，AI 带来了更多的不确定性，指数级提升了原始数据自动化关联的难度，给准确推理并定位问题的挑战添了堵。总结起来，原本的认知鸿沟，被进一步分化成三层新的鸿沟 [ 2] ：数据鸿沟：原始数据混杂、碎片化、噪声多，99% 以上可能是无效信息，难以从中有效提取信号。模型鸿沟：AI 模型存在“黑盒”特性，推理过程难以解释；还可能出现“幻觉”，生成看似合理但不符合事实的结果。工程鸿沟：每天数 PB 级的数据采集、清洗、存储、计算，对性能、成本、安全性提出极高要求。数据到建模让一个没见过电路图的人，从一堆电压表读数中定位并恢复故障服务器，是不现实的。当前市面上大多数的 AI 运维助手，本质上仍是 L1 级智能体：它们被封装在一个封闭的对话框里，被动响应用户提问，背后是一连串预设的 if-else 规则或简单 RAG 检索。它们没有对系统结构的内生理解，无法主动推理依赖路径，更谈不上安全执行修复操作。而要迈向 L2 甚至 L3 级智能体，即能自主感知、规划、行动并持续学习的数字员工，就必须为其构建一个结构化的运行时上下文，不然只能靠人的经验来排查、定位和解决问题。这个上下文是经过建模、带有语义、支持查询与推理的图谱。有了这张图，智能体就能避免在数据海洋中盲目打捞，而是在一个有路标、有规则、有边界的城市中穿行。因此，出路不在更多的数据，而在更好的建模。先为 IT 系统建立一张认知地图。这张图要包含实体（主机、服务、数据库）、关系（调用、依赖、部署）、行为（日志事件、性能指标）以及它们之间的语义约束。只有在这张图上，智能体才能像经验丰富的老运维一样，快速定位故障并恢复生产。UModel 正是这张图的建模语言。我们需要从“数据驱动”转向“建模驱动”，从面向现象的观测，转向面向本质的建模，构建一个统一的上下文图谱，这正是 UModel 的使命。什么是 UModelUModel（Universal Observability Model）是基于图模型的可观测数据建模方法。又是图模型，又是建模，一听就很学术。通俗易懂的讲，就是用“画图”的方式，把一堆随机事件之间的概率关系理清楚，让复杂变简单，让模糊变清晰。因此，UModel 旨在通过标准化的数据建模方式，实现可观测数据的统一表示、数据建模与具体存储的解耦，从而实现智能分析。有了 UModel，智能体才能像经验丰富的老运维那样快速定位故障并恢复生产，成为可能。UModel 可以看成是阿里云可观测体系的数据建模基础。总的来讲，UModel 的核心思想，是为可观测领域打造一个认知操作系统，是一套标准化的数据建模方法，旨在弥合前文所述的三重鸿沟，为 AIOps 提供可解释、可扩展、可自动化的基础。接下来，我们从 UModel 的构成和使用方式来…

阿里的永久免费真的可信吗
type: item
date: 2026-01-22T04:43:03+08:00
description: 很久之前就听说了 iflow，刚出来的时候还是限时免费，火了一段时间，今天再进去看，发现变成永久免费了，不过这玩意不会跟阿里云盘的永久不限速同出一辙吧

云原生为基，AI为翼：回望阿里云云原生的2025年
type: item
date: 2026-01-20T18:46:31+08:00

阿里云 CIO 全面深度解析：企业 AI 大模型落地实践「 RIDE 方法论」
type: item
date: 2026-01-19T18:17:10+08:00
description: 据麦肯锡发布的《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，并且产生实际的业务结果，就要做非常大的投入。恰好，在这个领域，我们做了很多探索和实践。阿里云企业大模型应…

阿里云 CIO 全面深度解析：企业 AI 大模型落地实践「 RIDE 方法论」
type: item
date: 2026-01-19T12:14:31+08:00
description: 据麦肯锡发布的《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，并且产生实际的业务结果，就要做非常大的投入。恰好，在这个领域，我们做了很多探索和实践。阿里云企业大模型应…