Day 071 · AI 产品怎么做成本控制：我的优化思路

上一篇写到，我在测试一个 AI 产品时发现，一次完整使用流程可能花掉几美元。

真正开始优化以后，我发现，AI 成本控制并不只是缩短 Prompt、减少输出，或者换一个更便宜的模型。

我最后把它拆成了三个问题：

哪些钱根本不应该花；
必须花的钱，如何设定边界；
钱省下来以后，结果是否仍然值得使用。

第一步：先减少不应该发生的 AI 调用

成本优化最先要问的，不是“用哪个模型更便宜”，而是：

这一步真的需要 AI 吗？

很多工作并不需要模型。

例如：

去重可以用数据库和普通程序；
格式转换可以用 parser；
薪资、地点和硬条件比较可以用规则；
已知招聘网站可以直接通过 API 或固定页面结构获取；
简单排序可以先使用评分规则；
重复查询的公司和网页信息可以缓存；
固定格式的内容可以使用模板生成。

AI 更适合处理普通程序难以稳定完成的部分，例如：

判断一段经验与岗位要求是否真正相关；
综合多条证据形成结论；
处理模糊、冲突或缺失的信息；
根据具体上下文完成写作。

旧的思路可能是：

让 AI 搜索岗位、读取网页、去重、过滤、判断和排序。

新的顺序是：

普通程序先负责获取、解析、去重和硬条件筛选，只把剩下少量需要判断的内容交给 AI。

这不仅更便宜，也更稳定、更容易测试。

最便宜的调用，不是使用了更小的模型，而是这次调用根本没有必要发生。

第二步：减少每次调用读取的内容

调用次数减少以后，还要继续看每次调用到底读了什么。

我之前的一些流程会把完整的职位信息、用户职业经历、求职偏好和历史分析结果，重复发送给多个模型步骤。

但并不是每项任务都需要知道所有信息。

例如，一条 200 字符以内的 LinkedIn 消息，可能只需要：

岗位名称；
公司信息；
一两个最相关的经历；
希望建立联系的原因。

它不应该读取生成完整简历和岗位报告所需要的全部上下文。

后来我的处理方式是：

先整理一份可复用的证据包；
为每项任务选择真正需要的证据；
只发送相关片段，而不是完整历史；
对职位、公司和网页内容做缓存；
避免不同步骤重复搜索和重复读取相同信息。

这一步降低的不只是 Token，也减少了模型被无关信息干扰的可能。

第三步：为所有付费调用设置一个“收费站”

减少调用和输入以后，还需要一个统一的执行边界。

我把它理解成一个收费站。

以前，每个功能都可以直接调用模型：

岗位扫描走自己的调用，匹配分析走自己的调用，材料生成再走另一套调用。

这样的问题是：

每个功能可能使用不同的模型和参数；
有的地方可能忘记设置上限；
SDK 可能在背后自动重试；
新增功能可能绕过原有的成本记录；
很难控制一个用户或整个产品的总开销。

后来，所有付费调用都必须先经过同一个入口。

收费站会在调用发生之前检查：

这是什么功能；
使用哪个模型；
最多允许多少输入和输出；
是否允许搜索；
最多允许搜索几次；
是否允许 retry 或 continuation；
这一次最坏可能花多少钱；
用户和系统是否还有预算。

不符合规则，就不允许调用。

这和月底看账单完全不同。

月底报表只能告诉我钱已经花掉了。收费站解决的是：

这笔钱现在能不能花？

第四步：调用前先预留预算，而不是花完以后报警

为了让收费站真正有效，我还引入了预算预留。

系统不会根据一个乐观估计说：

这次大概只花 0.05 美元，先运行再说。

它会按照预先设置的最大输入、输出、工具和重试次数，计算最坏情况下可能产生的费用，并先预留这笔预算。

调用结束以后，再根据实际使用结算，多余的部分释放。

这个设计有点像酒店押金。

为什么不能只记录实际费用？

因为多个请求可能同时发生。

假设账户里还剩 1 美元，同时来了三个“预计花费 0.4 美元”的请求。如果不提前预留，它们可能都会认为预算充足，最后一起超过上限。

预留也能避免 timeout 后立即重复调用。

请求超时不代表模型服务一定没有处理。如果系统立刻释放预算并重新执行，可能会为同一个任务付两次钱。

所以，在无法确认 provider 是否已经接受请求时，预留金额会暂时保留，直到能够完成核对。

第五步：为每项能力设置不同的价格

不同 AI 功能不应该共享一个模糊的预算。

一条简短消息、一封求职信、一份完整简历和一次公司研究，复杂度与用户价值完全不同。

在我的初始方案里，不同能力有不同的单次费用上限，例如：

简短 LinkedIn 消息：0.03 美元；
求职信：0.12 美元；
定制简历：0.25 美元；
完整岗位匹配分析：0.40 美元。

同时还有：

单个用户每日总预算；
自动后台任务的独立低额度；
产品整体的月度预算；
模型供应商账户的外层限制。

这些数字不是行业标准，只是当前产品在当前模型价格下的初始边界。

重要的不是数字本身，而是：

每项能力都应该有一张和其价值、复杂度相匹配的价格标签。

第六步：收费站之外，还要有一本完整的账

收费站负责决定钱能不能花，账本负责记录钱花去了哪里。

以前只有一次逻辑任务的总 Token，很难回答：

实际向模型发送了几次请求；
每次输入和输出分别是多少；
是否发生了 cache read 或 cache write；
使用了几次搜索；
第二次请求是 retry、continuation，还是用户重新点击；
失败之前是否已经产生费用；
timeout 后的账单是否仍然不确定。

后来，每一次真实的 provider attempt 都单独记录。

即使最终没有生成产品结果，也要留下：

使用量；
工具调用；
失败阶段；
重试原因；
实际费用；
是否已经完成结算。

这让我第一次能够区分：

产品结果失败了，和付费调用没有发生，是两件完全不同的事。

收费站负责控制未来，账本负责解释过去。

缺少任何一个，成本管控都不完整。

第七步：成本下降以后，还要证明质量没有一起下降

最容易省钱的方法其实很多：

少给模型一些信息；
砍掉分析步骤；
缩短输出；
换更弱的模型；
不再搜索外部资料。

但如果结果因此变差，这并不算优化，只是把 API 成本转移成了产品质量损失。

所以，我还需要在固定样本上同时比较：

实际成本；
响应时间；
事实准确性；
内容完整度；
结论是否稳定；
用户是否仍然觉得有用；
最终需要人工修改多少。

这里必须区分三种状态：

已经测量：真实运行得到的成本、Token、延迟和失败记录；
工程预测：根据减少调用、缩小上下文和增加缓存推算的节省；
仍然未知：需要真实材料和付费测试才能确认的质量变化。

如果还没有完成对比测试，就不能把预计节省写成已经实现的结果。

最后

现在回头看，AI 成本控制可以浓缩成四句话：

能不用 AI 的地方，先不用 AI。必须调用时，只提供真正需要的内容。每笔付费都要先经过收费站，再进入账本。钱省下来以后，还要确认用户价值没有一起被省掉。

换一个便宜模型只是其中很小的一步。

真正的成本优化，是让每一次 AI 调用都有理由、有边界、有记录，也能够被评价。