企业做 AI，到底应该先建平台，还是先做场景？

从预算、组织、复用与落地节奏出发，给出一套可执行的建设顺序

 做企业AI项目时，我经常听到两类完全相反的声音。

一类人说：“AI一定要统一规划，先把大模型平台、知识库平台、Agent 平台、算力平台都建起来，后面各部门直接用。”另一类人说：“平台都是虚的，先做几个能落地的场景，能用起来再说。”

这两种观点都不算错，但如果把它们当成非黑即白的选择，就很容易走向两个极端：平台建得很完整，却没有人真正使用；或者场景做了一堆，最后模型、知识、接口、权限和运维各自为政，重复投入越来越高。

所以，企业真正应该讨论的，不是“平台和场景谁更重要”，而是：在当前阶段，什么能力应该先建，什么能力应该等场景跑通以后再沉淀。

01 为什么企业总会陷入“先平台，还是先场景”的争论？

因为这背后其实对应的是两种不同的建设逻辑。

1）平台逻辑：先把公共基础能力准备好

平台派更关注长期复用。他们担心今天采购一个知识库，明天采购一个 Agent 平台，后天再买一套模型服务，最后形成新的“AI 烟囱”。因此希望从一开始就统一模型接入、知识管理、权限、审计、工具调用、评测和运营。

2）场景逻辑：先证明AI到底有没有业务价值

场景派更关注短期落地。他们会问：如果连第一个场景都没跑通，为什么要先投入大量预算建设平台？如果员工根本不用，业务部门也没有明确收益，再完整的底座也只是基础设施。

真正的问题是：企业AI既有“应用创新”的属性，又有“数字基础设施”的属性。场景决定AI有没有价值，平台决定价值能不能规模化复制。两者不是替代关系，而是先后节奏与投入比例的问题。

02 这4种情况，我更建议先从场景开始

1. 企业还处在AI探索期

如果组织内部还没有形成稳定的 AI 用户群，也没有跑通过可复制的业务场景，这时最重要的不是平台完整度，而是尽快找到“AI 真正能产生价值的地方”。

例如内部知识问答、智能问数、客服辅助、报告生成、研发助手、合同审核等场景，先挑1—3个业务痛点明确、数据基础相对成熟、用户愿意配合的方向做验证，比先建设十几个平台模块更有意义。

2. 预算有限，需要尽快看到结果

很多企业第一阶段预算只有几十万到一两百万元。如果把大部分预算都投入算力、平台、统一门户和复杂治理，真正留给业务场景的钱反而很少。项目验收时，管理层最容易问的仍然是：“到底解决了什么问题？”

预算越有限，越应该把钱优先放在可量化的业务闭环上。底座只做支撑当前场景所必需的部分。

3. 业务需求还在快速变化

大模型技术和企业需求都在快速变化。今天大家想做知识问答，半年后可能更关注 Agent和流程自动化；今天认为必须自建的能力，明年可能已经变成成熟云服务。

在需求没有稳定之前，把平台能力一次性做得很重，容易出现“技术方案锁死、业务方向变化”的问题。场景先行可以让企业用更低成本试错。

4. 组织协同机制还没有建立

企业AI的难点往往不只是技术，而是业务部门、信息化部门、数据部门、安全部门和供应商如何协同。如果连谁提需求、谁验收、谁运营、谁维护都没有明确，就先建设统一AI平台，很容易变成信息化部门单方面“建平台”，业务部门被动“来使用”。

这时更适合通过真实场景把协同机制跑一遍，让组织先学会如何做 AI 项目。

03 这4种情况，平台能力应该适当前置

1. 已经确定会同时建设一批AI场景

如果集团已经明确未来一年会落地十几个甚至几十个AI 场景，而且覆盖多个部门、子公司和业务条线，那么每个项目单独采购模型、知识库、权限和接口能力，重复建设的成本会迅速放大。

这时就应该把模型服务、知识服务、身份权限、工具接入、日志审计等公共能力前置设计，至少形成统一技术边界。

2. 数据与安全边界要求高度统一

央国企、金融、能源、制造等组织，往往对内外网边界、数据分级、模型调用、日志审计、账号权限有统一要求。如果各场景自行选模型、自行接数据，很快就会出现安全和治理风险。

这时平台不是为了“看起来先进”，而是为了建立统一控制面。

3. 多个场景明显共享同一批能力

例如多个部门都需要统一知识库、统一模型网关、统一组织权限、统一Agent工具目录，或者多个场景都会调用 ERP、MES、CRM、数据中台等同一批系统接口。

当“重复能力”已经清晰出现时，把它们平台化通常比每个项目重复开发更划算。

4. 企业有长期运营团队，而不是只做一次性交付

真正的平台一定需要持续运营，包括模型升级、知识更新、Prompt与流程优化、工具治理、版本管理、评测、安全和成本监控。如果企业已经明确有专门团队承担这些工作，平台建设才有组织基础。

反过来，如果企业没有长期运营角色，再复杂的平台最终也可能变成“交付完成即停止迭代”。

