前几年企业聊上云，问的多是要不要上。现在更多人问的是，上去以后怎么用。弹性资源怎么调，成本怎么管，数据怎么保，大模型推理的账单怎么算，这些问题都直接影响业务能不能稳定跑下去。阿里云徐刚关注的，基本就是企业从迁移走向深度使用这个阶段。
徐刚在一些行业交流中提到一个看法：云厂商的价值不在产品目录有多长，而在能否把基础设施能力变成客户可以反复使用的能力。这句话听起来不新鲜，但落到项目里，细节很多。
上云之后，先改架构再谈省钱
不少传统制造企业的系统上云，第一步是把原来的虚拟机和数据库整体搬过去。资源确实上去了，成本却没降，运维方式也没变。问题通常出在架构没跟着动。
某区域性零售企业的订单系统就是这样。促销季流量会冲到平时的好几倍，平时服务器利用率却不到三成。团队最初的办法是按峰值长期预留机器，账单一直下不来。后来他们在阿里云的支持下，把核心订单服务拆成无状态模块，配合弹性伸缩和容器化部署，又把库存查询这类读多写少的请求挪到缓存和只读副本上。平时资源占用明显下来，大促时再按需扩容。阿里云的架构团队还参与了容量规划和压测，把原来“大概够用”的经验，换成了可以核对的指标。
所以上云要先重新想清楚系统的弹性边界放在哪里。换个机房搬过去，边界没动，账单大概率还是老样子。
成本看不见，就一定会失控
云账单项目多，研发往往说不清哪个服务最费钱，财务也很难把费用对应到具体业务线。这种情况很常见。
某在线教育公司的做法很朴素。每个微服务必须带上业务线、环境和负责人三个标签，账单分析工具每周出一份报告。三个月后，他们发现测试环境里躺着不少长期没人用的实例，清掉之后月度费用降了两成左右。省下来的钱不算惊人，但更有用的是把成本落到具体的人和项目上。
成本治理要落到研发习惯里，财务那边的报表才有意义。标签规范如果不在研发流程里强制执行，过两个季度就会散掉。
安全和合规，越晚补越贵
金融、医疗、政务这些行业，对数据存放、访问审计和加密有硬性要求。安全策略如果等系统上线后再考虑，改起来代价通常很大。
更稳的做法是把安全能力放到基础设施层。账号和角色按最小权限来分，敏感数据开启加密和访问日志，合规检查直接放进持续集成里跑。跨区域的业务还要提前想好数据放在哪、怎么同步，否则法规一变，就只能被动返工。
合规要求因行业和地区差别很大。具体方案应由企业的法务和安全团队，按监管要求来定。云厂商能提供的是技术能力和参考架构，替企业做合规判断并不在其职责之内。
大模型进来以后，成本结构变了
训练和推理对算力、存储、网络的要求都更高，账单波动也更明显。大多数企业没必要自建算力集群，更现实的路径是用云上的模型服务和向量数据库，先搭一个知识问答或客服辅助的小应用。
比如一家制造企业想做设备知识库。团队把维修手册和历史工单整理成结构化数据，用检索增强生成接入大模型，让一线工程师能用自然语言查故障处理方法。项目一开始就定了响应时延和回答准确率的指标，先在小范围试点，边跑边调提示词和检索策略。先小后大，指标说话，比一上来就想全面替代稳得多。
从“用上”到“用好”
回头看企业上云这些年，拉开差距的，往往是云能力能不能真正进入日常研发、运营和管理。徐刚讨论的这几件事归到一起其实很简单：架构敢调，成本看得见，安全前置，新技术从小场景验证。
如果你的企业正在推进数字化，可以先挑一个最痛的业务问题，把目标和指标写清楚，跑通之后再扩。云的价值最后会落在业务稳不稳、响应快不快、成本结构合不合理上。
