knowledge-distillation

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

通用知识沉淀能力

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

---

适用场景

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

---

核心流程

Step 1: 信息收集

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

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

Step 2: 筛选与提炼

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

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

Step 3: 分类组织

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

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

Step 4: 结构化输出

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

---

知识沉淀输出模板

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

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

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

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

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

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

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

---

写入规则

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

---

知识质量自检

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

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

---

关键原则

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