建一个能被信任的知识库

助手答错的时候，第一反应都是去查检索。但相当多翻掉的项目里，技术链路每一步都对，答案依然是假的——因为它引用的那份文件在写下来那天就是错的。这种失败之所以安静，是因为上游每一个指标都漂亮：段落找对了、引用准确、延迟正常，答案自信地错着。

先分清是哪一种错

动手之前，先按引用来给错答案分类。

引用正确而答案错误，是资料问题。调了一周召回，源头那行字已经印错了几年。引用错误或没有引用，是检索问题，这一类才轮到模型和索引去修。引用对、答案也对，用户仍然没法照着办事，是交接问题：资料没问题，流程少了一块。

这个分类花不了半天，却能挡掉最贵的一种白干，因为三种错在演示桌前面长得一模一样，底下却毫无共同点。

可信度检查：四栏，和谁签字算数

公开的三步法大多从岗位访谈和目录开始。这个顺序是反的。把一堆没人愿意背书的文件排成一个漂亮目录，只是把错误组织得更整齐。

先取第一版真正会引用到的那批资料——整柜子不用看，抽样即可——每份填四栏：谁写的、哪一版；什么时候生效；谁签字确认它现在仍然正确；出现什么事件必须重读。

签字规则比表格本身重要。签字的人必须是这条答案错了他会被追责的角色：规格由产品负责人签，政策由政策负责人签。不是 IT，不是项目发起人，也不是「团队」。签字不代表内容为真，它代表出了问题有一个可以再问一次的人。没人肯签的文件只能作为参考入库，不可引用，助手遇到它必须回答「没有依据，转人工」，而不是顺着编。这一条把知识库和「套在档案柜上的搜索框」分开。

这一步被跳过的信号很具体：通常是最有经验的那个员工，一边读文件一边在脑子里自动纠正，自己都没察觉。你问他某一行和实际做法对不对，他说「也不完全是，大家都知道」。大家都知道的、任何系统里都没有的那部分，正是助手会稳定地、可复现地答错的地方。

三步法，以及门前那道闸

可信度检查过了，熟的那套顺序才成立。

岗位访谈要还原的是交接顺序，不是组织架构：谁接单、谁做判断、谁退回。按组织架构排目录，等于把架构图重画一遍，把交接环节盖住了——而工作和错误都在交接处。目录应该按业务流转排，一步一个目录，让检索的单位和干活的单位对上。

每个岗位一份 SOP，边界要写进 SOP 里：谁能报价、谁必须转顾问、助手什么事绝对不许自己答。

那家 16 人的知识产权代理公司，客户方成立了内部 AI 小组，逐条书面确认流程全部走通之后，才开始动手搭东西。这道闸是「一次交付」和「一次返工」的分界线，也是最便宜的一份保险——否则等你发现分歧，代码已经在了。

顺带一条：资料多不等于知识任务成立。加资料之前先核三件事：谁会用到这个答案、他拿它和什么比、口径是不是统一的。档案很大而口径没定的公司，得到的只是一个更快生产两套互不相容答案的系统。写下来的流程和真正在跑的流程也很少是同一份文件，后者多半躺在某个影子系统里，而人照着它办事。

权限是资料的一部分，不是提示词的事

不同岗位能看的资料不同，边界必须在检索之前用身份和权限卡住，而不是写一句「不要泄露」指望模型自觉。拿两个账号问同一个问题去测，除了回答，也看引用来源和历史记录里有没有带出不该给的内容。数据与安全边界是知识库设计的一部分，不是上线前再补的加固项。

交出去以后怎么保持可信

两个习惯让它活着。一是留一批真实的历史问题，每次资料变更后重跑一遍；知识库的水平，取决于它对「不是为它准备的问题」的回答。二是把每一次没答好记成三类之一：没找到、用错了、过期了。不记下来的失误，下个季度会以同样的样子再来一次。

没确认的事情就写「待确认」。用看起来合理的解释把缺口补上，是把一个已知的不确定，换成一次未知的错误。这和五阶段交付在验收上的纪律是同一条：没核对过的状态记为未核对，不要四舍五入成通过。

判据

挑系统最常回答的五个问题，逐个去找愿意为它签字的那个人。五个里签不满五个，这个知识库就没准备好：它还只是一个套在档案柜上的搜索框，而它出错的方式，再多的索引也修不了。