事情起因是我让agent帮忙改个接口,后面发现测试有点问题,又让它排查。它改一版我看一版,没过就继续开新对话,顺手还让它把相关代码都解释一下。
最后PR可能就几十行改动,token是狠狠干到一亿。不过mentor也没怎么说我,只让我后面别把AI当无限聊天机器人,有问题先收敛范围,能自己定位的别一上来就把整个仓库塞进去。
有人说,自己一天能用21亿 Token,甚至还有人一天3B。
所以单纯看“1亿”这个数字,并不能直接判断这个实习生到底浪费了多少。
现在很多 Coding Agent 都会反复读取代码、上下文和工具调用结果,最终生成几十行代码,背后消耗大量 Token 并不奇怪。
而且不同产品对输入、输出以及缓存 Token 的统计方式也存在差异。
所以真正值得关注的问题其实是:
花了这么多 Token,工作效率提升了多少?
如果一个复杂模块涉及几十个文件,AI 花大量 Token 最后把问题解决了,那可能完全值得。
但如果只是修改几十行代码,Agent 来回跑了几十轮,最后问题还是靠自己重新定位,那就有点尴尬了。
以前程序员写代码,成本之一是敲代码。
现在 Agent 能帮你写大量代码,真正稀缺的能力开始发生变化。
你能不能快速定位问题?
能不能告诉 AI 哪些文件值得看?
能不能把一个大问题拆成几个小问题?
发现 AI 已经开始跑偏后,能不能及时停下来?
这些能力可能会越来越重要。
比如已经知道接口涉及哪些文件和上下游调用关系,就没必要每次都让 Agent 从整个项目开始搜索。
先限定范围,再给出明确目标;测试失败时,把准确的报错和上下文交给 AI;连续几轮没有进展,就先停下来重新判断问题。
这些操作看起来很简单,却可能直接影响 AI Coding 的效率。
以前大家讨论程序性能,会关注 CPU、内存、磁盘。
以后可能还要多关注一个东西:
AI调用成本。
企业愿意花钱买 AI,最终还是希望员工的产出提高。
如果原来一个程序员一天完成10个任务,使用 Agent 后还是10个任务,但 AI 成本增加了一大截,公司自然会重新评估这种使用方式。
所以真正成熟的 AI 编程方式,并不是单纯追求“少用 Token”。
该让 AI 深度分析的时候就让它分析,该调用工具的时候就调用工具;但如果已经发现方向错了,也要及时停止。
这位实习生被 mentor 提醒,未必是一件坏事。
早点意识到 AI 有成本,学会控制 Agent 的工作范围,对刚入行的程序员来说,反而是一堂挺实用的课。
以后真正厉害的程序员,可能不是每天烧掉最多 Token 的人。
而是知道什么时候该让 AI 多花 Token,什么时候该及时叫停,并用合理的成本把事情做得更快、更稳的人。