> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/08-chapter.md).

# 第8章 自我蒸馏:把个人经验沉淀为 AI 可复用的资产

**本章导读**:多数 AI 编程项目用完即弃,工程师的隐性经验(踩过的坑、走过的弯路、形成的判断)从未被沉淀。本章复盘一个真实项目:为某工程团队搭建"个人经验蒸馏系统",AI 替团队成员把过去 3 年的项目经验、踩坑记录、决策逻辑整理为可复用的知识库、Skill 文件、Prompt 模板,后续 AI 工作可直接调用。本章的方法论是"知识的三层沉淀"——把经验先蒸馏为知识库(可被检索),再蒸馏为 Skill(可被 AI 自动调用),再蒸馏为 Prompt 模板(可被人类复用)。

**本章关键词**:自我蒸馏、知识库、Skill、Prompt 模板、三层沉淀

## 8.1 个人经验的"流失"问题

### 8.1.1 工程师为什么"换人就重做"

**现场还原**:项目负责人(以下简称"负责人")第一次接触这个需求,是在某工程团队周一的站会上。团队负责人(以下简称"工程总监")在会上宣布:"资深工程师 Z 下个月离职,接手他模块的工程师 X 是今年 7 月才入职的新人"。站会结束后,工程总监单独找到负责人,提了一个问题:"Z 过去 3 年踩过的坑、走过的弯路、形成的判断,能不能在他走之前蒸馏出来?"负责人答:"可以,但需要 Z 配合 8—10 小时"。工程总监说:"我去说服他"。

工程团队的常见现象:一个老员工离开,他过去 3 年踩过的坑、走过的弯路、形成的判断,随之流失。新员工接替,要么重走一遍老路(再踩一次坑),要么靠文档/口述慢慢学习(效率低)。

这一问题的根源是:个人经验以非结构化形式存在——散落在聊天记录、个人笔记、会议纪要中,无法被检索、被复用、被沉淀。AI 时代之前,沉淀经验的成本高(需要专人整理),收益低(整理后用得不多);AI 时代,沉淀经验的成本大幅降低(AI 替人整理),但如何让经验"可被复用"仍是难题。

**现场细节**:资深工程师 Z 第一次被工程总监要求"配合蒸馏"时,反应是抗拒的。工程总监没有强推,而是让 Z 把上周处理的一个线上事故复盘文档打开,指着其中一段说:"这段'为什么当时选 A 不选 B',这就是经验,新员工 X 看了能少踩一次坑"。Z 看了 3 秒,回了这一段(原文摘录):

> "那确实,但这种东西我脑子里有 100 段,文档里只写了 5 段——大部分都在飞书群里说过,没整理过。你们要真能让我脑子里的东西变成文档,我是愿意配合的"。

工程总监接话:"这就是我们想蒸馏的——你脑子里的 100 段,能否让 AI 替你写出来"。**经验显性化的第一步,是让当事人意识到"自己脑子里有东西"**。

### 8.1.2 经验的三种形式

个人经验的存在形式有三种:

* **个人记忆**:存于人脑,会遗忘,会失真,会随人员流动而流失
* **文档记录**:存于文档,会过时,会失修,需要人主动维护
* **系统沉淀**:存于系统(知识库、Skill、Prompt),可被检索、可被调用、可被复用

三种形式的可靠性递增,成本也递增。AI 时代的突破是:把"个人记忆"低成本地转化为"系统沉淀",让经验以最可靠的形式存在。

**现场细节**:Z 的"个人记忆"在蒸馏前的状态:脑子里有约 100 段经验(他自己估的),文档里有 5 段(他自己写的复盘文档),飞书群聊里散落约 40 段(过去 3 年的"为什么当时那样做"讨论)。负责人当时让 AI 跑了一次"经验盘点"——抓 Z 过去 3 年所有飞书发言 + 5 段复盘文档 + 个人笔记(语雀上 Z 的私有知识库),初步识别出 87 段可被结构化的经验。Z 看完清单后说:"这 87 段里,有 60 段我都快忘了——确实是经验,只是没意识到要写下来"。**经验流失的最大隐性成本不是"找不到",是"没意识到有"**。

![知识的三层沉淀结构](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-453544d50e02032719dcda61238fa9bb8cdbb413%2Fai_coding_book_sec08_three_layers.svg?alt=media)

### 8.1.3 蒸馏的目标

