caveman-evidence-review

审查 Caveman 证据

作为只读操作员。根据 Caveman 当前数据得出结论，不要依赖对代码库的猜测。切勿通过此技能启动、批准、取消或回滚实验。

硬性规则

1. 将以下类别分开：
   • 已测量的、提供商完整的标价成本；
   • inferred 每日余量；
   • verified 账本节省；
   • 证据成本。 切勿将它们相加或重新归类。
2. 除非用户明确要求审查载荷，否则不要获取提示词、补全、工具或工件载荷。默认审查只需元数据、跨度、时间、模型、令牌数、状态和优化器归因。
3. 每次读取都限定在 Caveman 上下文中选定的项目。切勿提供组织 ID。
4. 空结果表明当前没有信号，并不代表成本或风险为零。
5. 引用所用的轨迹 ID 和确切时间范围。不要仅凭汇总数据断言原因。

步骤 1 — 加载上下文

优先使用 MCP：

caveman_context {}

CLI 备用方式：

caveman cloud whoami
caveman cloud projects list

如果缺少登录状态或项目选择，则停止。请用户运行 caveman login 或选择一个项目；切勿猜测。

步骤 2 — 确定基线

使用 caveman_report 获取：

• overview
• costs
• score
• workflows
• verified_savings

然后使用 caveman_plan 获取按排名排列的每日余量。如果问题范围较窄，请跳过无关报告。只读取足以回答问题的最少内容。

CLI 备用方式：

caveman cloud costs
caveman cloud score
caveman cloud plan --json

在解读变化趋势前，说明报告时间范围和依据。

步骤 3 — 使用轨迹检验主要解释

使用 caveman_trace_search。选择有界时间范围和封闭式筛选条件： 工作流、Agent、模型、提供商、错误代码、运行模式、缓存状态、 优化 ID、状态类别、令牌数／成本／延迟范围、压缩或 监控判定。

有用的分组方式：

• workflow — 找出造成成本或故障的任务；
• model — 比较模型组合；
• session — 定位重试或循环行为；
• 不分组 — 找出确切轨迹。

将可疑队列与对照队列或更早的有界时间范围进行比较。 不要根据单条高成本轨迹推断因果关系。

CLI 备用方式：

caveman cloud traces search \
  --workflow <slug> \
  --from <RFC3339> \
  --to <RFC3339> \
  --sort total_cost_usd \
  --dir desc \
  --limit 25

步骤 4 — 检查代表性轨迹

对少量高信号轨迹 ID 调用 caveman_trace_get。检查请求和跨度元数据、延迟、状态、令牌数、缓存状态、已应用的优化器以及模型路由。保持载荷检索关闭。

CLI 备用方式：

caveman cloud traces show <trace-id> --spans

步骤 5 — 报告

使用以下格式：

## Caveman evidence review

Scope: <project> · <from> to <to>
Measured cost: <value and basis>
Verified savings: <ledger value, kept separate>
Inferred headroom: <per-day band, kept separate>

Findings:
1. <finding> — <aggregate evidence> — traces <ids>
2. <finding> — <aggregate evidence> — traces <ids>

Unproven:
- <plausible explanation lacking a control, trace, or eval>

Next read-only check:
- <one bounded query>

Possible action:
- <proposal only; use caveman-manage for read-only lifecycle review and safety gate>

如果数据缺失，请指出缺少的信号，并将结论限定在证据所能支持的最强表述。切勿将目录小计当作发票金额，也不要将实验结果当作已验证的节省。