【AI Talk】11 Token 的工程汇率学

最近我的日均 Token 消耗来到了五千万的量级，无论是编码还是文档的工作都有很大一部分是和 AI 协作完成的（当然本文是纯手打），在不同的模型间来回切换，让我发现了一个很有意思的事情，我管它叫做“Token 的工程汇率学”。

已知国外的 Coding Plan 是 200 刀，国内的一般是 200 元，这里有一个货币的汇率，我刚查的是 6.82。考虑到国内的 Coding Plan 一般会量大一些，以 GLM5.1 的 Max 套餐为例，469 元可以得到大约 3 个国外的 Coding Plan。这样一波折算下来，单个 Token 的汇率是 8.7（1海外 Token兑换8.7国内 Token)。但是因为不同模型的智能程度和配合 Agent 的消耗量不同，所以实际在不同任务上，对应的工程汇率会有很大的波动。

简单来说，工程汇率决定了怎么样才是更有性价比的，假设模型智能相同，工程汇率是货币汇率的倒数，即同样的价钱，用国内模型的产出是海外模型的 8.7 倍。但实际上，单价更贵的模型往往可以转化为更少的返工次数、Token 消耗和重构次数，最终的结论可能反而是 Token 越贵，Token 就越便宜（更聪明的模型在完成任务的成本上反而更低）。

从追求性价比的角度来说，实际上我们可以通过很多不同的方式来提升国内模型的工程汇率（哪怕从 8.7 下降到 4，都还有 4 倍的成本优势）。各家基础大模型的厂商都在推出的 Harness 特性实际上都在通过工程的方式提升单个 Token 的性价比，那么对于上层的应用构建来说，还有一些其他的方式来优化工程汇率。

第一个方法就是更好的提示词，并不是结构上的精雕细琢，而是在方法论上引导 Agent 直接找到 80 分的方案。这里是高级程序员的主场，因为大模型学习了足够多的开源代码，实际上只需要思路上的简单引导，就可以很快达到最佳实践。当然，非科班出身也一样可以最终达到最佳实践，只是可能多 1-2 次试错。

第二个方法是构建自己的 Auto 模式。不少 Coding Agent 都有 Auto 模型，即会自动评估任务的难度，选择最合适的模型。但在一个领域做了一段时间之后，实际上应该有自己的判断，直接选择最合适的模型，以达到最佳的工程汇率。95 分的模型应该做 90-95 分的任务，用来做 60 分的任务不是不可以，但就性价比不高。

第三个方法是 Unix 哲学。每个工具只做一件事情，但是做得足够好，这样消耗的上下文长度可以得到很好的控制（长上下文又贵又慢），ALL in One 只适合模型层面的融合，应用层面返璞归真才是最有性价比的。但分久必合合久必分，工程学是一个循环，可能明年又会得到不同的结论。

最后分享一下我的常用方法：架构设计用最贵最聪明的，功能实现测试驱动用国内的足矣。