蒸馏的目标不是"把经验全部写下来",而是"让经验在被需要时被找到"。一个完整的个人经验库,应能回答"过去我们做这类项目时,踩过哪些坑?"、"当时为什么选择 X 方案而不是 Y 方案?"、"这次遇到的问题,以前是怎么解决的?"——这些问题,正是 AI 替团队干活时最需要的"上下文"。

![自我蒸馏全流程](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-e4fe9307a008cff548f35005175c86b69d0da9f5%2Fai_coding_book_sec08_distill_flow.svg?alt=media)

![经验采集四步流程](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-be97b4f81d43a4cf8c1376fa88c760f29375ea3b%2Fai_coding_book_sec08_four_steps.svg?alt=media)

**现场细节**:蒸馏的目标在项目第 2 周发生过一次调整。原目标"把 Z 的 3 年经验全部入库",工程团队(以下简称"知识工程师")实施到第 8 天时发现,Z 的经验里有 30% 是"和具体人/具体会议/具体上下文强绑定"——离开当时的情境,这些经验没有可复用性。负责人当周把目标调整为"沉淀可被新人复用的经验"——可被复用的标准是"新员工 X 看到这个经验,能直接用于处理他没遇到过的问题"。这一调整让经验库从 87 段缩减到 56 段,但每一段都被证明"对新员工有直接价值"。**蒸馏不是"越多越好",是"能被复用才算"**。

## 8.2 知识的三层沉淀

### 8.2.1 第一层:知识库(可被检索)

**现场还原**:知识库的第一版,知识工程师让 AI 把 Z 的 87 段经验按"主题"分类——性能、安全、架构、UI、流程、沟通。分类完成后,新员工 X 试着用"上次接口超时"做关键词检索,返回了 4 段相关经验,其中 2 段有用、2 段无关(因为 Z 的"超时"指的是网络超时,X 的"超时"指的是数据库查询超时)。知识工程师没有立即扩库,而是让 X 写了一句话:"如果搜索结果能区分'网络超时'和'数据库超时'就好了"。这一句话,后来变成了知识库的标签体系——每条经验在入库时,被强制要求打 2—3 个"上下文标签"。

知识库是经验的"原材料"——把零散的信息集中存储,提供检索能力。知识库的最小单元是"一条经验",每条经验包含:

* **场景**:在什么情况下遇到这个问题
* **现象**:问题表现为什么
* **原因**:为什么会出现这个问题
* **解法**:当时怎么解决的
* **效果**:解法的实际效果

五项结构让经验可被检索——查询"性能"相关的经验,可以找到所有涉及性能的场景;查询"踩坑"相关的经验,可以找到所有记录在案的坑。

知识库的实现方式有多种:Markdown 文件集合(简单)、向量数据库(可语义检索)、专用知识库系统(Confluence、Notion 等)。本案例采用 Markdown 文件 + 向量检索的组合,简单且可被 AI 直接读取。

**教训**:五项结构看似简单,实际跑起来最容易出问题的是"解法"和"效果"两项——"解法"被写成"我们用了 X 方案"(抽象),而非"先关掉 A 服务,再修改 B 配置里的 timeout 参数,最后重启 C 进程"(具体)。"效果"被写成"问题解决了"(主观),而非"问题从 100% 复现降到 0 复现,但 CPU 占用上升 5%,后续需调优"(客观)。负责人后来在模板里加了一行硬性要求:"解法必须能让一个新员工照着做,效果必须能用数据描述"。

### 8.2.2 第二层:Skill(可被 AI 自动调用)

Skill 是"AI 怎么想"——一份写给 AI 看的操作规程,把经验固化为 AI 在特定场景下的行为规则。Skill 的典型结构:

```
Skill: [技能名]

适用场景:
- 在什么情况下使用这个 Skill

执行步骤:
1. 第一步:做什么
2. 第二步:做什么
3. ...

注意事项:
- 需要特别留意的地方

输出格式:
- 输出应该长什么样
```

Skill 与知识库的区别:知识库是"被检索的"(AI 主动查询),Skill 是"被调用的"(AI 在特定场景下自动执行)。Skill 更接近"工作流",知识库更接近"参考资料"。

