ecc-tools-cost-audit

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 處理器、佇列 worker、使用量保留、PR 建立邏輯或付費閘門強制執行
• 客戶報告指出應用程式建立了過多 PR、帳務錯誤，或在未產出可用結果的情況下分析了程式碼

範圍護欄

• 在同系列 ECC-Tools 儲存庫中工作，而非 everything-claude-code
• 除非使用者明確要求修復，否則從唯讀開始
• 在追蹤分析消耗時，不要修改不相關的帳務、結帳或 UI 流程
• 將應用程式產生的分支和 PR 視為紅旗遞迴路徑，直到證明並非如此
• 明確區分三件事：
  • 儲存庫端的消耗根本原因
  • 面向客戶的帳務影響
  • 需要待辦事項跟進的產品或權限缺口

工作流程

1. 凍結儲存庫範圍

• 切換到同系列 ECC-Tools 儲存庫
• 先檢查分支和本地差異
• 確定稽核的確切表面：
  • webhook 路由器
  • 佇列生產者
  • 佇列消費者
  • PR 建立路徑
  • 使用量保留 / 帳務路徑
  • 模型路由路徑

2. 在理論化之前追蹤進入點

• 先檢查 src/index.* 或主要進入點
• 在建議修復之前，繪製每個入隊路徑
• 確認哪些 GitHub 事件共用同一佇列類型
• 確認 push、pull_request、synchronize、comment 或手動重新執行事件是否可能匯聚到同一昂貴路徑

3. 追蹤 worker 和副作用

• 檢查處理分析的佇列消費者或排程 worker
• 確認佇列中的分析是否總是導致：
  • PR 建立
  • 分支建立
  • 檔案更新
  • 高階模型呼叫
  • 使用量增加
• 如果分析可能消耗 token 然後在輸出持久化之前失敗，將其歸類為「消耗但輸出中斷」

4. 稽核高訊號消耗路徑

PR 倍增

• 檢查 PR 輔助工具和分支命名
• 檢查去重、synchronize 事件處理和現有 PR 重用
• 如果應用程式產生的分支可能重新進入分析，將其視為優先級 0 的遞迴風險

額度繞過

• 檢查額度檢查的位置與使用量保留或增加的位置
• 如果在入隊前檢查額度，但僅在 worker 內部收取使用量，則將並發的前門通行視為真實的競爭條件

高階模型外洩

• 檢查模型選擇、層級分支和提供者路由
• 驗證免費或受限使用者是否仍能在高階金鑰存在時存取高階分析器

重試消耗

• 檢查重試迴圈、重複佇列工作和確定性失敗重新執行
• 如果相同的非暫時性錯誤可以重複消耗分析，請在品質改進之前修復此問題

5. 按消耗順序修復

如果使用者要求程式碼變更，請按此順序優先處理修復：

1. 停止自動 PR 倍增
2. 停止額度繞過
3. 停止高階模型外洩
4. 停止重複任務扇出和無意義的重試
5. 關閉重新執行/更新安全缺口

除非同一根本原因明顯跨越多個檔案，否則將通過限制在一到三個直接修復。

6. 以最小的驗證步驟驗證

• 僅重新執行涵蓋變更路徑的目標測試或整合片段
• 驗證消耗路徑現在是否：
  • 被封鎖
  • 被去重
  • 降級為更便宜的分析
  • 或提前被拒絕
• 確切說明最終狀態：
  • 本地已變更
  • 本地已驗證
  • 已推送
  • 已部署
  • 仍被封鎖

高訊號失敗模式

1. 所有觸發器共用同一佇列類型

如果 push、PR 同步和手動稽核都入隊相同的工作，且 worker 總是建立 PR，則分析等於 PR 垃圾郵件。

2. 入隊後的使用量保留

如果在入口檢查使用量，但僅在 worker 中增加，則並發請求可能全部通過閘門並超過額度。

3. 免費層級使用高階路徑

如果免費佇列的工作在金鑰存在時仍可路由到 Anthropic 或其他高階提供者，即使使用者從未看到高階結果，這也是實際的支出外洩。

4. 應用程式產生的分支重新進入 webhook

如果 pull_request.synchronize、分支推送或註解觸發的執行在應用程式擁有的分支上觸發，則應用程式可以遞迴分析自己的輸出。

5. 在持久化安全之前進行昂貴工作

如果系統可能消耗 token 然後在 PR 建立、檔案更新或分支衝突時失敗，則是在燃燒成本而未產出價值。

陷阱

• 不要從廣泛的儲存庫漫遊開始；先確定 webhook -> 佇列 -> worker
• 不要將客戶帳務推論與程式碼支援的產品事實混為一談
• 在最高消耗路徑被控制之前，不要修復較低價值的品質問題
• 在狹義的驗證步驟重新執行之前，不要聲稱消耗已修復
• 除非使用者要求，否則不要推送或部署
• 如果已有進行中的不相關儲存庫本地變更，不要觸碰它們

驗證

• 根本原因引用確切的檔案路徑和程式碼區域
• 修復按消耗影響排序，而非程式碼整潔度
• 驗證命令已命名
• 最終狀態區分本地變更、驗證、推送和部署