上周我在客户现场，任务是从几个业务团队里，挑一个长期写综合材料的部门，用一周时间为他们做个企业RAG知识助手的最小样板。演示时，能从过去的领导讲话、专题报告、调研材料中，找到想要的信息，还能给出来源。客户当场表示还挺不错的。
本以为后面继续往知识库里灌资料就完事了，结果这周去问反馈时，业务部门的对接人甩给我一份提问日志，只丢下一句："这东西，我们用不了。"
我当时还挺纳闷的，这智能体答得挺全面的，还能显示出处，会有什么问题？等我把那份日志从头到尾翻完，才算回过味来：那些AI给出的看似完美的答案，在业务眼中，根本就不是他们想要的。
我本以为，用户在提问时，会问一些概念性问题，比如“xxxx是什么意思”、“公司2026年战略目标是什么”。而实际的问题则是：
“XX同志在公司战略会上讲话的主要观点有哪些？”
“xxxxx这句话是在哪次会议上提出的？”
“列出XX同志在25年到26年每场战略会上的讲话要点”
而我搭的AI助手，只会挑几句意思相近的话概括一下，给个差不多的来源，就算交差了。
可用户真正要的，是把历史材料找全，把原话和概要分清楚，以及把每条结论的来源都交代明白。
这不是建几个知识库、配好提示词就能搞定的，也解释了为什么现在大家都说企业 AI 落地难在理解业务、而不在大模型本身。
于是在这一周，我把整个知识查询助手进行了重构，最终形成了一套五层产品框架：问题层、知识层、任务层、证据层、验收层。下面就把这五层逐一拆开讲给你听，因为只要你做企业 AI，就迟早会撞上同一个坑：
回答成立，交付不成立。
这五层的核心逻辑是：先用真实问题重新定义成功，再按证据属性整理知识，接着拆分查询任务，为答案加上校验规则，最后用业务标准验收。
第一层：先定义问题
回过头来看，第一版不是不能跑。如果是查某个明确的主题，它还是能给出答案的。
坏就坏在，我把"知识查询"当成一个功能，可用户会拿它当一组工作任务。
实际在查询时，用户的问题会涉及主题、时间、人物、材料类型和使用场景。有时还要精确到某个月、某次活动，以及材料是对外汇报，还是某次来访调研。同一位领导、同一个主题，在不同场合的表达重点也不一样。
所以真实场景里，全是这种错位：
用户问“xx同志有没有说过这句话”，需要做逐字核验，第一版给不了；
用户问“xx同志在xxx会议上的主要观点”，可以允许AI归纳，但必须要有原文支撑，而我只给了个大概；
用户想要“历次、全部、每一次”的领导讲话，系统就不能只返回相似度最高的三五份文件。
所以问题层只解决一件事：用户说的"查一下 XX"，在真实工作里到底意味着什么。
于是我在第二版里做的第一件事，是把用户的真实问题整理出了八个类型，分别是：
原话定位、单篇观点提取、历次会议汇总、跨材料专题查询、专题研究查询、历史汇报查询、经营数据查询，以及需要跨多类资料的综合问题。
这八类一定下来，我才知道自己的第一版漏得有多离谱。
第二层：重构查询边界
确认好需求后，客户又提交了一批新资料。规模从第一轮的几十份扩展到数百份，时间跨度更长，材料类型也更复杂。
最省事的做法当然是继续上传，但你懂的，新资料越多，第一版的问题只会被放大。“相似度检索”不等于“完整检索”，原来只有几份讲话材料时，检索出错还能靠人工识别，资料一多，完整讲话、会议整理稿、研究报告、历史汇报和当前数据就一定会互相干扰。
于是我重新一篇篇开始检查这批资料，很快就发现了问题：
有些文件名没日期，正文中才出现时间；
有的标题挂了好几位发言人，但具体一段话是谁说的，要结合上下文判断；
有些材料是根据会议录音整理的讲话要点，不是逐字稿；
有些历史汇报写得很成熟，其中的数据却和其他材料对不上；
还有的数据表里同时包含单月、累计、同比、占比和行业位次值，问题里少一个时间条件，答案就会差出十万八千里。
这就是企业里干了好些年，自然而然攒下来的样子，谁也怪不着。
针对这种多元查询的场景，我的解法是分两步：
先重做知识治理，再重构智能体查询逻辑。
先把资料按证据属性和使用方式重新分成五类：领导讲话和会议材料、产业专题和业务调研、专题研究和历史信息、成熟汇报材料、当前经营数据。目的是告诉系统，每组资料能回答哪类问题。
重新分类后，还要单独给每份文档，补上一段用来增加机器可读性的索引元数据，内容就是这篇稿子中提到的人物、时间、会议、材料类型、主题和来源属性。如下图所示：
虽然很麻烦，但它可以让系统在检索到一篇文档后，知道它属于哪一年、哪类会议，以及哪位发言人说的。
材料结构也要单独处理。因为企业讲话汇报这东西，核心观点常常就藏在"第一、第二、第三"这种行文里，第一版智能体在测试时，系统有时只概括了开头一段，中间几个要点全漏了。
因此，第二版需要在不改动原文内容和顺序的前提下，提取其中的标题层级和观点边界，单独摘录在正文对应位置，供模型识别理解上下文。如下图所示：
知识层的关键判断是：资料进入系统之前，必须先说明它的可查询边界。
这个边界没立住，模型越会写，风险反而越大。
第三层：入口唯一，分工路由
问题拆开了，资料也重新治理了，接下来才轮到AI助手本身。
对这个AI助手，客户只有一个要求：入口唯一。他们不想问不同问题还得换不同助手，嫌麻烦。
于是我根据前面2层的分析，把执行逻辑拆成四类查询任务：
一类专门处理领导讲话原文，负责校验原句、发言人、会议和时间；
一类处理专题研究，负责梳理报告框架和主要观点；
一类处理历史汇报，重点区分汇报对象、时间和版本；
一类只处理经营数据，核对指标、时间、单位、口径。
用户只管正常提问，统一助手会先识别查询意图，再把问题交给对应的专业任务处理，返回前统一校验答案完整性、来源和口径。这本质上就是 Agent 的多任务编排：入口统一，后台按专业拆路由。
这种设计解决了第一版的一个问题：原话查询和研究总结，不能用同一套回答逻辑。
对领导原话的查询，不能只给出意思相近的句子来概括，必须找到原话；而对于后者，可以由模型提炼总结，但也要标明总结来自哪份报告。
第三层还有个容易被忽略的部分：复杂问题不能只检索一次。
假设用户要汇总历次同类会议的领导观点，这类意图就要拆成三步执行：
第一步，先读取检索导航，确定这个系列理论上该覆盖哪些文件、多少次会议；
第二步，按照清单逐份提取内容，联合讲话材料还要检查段落能不能明确归属于目标人物；
第三步，再把应覆盖清单和实际结果对一遍，少一份就明确提示信息有缺失。
跨材料查询某个主题也类似：先发现相关文件，再逐份提取证据，最后归类和去重。不同会议里的话不能拼成一段引号；如果分类标题是AI概括的，也要说明它只是主题归类，不是原文件标题。
很多所谓智能体答得不准的问题，其实是根本没设计这个流程。模型只执行一次搜索，当然倾向于返回最相关的几段。而想达到业务要求的信息完整性要求，就必须先有范围，再逐份执行，最后做覆盖校验。
任务层的原则可以归结为一句话：前台越简单，后台越要把复杂度拆清楚。
第四层：答案返回前，要校验三道证据
设计第二版方案时，我专门增加了一道证据约束：完整性、来源和口径。
完整性。解决的是信息遗漏问题。当用户问想知道某个领导的历次讲话时，系统要先说明该覆盖多少份文档，实际覆盖多少份。没查全，就直接说没查全。
来源。解决的是内容出处问题。要求输出时，在引号内能放知识库中逐字存在的原文，不进行润色、缩写、拼接。对于联合讲话材料，只有在段落明确属于目标人物时才能引用，归属不清就要给用户提示。
口径。解决的是统计指标计算依据的问题。对于查数据的回答，要同时说明指标、时间、数值、单位和统计口径，严格区分单月和累计、行业占比和内部结构占比。没写清楚的内容，系统不能自行推算。
这三道校验的目的，是确保答案可被业务认可真实性。
尤其对问答准确性要求较高的企业，最怕的就是模型一本正经地编——把“差不多”包装成“就是它”，或者在两个冲突数据之间替业务人员默默做决定。
因此我会在提示词中进行限制，要求系统能确认的，就带着来源回答；不能确认的，就展示冲突，交回责任人。专业的动作有时不是给答案，而是知道哪些答案现在不能给。
证据层最终要解决的是：系统凭什么让用户相信这份回答。
第五层：先写验收标准，再让AI回答
问答类智能体，如果只看AI返回，很容易被答案的语言质量所吸引：文字通顺、有标题、有总结，乍一看还可以，但业务人员扫一眼就知道不是他想要的。
于是在做第二版方案时，我换了一种验收方式：先写标准，再问问题。
我整理了一批典型问题和改写问法，目的是把：完全一致的原话、近似表达、单篇材料观点、历次会议、跨材料专题、历史汇报和经营数据全部能覆盖到。每道题都提前规定几个关键点：应该找到哪些文件，必须出现哪些来源，以及哪些内容绝不能出现。
完全一致的句子，要明确告诉用户“来自原文”；
如果用户用了一个意思相近、但材料中并不存在的说法，系统必须说明没找到完全一致原句，再提供高度相关内容。
问“历次讲话”时，答案在开头就要交代应覆盖多少份材料、实际覆盖了多少份。
问数据时，则必须同时说明指标、数值、单位和计算口径。
通过这套可执行、可验收的评测任务，可以把AI助手的回答效果评估，从主观感觉，变成了可复核的交付标准。
验收层的核心是要讲清楚：业务人员凭什么同意它进入工作。
如何使用这五层框架
对比第一版和第二版方案，最大的差异在于：如何准确定义“查询正确”这件事。
第一版由于没收到典型问题作为样例，就只能通过模拟问题，先验证资料能不能被读取，模型能不能生成答案。
而第二版则是基于用户反馈，沿着五层框架逐步推进：
问题层：用真实问题定义系统要完成的任务；
知识层：按证据属性划分材料的使用边界；
任务层：一个入口承接用户，后台按专业任务分拆路由；
证据层：对完整性、来源、原话和数据口径进行校验；
验收层：提前写清预期覆盖、禁答内容和业务通过标准。
最后把五层合一块，本质上就是一道公式：
可信的企业知识助手 = 真实问题 × 知识边界 × 任务编排 × 证据校验 × 业务验收
注意是乘法，不是加法。哪一层趋近于零，整个就归零。
如果你正在做类似项目，我建议先别纠结选Kimi-K3还是GLM-5.2，也别急着讨论如何VibeCoding。先找业务要十个他们天天真会问的问题，再拿一批真实材料，让业务人员当场判断答案哪里不能用。通常问不了几轮，问题层、知识层和证据层的缺口就会自己露出来。
搭个能回答问题的AI知识助手并不难。难的是让它知道哪些话可以概括，哪些话必须原样引用，哪些材料不能混用，以及什么时候该诚实地告诉用户——我没找到。
我是申悦，AI创业者、独立讲师、企业AI顾问。提供企业AI培训、AI落地方案咨询、AI智能体设计和运营陪跑服务。服务过东风集团、海亮集团等世界500强企业。如果你的公司正在做AI转型、流程重构、知识库建设和智能体落地，想要获得FDE式的服务，欢迎加V详聊合作：s2dongman
热门跟贴