这家公司是谁：业务账决定了需求形状
联通华盛是中国联通集团的全资子公司、二级公司，去年营收数百亿元，员工超过 1500 人，采用三级架构垂直领导。陈丰伟分管产品、渠道、财务、数字化与科技创新五个领域。
他给公司算的「业务账」是理解这次落地的起点：一年客户订单数百万单，物流交付数百万次，银行对账数十万笔，发票数十万张。这四组数字决定了这家企业的智能体需求不是「写点文案」，而是高频、跨系统、规则明确的事务处理。订单、发货、对账、开票——每一环都在多个系统之间搬运结构化数据，每一环都有明确对错标准。这类工作的共同特征，后来被他们自己总结成三条：数据结构化、工作重复、可以做成 Skill。
本文全部事实来自 2026 年 10 月 19 日《中国经营报》旗下中经 TMT 对陈丰伟的公开报道。所有效率数字均为企业方陈述，无第三方审计、无基线测量方法披露、无对照组。文中出现的「效率提升十几倍」「重复性工作提升约 10 倍」等表述，均为受访者的自我估计。本文在引用时逐条标注口径，不将其等同于可复核的 ROI。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
三年时间线：从不敢用到能用
陈丰伟把这条时间线讲得很具体，它解释了为什么这家公司的智能体落地发生在 2026 年而不是更早。
| 时点 | 状态 | 卡在哪 |
|---|---|---|
| 2022 年 | 接入大模型做管理类统计分析 | 并未介入生产运营 |
| 2025 年末 | 智能体陆续出现，但都在云上 | 企业不敢把数据放到云上 |
| 2026 年内 | OpenClaw 可端侧部署 | 开源需要不断升级，维护成本高 |
| 2026 年 3 月起 | 腾讯推出 WorkBuddy | 企业开始真正思考智能体如何与数据与生产流程结合 |
这条线的关键不在产品对比，而在卡点的性质变化：2022 年卡在能力，2025 年末卡在数据合规，2026 年初卡在维护成本，到 3 月之后才同时满足「不出口数据」与「不用自己养工程团队」两个条件。对大多数国企与大型传统企业来说，这三个卡点的顺序大体相同——先解决数据不出域，再谈场景。
什么是「欢乐模式」：不强制、不规划、管够 Token
这套打法的名字来自陈丰伟本人，原话是「个人欢乐，公司也欢乐」。拆开看是三条相互支撑的做法。
- 不强制使用。没有规定哪个岗位必须用哪款工具，全靠口口相传。
- 不一次性规划采购。账号采购不是立项时定死，而是「不够用了再买」，从 100 个、200 个、300 个逐步滚到约 600 个。
- Token 管够但公开。花钱公司报销、需要 Token 公司给账号；内部管理方式是在公司内网张榜公示每个人用了多少。
三条里最难复制的是第三条。它同时解决了两个相反的问题：管够解决了「不敢用」，公示解决了「乱用」。陈丰伟的账算得很直接——公司是数百亿元营收的企业，在一款终端上提高的效率、减少的库存、节省的钱，远远超过 Token 投入。
他对定位的表述也值得记下来：「我们也没说智能体替代人，它只是替代人的工作。」在他看来，智能体是「放大人的特长」，每个员工都做自己岗位的 Skill。这个措辞在内部沟通中很重要：把对象从「人」换成「工作」，抵触会小很多。
三笔账：开票、IT 需求、重复性工作
公开报道里能被量化的主要是三笔账，各自的性质不同。
| 账目 | 改造前 | 改造后 | 性质 |
|---|---|---|---|
| 财务开票对账 | 31 个省份财务人员每人每月 1 天；另有 50 余名业务人员每月 1 至 2 天做报账结算 | 1 人结合 RPA 工具处理全国开票、配票、对账，2 天完成 | 人力替代，可直接折算人天 |
| IT 开发需求 | 各业务部门每月提大量需求，一个需求短则一个月、长则三个月 | 数字化部只提供数据接口，业务同事自己搭工作台，报表随时可改 | 排队周期消失，难以直接定价 |
| 重复性工作 | 基于约 100 个案例的总结 | 效率提升约 10 倍；特征为数据结构化、工作重复、可做成 Skill | 抽样自评，无统一口径 |
三笔账里，开票那一笔最硬，因为它的基线是人数乘天数，可以折算。IT 需求那一笔更值钱但更难算——90% 的 IT 开发需求被 Token 替代，这个数字的口径是陈丰伟的判断而非工单统计；但它指向的收益类型很关键：真正消失的不是开发工时，而是需求排队本身。一个业务部门等三个月才能拿到报表，与当天自己改出来，两者的价值差远超出人力成本的范畴，而这部分在传统 IT 预算里恰恰是无法定价的。
口径辨析：同一笔账的两个版本
同一篇报道里，开票这笔账出现了两个版本，必须同时摆出来。
报道导语的说法是「财务开票从 31 个省 31 人各花 2 天，变成 1 人 2 小时」；正文的说法是「原先 31 个省份的财务人员每人每月需耗费 1 天完成开票对账，50 余名业务人员每月需耗费 1 至 2 天完成报账结算；引入之后仅需 1 人结合 RPA 工具处理全国开票、配票、对账，2 天即可完成」。两个版本的基线（每人 2 天对每人每月 1 天）与结果（2 小时对 2 天）都不一致。按导语口径折算，压缩到约 0.4%；按正文口径折算，压缩到约 6.5%。两者相差约十六倍。本文倾向以正文为准，因为它给出了完整的参与角色与周期单位，且明确提到新方案是「1 人结合 RPA 工具」，而 RPA 本身的贡献没有被单独剥离。无论采用哪个版本，都要注意：RPA 与智能体共同完成了这件事，收益不应全部记在智能体名下。
本文按正文口径再往前算一步。若把 50 余名业务人员的报账结算也计入基线，按月计算的下限为 31 人天加 50 人天，共 81 人天；改造后为 2 人天，压缩比约 2.5%。年化约为 972 人天降至 24 人天，年省约 948 人天，按每天 8 小时折算约 7584 小时。需要强调三项假设均未披露：改造后的 2 天是否已覆盖原本的报账结算环节、每月连续执行是否成立、以及这里的「人天」是否按满负荷 8 小时计。因此这组数字只能作为量级参考，不能作为 ROI 结论。
四个阶段：他们说自己走到哪了
陈丰伟把智能体为企业运营服务分成四个阶段，这个划分比多数成熟度模型更贴近落地现实。
| 阶段 | 特征 | 关键约束 |
|---|---|---|
| 阶段一 | 用现有数据做多任务操作，提升单点效率 | 智能体需要与人紧密结合，不允许它独立完成一项工作 |
| 阶段二 | 某几项工作全流程端到端由智能体完成 | 要求流程边界清晰、结果可核验 |
| 阶段三 | 某些部门、岗位全面智能体化 | 会带来组织机构的变化 |
| 阶段四 | AI 原生组织 | 未见公开定义 |
他的判断是：「现在我们公司应该处在阶段一向阶段二的转型当中。」这句话的分量在于它给出了一个诚实的位置。大量企业的公开材料会把试点描述成规模化，而这份自述明确承认还在跨第二道门槛之前。阶段一里那条「不允许它独立完成一项工作」的约束尤其值得注意——它不是保守，而是阶段定义的一部分：单点提效阶段，人必须在环内。
T-1 备份：用数据新鲜度换数据不出域
国企谈 AI 绕不开数据安全。联通华盛的做法被陈丰伟自己称为「笨办法」，但它是整个案例里工程价值最高的一环。
具体做法是：生产流程仍由原有的数字化系统支撑，每晚把 T-1（昨日 24 点前）的数据全量备份到一个独立数据库，智能体只在这份备份上做提效。开发票不要求上一小时的需求在这一小时就开完，把截至昨晚的客户需求处理完即可。这套方案目前已覆盖 90% 以上的场景。
这个方案的实质不是加密、不是脱敏，而是一次显式的权衡：用数据新鲜度换数据不出域。它之所以有效，是因为它把「要不要实时」从一个笼统的安全争论，拆成了逐场景可判定的问题——哪个场景能接受 T-1，哪个不能。报道称覆盖了 90% 以上场景，反过来说明剩下不到 10% 才是真正需要解决的数据合规硬骨头。陈丰伟自己的表述也很直接：这是「云侧模型智能体加企业数据安全问题还没完全解决时的中间方案」，在安全与效率之间，选择先行动起来，而不是等一个完美方案。对同类企业来说，先列出各场景的时延容忍度清单，比等待一个通用合规方案更有可能推进。
把 Skill 写进制度：数字员工与效率工具的分界线
报道里有一个容易被当成花絮的细节，实际上可能是这个案例最重要的信号：公司不少制度流程在修订时，已明确写入「某个动作使用哪个 Skill 来操作」。审发票、审单据、审付款依据等相关 Skill 已正式写入企业管理制度，全国 100 余名财务人员实现工具全覆盖。
这件事的意义在于：Skill 从个人经验变成了合规对象。此前智能体在企业里的典型形态是个人效率工具——某人自己攒了个提示词，好用，但换个人就断了，也不在任何审计范围内。一旦写进制度，Skill 就有了责任人、有了版本、有了适用范围，也就进入了可以被检查、被追责的范畴。陈丰伟的原话是：「过去的规章制度是写给人看的，未来的规章制度是写给智能体看的。」
本文据此判断：Skill 是否进入正式制度，是「数字员工」与「个人效率工具」的分界线。前者能被组织承接、能被审计、能随制度修订而演进；后者随人员流动而消失。这条判断不依赖具体产品，任何企业都可以用它来检验自己的智能体落地到了哪一层。
负责人自己怎么用：两个定时任务
陈丰伟本人的用法更像一个「AI 原住民」，这为内部推广提供了示范样本。他给自己开发了两个定时任务：其一是关注 eSIM，要求智能体每天找出 eSIM 类的 10 个头部话题并给出操盘建议，每天 8 点前推送到飞书；其二是「终端比价」任务，把前一天降价涨价幅度 10% 以上的产品做比价推送。
这两个例子的共同点是：触发方式是定时而非提问，产出落在他已经在用的工具里，且任务边界由明确阈值定义（10 个话题、涨跌 10%）。相比之下，「对着它不知道要干什么」的员工缺的正是这种具体的任务定义。这也解释了他那句判断——「AI 技术可以普及，但是 AI 思维不会普及」。他还区分了两类工具：生成式工具不能做跨任务调度，智能体最重要的是跨任务，可以帮你完成一个复杂的过程。
六步打法：从零到六百个账号
把公开信息重排成可执行的顺序，得到下面六步。这套顺序的前提是已有可用的企业级智能体产品与内部数据接口能力。
- 步骤一：先盘业务账，不盘技术栈。数清楚订单、交付、对账、票据这类高频事务的年量级，需求的形状由业务量决定，而不是由模型能力决定。
- 步骤二：先解决数据不出域。用 T-1 全量备份到独立数据库的方式，把「智能体能看到什么」与「生产系统」物理隔开，先跑通再谈优化。
- 步骤三：列出各场景的时延容忍度清单。逐场景判定能接受 T-1 还是必须准实时，能接受的那部分即可立即开工。
- 步骤四：选一个能折算人天的场景做样板。优先选参与人数与耗时都可数的流程，例如开票对账，这样基线与收益都能算清。
- 步骤五：把跑通的 Skill 写进制度。明确责任人、版本与适用范围，让全国或全公司的人员实现工具全覆盖，而不是停留在个人使用。
- 步骤六：Token 管够加用量公示。采购按需追加而非一次定死，同时在内网公开用量，用透明替代审批。
三条红线与避坑清单
结合公开信息与同类案例的常见失败模式，这份打法里至少有三条不能越过的线。
- 红线一：阶段一不允许智能体独立完成工作。在单点提效阶段把人摘出回路，一旦出错没有兜底，且会一次性击穿内部信任。这条约束来自企业自身的阶段定义，不应提前解除。
- 红线二：不要把 RPA 的功劳记给智能体。开票这笔账明确是「1 人结合 RPA 工具」完成的，两者贡献未做剥离。做内部复盘时若不拆开，后续预算分配会失真。
- 红线三：不要把账号数当成渗透率。600 个企业版账号加上个人版超过一千个，这是采购与开通口径，报道未披露日活或月活。账号增长靠口口相传是好事，但要衡量真实渗透必须另设活跃度指标。
另有三条需要提前想清楚的保留事项：其一，覆盖 90% 以上场景的 T-1 方案是中间方案而非终局，剩下不到 10% 的场景需要另行设计；其二，「效率提升十几倍」「重复性工作提升约 10 倍」均为自估，缺少测量方法；其三，阶段三会带来组织机构变化，这一层尚未见有任何公开准备动作。
综合判断
这个案例的价值不在数字最大，而在路径最像大多数企业能走的那条。它没有大模型中台、没有统一智能体平台、没有强制考核，靠的是三件朴素的事：把数据不出域用 T-1 备份这个笨办法先解决掉、选一个能折算人天的场景把账算清、然后把跑通的 Skill 写进制度。
其中最值得借鉴的是 T-1 这个选择。它把一场通常会拖上一年半载的数据安全争论，转化成了一份逐场景的时延容忍度清单，90% 以上的场景因此立即开工。这个思路不依赖任何特定厂商，任何企业都能照做。
需要同时保持清醒的是证据强度。全部数字来自企业方自述，同一笔账存在相差约十六倍的两个版本，RPA 与智能体的贡献没有剥离，账号数不等于活跃度，阶段划分与「欢乐模式」均为主观框架。本文给出的年省约 948 人天、约 7584 小时的推算建立在三项未披露的假设之上，只作量级参考。这套打法可以学，但学的是顺序与架构选择，不是那些倍率。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。