# Knowledge Distillation

> 通用知识沉淀能力 - 提供从项目交付过程中提炼可复用经验、教训和模式的标准化方法论，包括信息收集、精简提炼、结构化输出。不绑定任何特定工作流或存储方式。当用户说"帮我做知识沉淀"、"总结一下这次需求的经验"、"记录一下踩坑"、"沉淀一下这次的技术决策"、"做个复盘"时使用本技能。

- Skill: `tencent/knowledge-distillation-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tencent/knowledge-distillation-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tencent/knowledge-distillation-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tencent (https://skillmd.com/u/tencent)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tencent/knowledge-distillation-2

---


# 通用知识沉淀能力

提供一套标准化的知识沉淀方法论，帮助从项目/需求交付过程中系统性地提炼可复用的经验、教训和模式。本 skill 关注**知识提炼方法本身**，不绑定任何特定的存储位置、项目管理工具或工作流。

---

## 适用场景

- 需求/项目交付完成后，提炼可复用的知识
- 技术攻关后，记录关键决策和踩坑经验
- 代码改造后，沉淀可复用的改造模式
- 定期回顾，梳理团队知识资产

---

## 核心流程

### Step 1: 信息收集

回顾交付过程中的各阶段产物和记录，提取有沉淀价值的信息：

| 信息来源 | 关注要点 |
|---------|---------|
| 需求分析产物 | 需求理解中的关键决策、澄清的歧义、识别的边界条件 |
| 技术方案产物 | 架构决策理由、方案取舍原因、技术选型考量 |
| 代码实现产物 | 实现中遇到的坑、关键改造模式、巧妙的解决方案 |
| 测试产物 | 发现的缺陷模式、易出错的场景、测试方法的有效性 |
| 审核/评审记录 | 被打回的原因、修订内容、评审中提出的关键问题 |
| 沟通记录 | 用户/干系人补充的关键上下文信息 |

### Step 2: 筛选与提炼

对收集的原始信息进行筛选和精炼，每条知识点必须满足以下标准：

| 标准 | 要求 | 反例 |
|------|------|------|
| **可复用** | 对后续类似场景有参考价值 | "本次需求的截止日期是 X" |
| **具体明确** | 包含具体的模块名、函数名、技术术语等上下文 | "某个模块有个坑需要注意" |
| **结论导向** | 直接写结论和做法，不记录过程讨论 | "经过 3 轮讨论最终决定..." |
| **精简** | 每条 1-3 句话，直击要点 | 大段复制粘贴原始产物内容 |

### Step 3: 分类组织

将提炼的知识点按类别组织：

| 类别 | 内容范围 | 举例 |
|------|---------|------|
| **业务知识** | 业务规则、模块职责、数据流向 | "X 表的 Y 字段由外部程序写入，不在本系统控制范围内" |
| **技术决策** | 架构选型、方案取舍及其理由 | "选择序列表方案而非 Redis 方案，因为需要事务内原子操作" |
| **改造模式** | 可复用的代码改造范式 | "通用化函数设计：接受 table_name/id_column 参数，支持多业务类型" |
| **踩坑记录** | 易错点、陷阱、注意事项 | "GBK 编码文件中不能使用 UTF-8 特殊字符，否则编译失败" |
| **流程改进** | 对工作流程的改进建议 | "审核标准应增加 X 检查项，本次因遗漏导致返工" |

### Step 4: 结构化输出

按照下方模板输出知识沉淀结果，并写入用户指定的文件路径。若用户未指定路径，询问保存位置。

---

## 知识沉淀输出模板

```markdown
## {需求/项目标识} - {标题} ({日期})

### 业务知识
- {从需求分析中提炼的业务规则、模块职责、数据流向等}

### 技术决策
- {架构选型理由、方案取舍、为什么选 A 不选 B}

### 改造模式
- {代码改造中总结的可复用模式/范式}

### 踩坑记录
- {实现/测试过程中遇到的坑、易错点、注意事项}

### 流程改进
- {本次流程执行中发现的改进点}
```

> 如果某个类别没有值得沉淀的内容，该类别可省略。
> 如果本次交付整体没有新的知识点（如简单配置变更），输出一条简要记录说明。

---

## 写入规则

1. **追加不覆盖**：每次沉淀追加新章节，不修改或删除已有条目
2. **幂等安全**：同一需求/项目多次沉淀时，检查是否已存在对应章节，避免重复
3. **版本化**：沉淀产物应纳入版本控制，确保可追溯

---

## 知识质量自检

沉淀完成后，检查以下要点：

- [ ] 每条知识点是否满足"可复用、具体明确、结论导向、精简"四个标准？
- [ ] 是否遗漏了重要的决策理由或踩坑经验？
- [ ] 知识点的分类是否准确？
- [ ] 是否包含了足够的上下文信息，让不了解本次需求的人也能理解？
- [ ] 是否有大段复制粘贴原始产物的情况？（应提炼为精简结论）

---

## 关键原则

1. **宁缺毋滥**：只沉淀真正有复用价值的知识，不为了填充而凑数
2. **具体到位**：包含具体的技术术语、模块名、函数名，让知识可操作
3. **结论优先**：直接给出结论和最佳实践，不记录冗长的讨论过程
4. **持续积累**：每次交付都追加，逐步构建团队知识资产
5. **可检索性**：使用清晰的标题和分类，便于后续检索和引用