04 最容易踩的两个坑：平台空转，或者场景烟囱化

坑一：先建“大而全”的平台，结果找不到真正用户

有些企业一上来就按照“企业级 AI 中台”的思路建设：模型管理、知识库、Agent 开发、算力调度、提示词管理、评测、安全、运营、门户全都要。功能清单很完整，但真正业务上线时，发现只有少数几个场景在使用。

这类项目最大的问题不是平台本身不好，而是公共能力的规模被提前假设了。企业为了未来可能出现的需求，提前承担了当前并不需要的建设和运维成本。

坑二：只追求“一个场景一个结果”，最后重复建设

另一个极端，是每个部门各自做POC：A部门买一套知识库，B部门接一套模型，C部门自己做Agent，D部门再采购一套智能问数。前期都能快速出效果，但半年以后会遇到同样的问题：账号不统一、知识重复建设、接口重复开发、模型调用不可控、供应商越来越多。

这时再想统一，迁移成本往往比一开始做最小公共设计更高。

05 我更推荐的路径：场景牵引 + 最小公共底座 + 滚动平台化

如果让我给大多数企业设计第一阶段 AI 建设路径，我通常不会建议“平台”和“场景”二选一，而是采用三步走。

第一步：先选1—3个值得做的业务场景

优先选择三个特征同时具备的场景：业务痛点真实、数据能够获取、效果可以衡量。不要因为某项技术热门就强行寻找场景。

场景选择时，可以重点看四个指标：使用频率、人工成本、业务价值、可复制性。能高频使用、明显减少人工、直接影响效率或经营结果，同时未来还能复制到其他部门的场景，优先级最高。

第二步：只建设“最小公共底座”

最小公共底座不是一套大而全的平台，而是保证当前场景可以稳定上线、同时为后续复用留出接口。通常可以先考虑以下能力：

·统一模型接入：至少避免每个场景直接绑定不同模型接口。

·基础知识与数据接入：明确知识库、数据库、接口的接入规范。

·统一身份与权限：让 AI 能继承企业现有账号、部门与数据权限。

·日志与审计：知道谁问了什么、调用了什么、返回了什么。

·基础评测与运营：能持续判断效果、成本和使用情况。

至于复杂的多 Agent 协同、统一低代码开发平台、跨集群算力调度、全量模型训练平台等能力，没有真实需求时完全可以后置。

第三步：把被重复使用的能力逐步“长成平台”

当第二个、第三个场景开始出现，企业就可以观察：哪些能力在重复？如果多个场景都需要模型路由，就沉淀模型网关；都需要知识，就建设统一知识服务；都要调用业务系统，就建设统一工具/API 目录；都要做Agent，就逐步补齐运行、评测和运营能力。

这样形成的平台，不是凭空规划出来的，而是被真实业务一层层验证出来的。它的每个模块都有明确使用者，也更容易控制预算。

06 用这张表，判断你现在应该“场景优先”还是“平台前置”

如果左侧特征占多数，不要急着建设“大而全”的企业 AI 平台；如果右侧特征明显占多数，说明企业已经进入规模化阶段，需要提前处理共性能力和治理问题。

很多企业其实处在中间状态：已经有几个试点，但还没有大规模复制。这时最合适的并不是突然做一个“大平台”，而是把现有试点中已经重复出现的能力先抽出来。

07 真正应该统一的，不是所有技术，而是企业AI的建设规则

企业在讨论“统一AI底座”时，很容易把“统一”理解成所有场景必须用同一个模型、同一个开发平台、同一个供应商。其实这并不现实，也未必有利于创新。

我更倾向于统一的是规则，而不是强行统一所有实现。至少应该统一四件事：

·统一场景准入：什么样的问题值得用AI，立项前怎么判断价值。

·统一安全与数据边界：哪些数据能给模型、哪些工具能调用、哪些结果必须人工确认。

·统一技术接口：模型、知识、工具、身份、日志尽量遵循可替换、可复用的接口规范。

·统一运营指标：不仅看“是否上线”，还要看活跃用户、任务成功率、人工替代量、成本和业务结果。

这样，即使不同场景采用不同模型、不同产品或不同生态伙伴，也不会完全失控。企业可以允许业务创新保持一定灵活性，同时把真正需要统一的治理能力掌握在自己手里。

08 我建议企业按这个顺序建设AI

如果把上面的逻辑压缩成一条可执行的建设链路，我更建议是：

这条链路最重要的变化，是把“平台建设”从项目起点，放到了场景验证之后；但又没有完全放弃平台思维，而是在第一天就考虑接口、权限、日志和未来复用。

所以，企业 AI 的正确答案通常不是“先平台”或“先场景”。真正成熟的做法，是让场景负责证明价值，让平台负责放大价值。

写在最后

企业做 AI，最重要的从来不是把平台建得多完整，而是持续把“业务价值”变成“可复用能力”。先让 AI 在真实业务里跑起来，再把跑通的方法、数据、接口和治理沉淀下来，平台才会真正有生命力。