持续学习与模式提炼

核心问题

在长期迭代的项目中，开发者常面临三类认知困境：重复性错误难以根治（同一类逻辑偏差在后续迭代中反复出现）、成功经验缺乏沉淀机制（临时解决方案随会话结束被遗忘）、反模式影响范围失控（低效实践通过代码复制扩散到其他模块）。传统开发流程缺乏系统化的错误归因与模式归档能力，导致团队始终在「试错-遗忘-再试错」的循环中消耗精力。

工作机制

该技能通过模式提取框架构建「编码会话→认知沉淀→规则应用」的闭环：

• 三类知识分类：

- Corrections（修正项）：记录代码审查中暴露的逻辑偏差，例如未处理空指针的边界情况
- Successful Approaches（成功模式）：提炼可复用的架构决策，如异步任务队列的优先级调度策略
- Anti-Patterns（反模式）：标记引发问题的实现方式，例如过度使用单例导致的耦合度飙升

• 置信度评分系统：

- 0.95+：跨项目验证的规则（如HTTP超时重试机制）
- 0.80-0.94：当前代码库内确认的实践（如本项目的ORM查询优化策略）
- 0.60-0.79：需带条件建议的规则（如「建议使用事件溯源模式，但需评估事务边界」）
- 0.40-0.59：待验证的假设（如「可能通过引入缓存提升性能，但需压力测试」）

• 分层存储机制：

- 高置信度规则（>0.85）写入CLAUDE.md主指令区，作为强制约束
- 中置信度规则（0.60-0.84）存入Learnings专区，供后续决策参考
- 低置信度记录（<0.60）保留在会话日志中，等待跨会话验证
- 废弃规则（DEPRECATED）移入归档区，标注替代方案

适用边界

• 不适用场景：一次性原型开发、文档驱动的静态项目、无持续维护计划的实验性代码
• 依赖条件：需要团队维护CLAUDE.md等记忆文件，且成员需理解置信度分层规则
• 实践限制：

- 置信度评估依赖开发者的归因能力，主观偏差可能影响规则质量
- 每月清理策略需配合实际项目节奏，过度清理可能丢失潜在有用模式
- 跨项目迁移时需重新评估规则适用性（如硬件相关优化规则不适用于云原生场景）