一次 AI 辅助编辑的Token消耗复盘看看我们的钱花哪儿了

上周编辑了两篇文章，过程都被完整记录了下来。两篇都不是一次定稿，而是经过了多轮修改、重写和格式调整。通过用旗舰模型分析在 AI 辅助编辑文章时，不同模型的调用量、Token 消耗分布，以及消耗主要集中在哪个环节。

文章 A：一篇促销短文，经历了”初稿 → 格式调整 → 重写 → 口语化润色 → 排版修正”五个阶段，累计产生 89 次 API 调用。

文章 B：一篇测评文，主要是去掉内联样式并更新内部规范，迭代较少，累计 30 次 API 调用。

一、模型使用情况

文章 A：四模型接力

文章 B：单模型直出

二、核心发现：Token 消耗到底在哪儿

1. Input 占绝对大头

两篇文章合计消耗约 2200 万 Tokens，其中 Input 占 99.3%，Output 仅占 0.7%。

也就是说，钱的 99% 没花在”让 AI 写内容”上，而是花在”告诉 AI 之前发生了什么”。

2. 上下文膨胀是主因

每次 API 调用，系统都要把整段对话历史（包括之前的所有指令、AI 的回复、工具返回的网页源码、文件内容、报错信息）重新打包发送。轮数越多，包袱越重。

文章 A 的最长一次 Input 达到了 27.6 万 Tokens——这不是在生成文章，而是在搬运历史。

3. 多轮迭代是罪魁祸首

对比两篇文章：

• 文章 B（30 轮，287 万 Tokens）：需求明确，一次说完，迭代少。
• 文章 A（89 轮，1909 万 Tokens）：经历了”重写 → 再改 → 再润色 → 再调排版”，每一轮都背着前面的全部历史。

同样的输出量，文章 A 的成本是文章 B 的 6.7 倍。

4. 工具返回结果也是隐形负担

编辑过程中频繁使用了文件读取、网页抓取、代码执行等工具。这些工具返回的内容（例如一个完整的 HTML 文件、一个技能规范文档、一次部署日志）都会被保留在上下文中，成为下一轮 Input 的一部分。

三、哪个环节最烧钱

如果把文章 A 的 1909 万 Tokens 拆开看：

• 初稿阶段：133 万（7%）
• 格式调整+发布阶段：571 万（30%）
• 重写阶段：133 万（7%）
• 反复修改+润色阶段：1072 万（56%）

超过一半的成本烧在了最后的”反复微调”阶段。 此时历史上下文已经累积到几十万 Tokens，每说一句话都要先搬一次家。

四、为什么消耗会失控

“先写一版看看”心态：初稿方向未定，导致后续推翻重来，历史作废但不消失。

碎片化指令：”口语化一点””优惠码位置不对””更新下”——每句都是新轮子，但轮子都没拆旧包袱。

工具输出的累积：读取一个大文件后，其内容永久留在上下文中，即使后续只修改其中一行。

五、可以怎么省

基于这次复盘，有几个实操建议：

1. 需求一次给齐
把”语气、格式、位置、价格”一次性交代清楚，比先写出来再看能少 60% 以上的迭代轮次。

2. 大改不如新开
当发现需要推翻重写时，直接开一个新会话，把核心素材重新喂进去。新会话的上下文从零开始，比带着 27 万 Tokens 的历史包袱要便宜得多。

3. 精简指令，聚焦动作
“把第三段的价格改成 33 元”比”更新下”更高效。前者让 AI 只做增量修改，后者可能触发全文重读。

4. 定期归档历史
对于长会话，可以在关键节点做一次”状态快照”（例如把当前确认的标题、价格、链接写进一个独立文件）。后续轮次引用快照而非搬运整段历史。

5. 区分”创作模式”和”执行模式”
创作需要上下文连贯，成本高。而纯格式调整、价格更新等原子操作，可以用轻量级方式完成，几乎不携带历史。

六、结语

这次复盘最意外的发现是：AI 辅助写作的成本大头不在写，而在记。模型没有人类的遗忘能力，你每说一句话，它都要把前面说的所有话再背一遍。

所以，用好 AI 的关键有时候不是怎么问得更好，而是懂得什么时候该新建对话。