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當修復需要在工作者、路由器或計費路徑中添加回歸測試覆蓋時
何時使用
- 使用者提到 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 輔助工具和分支命名
- 檢查去重、synchronize 事件處理和現有 PR 重用
- 如果應用程式生成的分支可以重新進入分析，則將其視為優先級 0 的遞迴風險
配額繞過
- 檢查在何處檢查配額，以及在何處預留或增加使用量
- 如果配額在入隊前被檢查，但使用量僅在工作者內部被收取，則將同時的前端通過視為真正的競爭條件
高級模型洩漏
- 檢查模型選擇、層級分支和提供者路由
- 驗證當高級金鑰存在時，免費或受限使用者是否仍能命中高級分析器
重試燃燒
- 檢查重試迴圈、重複佇列工作和確定性失敗重新執行
- 如果相同的非暫時性錯誤可以重複花費分析資源，請在品質改進之前先修復此問題
5. 依燃燒順序修復
如果使用者要求程式碼變更，請按此優先級修復：
- 停止自動 PR 乘法
- 停止配額繞過
- 停止高級洩漏
- 停止重複工作扇出和無意義的重試
- 關閉重新執行/更新安全缺口
將操作範圍限制在一到三個直接修復，除非相同的根本原因明確跨越多個檔案。
6. 以最小的證明步驟驗證
- 僅重新執行針對性測試或涵蓋已變更路徑的整合片段
- 驗證燃燒路徑現在是否：
- 被封鎖
- 被去重
- 被降級為更便宜的分析
- 或過早被拒絕
- 確切說明最終狀態：
- 已本地變更
- 已本地驗證
- 已推送
- 已部署
- 仍被封鎖
高訊號失敗模式
1. 所有觸發器共用一個佇列類型
如果 push、PR 同步和手動審計都將相同的工作入隊，且工作者總是建立 PR，那麼分析就等於 PR 垃圾郵件。
2. 入隊後使用預留
如果使用量在前端被檢查，但僅在工作者內部增加，則並發請求可以全部通過閘門並超出配額。
3. 高級路徑上的免費層級
如果免費佇列的工作在金鑰存在時仍可路由到 Anthropic 或其他高級提供者，那麼即使使用者從未看到高級結果，這也是真實的支出洩漏。
4. 應用程式生成的分支重新進入 Webhook
如果 pull_request.synchronize、分支推送或評論觸發的執行在應用程式擁有的分支上觸發，則該應用程式可以遞迴分析自己的輸出。
5. 在持久化安全之前的昂貴工作
如果系統可以花費 token，然後在 PR 建立、檔案更新或分支衝突上失敗，則它在燃燒成本卻沒有產生價值。
陷阱
- 不要從廣泛的儲存庫漫遊開始；先釐清 Webhook -> 佇列 -> 工作者
- 不要將客戶計費推斷與基於程式碼的產品事實混為一談
- 在最高燃燒路徑被遏制之前，不要修復低價值的品質問題
- 在狹窄的證明步驟被重新執行之前，不要聲稱燃燒已被修復
- 除非使用者要求，否則不要推送或部署
- 如果已經在進行中，不要觸碰不相關的儲存庫本地變更
驗證
- 根本原因引用確切的檔案路徑和程式碼區域
- 修復按燃燒影響排序，而非程式碼整潔度
- 證明指令被命名
- 最終狀態區分本地變更、驗證、推送和部署