recall-double-check

---
name: recall-double-check
description: "Quality assurance system that verifies deliverables match user requirements and execution plans. Features: (1) Auto-Memory - record conversations and tasks, (2) Double Check - verify deliverables in 3 scenarios: plan confirmation, post-delivery verification, user-triggered check, (3) Idle Reflection - periodic review and lesson extraction. Triggers on 'double check it', 'dc it', 'what's wrong', '再检查一下', '到底怎么回事'."
---

# 再想想 (Recall and Double Check)

## 概述

本技能建立完整的质量保障系统，三大功能：

1. **记住 (Auto-Memory)** - 自动记录对话和任务
2. **再想想 (Double Check)** - 三层复核防止交付错误
3. **主动回顾 (Idle Reflection)** - 定期回顾提炼经验

---

## 记忆文件系统

```
memory/                    # 记忆存储根目录
├── 日记/                  # 每日自动记录
│   └── YYYY-MM-DD.md
├── 文档/                  # 事实、方案
│   └── 股票/
├── 经验/                  # 经验总结
└── index.json             # 索引文件
```

**MEMORY.md** 保持精简，只存规则/技术/永久性信息，其他以索引指向 memory/

---

## 功能1: 记住 (Auto-Memory)

### 触发时机
- 每次用户交互结束
- 执行动作完成后
- 任务执行过程中关键节点

### 日记记录规范（详细版）

#### 格式模板
```markdown
## HH:MM:SS ⭐ [事件标题]

**背景**: [前因，引用之前的相关记录]

**交流过程**:
- 用户: "[用户原话，情绪激烈时加粗]"
- 我: "[我的回应]"
- 用户: "[用户反馈]"
- ...

**执行过程**:
- [时间] 开始执行 [动作]
- [时间] 遇到问题: [问题描述]
- [时间] 尝试解决: [解决措施]
- [时间] 结果: [成功/失败/部分成功]

**情绪标记**: [如有激烈情绪，标注类型和原因]
- 类型: 不满/急切/失望/愤怒/赞赏等
- 触发点: [什么导致情绪]
- 我的应对: [如何回应]

**验证情况**:
- 是否激活double check: [是/否，触发词]
- 验证结果: [通过/发现问题]
- 补救措施: [如有]

**关键决策**:
- 决策点: [做了什么决定]
- 依据: [基于什么信息]
- 风险: [潜在问题]

**产出/结果**:
[详细描述产出内容]

**待办/后续**:
- [ ] 待办事项

标签: [标签1,标签2,...]

---
```

#### 记录原则

**1. 交流过程记录**
- 保留关键对话的原文
- 用户情绪激烈的回答**加粗**
- 用户的重要要求用引用格式
- 转折点和分歧点必须记录

**2. 任务执行详细记录**
```markdown
**执行时间线**:
- 10:05:12 用户提出要求
- 10:05:30 我开始分析文件
- 10:06:15 发现文件章节范围与预期不符
- 10:06:20 向用户确认
- 10:07:00 用户确认"**再次检查...**"（情绪：急切）
- 10:07:30 重新启动深度分析任务
- 10:40:00 任务完成，输出文档
```

**3. 问题与补救详细记录**
```markdown
**问题记录**:
- 问题发生时间: [具体时间]
- 问题描述: [详细描述]
- 影响范围: [影响了什么]
- 根因分析: [为什么会发生]

**补救过程**:
- 补救措施1: [描述] - 结果: [成功/失败]
- 补救措施2: [描述] - 结果: [成功/失败]
- 最终解决: [如何解决的]

**教训**:
- 我的失误: [哪里做错了]
- 如何避免: [下次怎么做]
```

**4. Double Check激活记录**
```markdown
**Double Check触发**:
- 触发词: [用户使用的触发词]
- 触发时间: [时间]
- 检查目标: [检查什么]
- 发现的问题: [如有]
- 修正措施: [如何修正]
```

#### 记录优先级

| 优先级 | 内容类型 | 必须记录 |
|--------|----------|----------|
| P0 | 用户情绪激烈的交流 | 原文+情绪类型+触发点 |
| P0 | 重要要求/指令 | 用户原话+我的理解+确认过程 |
| P1 | 任务执行过程 | 时间线+关键节点+问题 |
| P1 | 失败/错误/异常 | 详细过程+根因+补救 |
| P2 | 正常完成的任务 | 简要记录+产出 |
| P3 | 例行检查/heartbeat | 可记录为HEARTBEAT_OK |