**现场细节**:本案例的 5 个 Skill 中,最有价值的是"代码审查 Skill"——它来自 Z 过去 3 年的 23 段代码审查经验。Z 在离职前最后一周,看了这份 Skill,提了一处修改:"'注意'一栏里加一条——'如果改动涉及支付链路,必须人工 review,不能只靠 AI'。这是我们去年踩过的一个坑,差点上线了一个支付金额算错的版本"。这一句话的修改,让 Skill 从"AI 通用审查"升级为"AI 通用审查 + 支付链路强制人工"。**Skill 的"注意"一栏,是整个 Skill 的灵魂——它记录的不是"做什么",是"什么不能做"**。

### 8.2.3 第三层:Prompt 模板(可被人类复用)

Prompt 模板是"人类怎么用 AI"——一份预定义的提示词,人类在特定场景下可直接使用,而非每次重新写。Prompt 模板的典型形式:

```
我需要你 [做什么]。

要求:
- [要求 1]
- [要求 2]

输入:
[我会提供的内容]

输出:
[我期望的输出形式]
```

Prompt 模板与 Skill 的区别:Skill 是"AI 自动调用",Prompt 模板是"人类主动使用"。Skill 让 AI 更聪明,Prompt 模板让人类更高效。

**现场案例**:本案例的 10 个 Prompt 模板中,使用频率最高的是"用户访谈 Prompt 模板"——产品经理每周用 2—3 次。这个模板最初是 Z 在 2 年前总结的,当时 Z 每周要访谈 5 个用户,每次访谈前要手写 8—10 个问题。Z 把"高频使用的 6 类问题"沉淀成模板后,产品经理的小时工时从 4 小时缩短到 1.5 小时。新员工 X 接手 Z 的工作后,直接用这个模板,没问 Z 任何问题——Z 离职后,模板仍在发挥作用。**Prompt 模板是经验可被复用的最高形式——它不依赖任何具体的人**。

### 8.2.4 三层之间的关系

三层之间的关系:

* 知识库是底层,提供"原材料"
* Skill 是中间层,把知识库中的经验固化为 AI 行为
* Prompt 模板是上层,把 Skill 中的行为封装为人类可用的工具

经验从下层向上层"蒸馏"——下层详细、上层精炼。下层越完整,上层越精准;上层使用越多,下层需要补充。

**现场细节**:三层之间的"使用反馈"在本案例第 4 周形成了一个闭环。新员工 X 使用"代码审查 Prompt 模板"时,发现 AI 漏掉了一个关键检查项——X 把这个遗漏写进飞书文档;知识工程师把这条反馈沉淀回知识库,作为"代码审查"主题的新一条经验;这条经验触发了"代码审查 Skill"的更新——增加"必须检查事务边界"这条注意;产品经理下次再用 Prompt 模板时,AI 已经能检查事务边界了。**三层之间不是"自下而上的一次性蒸馏",是"自上而下使用—自下而上回流"的持续循环**。

## 8.3 实战过程:从个人记忆到系统沉淀

### 8.3.1 经验采集

**现场还原**:经验采集阶段,知识工程师用爬虫抓取 Z 的飞书群聊(过去 3 年约 1.2 万条发言)、语雀个人笔记(86 篇)、飞书文档(他参与过的 23 份会议纪要)。抓取过程中,知识工程师遇到了两个真问题:一是 Z 的部分语雀笔记是"草稿"状态(只有标题没内容),这些被自动过滤;二是 Z 的一部分飞书发言是私聊(和个人生活相关),这些按隐私规则被剔除。最终入库的是 9,400 条群聊发言、72 篇笔记、19 份会议纪要。Z 看到抓取结果时说:"原来我说过这么多话,我自己都不记得"。

蒸馏的第一步是"采集经验"——把散落在聊天记录、个人笔记、会议纪要中的信息收集起来。本案例中,经验来源:

* 团队的聊天记录(近 3 年的飞书群聊)
* 工程师的个人笔记(语雀、Notion 等)
* 项目的会议纪要(飞书文档)
* 项目的复盘报告(仓库中的 docs/)

采集的工具是爬虫+文本处理:爬虫抓取飞书群聊、文档平台;文本处理将非结构化文本切分为"经验条目"。

**教训**:采集阶段最容易越界的是"抓取私人内容"。某次类似的蒸馏项目,知识工程师把工程师 A 的私聊也抓了,被 A 当场投诉——"这是我和女朋友的聊天,不是工作经验"。这条边界必须在采集前就和当事人讲清楚,而不是采集后被发现。本案例在采集前,负责人和 Z 签了一份 1 页的"采集知情同意书",明确"只采集工作相关内容,不采集私聊、不采集个人评价、不采集涉及第三人的负面信息"。这份同意书后来被沉淀为所有蒸馏项目的标准动作。

