12
性能与成本优化
性能与成本优化
AI coding 的体验，常常卡在两个点：太慢，或者太贵。大多数团队一开始只盯着 model 价格，后来才发现真正拉高成本的，往往是超长 context、无效轮次、反复重试和一次请求想做太多事。
所以 performance 和 cost 不是分开的两个话题，它们本质上是同一个 workflow 设计问题。
先搞清楚：慢，到底慢在哪
很多人说“这个 AI 太慢”，其实没有拆清楚是哪一层慢：
- model 本身慢
- context 太长
- task 太大
- 工具调用太多
- 你让它做了过量解释
如果不拆原因，后面就很容易陷入“盲目换 model”。
最常见的 4 个成本来源
| 来源 | 为什么会贵 |
|---|---|
| 长 context | token 一下就上去 |
| 大而全 prompt | 很多信息其实当前 task 用不到 |
| 无效轮次 | 一直返工，重复生成 |
| 高阶 model 滥用 | 小任务也上最贵 model |
你会发现，真正影响账单的，往往不是单价，而是 workflow 不够克制。
第 1 步：先把 Task 拆小
一个 prompt 里同时要求：
- 分析项目结构
- 修改多个文件
- 写测试
- 写 PR 描述
- 解释原理
这通常就是又慢又贵的起点。
更好的方式是拆成阶段：
- 先分析
- 再改动
- 再验证
- 最后补 PR 文案
拆小不仅省 token，也更稳。
第 2 步：Context 要精准，不要贪多
不是上下文越多越好。
如果你把整个聊天历史、整个大文件、整个模块都塞进去，AI 不一定更聪明，只会更贵、更容易跑偏。
更好的原则：
- 只给和当前 task 直接相关的 file
- 大文件先 summary，再引用关键片段
- 历史对话很长时先做 context compression
这一步往往是性能和成本优化里最值钱的动作。
第 3 步：小 Task 不要默认上大 Model
不是所有任务都需要最强 model。
| Task | 更合适的选择 |
|---|---|
| 简单补全、改文案、PR summary | 小模型或中档模型 |
| 多文件重构、长 context 阅读 | 中高档模型 |
| 高风险推理、复杂分析 | 更强模型 + 人工 review |
一句话：别把 expensive model 用在 repetitive low-risk task 上。
第 4 步：减少无效输出
很多 prompt 默认让 AI 讲太多：
- 解释一大段原理
- 提供多个版本但你根本不会看
- 重复总结你已经知道的 context
更省的问法通常是：
请给最小 patch。
不要写长解释。
只在必要时说明风险和验证步骤。
如果你只是想要可执行 patch，这类限制会明显降低输出体积。
第 5 步：把重复工作转成复用资产
高频 task 如果每次都走完整模型调用，成本很难低。
更好的做法是逐步把这些动作沉淀成：
- snippet
- shell script
- template
- local utility
- cached context summary
这样能把“每次都重新问 AI”变成“只在关键步骤问 AI”。
一个常见的优化思路
long task
-> split into smaller tasks
-> trim context
-> choose cheaper model where possible
-> reduce verbose output
-> reuse validated assets
这个顺序比单纯盯模型定价表更有效。
常见误区
| 误区 | 问题 | 更好的做法 |
|---|---|---|
| 一慢就换 model | 根因可能是 context 过长 | 先拆原因 |
| 什么都给最强 model | 成本容易失控 | 按 task 分层 |
| 上下文越多越好 | 反而更慢更乱 | 做精确引用 |
| 每次都完整解释 | token 浪费大 | 限制输出长度 |
Practice
回看你最近一次“很慢或很贵”的 AI coding 任务：
- 是 task 太大，还是 context 太长？
- 有没有本来可以拆开的阶段？
- 有没有本来可以用更小 model 的步骤？
- 有没有不需要的长解释？
把这 4 个问题答清楚，你对 performance / cost 的优化就不再只是“感觉”，而是有具体抓手。