#### 示例

**示例1: 用户情绪激烈的场景**
```markdown
## 09:05:00 ⭐ 求魔文件范围误判更正

**背景**: 用户此前发送三个小说文件，我仅读取开头几行就判定文件范围，导致误判。

**交流过程**:
- 用户: "**再次检查收到的三个文件，三个文件都覆盖了30多章内容，一共一百多章**"（情绪：**急切、不满**，指出我的错误）
- 我: 立即重新检查文件
- 用户: "**这么快就分析完了吗？**"（情绪：**质疑、不信任**，对我的速度表示怀疑）
- 我: 承认错误，启动深度分析sub-agent

**情绪标记**: 
- 类型: 急切+质疑
- 触发点: 我发现文件范围错误+速度过快
- 我的应对: 立即承认错误，启动深度模式重新分析

**问题分析**:
- 我的失误: 只读取文件开头几行就下结论，没有完整检查
- 根因: 草率、图快、缺乏严谨性
- 影响: 需要重新执行，浪费用户时间

**补救措施**:
1. 重新分析三个文件的完整章节范围
2. 启动sub-agent进行逐章深度分析（预计30-60分钟）
3. 更新知识库标记为"第1-111章完整"

标签: 小说知识库,求魔,更正,用户不满
```

**示例2: 任务失败详细记录**
```markdown
## 07:34:00 ⭐ 修复AI早报cron任务日志问题（dc it）

**背景**: 昨晚23:59的AI早报晚间版任务执行后，用户未收到简报。

**交流过程**:
- 用户: "**昨晚的ai报呢**"（情绪：**失望**，期待落空）
- 我: 检查cron任务状态，发现状态显示"ok"但runs为空
- 用户: "**需要，dc it，查看昨晚有没有日记**"（激活double check）

**执行过程**:
- 07:34:10 检查cron任务状态，发现lastStatus="ok"但runs=[]
- 07:34:20 检查日记文件，发现无昨晚简报记录
- 07:34:30 分析根因：delivery.mode="announce"在企业微信不可靠
- 07:35:00 制定修复方案
- 07:35:30 更新两个cron任务（午间版+晚间版）
- 07:36:00 验证更新成功

**Double Check触发**:
- 触发词: "dc it"
- 检查目标: 昨晚任务执行情况
- 发现的问题: 任务执行但runs为空，无日记记录，企业微信未收到
- 根因: announce模式在企业微信渠道不可靠
- 修正: 改为none模式，payload明确要求使用message.send

**验证情况**:
- cron list显示任务已更新
- 下次执行时间正常
- 已添加本地日志记录要求

标签: cron修复,AI早报,dc it,double-check
```

### 执行命令
```bash
# 记录普通信息
./scripts/memory.sh record "对话摘要" --type normal

# 记录重要信息（带标签）
./scripts/memory.sh record "详细记录..." --type important --tags "需求,股票"
```

---

## 功能2: 再想想 (Double Check)

### 触发词（中英双语）

**English**:
- "double check it"
- "what's wrong with you"
- "what's the problem"
- "check again"
- "something is wrong"
- **"dc it"** — shorthand for "double check"

**中文**:
- "再想想"
- "再检查一下"
- "到底怎么回事"
- "出了什么问题"
- "不对"
- "错了"
- "有问题"

### 三层复核流程

#### 阶段1: 方案确认 (Plan Confirmation)

用户提出需求后，执行前必须：

1. 清晰呈现方案
2. 询问确认："这个方案是否符合你的需求？"
3. **等待用户确认**
4. 确认后才存入记忆

**存储格式**（双层索引）：

```markdown
# MEMORY.md - 精简索引
## Tasks, Plans and Missions
### [任务名称]
**当前方案**: /memory/日记/2026-03-14.md

# /memory/日记/2026-03-14.md - 完整方案
## [任务名称] - 完整方案确认

**关联任务**: [Task ID]

### 原始需求
[用户原始需求，尽量原文]

### 确认方案
[ agreed execution details ]

### 验证标准
- [ ] Criterion 1
- [ ] Criterion 2
```

#### 阶段2: 交付验证 (Delivery Verification)

任务完成后，交付前必须：

1. **检索原始需求和方案**：
   - 搜索 MEMORY.md ## Tasks, Plans and Missions
   - 找到匹配任务名
   - 跟随"当前方案"路径到日记文件
   - 读取完整方案和验证标准

2. **对比交付物**：
   - [ ] 是否符合原始需求？
   - [ ] 是否遵循确认方案？
   - [ ] 是否满足成功标准？