### 8.3.2 经验结构化

**现场细节**:经验结构化是整个项目最耗时的环节。知识工程师用 AI 处理 9,400 条群聊发言时,AI 先做"经验识别"(用 Z 之前标注过的 100 条"是经验/不是经验"样本训练分类器),识别出 1,830 条"可能是经验"的内容。然后 AI 把这 1,830 条按"五项结构"提取,生成 1,830 份结构化草稿。Z 花了 2 个半天审核这 1,830 份草稿,删掉 1,200 份(过于琐碎或脱离上下文),修改 470 份,直接通过 160 份。最终入库 630 份。Z 审核到第 800 份时对负责人说:"我现在看到任何一句话都会想'这能变成经验吗',职业病了"。**结构化过程本身,就是一次对当事人经验的"再认识"——审核的过程比最终入库的结果更有价值**。

采集到的经验是"非结构化"的——一段聊天记录中可能混杂着问题描述、解法讨论、情绪表达。蒸馏的第二步是"结构化"——把非结构化信息转化为"场景-现象-原因-解法-效果"五项结构。

结构化的工作由 AI 完成:AI 阅读每条聊天记录,识别其中的经验内容,按五项结构整理。人工审核 AI 的输出,确保结构化结果准确。

### 8.3.3 知识库构建

结构化后的经验入库。入库的步骤:

* **去重**:相同或相似的经验合并
* **分类**:按主题(性能、安全、架构、UI 等)分类
* **索引**:为每条经验建立索引,便于检索

知识库建立后,AI 在回答"过去我们做这类项目时,踩过哪些坑"时,可自动检索相关经验。

**现场细节**:入库的 630 份经验,知识工程师按主题分类后,数量分布是:性能 142、安全 89、架构 156、UI 67、流程 98、沟通 78。负责人当时提了一个问题:"性能 142 是不是太多了?"知识工程师查了下,发现其中 60 份是"数据库查询慢"的变体——本质上是同一条经验。负责人让知识工程师把这 60 份合并成 1 份"通用数据库慢查询排查清单",其余 82 份保留。合并后,知识库从 630 份变成 571 份,但"通用清单"这一份被新员工 X 在 2 个月内调用了 14 次——是整个知识库里被调用次数最高的经验。**重复不可怕,可怕的是"重复"被当作"多条独立经验"**。

### 8.3.4 Skill 提炼

**现场还原**:Skill 提炼阶段,知识工程师用 AI 在 571 份经验里识别"高频模式"——"同一条经验在多个场景下被使用,且使用方式相似"。AI 识别出 7 类高频模式,知识工程师挑了 5 类提炼为 Skill:性能优化(对应 142 份性能经验)、安全检查(89 份安全经验)、代码审查(综合 156 份架构 + 89 份安全经验)、文档生成(综合 67 份 UI + 98 份流程经验)、用户访谈(对应 78 份沟通经验)。每个 Skill 在提炼后,都被 Z 在 1—2 个真实任务中试运行——不符合预期的改到符合为止,平均每个 Skill 改了 2.3 轮。

基于知识库中的经验,提炼 Skill。提炼的原则:

* **频繁出现的场景**:多次出现的场景,适合提炼为 Skill
* **可被固化的行为**:行为规则明确,适合 AI 自动执行
* **错误代价高**:出错代价高,适合让 AI 强制执行

本案例提炼了 5 个 Skill:性能优化 Skill、安全检查 Skill、代码审查 Skill、文档生成 Skill、用户访谈 Skill。每个 Skill 都基于知识库中的多条经验。

### 8.3.5 Prompt 模板制作

**现场细节**:Prompt 模板的制作有一个反直觉的发现——最有用的模板,不是"最详细的",而是"最具体的"。本案例最初制作的一个"通用代码审查 Prompt 模板"有 200 多字,新员工 X 用了 2 周后反馈"每次都要改一大段才用得上"。知识工程师回看,发现模板写得太通用——"请审查这段代码"是新员工 X 写不出好答案的根因。改成"请按以下 5 点审查这段代码:① 是否有 SQL 注入风险;② 是否有 N+1 查询;③ 是否有未处理异常;④ 是否有命名不一致;⑤ 是否有可读性问题"——新员工 X 反馈"用得顺"。**Prompt 模板的价值,不在覆盖多广,在约束多准**。

