用 AI 做知识库：让团队问一句就拿到带出处的答案

任务目标

做完这件事，你应该有：一个问一句话就能拿到答案、并且答案能点回原文的知识库。新同事问「报销标准是多少」，它给出金额并附上制度文件的具体段落；客服问「这个功能上线了吗」，它给出结论并附上产品公告的日期。更关键的是，当文档里根本没有答案时，它会说不知道，而不是编一个。

这条路径覆盖的是内部资料型知识库：制度与流程、产品文档、客服话术与常见问题、项目历史记录、销售资料、研究资料。它不覆盖三类——需要严格权限分级的合规场景（法务意见、医疗诊断、财务审计）、需要实时准确性的业务数据查询（库存、订单状态）、以及需要跨系统写操作的自动化。第一类是责任问题，第二类应该查数据库而不是查文档，第三类是另一个工程。

推荐工具组合

图 1：知识库任务的顺序。注意箭头方向：问题在前，文档在后。倒过来做——先把所有文档倒进去再想能问什么——是最常见的失败起点。

为什么这样选

为什么先写问题清单，而不是先导文档。 「把公司所有文档做成知识库」是一个没有验收标准的目标，做完了也不知道算不算成功。改成「这个库要能回答这 20 个问题」之后，一切都有了依据：哪些文档必须进、哪些是噪声、调优调到什么程度算够、上线后怎么衡量。这一步花两小时，决定了后面两天是不是白干。

为什么强烈建议先用带强制引用的托管方案跑一遍。 NotebookLM 这类工具有一个别的方案给不了的好处：它的每句回答都挂着出处，你点开就能看到它到底读了哪一段。这会立刻暴露最本质的问题——很多时候不是检索不准，是你的文档里压根没有这个答案。自建 RAG 反而会掩盖这一点，因为模型会用通用知识把缺口填上，你看到一个看似合理的答案，其实和你的文档无关。

什么时候才真的需要自建。 只有四种情况：数据不允许离开内网；需要和业务系统打通（查了文档还要查订单）；文档量大到托管方案装不下；需要按部门或角色做精细权限。除此之外，自建的收益通常抵不过维护成本。真要自建，RAG、Embedding 和向量数据库这几个概念得先搞明白，工程细节可以看 RAG 为什么答不准？10 个工程原因和解决方案。

为什么必须有评测问答集。 没有它，你的所有调优都是凭感觉。今天把切块调小了，感觉好像准了点，明天换个问法又不准了，你无法判断是改好了还是改坏了。二三十道固定题目、每次改动后重跑一遍，是这件事从玄学变成工程的唯一办法。

完整步骤

第 1 步：写「要回答哪 20 个问题」

不要自己闷头想。去问真实用户：新人入职第一周问过什么、客服后台里重复率最高的问题是什么、你自己上一次翻文档是在找什么。凑够 20 条真问题，按频率排序。

同时写下三到五个这个库不负责回答的问题，明确边界。

第 2 步：按问题筛文档

对着问题清单去找文档，而不是把共享盘整个倒进来。每份候选文档回答三件事：它能回答清单里的哪几个问题；它是不是当前有效版本；它的负责人是谁。

三种文档必须先处理掉：过期的（去年的价格表、已废止的流程）、重复的（同一制度的三个版本散在不同文件夹）、草稿（标题里带「讨论稿」「V2 修改中」的）。这一步删掉的文档往往比留下的多，这是正常的。

第 3 步：预处理

• 扫描件和图片型 PDF：必须先做文字识别，否则等于一张白纸进库。判断方法很简单——在 PDF 里能不能选中文字。
• 超长文档：几百页的手册整份丢进去，检索时会因为主题混杂而抓不准。按章节拆成独立文件。
• 表格：纯表格在检索里表现很差，给每张表补一段文字说明「这张表回答什么问题、每一列是什么」。
• 会议录音和培训视频：转写成文字，并在开头补上时间、参会人、议题。
• 具体的解析坑可以看 AI 如何读懂 PDF？从 OCR、解析到 RAG 问答。

