当智能体在幻觉，它其实只是饿着上下文

有一种说法很形象：当我们说一个智能体在幻觉时，我们真正在说的是一个正在饿死、缺少上下文的智能体。

它不是在「故意撒谎」。它在补全。训练里学过的通用软件常识、网页上似是而非的同类产品说明、提示词里被截断的半截句子——缺料时，模型仍然会把话圆完。圆完的那句，听起来像文档，执行起来像事故。

把问题命名成「模型坏了」，对策就会飘向换更大的模型、加更花的提示词。把问题命名成「它饿了」，对策就会落回土问题：它够得着的现行事实在哪？进没进对外库？有没有过审？同一事实是不是三处说法？

行业里常说的 RAG，白话就是先检索你们已有的资料，再让模型基于检索结果总结回答——不是让它凭训练记忆即兴当产品专家。RAG 做得好，前提仍是「库里有对的、现行的料」；库空、库乱、库过期，检索再响亮，总结也只是把饿包装成权威。

把金句落到周会上更刺耳：你们若把「演示日答得溜」当成上线标准，却不检查它咬的是不是已发布帮助页，等于默许助手空着肚子对外表演。作者侧怎么把页写成口粮，前面写过。本篇换到治理与产品边界：对外问答若允许空着肚子说话，幻觉就不是偶发 bug，而是默认工作模式。

行业公开调研里，幻觉是首要担忧的比例大约六成多。角色画像还不完全一样：写作者更咬准确度与技能退化；工程师更咬成本、法务与用户信任。两边怕的点不同，怕「错」是重叠的。

文档比多数营销文案更怕错，原因很简单。

软文里夸张一句，读者最多翻个白眼。帮助里错一步，实施会按着做：权限开错、数据导错、回滚路径走错。一条错误指令，毁掉的不只是一次演示，还有对产品的信任——客户很少区分「是 AI 编的」还是「是你们官方说的」，尤其当答案出现在你们自己的帮助中心对话框里。

创作侧 AI 已经过了主流门槛：经常用它写文档的人很多。采用跑在治理前面，才是更难受的结构：大家都会用生成，真正有指南、有审核闭环的团队却少一截。本篇不展开「百分之几十有指南」的治理比例长文；只需认清半步——越是把助手推到客户面前，越不能把「听起来对」当成「可以执行」。

怕幻觉，不是保守。是承认文档场景的损失函数更陡。所谓可追溯性，就是答错之后还能顺着问：这句话从哪页来、对应哪版、谁发过布。追不上，就只剩「模型好像说错了」的互相甩锅——客户不会关心你们内部怎么甩。

把「饿」说成人话：助手答错，往往不是它比人坏，而是它比人更老实——人还能说「我不确定，去问研发」；饿着的模型很少主动闭嘴。组织若把「听起来完整」当成上线标准，等于奖励它继续补全。治理的第一刀，不是换模型，是不许空着肚子对外说话。

国内现场里，危险演示通常长这样。

把通用大模型挂在网站右下角，系统提示写「你是某某产品客服」，知识库勾选含糊，或干脆不接库，靠模型「理解官网」。现场问价格相关能力、私有化限制、某个半上线功能，它都能答。销售高兴：终于不用等人。

第二天客户按答案采购或实施，发现限制对不上、接口字段是杜撰的、步骤里的按钮名来自竞品记忆。回滚成本由实施和客服扛；品牌损失由全公司扛。复盘时有人说「AI 还早」，有人说「提示词没调好」——更准确的说法是：你们让一个饿着的模型，对着付钱的人即兴表演产品专家。

另一类错误略体面：接了库，但库是「全网盘打包」「飞书一次导出」「含草稿与过期 PDF」。助手检索到的是噪声，总结得越流畅，越像权威。人还知道去群里喊一声「以谁为准」；客户侧助手没有你们的企微群。上午客服在群里口述了正确限制，下午助手仍从过期 PDF 里答出旧限制——两边都「好像有依据」，客户只看见互相打架。

还有一类边界含糊：对内说「仅供参考」，对外 UI 却长得像正式客服；答错了无法点回原文，只留下一段无法审计的聊天气泡。不确定感被界面抹平了，风险被留下了。

周二演示用空模型答「支持按组织树隔离」；周三合同附件按这句写进范围；周四实施发现现网只有项目级隔离。客户不问「是不是 RAG 没配好」，只问「你们到底会不会做」。

还有一种更日常的饿法：帮助中心里其实有现行页，但从未发布进会被问答检索的库；或者发布了，标题是内部代号，用户问句对不上，检索落空，模型只好拿常识补全。饿不一定是「库里零页」，也可能是「库里有粮，门口却找不着勺」。真实痛点往往不是「回答不够长」，而是不确定：这句话有没有落在已发布事实上？我能不能点开原页核对？错了谁负责收回？

卡住你们的，通常不是「模型参数够不够大」，而是更土的不确定叠在一起。你不确定助手此刻读的是不是已发布那一版；不确定客户能不能点开原页核对；不确定错了之后，组织还找不找得到放行的人。这三种不确定，比「回答不够长」更磨人。

国内周会里还有一种体面的自欺：演示环境接了精选语料，生产环境勾选「全站含历史」。演示日零幻觉，上线周客户按杜撰字段联调失败。复盘写成「AI 还早」，真相是两套口粮、一套 UI。把生产口粮收成「仅已发布」，把「知识库暂无」当成可接受的诚实答案，比再调一夜提示词更接近治理。

Baklib 的立场比较拧巴，也故意拧巴：要上 AI 到达层，但先把嘴管住。

AI 客服 / AI 智能搜索 一类能力，建立在企业已发布知识上——帮助中心、文档与手册等叶子先有真源、先过审、先发布，再被检索，再被总结。建设侧模板可点亮 Chat、Help、Docs；Chat 不是另起一套说明书，而是到达方式。草稿、群聊口述、未发布飞书页，默认不应成为对外答案的口粮。

诚实边界写清楚，反而更像能买的东西：

这是检索加总结，不是逐句高亮溯源的法庭证据系统。我们追求的是答案尽量来自已发布库，并让人能点回帮助中心或文档原文核对；不吹「每一句都有彩虹标注且永不出错」。所谓 AI Chat，就是对话界面上的那层到达方式——聊可以，但嘴应只咬已发布料。模型仍可能总结偏，组织仍要定口径、做审核、处理反馈。客户真正要的，往往不是更长的回答，而是「这话能不能点开原页核对」；核对通道在，信任才接得住一锤。治理流程、人机比例那些，后面专门写；这里先把开关拧在「只吃已发布」。

落地时顺序同样克制。先亮帮助与文档等骨干入口，树干真源可协作、可版本；再开对话。演示日宁可答「知识库暂无」或引导到人工，也不要用空模型即兴生成产品限制。空叶子有时比饿着乱吃安全。

对外上线前，建议团队自己问三句：答案是否只来自已发布库？答得出时能否点回原文？答不出时是否明确说不知道，而不是圆场？三句都过，才算嘴管住了。少一句，幻觉就仍有机会穿着客服的衣服出门。