> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/enterprise-llm-deployment.md).

# 企业大模型落地（2026-2027）：先试点哪个用例

本文整理自 Duaer 文档站，指出企业大模型落地的主要瓶颈在于集成层而非模型能力，并介绍用例评估与首个试点的选择方法。

## 企业大模型落地为何常常停滞

企业大模型落地很少是因为模型能力不足而停滞。更常见的情况是，团队把通用大模型接入了原本并非为它设计的系统：权限混乱的文档库、接口薄弱的工单工具，以及围绕确定性软件建立的审批流程。大多数项目失去动力的地方不在模型，而在集成层。

## 值得考虑的典型用例

大多数组织最终会评估以下几类场景：

· 内部知识助手：基于政策、手册和历史工单回答问题

· 在现有工作流中起草与总结，例如客服回复、合同审阅备注或会议跟进

· 对入站请求、工单或邮件进行分类与分派

· 从发票、表单或报告中结构化提取信息并写入现有系统

· 为内部工程和数据分析团队提供查询与代码辅助

这些场景在集成难度上差异很大。总结用户已经打开的文档很简单，而回写到系统记录中则复杂得多。

## 按价值与集成难度排序

建议从两个维度为每个候选场景打分。价值维度看每周有多少人执行该任务，以及回答缓慢或错误会造成多大损失。难度维度看任务跨越多少个系统，是否需要实时数据，权限模型有多严格，输出能否自动校验。

一个务实的原则是：从价值高、且在下游发生任何变更前有人工复核输出的场景开始。带引用的只读检索通常优于自主执行操作。涉及计费、人事或客户记录写入的任务应放在后面，等权限控制和日志记录得到验证之后再推进。关于这套评分方法的更深入讲解，可参阅 [按价值与难度对大模型用例排序的方法](https://doc.duaer.com/zh/guides/enterprise-llm-adoption-scenario-selection/)。

## 如何选择第一个试点

一个强有力的首个试点通常具备四个特征：

1. 业务部门中有明确的负责人，而不只是 IT 部门

2. 所需的文档或数据集较为新近，并且已经可以访问

3. 有可衡量的基线，例如处理时长或审阅耗费的工时

4. 若模型表现不佳，有清晰的回退方案，可以回到现有流程

应避免那些同时依赖多个未完成集成的试点。如果项目需要新的身份层、新的数据管道和新的界面，它就是一个平台级项目，应当按平台项目来界定范围。许多在试点与规模化之间停滞的团队都犯了这个错误。在投入预算之前，建议先回顾 [企业 AI 落地后常见的停滞点](https://doc.duaer.com/zh/guides/enterprise-ai-adoption-pitfalls/)。

## 本周可以做的一件事

从当前的需求清单中挑出三个候选场景。对每一个场景，写下它涉及的系统、将对输出负责的人，以及能够证明其是否有效的指标。凡是无法同时说清这三项的候选，直接剔除。剩下的短名单，才是真正的起点。

企业大模型落地能否成功，取决于首个用例是基于集成的现实性来选择，而不是基于对模型的雄心。

## 常见问题

### 企业大模型的第一个试点应该选什么场景？

优先选择价值高、且在下游变更前有人工复核的场景，例如带引用的只读知识检索。涉及计费、人事或客户记录写入的任务应放在后面，待权限控制和日志审计验证后再推进。

### 企业大模型试点后为什么难以规模化？

常见原因是试点同时依赖多个尚未完成的集成，例如新的身份层、数据管道和界面。若项目需要这些配套，应按平台项目来立项和规划，而不是当作一个普通试点。

### 如何判断一个大模型用例是否值得立项？

可以检查三件事：它涉及哪些系统、由谁对输出负责、用什么指标衡量效果。无法说清其中任何一项的候选场景，应先从清单中剔除。