第 4 步：定文档规范

给每份进库的文档补一段统一的头部：适用范围、生效日期、最后复核日期、负责人、失效条件。这五行的价值在两个地方——检索时它是强信号，模型能据此判断哪份更新；维护时它让「这份还有效吗」变成一眼能看出来的事。

第 5 步：入库

托管方案就是上传。自建的话，先用最朴素的配置跑通全链路再谈优化：固定长度切块加重叠、通用嵌入模型、返回前若干条。不要在第一版就上重排、多路召回、查询改写——你还没有基线，加了也不知道有没有用。切块策略的取舍见 RAG 文档切分怎么做？Chunk Size 实战对比。

第 6 步：建评测问答集

二三十道题，分四类：

1. 直答题：答案在某一份文档里明确写着。
2. 归纳题：需要综合两三份文档。
3. 陷阱题：文档里没有答案，正确表现是拒答。这类题至少占两成。
4. 时效题：有新旧两个版本，正确答案必须是新版。

每题写下标准答案和应该引用到的文档，之后每次调优都重跑一遍。

第 7 步：调优

按顺序排查，一次只改一件事，改完重跑评测集：先看检索是否召回了正确段落（如果没召回，调切分和检索方式），再看生成是否忠于召回内容（如果跑偏，改系统提示词，强制引用、允许拒答）。如果召回里正确段落排得靠后，才考虑加重排，见 Rerank 是什么？为什么 RAG 经常需要重排。

第 8 步：定维护机制

上线不是终点。要明确三件事：每类文档的负责人是谁；多久复核一次（制度类可以半年，产品类可能是每次发版）；文档失效时怎么下线。没有维护机制的知识库，三个月后会开始给出错误答案，而且没人发现。

图 2：调优的分诊路径。先判断是「没找到」还是「找到了但答错」，这两类问题的解法完全不同，混在一起调是最耗时间的做法。

提示词

一、从问题反推文档清单

你在帮我规划一个内部知识库。下面是这个库必须能回答的问题清单。

请针对每个问题输出：
1. 回答它需要哪一类文档（写文档类型和大致标题，例如"差旅报销制度"）。
2. 这份文档里必须包含哪几个具体字段或数字，答案才算完整。
3. 如果我们手上没有这份文档，这个问题应该怎么处理——是先补文档，
   还是明确写进"本库不回答"清单。

最后汇总成一张「必需文档清单」，按「几个问题依赖它」从多到少排序。

问题清单：
{贴你收集的 20 个真实问题}

二、文档元数据标准化

读下面这份文档，输出一段标准头部，用于放在文档最前面。格式固定为：

适用范围：（谁适用、哪些情况适用）
生效日期：（文档里明确写了就用原文；没写就输出"未标注"，不要推测）
最后复核日期：未复核
负责人：（文档里出现的部门或角色；没有就输出"待指定"）
失效条件：（什么情况下这份文档不再适用）
一句话摘要：（30 字以内，说清这份文档解决什么问题）
关键术语：（列出 3–8 个本文档特有的名词）

硬性要求：所有信息必须来自文档原文。凡是原文没写的，写"未标注"或"待指定"，
禁止根据常识补全。最后单独列出：你认为这份文档缺少哪些关键信息。

文档：
{贴文档正文}

三、知识库问答的系统提示词

你是本团队内部知识库的问答助手。回答必须遵守以下规则：

1. 只使用检索到的文档片段作答，不得使用你的通用知识补全。
2. 每一个结论后面标注来源：文档名称 + 章节或段落定位。
3. 如果检索片段不足以回答，直接说"现有文档里没有这个信息"，
   并说明还需要什么材料，不要给出可能的答案。
4. 如果多个片段互相矛盾，把冲突原样呈现出来，并按"生效日期"较新的优先，
   同时提示用户存在版本冲突。
5. 涉及金额、期限、比例、人名、审批层级时，必须逐字引用原文，不得改写。
6. 用户问的是流程时，按步骤列出，并标明每一步的责任角色。

