analyze-logs

name	analyze-logs
description	分析近期鉴定日志，识别 plan_execute 路径的系统性问题并生成 markdown 报告

/analyze-logs

分析项目近期的鉴定日志，找出系统性问题，写报告到 reports/。

触发参数

• --last N：分析最近 N 天（默认 7）
• --since DATE：从 ISO 日期起（如 --since 2026-05-01）

执行步骤

1. 跑数据准备脚本（输出会很长，用重定向到文件方便 Read）：

   python scripts/prepare_log_data.py --last 7 > reports/_log_data.md
   

   或 --since 形式。命令运行需要 < 5 秒。

2. 用 Read 工具读 reports/_log_data.md——里面已经按 case 聚合好关键字段（tokens、stages、search queries、claims、verdict、outliers）。

3. 分析（核心环节，主 Claude 干这个）：

   • 找系统性问题，不是单 case 偶发：

     • 多个 case 同时出现的模式（如 50% case 都 cross_round_repeats > 0、verdict_text_empty 高频）
     • 趋势性变化（如最近几个 case 的 token 比早期高很多）
     • 看起来"不该这样"的现象（如所有 case claim 数都是 5——可能是 prompt 引导太强）

   • 不要只看预设 outlier 标记：脚本只标了 input_tokens > 200K、elapsed > 120s、all_unverified、cross_round_repeats、verdict_text_empty 这几条。用你的推理找未标的模式：

     • search queries 是否在不同 case 间出现"模板化"（说明 prompt 让模型只会这几种问法）
     • top stages 的耗时分布是否畸形（某一类 claim 总是最贵）
     • claims 的 note 里有没有反复出现的失败原因（如多 case 都说"网络连接失败"）
     • bullshit_index 与 claim verdicts 是否经常自相矛盾

   • 每个结论必须引用具体 case_id 作为证据：不能"我觉得 token 高"，要"case 20260511-XXXX 单 claim 跑到 88K、case 20260511-YYYY 也是 75K"。

4. 写报告：用 Write 工具写到 reports/log_analysis_<YYYYMMDD-HHMM>.md，结构如下：

   # 鉴定日志分析报告
   
   ## 元数据
   - 时间窗、case 数、生成时间、git_commit（从输入复用）
   
   ## 基本统计
   （从 _log_data.md 的全局聚合段提炼，加你的解读）
   
   ## Top N 问题诊断
   ### 问题 1: <标题>
   - 现象：（具体描述）
   - 证据：（case_id 列表 + 关键数字）
   - 影响：（对 verdict 质量 / token 成本的影响）
   
   ### 问题 2: ...
   
   ## 建议修法
   - 针对问题 1：<可执行修法>（具体到改哪个文件/函数/prompt 段）
   - 针对问题 2：...
   
   ## 工具自身改进建议
   （反思本次分析过程中工具的不足）
   - 脚本 `scripts/prepare_log_data.py` 还缺哪些字段？
   - 本 SKILL.md 哪些指令不够清晰让你走了弯路？
   - 报告结构有什么可优化的？
   - 至少一条；即使无明显缺陷也要写"当前数据足够，无明显工具缺陷"。
   
   ## 附录
   - outlier case 列表（带 logs/ 相对路径链接）
   

5. 报告写完后，删除中间文件 reports/_log_data.md，然后主动告知用户：

   "分析完成，报告：reports/log_analysis_<日期>.md。工具改进建议见报告末尾——要我现在实施吗？"

   等待用户明确指示再改脚本或本 SKILL.md。未经同意不能默默改。

硬约束

• 零外部 LLM API 调用：所有分析由当前 Claude 会话完成
• 不主动改源码：除非用户明确要求实施工具改进建议
• 不主动重跑历史 case：成本不可控
• 报告写到 reports/，不进 git（已在 .gitignore）
• 每个结论必须有 case_id 证据——禁止"可能"、"似乎"、"通常"这种无证据描述

找未知模式的提示

不要只看脚本预聚合的 outlier。问自己：

• "如果我每周都跑这个分析，下次我希望能看到什么但这次没看到？"——那就是工具改进点。
• "这批 case 里最让我觉得奇怪的现象是什么？"——可能是未知模式。
• "如果模型行为最近变了，哪些字段会暴露这个变化？"——time-series 维度。

Dev replay 处理

脚本会自动识别 dev replay（24h 内同 title 出现 ≥3 次、或 空 title + 无 history），标记 is_dev_replay=True，并输出到独立 section ## Dev Replay case 详情（默认不过滤，便于观察调优过程）。

报告中分开处理：

• "Top N 问题诊断" 主要基于真实 case——dev replay 是开发期人工跑的，不代表线上分布
• "调优演变观察"（如有）放进单独段落，引用 ## Dev Replay 时序演变 里同 title case 的 token 序列
• 不要把 dev replay 的 outlier 与真实 case 的混在一起报告

命令选项：

• 默认：保留 dev replay 并标记
• --exclude-dev：完全过滤 dev replay（适合纯线上趋势分析）
• --include-dev-as-real：跳过 dev replay 启发式（同篇真实文章被多次鉴定的场景，避免被误标）
• --token-outlier=N / --elapsed-outlier=N：自定义 outlier 阈值（默认 200K / 120s）

真实 case 不足时的处理

跑完数据准备后，如果发现 真实 case 数 < 5，先不要急着写报告。检查：

1. 时间窗可能太短：默认 --last 7 只看最近 7 天。先告诉用户"真实 case 只有 N 个，要不要扩大到 30 天/90 天看看？"，等用户回答后用 --last 30 或 --last 90 重跑
2. 可能 dev replay 误标：如果用户最近反复鉴定同一真实文章（不是开发期 replay 脚本），dev 启发式会把这些当 dev。建议跑 --include-dev-as-real 让用户判断
3. 真没有就如实说：n=2 时不要装作能给出趋势判断，明确说"数据不足，列举式呈现，不做统计推断"

脚本已经在 case<5 时自动改为"列举式"输出（不算 median/p95），但你还要在报告里明确说明 n 太小、结论无统计意义。

何时不应跑 /analyze-logs

跑前先看 reports/ 下最近的 log_analysis_*.md：

• 如果上次报告在 24h 内写过、真实 case 数没增加（看上次报告的元数据），告诉用户结论 80% 会一样，建议跳过——避免空转
• 如果用户坚持跑（如想验证工具改动效果），按正常流程继续
• 真正值得重跑的场景：用户跑了新真实 case、有新调优 commit、跨过 7+ 天