规模化企业 AI，先复制治理能力，不要复制工具数量

在一个非特定企业情境中，第一个 AI 场景刚刚通过验证，组织很容易形成一种冲动：既然一个部门能用，就给所有部门各做一个；既然一个助手有效，就把同样的工具快速铺开。几个月后，应用数量上升了，组织却面对更多数据副本、冲突口径、重复接口、无人维护的提示词和不清楚的责任边界。看起来在规模化，实际是在规模化偶然性。

企业 AI 的规模不应由助手数量、账号数量或模型调用量定义。**真正的规模化，是新增一个场景时，单位诊断、连接、治理和验证成本持续下降，同时风险没有随使用范围失控增长。**这要求企业复制经过验证的公共能力与交付方法，而不是复制某个试点的界面。不同场景可以有不同流程，但身份、对象、来源、权限、评估和审计应形成稳定底座。

为了让“新增一个场景”可审计，本文把场景单位定义为：一个明确业务对象、一项触发条件、一位决策所有者、一组有边界的可选动作，以及一个可回收的结果信号。处理采购订单逾期与处理合同例外是两个场景；为同一场景增加一个展示页面不是新场景。只有边界稳定，跨期成本才有可比意义。

试点成功为何会在复制时变形

试点往往依靠一小群人密切协作。业务专家随时解释术语，技术人员手工清洗数据，负责人亲自审核结果，异常也能在群聊中解决。这种“高关注环境”掩盖了许多隐性成本。一旦扩展到十个部门，原先靠个人记忆维持的上下文无法等比例增长。

复制还会把局部定义带到错误的地方。销售中的“客户”可能指商机主体，财务中的“客户”可能指结算实体，售后关心的是设备与服务关系。若把一个场景的客户字段直接当作全企业标准，系统会在表面统一下产生判断偏差。相反，若每个部门都重新定义，跨部门流程又无法连起来。

第三个原因是价值与风险扩张速度不同。一个只读知识问答的错误影响有限；同一能力连接邮件、审批和 ERP 写入后，错误会快速传播。企业若只扩展功能，不扩展权限控制、监控和事故响应，就会让行动半径超过治理能力。

一核两环扩张模型

“一核两环”把规模化拆成公共能力核、场景交付环和组织学习环。

公共能力核承载不应被各部门重复发明的部分：企业身份与最小权限、关键业务对象及其关系、可信知识来源、系统与数据连接、模型与提示版本、评估样本、审批、日志和成本观测。公共能力核不是一个大而全的平台项目，而是一组随场景沉淀、可被明确调用的契约。每项能力都要有负责人、服务边界和变更规则。

场景交付环负责把公共能力装配进具体流程，依次经过业务诊断、方案设计、最小验证、系统建设与运行复盘。它必须从一个决策单元开始，例如“处理一张逾期采购订单”，而不是“建设供应链智能”。输入包括现行流程、对象、参与者、例外和风险；输出包括可操作建议、人工权限、写回动作和效果信号。

组织学习环负责把场景经验送回公共能力核。每次上线后，团队应区分三类结论：只适用于该部门的规则、可推广到相邻场景的模式、应成为企业底线的控制。组织学习环还要负责淘汰无效应用、合并重复资产、更新评估样本。没有退出机制，规模化最终一定变成存量负担。

两个环的节奏不同。场景环追求在决策窗口内验证价值，学习环追求跨场景的一致性和长期可维护性。用同一审批节奏管理两者，可能让试点过慢或让公共变更过快。企业应允许低风险场景快速实验，但任何进入公共能力核的对象定义、接口与权限模式都要经过更严格审查。

用“复用梯度”判断该统一到什么程度

不是所有东西都值得平台化。可以把资产按复用梯度分为四级。第一级是一次性探索物，只在沙箱中存在；第二级是场景组件，由单一业务域维护；第三级是跨场景能力，需要清晰接口、文档和兼容策略；第四级是企业控制，包括身份、权限、审计和关键主数据，必须统一治理。

