阿里云赵洋谈云计算进入智能时代，企业该先押哪个方向

过去十几年，企业上云解决的多半是“能不能用”的问题。机房不用自己盖，服务器按需取用，业务要扩张也不必等硬件采购排期。现在大模型和生成式AI来了，问题换了个样子：数据有没有攒下来，算力能不能调得动，模型能不能真正用在具体业务里。

阿里云赵洋在一些公开场合提到，云厂商的价值正在从提供基础资源，转向提供能持续迭代的技术底座和行业方案。这个判断和行业里的普遍感受大体相符，对正在做数字化规划的企业来说，可以当作一个思考的起点。

【待核实：赵洋的具体职务、主要经历及引述内容，编辑时请以官方公开资料为准】

从资源上云到能力上云

阿里云成立于2009年，早期以弹性计算和对象存储起家。这些年，它的产品线从底层操作系统、数据库、中间件一路延伸到上层的AI平台，形成了比较完整的一条链路。对企业来说，好处在于可以按阶段挑服务，不必一开始就押注一整套复杂架构。不过产品多也意味着选择多，先想清楚自己卡在哪一步，比对着产品目录逐个研究更省时间。

一般来说，上云会经历三个阶段：

基础设施迁移：把核心系统从机房搬到云上，先解决资源弹性和容灾问题。迁移前后要留一份性能基线，否则搬完之后发现响应变慢，也很难说清原因。
数据与应用重构：打通各系统之间的数据孤岛，把原来的单体应用拆成可以独立部署的服务。这一步最耗时，常见做法是先拆一个边界清楚的模块试点，而不是整体推倒重来。
智能化升级：数据和流程稳定之后，再引入大模型，用在客服应答、质检抽检、营销文案这类有明确输入输出的场景里。

三步之间并不是严格的先后关系，有的企业会在迁移的同时就做局部智能化。但如果数据质量差、接口五花八门，就跳过前两步直接上智能应用，结果往往是模型能跑，效果却不稳定，业务部门很快就会失去耐心。

一个示例：零售企业的数据中台改造

以下是一个示例性案例，用来说明改造的思路。具体数据和细节需要在正式发布前核实，不能直接当作真实客户的经验引用。

设想一家区域连锁零售企业，会员系统、门店系统和供应链系统各自独立运行。同一位顾客在线上下单、到店消费的记录对不上，市场部门做完一次促销，很难说清楚到底是哪一批人买了单。企业在云端搭建统一的数据中台，把三套系统的数据按同一套标准汇聚起来，再通过数据服务接口开放给营销和选品部门。

改造之后，营销团队用统一的用户画像做分层触达，复购情况有所改善。更直接的变化是，业务人员不用再排队等技术团队取数，分析周期从原来的几天缩短到几个小时。这类项目的难点通常不在技术有多新，而在前期要花不少时间和各部门谈清楚“订单”“会员”“有效顾客”到底怎么定义。口径统一了，后面接入智能应用才有意义。

企业选型时可以先问的几个问题

在比较云服务商和技术方案时，下面几件事最好在签约前想清楚：

数据安全与合规：列出哪些数据必须留在境内，哪些人可以访问，访问行为是否有审计日志。金融、医疗行业尤其要把这些写进需求文档，不要等到上线前的安全评审才想起来。
迁移成本与锁定风险：确认数据导出格式是否开放，接口是否遵循常见标准。可以要求供应商给出一份数据迁出的操作说明，看看写得是否具体。
团队能力匹配：云上的运维、开发和数据工程要同步建设。工具买回来，如果没人会配置权限，也没人会看监控告警，大概率还是会闲置。
业务价值验证：每个阶段定一个能量化的目标，比如单位计算成本的变化、故障恢复所需的时间，或者某个活动的转化率。目标写得越具体，越容易判断这一步值不值得继续。

对大多数中小企业来说，更稳妥的做法是从一个价值高、边界清楚的场景切入，比如一份重复性强的报表，或者一条客服咨询链路。跑通了，积累下数据和经验，再逐步扩展。一开始就想全面上云、一步到位做智能化，投入往往会超过实际收益，团队也容易在中途泄气。