uzqw

低成本使用 AI Coding：把昂贵推理留给决策，把廉价 Token 用于执行

把昂贵推理留给决策，把廉价 Token 用于执行：通过压缩问题空间、沉淀上下文、减少人类中断，实现 AI Coding 的长期成本优化。

2026/08/15更新于 2026/08/15约 6 分钟

长期使用 AI 编程以后，我逐渐形成了一种比较朴素的成本观：

不是所有任务都值得使用最强模型。

很多时候，模型成本高，并不是因为任务本身难，而是因为：

我没有提前把问题想清楚。

如果一个任务同时要求 AI：

  • 理解陌生项目；
  • 猜需求；
  • 做架构；
  • 判断产品规则；
  • 修改代码；
  • 自己验证；

那确实非常依赖顶级模型。

但如果我提前解决最困难的部分：

  • 问题定义；
  • 核心架构；
  • 数据模型；
  • 约束；
  • 验收条件；

那么剩下大量工作实际上只是：

Execution。

而执行类任务并没有想象中那么需要顶级智能。

这就是我现在使用 AI Coding 最重要的成本优化原则：

昂贵推理用于决策，廉价 Token 用于执行。

AI Coding 的成本不只是 Token

讨论 AI 成本时，很容易只看：

一个模型多少钱。

但真实成本至少有四种：

模型成本
+
人工等待成本
+
返工成本
+
人工决策成本

例如一个便宜模型执行任务花了十分钟，但最终方向错了，需要我重新阅读代码、重新设计，再运行一次。

它实际上可能比昂贵模型更贵。

反过来也一样。

如果一个任务本来只是：

按照明确方案修改 20 个接口错误码。

却交给最昂贵的推理模型。

其实也是资源浪费。

所以真正的问题不是：

哪个模型最便宜？

而是：

什么复杂度的任务，应该分配什么等级的推理能力？

我现在把任务分成两类

第一类是：

Decision-heavy。

例如：

  • 架构设计；
  • 数据模型设计；
  • 跨服务改造；
  • 复杂线上 Bug；
  • 数据一致性问题；
  • 历史兼容；
  • 大型重构；
  • 模糊需求澄清。

这些任务真正昂贵的是：

判断。

需要理解很多上下文，并且错误决策的下游成本很高。

这种任务值得：

  • 自己深度参与；
  • 使用更强模型；
  • 多模型 Review；
  • 多轮推演。

第二类是：

Execution-heavy。

例如：

  • 按方案实现接口；
  • 批量修改；
  • 补测试；
  • 重命名；
  • 清理 Deprecated Code；
  • 根据规范生成 CRUD；
  • 编写迁移脚本初稿；
  • 扫描依赖；
  • 整理文档。

这些任务主要需要：

准确执行约束。

这时候中等能力模型往往已经足够。

真正决定成功率的反而是输入质量。

一个重要变化：先压缩问题空间

以前我会直接把任务交给 AI：

帮我把会员系统重构一下。

这个任务的问题空间非常大。

AI 需要自己决定：

  • 哪些表要改；
  • 哪些接口要改；
  • 什么叫“重构完成”；
  • 老数据怎么办；
  • 旧接口怎么办；
  • 哪些边界情况重要。

模型自然需要大量推理。

现在我更倾向于自己先把问题压缩成：

目标：
会员状态只允许从 subscriptions 表读取。

约束：
users 表历史字段继续保留，但停止作为业务数据源。

需要修改：
profile
refresh
redeem
webhook

不可修改：
老版本兼容接口。

验收：
集成测试覆盖免费用户、有效会员、过期会员、续费四种状态。

这时 AI 面对的问题已经完全不同。

它不需要：

发明方案。

只需要：

实现方案。

问题空间被压缩以后：

  • Token 更少；
  • 错误率更低；
  • 返工更少；
  • 对顶级模型依赖更低。

这实际上比单纯找一个更便宜的 API 更重要。

Context 本身也是成本

很多人使用 AI Coding 时，还有一种隐藏浪费：