升级一级，应提供一级证据。一个提示模板被两个团队复制，并不自动成为公共组件；它需要证明输入边界稳定、输出可测试、负责人明确。一个业务对象要成为企业级定义，则要经过相关部门对标识、生命周期、权限和冲突处理的共同确认。平台化的门槛越清楚，团队越不会在“全部集中”和“各自为政”之间摇摆。

场景成本台账：让第二次交付证明复用

规模能力不靠项目清单证明，而靠一张逐场景维护的成本台账。每个场景从范围获批到稳定运行，分别记录基线、增量成本、共享成本分摊、运行成本和退役责任。

**基线必须同口径。**团队以场景单位中的业务对象为分母，记录现有决策周期、参与工时、错误与返工、例外率、质量和风险事件。比较前后时保持业务量、风险等级和观察窗口可解释；若流程或需求结构同期变化，就单独标注，不能把差异全部算作复用收益。

**增量成本必须归全。**诊断访谈、数据清理、对象映射、连接器、知识与规则、模型配置、界面和系统写回、安全评审、培训与流程变更都进入建设成本；模型调用、基础设施、人工复核、监控、事故处理、维护与退役进入运行成本。临时专家支持和手工导出也要计入，不能因为没有采购单就视为免费。

**共享成本要有分摊规则。**身份与审计等固定底座可按活跃场景分摊，模型和基础设施按实际消耗，专用连接器按受益场景或业务域分摊；企业也可以选择其他驱动，但必须事先记录并跨期一致。把第一场景承担的公共建设全部留在首个项目、后续场景只记边际软件费，会制造虚假的成本下降。

台账同时保留两个指标：“新增场景交付成本”是该场景从获批到稳定运行的全部增量成本及应分摊共享成本；“对象运行成本”是稳定后每处理一个订单、合同或工单的持续成本。前者检验复制能力，后者检验运营经济性，两者不能混为一个平均数。

第二个相邻场景是最有价值的审计样本。评审不问是否复用了代码，而问哪些对象、权限、连接、评估与运行机制无需重新发现，复用节省了什么成本，又引入了什么适配负担。若换一组人员后仍依赖口头解释或临时群聊，台账应把这部分显性成本记回，而不是宣布平台化完成。

发布门槛也进入台账：业务所有者、数据来源、权限表、关键评估、人工接管、日志和退役条件缺一项，场景就未达到“稳定运行”，不能提前停止计费。长期没有责任人、没有使用或无法说明价值机制的场景，应被退役并记录退出成本。

四种“伪规模化”

第一种是许可证规模化：账号覆盖很广，但关键流程没有改变。第二种是演示规模化：每个部门都有 POC，却没有任何一个进入可维护运行。第三种是自动化规模化：连接了越来越多动作，却缺少统一权限和事故处理。第四种是平台规模化：先建设庞大底座，迟迟没有真实场景检验，最终公共能力只是技术假设。

还有一个重要边界：公共能力越强，并不意味着业务差异越少。合同义务、设备维护和客户服务拥有不同证据与责任，不能为追求复用而压成同一流程。企业应统一能够降低风险和重复成本的部分，保留构成业务判断的差异。

扩张决定要看下一场景是否真正变便宜

企业真正需要的，不是更快生产更多 AI 应用，而是更快识别什么值得建设、什么可以复用、什么必须受控、什么应当停止。扩张前应比较同等级场景的完整交付成本、对象运行成本、决策结果和风险，而不是展示发布数量。

如果新增场景仍要重新定义对象、重做权限、手工搬运数据和依赖同一批专家，单位成本没有下降，企业只是并行了更多项目。只有台账证明复用降低了可比成本，同时质量和控制没有恶化，才有理由进入下一轮扩张。

Luminent 会用场景成本台账区分可复用的平台投入与业务专属的交付成本，让企业在转型路线中依据下一场景的真实边际代价安排扩张顺序。