作者 | 凌敏、籍云
AI 个人工具每天都在创造奇迹，企业 AI 落地却像陷入泥潭。阿里云 CIO 与十大行业 40 余家头部企业 CXO 深度碰撞数月，打捞出十个鲜少被公开讨论的真实之问。这不是一份标准答案，而是企业“向内看”的一面镜子。
一边科幻，一边泥潭
AI 的冰与火：工具级和企业级的两极境遇
AI 工具高热两个月了，OpenClaw 反复刷屏。一个人，一台电脑，给 AI 开放本地权限，它开始自主搜索、写代码、调文件、发邮件——有人用它几小时完成了过去一周的工作量。漫天的 AI 应用，让 个人的生产力可以扩张 50 倍。“AI 时代，一个人完全有可能创办一家估值 10 亿美元的独角兽公司。”Open AI 联合创始人山姆·奥特曼说。
与个人 AI 的画风相反，企业级 AI 冷热不均，战线也更长一些。2025 年的一场小型闭门会上，一家知名化妆品公司 CIO 表示，他几乎与所有做 AI 智能营销的厂商聊了一遍，都没有结果，他甚至立场鲜明地反对数字人产品进入零售公司，认为这是 伪需求。同年 9 月的另一场 CXO 闭门会，一位知名企业的 CEO 甚至当场发问：“AI 到底是不是一场骗局？”
去年大家对 AI 半信半疑，至少在企业落地层面，AI 还远没有看起来那么确定。今年，态度肯定了，但心态迷茫了。
2026 年有一些公开的企业案例：某保险公司开发的 AI 理赔系统上线后准确率仅 60%，因数据格式混乱、内容过时，需额外花 2 个月清洗数据，项目严重延期；某制造企业 AI 质检系统误判率 15%（而人工仅 3%），因产线数据无法实时接入，三套老旧系统打通需半年且预算超支，系统上线三个月后“休眠”；某连锁超市巨头引入 AI 动态补货系统，覆盖 1200 家门店，上线后，华东区门店缺货率飙升 40%，而华南区却库存积压。
管中窥豹，以上这些，只是 AI“试点炼狱”的一些样本。
观察发现，2025-2026 年 AI 大模型发展最诡异的处境是：个人用 AI 越来越像科幻，企业用 AI 越来越像泥潭。个人工具级和企业组织级的 AI 价值兑现进度条，完全不在一个配速上。
MiniMax 在最近一次财报电话会上表示，Agent 已经覆盖其 90% 员工所在的工作场景，这是其能以 400+ 名员工同 OpenAI 以及其他国际巨头竞争的底气之一。这一数据指向的是，行业内最先进的公司正成为所谓的 AI-Native 组织。而据 MIT 针对 2025 年商业人工智能现状的研究显示，全球 54% 的顶级企业将 AI 列为优先投资，但真正实现转型价值的，还不足 5%。即使到今年，这一局面并未出现明显改善。据普华永道今年 1 月发布的数据显示；仅有约 12%的 CEO 认为，企业 AI 已经实现成本与收入两端的价值兑现。当然，企业对 AI 的投入，依旧升温，但实现价值兑现的进程，持续缓慢。
图 1: AI 境遇对比（图片由 AI 理解生成）
在这组冰与火反差巨大的数据背后，一个群体被推到了聚光灯下——企业 CIO。
站在 AI 时代风口上，CIO 成为这场 AI 赛事最直接的承压者，他们是企业技术战略的制定者，是 AI 落地的第一责任人，也是在愿景与现实之间不断拉锯的缓冲带。
企业级 AI 的锚点：CIO 的十个集体追问
当“AI 一日，人间一年”演绎得愈发剧烈，让 CIO 犹如"钢丝上跳舞"。
理性去看 CIO 这种时代性压力，背后并非一时之症，是深在腠理、盘根错节的历史包袱，与当下 AI 迎面接壤之后，问题更加错综复杂。解铃更须系铃人，或许只有局内人，才更懂这场 AI 局的解法。
为了给企业找到 AI 落地路径，阿里云 CIO 已经探索 AI 几年了，从无数个坑点中爬出来，总结矫正再去尝试，始终不停。去年，他找到了 RIDE 的落地方法，但方法的打磨和迭代，不是孤军一人闭门造车，而是和更多顶尖企业的 CXO 深度碰撞，去验证问题和答案。
这个验证过程，最关键的是真实。
袒露真相才能找到问题，定义问题才能领悟解题，于是，很多 AI 落地答案是从真正的“Bug”里走出来的。事实证明，阿里云 CIO 在与十大行业、40 家顶尖企业深度对话之后，大家表现出来的困惑背后，并非“AI 能不能”，而是更为根本的 What 和 How 两个方向：
我们到底在用 AI 做什么？—— 所谓做什么
企业的 AI 为什么总是做不成？——所谓怎么做
历经 AI 发展最快的这半年多，从大量的管理者对话中，阿里云 CIO 团队试图找到问题的真实锚点，并梳理成一份 AI 时代的纪实性报告：《企业智变下的 CIO 集体之问》（以下简称《CIO 之问》）。
报告横跨十大行业的关键共性问题，并归纳为 企业级 AI 的十大经典之问，一定程度上也代表了 AI 大模型时代下，CIO 的集体之问。
一问：当企业做 AI 数字人时，究竟在做什么 ？
二问：AI 来与否，CIO 与组织都面临一样的老问题 ？
三问：当下 AI 机会迷思，如何分辨大模型“能做”与“慎入”的业务 ？
四问：为什么，大多数企业都搞不定“企业知识库” ？
五问：怎么搞定高品质的“AI 燃料”：知识工程 ？
六问：Agent 的工程落地，“品味”是关键 ？
七问：AI 数字员工上线，和谁比、归谁管 ？
八问：企业如何应对“AI 替代”的群体抵触，推动组织转型 ？
九问：AI 时代的组织权责：IT 与业务，缘何矛盾？怎样融合 ？
十问：AI 推动的“10X”研发效能，真相如何 ？
前三问追问本源， 后七问深入内里。下面，我们逐一把问题展示出来。我们相信，从企业内里找到真正的问题，离答案就不远了。
图 2: 报告归纳十大经典问题（图片由 AI 理解生成）
我们到底在用 AI 做什么 ？
当下有个颇为矛盾的现实：一面是，全球企业都在以前所未有的速度加大投入 AI，据 Gartner 预测，2026 年全球 AI 总支出将达到 2.5 万亿美元，同比增长 44%；另一面是，很多企业在回答“到底用 AI 在做什么”时，价值却格外模糊，也带着不自信。
这是当下企业 AI 推进中典型的反常识现象。
在阿里云 CIO 与 40 多家顶尖企业的深度交流中，这样的时刻反复出现。表面上看，这些企业的 AI 项目并不少，推行也很积极甚至激进。但当视角从具体的项目中抽离出来，回归到最根本的那个内核上时，很多 CIO 会突然停顿一下。目标、路径与预期好像彼此错位，甚至，也许连“问题”都没有发现。
世界的运行秩序，往往是由 20% 的根本性力量决定的，企业也一样。所以，报告的第一问，先从第一性原理出发，回归企业级 AI 的本质。
CIO 一问：当企业做 AI 数字人时，究竟在做什么？
过去一年，数字人几乎成了企业 AI 最火的关键词之一。从客服数字人、销售数字人，到运营数字人、招聘数字人，几乎所有行业都在尝试把 AI 放进业务流程里。
The Business Research Company 今年 3 月发布的一份数字人市场报告显示，近年来数字人市场规模呈指数级增长。预计 2026 年 数字人市场规模将从 2025 年的 477.2 亿美元增长至669.8 亿美元，到 2030 年，数字人市场规模将达到2581.5 亿美元。
与市场的“高热”形成鲜明对比的是，不少企业在认知层面仍处于“混沌期”。
主体的混沌是阶段性的，就像龙虾潮演变成全民养虾，数字人流行演变成企业数字员工全面上阵，但当我们大量使用工具时，究竟是在做什么？这是必要的本源性拷问。
这是在《CIO 之问》的形成过程中，被意外暴露出来的，一个看似基础的问题，比如：数字人和 AI 服务、智能外挂，是不是一回事？
很多企业的第一个 AI 项目，大多是基于 AI 技术的服务或是“外挂型 AI”，比如翻译服务、营销工具等。但 这些往往只停留在工具层面，并不承担完整的生产任务和业务责任，也几乎无法度量价值。企业用了，却很难说清楚它到底有没有用。
数字人则不同。它的输入 / 输出和人类员工完全一致，可以作为“人”来抽象，它执行原来人类员工在现实中执行的任务，甚至比人类做得还好。企业也可以像度量人类员工一样，度量数字人的质量和效率。其背后的逻辑在于，数字人是把原本依赖个人经验完成的知识与操作过程，线上化、数字化，进一步产品化。比如，一个电销数字人的本质，就是垂直知识 + 电销服务的 SOP。
从这个角度，《CIO 之问》也推理出要点：当下企业级 AI 所做的事情，本质上是“一场知识工作的线上化补课”，AI 也让知识工作第一次可以“被管理”。这是 AI 数字员工的根本起点。
过去几十年里，知识工作（如法务、HR、销售、设计）是“离线的”，知识和判断都在人的脑子里，企业大量的知识工作由于非结构化特征，很难被传统 IT 系统数字化，也就没办法被洞察和改进。
AI 第一次历史性地，让知识工作的过程和结果可以被在线化、被度量、被优化，也由此派生了数字人。报告流出的一组对话中，一家科技公司 CEO 认同感慨：“以前我们管流程，现在我们终于能管知识了。”
这里，阿里云 CIO 也同步延展了一个认知：与传统系统相比，数字人首先要解决的，其实是一个生产关系问题。意思是，数字人的一大核心职能，就是承接原本由人类执行的知识工作，解决真实世界因人类固有约束，而形成的生产关系问题。
因此，企业做数字人，要 先定义出“有价值的重复执行的任务”，让数字员工先承担起来。通过这样的方式，IT 部门与业务部门可以围绕具体任务形成共识，而不是把 AI 当作许愿池，造成无法落地的矛盾。
在这个过程中，数字人往往是先以效率工具的形态进入企业，随着数字人承接的任务不断扩大，原本围绕人力组织起来的业务流程也会随之改变。从落地顺序来看，效率工具是入口，价值重构是结果。
早在 2025 年 9 月，阿里云内部就已落地了 28 个数字人项目，在内部工作系统中，这些数字人与普通员工一样，拥有工号和头像。关键的是，数字人的业务任务是真实的，度量是完整的。
图 3: 企业级 AI 的本质（图片由 AI 理解生成）
当然，数字人能顺利承担任务的前提，是企业内部的系统、数据和流程能够配合它的工作。如果缺乏相应的流程支撑，再先进的数字人也无法真正融入业务。
这正是《CIO 之问》第二问探讨的核心。
CIO 二问：AI 来与否，CIO 和组织都面临一样的老问题 ？
在大模型能力几乎每隔几个月就上一个大台阶的当下，很多人都会产生一种强烈的错觉：AI 已经这么强了，企业里的很多效率与业务问题都能快速解决。但源源不断的风险事件和数据困局，揭露的却是另一个截面 ：AI 能力越强，越容易暴露企业原本隐藏的问题，尤其是数据这类地基问题。
Informatica 今年 1 月发布的《2026 年首席数据官洞察》研究报告中指出，69% 的企业已将生成式 AI 嵌入到业务流程中，但 91% 的数据领导者表示，数据可靠性仍然是 AI 项目从试点走向生产的主要障碍。报告将这种现象称为“信任悖论”：虽然员工普遍信任 AI 使用的数据，但数据领导者深知数据质量和治理结构的短板。
《CIO 之问》用一个极其准确的比喻——AI 是面镜子，照出 IT 系统的历史——来描述这种现象。镜子不会让一个丑的人变美，也不会让一个美的人变丑。同样，AI 也不会创造出新的问题，它只是把企业原本就存在的问题照亮了，让企业第一次必须认真面对这些历史问题。
以数据分析为例，很多企业都在尝试构建 BI 或商分数字人，通过自然语言进行提问，AI 自动生成 SQL 查询并返回分析结果。看似简单，但它隐藏一个巨大的前提：企业原来的数据指标要完善。如果原来的 SQL，人都写不出来，那么换成 AI 之后，问题依然不会消失。
也有企业提到 AI 时代的业务指标体系怎么建？但《CIO 之问》讨论认为，指标的问题，本质上和 AI 没关系，它是上一代数字化要解决的问题。理论上，企业应该有一套清晰的核心指标体系，团队围绕这些指标迭代，就像围绕北极星指标观察业务异常。但如果企业在上一轮数字化转型中，没有解决好数据拉通、业务决策、业务数字化、数字业务化等一系列问题，到了 AI 时代，大家以为拿到了一盏“阿拉丁神灯”，开始期待 AI 能够自动解决所有问题，这是不现实的。
阿里云 CIO 一直把企业原来的系统与数据基础比作“蛋糕坯”，AI 更像是蛋糕坯上的樱桃。老板想要的是一块漂亮的樱桃蛋糕，如果没有蛋糕坯，再漂亮的樱桃也无法做成樱桃蛋糕。换句话说，如果底层数据结构混乱、指标体系不清晰，再先进的 AI，也无法生成真正有价值的结果。
如果把企业技术发展路径放在更长的时间轴上看，很容易理解背后的根因。
过去二十多年，企业技术体系大致经历了三轮演进：信息化、数字化和智能化。信息化关注的是把业务搬到系统里；数字化关注的是用数据理解业务，通过数据做解读、做决策；智能化关注的是让 AI 参与到生产中，涉及到对数据的评测。从难度上来看，智能化>数字化>信息化。
理想的演进顺序是逐步递进，但现实情况却是，在很多企业里，这三件事几乎交叠着同时发生。
《CIO 之问》在交流中观察到，“在飞行中换发动机”来形容企业状态的，大量存在。也就是说，企业一边补信息化时代的作业，比如系统整合、流程线上化；一边补数字化转型的作业，如数据治理、指标体系建设；同时还要融入 AI 快速进入智能化阶段。这难度可想而知。
图 4: AI 是蛋糕坯上的樱桃（图片由 AI 理解生成）
于是，一个很微妙的局面出现了。AI 看起来“无所不能”，但在企业真正落地时却又“落不下去”。这种尖锐的反差，也是 CIO 在这一轮技术变革中的最大压力来源。问题的症结，也许需要重新审视 IT 系统的本质。
《CIO 之问》 给出一个本源的思考：IT 里的信息系统，本质是物理世界的一个抽象，是企业业务历史社会关系的总和，CIO 终归是要戴着历史所有的镣铐，去支持新业务的。
于是，AI 时代的 CIO，到了跳出单纯技术视角的历史时刻。
CIO 的关键词“I”，从信息化的 Information，扩展到数字化的 Data，又进入智能化 Intelligence。分析机构也在重新定义 CIO， 从 IT 智能负责人向战略制定者，从技术维稳者向生态协调者。
阿里云 CIO 也给出他的经典理解，从“系统交付者”变成“组织翻译官”。这个翻译有两个方向：一是“向上”，把技术的现实约束翻译给业务高层，让他们的 AI 期望值落地；二是“向下”，把业务的真实需求翻译给技术团队，让工程师知道自己做的东西真正有人用、有人评、有人负责。
AI 在不断降低技术生产的门槛，过去，CIO 的不可替代性很大程度上来自“只有我们懂技术”，但当下，CIO 真正要当作自己第一衡量标准的，是“业务结果”，而不是“技术交付”。
Asana CIO Saket Srivastava 也谈到，未来的 CIO 将不再以管理系统为荣，是以 “如何编排工作在整个业务中的流转”为考核标准。也许，无论哪种角色转身，这本就是 AI 这面“镜子”照见 CIO 群体的结果。
图 5: AI 的发展与 IT 的本质，决定 CIO 的角色变迁（图片由 AI 理解生成）
当企业逐渐看清这些老问题之后，新难题也随之出现：在大模型几乎无所不包的能力面前，企业到底投入在哪儿，才是对的？
这也引出了《CIO 之问》的第三个问题，这几乎是所有企业的集体之迷。
CIO 三问：如何分辨 AI 大模型“能做”与“慎入”的业务？
过去几年，大模型能力不断刷新外界想象，几乎每个行业都在讨论新的应用机会，希望找到可以被 AI 改造的环节。但现实却是，企业对 AI 的期待已经远远超出技术本身，AI 炒作与价值回报之间存在巨大的鸿沟。
根据普华永道今年 1 月发布的第 29 届全球 CEO 调查，大多数首席执行官表示，他们的公司尚未从 AI 投资中获得财务回报。更具反差的是，尽管 AI 被视为拉开企业差距的关键变量，但 CEO 们对营收增长前景的信心却跌至五年来的最低点：仅有 30% 对未来 12 个月的营收增长持乐观态度，远低于 2025 年的 38% 和 2022 年的 56%。
表面上看，大家失去的是对 AI 价值回报的信心，实际更隐蔽的症结，是企业在 AI 项目起点上的判断偏差。
但并非所有的企业都意识到这一问题。 AI 掀起的这股技术热潮下，很多公司把 AI 当作“万能钥匙”：客服用 AI、销售用 AI、数据分析用 AI、商场排班用 AI、库存管理用 AI、金融交易系统用 AI、对账系统用 AI、服装设计用 AI、一线导购用 AI……为了不错过，企业好像什么都能用 AI 重新做一遍。
这也是当下企业在 AI 落地过程中，非常典型的 一个认知误区：不是先定义问题，而是先决定用 AI。
《CIO 之问》发现，这种误区的根源性在于，企业可能没有认清 这轮 AI 革命的核心 LLM（large language model）的本质。所谓大模型，是“大语言”模型，很多企业忽视了这个“大语言”究竟擅长做什么。它必然是一个围绕 language 构建出的系统。只要是有 language 关键字的业务范畴，大模型都非常擅长。
但现实却是，一些并非以 language 为中心的工作，也被一股脑儿地丢给 AI。
以行业常见的排班规划和库存管理为例，这类典型的规划场景，本质上是最优化调度问题，属于重度规划，它的重复性不高。并不是一个以自然语言交互为基础的应用，而是一个结构化的求解，可度量、可观测。对于这类能结构化的场景，一旦引入 LLM 用自然语言去操纵它，反而会牺牲精准性。在《CIO 之问》报告呈现的一组对话中，某制造行业企业坦言，从一个小的具体场景做起来会发现，对于结构化场景，“大模型是做不过传统手段的”。
能精准解决的问题，就没必要引入模糊能力。像金融行业的交易系统、对账系统这类场景，道理也是如此。这类业务的核心是交易精准，任何细微误差都可能带来严重后果。因此，这类场景更适合采用原来传统的 OLTP，用精准的数据模型和对账校验系统来完成。
这类场景上的判断偏差，根源在于企业未能分辨大模型“能做”与“慎入”的业务究竟是什么。所以简单总结来看，《CIO 之问》从多轮问题讨论中，给出三个关键点：能做、慎入、和边界。
先看 “能做”。如前文所说，这一轮 LLM AI 的本质是 language（语言交互的知识工作）。这意味着，以 language 为中心的工作，都将被大模型深刻影响。比如电销、客服、招聘、OKR、文档、翻译、合同审核，还有研发类的 C language、Java language、SQL language 等等。
再看 “慎入”。与 language 为中心相反，那些不以自然语言交互为基础的应用，比如重度依赖规划、不经常重复，比如高度结构化且需要高度精准化的场景，当下的 LLM 并不擅长。并且，当下的 LLM 对物理世界的场景帮助也有限，也许未来，具身智能技术会在最后一公里的物流服务上带来效率颠覆。
在“能做”与“慎入”之间，这里，还存在一个模糊的 “边界”。比如有企业抛出很有意思的问题：“有些模糊的地带既可以用 AI 做，也可以用传统系统做，到底该用谁来做？”
对这个问题，《CIO 之问》给出这样的考虑原则：能垂直专业化，就先做垂直专业化。
一方面，这涉及到技术部门的一个长期问题：它永远是“大一统”逻辑（统一 IT 、统一信息、统一数据中台、统一智能化平台），经常会有横向的技术团队来承接这件事，但它最终无法形成专业化。
另一方面，涉及到 “世界知识”与“垂域知识”的问题。本质上，人工智能，其实是由人去教它的，但如果人都搞不清楚的问题，就不能企图让 LLM 搞清楚。更进一步来说，对于物理、数学等标准化的“世界知识”，AI 能够进行训练；但对于企业业务领域的知识，AI 是很难获取的，也就对这些知识无法评测。这是个关键的可度量问题。
图 6: 分辨 LLM AI 的能力边界（图片由 AI 理解生成）
当企业能够定义问题，分辨能与不能时，下一步真正卡住脖子的，往往不是技术，是落地过程中那些更深层、也更棘手的问题：为什么 AI 项目做了很多，却始终难以兑现价值？
为什么 AI 项目总是做不成？
很多企业的 AI 项目往往立项时声势浩大，高层重视、预算到位、试点汇报时数据亮眼，但几个月后却骤然降温，使用率下降，管理层陷入怀疑。这是很多企业在当下的普遍状态。麦肯锡在 2025 年末发布的报告解读中指出，大多数企业的 AI 项目仍停留在 PoC 或试点阶段，只有 7% 的组织实现“全组织部署整合”。
在传统的信息化项目中，系统的逻辑相对确定、清晰，大家更多是在既定规则上实现自动化。AI 项目则完全不同，它依赖大量高质量的数据，需要专门的人构建知识、定义评测标准，需要组织内部形成新的协作方式。
很多企业在复盘 AI 项目时，最初的直觉往往将问题归结于技术：是不是模型能力还不够强？算法效果不稳定？算力成本太高？AI 项目之所以停在 PoC，并不是因为技术做不出来，而是 组织本身还没有为 AI 的工作方式做好准备。
因此，《CIO 之问》的后七问，选择将视角拉到 企业系统与工程内部，从企业真实落地难题出发，逐一拆解那些在 AI 项目落地中绕不开的关键。
问题的第一站，是企业知识库。这是几乎每个企业在启动 AI 项目时，都会面对的课题。铺天盖地的教程让企业快速构建知识库成了一件看起来容易的事情，但现实却是，企业知识库往往是最早立项、也最容易陷入停滞的项目之一。
《CIO 之问》的第四问，深入探讨了企业知识库失败的根因。
CIO 四问：为什么，大多数企业都搞不定“企业知识库”？
在企业的 AI 项目规划里，知识库通常会被放在一个非常核心的位置，不少企业也愿意为其投入资金、物力和人力。但往往知识库建了两年还是一塌糊涂，好像 ChatBI 上线即终结。
公开信息显示，某国有银行信用卡中心曾投入 300 万元上线智能知识管理系统，希望通过系统化沉淀内部知识，提升员工查询效率。但系统上线后，实际使用率持续低于 25%，大家宁愿请教同事或用自己整理的 Excel 知识库，也不愿意打开系统检索。
投入打了水漂，知识库成了摆设，这只是企业知识库困境中的一个缩影。
为什么看似成熟的知识库，却在企业内部频频“翻车”？
其中的一个重要原因是，企业对知识库的期待已经发生了根本改变。过去，知识库是给人用的，员工查资料、做决策、写报告，即便信息不完整，人也可以依靠经验进行判断和补充。但 在 AI 时代，知识库的使用对象是 AI，AI 需要根据知识库自动回答问题、生成报表、辅助决策。也有不少企业尝试通过 ChatBI 等方式，把原本只有数据分析师或管理层才能使用的数据能力开放给更多人，让员工通过自然语言就能完成数据分析。
这本是一件非常有价值的事情，它意味着数据走向平权。《CIO 之问》也观察指出：正是因为这些“大而全”的期待，让企业知识库陷入盲目建设，暴露出更多的问题。比如，很多企业在推进 ChatBI 项目时发现，自然语言转成 SQL 并不难，难的是，企业原有的数据体系是否足够清晰、可靠。如果原来的 SQL 不完整、不准确，ChatBI 项目推进自然会遇到瓶颈。
此外，这种“大而全”的期待也会让企业知识库建设逻辑出现偏差。比如，很多企业以为，只要把散落的文档、报表和邮件收集到一个系统里，就完成了知识库建设。甚至有些企业还期待，AI 能够自动补全那些缺失的历史知识。但正如《CIO 之问》第三问中已经强调的，AI 有其能力边界，对于物理、数学等标准化的“世界知识”，可以利用 AI 进行补充，对于实质知识、垂域知识，只能靠企业自身积累。
因此，报告给出建议：企业在建设知识库时，需要聚焦垂域场景，从具体的业务任务出发，先识别出该场景的“意图空间”，再根据“意图空间”识别需要用什么样的半结构化数据来支撑，再去有针对性地进行知识库建设。这是一个从应用垂直视角重新建设的正向逻辑。
但在现实中，很多企业走的路径完全相反。比如，在大量的 CIO 交流中，企业看似在讨论如何管理散落的非结构化知识，实际的潜台词是，企业存量的 Word 文档是一个全量的、支离破碎的收集逻辑。这些知识本身并不完整，甚至和现实业务脱节，有错有漏。用这样的知识做地基，无异于 “浮沙筑高台”。这也是为什么，大多数企业都搞不定“企业知识库”。
当企业开始以 聚焦垂域场景的思路，推进知识库建设时，很多看似复杂的问题，尤其是大家普遍关心的知识库数据安全问题，都会找到答案。
在这之上，另一个问题随之出现：当企业真正把知识库收缩到具体业务场景之后，如何保证供给 AI 的知识燃料是“精品煤”，而非“粗煤”？这直接关系到能否让 AI 产生真正的业务价值。
《CIO 之问》第五问，试图寻找的正是这一问题的解。
CIO 五问：怎么搞定高品质的“AI 燃料”：知识工程？
知识即数据。如果数据本身存在问题，知识质量也不会高，AI 效果更不会好。
台湾 CIO 杂志在今年 1 月发布的《CIO Insight 年度调查报告》中提到，38% 的 CIO 承认 AI 导入后的效率不如预期，原因是公司内部的资料太脏、太乱了。超过 40% 的企业直言，手上超过一半的数据都需要清洗。报告将这一现象称为“数据的赎罪”，并预测 2026 年，很多企业将被迫停下脚步，花大价钱去进行数据治理。
这听起来很不性感，但如果不做，之前的 AI 投资就会变成财务黑洞。
不过，数据治理还只是第一步。再往上走，是知识工程。阿里云 CIO 在去年的《C 位面对面》栏目中曾做过一个形象的比喻：“我们这一轮 AI，假设它是引擎，那知识就是燃料。”
撑起 3000 多亿美元市值的 Palantir 提出的“本体论”，本质上就是建立知识工程能力，把业务知识结构化建模。不过，很多人把“建模”当成了终点，其实它只是起点。关键需要先想清楚，到底要建哪个领域的“本体”？这个“本体”是谁定义的？能不能被验证？能不能跑出结果？这是《CIO 之问》探讨本体论时给出的挑战。
阿里云 CIO 坦言，这两年团队的工作，实际上就是用 AI 逼着人把脑子里那些“只可意会”的经验，变成可执行、可校验的结构。真正的本体，不是画出来的，而是跑出来的。要想落地 Palantir 的“本体论”，很难靠咨询公司画个图去实现，而是要把 AI 当员工，逼着业务部门一起去定义“什么是好”，用真实数据和结果反推结构，每次迭代都看“客户是否真的用起来了”。
《CIO 之问》探讨认为，做好知识工程，就先做“意图空间”。这里有几个关键点：做垂域的有限空间，否则“起步即死亡”；在垂领里，倒过来还原意图；要警惕智能补偿的欺骗性。
因此，讨论的建议是：在构建知识空间时，企业需要先从不可能到可能，从无限空间到有限空间，如果恰好在某个垂域有比较规整的数据，就可以将其当做切入口。
从选定切入口，到真正构建起可用的知识空间，企业还会遇到一些实际落地问题，比如：
1. 知识空间究竟该由哪个团队来主导？很多企业的第一直觉往往是“IT 团队主导，业务团队配合”，但报告挖掘出的真相是，业务团队必须成为驱动者。
2. 知识空间另一个难点，是隐形知识如何显性化？报告探讨认为，AI 做的，只是将原来的“知识”翻译成“技术语言”，这并不是 AI 时代才出现的新工作，是知识工作者原来就应该做、但一直没有真正做好的本分。
3. 数据涉及核心机密时，企业内部 AI 中台提出的安全等级挑战如何应对？报告认为这涉及到 一个常见误区： 不该问“AI 权限怎么办”，AI 应该是基于原来的系统去做，尊重原来的系统也许就不存在权限问题。
《CIO 之问》从一系列的知识问题中发现：很多问题本质上透露的，是需要改变的思维范式——企业需要把 AI 视作新的渠道，而非新的功能。如果将 AI 视为一个新的功能，将数据、API 独立于原有的业务系统，重新做一遍，那么管理成本会迅速失控，架构复杂度也会飙升。
图 7: 知识工程的认知转变（图片由 AI 理解生成）
回到主线，当企业的意图空间和知识空间都建立好了，才有可能开展评测，度量 Agent。这也是 Agent 工程落地的关键。
《CIO 之问》第六问，探讨的核心就是“评测”二字。
CIO 六问：Agent 的工程落地，品味才是关键？
要想找到 Agent 工程落地的答案，需要先认清 AI 工程的关键。
《CIO 之问》将 新 AI 时代的工程比作“壳”，数据和评测工程比作“肉”。当前，很多企业陷入的误区是，是把大量资源投入在“壳”上——用通用模型快速做个“壳”出来，实现所谓的提效。但在垂域里，“肉”才是最重要的——数据和评测工程所代表的 know-how，才是企业真正的护城河。
更直白地说，企业要想实现 AI 项目的成功，首先要重视评测的人，这和“品味”大为相关。
1995 年，记者在一场采访中问乔布斯：“你怎么知道什么是正确的方向？”乔布斯回答道：“最终，这归结于品味。要主动去接触人类创造过的最杰出成果，再试着将这些融入你正在做的事。”
三十年后，这句话在 AI 时代显得格外鲜活。《CIO 之问》也给出一个有意思的推断：AI 以前所未有的速度降低技术门槛，技能大规模通胀，真正的品味开始通缩，异常稀缺。这里所谓的品味，不是抽象的审美偏好，是指对“什么才算真正好”的判断力，这与这一轮 AI 的关键问题——评测——高度相关。
听上去也许有些反常识。今天谈 Agent 工程落地，大家最常讨论的是数据、模型、算力、工具链，仿佛只要这些条件具备，落地就是水到渠成。与之相比，真正愿意深入讨论“评测”的人却不多。但评测，恰是这一轮 AI 里最难、最关键的部分。
这要回归到本质去理解。与上一轮以深度学习为代表的 AI 革命相比，这一轮 AI 革命最大的区别就在于，度量数据、评测没有标准答案。这也是强调品味的根因。比如，深度学习时代做数据评测相对直接，图片是交通灯还是汽车，都可以通过打标建立标准答案。但这一轮 AI 革命，大模型输入 / 输出都是“小作文”，在企业专业场景里，更是没有标准答案，很难直接度量，这也间接带来了成本增高等落地难题。
从这个角度来看，企业实现 Agent 工程落地，要由有品位的人，来构建知识与定义评测标准，这直接决定了大模型应用能达到的高度。
更深层地讲，《CIO 之问》给出了经典的讨论：对 AI 的品味，本质上是人类对复杂世界的经验、抽象能力和责任感的结晶。AI 可以提升下限，但上限，永远靠人来定义。
品味之后，是具体的执行。
这也是很多企业很关心的具象落地问题，像企业 AI 开发的脚手架工程、小模型与大模型的使用，数字员工与数字员工的交互设计……从问题能观察出一些需要警惕的误区：
报告探讨认为 “AI 开发平台不是预先规划、构建出来的，一定是“打”出来的”，源于真实的业务碰撞，而非技术空想；
一些训练场景下的基本原则是 “能不用小模型就不用、能不去微调就不去微调”；
在单一数字员工落地就很难的情况下，很多企业还企图再用 Multi-Agent 一起来，这无异于从一个草台班子变成两个草台班子加起来，等等。
每个话题都可以延展出一项课题，这里不做赘述，更多可详见完整报告。
图 8: AI 时代的壳与肉、技能与品味（图片由 AI 理解生成）
当 Agent 开始真正在工程中落地，数字人的管理，直接影响 Agent 能否真正产生价值，《CIO 之问》第七问，试图探讨这个被高频提及的问题。
CIO 七问：AI 数字员工上线，和谁比、归谁管？
很多企业在讨论 AI 数字员工时，最先想到的往往是能力：模型够不够强，回答准不准，能不能真正接流程、替人干活。但真正到了上线那一步，才发现最大的问题出现在组织层面——
AI 数字员工上线后，到底该和谁比？
是和专家比，还是和原来岗位上的普通员工比？
它归技术部门管，还是归业务部门管？
出了问题，“锅”算谁的？
传统的金字塔结构会彻底改变吗？
……
这些问题之所以难，是因为过去大多数组织的管理体系，不是为“非人类员工”设计的——组织本身还没有为 AI 的工作方式做好准备。
管理学中公认的一大信条是：如果你不能衡量它，就不能管理它。所以《CIO 之问》探讨的，是对数字员工的度量和管理。报告认为：AI 数字员工难以管理的根本原因在于，它是知识型员工。正如“现代管理学之父”彼得·德鲁克所说，知识型员工是最难管理的，因为难度量。因此，AI 数字员工进入企业之后，首先冲击的不是某个岗位，而是企业原有的管理方式。
但在大多数企业中，组织结构、岗位职责和 SOP 依然停留在旧体系里。在这种错位中，自然暴露出了前文所探讨的和谁比、归谁管等问题。
先看“和谁比”。这里最常见的误区是，很多企业将 AI 数字员工直接拿来和专家比，期待它能达到专家的水平，甚至把 AI 视作神来比较。
但在现实中，企业是一个金字塔的能力模型：塔尖是少数专家，塔底则是大量重复执行标准化任务的人。企业之所以能扩大规模，不是因为专家越来越多，而是因为专家把经验沉淀成 SOP，再交给更多普通员工、基层员工或者外包去执行。从这个意义上说，当下 AI 数字员工最现实的落点，并不是先替代专家，是优先接管金字塔底部那些人的“真实任务”。
再看“归谁管”。有不少企业提出这个疑惑：过去，出了问题可以直接找到具体的负责人，但现在有了 AI 数字员工，出问题是不是就甩锅给 AI 了？答案显然是否定的。《CIO 之问》探讨认为，“锅”一定都是在正式员工身上，AI 是外包性角色，谈不上“锅”的责任。而很多企业普遍存在这个误区的根因在于，并没有一个清晰的责任结构。
比如，这里有一个认知错位：很多企业会下意识地将 AI 数字员工交给技术部门来管，但一旦它真正进入业务流程，具体岗位任务，它的价值就和业务结果挂钩。因此，AI 数字员工更适合交由业务部门管理，同时，业务要与技术部门一同合作去度量，去确认 AI 数字员工是否合格。这个过程中，IT 部门担当了“数字员工提供商”的角色。这是《CIO 之问》给出的建议。
当然，不同岗位的 AI 数字员工，落地后的管理方式和注意点也不尽相同。在《CIO 之问》中，不同企业探讨了多个场景下的数字人落地经验：
在当下应用数字人最广泛的客服场景，企业需要解决的不只是“怎么管”，还需要明确问答背后的知识体系是如何构建与保障的；
LLM 最擅长的文档场景，过去需要人工六个月才能完成一轮的验证工作，文档验证数字人只需要一个星期；
服装设计师这类复合型岗位，数字人最适合接管的是“单一任务”，把设计师从“画图工”里解放出来，用 AI 当作“精英放大器”来放大人类员工的带宽。等等。
这里，在对数字员工进行度量和管理时，《CIO 之问》讨论出有几个原则：首先，AI 服务于真实、具体、可验收的任务。第二，AI 的价值需要 E2E 业务价值的指标来度量。再者，组织关系和管理模式也需要随之调整。
图 9: AI 数字员工的管理要点（图片由 AI 理解生成）
当这些基础问题理顺之后，随着数字人应用场景越来越多，人机协同矛盾将不断扩大：哪些任务该交给 AI，哪些仍需保留给人类？如果没有想清楚这个问题，很容易在组织内部引发群体恐慌。
《CIO 之问》的第八问，探讨的正是群体恐慌下的管理之道。
CIO 八问：企业如何抚平“AI 代替”的群体恐慌，推动组织转型 ？
在这轮 AI 掀起的风暴中，全球科技行业关于裁员的消息愈发猛烈。
今年 2 月，美国知名金融科技公司 Block 宣布计划裁员 40%，员工规模从 1 万人缩减至 6000 人以下。该公司创始人杰克·多西在致股东的一封信中提到，AI 工具是此次裁员的原因。“核心逻辑很简单，智能工具已改变了创建和运营一家公司的意义。”
据路透社今年 3 月报道，Meta 也在酝酿一轮前所未有的大裁员，裁员比例可能高达公司总人数的 20% 以上。按照 Meta 在 2025 年底公布的约 7.9 万名员工总数来算，这场裁员意味着将有大约 1.6 万人失去工作。
AI 冲击的不仅是普通员工，也包括 CEO。今年 3 月，担任 Adobe CEO 长达 18 年的 Shantanu Narayen 宣布将在找到继任者后卸任 CEO 一职。有分析人士指出，Adobe 近年来被市场视为“AI 时代的落后者”，尽管 Narayen 曾带领 Adobe 完成向订阅制的成功转型，但在生成式 AI 浪潮中，投资者对其战略方向和创新能力产生严重怀疑。
这些新闻在企业内部，往往会引发另一种情绪，一种越来越普遍、却又难以公开讨论的焦虑：AI 究竟是增效工具，还是“裁员利器”？硅谷的精简叙事是否会复制到中国？
事实上，AI 替代已经是一个公开的秘密，每个人都心里在想，它什么时候会发生。
面对这种群体性担忧，答案或许就藏在企业组织的 金字塔结构变化里。传统的金字塔结构是一个正三角，当 AI 接管金字塔底部那些人的“真实任务”后，组织结构会发生深刻变革——金字塔底的工作几乎全部用 AI 替代，形成精英工作制，精英核心角色也许有两个：高价值工作者 + AI 训练师。
《CIO 之问》还给出进一步的探讨内容：
金字塔虽然不会彻底消失，但它的“含人量”会发生结构性的重组：金字塔底层的大量重复性知识任务，会首先被数字员工接管；中层的管理幅度会发生变化，比如过去一个主管管理 10 个人，现在可能需要管理 3 个人和 7 个数字员工，对主管的能力要求也更高了；顶层的精英短期内不会被替代，但他们的工作方式会发生变化，人的价值集中在“判断力”和“品味”上。
总之，金字塔的形状会变：底部收窄、中部变薄、顶部对能力要求更高。当然，成熟的大型组织金字塔会是渐进式的收缩，而非颠覆式的重构。
在此之上，人与 AI 的协同关系也会发生变化。要想理清这种协同关系，可以从 Copilot 和开发者两个维度来看待问题。
从 Copilot 维度来看，AI 数字员工作为辅助工具，相当于提升了一个人的产出效果和产出量。从组织管理的角度看，这或许不算 credit，也不算拓展了 HC。以阿里云 CIO 团队的电话外呼数字人为例，它属于售中辅助，并没有因此减少一个人力编制，只是同样的任务做得更好了，通话轮次多了，客户满意度也增加了。组织的核心能力并没有本质变化，只是同样的人做事比原来更靠谱了。
从开发者维度来看，以某大型企业的观察，内部使用 Cursor 后，开发人员的产出并没有明显增加，不少人反而开始“摸鱼”。也有管理者提出，应该给开发人员额外增加 20% 的工作量。这背后是一个管理逻辑。
如此来看，人和 AI 数字员工的关系，本质上不是一个“谁替代谁”的问题，而是一个“知识员工”的质量与管理命题：AI 释放出来的时间和精力，能不能被有效地重新投入到更有价值的任务中去？一个工程师带 5 个数字员工是否可以晋升高级工程师？数字员工的 AI 赋能后，怎么去评判真实员工的 KPI 完成度？……真实的课题还是要留给企业管理者。
图 10: 金字塔的“含人量”结构化重组（图片由 AI 理解生成）
当企业逐步从“AI 替代”的恐惧走向“AI 协同”的组织策略时，IT 与业务之间的张力便愈发难以回避。《CIO 之问》的第九问，试图理清的就是 IT 与业务之间的矛盾与融合。
CIO 九问：AI 时代的组织权责：IT 与业务，缘何矛盾？怎样融合？
IIoT World 与 HiveMQ 今年 1 月联合发布的一份数据报告显示，跨职能部门的协调不力正在扼杀 AI 项目。在一篇报告的解读文章中，作者描绘了一个极具代表性的会议场景：
OT 总监刚经历一场由软件更新引发的生产危机，要求新系统远离生产网络；IT 负责人担心数据治理，上一个试点项目把未经验证的传感器数据直接推给云端模型，既无访问控制也无模式规范；数据科学负责人已经等了八周才能访问六台压缩机的振动数据——数据存在，但被 OT 控制，由 IT 管理防火墙，双方都没有文档记录。三个人都对，但项目寸步难行。
那篇报告的作者将这种现象定义为 “组织摩擦”，并直言：这是工业 AI 项目的无声杀手。
这种矛盾不是个别现象，AI 在企业里全面开花，但企业里的 IT 部门和业务部门，似乎比任何时候都更具对抗性。表面上看，AI 是工具，实际上，它放大了长期存在的摩擦：谁做“蛋糕坯”，谁做“樱桃”的矛盾被无限放大。有技术管理者更是直言：“我们做蛋糕坯的，经常被做樱桃的人挑战。”
两个团队的这种对抗，几乎是流淌在毛孔里，但影响的是最终的樱桃蛋糕越来越难。
原因很简单，当下的智能化阶段，创造了一定程度的技术平权，业务团队也能自己搭建简单的数字员工、AI 应用和自动化流程，用 demo 快速展示成果；而 IT 团队依旧要背负基础系统的稳定、数据安全和隐性责任，却总是不容易被看到。交流中，有的 CIO 甚至苦笑发问：“ IT 部门该如何让业务部门明白，他们做出来的 demo 和系统性做出来的，是不一样的！”
由此，甚至萌生出一种叫做“ITBP”（ IT Business Partner）的新物种岗位，来尝试化解业务与 IT 部门的冲突。
回过头看，阿里云 CIO 发现，这依旧不是 AI 时代带来的新问题，而是历史中本就存在的老问题，只是在 AI 时代被无限放大。从企业信息系统发展的历史来看，信息化到数据化再到智能化，本质都是如何用信息技术去帮助业务提效、创新。这中间牵涉 三种角色：第一种角色叫做“业务”的物理世界；第二种角色是所谓的“产品经理”，把业务物理世界的语言，翻译为 PRD；第三种角色是“研发”团队，把 PRD 这个自然语言再翻译成 Java 或者 C 代码。
很多人以为，第二次翻译——从需求到代码——才是技术难点。但是，真正的瓶颈往往出现在第一次翻译：现实业务与系统需求之间的映射。业务与 IT 的协同本质上是“翻译”过程，一般情况下，是个单向道关系，如果技术不往“业务”多去理解，科技与业务是永远衔接不上的。
《CIO 之问》探讨认为，要想解决业务与 IT 断层，需要的是“双语人才”，这也是 ITBP 的真正价值，这在当下尤为关键。
从企业 IT 系统的变化来看，可以更清晰地理解这一角色的必要性。从第一轮信息系统的在线化，到第二轮数据中台的数字化，再到第三轮的智能化，特征都是将企业物理世界中的业务语言，翻译成 IT 系统能够理解和执行的语言。如此看来，业务与 IT 的协同，本质上是“翻译”过程，需要既懂业务又懂技术的复合型人才，用双向语言弥补掉“翻译”链条上信息丢失造成的协作困境。
图 11: IT 与业务的对抗性与融合路径（图片由 AI 理解生成）
当 IT 与业务之间的矛盾逐渐化解、协作步入正轨之后，AI 的工具高速迭代也在配合这种组织的提效演进，但 AI 究竟能在多大程度上提升生产力，这是单纯的 AI 技术驱动，还是要回归到软件工程的老问题？
《CIO 之问》的最后一问，来做探讨。
CIO 十问：AI 推动的“10X”研发效能，真相如何 ？
“AI 让研发效率提升 10 倍”——这是过去一年技术圈最诱人也最危险的叙事。
AI 编程工具热度始终不减。从各类代码助手密集发布，到 Vibe Coding 掀起氛围编程热潮，再到崇尚技术规格的 Spec-Driven 大火……新词与 100 倍、1000 倍的提效案例齐飞，让研发领域格外热闹。
今年 2 月，前谷歌、亚马逊资深工程师 Steve Yegge 在《The Anthropic Hive Mind》博文中，揭示了一个惊人事实：Anthropic 的工程师，按核心功能迭代速度、代码产出质量综合测算，效率是如今使用 Cursor 和聊天工具的工程师的 10 到 100 倍，大约是 2005 年谷歌员工的 1000 倍。
弗雷德·布鲁克斯关于软件工程管理的奠基之作《人月神话》，提到的开发人员之间的生产效率差异还只是 10 倍，如今，“1000x 程序员”似乎已经成真。
但在企业的真实落地中，情况往往比较“骨感”。撇开泡沫去挖掘内核就会发现，Vibe Coding 同时也是垃圾代码高速生产器，甚至让技术团队“死”得最快。至于 Spec-Driven，它的本质是拉通、对齐、左移，Spec 正是那个拉通对齐的核心锚点。于是，问题又回到了原点：Spec 变成了知识工作，这个 Spec 写得好不好、对不对，需要精英员工去跨职能度量。
也就是说，无论企业怎么围绕 Spec 做文章，最终指向的都是同一个逻辑——精英前置。需要由精英在前面解决 Spec，同时，后面也不能完全交给 AI 去 coding。代码中大约有 20%-30% 的核心部分，必须经过人的调整和把关之后，才能交给 AI 去执行。而这 20%-30% 的代码，往往恰恰是整个系统中最难的部分。
如果把互联网应用的开发工作拆开来看，会发现真正在写代码的时间其实只占 20%。这 20% 的编码时间里，真正复杂的业务逻辑代码又只占 20%——也就是说，真正 AI 难以替代的“硬骨头”，只占整体工作量的 4% 左右。剩下的 96%，都是简单重复的代码、注释文档、概念验证之类的脚手架工作。AI 能替代的恰恰是这些。
但问题是，即使代码采纳率高达 80%，最后的人月效率却可能毫无变化——因为那 80% 的非编码时间（需求讨论、方案设计、沟通对齐、测试返工），AI 一点都省不掉。
从这个角度来看，报告给出的观点是，Spec-Driven 的确是一条比较难走的路，它高度考验的是一个团队“精英化”的软件工程能力，也就是在“左侧”，一次把事情做对的规划能力，这本质上和 AI 没关系。
因此，企业需要重新审视“人月神话”——软件工程度量的复杂度，并不是简单的线性关系。过去在复杂的工程项目中，盲目增加人手反而会拉长工期；AI 时代更是如此，增加 AI 同样会增加沟通链路的消耗。
阿里云 CIO 实践中得出的结论是 ：实现研发效能提升，一定要用“同类的需求”，去看 E2E 的“人月消耗”是否能够减少。要解决掉这些真正的“人月效率”，从更深处来看，AI 能帮到的部分并没有想象中那么大，企业还是需要从根上出发，看待自己的组织架构。AI 并没有打破软件工程的基本规律，它只是把很多原本隐藏的问题提前暴露了出来。
此刻，每个技术管理者都可以反问自己，1000 倍的程序员诞生了，但企业的 “人月效率”变了吗？
这也呼应了《CIO 之问》后七问所揭示的 一个共同现实：在 AI 项目落地过程中，企业遇到的困难往往看似是工程难题，实际真正卡住的往往不是技术。 即便技术方案成型、工程能力补齐，但必要的基石跟不上，AI 依旧会在“最后一公里”熄火。
图 12: AI 在研发效能中的权重角色（图片由 AI 理解生成）
《CIO 之问》：
不是标准答案，是企业内镜
AI 落地从来都不是一个公式可解的题。因为每家企业的欠账不一样，每个 CIO 面对的组织土壤不一样。同样的 AI 技术，在不同企业里会长出完全不同的结果。这也是为什么，今天的大多数企业仍然若隐若现地停留在 AI 落地的迷雾之中。
于是，阿里云 CIO 团队尝试整理了这部《CIO 之问》报告，它绝不是一份数据堆砌的行业白皮书，是一次真正“局内人对局内人”的深度打捞：它不约束每个问题的标准答案，开放式的探讨让更多企业看清问题本身。报告中，阿里云 CIO 与来自十大行业 40 余家头部企业的同行展开长达数月的对话，以问答对撞的方式，打开那些鲜少被公开讨论的技术决策困境、组织博弈隐痛与认知误区。
报告的初衷，尝试做一件更本质的事情——照见外表看不见的现实，为企业提供一面“向内看的镜子”。
而它的起点，来自一个非常朴素的疑问。
在大模型时代下，阿里云定位为“全栈人工智能服务商”，作为阿里云 CIO，必须先蹚出一条路来，让 AI 在企业内部跑通。在企业内部推动大模型应用落地的过程中，经历了大量真实而复杂的困难，虽然这些问题最终都得到了解决，但这和外界很多近乎完美的 AI 落地叙事截然不同。于是，这位 CIO 心中产生了一个困惑：是不是只有他遇上这些坑？
带着疑问，阿里云 CIO 开启了这场对话之旅。过去几个月里，在与来自金融、零售、汽车、物流、消费电子、制造、能源、互联网服务、服饰等十大行业的大量 CXO 不断深度交流。话题天南海北：传统企业 AI 错过的恐慌、LLM 的能力边界、知识工程的困境、Agent 的落地、数字员工的绩效核算、业务与 IT 部门的对抗性、Vibe coding 的危险性、IT 系统的历史镣铐、AI 基础设施与应用建设的矛盾……
对话没有剧本，真诚又真实。
随着对话的深入和累积，阿里云 CIO 发现，自己不只是在找答案，更是在与一群同样困在 AI 落地迷雾中的同行人，相互取暖、相互校验、分享经验、共同成长。
在做这份报告的过程中，看到的是：越来越多的 CIO，开始愿意把自己踩过的坑讲出来，而不是只讲光鲜的成功案例；越来越多的企业，开始把“AI 数字员工能不能上岗接管一个真实任务”作为第一个考核点。
AI 大模型时代的 CIO，不该是孤独的技术管理者，而是推动企业有机会走出迷雾的同行者。这份报告的意义，如果能让更多人少走一段弯路，便已足够。
阿里云 《AI 大模型时代的 CIO| 企业智变下的 CIO 集体之问》完整报告即将发布，报告中会有多维的对话、鲜活的问题、真实的探讨、丰富的思考、认知的转折、共识的图谱，让读者带走各自所需。
正如这份纪实报告自述，这是一场没有预设终点的对话之旅，也是对后来者的邀请。
AI 的迷雾依然存在，但同行的人多了。
敬请关注，完整报告。
今日好文推荐
