很多团队第一次用 Dify 做企业内部问答机器人，都会从“让它更聪明”开始：接更多模型、上传更多文档、开更大的上下文、把提示词写得越来越复杂。结果常常不是更好用，而是更难排查：员工问一个制度问题，回答里混了旧版本文档；客服问产品参数，模型把 A 产品和 B 产品拼在一起；老板问“为什么答错”，团队却不知道问题出在知识库、检索、提示词还是模型本身。
内部问答机器人真正能落地，第一步不是追求全能，而是把范围切小。Dify 的优势在于它能把知识库、提示词、模型、工作流和应用发布串起来，但这也意味着你需要像做一个小产品一样设计它，而不是把公司网盘丢进去等奇迹发生。
先选一个低风险场景，不要从全公司知识库开始
最适合第一版的场景通常有三个特点：问题重复、答案相对稳定、答错不会立刻造成严重损失。比如新人入职常见问题、报销流程、某个 SaaS 产品的帮助文档、内部工具使用说明、客服质检口径。不要一上来做“公司万事通”，也不要把法务、财务、人事、销售所有制度混进同一个机器人。
一个可执行的第一版边界可以这样写：只回答“员工报销与差旅流程”；只使用 2026 年 1 月以后发布的制度文档；不回答薪酬、劳动合同、税务筹划问题；无法确认时必须提示联系财务同事。这个边界看起来保守，但它能让你知道机器人什么时候应该回答，什么时候应该拒答。
整理知识库时，先拆文档，再决定怎么上传
很多问答效果差，不是模型差，而是文档结构太乱。一个 80 页 PDF 里同时包含背景说明、旧流程、例外规则、截图和附录，直接上传后，检索很容易把不相干段落召回。更好的做法是先把文档拆成小块：流程说明、字段解释、常见问题、例外规则、联系人、更新时间。
每个知识块最好有一个明确标题，例如“差旅住宿标准：一线城市”“发票抬头填写规则”“报销被退回的 5 个常见原因”。如果内容有版本，标题里写上日期。Dify 的知识库不是垃圾桶，越像一个可维护的帮助中心，回答越稳定。
提示词要写“角色、边界、引用、拒答”，不要只写语气
内部机器人提示词里最重要的不是“请专业、友好、简洁”，而是边界。可以从这段骨架开始：
你是公司内部报销流程助手。你只能根据知识库内容回答。回答时先给结论，再列步骤。如果知识库没有明确依据，请说“我没有找到可确认的制度依据”，并建议用户联系财务。不要编造金额、日期、审批人或例外政策。涉及个人薪酬、合同、税务筹划的问题一律拒答。回答末尾列出依据文档标题。
这类提示词会牺牲一点“像真人”的感觉，但换来可控性。企业内部工具最怕的不是回答不够华丽，而是一本正经地胡说。
用 30 个真实问题做验收，不要只看演示效果
上线前不要只问“报销流程是什么”这种标准问题。找业务同事收集 30 个真实问法，里面要故意包含错别字、模糊表达、边界问题和无关问题。例如：“上周去上海住了 680 能报吗”“客户请我吃饭算招待还是差旅”“发票丢了怎么办”“我可以先垫付再找领导补批吗”“工资扣税怎么算”。
每个问题都标注期望结果：应该直接回答、应该追问、应该拒答、应该转人工。测试时记录三列：召回到了哪些文档、回答是否准确、是否给出了不该给的承诺。这个表比单纯看聊天记录有用，因为它能告诉你下一步该改知识库、提示词还是流程。
什么时候该用工作流，而不是普通问答
如果问题只需要从文档中找答案，普通知识库问答就够了。如果问题需要判断条件、收集字段、调用外部系统，就应该考虑 Dify 工作流。例如“我这张发票能不能报”需要用户提供城市、金额、日期、费用类型、发票状态，再按规则判断；这不是一句提示词能稳定解决的。
工作流适合把步骤拆开：先识别问题类型，再收集缺失信息，再检索对应规则，最后输出结论和下一步动作。它比单轮问答慢一点，但更适合内部流程、客服分流、表单预审这类任务。
上线后要看三类指标
第一，看无人能答率：用户问了但机器人没有找到依据，这能暴露知识库缺口。第二，看误答率：回答看似完整但依据不对，这是最高优先级问题。第三，看转人工原因：如果很多人仍然问同一个问题，说明答案入口、标题或流程本身需要调整。
建议每周固定抽样 50 条对话，标记“可接受、需优化、危险回答”。危险回答不要只改提示词，要追溯到文档版本、召回片段和边界规则。内部机器人不是上线一次就结束，而是一个持续维护的小系统。
Dify 适合谁，不适合谁
Dify 适合有明确知识源、愿意维护文档、需要把问答和流程连接起来的团队。如果你只是想给网站加一个简单聊天入口，Botpress 或现成客服 AI 可能更快；如果你要完全自托管复杂流程，n8n、Flowise 和自建服务也可能更灵活。Dify 的价值在于把“知识库 + 应用发布 + 工作流 + 模型选择”放在同一个操作界面里，适合从内部小场景开始迭代。
最好的第一版不是无所不知，而是回答少数问题时足够可靠。只要边界清楚、知识库可维护、验收问题真实，Dify 做出来的内部问答机器人就不会只是一个好看的演示，而会变成团队真的愿意用的工具。