在 AI 辅助编程场景中，Token 消耗的透明化是成本控制的第一步。CodeBurn 作为 Claude Code 專用的開源分析工具，通过直接读取本地会话数据（~/.claude/projects/），在不使用任何 Wrapper 或代理的前提下，将每一次交互的 Token 消耗归类到 13 种确定性的任务类型中。这种任务级别的细粒度分解，为理解和优化 AI 编程成本提供了可操作的量化基础。
13 类任务的分类机制与消耗特征
CodeBurn 的任务分类并非依赖 LLM 推断，而是基于确定性的规则：从工具使用模式（如 Edit、Write、Read、Grep、Bash）和用户消息关键词（如「add」「create」「refactor」「pytest」）中提取特征。当检测到特定的工具组合或关键字时，该次交互即被归入对应类别。以下是各类任务的典型消耗特征与优化要点。
Coding（编码任务）
编码任务是最核心的消耗来源，使用 Edit 或 Write 工具时触发。CodeBurn 追踪的 One-Shot Rate（一次性成功率）指标在此类别中尤为关键 —— 该指标通过检测 Edit → Bash → Edit 的重试循环模式，计算有多少比例的代码编辑在首次尝试时即告成功。如果 Coding 类别的 One-Shot Rate 持续低于 60%，通常意味着 Agent 在代码修改时陷入反复试错循环，Token 消耗被低效地消耗在「编辑 - 测试 - 修复」的迭代中，而非产生实际代码价值。优化方向包括：提供更完整的上下文（相关函数签名、依赖模块），减少 Agent 猜测代码结构所需的探索性读取。
Debugging（调试任务）
调试任务通过错误相关关键词（如「error」「fix」「bug」「issue」）结合工具使用模式触发。由于调试通常涉及复现问题、定位根因、修改代码的全链路操作，其 Token 消耗往往呈现输入占比高的特征 ——Agent 需要反复读取报错堆栈、相关源文件、日志输出，才能逐步收敛到正确的修复方案。值得注意的是，调试任务的 One-Shot Rate 通常低于编码任务，这是因为错误的多样性和上下文依赖性更高。对于高频调试场景，建议在提示中直接提供完整的错误上下文（包括堆栈信息、相关配置、环境变量），以减少 Agent 自主探索的开销。
Feature Dev（功能开发）与 Refactoring（重构）
功能开发任务由「add」「create」「implement」等关键词触发，重构任务由「refactor」「rename」「simplify」触发。这两类任务的 Token 消耗差异显著：功能开发通常涉及新代码的编写，输入以需求描述和现有代码为主；重构则在修改现有代码的基础上进行，输入更多包含待重构代码的上下文。CodeBurn 的仪表盘会将这两类任务的消耗分别展示，配合 One-Shot Rate 可识别出重构过程中的痛点 —— 如果 Refactoring 类别的一次性成功率偏低，说明 Agent 对代码结构的理解存在偏差，可能需要显式提供架构图或关键依赖关系。
Testing（测试任务）
测试任务通过检测 Bash 中的 pytest、vitest、jest 等测试框架关键字触发。测试任务的特点是输出 Token 相对固定（生成测试用例代码），但输入 Token 波动较大 —— 取决于待测代码的复杂度和测试覆盖率要求。在实践中，Testing 类别的消耗往往被低估，因为测试用例的编写需要 Agent 理解被测模块的接口和边界条件。优化建议：将测试任务拆分为「理解被测代码」和「生成测试用例」两个阶段，在提示中明确指定测试框架和覆盖率目标，减少 Agent 在工具选择上的探索消耗。
Exploration（探索任务）
Exploration 任务在仅使用 Read、Grep、WebSearch 而不产生代码编辑时触发。这类任务的消耗通常呈现输出 Token 极低的特点 ——Agent 主要在做信息收集和代码阅读，生成的文字量有限。CodeBurn 仪表盘中的「Read 调用次数」和「Shell 命令」_breakdown 是 Exploration 任务的关键监控指标。如果一个会话中 Exploration 的 Token 消耗占比过高但最终未产生任何代码修改，可能说明任务目标不够清晰，导致 Agent 陷入过度探索。优化方向：在提示中明确探索的目的和终止条件（如「找到满足条件的函数后立即停止搜索」），避免无目标的代码库漫游。
Planning（规划任务）
规划任务通过 EnterPlanMode 或 TaskCreate 工具触发，通常发生在复杂任务的起始阶段。其 Token 消耗以输出为主 ——Agent 生成结构化的任务分解和执行计划。Planning 类别的监控价值在于：如果一个项目的 Planning 消耗异常偏高，可能意味着任务拆解不够清晰，或者 Agent 在规划阶段花费过多时间犹豫不决。建议结合 One-Shot Rate 观察：低 One-Shot Rate 的 Planning 任务往往产生过度复杂的计划，后续执行时需要频繁调整，反而增加总体消耗。
其他任务类别概览
Delegation（委托）任务通过 Agent 工具的调用触发，用于追踪子 Agent 的 Fan-Out 消耗；Git Ops 任务追踪 git push/commit/merge 等版本控制操作的消耗；Build/Deploy 任务追踪 npm build、docker、pm2 等构建部署流程的 Token 消耗；Brainstorming 任务在「brainstorm」「what if」「design」等关键词下触发，用于创意讨论；Conversation 任务在无工具调用的纯文本交互时触发；General 任务处理 Skill 工具调用和未分类场景。Dashboard 中的 Core Tools、Shell Commands、MCP Servers 面板分别展示了这 13 类任务在工具层面的细节分解。
可落地的成本监控参数与阈值
基于 CodeBurn 提供的量化能力，以下是一套可直接用于生产环境监控的成本参数建议。
缓存命中率监控：CodeBurn 从 Claude Code 会话中提取 cacheRead 和 cacheWrite 数据，计算缓存命中率。缓存命中率持续低于 80% 时，通常意味着系统提示或项目上下文不够稳定，Agent 每次交互都需要重新加载大量上下文。建议将缓存命中率纳入日常监控，当 7 日滚动平均值低于 80% 时，检查项目配置文件和系统提示是否发生了非预期变更。
单次会话成本上限：CodeBurn 仪表盘展示每个项目的日成本图表和最昂贵的 5 个会话。对于个人开发者，建议将单次会话成本阈值设置为 2 美元（以 Opus 4.0 定价为基准），超过阈值时触发告警。对于团队场景，可根据项目复杂度差异化设置 —— 实验性项目阈值可适当放宽，生产维护项目阈值应收紧。
One-Shot Rate 基线：建议为不同任务类别设置差异化的 One-Shot Rate 基线。Coding 和 Feature Dev 的一 - shot 率目标应 ≥ 70%；Debugging 和 Refactoring 由于任务复杂度较高，基线可设为 ≥ 50%；Testing 的基线设为 ≥ 60%。当某类任务的 One-Shot Rate 持续低于基线时，需要审视提示策略或项目上下文的组织方式。
MCP 服务器消耗追踪：如果使用了 MCP 工具（如文件系统访问、数据库连接等），CodeBurn 会单独追踪 MCP 服务器的 Token 消耗。正常情况下 MCP 消耗应占总消耗的 10% 以下，超过该比例可能说明 MCP 工具的使用效率存在问题 —— 例如 Agent 频繁通过 MCP 读取同一文件而非利用上下文缓存。
模型选择成本监控：CodeBurn 按模型（Opus、Sonnet、Haiku 等）分解成本。如果发现 Opus 4.6 在简单任务（如代码浏览、小修复）上的消耗占比过高，说明模型选择不够精准 —— 对于此类任务，显式指定使用 Sonnet 或 Haiku 可显著降低成本。可以在 Claude Code 配置中针对不同项目类型设置默认模型，避免过度使用高配模型。
工程化集成路径
将 CodeBurn 融入开发流程的核心思路是「度量 - 分析 - 优化」的闭环。在度量层面，建议通过 codeburn status --format json 将每日的 Token 消耗数据导出到团队的可观测性平台（如 Grafana 或 DataDog），设置成本仪表盘和异常告警。在分析层面，利用 codeburn report -p 30days 定期回顾过去一个月的任务分布和 One-Shot Rate 变化趋势，识别成本异常增长的任务类别和项目。在优化层面，根据分析结果调整提示策略 —— 例如在 Exploration 任务中添加明确的终止条件，或在 Coding 任务中提供更完整的上下文。
CodeBurn 的核心价值在于将抽象的「AI 编程成本」转化为可分类、可量化、可优化的具体指标。当开发者能够清晰地看到每个任务类型的 Token 消耗占比和一次成功率时，成本优化就不再是凭直觉的猜测，而是有数据支撑的系统性决策。
参考资料
- CodeBurn 官方仓库：https://github.com/agentseal/CodeBurn