---
title: "Claude Code 知识库迭代：持续更新让 AI 越来越懂你"
description: "知识库建好就开始过期。这一节给出三层维护节奏、五个更新信号，以及一套让 AI 帮你做体检的提示词。"
updated: 2026-11-13
canonical: https://docai.cc/learn/iterate-knowledge-base/
markdown_mirror: https://docai.cc/learn/iterate-knowledge-base.md
---
## 建好那天，就是它开始过期的第一天

产品改了名字，退款政策换了口径，审批人也调整了。知识库里的文件还是上个月的样子。你让 AI 按它写回复，文字很顺，细节全错。

比过期更隐蔽的是冗余：同一条规则抄在三个文件里，改了一处漏了两处；文件名越来越随意，找一份材料要翻半天。

知识库的价值不在体量，在可信。维护做的就是把「可信」守住。

## 三种维护节奏

不必搞成项目管理，按频率分三层就够：

**每次任务结束后，五分钟。** 只问两件事：这次有没有发现更快的做法？有没有哪句话被 AI 理解错了？有，就当场改对应文件。趁记忆还热，改动往往只有一两行。

**每周一次，一刻钟。** 翻一遍本周用过的文件，看哪些真的被引用、哪些一次没打开。没打开未必没用，但连续几周无人问津的，值得怀疑。

**每月一次，一小时。** 处理结构问题：合并重复内容、删掉失效段落、给每份文件补上「最后核实」日期、检查目录还能不能一眼找到东西。

季度级别的大整理可以放在业务淡季，不必强求固定日期。节奏是为了防止腐烂，不是为了打卡。如果知识库由团队共用，再补一条规则：谁改动，谁在文末留一行说明。不用开会同步，下一个人翻到就能明白上下文。

## 五个该更新的信号

| 信号 | 动作 |
|---|---|
| 某个提示词最近效果变差 | 回看输出，补上缺失的约束 |
| 平台或模型有了新的接入方式 | 更新操作步骤，注明适用版本 |
| 业务流程改了审批人 | 改流程文档，别只改一处 |
| 发现了更省事的做法 | 替换旧方法，保留旧方法的失效原因 |
| 某份文件半年没被打开 | 归档或删除 |

判断标准可以更简单：**这份文件如果今天被 AI 读到，会不会让它做错事？** 会，就马上改。只是不够漂亮，可以等下次。

## 让 AI 当校对员

维护知识库最枯燥的是通读和比对，这恰好是模型擅长的。它不嫌重复，但上下文装不下时同样会漏读，重要文件仍要人工抽查。把检查任务交给它：

```text
请逐个读取 knowledge/ 目录下的全部文件，输出一份体检报告：
1. 相互矛盾的说法，列出文件与行号
2. 内容重复超过一半的文件对
3. 最后核实日期距今超过六个月的文件
4. 引用已下线功能、路径或流程的段落
只报告问题，不要直接改文件。
```

最后一句要保留。让它先出报告、你决定改不改，比它自作主张安全。报告出来后按影响排序：会让模型说错话的排前面，重复和排版放后面。一次只改三五条，改完顺手验证一次，避免大面积返工又引入新错误。

维护也不是单向付出。每次任务收尾时，让 AI 把过程整理成可追加的一段，你只需审一遍：

> 把刚才这次任务的背景、步骤、有效提示词、遇到的问题整理成一段 Markdown，按知识库现有格式输出，直接可追加。

这比事后回忆省力，也更完整。背景应该怎么组织，可参考[上下文工程](/concepts/context-engineering/)与[结构化知识文档](/learn/structured-knowledge-docs/)。

## 交接时把它交出去

岗位变动时，知识库的去向常被忽略。文件留在旧电脑里，等于白攒。交接前做三件事：给每份文件补一行「最后核实」日期和负责人；写一份一页纸的索引，列出文件、各自解决什么问题、入口在哪；当面演示一次调用过程，看一遍比读十页说明有效。

内容要区分归属。公司业务相关的流程与客户信息留在公司；个人的通用方法可以整理一份带走，但先确认不含保密信息。只服务你一个人的知识库，也别省掉索引——停用三个月再回来，你会需要它。

## 下次打开时它还靠得住

知识库和代码一样，不更新就会腐坏；你维护的不是文档，而是下一次开口时 AI 对你的了解程度。回头看它为什么值得建，也是一种校准：[为什么沉淀工作经验](/learn/knowledge-base-benefits/)。