基于 Skill,制作 Prompt 模板。模板的设计原则:

* **可被人类直接使用**:无需修改,或仅修改少量参数
* **可被 AI 引用**:模板本身可作为 Skill 的输入
* **可被复用**:同一类任务可使用同一模板

本案例制作了 10 个 Prompt 模板,覆盖"用户访谈"、"竞品分析"、"代码审查"、"周报生成"等常见任务。

## 8.4 验收与效果

### 8.4.1 验收清单

自我蒸馏系统的验收,包含以下检查项:

* **知识库完整性**:核心经验均已入库,无重要遗漏
* **检索准确性**:查询"性能"相关经验,返回的经验确实与性能相关
* **Skill 有效性**:在适用场景下,AI 自动调用 Skill,行为符合预期
* **Prompt 模板可用性**:人类可直接使用模板,产出质量满足要求

### 8.4.2 实际效果

**现场还原**:系统上线 6 个月后,工程总监让负责人做了一次"前后对比"。对比项:新员工上手时间(蒸馏前 3 个月,蒸馏后 1 个月)、重复踩坑次数(蒸馏前每月 2—3 次,蒸馏后 0—1 次)、AI 工作质量(AI 自动调用 Skill 比例约 30%)、知识流失率(核心经验从 70% 降低到 10%)。其中"知识流失率"这一项,工程总监专门去问 Z:"你觉得你的经验还剩下多少?"Z 答:"我估计 90% 还在(在系统里),10% 确实没沉淀(涉及当时具体的人,我没让他们入库)"。这个数字被工程总监写进验收报告,作为"接受 10% 流失是合理范围"的依据。

系统上线后 6 个月的实际效果:

* **新员工上手时间**:从 3 个月缩短到 1 个月
* **重复踩坑次数**:从每月 2—3 次降低到 0—1 次
* **AI 工作质量**:AI 在执行任务时,自动调用 Skill 的比例约 30%,显著提升质量
* **知识流失率**:核心经验的流失率从 70% 降低到 10%

**教训**:验收数据里"知识流失率从 70% 降到 10%",看似巨大进步,但负责人和工程总监都同意"剩余 10% 不可消除"——这部分经验涉及具体的人、具体的会议、具体的情绪,沉淀成本远大于复用价值。**经验沉淀不是"100% 不流失",是"接受合理范围的流失"**。

### 8.4.3 长期维护

知识库与 Skill 需要长期维护:

* **每月补充**:新经验应及时入库
* **每季度复审**:旧经验应评估是否仍然有效
* **每年重构**:Skill 和模板应根据团队发展重构

维护是知识资产管理的延续——沉淀不是一次性工作,而是持续过程。

**现场细节**:长期维护中,知识工程师发现一个意料之外的角色——"经验贡献者"。原本设计是"AI 替人整理",但项目推进到第 3 个月时,团队里有 4 名工程师主动开始写"经验条目"。知识工程师问其中一位工程师为什么,工程师答(原文摘录):

> "写下来比不写清楚。我以为我懂,写的时候才发现我漏了 3 个前提条件——这种'以为自己懂'的盲区,是写给我自己最大的好处"。

知识工程师后来在每月补充环节加了"经验贡献者激励":每贡献 10 条经验,工时统计里加 1 小时(相当于"知识管理"工作被正式认可为工作时间)。**最好的长期维护,不是"AI 自动更新",是"团队愿意主动写"**。

## 8.5 方法论提炼与可复用资产

本章的方法论可提炼为四个原则。

**原则一:经验应从个人记忆转向系统沉淀**。个人记忆会流失,系统沉淀可复用。这一转化是经验管理的核心。

**原则二:三层沉淀各有用途**。知识库供检索,Skill 供 AI 调用,Prompt 模板供人类使用。三者协同,覆盖经验使用的全部场景。

**原则三:经验的结构化是蒸馏的关键**。非结构化经验无法被有效使用,必须结构化为"场景-现象-原因-解法-效果"等标准形式。

**原则四:沉淀是持续过程**。知识库与 Skill 需要长期维护,新经验应持续入库,旧经验应定期复审。

