性能与成本优化

AI coding 的体验，常常卡在两个点：太慢，或者太贵。大多数团队一开始只盯着 model 价格，后来才发现真正拉高成本的，往往是超长 context、无效轮次、反复重试和一次请求想做太多事。

所以 performance 和 cost 不是分开的两个话题，它们本质上是同一个 workflow 设计问题。

---

先搞清楚：慢，到底慢在哪

很多人说“这个 AI 太慢”，其实没有拆清楚是哪一层慢：

• model 本身慢
• context 太长
• task 太大
• 工具调用太多
• 你让它做了过量解释

如果不拆原因，后面就很容易陷入“盲目换 model”。

---

最常见的 4 个成本来源

你会发现，真正影响账单的，往往不是单价，而是 workflow 不够克制。

---

第 1 步：先把 Task 拆小

一个 prompt 里同时要求：

• 分析项目结构
• 修改多个文件
• 写测试
• 写 PR 描述
• 解释原理

这通常就是又慢又贵的起点。
更好的方式是拆成阶段：

1. 先分析
2. 再改动
3. 再验证
4. 最后补 PR 文案

拆小不仅省 token，也更稳。

---

第 2 步：Context 要精准，不要贪多

不是上下文越多越好。
如果你把整个聊天历史、整个大文件、整个模块都塞进去，AI 不一定更聪明，只会更贵、更容易跑偏。

更好的原则：

• 只给和当前 task 直接相关的 file
• 大文件先 summary，再引用关键片段
• 历史对话很长时先做 context compression

这一步往往是性能和成本优化里最值钱的动作。

---

第 3 步：小 Task 不要默认上大 Model

不是所有任务都需要最强 model。

一句话：别把 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

这个顺序比单纯盯模型定价表更有效。

---

常见误区

---

Practice

回看你最近一次“很慢或很贵”的 AI coding 任务：

1. 是 task 太大，还是 context 太长？
2. 有没有本来可以拆开的阶段？
3. 有没有本来可以用更小 model 的步骤？
4. 有没有不需要的长解释？

把这 4 个问题答清楚，你对 performance / cost 的优化就不再只是“感觉”，而是有具体抓手。