本文へ移動
cccskills
無料GitHub で公開

knowledge-distillation

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

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.0 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

通用知识沉淀能力

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Add or maintain CodeBuddy hook observability for projects that need local metrics for tool latency, transcript token usage, session cost, and multi-agent trace attribution. Use when wiring hook-based telemetry, debugging missing usage events, and validating AgentLens state.

日本語の概要は準備中です。原文の説明を表示しています。

Tencent/LoopForge542026年10月14日 更新

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

日本語の概要は準備中です。原文の説明を表示しています。

Tencent/LoopForge542026年10月14日 更新

devflow

無料

在用户明确要求结构化、可恢复、多阶段的软件交付流程,或要求按 devflow 继续已有任务时使用。覆盖任务分级、需求、设计、计划、实现、设计稿还原、代码审查、测试、固定产物归档、知识沉淀和预览部署;适用于不同 Agent、语言、框架和仓库。普通的一次性小改、单独问答或无需流程编排的代码操作不应仅因属于软件开发而自动触发。

日本語の概要は準備中です。原文の説明を表示しています。

Tencent/LoopForge542026年10月14日 更新

在技术设计前澄清软件交付需求,解决重要产品决策、隐含假设、范围边界、成功标准和未决分支。用于 DevFlow medium/large 的 REQUIREMENT 阶段,或功能请求过于模糊、无法安全设计时。只询问无法从项目证据中回答的问题;不实现、不提交、不写技术方案,也不调用计划类 skill。

日本語の概要は準備中です。原文の説明を表示しています。

Tencent/LoopForge542026年10月14日 更新

在 Codex 中运行 devflow。用户提到 devflow、start/resume/status/abort devflow、多 agent 工作流,或要求“按 Codex devflow 跑”时使用。

日本語の概要は準備中です。原文の説明を表示しています。

Tencent/LoopForge542026年10月14日 更新

通用知识沉淀能力。用于从 devflow 或其他交付过程的需求、设计、实现、审查、测试产物中提炼可复用经验、技术决策、踩坑记录和流程改进。

日本語の概要は準備中です。原文の説明を表示しています。

Tencent/LoopForge542026年10月14日 更新

Tencent のスキルをすべて見る

このスキルの問題を報告する