用 Dify 搭企业内部问答：能跑起来和能上线差多远

装一个 Dify、接一个模型、把部门文档拖进去，一个能对话的内部问答界面半天就能出现在屏幕上。演示那天效果通常不错，老板随口问几个问题，回答流畅、语气专业，会议室里的气氛很好。

然后项目进入上线阶段，事情开始变慢。谁能看到哪份文档、十个人同时提问会不会排队、答错了怎么回溯、模型换了会不会整套失效、答不出来时界面该说什么——这些在演示里都不会出现，却决定了系统能不能真的交给业务部门天天用。原型和上线之间隔的不是功能清单，是五件工程上的事。

一、原型跑得动，上线为什么卡住

原型阶段的环境干净得不像话。文档是开发者自己挑的十几份，格式规整、没有重复版本；用户只有他自己；出错没人追责，重启一下就当没事发生。这种条件下跑通，只说明这套工具能用，说明不了它能在业务里用。

真实环境立刻换了一套条件。资料是脏的：同一份管理办法存着三个年份的版本，扫描件没有文字层，参数表跨页断成两截。用户是杂的：有人问报销标准，有人问设备功耗，还有人拿它当搜索引擎试边界。责任是实的：答错一句，业务方照着错的做，损失得有人认。

所以卡点通常不在模型能力上，而在模型外面那一圈工程。演示的时候没人追问“这句话出自哪份文件第几条”，上线之后每天都有人追问。答不上来第一次是意外，第二次开始，系统就没人用了。

二、五处差距，用一张表说清

把原型和上线并排放在一起，差距集中在五个地方。这五项不是加分项，缺任何一项，系统都会在某个具体场景里失去信任。

环节	原型状态	上线要求	差距落在哪
权限隔离	一个账号进全库，检索不分部门	按部门、角色、密级分级，外部人员看不到内部资料	文档级权限与统一身份对接，工作量最大
并发与延迟	一个人点，等五秒也能接受	峰值几十人同时提问，首字延迟要稳	队列、限流、缓存，加上真实容量压测
日志审计	只有控制台报错可看	谁问的、问了什么、引用了哪份文档、答了什么，全部留痕	会话级日志与留存周期，内审要能调出来
模型切换	写死一个模型，换就改配置重启	多模型可切换可降级，切换不影响正在进行的会话	调用抽象层与灰度验证流程
答案兜底	答不出来就顺手编一段	答不出要明说，并给出查原文或转人工的路	置信度判断与固定话术

这张表可以直接当检查清单用。五项里最容易被低估的是权限和日志，它们不影响演示效果，却决定这套系统能不能过内审、出事时能不能说清。最容易被高估的是模型：换一个更强的模型，解决不了越权检索，也解决不了答案没有出处。

三、落地路径：三件事按顺序做

这五件事不该并排推进，顺序错了会返工。按下面的次序做，每一步都能独立验收。

1. 权限先做，效果后谈

很多项目反过来：先把回答效果调到满意，最后才补权限，权限一加召回范围缩了一半，前面调的参数全部作废。正确做法是先定文档的归属部门和密级，按用户身份卡死检索范围，再在这个范围里调效果。范围小了效果反而更容易调准，噪声源被提前剔掉了。

2. 并发和延迟靠压测，不靠估算

单机演示时响应快，不代表二十个人同时用还快。大模型推理的时间主要花在生成上，并发一上来，请求会在队列里排队，用户看到的是转圈而不是答案。上线前用真实人数、真实问题长度压一轮，记录首字延迟和完整回答耗时两个指标，再倒推需要几路并发、要不要加缓存、要不要把高频问题做成预设答案。

3. 兜底话术提前写，不要临场想

知识库一定有答不出的问题，区别只在于系统是老实说不知道，还是编一个像样的答案。后者短期看着聪明，长期是灾难。上线前把三类话术定下来：检索不到时说什么、检索到但置信度低时说什么、涉及权限外内容时说什么。每类都要带一个动作，比如给出原文链接、给出对应部门联系人、或者直接转人工。

四、成本与风险：真正贵的都不在软件

Dify 本身开源，部署成本低，容易让人以为整个项目花不了多少钱。实际预算里软件占比很小。

时间成本主要在对接。权限要接企业的账号体系，日志要接审计平台，文档要接共享盘或网盘，每一处对接都要对应系统的管理员配合，排期常常比开发还长。调用成本随使用量线性上涨，试用期十个人和上线后两百人，账单不是一个量级，需要按峰值和月活分别测算。

风险有三类值得提前摆到桌面上。权限配错，销售能检索到薪酬制度，这是事故不是 bug；答案没有出处，业务方无法核实，用两次就不信了；模型供应商变更或涨价，如果调用写死在代码里，迁移就是重写。三类风险都不难防，难的是有人在项目开始时就把它们写进方案。

五、怎么验收：四个角色，四份交付物

验收别只看“能不能回答”，要看“出了问题是哪个环节担责”。四个角色各自交东西，交齐了才算上线。

系统负责人交部署文档与账号清单：环境怎么起、配置在哪改、模型怎么换、出故障找谁，写清楚到别人接手能独立操作。

数据负责人交文档清单与权限矩阵：每份文档属于哪个部门、什么密级、谁能看，抽样能对上。

业务负责人交评测集与抽检记录：用真实提问而不是自己出的题，问题、期望出处、实际回答、判定四项留痕，命中率按周跟踪。

运维负责人交监控项与日志样例：并发数、失败率、平均耗时、异常告警阈值，以及一份能查出“谁在什么时候问了什么、系统引用了哪份文档”的日志样本。

四份交付物里最容易糊弄的是评测集。用自己出的题测，分数永远好看；用业务方真实问过的问题测，才知道到底能不能用。

六、先做一个部门的三个月，别做全公司的三天

原型三天能跑，是因为范围小、条件好。上线要三个月，不是技术变难了，是范围扩大到真实业务之后，那五件事一件都躲不掉。想缩短周期，办法不是压缩工期，是压小范围：挑一个部门、一个明确的问答场景、一批干净的文档，把权限、并发、日志、模型切换、兜底五件事完整走一遍。走通了，复制到第二个部门只是换人执行；走不通，损失可控。

内部问答系统真正的价值，不在于它能答多少题，而在于业务方敢不敢拿它的答案去做决定。敢，说明出处清楚、权限清楚、错了能追；不敢，界面做得再漂亮也只是个玩具。

如果你已经在 Dify 上跑出了原型，正卡在上线这一步，可以先做一次现状盘点。我们的企业知识库建设方案里带了一套权限与验收模板，也可以配合AI 智能体私有化部署、AI 工作流自动化一起规划；想先摸清现有系统的短板，可以从免费 AI 可见度诊断或联系我们开始聊。