前言
之前在掘金写过用 Trae 做 Three.js 魔方，也折腾过 Cursor 接 Blender MCP。那几篇主要是边做边放效果，这次换个角度，看看这些 AI 工具到底用了多少。
刚好掘金最近有 AI 用量晒图活动，我打开自己的统计页，切到 90D、全部渠道，页面上是 1.4B Token。
B 是十亿，换成我们习惯的说法，就是大约 14 亿。
先放截图，后面再聊具体拿它干了什么。
截图时间：2026 年 8 月 28 日 11:20。来源为掘金个人用量页，范围为近 90 天、全部渠道。
一、先把这份账单看明白
把页面里的完整数值展开，是下面这些：
| 项目 | 数值 |
|---|---|
| 总 Token | 1,425,708,605，约 14.26 亿 |
| 输入 Token | 1,121,657,469 |
| 输出 Token | 304,051,136 |
| 页面预估费用 | $699.00 |
这里得说明一下：预估费用不是实际付款金额。 页面怎么统计的，就按它的名称写，不能直接说"我花了 699 美元"。另外，这是近 90 天的数据，也不是某一周、某一个项目的消耗。
这份采集结果里有 Codex 和 Claude。按 Token 看，Codex 占 86.3%，Claude 占 13.7%。以前文章里用过的其他工具，不在这张统计里就不往里面算。
输入比输出多不少。这也提醒我，不能只盯着 AI 最后回了多少字。做代码任务时，要看的文件、报错和前面的对话都可能进入上下文，最终回复只是其中一部分。
不过，用量大不等于效率高。仅凭这张图，也比较不出哪个模型更划算------交给它们的任务都不一样，没法当成同条件测评。
二、最近实际拿 AI 做了什么
下面是近 90 天的趋势图，起伏挺明显。
图能告诉我哪段时间用得多，但没有按开发任务拆分。我不能指着某个峰值就说，这天一定是在修某个 Bug。
所以这里单独拿最近两件有记录的事聊聊。它们能说明我的使用场景，不代表这 14 亿 Token 都花在了上面。涉及业务的名字就不展开了。
1. 配置明明写了，服务还是启动失败
最近在启动一个多服务的 AI 应用，前端、API、后台 Worker、数据库迁移和 MCP 服务要一起跑。模型调用配置已经放进了本地 .env，启动时却还是报错：
text
model_mode=openai 时必须配置 openai_api_key这个问题单看报错，很容易继续盯着 Key 本身查。但当时真正缺配置的是迁移容器。
API 和 Worker 拿到了环境变量，迁移服务没有。它又复用了同一套配置校验，启动时同样要求模型 Key，于是还没开始迁移就失败了。
文件里有配置，和目标进程拿到了配置，是两回事。
这次 AI 帮忙做的工作，就是沿着启动配置往下查：哪个服务报错，它加载哪套配置，Compose 又给它传了哪些变量。最终把这项配置放到共享环境配置里，让几个需要它的服务统一继承，没有去改业务逻辑。
修完也没停在"容器已经起来了"。当时继续检查了迁移退出码、API 就绪接口，以及 Worker 能否初始化 MCP 连接并列出工具。这些检查通过，才算把这次启动问题处理完。至于完整业务流程，还得另外验证。
对我来说，这类任务挺适合让 AI 参与。它需要同时对照几个文件，不一定写很多新代码，但能帮着把容易漏看的地方串起来。前提是把报错和相关文件给清楚，否则一句"启动不了，帮我修一下"，排查范围就太大了。
2. 给 H5 加个返回按钮，先别急着写接口
另一个需求小得多：给 App 里的 H5 加一个退出按钮，其他地方不要动。
看起来只是补个图标，再绑个点击事件。实际上还得弄清楚，"退出"是返回网页上一页，还是通知宿主 App 关闭当前页面。
这次查完接口文档，再看项目，发现运行时里已经有 exitApp()，桥接调用和结果检查都封装好了。页面只要复用，不需要再写一套。
最后改动集中在三个地方：顶栏按钮、页面的退出回调、按钮样式。点击之后暂时禁用，失败时恢复可点击，并走已有的错误提示。
这也是我希望 AI 做小需求时保持的尺度。已有实现能用，就沿着原来的结构接上。一个返回按钮，不需要顺便把整个页面重新整理一遍。
这里还有个不能省略的检查：类型检查通过，不代表手机 App 里一定能退出。宿主注入的桥接能力，本地浏览器没有。当时完成的是代码和静态检查，真正的关闭动作还需要放进 App 验证。
如果最后只留下"功能已完成"五个字，过几天回头看，很容易把这两个状态混在一起。
三、比起把问题写短，我更想少来回改几次
这次整理用量，我没有做严格的前后对照实验，所以就不写"这几个技巧能省一半 Token"了。下面是结合这些任务，我觉得值得保留的几个做法。
先说清楚哪些地方不能动。
比如那个退出按钮，约束就是复用已有逻辑、别碰其他功能。把这个范围摆在前面，后面审查时也容易判断：这段修改到底是不是需求需要的。
报错给上下文，但不用把所有东西都丢进去。
服务名、失败命令、关键报错、相关配置文件，通常比一大段无关日志有用。像启动失败那次，先确定是迁移容器缺配置，才有后续的修复方向。密钥值不需要发给 AI，更不应该出现在文章截图里。
把"怎么才算完成"一起告诉它。
页面需求看效果和交互；服务启动看就绪状态和实际调用；依赖 App 的能力，单独列出真机验证。这样最后拿到的结果才不只是几份改过的文件。
把这些要求合起来，我会这样描述一个类似的任务。下面是整理后的示例，不是原始对话：
text
请先定位迁移服务启动失败的原因，暂时不要改代码。
报错提示缺少模型调用配置。
重点检查配置加载和 Compose 中的环境变量传递，
不要输出任何密钥值。
确认原因后，说明需要修改哪些文件。
修复只涉及启动配置，不调整业务逻辑。
修改后验证迁移退出码、API 就绪状态和相关服务间调用，
最后说明通过了哪些检查，还有哪些没有验证。这段话不算短，但读完能知道要查什么、能改什么、最后要看什么。对我来说，这比让 AI 先猜一轮，再追着补限制更实用。
当然，检查本身也会消耗 Token。该查的代码、该跑的验证，我不会为了数字好看就省掉。更值得减少的是查错方向、改了无关文件，然后再花几轮把它们改回来。
最后
这次晒账单，留下来的数字是近 90 天约 14 亿 Token。具体到开发里，就是一次启动排错、一个小按钮，以及很多这样的任务。
AI 可以帮我看文件、找问题、补代码，但改动是不是合适、验证到哪一步，还是得看清楚。下次再碰到"配置都写了，怎么还报错"，至少我会记得先问一句：到底是哪个进程没拿到？
想看看自己的使用情况，可以去 掘金 AI 用量页。记得先选好统计范围，7 天和 90 天，确实是两份不一样的账单。