Claude Code 文档复用：用知识库解决同类问题

第二次遇到同一个问题，才是分水岭

第一次做员工手册，你摸索了整整一周。半年后换一家公司又要做，脑子里只剩下「当时好像用了某个结构」。于是查资料、试排版，一周再来一遍。

复用不是把旧成果改个名字再用。成果会过时，方法不会。把「怎么做的」留下来，下一次才不必从零开始。

记录也不必长。一页纸能说清输入、动作和验收，就够下次开工；写成十页的总结，反而没人愿意翻。

先判断值不值得记

不是所有事都值得沉淀。用两个维度筛：同类任务会不会再来，流程是否稳定。

值得记	不值得记
每月都要出的报表	一次性的临时通知
有固定审核环节的提案	靠现场判断的沟通
反复被问到的客户异议	很快失效的活动信息
新人必须遵守的规范	只有自己看得懂的备注

一个更快的判据：如果明天重做一遍，你能不能稳定复现同样的质量？能，说明方法已经成型，写下来不会白费。

粒度也要控制。一份记录只覆盖一类任务，别把报价、合同、售后全塞进同一个文件。文件越聚焦，模型越容易判断该不该用；混在一起时，它往往只读标题就下结论。

存放也要有规矩：一类任务一个文件，统一放进 knowledge/tasks/，文件名用动词开头，例如 write-quotation.md、review-contract.md。新建之前先搜一遍关键词，已有同类就补进去；两份同类记录并存久了，说法早晚会打架。

一份能直接照着做的记录

别写成心得，写成别人和 AI 都能照着执行的说明：

# 客户报价单制作
**什么时候用：** 新客户询价，需求已确认
**最后核实：** 2026-11-01

## 输入
- 需求确认邮件
- 产品价格表（路径：...）

## 步骤
1. 按需求勾选产品组合
2. 用报价模板生成初稿
3. 核对折扣权限，超出范围找主管
4. 导出 PDF，文件名：客户名-日期

## 提示词
> 根据这份需求邮件和价格表生成报价单，逐项列出单价与数量。
> 价格表中没有的项留空，不要估价。

## 验收与坑
- 总价必须手算复核一遍
- 折扣超过权限时不能直接发

结构比文采重要。每个分区各管一件事：输入决定它需要哪些材料，步骤规定动作顺序，提示词固定表达方式，验收与坑负责兜底。少了最后一块，输出好坏就只能凭感觉判断。写的时候多用短句和清单，长段落会让模型和你都难以定位。具体写法可以参照结构化知识文档。

调用时让它先选方法

有了记录，别只是把文件丢过去。先让它判断当前情况适合哪一条，再执行：

我要处理一个新客户的询价，对方要三种产品、希望两周内交付。 先读 @knowledge/报价单制作.md 和 @knowledge/折扣规则.md， 告诉我这套流程是否适用、哪一步需要我确认，然后按步骤执行。

先选方法再动手有两个好处：方法不适用时能及时换掉；执行时它知道每一步的验收标准。

如果它回答「这份记录不适用，对方要的是定制方案」，别急着否定。先问清哪一步对不上，往往能补出一条新的分支经验。

这背后是提示词模板的思路：稳定不变的部分固定下来，每次只替换变量。第一次用一份新记录时，先拿旧案例试跑，把结果和你当时的做法对比。差异往往说明记录少写了一步，或者那条经验只适用于特定类型的客户。

失败记录比成功经验更挡坑

「试过批量导出，不行，工具一次只能导出固定条数」这样一句话，能挡住下一次两小时的弯路。成功经验告诉你路怎么走，失败记录告诉你哪条路是死的。

失败记录还逼你把假设写出来。很多错不是方法本身有问题，而是当时默认了一个后来不成立的前提。

更新也别攒。做完一次任务，顺手在文件末尾加一行日期和结论：

## 更新记录
2026-11-02 新增「客户要求拆分交付」的处理方式，放在步骤 2 之后

让一份经验活得久一点

复用让一份经验服务很多次；要让这份经验一直有效，还得有人定期修剪它——持续迭代知识库。