在大规模采用 AI 编码工具的过程中，Token 消耗的可观测性逐渐成为工程团队的核心需求。多数现有方案聚焦于会话级别的全局用量统计 —— 即一个对话周期内消耗了多少 tokens、产生了多少费用。然而，这种粗粒度的计量方式难以回答一个更根本的问题：这些成本究竟花在了什么样的任务上？CodeBurn 作为一款新兴的开源工具，试图填补这一空白，通过任务级的细粒度计量，让开发者能够清晰看见每一份 Token 预算的实际流向。
任务级计量的核心价值
传统的 Token 计量通常以会话（Session）或项目为维度进行聚合。这种统计方式的局限在于，它只能告诉我们「总共花了多少钱」，却无法揭示「钱花得值不值」。一个典型的工程场景是：团队发现本月 Claude Code 的费用明显增长，但无论怎么优化全局缓存策略，成本始终居高不下。问题可能出在多个方向 —— 可能是系统提示词过长导致缓存命中率低，也可能是某个特定任务类型（如调试或重构）消耗了大量 Tokens 却收效甚微。如果是后者，仅靠会话级别的统计根本无法定位。
CodeBurn 的核心设计理念正是将计量粒度下沉到任务维度。它不满足于告诉你这个月花了多少美元，而是追问：这笔费用中，编码任务占了多少？调试任务占了多少？一次成功的代码编辑与需要多次重试的编辑之间，Token 消耗的差异有多大？这种追问的答案，才是优化资源分配的实际依据。
十三种任务分类的实现
CodeBurn 内置了一套基于规则的分类系统，将 AI 编码工具执行的会话拆解为 13 种任务类别。这种分类不依赖额外的 LLM 调用，而是完全基于工具使用模式（Tool Usage Patterns）和用户消息中的关键词进行判定，保持了轻量与确定性。
具体来看，这 13 种任务类型包括：编码（Edit、Write 工具触发）、调试（错误关键词加工具使用）、功能开发（"add"、"create"、"implement" 关键词）、重构（"refactor"、"rename"、"simplify"）、测试（bash 中的 pytest、vitest、jest）、探索性阅读（Read、Grep、WebSearch 但无编辑操作）、规划（EnterPlanMode、TaskCreate 工具）、委托（Agent 工具 Spawn 子代理）、Git 操作（bash 中的 git push/commit/merge）、构建与部署（npm build、docker、pm2）、头脑风暴（"brainstorm"、"what if"、"design"）、纯对话（无工具调用的文本交流）以及通用技能工具调用。
每种分类都有明确的触发条件。例如，当用户消息中包含 "refactor" 且会话中出现了 Edit 工具调用时，该会话段即被标记为重构任务。这种规则驱动的分类方式避免了复杂 NLP 模型的额外开销，同时也保证了不同会话之间的可比性。
一次成功率：量化 AI 执行效率的关键指标
除了任务分类，CodeBurn 还引入了一个极具工程价值的指标：一次成功率（One-shot Rate）。这个指标衡量的是 AI 在执行某类任务时，第一次尝试就成功的比例。以代码编辑为例，CodeBurn 通过检测 Edit -> Bash -> Edit 的循环模式来识别重试行为。如果一个编辑 turn 后紧跟着测试执行（bash）然后再次出现编辑，则视为一次重试。编码任务的一次成功率 90% 意味着 AI 在 10 次代码编辑中有 9 次是一次执行就达到目标的。
这个指标的价值在于，它将 Token 消耗与任务产出效率直接挂钩。低一次成功率意味着 AI 在同一个任务上反复消耗 Token 进行重试 —— 每次重试都是额外的输入 Token（上下文传递）、输出 Token（推理与生成）和可能的缓存写入。这些隐性的「重试成本」在传统计量模型中完全不可见，但在 CodeBurn 的分析下无所遁形。工程团队可以据此判断：是否应该为特定任务类型切换到更强大的模型？是否需要改进系统提示词以减少重试？是否某些项目的代码质量导致测试频繁失败进而触发重试？
数据源读取与定价机制
从工程实现角度，CodeBurn 的数据读取策略值得深入理解。它采用了一种「无代理」（No Wrapper, No Proxy）的设计，直接从各 AI 编码工具的本地会话存储中读取数据。Claude Code 的会话以 JSONL 格式存储在 ~/.claude/projects/ 目录下，每个文件包含模型名称、Token 计数（输入、输出、缓存读取、缓存写入）、工具调用块和时间戳。CodeBurn 读取这些文件后，按日期范围过滤并进行去重处理，最后应用任务分类器。
定价数据则源自 LiteLLM 的模型定价库，该库聚合了主流模型的输入 / 输出 / 缓存读写价格，并支持 Web Search 成本计算。CodeBurn 每 24 小时自动缓存定价数据，避免频繁网络请求。对于 Claude 模型和 GPT-5 系列，工具内建了硬编码的备用定价，防止模糊匹配导致的定价错误。这种双重保障确保了成本计算的可靠性。
多货币支持也是 CodeBurn 的一项实用特性。它通过 Frankfurter API（欧洲央行数据）获取实时汇率，支持 162 种 ISO 4217 货币代码。汇率同样缓存 24 小时，配置存储在用户本地。整个货币转换链路不依赖任何需要认证的外部服务，极大降低了部署门槛。
工程落地的参数与监控建议
将 CodeBurn 融入日常开发流程，有几个关键参数值得关注。首先是时间窗口的选择 —— 默认的 7 天视图适合日常观察，而 30 天窗口则更适合做月度复盘。对于团队级部署，建议将 JSON 导出与监控系统对接，将任务级别的 Token 消耗和一次成功率纳入 SLO 监控。
其次是缓存命中率的基线。CodeBurn 的仪表板会显示全局缓存命中率，低于 80% 通常意味着系统提示词不稳定或缓存配置存在问题。但需要区分场景：实验性项目的单次会话缓存率低是正常的，而持续数周的项目如果缓存率始终在 60% 以下，则需要检查 Claude Code 的初始化配置。
另一个实用建议是利用 MCP 服务器面板。CodeBurn 会按 MCP 服务器拆分 Token 消耗，如果你发现某个 MCP 工具（如文件系统操作或数据库查询）消耗了不成比例的 Tokens，这可能是该工具实现低效的信号。对应的优化方向包括：减少不必要的 MCP 调用、合并批量操作、或考虑用原生工具替代。
总结
CodeBurn 的出现，代表了 AI 编码工具可观测性从「全局统计」向「任务诊断」的演进。它不只是一款 Token 计量工具，更是一面映射 AI 执行效率的镜子。通过任务级分类与一次成功率这两个核心指标，工程团队得以回答「Token 花在哪里」与「花得是否值得」这两个根本问题。对于正在规模化使用 Claude Code、Cursor 或其他 AI 编码工具的团队而言，引入这类细粒度计量工具是优化成本、提升效率的务实一步。
资料来源：CodeBurn GitHub 仓库（https://github.com/agentseal/codeburn）