tencent 通用知识沉淀能力
提供一套标准化的知识沉淀方法论，帮助从项目/需求交付过程中系统性地提炼可复用的经验、教训和模式。本 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}
### 改造模式
- {代码改造中总结的可复用模式/范式}
### 踩坑记录
- {实现/测试过程中遇到的坑、易错点、注意事项}
### 流程改进
- {本次流程执行中发现的改进点}
如果某个类别没有值得沉淀的内容，该类别可省略。 如果本次交付整体没有新的知识点（如简单配置变更），输出一条简要记录说明。
写入规则
- 追加不覆盖：每次沉淀追加新章节，不修改或删除已有条目
- 幂等安全：同一需求/项目多次沉淀时，检查是否已存在对应章节，避免重复
- 版本化：沉淀产物应纳入版本控制，确保可追溯
知识质量自检
沉淀完成后，检查以下要点：
- 每条知识点是否满足"可复用、具体明确、结论导向、精简"四个标准？
- 是否遗漏了重要的决策理由或踩坑经验？
- 知识点的分类是否准确？
- 是否包含了足够的上下文信息，让不了解本次需求的人也能理解？
- 是否有大段复制粘贴原始产物的情况？（应提炼为精简结论）
关键原则
- 宁缺毋滥：只沉淀真正有复用价值的知识，不为了填充而凑数
- 具体到位：包含具体的技术术语、模块名、函数名，让知识可操作
- 结论优先：直接给出结论和最佳实践，不记录冗长的讨论过程
- 持续积累：每次交付都追加，逐步构建团队知识资产
- 可检索性：使用清晰的标题和分类，便于后续检索和引用