审查 Caveman 证据
以只读操作员的身份行动。根据当前的 Caveman 数据得出结论，而非来自仓库的猜测。永远不要通过此技能启动、批准、取消或回滚实验。
硬性规则
- 保持以下分类相互独立：
- 按提供商列出的标价成本；
推断的每日空间；已验证的账目节省；- 证据成本。 切勿添加或重新标注它们。
- 除非用户明确要求审查有效载荷，否则不要获取提示词、补全、工具或工件的有效载荷。对于默认审查，元数据、跨度、时间、模型、令牌计数、状态和优化器归属已足够。
- 每次读取的范围仅限于 Caveman 上下文所选的项目。切勿提供组织 ID。
- 空结果意味着当前无信号，而非零成本或零风险。
- 引用追踪 ID 和精确的时间窗口。不要仅凭聚合数据就断言因果关系。
第 1 步 — 加载上下文
优先使用 MCP：
caveman_context {}
CLI 后备方案：
caveman cloud whoami
caveman cloud projects list
如果缺少登录或项目选择，则停止。要求用户运行 caveman login 或选择一个项目；切勿猜测。
第 2 步 — 建立基线
使用 caveman_report 获取：
overviewcostsscoreworkflowsverified_savings
然后使用 caveman_plan 获取按排名排列的每日空间。如果问题范围较窄，可跳过无关报告。读取能够回答该问题的最短报告集。
CLI 后备方案：
caveman cloud costs
caveman cloud score
caveman cloud plan --json
在解释趋势之前，说明报告窗口和依据。
第 3 步 — 使用追踪测试主要解释
使用 caveman_trace_search。选择一个有界限的时间窗口和闭合过滤器：工作流、智能体、模型、提供商、错误代码、运行时模式、缓存状态、优化 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 证据审查
范围：<项目> · <起始时间> 到 <结束时间>
测量成本：<数值和依据>
已验证节省：<账目值，保持独立>
推断空间：<每日区间，保持独立>
发现：
1. <发现> — <聚合证据> — 追踪 <ID>
2. <发现> — <聚合证据> — 追踪 <ID>
未证明：
- <缺乏对照组、追踪或评估的合理解释>
下一个只读检查：
- <一个有边界的查询>
可能采取的行动：
- <仅限提议；使用 caveman-manage 进行只读生命周期审查和安全门>
如果数据缺失，则说明缺失的信号，并在最有力的支持陈述处停止。切勿将目录小计转化为发票，或将实验结果转化为已验证的节省。