不断让模型重新理解项目。

例如每次任务都让 AI：

  • 扫整个仓库；
  • 阅读大量 README；
  • 重新判断目录结构；
  • 猜编码规范。

这会消耗大量 Token，也增加误解概率。

我更倾向于把长期稳定的上下文显式沉淀下来，例如：

AGENTS.md
ARCHITECTURE.md
TESTING.md
ERROR_CODE.md
DATABASE.md

或者通过 Skills 把操作流程固定下来。

这样 AI 不需要每次重新推理：

这个项目应该怎么工作？

而是直接读取既有约束。

本质上，这是在把：

Runtime Reasoning

转化成：

Precomputed Knowledge。

对于高频任务，这个收益会不断复利。

最贵的是人类中断

后来我发现，AI Coding 最大的成本甚至不是 Token。

是：

它不断打断我。

例如 Agent 执行一个任务：

运行
↓
报错
↓
问我
↓
继续运行
↓
发现另外一个问题
↓
再次问我

一个任务可能只消耗几块钱模型费用。

但让我发生五次上下文切换。

对于开发者来说，这可能才是最昂贵的部分。

所以我现在越来越关心：

如何减少 Agent 需要向我提问的次数。

例如提前告诉它：

  • 可以修改哪些文件；
  • 哪些错误允许自行修复；
  • 测试失败如何处理；
  • 什么情况下必须停止；
  • 什么情况可以自己做决定。

理想状态是：

Task
↓
Agent Execution
↓
Tests
↓
Auto Fix
↓
Result

只有遇到真正的：

Architecture Decision

才返回给我。

这比省一点 Token 更有意义。

模型应该像计算资源一样被调度

现在我越来越倾向于把模型看成一种计算资源。

类似：

CPU
Memory
GPU

不同任务需要不同资源规格。

例如：

简单搜索
→ 低成本模型

机械修改
→ 中等模型

复杂 Debug
→ 强模型

架构决策
→ 人 + 强模型 + Review

没有必要所有任务都申请最大的机器。

同样，也没有必要为了省钱，所有任务都跑最低规格。

核心是：

模型能力和任务复杂度匹配。

人真正应该承担什么

如果目标是长期降低 AI 成本，人最重要的工作并不是：

自己多写代码。

而是提前把以下信息变清楚：

Problem Model

系统到底在解决什么问题？

Architecture

职责和数据边界在哪里？

Constraints

哪些东西绝对不能违反？

Acceptance Criteria

什么状态叫完成？

只要这四件事情清楚，大量 Coding Work 就会退化成 Execution Work。

而 Execution Work 是最容易：

  • 自动化；
  • 并行化；
  • 使用低成本模型；
  • 交给 Agent。

这也是我认为程序员使用 AI 后仍然值得持续提高架构能力的原因。

不是因为：

未来还需要亲自写复杂代码。

而是因为：

你对系统理解得越深，越能把复杂问题降维成廉价任务。

我的基本策略

目前我大概采用这样的资源分配方式：

高价值人工注意力
→ 需求、架构、风险、决策

高成本模型
→ 高不确定性推理

普通模型
→ 大部分实现工作

自动化系统
→ 测试、验证、重复检查

这样最终优化的不是：

每百万 Token 的价格。

而是：

每一个正确交付结果，需要消耗多少人工认知。

我认为这是更值得优化的指标。

最后的判断

AI Coding 的长期成本优化，不应该只是不断寻找更便宜的模型。

真正有效的方式是：

降低任务本身需要的智能水平。

通过更好的：

  • 架构；
  • 文档；
  • Constraints；
  • Skills；
  • Tests；
  • Workflow；

把一个原本需要顶级模型才能完成的模糊任务，压缩成普通模型可以稳定执行的确定性任务。

所以我现在越来越认可一句话：

把昂贵智能留给不确定性，把廉价 Token 留给确定性执行。

这可能比“永远使用最强模型”更接近 AI Coding 的长期工程化形态。

评论