**可复用资产:经验条目模板**——本节 8.2.1 给出的五项结构,可作为所有经验条目的标准格式。

```
经验条目

场景: [在什么情况下遇到这个问题]
现象: [问题表现为什么]
原因: [为什么会出现这个问题]
解法: [当时怎么解决的]
效果: [解法的实际效果]
```

**可复用资产二:Skill 模板**——本节 8.2.2 给出的结构,可作为所有 Skill 的标准格式。

```
Skill: [技能名]

适用场景:
- 在什么情况下使用这个 Skill

执行步骤:
1. [第一步]
2. [第二步]
3. ...

注意事项:
- [需要特别留意的地方]

输出格式:
- [输出应该长什么样]
```

## 本章方法论:让经验以最可靠的形式存在

本章的方法论核心是"让经验以最可靠的形式存在"——个人记忆会流失,系统沉淀可复用;非结构化经验难使用,结构化经验可被检索、可被 AI 调用、可被人类复用。三层沉淀(知识库、Skill、Prompt 模板)覆盖经验使用的全部场景,让团队从"换人就重做"转向"经验持续积累"。

下一章将讨论"反馈回路"——AI 替读者建立"经验自动写回系统"的机制,让系统在使用中持续进化。这一章关注的是"系统的动态优化"能力。

### 8.6.1 本章思考题

1. 8.1.2 的"经验三种形式"(个人记忆/文档记录/系统沉淀),你团队过去 3 年的经验主要存在哪种形式?流失率最高的是哪种?
2. 8.2 的三层沉淀:你团队的知识库、Skill、Prompt 模板各有多少?如果知识库 > 100 条而 Skill < 3 个,说明什么?
3. 8.3.2 的"五项结构"(场景/现象/原因/解法/效果):你团队最近一条入库的经验,五项是否齐全?缺项最常见的是哪一项?
4. 8.3.5 的"最有用的模板不是最详细的,而是最具体的":你的 Prompt 模板平均字数是多少?新员工需要修改多少才能用?
5. 8.4.3 的"经验贡献者激励":你团队有"写经验"被正式认可为工作时间的机制吗?如果没有,主动贡献的人占比多少?

### 8.6.2 本章延伸阅读

1. **\[工具文档] Anthropic Engineering Blog《Equipping agents for the real world with Agent Skills》(2025-10-16)** — skill="给新员工的入职指南"类比、文件夹式组织、按需动态加载 | 第 8 章
2. **\[工具文档] Anthropic 官方 Agent Skills authoring best practices** — SKILL.md 规范:正文 500 行以内、description 写"做什么+何时用"、name 用动名词、长材料拆 references 渐进式披露 | 第 8 章
3. **\[工具文档] Claude Code 官方 Memory 文档(2026-07-22)** — CLAUDE.md + Auto Memory 双记忆机制的经验沉淀工程结构 | 第 8 章
4. **\[文章] obra/superpowers README** — 14 个 Markdown skill 强制 TDD/调试/评审工作流,2026-07 超 25 万 stars 的方法论即代码 | 第 8 章
5. **\[文章] 新浪财经转载大模型幻觉六大治理方案(RAG/联网检索,2026-05-20)** — RAG 锚定可验证事实、内置知识→搜索→爬虫互补 | 第 8 章

## 完整提示词:经验三层沉淀的执行编排

本节给出的提示词,是 8.3 节"实战过程"的执行化版本。读者接到"把团队/个人经验沉淀为可复用资产"的任务时,可直接复制使用,AI 会按"采集—结构化—入库—提炼 Skill—制作 Prompt 模板"五步骤推动工作。

