AI 编程工具 50% 用在读代码而非写代码

我对自己如何使用 AI 编程工具有一个自信的心理模型：写代码。样板文件、脚手架、那些繁琐的部分。

我导出了一年的会话日志并做了分类。这个模型错了。

实际分布

理解（Comprehension）：约 50%。这个模块是做什么的，数据如何流经它，这个决定是怎么做出的，它处理哪些边缘情况。

写新代码：约 30%。

验证和 review：约 10%。

杂项：约 10%。语法查询、格式转换、文档。

一半的使用量在阅读。我花了一年时间在更小的那个部分上做优化。

为什么这在操作层面很重要

理解不只是最大的分类——它是单位价值下成本最高的类别。

回答"这里的 auth 是怎么工作的"意味着要读很多文件。所有这些都会进入你的上下文窗口。而用量是按上下文计费的：会话中每条后续消息都背负着模型为回答那一个问题而读取的所有内容的重量。

所以这个最高频的分类同时也在膨胀着后续所有内容的成本。

一旦知道该瞄准哪里，解决方案就清晰了

通过子代理来处理理解类请求。

子代理在自己的上下文窗口中读取内容并返回摘要。你的主线程收到的只是答案，而不是产生答案的那二十个文件。

Use a subagent to investigate how token refresh works in the
auth module, and whether there are existing OAuth utilities
worth reusing. Report findings, don't modify anything.

同样的答案，只是后续成本的一小部分。

针对这个占据我一半使用量的分类，这一项改动比我自己尝试过的所有其他优化加起来效果都更好——包括好几个我此前相当满意的优化。

杂项比预期要大。百分之十，大部分价值较低。语法问题和概念查询现在会进入一个轻量模型上的可丢弃会话，用完即关。它们没有理由占据主线程并膨胀后续所有内容。

验证比预期要小，这让我有点困扰。这是我在压力下最会为之辩护的分类，但它并没有获得相应的投入。我现在已经刻意增加了它。

月度差异很大。繁忙月份的用量大约是安静月份的 三 倍——取决于那个月是否恰好包含一次迁移或一批待 review 的内容。

如何你自己做这件事

大多数 CLI 会在本地保存会话历史。导出来，按意图分组，计数。

分桶方法很粗糙，这没关系——你要的是大致分布，不是精确数字。一个晚上的工作量。

为什么要费这个事：你很可能猜不对自己的分布。你做的每个效率决策都瞄准着你目前以为的分布。如果那个判断是错的，那瞄准就是歪的，而且你找不到其他方式来发现。

第三个发现解释了一件困扰我一整年的事：为什么我的订阅档位总觉得不对。

我一直按最忙的月份来选择，然后在其余几乎不怎么打开这个工具的月份也支付那个费率。在我审计的三个月中，利用率约为 40%。

订阅定价假设消耗大致是平稳的。但工作按项目到来，而项目有它的形状。

我现在用一个低档位基础订阅，然后通过 Asale 覆盖峰值——这是一个市场，未使用的订阅容量会被导向需要它的人，按每百万 token 定价。它产生的按请求记录恰好使得这次审计成为可能。

决定适用性的披露：请求会通过另一个用户的客户端中继，所以在那一跳上Payload是可见的。没有端到端加密——他们的首页上声明了这一点，并注明分享订阅容量可能与上游条款冲突。个人项目和开源，没问题。NDA 约束的工作，不行。

如果你做过这个练习，我会很好奇你的分配是什么样的。我怀疑阅读偏重的模式很常见但很少被讨论。