ECC 工具成本审计¶

当用户怀疑 ECC Tools GitHub App 正在消耗成本、过度创建 PR、绕过使用限制，或将免费用户引入高级分析路径时，使用此技能。

这是一个针对同级 ECC-Tools 仓库的聚焦操作者工作流程。它既不是通用计费技能，也不是全仓库范围的代码审查。

技能栈¶

在适用时将这些 ECC 原生技能纳入工作流程：

• autonomous-loops：用于跨越 webhooks、队列、计费和重试的有界多步骤审计
• agentic-engineering：用于将请求路径追踪为离散、可证明的单元
• customer-billing-ops：当需要清晰分离仓库行为与客户影响计算时
• search-first：在发明辅助函数或重新实现仓库本地工具之前
• security-review：当涉及认证、使用门控、授权或密钥时
• verification-loop：用于证明重跑安全性与修复后的确切状态
• tdd-workflow：当修复需要在 worker、router 或计费路径中覆盖回归测试时

使用时机¶

• 用户提到 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 链路
• 不要将客户计费推断与基于代码的产品事实混为一谈
• 在最高消耗路径得到控制之前，不要修复低价值质量问题
• 在针对性的验证步骤重跑之前，不要声称消耗问题已修复
• 除非用户要求，否则不要推送或部署
• 如果已有无关的仓库本地更改正在进行中，不要触碰它们

验证¶

• 根本原因需引用确切的文件路径和代码区域
• 修复按影响严重程度排序，而非代码整洁度
• 验证命令需明确命名
• 最终状态需区分本地变更、验证、推送和部署