朋友委托我搭建一个化妆品购物网站。在公司一直只写C，这是一个尝试新技术栈的机会。支付用Toss Payments，前端用React。“金融业下一代项目全在用React"这句话一直在我心里，Toss Payments也是Node友好的。方向很快就定下来了。

当然，我从来没用过这个技术栈。有热情，但不是那种可以先学再做的deadline。所以我试了一下vibe coding。

“帮我做一个卖化妆品的购物网站，参考网站地址是～。“就这么一句话，它自己噼里啪啦一阵，连我没想到的部分都设计出了mockup。啊，vibe coding出来一年多了，我完全落后了。

计划靠读Claude生成的代码来学新技术栈，这个想法蠢到不行。我读代码的速度远不及Claude生产代码的速度。所以我不自己review了，让它自己review自己的代码。（人类时代的终结似乎要来了。）

用着用着，Claude开始丢失之前的上下文。搜了"context"这个词才知道原因。也找到了用子agent分角色的方案。pm、dba、back、front、qa——搭了5个结构。CLAUDE.md里定义了路径规则、会话运营指南等所有内容。使用量在15%左右。这应该够了吧。

三小时后，我看到了 You've hit your limit · resets 3am。

凌晨3点重置，这个我理解。但我不理解的是——为什么三小时就到了？

从一开始扣子就扣错了

搭5个agent的时候，我有一个错误的假设：“Claude思考越多，消耗的token就越多。“没有根据。只是觉得应该是这样。

每个agent都填满了if-then规则。消除Claude需要推理的空间，推理成本就会降低——我是这么相信的。CLAUDE.md也是用这个逻辑填的。

碰到limit之后才去搜索。那时候才知道自己错了。Claude消耗token的大部分不是推理，而是读取。agent每次执行都从头读完整个CLAUDE.md。我辛辛苦苦填的CLAUDE.md，每次执行都整个加载进上下文。

把散文式说明压缩成表格，删掉重复项。消耗速度降了下来。

拆得更细token就会少吧

轻量化之后，Compacting conversation...出现的频率降低了。context维护得很好。开心。

但看token消耗，反而漏得更多了。

“把角色分得更细，每个agent处理的范围就更窄了吧。“这是下一个尝试。

从5个增加到12个。api-designer、ui-designer、performance-engineer、security-auditor……一个按阶段系统化分工的结构。

context维护得很好。但token感觉漏得更多了。

含泪合并

让Claude诊断原因。感觉像在听法院宣判。token.. my precious…

agent数 = CLAUDE.md读取次数。12个agent每次都把它读12遍加载进上下文。拆得越细，烧得越快。

必须缩减。虽然真的很用心做的，但含泪合并了。

api-designer并入backend-developer，ui-designer并入frontend-developer，performance-engineer并入code-reviewer。

项目前后节省
agent文件总容量112KB40KB-64%
agent数量12个9个-3个

使用量消耗速度明显改变了。

所以升级了Max

结构理顺之后才真正体会到Claude的工作速度。确实花钱。但处理速度超乎想象。自己做要好几天的工作，一个session就搞定了。

升级到Max计划，不浪费地好好用。

结构问题解决了。为了守护my precious，没有停止搜索。然后发现了。Claude读文件时，500行就读500行。跑测试时，连成功的case都全部加载进上下文。不是agent数量的问题。是Claude看的东西本身就是问题。

怎么才能让Claude只看需要的东西？

本系列其他文章

参考