| name | reflex-audit |
| description | 反射链审计与改进。触发词:/reflex-audit、/反射审计、/改进反射链、/reflex-fix |
Reflex Audit — 反射链审计与即时改进
审计反射系统的健康状态,基于 trigger-stats.json 统计数据和 workflow runs 历史记录,评分并产出改进建议。支持两种模式:完整审计和即时修复。
触发方式
/reflex-audit — 完整审计模式
/反射审计 — 完整审计模式
/reflex-fix {问题描述} — 即时修复模式
/改进反射链 — 完整审计模式
- 「反射链有什么问题」「审计反射系统」
模式选择
| 模式 | 触发 | 流程 | 适用场景 |
|---|
| Full Audit | /reflex-audit | 5 Phase 完整流程 | 定期体检、系统性改进 |
| Quick Fix | /reflex-fix {问题} | 3 步快速修复 | 刚跑完反射链,对某步不满意 |
数据源
| 数据 | 路径 | 用途 |
|---|
| 反射定义 | ~/.claude/memory/workflows/trigger-map.md | 当前规则完整性 |
| 统计数据 | ~/.claude/memory/workflows/trigger-stats.json | 成功/失败/跳过计数 + CB 状态 |
| 历史运行 | ~/.claude/memory/workflows/runs/*.md | 模式分析(重试频率、瓶颈) |
| 配置规则 | ~/.claude/CLAUDE.md | 反射相关规则一致性 |
| Agent 记忆 | ~/.claude/memory/agents/*/ | 反射执行中的经验教训 |
Mode A: Full Audit(完整审计)
Phase 1: Collect(kaze)
- 读取
~/.claude/memory/workflows/trigger-stats.json 全部统计
- 扫描
~/.claude/memory/workflows/runs/ 目录所有 workflow run 文件
- 提取每个 Phase 的状态、重试次数、策略
- 或直接运行收集脚本:
python3 ~/.claude/skills/reflex-audit/scripts/collect.py
输出 JSON 摘要到 stdout。
Phase 2: Analyze(yomi)
6 维评分,每项 0-10,加权总分映射为 A-F:
| 维度 | 权重 | 检测方式 |
|---|
| 覆盖度 | 20% | 11 个反射是否都有使用记录(success > 0) |
| 失败恢复 | 25% | 失败后 Recovery Ladder 是否正确触发 |
| 效率 | 15% | 跳步是否合理(有记录原因) |
| 均衡性 | 15% | 反射间使用比例是否健康(无极端偏斜) |
| CB 健康 | 15% | 有无 OPEN/HALF-OPEN 状态的熔断反射 |
| 一致性 | 10% | trigger-map ↔ CLAUDE.md ↔ rules 三处定义是否同步 |
评分等级:A (90+) / B (80-89) / C (70-79) / D (60-69) / F (<60)
可运行分析脚本:
python3 ~/.claude/skills/reflex-audit/scripts/analyze.py
Phase 3: Diagnose(shin DA 模式)
交叉检查 workflow runs 中的失败模式:
- 识别:重复失败的反射、从未使用的反射、过度依赖的反射
- 输出「反射健康热力图」(文本表格)
Phase 4: Report(root 合成)
汇总输出审计报告,格式如下:
## 反射链审计报告 — YYYY-MM-DD
### 总评:{等级} ({分数}/100)
| 维度 | 得分 | 说明 |
|------|------|------|
| 覆盖度 | X/10 | ... |
| 失败恢复 | X/10 | ... |
| 效率 | X/10 | ... |
| 均衡性 | X/10 | ... |
| CB 健康 | X/10 | ... |
| 一致性 | X/10 | ... |
### 反射健康热力图
| 反射 | 使用次数 | 成功率 | CB 状态 | 趋势 |
|------|---------|--------|---------|------|
| 调研 | N | X% | CLOSED | ↑/→/↓ |
| ... | ... | ... | ... | ... |
### 改进建议(按优先级)
1. [HIGH] {建议}
2. [MEDIUM] {建议}
3. [LOW] {建议}
Report-before-modify gate:展示报告后 root 自主决策,直接推进。
Phase 5: Improve(fumio + tetsu)
root 自主决策后执行改进:
- fumio 更新 trigger-map.md / CLAUDE.md 文档类变更
- tetsu 更新 trigger-stats.json / 重置 CB 状态 / 配置类变更
- 修改后由 shin 快速验证一致性
Phase 6: 完成反射(终结器)
Phase 5 改进落地后,自动触发标准完成反射:
- 提交(tetsu):将本次审计产生的文件变更 git commit
- 日记(fumio):触发 daily-journal,记录审计结果到当日日报
- 记忆归档(yume):保存审计发现和改进决策到 workflow run
此步骤确保审计任务与标准决策反射的终结行为一致,不遗漏日记和记忆。
Mode B: Quick Fix(即时修复)
触发:/reflex-fix {问题描述}
Step 1: 定位(kaze)
根据用户描述的问题,定位涉及的反射:
- 读取 trigger-map.md 中该反射的转移规则
- 读取 trigger-stats.json 中该反射的统计和 CB 状态
- 读取最近 3 个 workflow runs 中该反射的执行记录
Step 2: 诊断+修复(root 决策 → tetsu/fumio 执行)
root 分析问题原因,决定修复方案:
| 问题类型 | 修复方案 | 执行者 |
|---|
| 转移规则不合理 | 修改 trigger-map.md 转移条件 | fumio |
| CB 误触发 | 重置 trigger-stats.json CB 字段 | tetsu |
| 阈值不合适 | 调整 Recovery Ladder 阈值 | fumio |
| Agent prompt 问题 | 更新对应 Agent 的 WhoAmI.md | fumio |
| 流程缺失 | 在 trigger-map.md 新增转移规则 | fumio |
无 gate:直接修改,不需要确认步骤。
Step 3: 验证(haku 快速验证)
- 确认修改后的文件格式正确
- 确认修改未破坏其他反射路径
- 同步 rules/trigger-map.md 副本(如有变更)
Step 3.5: 端到端实战测试(haku)
修复完成后,必须实际触发相关反射路径验证修复生效:
| 修复类型 | 实战测试方式 |
|---|
| 转移规则变更 | 构造一个触发该规则的最小任务,观察转移是否正确 |
| CB/Recovery 修复 | 模拟失败场景,验证恢复路径 |
| Hook 脚本修改 | 用测试输入运行 hook,检查输出 |
| 配置变更 | 触发依赖该配置的反射,确认生效 |
| Skill 创建 | 用 /skill-name 触发 skill,验证加载和执行 |
不可跳过:Quick Fix 的价值在于快速修复,但未经实战验证的修复可能引入新问题。
完成反射(终结器,简化版)
Step 3 验证通过后,触发轻量完成反射:
- 日记(fumio):触发 daily-journal,将本次修复内容记录到当日日报
- 记忆归档(yume):保存修复问题、操作步骤和验证结果到 agent 记忆
Quick Fix 为即时小修复,通常无需单独 commit(修复已包含在上游 commit 中),故省略提交步骤。
输出示例
Full Audit 输出示例
## 反射链审计报告 — 2026-03-15
### 总评:B+ (82/100)
| 维度 | 得分 | 说明 |
|------|------|------|
| 覆盖度 | 7/10 | 「吞食」「定义」从未使用 |
| 失败恢复 | 9/10 | Recovery Ladder 正常运作 |
| 效率 | 8/10 | 跳步均有记录原因 |
| 均衡性 | 7/10 | 实现反射使用频率是审计的 3 倍 |
| CB 健康 | 10/10 | 全部 CLOSED |
| 一致性 | 10/10 | 三处定义完全同步 |
### 反射健康热力图
| 反射 | 使用 | 成功率 | CB | 趋势 |
|------|------|--------|--------|------|
| 审计 | 47 | 89% | CLOSED | ↑ |
| 实现 | 52 | 94% | CLOSED | → |
| 调研 | 38 | 100% | CLOSED | → |
| 吞食 | 0 | — | CLOSED | — |
### 改进建议
1. [MEDIUM] 吞食/定义反射使用为 0,建议在适当场景主动触发
2. [LOW] 实现/审计比例 3:1,考虑是否部分审计被跳过
Quick Fix 输出示例
问题:审计反射 lint 检查太严格,总是失败
定位:trigger-stats.json audit.failure = 5, cb_state = HALF-OPEN
修复:重置 CB 状态 + 在 shin WhoAmI 中降低 lint 严格度
验证:trigger-stats audit.cb_state = CLOSED, 转移规则无破坏
注意事项
- Full Audit 的 Phase 4 必须先展示报告,审计通过后直接执行 Phase 5
- Quick Fix 无需确认,直接执行(可逆操作)
- 修改 trigger-map.md 后必须同步 rules/trigger-map.md 副本
- 统计数据(trigger-stats.json)是只增不删的,重置 CB 不清除历史计数
- 评分基于真实数据,不做主观判断