knowledge-distillation

# 通用知识沉淀能力 提供一套标准化的知识沉淀方法论，帮助从项目/需求交付过程中系统性地提炼可复用的经验、教训和模式。本 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. **可检索性**：使用清晰的标题和分类，便于后续检索和引用