持续学习

解决的问题

团队里最常见的浪费不是写错代码，而是同一个坑被反复踩：上周 review 里纠正过的 null 判空方式，这周又被同一个 Agent 用错；上次验证过能跑通的缓存封装，下次会话又重新发明一遍。根因在于经验只存在于单次会话上下文里，会话一结束就丢了，新会话从零开始。

技能如何工作

这个技能把「事后复盘」做成固定流程，核心是三个组件：

1. 模式提取框架（Pattern Extraction）

每次重要的编码会话结束后，把学到的东西归入三个桶：

• Corrections（纠正）：review 中或被用户指出的错误
• Successful Approaches（成功做法）：验证有效、值得复用的模式
• Anti-Patterns（反模式）：引发过问题、应当避免的做法

每个条目都要按固定格式书写，并通过置信度评分决定后续行为：

• 0.95+：跨项目验证过，自动应用
• 0.80–0.94：当前代码库内确认，应用时说明来源
• 0.60–0.79：观察到但未充分验证，带保留意见地建议
• 0.40–0.59：基于有限数据的假设，应用前先询问

条目还带有状态标记：VALID 为正常可用；SUPERSEDE 表示用更好的做法取代了旧条目；DEPRECATED 表示曾经有效、现已过时，不再应用。

2. 写入记忆文件

学习条目按置信度分流到项目的 CLAUDE.md 或同类文件中：

• 高置信度（>0.85）写入主指令区，直接影响后续行为
• 中等置信度（0.60–0.84）放入专门的 Learnings 区块
• 低置信度（<0.60）暂留会话笔记，验证通过后再入库
• 废弃条目移入归档区，并注明废弃原因

3. 定期维护

每月评审一次知识库：超过 90 天未被引用且置信度低于 0.70 的条目会被移除，防止记忆文件无限膨胀。

适用边界

这个技能的价值完全取决于复盘的执行质量。如果会话结束不提取、或提取时敷衍了事，记忆文件会迅速变成噪音堆。另外，置信度评分依赖人工判断，跨项目迁移条目时要留意适用前提是否变化。它适用于长期迭代的项目，对一次性脚本这类短命任务意义不大。