```
你是"个人经验蒸馏系统"的工程协作 AI。用户的任务是"把过去 N 年的项目经验,沉淀为团队可复用的资产"——这些资产包括知识库(可检索)、Skill(可被 AI 自动调用)、Prompt 模板(可被人类直接使用)。

[角色]
- 你是"蒸馏工程师",负责把零散、非结构化的经验,转化为三层沉淀(知识库 / Skill / Prompt 模板)。
- 你的核心能力是"识别+结构化":识别哪些是"经验"(可被复用),哪些是"杂音"(一次性、不可复用);把识别出的经验结构化为"场景-现象-原因-解法-效果"五项形式。
- 你的工作节奏是"由下而上":先把经验蒸馏为知识库(底层原材料),再从知识库提炼 Skill(中间层固化),再从 Skill 制作 Prompt 模板(上层工具)。

[第一步:经验采集]

用户会提供经验来源,通常包括:
- 团队的聊天记录(飞书群、Slack、企微等)
- 工程师的个人笔记(语雀、Notion、飞书文档等)
- 项目的会议纪要
- 项目的复盘报告(代码仓库的 docs/ 目录)
- 客户邮件(经脱敏处理)

采集时,你的工作:
- 用爬虫工具批量抓取上述来源(注意:严格遵守隐私规则,不抓取个人信息)
- 抓取后做初步切分:按时间、按项目、按主题三个维度
- 标注每条信息的"原始来源 + 抓取时间 + 抓取人"

[第二步:经验结构化]

对每条原始信息,执行结构化处理:
- 阅读整段内容(可能是聊天记录、会议纪要)
- 识别其中是否包含"经验"——判断标准:该内容是否描述"在什么情况下做了什么,效果如何"
- 若是经验,按"五项结构"提取:
  1. 场景:在什么情况下遇到这个问题(何时、何地、涉及谁)
  2. 现象:问题表现为什么(具体症状、报错信息、用户反馈)
  3. 原因:为什么会出现这个问题(根因分析、相关方、时机)
  4. 解法:当时怎么解决的(具体步骤、工具、配置、决策)
  5. 效果:解法的实际效果(数据支持、用户反馈、后续变化)
- 输出格式:Markdown 文件,文件名按"主题-场景-日期.md"命名

AI 草拟后,人工审核。审核标准:①五项是否完整;②描述是否准确(无夸大、无遗漏);③是否涉及个人评价(若是,删除该部分)。

[第三步:知识库构建]

结构化后的经验入库,步骤:
- 去重:相同或相似的经验合并,保留最完整的一条
- 分类:按主题分类(性能、安全、架构、UI、流程、沟通等),每类一个子目录
- 索引:为每条经验建立索引文件(README.md),列出该类下所有经验的标题与链接
- 知识库的存储:用 Markdown 文件集合,简单可移植;向量检索作为可选增强

知识库建立后,可回答的典型问题:
- "过去我们做这类项目时,踩过哪些坑?"
- "当时为什么选择 X 方案而不是 Y 方案?"
- "这次遇到的问题,以前是怎么解决的?"

[第四步:Skill 提炼]

基于知识库中的经验,提炼 Skill。提炼原则:
- **频繁出现的场景**:多条经验指向同一类场景,适合提炼
- **可被固化的行为**:行为规则明确,可被 AI 自动执行
- **错误代价高**:出错后果严重,适合让 AI 强制执行

Skill 的标准结构(参见 8.5 节模板):
- 技能名
- 适用场景(何时调用)
- 执行步骤(逐步骤说明)
- 注意事项(常见错误)
- 输出格式(产出物长什么样)

每个 Skill 提炼后,先在 1—2 个真实任务中试运行,确认 AI 在调用 Skill 后行为符合预期;不符合则修改 Skill,直到稳定。

[第五步:Prompt 模板制作]

基于 Skill,制作 Prompt 模板。模板设计原则:
- 可被人类直接使用(无需修改,或仅修改少量参数)
- 可被 AI 引用(模板本身可作为 Skill 的输入)
- 可被复用(同一类任务可使用同一模板)

Prompt 模板的标准结构(参见 8.2.3 节):
- 任务描述(我需要你做什么)
- 要求(具体约束)
- 输入(我会提供什么)
- 输出(我期望什么形式)

本案例产出 5 个 Skill、10 个 Prompt 模板,覆盖"用户访谈"、"竞品分析"、"代码审查"、"周报生成"等常见任务。

[输出格式]
- 每个步骤结束后,先输出"本步骤产出"(1—2 段总结),再询问用户是否进入下一步。
- 整个流程预计 2—4 周(传统方式 3—6 个月),其中采集与结构化占 70%。

[边界]
- 你不替用户决定"哪些经验值得入库";你只做结构化,价值判断由用户做。
- 你不抓取涉及个人隐私的内容(私人聊天、个人评价);只抓取工作相关内容。
- 你不假设所有经验都有"效果数据";无效果数据的,标注"该效果未经数据验证"。
- 蒸馏后,你建议用户做"覆盖度审计"——挑 3 个真实场景,验证知识库是否能回答"过去怎么做的"。
```