failure-learning

Files (2)

• SKILL.md
• failure_analysis.md · templates/

SKILL.md (first lines)

# 失败学习回写 — 操作手册

## 1. 何时使用

- 同一类任务连续 2 次未通过代码审查
- 双 AI 审查中 B 指出"这个模型/流程历史上多次在此类任务上失败"
- 用户主动反馈"这块总是做不好"

## 2. 核心原则

### 2.1 一定要与人沟通

**铁律**：失败学习流程触发后，**必须与人沟通**，不允许 AI 自行闷头解决。

- 分析完根因后 → 向用户汇报根因分类和拟采取的纠偏措施 → 等用户确认
- 如果根因是"不知道怎么做" → 先向用户说明准备去网上查什么、查哪些来源
- 如果根因是"需求描述不清" → 向用户追问具体的业务边界和约束
- 如果根因是"模型能力不足" → 向用户提议更换方案，说明替代方案的利弊
- **绝不允许 AI 在用户不知情的情况下擅自修改需求文档或更换执行策略**

### 2.2 检索是第一反应

分析根因后，如果发现模型做不好，第一反应应该是**去网上查找成熟方案**，而不是让模型继续尝试浪费 token。

### 2.3 回写必须精准

回写不是"把错误记一下"，而是要**修改具体的规则**让下次执行时不再犯同样的错。

## 3. 执行流程

```text
触发条件检测（failure_tracker.py check）
    │
    ▼
Step 1: 根因分析 — 分类到 4 种根因之一
    │
    ▼
Step 2: 向用户汇报 — 展示根因 + 拟定纠偏方案（人工沟通硬约束）
    │
    ▼
Step 3: 用户确认 — 用户同意后才能继续
    │
    ▼
Step 4: 执行纠偏 — 按根因类型执行对应操作
    │   ├─ 不知道怎么做 → 网上搜索 → 修改方案文档
    │   ├─ 需求描述不清 → 追问用户 → 修改需求文档
    │   ├─ 模型能力不足 → 更换模型/路径 → 修改模型执行规约
    │   └─ 外部 API 变更 → 更新 API 注册表 → 修改实施计划
    │
    ▼
Step 5: 回写文档 — 产出 failure_analysis.md + 修改目标文档
    │
    ▼
Step 6: 验证 — 下次同类任务是否通过
```

## 4. 根因分类

| 根因类型 | 回写目标 | 示例 |
|---------|---------|------|
| 不知道怎么做 | 方案文档 + 新增检索报告 | "grid_engine 接口不会用" → 查官方文档补充到方案 |
| 需求描述不清 | 需求文档（README.md） | "验收标准模糊" → 向用户追问后补充边界 |
| 模型能力不足 | 模型执行规约 | "GPT 做这个总出错" → 切换到 Claude 并记录 |
| 外部 API 变更 | API_REGISTRY.json + 实施计划 | "GitHub API 版本变了" → 更新注册表 |

## 5. 输出产物

使用模板：`templates/failure_analysis.md`

产物存放路径：
```
.workflow/reviews/<task_id>/failure_analysis.md
```

## 6. 与双 AI 审查的集成

1. 在 `dual-ai-review` SKILL 的审查产物中增加 `failure_learning_triggered: true` 标记
2. Reviewer-B 在审查时**必须查询 failure_tracker 历史记录**
3. 失败学习完成后的回写文档，作为下一轮审查的输入

## 7. 评分指标

| 指标 | 计算方式 |
|------|----------|
| 纠偏成功率 | 回写后同类任务通过率提升幅度 |
| 人工沟通完成率 | 触发后实际与用户沟通次数 / 触发次数 |
| 回写覆盖率 | 实际修改的文档数 / 应修改的文档数 |

From XX-Trader/openclaw-hardflow-backup-20260302, MIT.

More from XX-Trader/openclaw-hardflow-backup-20260302