審查 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 證據審查
範圍：<project> · <from> 到 <to>
測量成本：<值與基準>
已驗證節省：<帳本值，保持分離>
推斷餘裕：<每日範圍，保持分離>
發現：
1. <發現> — <彙總證據> — 追蹤 <ids>
2. <發現> — <彙總證據> — 追蹤 <ids>
未經證實：
- <缺乏對照組、追蹤或評估的合理解釋>
下一次唯讀檢查：
- <一個有限的查詢>
可能動作：
- <僅提案；使用 caveman-manage 進行唯讀生命週期審查和安全閘門>
如果缺少資料，請指明缺少的訊號，並在最強有力的支援陳述處停止。絕不要將目錄小計變成發票，也不要將實驗結果變成已驗證的節省。