不要为了显得有帮助而扩展回答范围。说"不知道"是正确行为。

四、生成评测集与判分

基于下面的文档清单，帮我生成一份知识库评测集，共 25 题，按四类分配：

- 直答题 10 题：答案在单一文档里明确写着。
- 归纳题 5 题：需要综合 2–3 份文档。
- 拒答题 5 题：看起来相关、但现有文档里没有答案，正确表现是拒答。
- 时效题 5 题：涉及有新旧版本的内容，正确答案必须来自较新版本。

每题输出：问题 / 标准答案 / 应当引用的文档 / 判分要点（什么情况算通过）。
拒答题的标准答案统一写"应当拒答，并说明缺少什么材料"。

文档清单：
{贴文档标题与一句话摘要}

实测演示：一个引用、一个版本冲突、一个拒答

实测环境：macOS + Claude Code 命令行 2.1.226，--model sonnet，2026 年 8 月。文档是虚构的演示材料，命令和输出都是真跑出来的。

动手前：先把命令行装好

演示用的是 Claude Code 的命令行版本，三条命令装好并验证：

# 1. 需要 Node.js 22 或更高版本
node --version

# 2. 全局安装
npm install -g @anthropic-ai/claude-code

# 3. 验证
claude --version        # 应输出类似 2.1.226 (Claude Code)
claude doctor           # 检查安装是否健康

第一次使用要登录：在终端直接敲 claude 进入交互界面，按提示完成账号授权（之后可以用 claude auth 管理登录状态）。登录完成后，下面这种一次性的 -p 调用就能直接跑了。

本文所有命令都写了 --model sonnet，是为了让你复现时和这里用的是同一档模型；不加这个参数会用你账号的默认模型，输出会有出入。

第一步：准备材料（复制粘贴即可）

搭一个只有三份文档的最小知识库，专门用来复现前面说的三类问题。整块粘进终端：

mkdir -p ~/demo/kb/docs && cd ~/demo/kb

cat > docs/差旅报销制度-v3.md <<'EOF'
适用范围：全体员工的国内出差
生效日期：2026-03-01
最后复核日期：2026-03-01
负责人：行政部
失效条件：发布 v4 后本版失效

# 差旅报销制度 v3

## 第二章 住宿标准
一线城市住宿标准为每晚 600 元，其他城市为每晚 400 元。超标部分需部门负责人书面批准。

## 第三章 提交时限
出差结束后 15 个工作日内提交报销单，逾期需附说明。
EOF

cat > docs/差旅报销制度-v2-已作废.md <<'EOF'
适用范围：全体员工的国内出差
生效日期：2025-06-01
失效条件：已被 v3 取代，仅作历史留档

# 差旅报销制度 v2（已作废）

## 第二章 住宿标准
一线城市住宿标准为每晚 500 元，其他城市为每晚 350 元。

## 第三章 提交时限
出差结束后 30 个工作日内提交报销单。
EOF

cat > docs/远程办公指引.md <<'EOF'
适用范围：签订正式劳动合同满 6 个月的员工
生效日期：2026-01-15
负责人：人力资源部

# 远程办公指引

每月可申请远程办公不超过 4 天，需提前 2 个工作日在系统提交。
核心协作时间为工作日 14:00–18:00，需保持在线。
EOF

三份文档的分工是：一份现行版、一份已作废的旧版（数字故意和现行版不同）、一份完全无关的文档，用来看它会不会乱抓。三份都按第 4 步的规范补了文档头部：适用范围、生效日期、负责人、失效条件。

接着把「提示词」第三段存成系统提示词，末尾追加三个问题：

cat > system.txt <<'EOF'
你是本团队内部知识库的问答助手。回答必须遵守以下规则：
1. 只使用我提供的文档片段作答，不得使用你的通用知识补全。
2. 每一个结论后面标注来源：文档名称 + 章节定位。
3. 如果文档不足以回答，直接说"现有文档里没有这个信息"，并说明还需要什么材料。
4. 如果多个片段互相矛盾，把冲突原样呈现，并按"生效日期"较新的优先。
5. 涉及金额、期限、比例、审批层级时，必须逐字引用原文，不得改写。
不要为了显得有帮助而扩展回答范围。说"不知道"是正确行为。

