阅读代码的成本高于编写代码，却没有人提醒过我
我原本对自己使用 AI 编程工具的方式有一个很笃定的设想：写代码。样板代码、脚手架、那些枯燥的活儿。为此，我导出了一年的会话日志，逐一做了分类。结果证明，这个设想是错的。
实际分布是：
- 理解代码：约 50% —— 这个模块是干什么的、数据在中间如何流转、当初为什么做出这个决定、它处理了哪些边界情况。
- 编写新代码：约 30%
- 核验与审查：约 10%
- 其他杂项：约 10% —— 语法查询、格式转换、查文档。
我有一半的使用时间其实是在读代码，而我过去一整年，都在针对占比更小的那一半做优化。
为什么这一点在操作层面很重要
理解代码不仅是占比最大的类别，也是单位价值成本最高的。回答「这里的 auth（认证）是怎么实现的」这类问题，意味着要读一大摞文件，而这些内容全部会进入你的上下文窗口（context window）。用量又是按上下文计费的：这个会话里之后的每一条消息，都要背上模型为了回答那个问题而读过的所有内容。于是，这个最高频的类别，同时也在抬高后续一切交互的成本。
找准问题之后，解决方案就清晰了
把理解型任务交给子代理（subagent）去处理。子代理在自己的上下文窗口里完成阅读，只返回一份摘要；主线程拿到答案，却不必带着生成答案所读的那二十个文件。比如，可以派一个子代理去调查 auth 模块里的 token 刷新机制是如何工作的，以及项目里是否已有现成的 OAuth 工具。
值得继续沿用的做法是：只让它报告发现，不要改动任何代码。同样的答案，下游成本却省了一大截。针对这个后来占了全部用量一半的类别，我做出的这一处改动，比此前所有优化加起来都有效——其中有些我之前还挺得意。
补充发现：杂项类占比比预想中高，约 10%，但大多没什么价值。现在语法问题、概念查询这类需求，我会在轻量模型上临时开个会话，问完就关。它们不值得占据主线对话，把后面的上下文撑得又长又贵。
验证类占比则比预期低，这一点让我不太舒服。它是我最看重、顶住压力也要做的环节，实际分配到的开销却不成比例。于是我有意识地加大了这部分投入。
月度差异非常大。最忙的一个月开销大约是清闲月份的 3 倍——区别就在于那个月有没有碰上迁移或积压的代码评审。
如何自己做同样的事
大多数命令行工具（CLI）都会在本地保存会话历史。把历史导出，按使用意图分组、计数。分类过程很粗，但没关系——你要的是大致分布，不是精确结果。一个晚上就能做完。
为什么要费这个事：因为你很可能猜不准自己的使用分布。你做的每一个效率决策，其瞄准的都是你当前脑子里认定的那个分布。如果这个认定是错的，瞄准也就错了，而且你没有其他途径能发现。
方差问题
第三个发现解释了我一整年的困惑：为什么订阅档位怎么选都觉得不对。我以前是按自己最忙的那个月来定档，然后接下来几个月几乎不打开，却一直按那个价格付费。我审计的那三个月，实际利用率大概只有 40%。订阅定价默认的是平稳消费，但工作是以项目为单位的，而项目是有起伏的。
我现在选用一个低基线档位，爆发期用 Asale 来覆盖——这是一个闲置订阅容量交易市场，容量会转给有需要的人，按每百万 token 计价。它每次请求生成的记录，刚好也是我最初能完成这次审计的原因。
有一点需要提前说明，好让你判断它是否适合你：请求会经由另一个用户的客户端转发，所以在这一跳中，请求数据是可见的。
服务首页明确写了不支持端到端加密，还提示共享订阅额度可能违反上游服务条款。个人项目和开源项目用着没问题，但签了保密协议（NDA）的工作就不行了。
如果你也做过类似的统计，我很想知道你那边读写时间的占比是多少。我猜「读代码占大头」这种情况很普遍，只是很少有人认真讨论过。