3. **检查问题**：
   - 上下文丢失（忘记关键约束）
   - 细节漂移（中途改变方法）
   - 范围蔓延（添加不必要内容）
   - 范围收缩（遗漏必需部分）

4. **3次重试机制**：

```
尝试 1/3:
- 识别问题
- 修正提示/指令
- 重新生成交付物
- 再次验证

尝试 2/3:
- 如仍错误，深入分析
- 检查是否误解需求
- 修正方法
- 重新生成

尝试 3/3:
- 最终尝试，明确约束
- 如仍失败 → 生成失败报告
```

**失败报告模板**：
```markdown
## 交付检查报告

**原始需求**: [用户原始需求]
**确认方案**: [当时确认的执行方案]
**交付物摘要**: [本次交付内容]

**不匹配点**:
1. ...
2. ...

**已尝试**: 3轮修正
**失败原因**: [为什么无法匹配]

**建议**: [人工介入建议]
```

#### 阶段3: 用户触发检查 (User Triggered)

用户表达疑虑时：

1. **识别目标**：当前任务或最近交付物
2. **检索方案**：通过索引找到完整方案
3. **执行验证**：同阶段2
4. **报告结果**：
   - 如正确："检查完成，交付物符合需求：[对比说明]"
   - 如发现问题："发现问题：[问题描述]，正在修正..."

### 执行命令

```bash
# 触发复核
./scripts/memory.sh check "本次任务描述" "用户原始需求"
```

---

## 功能3: 主动回顾 (Idle Reflection)

### 触发时机
心跳空闲时（每5-10次随机触发）

### 执行流程
1. 随机选取近3天日记
2. 筛选高价值记忆（含"纠正"、"错误"、"反馈"、"偏好"）
3. 提炼经验教训 → 写入 `memory/经验/`
4. 更新索引

### 执行命令
```bash
# 触发回顾
./scripts/memory.sh reflect
```

---

## 索引系统

### 双层索引结构

**Level 1: MEMORY.md - 任务索引**
```markdown
## Tasks, Plans and Missions
### [任务名称]
**当前方案**: /memory/日记/YYYY-MM-DD.md
```

**Level 2: 日记文件 - 完整方案**
详细记录：原始需求、确认方案、验证标准

**检索流程**：
```
需要验证 → 搜索 MEMORY.md → 找到任务名
               ↓
         获取"当前方案"路径
               ↓
         从日记文件读取完整方案
               ↓
         执行验证
```

### 索引文件格式

`memory/index.json`:
```json
{
  "files": [
    {"path": "日记/2026-03-14.md", "keywords": ["技能清理"], "summary": "删除60+未使用技能"},
    {"path": "文档/股票/持仓.md", "keywords": ["中际旭创", "阳光电源"], "summary": "股票持仓信息"}
  ]
}
```

---

## 验证清单

交付前必须检查：

- [ ] 输出匹配原始需求
- [ ] 输出遵循确认方案
- [ ] 所有成功标准已满足
- [ ] 无上下文丢失
- [ ] 无幻觉添加
- [ ] 无遗漏必需元素

---

## 使用示例

### 示例1: 方案确认

用户："创建一个股价监控任务，每天早上9点检查中际旭创"

提出的方案：
"方案：创建cron任务，每天早上9:00查询中际旭创(300308)股价，发送到企业微信。
确认一下：
1. 时间是早上9:00对吗？
2. 只监控中际旭创一只股票？
3. 发送到企业微信的LiMeng？"

等待确认 → 存入记忆 → 继续执行

### 示例2: 交付验证

Cron任务完成，生成股价报告。

交付前：
1. 检索："监控中际旭创，早上9点，发企业微信"
2. 检查交付物：
   - [x] 包含中际旭创股价？Yes
   - [x] 时间正确？Yes  
   - [x] 发送到企业微信？Yes
3. 发送给用户

### 示例3: 用户触发检查

用户："再检查一下刚才的日报"

行动：
1. 识别：最近交付物 = AI早报
2. 检索：原始需求（搜集12小时内AI新闻）
3. 检查：
   - [x] 覆盖12小时内？→ 检查时间戳
   - [x] 包含GitHub Trending？→ 验证
   - [x] 包含ClawHub？→ 验证
4. 报告："检查完成，4项要求全部满足"

---

## 记住

**Better to check twice than deliver wrong once.**

任务标记"完成"前，绝不跳过验证。