请依次回答下面三个问题，每个问题单独成段：
Q1：一线城市住宿一晚最多能报多少？
Q2：报销单最晚什么时候交？
Q3：出差期间的市内交通费怎么报？
EOF

三个问题分别对应评测集里的三类题：Q1 答案在文档里，但新旧两版数字不同；Q2 同样有冲突；Q3 三份文档全都没写。

第二步：跑起来

把系统提示词和三份文档拼成一个输入文件，再一次性调用：

{ cat system.txt; echo; for f in docs/*.md; do echo "===== 文档：$f ====="; cat "$f"; done; } > input.txt
claude --model sonnet -p "$(cat input.txt)"

查看大图

×

终端窗口：列出三份演示文档，把系统提示词和文档合并成 input.txt，调用 claude，输出里 Q1 指出版本冲突并逐字引用两版金额，Q3 直接回答现有文档里没有这个信息

图 3：这一节命令的实际终端输出。看 Q3 那一段——它没有编，而是说清楚了缺什么材料。

第三步：读结果

输出节选：

Q1：存在版本冲突，按"生效日期"较新的优先：
- 《差旅报销制度-v3.md》（生效日期：2026-03-01，现行版本）第二章"住宿标准"：
  "一线城市住宿标准为每晚 600 元，其他城市为每晚 400 元。超标部分需部门负责人书面批准。"
- 《差旅报销制度-v2-已作废.md》（生效日期：2025-06-01，已作废）第二章"住宿标准"：
  "一线城市住宿标准为每晚 500 元，其他城市为每晚 350 元。"
结论：以 v3 的"每晚 600 元"为准，两版数字存在差异，提示用户注意版本冲突。

Q3：现有文档里没有这个信息。提供的三份文档均未提及市内交通费的报销标准或流程。
需要补充包含"市内交通费"相关条款的报销制度文档才能回答。

三件事按预期发生了。

冲突被摆出来，而不是被抹平。 它没有二选一了事，而是把两个版本的原话都列出来，说明为什么取新版，并明确提醒存在版本冲突。这正是文档头部里那行「生效日期」换来的——去掉它，模型就只能猜哪份新。

金额和期限是逐字引用的。 600 元、400 元、15 个工作日，都带着原文和章节定位，可以直接点回去核。系统提示词里「涉及金额、期限、比例、审批层级时必须逐字引用原文」这一条不是装饰。

Q3 是拒答，而且说清楚了缺什么材料。 这一条最值钱：市内交通费是个非常合理的问题，模型完全有能力编一段「实报实销、需提供发票」的标准答案，听起来毫无破绽。它没编，是因为提示词里明确允许它说不知道。你的评测集里那两成拒答题，测的就是这一个行为。

顺带一提，那份无关的《远程办公指引》全程没有被拉进任何一个答案里——三份文档的规模下这不算什么，但等文档到几百份时，这就是「什么都塞进去」会毁掉的东西。

输入素材

• 20 条以上的真实问题（来自新人、客服记录、你自己的查找历史）
• 候选文档，并且已经确认过哪一份是当前有效版本
• 每类文档的负责人名单
• 一份术语表：内部黑话、产品代号、部门简称，这些是检索失败的高发区
• 权限边界说明：哪些文档不能进全员可见的库
• 会议录音或培训视频（如果知识大量存在口头传递中）
• 一个愿意花两小时陪你测的真实用户

最终结果

• 一个可问答的知识库，回答带出处，缺资料时会拒答
• 一份评测集与本轮分数，作为后续改动的基线
• 一份「必需文档清单」，标明哪些文档缺失、由谁补
• 统一的文档头部规范，新文档进库有章可循
• 一张维护责任表：文档类别、负责人、复核周期、下线规则
• 一份「本库不回答」的边界说明，贴在入口处

时间成本

以 100 到 300 份文档、小团队规模估算：

真正的时间消耗在筛文档和预处理，也就是那些看起来最不像 AI 的部分。任何跳过这两步的演示，用的都是本来就干净的资料。

费用

• 托管路线：多数团队的实际支出接近零——文档平台的问答能力通常包含在已有订阅里，轻量方案有免费额度。这条路线的成本主要是人力。
• 自建路线：三块可变成本——把文档转成向量的一次性嵌入成本（和文档总量成正比，通常是整个项目里最便宜的一项）、向量存储的常年费用、每次提问的生成成本（和使用频率成正比）。三项之外还有一台机器或一个托管服务的固定开销。
• 真正的大头是人力维护：文档复核、新增文档入库、失效文档下线。按每月半天到一天估算，这笔账在立项时就该算进去，否则知识库会在半年内自然死亡。
• 可以省钱的地方：把「问答」和「摘要」分开——高频简单问题用便宜的小模型，复杂归纳才调贵的模型；重复问题做缓存，相关背景见 Prompt Caching。

失败情况

图 4：七种典型失败与止损动作。前三种发生在入库之前，第四五种发生在调优阶段，最后两种发生在上线之后——这三段都要有人盯。

一、什么都塞进去。 直觉上文档越多越好，实际相反：无关文档会挤占检索结果的位置，把正确段落排到后面去。一个有 3000 份文档但只有 200 份相关的库，表现通常不如只装那 200 份。

二、同一份制度有三个版本。 这是内部知识库最普遍的问题。表现是同一个问题问两次给出不同金额。这不是模型的错——你的资料本身就是矛盾的。入库前必须认定权威版本，旧版移出而不是留着「以防万一」。

三、扫描件没做识别。 一份图片型 PDF 上传后看起来一切正常，但检索永远命中不了。判断方法：在阅读器里试着选中文字，选不中就说明里面没有文本层。

四、不会拒答。 这是最危险的一种失败，因为它看起来最像成功——回答流畅、格式漂亮、完全是编的。防御手段有两个：系统提示词里明确允许并要求拒答；评测集里放两成没有答案的题，专门测这个行为。相关背景见幻觉词条。

五、没有评测集就开始调优。 表现是反复调整、感觉时好时坏、最后不知道停在哪个配置。二三十道固定题就能解决这个问题。

六、上线即巅峰。 知识库不像网站，坏掉的时候没有报错——它只是开始给出过期的答案，而提问的人默认它是对的。这比不上线更危险。文档头部的「最后复核日期」和责任人，就是为了让这件事可见。

七、权限没隔离。 薪酬表、未公开的战略文档、客户合同被顺手拖进了全员知识库，然后任何人问一句就能拿到。正确做法是分库，而不是靠标签或提示词去限制——提示词不是权限系统。

替代方案

如果你只有几十份文档：不需要知识库。直接把相关文档丢进一个长上下文模型的对话里，效果往往更好，因为它读的是全文而不是片段。这条路的边界见长上下文模型真的更强吗？失效场景实测分析。

如果问题高度集中：统计一下，如果八成提问集中在十几个问题上，那么人工写一份三十条的问答手册，价值高于任何检索系统，而且维护成本低得多。先做这个，剩下的长尾再考虑知识库。

如果你要查的是结构化数据：库存、订单、报表这类问题不该问文档。让 AI 生成查询语句去查数据库，准确率和时效性都不是一个量级。

如果数据完全不能出内网：走本地模型加自建向量库的路线。代价是效果通常低于云端方案，且需要一个真正懂运维的人长期维护。

这是「AI 任务清单」系列的第一篇公开稿，其余几篇（用 AI 阅读和整理 PDF、做产品调研、搭建一个网站等）会陆续放出。想更深入了解检索侧的取舍，可以先看向量检索、BM25、Hybrid Search 应该怎么选？与RAG 为什么答不准？10 个工程原因和解决方案。