省在完成任务，不在省调用

工具调用便宜但任务没完成，已花的钱全是浪费。子 agent 降档是最大杠杆。

新手省成本容易盯着"调用了多少次 AI"。但真正的成本单位是"完成一个任务花了多少"。一个便宜调用但你反复返工的任务，比一个贵一点却一次到位的贵得多。

读完你能回答：

为什么"省调用次数"是省钱的反方向？
"省在完成任务"具体怎么落地？
最大的一根成本杠杆是什么？

为什么省调用不对

便宜调用但烂结果 = 最贵：工具调用一次很便宜，但因为没做对反复来，累计的钱远超一次好的调用
把 prompt 压到影响质量，再省下的 token 也会在返工里赔回去 copilot-cost
优化要把「完成任务」当分母：任务没完成，花在它上面的每一分都是浪费

省在完成任务

一次写对：上下文给足、验收标准清楚，减少返工，比"调用少"有效得多
批量在一轮里做：能并发、能一轮塞的，别拆成十次来回
让验证快速抓住错：错得越早发现，返工越少，越省

最大杠杆：子 agent 降档

定义明确的子任务用低成本/小模型，主任务用强模型兜底——这是单项影响最大的省钱手段 google-patterns
简单任务别都上最强模型，杀鸡不用牛刀
允许手动覆盖：关键时刻还是上最强

第二根杠杆：缓存命中是架构属性

prompt 缓存的本质是「只对没变的前缀重新计费」。因此它省不省，不取决于开了哪个参数，而取决于请求形状是否稳定：系统提示、工具定义、静态文档放在前面长期不动，追加的只有会话内容。如果一个请求把易变内容（时间戳、每轮重写的系统提示、随机排序的工具列表）混在前缀里，命中就无从谈起——这是调用方代码结构的属性，不是调优参数 anthropic-cost-performance。

把它当架构决策而不是省钱开关来做：前缀的组成、顺序和稳定性在写第一版请求组装代码时就定下来，而不是等账单出来再想办法。这其实就是「省在完成任务」的另一种形态——每次都重新加载整个前缀，和为返工反复付的钱是同一种浪费。

该花的舍得：按收益上限选模型

省钱的对偶问题是「什么时候该上最贵的」。前沿模型可能贵 100 倍，换的是多一个概念点的智能——值不值，看任务的收益上限 a16z-cascading-loops：

收益无上限的任务（研究、可能改变方向的关键判断）：多一分智能可能带来不成比例的价值，用前沿模型是理性选择
结果有界的任务（账目核清、格式合规）：「对」就是「对」，不会「对 100 倍」——用足够能力的便宜模型就够
判据是收益上限，不是可验证性；而且选型结论有保质期——前沿随版本每几周移动，要定期用真实任务重评

把"该省的省、该花的舍得"想清楚，vibe coding 的账才不会越算越亏。

成本守住之后，最后进入"越做越好"的收尾章：知识飞轮与持续协作。