ECC Tools 成本審計 是做什麼的？
當使用者懷疑 ECC Tools GitHub App 正在燃燒成本、過度建立 PR、繞過使用限制，或將免費使用者路由至高級分析路徑時，請使用此技能。
這是一個針對同名 ECC-Tools 儲存庫的專注操作工作流程。它不是一個通用的計費技能，也不是一個涵蓋整個儲存庫的程式碼審查。
技能堆疊
請在相關情況下將以下 ECC 原生技能引入工作流程：
autonomous-loops：用於跨越 Webhook、佇列、計費和重試的有界多步驟審計agentic-engineering：用於將請求路徑追蹤到離散、可證明的小單元customer-billing-ops：當需要清晰分離儲存庫行為與客戶影響計算時search-first：在發明輔助工具或重新實作儲存庫本地實用程式之前security-review：當涉及身份驗證、使用閘門、權限或機密時verification-loop：用於證明重新執行安全性和精確的修復後狀態tdd-workflow：當修復需要在 Worker、路由器或計費路徑中增加回歸測試覆蓋時
使用時機
- 使用者提及 ECC Tools 燃燒率、PR 遞迴、過度建立的 PR、使用限制繞過或高級模型洩漏
- 任務位於同名的
ECC-Tools儲存庫中，且依賴於 Webhook 處理器、佇列工作者、用量保留、PR 建立邏輯或付費閘門執行 - 客戶報告指出應用程式建立了過多的 PR、計費不正確，或在沒有產生可用結果的情況下分析了程式碼
範圍護欄
- 僅在
ECC-Tools儲存庫中工作，而非everything-claude-code - 除非使用者明確要求修復，否則從唯讀開始
- 在追蹤分析燃燒時，不要修改不相關的計費、結帳或 UI 流程
- 將應用程式生成的分支和應用程式生成的 PR 視為紅旗遞迴路徑，直到證明其為良性
- 明確分離三件事：
- 儲存庫端燃燒根因
- 面向客戶的計費影響
- 需要列入待辦事項跟進的產品或權限缺口
工作流程
1. 凍結儲存庫範圍
- 切換到同名的
ECC-Tools儲存庫 - 首先檢查分支和本機差異
- 確定審計的精確表面：
- Webhook 路由器
- 佇列生產者
- 佇列消費者
- PR 建立路徑
- 用量保留 / 計費路徑
- 模型路由路徑
2. 在理論化之前追蹤入口
- 首先檢查
src/index.*或主要進入點 - 在建議修復之前，繪製每個入隊路徑
- 確認哪些 GitHub 事件共享同一佇列類型
- 確認 push、pull_request、synchronize、comment 或手動重新執行事件是否可以匯聚到同一條昂貴的路徑
3. 追蹤工作者及其副作用
- 檢查負責分析的佇列消費者或排程工作者
- 確認排隊的分析是否總是導致：
- PR 建立
- 分支建立
- 檔案更新
- 高級模型呼叫
- 用量增加
- 如果分析可以花費 Token 然後在輸出持久化之前失敗，則將其分類為「無輸出燃燒」
4. 審計高信號燃燒路徑
PR 倍增
- 檢查 PR 輔助工具和分支命名
- 檢查去重、同步事件處理和現有 PR 重用
- 如果應用程式生成的分支可以重新進入分析，則將其視為優先級為 0 的遞迴風險
配額繞過
- 檢查配額檢查的位置，以及用量保留或增加的位置
- 如果配額在入隊之前檢查，但用量僅在 Worker 內部收取，則將並發的前門通過視為真實的競態條件
高級模型洩漏
- 檢查模型選擇、層級分支和提供者路由
- 在存在高級金鑰的情況下，驗證免費或受限使用者是否仍然可以命中高級分析器
重試燃燒
- 檢查重試迴圈、重複的佇列工作和確定性失敗重新執行
- 如果相同的非暫時性錯誤可以重複花費分析資源，請在進行品質改進之前先修復此問題
5. 按燃燒順序修復
如果使用者要求程式碼變更，請按以下順序優先修復：
- 停止自動 PR 倍增
- 停止配額繞過
- 停止高級模型洩漏
- 停止重複作業 Fanout 和無意義的重試
- 關閉重新執行/更新安全漏洞
除非同一個根因明確跨越了多個檔案，否則將範圍限制在一到三個直接修復範圍內。
6. 以最小證明步驟驗證
- 僅重新執行涵蓋已變更路徑的目標測試或整合片段
- 驗證燃燒路徑現在是否：
- 被封鎖
- 被去重
- 降級為更便宜的分析
- 或被提前拒絕
- 精確說明最終狀態：
- 已在本地變更
- 已在本地驗證
- 已推送
- 已部署
- 仍被封鎖
高信號失敗模式
1. 所有觸發器共用一個佇列類型
如果 push、PR sync 和手動審計都入隊同一個作業，且 Worker 總是建立一個 PR，那麼分析就等於 PR 垃圾郵件。
2. 入隊後的用量保留
如果在入口處檢查用量，但僅在 Worker 中增加用量，則並發請求可以全部通過閘門並超出配額。
3. 免費層級走高級路徑
如果存在金鑰時，免費排隊的作業仍然可以路由至 Anthropic 或其他高級提供者，即使使用者從未看到高級結果，這也是真實的支出洩漏。
4. 應用程式生成的分支重新進入 Webhook
如果 pull_request.synchronize、分支推送或評論觸發的執行在應用程式擁有的分支上觸發，則應用程式可以遞迴地分析自己的輸出。
5. 持久化安全性之前的昂貴工作
如果系統可以花費 Token 然後在 PR 建立、檔案更新或分支衝突時失敗，則它是在燃燒成本而不產生價值。
陷阱
- 不要從廣泛的儲存庫漫遊開始；先確定 Webhook -> 佇列 -> Worker 的流程
- 不要將客戶計費推斷與基於程式碼的產品事實混合
- 在最高燃燒路徑被控制之前，不要修復價值較低的品質問題
- 在執行狹義的證明步驟之前，不要聲稱燃燒已被修復
- 除非使用者要求，否則不要推送或部署
- 如果已經有正在進行中的不相關儲存庫本地更改，不要觸碰它們
驗證
- 根因必須引用準確的檔案路徑和程式碼區域
- 修復按燃燒影響排序，而非程式碼整潔度
- 證明命令必須被命名
- 最終狀態必須區分本地變更、驗證、推送和部署