القائمة
分析近期鉴定日志，识别 plan_execute 路径的系统性问题并生成 markdown 报告
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | analyze-logs |
| description | 分析近期鉴定日志，识别 plan_execute 路径的系统性问题并生成 markdown 报告 |
分析项目近期的鉴定日志，找出系统性问题，写报告到 reports/。
--last N：分析最近 N 天（默认 7）--since DATE：从 ISO 日期起（如 --since 2026-05-01）跑数据准备脚本（输出会很长，用重定向到文件方便 Read）：
python scripts/prepare_log_data.py --last 7 > reports/_log_data.md
或 --since 形式。命令运行需要 < 5 秒。
用 Read 工具读 reports/_log_data.md——里面已经按 case 聚合好关键字段（tokens、stages、search queries、claims、verdict、outliers）。
分析（核心环节，主 Claude 干这个）：
找系统性问题，不是单 case 偶发：
不要只看预设 outlier 标记：脚本只标了 input_tokens > 200K、elapsed > 120s、all_unverified、cross_round_repeats、verdict_text_empty 这几条。用你的推理找未标的模式：
每个结论必须引用具体 case_id 作为证据：不能"我觉得 token 高"，要"case 20260511-XXXX 单 claim 跑到 88K、case 20260511-YYYY 也是 75K"。
写报告：用 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/ 相对路径链接）
报告写完后，删除中间文件 reports/_log_data.md，然后主动告知用户：
"分析完成，报告：
reports/log_analysis_<日期>.md。工具改进建议见报告末尾——要我现在实施吗？"
等待用户明确指示再改脚本或本 SKILL.md。未经同意不能默默改。
reports/，不进 git（已在 .gitignore）不要只看脚本预聚合的 outlier。问自己：
脚本会自动识别 dev replay（24h 内同 title 出现 ≥3 次、或 空 title + 无 history），标记 is_dev_replay=True，并输出到独立 section ## Dev Replay case 详情（默认不过滤，便于观察调优过程）。
报告中分开处理：
## Dev Replay 时序演变 里同 title case 的 token 序列命令选项：
--exclude-dev：完全过滤 dev replay（适合纯线上趋势分析）--include-dev-as-real：跳过 dev replay 启发式（同篇真实文章被多次鉴定的场景，避免被误标）--token-outlier=N / --elapsed-outlier=N：自定义 outlier 阈值（默认 200K / 120s）跑完数据准备后，如果发现 真实 case 数 < 5，先不要急着写报告。检查：
--last 7 只看最近 7 天。先告诉用户"真实 case 只有 N 个，要不要扩大到 30 天/90 天看看？"，等用户回答后用 --last 30 或 --last 90 重跑--include-dev-as-real 让用户判断脚本已经在 case<5 时自动改为"列举式"输出（不算 median/p95），但你还要在报告里明确说明 n 太小、结论无统计意义。
跑前先看 reports/ 下最近的 log_analysis_*.md：