learn-eval

# /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）文件：

```markdown
---
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）聚焦 —— 每个技能一个模式
- 如果覆盖面得分较低，在保存前添加相关的变体场景