Claude Code 用了一阵子我某天闲下来把本地留下的使用数据全部翻了出来。一开始只是想看看到底烧掉了多少 token结果越看越不对劲——数据透露出来的使用模式跟我自以为的“高效协作”差得挺远。这篇文章就写给那些同样在用 AI 编程工具、但还没认真算过账的人。我会把分析思路、看到的数字以及数据背后几条不怎么好听但很真实的结论一条条摊开来讲。1. 数据从哪儿刨出来的翻 Claude Code 本地日志的三条路径很多人以为这类工具用完之后不留下痕迹其实恰恰相反。Claude Code 会把你每个会话的交互过程、工具调用、token 消耗、时间戳都记录在本地只是平时没人去看。我这次总共分析了一个多月的数据先从“数据到底藏在哪”说起。1.1 客户端默认留下了哪些痕迹默认情况下会话记录通常会存放在用户主目录下的.claude/projects目录里按项目目录分文件夹每个会话生成一个 JSONL 文件。一行就是一条交互记录字段大致包含角色user、assistant、system内容文本你输入了什么、模型回复了什么工具调用读文件、编辑文件、执行命令等动作token 用量输入和输出的 token 数量时间戳精确到毫秒只要你正常用过这些数据就在那里不需要开启什么特殊开关。你甚至可以把它理解成“黑匣子”——每次命令、每次编辑、每次尝试都被老老实实地记下来了。对我来说最有价值的字段是 token 用量和工具调用序列。token 用量直接对应当前会话的“体力消耗”工具调用序列则能还原出模型在动手之前经历了多少次思考和试探。1.2 我自己写的粗略统计脚本原始 JSONL 文件虽然完整但直接逐行去读根本看不出规律。我花了小半天写了个脚本把所有会话文件聚合起来按项目和操作类型统计。核心逻辑很简单遍历目录下的 JSONL 文件逐行解析成 JSON筛选关键字段再按会话 ID 归类。import json from pathlib import Path from collections import defaultdict data_dir Path.home() / .claude / projects stats defaultdict(lambda: {sessions: 0, turns: 0, input_tokens: 0, output_tokens: 0}) for path in data_dir.rglob(*.jsonl): session_id path.stem for line in path.read_text(encodingutf-8).splitlines(): if not line.strip(): continue item json.loads(line) if item.get(type) not in (user, assistant): continue stats[session_id][sessions] 1 stats[session_id][turns] 1 usage item.get(usage) or {} stats[session_id][input_tokens] usage.get(input_tokens, 0) stats[session_id][output_tokens] usage.get(output_tokens, 0) for session_id, s in stats.items(): print(session_id, s)脚本本身没什么技术含量但它把一个关键问题摊到了台面上我到底在一个会话里平均跟模型来回拉扯多少次又让模型白白阅读了多少上下文。这些数字光靠感觉是永远得不到的。1.3 为什么要自己动手而不是等现成的统计报表可能有朋友会问客户端或者后台不是有用量统计吗干嘛还要自己写脚本翻日志原因有两条。第一平台侧统计通常只到“账单”维度——总共花了多少 token、多少钱但它不会告诉你这些 token 花在了哪些任务类型上也不会告诉你哪些会话最终被 git 保留了下来、哪些被整体丢弃。第二我想要的不是“花了多少”而是“花得值不值”。这个答案只能回到原始日志里自己算。所以我的建议是别停留在看账单把日志翻出来多做一步归因。归因维度至少包括“任务类型”“会话轮次”“最终产出是否被保留”这三个后面你会发现它们的相关性非常明显。2. 先看底账一个月的使用数据长什么样在动手深入分析之前我先把总量拉出来看了一眼。说实话第一眼我就被自己的使用规模惊到了。2.1 总量、轮次和成本量级我统计的时间段大约是 30 个工作日。大致数字如下指标数值会话/任务总数214总交互轮次3,240平均每会话轮次15.1最长会话轮次42输入 token 总量约 1,500 万输出 token 总量约 420 万单任务平均成本约 9 万 token这个成本量级比我预想的大得多。我当时脑补的“随手问一句、改两行代码”场景实际上每个任务平均要消耗约 9 万 token。为什么会这么大因为 Claude Code 每改一个文件通常要先读一遍文件再重写或应用补丁再加上我的多轮反馈token 就像拧开的水龙头一样收不住。更值得注意的是这些 token 并不全是有效产出。我对照 git 提交记录发现大约 40% 的会话产物没有被最终保留要么被我手动回滚要么被后续迭代完全覆盖。换句话说差不多四成的消耗其实是为“试错”买单了。2.2 指令类型分布我到底在让 AI 干什么我抽样了 100 条自己发出的指令做了个大致的分类。看下来发现指令高度集中在少数几个动作上改功能/修 bug38%解释代码/回答疑问21%写测试用例17%重构/整理代码15%杂项格式化、写文档等9%这个分布本身没什么问题但结合“最终保留率”来看就很有意思了。写测试和写一次性脚本这两类任务的保留率最高能到七成以上改功能类的保留率中等大概五成重构类的保留率反而最低经常改完后来又手动调回。我后来复盘才意识到重构看起来是个很“AI友好”的任务但重构用到的清理工具可能也会误删除有隐性作用的老代码而上下文一长模型对这些细节的记忆就开始变得不可靠了。2.3 时间维度的使用习惯什么时间我更容易瞎折腾把时间戳按小时聚合之后模式也很清楚。我的活跃时段集中在工作日上午 10 点到下午 5 点但有意思的是不同时段的“动作含金量”完全不同。上午时段我更多是带着明确任务进来的第一次发出的指令通常就很长工具调用也密集下午尤其是临近下班那段时间明显出现了不少“半成品询问”——比如只丢给 AI 一段报错信息却没有任何上下文和目标描述。这类会话往往还没到产出阶段就草草结束白白消耗了好几万 token。这个发现让我意识到我的精力状态会直接影响指令质量而指令质量又直接决定 token 成本。状态差的时候与其硬着头皮让 AI 兜底不如直接停手第二天再干。3. 数据指向的真实强项哪些任务它确实能替我扛如果说翻数据翻出来的是“坏消息”那也不公平。把保留率最高的任务类型挑出来某种程度上就得到了 Claude Code 的真实能力画像。3.1 脚手架与重复性模板生成保留率最高的任务第一类就是生成脚手架代码。当时我负责一个模拟项目 X 的功能模块需要按既定分层结构新建模型、接口、仓库、服务、控制器一堆文件。这种工作完全符合 AI 工具的能力模型结构清晰、语义空间小、规则可穷举。那次我用一个会话就把整个模块的骨架搭完了二十几个文件统一风格、统一命名我只需要补少量业务逻辑。整个会话只用了 14 轮一次通过没有返工。数据里这一类任务的典型特征是第一轮指令里包含明确的目录结构、命名规范和文件清单。给得越细它生成得越准。这类任务有一个共性确定性非常高。你要的东西不是“创造”而是“按模板批量产出”。只要模板描述得足够精确模型的输出天然稳定。3.2 一次性脚本和数据处理工具第二类保留率高的是“用完即弃”的脚本。日志清洗、批量重命名、把 Excel 转成结构化 JSON、按规则拆分大文件……这些都是典型的单次任务场景封闭验收标准简单跑完不出错就行。我印象最深的是一个日志清洗脚本源文件格式混乱、字段有缺失、编码还不是 UTF-8。我花了五分钟把需求场景描述清楚包括几个特殊边界条件Claude Code 给出的方案比我预想的还要稳当连异常分支都处理好了。这类任务成功率高我分析主要是因为对话里不存在“历史包袱”——模型不需要理解一个庞大系统的来龙去脉只需要根据一小段明确输入产出一个相对独立的结果。这种任务的共同点是需求边界清晰、验证成本极低。跑一下就知道行不行行就直接用不行也不用怕弄坏什么。3.3 测试用例补全与回归用例梳理第三个让我意外的高保留率领域是补测试用例。我以前总觉得写测试是件很需要业务理解的事交给 AI 不够放心。但数据的结论恰恰相反只要我把被测函数的行为描述清楚模型生成的测试用例覆盖面通常比我手动写还全。有一回我要给某个数据解析函数补边界用例自己列了半天只想到常见的空值和异常格式。交给 Claude Code 后会额外补出一堆我想都没想过的分支超大数字、精度损失、尾随空格、Unicode 字符、时区问题。它沿着“输入空间的穷举”这个方向走得很远而这些恰好是单元测试真正需要的价值。不过这里有个前提被测试逻辑必须能够独立运行依赖要少。如果一个函数牵扯到数据库、缓存、外部接口它的测试生成能力就会大打折扣。4. 数据指向的效率黑洞这些场景我接下来不太会碰有强项自然就有黑洞。翻数据之前我对这些黑洞只有模糊感觉翻完之后它们一个个数据确凿地摆在了面前。4.1 上下文越来越长之后的“记忆力错乱”最明显的效率杀手是会话轮次过长。我按会话轮次把任务分组对比“产物最终被保留的比例”结果呈非常清晰的下降趋势会话轮次区间产物保留率典型特征1-5 轮约 70%结构化、目标单一6-15 轮约 55%需要多轮修正16-30 轮约 35%中途改过需求30 轮以上约 20%出现遗忘早期约定的情况轮次超过 30 之后模型“记忆力错乱”的现象变得非常明显早期的命名约束失效了之前确认过的边界条件被遗忘后面生成的代码跟前面的设计打架。我甚至见过一个会话里同一份配置内容被改回了旧值而两个版本都是模型自己写出来的。这背后的机制说穿了也不复杂上下文窗口再大也存在注意力分散的问题。越往后的内容占据的权重越高早期约定逐渐被“挤”出有效记忆区。把上下文理解成一个白板写满之后后面写的内容一定会覆盖前面的部分所以任务一旦复杂到需要反复讨论就千万别硬塞在同一个会话里。我的对策很简单一个任务一个会话中途改需求就果断新开会话把关键约束重新贴一遍宁肯多花点输入 token也不要在同一个会话里无限加轮。4.2 同一个错误修了三次的“打补丁循环”第二种效率黑洞是“同一个错误反复出现”的打补丁循环。数据里有好几条会话模型修了一个 bug跑测试又发现相关问题再修再跑又出现新问题就这个路子循环了五六轮。复盘这类会话我发现根因往往不是模型理解不了 bug而是它不太愿意动结构性的大手术。模型更倾向于在现有代码基础上做最小改动打一个补丁掩盖表层症状。但如果底层逻辑就有问题打补丁只会把问题挤到下一个分支去于是陷入“修一个、冒一个”的死循环。这种情况我现在的处理方式是一旦看到第二次同样的错误模式就会立刻叫停重新描述底层原因不让它继续做小修小补。与其让它修五次不如直接说“把这块逻辑重写一遍不要保留现有实现”通常一轮就能解决问题。4.3 涉及观感和交互细节的前端微调数据里另一种保留率很低的场景是前端观感类任务。比如“这个按钮的间距再调一下”“这个弹窗的位置感觉不太对”“颜色对比度再柔和一点”。这类任务模型不是不能做而是它做完之后我自己基本都会再手动改一遍。原因在于观感这种东西高度依赖“判断标准”而这类判断标准很难在对话里描述清楚。你说了“间距调一下”但对模型来说调到 4px 还是 12px 完全取决于整体视觉节奏不是局部规则能定义的。所以这类任务我会直接自己上手改不再消耗 token 去做低效试错。这不是说 AI 在前端领域没用——写组件逻辑、接口封装它依然很强。但凡是最终效果要“用眼睛验收”的环节我都默认不交给它。4.4 需求没想好就开问的“拉扯成本”最后一种黑洞我要老实承认是自己的问题需求没想清楚就开问。数据里最明显的特征是一些指令只有半行比如“这个模块有点问题帮我看看”“报错了帮忙分析下”。没有上下文、没有目标描述、没有期望输出格式然后就是一轮接一轮的补充说明。我数过这种会话的平均轮次通常比有清晰第一轮指令的会话多出七八轮而最终产出保留率反而不到三成。这不是模型的问题责任全在我这边——我自己都没想清楚要什么自然得不到想要的答案。这类数据的教训很简单在发出第一条消息之前先把目标写下来哪怕只是两三行的简短描述。写出来的过程不光是为了让 AI 理解更重要的是强迫自己把需求想清。指令越模糊拉扯越长成本越高这个规律在我所有会话数据里几乎是铁律。5. 翻完数据后的几条结论也是我和 AI 协作的新规矩数据翻到这里其实已经超越了“看自己用了多少”的阶段。它让我重新定义了跟 Claude Code 协作的方式而且每一条规矩都能在数据里找到依据。5.1 任务拆得越细、越接近原子化成功率越高数据里保留率最高的会话轮次大多在 10 轮以内第一轮指令通常非常聚焦。反观那些动辄二三十轮的会话很多是“把几个子任务混在一个会话里”造成的。所以我现在会把一个稍微大点的改动拆成两三个独立会话。例如“给接口加鉴权”这个任务我会拆成“设计鉴权方案”“实现中间件”“接入并测试”三段每段都单独开会话单独验收。拆开之后的直接好处是每一个会话的上下文长度都保持很短模型不会忘记早期约定我也不需要一遍遍重复关键前提。5.2 上下文是稀缺资源不能拿它当白板以前我有个坏习惯聊技术方案的时候也直接在 Claude Code 里“边想边聊”把 AI 当思维白板。数据告诉我这个习惯极其奢侈一段对话里如果有一半是探索性的讨论最后真正落实到代码的 token 可能只占一小部分。现在的规矩是需要思考的时候自己在编辑器里记录要点想清楚之后再带着目标和要点去问 AI。聊天式探索挪到别的场景去做不要让它在项目会话里消耗上下文容量。上下文是需要保护的资源每一轮无关讨论都在用质量换便利。5.3 用 git diff 审核而不是整段对话回放之前我审核 AI 改过的代码习惯把整个会话从头看一遍试图理解它的每一次思考。这种做法既浪费时间又容易被对话里的错误推理带偏。后来我改成了只看 git diff直接审查最终改动发现效率高得多。具体操作是让它改完代码之后直接退出会话回到终端里看 diff逐行确认是否合理。如果改动太大就先提交到分支再细看。对话记录里那些“模型自述打算怎么做”的内容大多数时候和它最终实际做的并不完全一致不如直接面对产物。5.4 我的轻量模板与系统提示词约束几次数据复盘之后我给 Claude Code 准备了一套自己的系统提示词和指令模板。系统提示词我只放了三条硬约束第一所有文件改动前先说明打算改哪个文件、改哪些部分第二不改变原有命名和编码风格第三遇到不确定的业务规则先提问而不是擅自假设。这三条加进去之后无效改动明显减少。指令模板则更简单我给自己定了一个固定格式任务背景一句、目标一句、约束条件若干条、验收标准一条。不多写但每次必写。看起来多花 30 秒实际上每轮至少省掉两三次来回解释的对话。提示系统提示词里不要塞太多内容否则同样会占用上下文窗口。只写跟本次协作最相关的约束其他一概不写。6. 数据复盘后我真正留下的三个习惯分析完这批使用数据之后我不太再关心工具本身又更新了哪些功能反而更关注自己的工作流值得保留什么。这里记录三个我现在还在用的习惯算是这段数据复盘真正留下来的东西。第一个习惯是定期导出统计。我现在每隔两周会跑一次脚本把最近会话按项目聚合一遍看几个关键指标总 token、保留率、平均轮次。我不太看绝对数字只看趋势。如果某段时间平均轮次明显上去、保留率下降就知道最近的任务切分粒度有问题或者状态不好、指令质量下滑该调整节奏了。第二个习惯是代码离手之前必须自测。这个自测由我做不委托给 AI。Claude Code 生成完代码我一定会自己把边界条件过一遍然后扔给 git diff 审核。原因也很简单数据告诉我AI 写的代码在自己看来永远是“自信的”但它不知道我真正想要什么只有我知道。把验收权牢牢握在自己手里这个工具才能真正成为杠杆而不是橡皮图章。第三个习惯是给“不碰清单”。我给自己列了一张明确不交给 AI 处理的任务清单涉及线上数据的迁移、核心鉴权逻辑的最终改动、以及任何“出问题代价很高”的部分。不是说模型一定做不好而是这些任务一旦出错损失远大于节省下来的时间。把风险高的活儿留给自己把确定性强、可验证的活儿交给它才是数据指向的最优分工。最后再多说一句自己的体会。翻数据这件事本质上不是翻工具的黑匣子而是翻自己工作习惯的镜子。你会发现很多“我以为”和“实际上”的差距也会发现哪些任务你只是在消耗 token 假装高效。定期照一照镜子比追着每一个新发布的功能跑要值得多。
