/learn-eval

description: 从会话中提取可复用的模式（Patterns），在保存前进行质量自评，并确定合适的保存位置（全局 vs 项目）。

/learn-eval - 提取、评测并保存

通过增加质量闸门（Quality Gate）和保存位置决策流程，对 `/learn` 命令进行扩展，以确保在写入任何技能（Skill）文件前的质量。

提取内容建议

寻找以下内容：

1. **错误解决模式（Error Resolution Patterns）** —— 根本原因 + 修复方法 + 可复用性 2. **调试技巧（Debugging Techniques）** —— 非直观步骤、工具组合使用 3. **临时变通方案（Workarounds）** —— 库的奇技淫巧、API 限制、特定版本的修复 4. **项目特定模式（Project-Specific Patterns）** —— 约定、架构决策、集成模式

流程

1. 回顾会话，寻找可提取的模式（Patterns） 2. 识别最有价值/最可复用的洞察

3. **确定保存位置：**

• 询问：“这个模式在其他项目中是否有用？”
• **全局（Global）** (`~/.claude/skills/learned/`)：可在 2 个以上项目中使用的通用模式（Bash 兼容性、LLM API 行为、调试技巧等）
• **项目（Project）** (当前项目中的 `.claude/skills/learned/`)：项目特定知识（特定配置文件的特性、项目特定的架构决策等）
• 如有疑问，选择“全局”（将“全局”移动到“项目”比反向操作更容易）

4. 使用以下格式起草技能（Skill）文件：

---
name: pattern-name
description: "130 字符以内"
user-invocable: false
origin: auto-extracted
---

# [描述性的模式名称]

**提取日期：** [Date]
**上下文：** [简要描述该模式适用的场景]

## 问题
[该模式解决的问题 - 请具体说明]

## 解决方案
[模式/技术/变通方案 —— 附带代码示例]

## 何时使用
[触发条件]

5. **在保存前进行自评**，参考以下评分标准：

| 维度 | 1 | 3 | 5 | |-----------|---|---|---| | 具体性（Specificity） | 仅有抽象原则，无代码示例 | 提供代表性的代码示例 | 包含涵盖所有使用模式的丰富示例 | | 可操作性（Actionability） | 不清楚该做什么 | 主要步骤易于理解 | 立即可以执行，涵盖边缘情况 | | 范围契合度（Scope Fit） | 太宽泛或太狭隘 | 基本合适，存在一些边界模糊 | 名称、触发器和内容完美契合 | | 非冗余性（Non-redundancy） | 与其他技能几乎相同 | 虽然有重叠但存在独特视角 | 具有完全独特的价值 | | 覆盖面（Coverage） | 仅涵盖目标任务的一小部分 | 涵盖主要情况，缺少常见变体 | 涵盖主要情况、边缘情况和潜在陷阱 |

• 为每个维度评分（1–5 分）
• 如果任何维度得分在 1–2 分，请改进草案并重新评分，直到所有维度均 ≥ 3
• 向用户展示评分表和最终草案

6. 请求用户确认：

• 展示：建议的保存路径 + 评分表 + 最终草案
• 在写入前等待明确确认

7. 保存到确定的位置

步骤 5 的输出格式（评分表）

| 维度 | 得分 | 理由 | |-----------|-------|-----------| | 具体性 | N/5 | ... | | 可操作性 | N/5 | ... | | 范围契合度 | N/5 | ... | | 非冗余性 | N/5 | ... | | 覆盖面 | N/5 | ... | | **总计** | **N/25** | |

注意事项

• 不要提取琐碎的修复（拼写错误、简单的语法错误）
• 不要提取一次性问题（特定的 API 故障等）
• 专注于能为未来会话节省时间的模式
• 保持技能（Skill）聚焦 —— 每个技能一个模式
• 如果覆盖面得分较低，在保存前添加相关的变体场景