---
title: "Claude Code 调用知识库：让 AI 直接读取文档"
description: "文件存在硬盘里不等于用得上。这一节讲清三种递材料的方式、一份任务该引用几份文件，以及怎么确认它真的读懂了。"
updated: 2026-11-13
canonical: https://docai.cc/learn/ai-reads-knowledge-base/
markdown_mirror: https://docai.cc/learn/ai-reads-knowledge-base.md
---
## 文件躺在硬盘里，不会自己进入对话

你花一周整理了产品资料、退款规则和写作规范，目录清清楚楚。下次让 AI 写客户回复，它仍然给出一套通用话术，连你们卖什么都不对。

不是模型不聪明，是它没看到那些文件。每开一个新对话，它通常从空白开始；你递过去什么，它才知道什么。知识库的价值，取决于「递」这一步做得好不好。

## 最省事的一招：在消息里点名

在 Claude Code 的输入框里输入 `@`，会列出当前项目内的文件，选中后随这条消息一起进入上下文；不同入口（终端、IDE、桌面、网页）的按钮位置略有差别，以你用的客户端为准。文件不在项目里时，最稳的做法是先复制进项目目录，再按相对路径引用；部分客户端也支持直接上传附件。

一个能直接用的例子：

```text
@knowledge/产品知识库.md @knowledge/邮件模板库.md
客户投诉物流太慢，要求退款。
请只依据上面两份材料，写一封回复：
- 先回应对方的等待
- 按退款政策说明是否符合条件
- 不承诺材料里没有的规则
```

最后一句别省。材料递到了，模型仍可能顺手发挥；把「只能依据这些」写成明确约束，编造的空间会小很多。

路径写错时，文件往往没有真正附上；模型拿不到内容，就会按通用经验写，表现和没引用几乎一样。

## 把常用背景写进项目说明

同一批文件如果每次都要带，写进项目根目录的说明文件更省事。Claude Code 会读 `CLAUDE.md`，每次启动自动加载，相当于开场先递一张地图。

```markdown
## 知识库在哪
- 产品事实：knowledge/产品知识库.md
- 退款规则：knowledge/退款政策.md
- 写作规范：knowledge/写作规范.md

## 默认要求
- 价格、时效类表述标注「需人工核实」
- 材料没有写的内容，输出「未提及」，不要补全
```

只写「文件在哪、什么任务读哪份」，不要把正文整段搬进来。指针好维护：改了原文件，说明文件不必跟着改。它也不是目录备份——真正有用的是「什么情况读哪份」，按任务场景分组，比罗列整棵文件树有效。

还要注意长度。说明文件每次都进上下文，写得越厚，留给任务的窗口越小，概念见[上下文窗口](/concepts/context-window/)。

## 一份任务要用几份材料

先给每份文件分配角色，再提要求。以竞品分析为例：

> 参考三份材料：`竞品信息.md` 提供对手资料，`产品知识库.md` 提供我方口径，`报告模板.md` 规定输出结构。按功能、报价、客户类型三个维度分析，最后给两条可执行建议。

三条经验：数量控制在三到四份；每份文件后面跟一句用途；把输出结构写清楚，别只说「写好一点」。信息如何分层，可参考[上下文工程](/concepts/context-engineering/)。

材料之间可能互相矛盾，比如旧价格表和最新通知对不上。提前告诉它「冲突时以哪份为准」，比事后逐条纠正便宜得多。

还有一个更隐蔽的坑：同一份规则存了多个副本。项目里一份、聊天记录里一份、同事电脑上还有一份，改了一处，另外两处仍是旧说法。引用前先确认唯一来源，其他位置只留指向它的说明，不要各存一份全文。

## 动笔前先确认它读懂了

材料一长，模型可能只扫了开头。加一步复述，能省下后面的大量返工：

> 先读 `@knowledge/产品知识库.md`，用五条列出核心卖点、主要竞品和不能承诺的事项。我确认后你再开始写。

复述不对，通常是三种原因：路径写错、文件太长被截断、内容结构太乱。先解决这三样，再谈产出。文件特别长时不要整份塞进去，按章节切开，先读目录和这次要用的那一节。

如果回答里冒出材料中没有的数字，别急着重问。换成这句更有效：「每个结论后面标出依据的原句，找不到就写未提及。」错误会自己浮出来。

## 看见之后，还要找得回

把材料递到模型眼前，只是让它「看见」；真正的复利在于下次遇到同类任务时，它还能找到同一份方法——[用知识库解决同类问题](/learn/reuse-knowledge-for-similar-tasks/)。
