降本增效方案

很多团队不是不关心成本，而是不知道从哪下手：账单一来吓一跳，问谁都说没多用；想省又怕降效果，最后只能砍需求。这篇按「先看清、再分流、后设闸」的顺序，给一份能照着做的方案清单，每一步都写清动作、判断标准和什么情况下不适用。

很多团队不是不关心成本，而是不知道从哪下手：账单一来吓一跳，问谁都说没多用；想省又怕降效果，最后只能砍需求。这篇按「先看清、再分流、后设闸」的顺序，给一份能照着做的方案清单，每一步都写清动作、判断标准，以及什么情况下这套动作根本不适用。

读之前先摆正一件事：降本增效不是一次性的运动，而是一套能放进日常节奏的固定动作。下面每一节都可以单独落地，但建议按顺序走，因为后一步的判断标准往往依赖前一步留下的数据。急着省钱的团队最常跳过的正是第一步，结果改完也不知道有没有效果。

先划清边界：省的是什么，别省错地方

把「降本增效」拆成两个独立目标会更清楚：一是降低单位任务的花费，二是提高同一预算下的产出量。前者靠换档、缩输入、控重试；后者靠减少返工、提高一次通过率。两者做法不同，混在一起谈，团队很容易只砍不增，最后活还是那么多，只是工具变差了。

动手之前，先把不能省的部分写下来贴在明处。判断标准是：这项开销一旦被压缩，会不会直接影响交付质量或带来合规风险。会，就别碰；不会，才进入后面的优化流程。

• 不能省：决定成单质量的核心推理环节，砍了返工成本反而更高
• 不能省：影响交付稳定性的冗余通道，省钱换来的失败重试通常更贵
• 不能省：合规、审计与日志留存，这类开销属于基础设施而不是优化对象
• 可以省：内部草稿、重复描述、批量分类等对最终交付不敏感的任务
• 可以省：实验性项目的额度，和线上业务隔离后单独设限

适用范围要提前说清：如果团队调用量很小，或者这项成本占整体支出比例很低，那这一轮的重点应该放在效果和稳定性上，而不是省钱。把人力花在优化上，本身就是一笔成本。

第一步：把当前花销摸成一张可比的底账

没有底账的优化基本靠猜。这一步的目标不是算得多精确，而是找出占比最高的两三个来源，别平均用力。多数团队看到的账单是总额加一堆明细，真正要做的是把它按「功能 × 模型档位 × 调用方」三个维度重新汇总一遍。

统一口径是这步的关键。按量、按次、订阅制混在一起看，很容易得出错误结论。先把不同计费方式折算成同一单位再比较，站内的 Token 价格换算器（/tools/token-price-calculator） 和 模型成本计算器（/tools/model-cost-calculator） 可以先帮你做换算，具体数字以页面当时显示为准。

不适用的情况也要讲明白：如果日志里连调用方或任务类型都缺失，那就先补字段再谈优化。否则改完之后你无法验证效果，只能凭感觉说「好像省了」，这种结论在复盘时没有价值。

给任务分级：哪些活根本不该用好模型

分级的核心问题只有一个：这个环节出错，会不会影响最终交付。会，就留在高档；不会，就往下试。多数团队的浪费不是出在对外的关键任务上，而是出在内部草稿、字段抽取、格式转换这类对结果不敏感的活上，却一直在用最贵的档位跑。

把任务分成三档之后，对中间档做小样本对照。方法是取一批真实输入固定下来，分别跑不同档位的模型，人工只看「是否影响最终交付」这一个指标，不要看主观感受。样本量不用大，但要覆盖真实的长尾情况。

1. 贴标签把现有调用按必须旗舰、够用即可、可有可无三档标一遍，标注依据写进底账的任务类型列
2. 做对照挑中间档选一批真实输入，固定同一份提示分别跑不同档位，记录是否影响交付
3. 找不适用项凡是错误会传导到下游链条、或返工成本明显高于差价的场景，直接排除出降级名单
4. 写成共用表把分级结果整理成一张对照表挂在团队共用位置，新人接入直接照表执行

降级不适用的情况要单独列出来：错误会在多环节传导的任务、人工复核比模型差价更贵的任务、以及监管或客户明确要求特定档位的任务。这三类不要为了省钱去动。

控制和上下文：先把不必要的输入砍掉

很多成本不是花在模型能力上，而是花在每次重复传递的冗余内容上。检查一下提示里有多少是每轮都要传的固定说明、历史记录和无关文档。能做成模板的固定说明不要每次重新塞，能截断的历史记录不要整段带上。

长文档类任务改动空间最大。与其把整篇材料送进去，不如先检索出相关片段再精读，这样既省输入也常常提升准确度。输出侧同样有空间：把长度、字段、是否允许解释这些约束写死，避免模型自由发挥带来的额外长度。

固定说明

能抽成模板的内容不要每轮重复传入，改一次全团队受益

历史记录

按轮数或长度截断，判断标准是删掉后回答是否还成立

长文档

改成先检索定位再精读，比整篇送入更省也更准

输出约束

明确长度与字段，减少自由发挥带来的额外消耗

路由与兜底：把请求送到最合适的地方

同一件事不必所有时候都走同一条路。按任务档位和实时负载做分流是常规做法：交互场景优先保证响应稳定，离线批处理可以走更宽松的路径。关键是把两类任务在入口处就分开，而不是等到账单出来才发现批处理占了高峰资源。

兜底策略同样影响花销。失败重试必须设上限并加退避，否则超时之后的反复重发会把预算悄悄烧掉，而且这部分消耗在账单上往往看不出来。选择通道时别只看价格，用 通道测速页（/tools/speed-test） 摸清各条路径的延迟，把等待时间和重试概率一起算进去。

• 交互类任务优先稳定，不为省钱切到慢通道
• 离线批处理可走宽松路径，排在低峰执行
• 重试设上限并加退避，避免超时反复重发
• 把延迟和重试概率一并计入，别只比单价
• 通道质量参考站内 中转站目录（/sites） 与 可信度排行（/rankings） 的当期结果

预算闸门：让跑飞停在一晚以内

闸门的作用不是省钱，是防止一次意外把整月预算吃掉。设三层阈值比较实用：日报预警用来发现异常，周预算警戒用来触发调整，月度硬上限用来兜底。真正重要的是触线之后的动作要事先写清楚——是自动降档、限速，还是直接暂停。

限流和闸门都建议按调用方设置，而不是按账号。这样团队里谁在跑什么一目了然，也不会出现一个人拉爆整体预算的情况。实验性项目单独开额度池，失败就失败，不牵连线上。

边界也要说清：闸门设太紧会打断正常业务，尤其是月末集中交付的团队。建议先观察一个完整周期再收紧，别一上来就卡到临界值。

团队节奏：把省钱变成例行动作

优化动作如果只做一次，很快就会回到原样。要让它在团队里留下来，得把检查和调整放进固定节奏。频率不用高，关键是每次都只关注少数几个信号：用量异常涨跌、新增调用方。其他细节不用逐条看。

账单与充值也要定期对一次口径。很多时候感觉「省了」，其实是记账方式变了或者充值周期错位。对齐口径之后再谈优化成果，否则复盘结论不可信。

• 每周花十几分钟看用量变化，只盯异常涨跌和新增调用方两类信号
• 每月核对一次账单与充值口径，先对齐再谈优化成果
• 每个模块的档位和提示模板都指定负责人，谁改谁回归验证
• 改动记录写在同一处，避免同一个人反复问同一件事
• 新成员接入时直接对照分级表，不用逐个讨论

常见反例是发一份通知让大家「省着点用」，没有具体动作也没有责任人。这种做法通常一周内就回到原样，因为没人知道该改什么。把动作归属到人，是这套节奏里最容易被省略、也最不能省的一步。

什么情况下先别优化

上面整套方案并不是任何时候都该做。判断标准其实很简单：预计省下的钱，是否明显高于投入的人力时间。算不清就先不做，把精力放在产品验证上。强行优化反而会拖慢主线。

• 产品还在验证阶段、调用量小且方向未定，优化的时间成本高于省下的钱
• 成本主要来自一次性投入，比如数据准备与评测，压缩推理开销对总账影响很小
• 团队还没有可用的用量记录，先补观测再动手，避免改完无法复盘
• 关键交付期临近，此时调整档位和模板会引入不确定性，建议放到之后

换句话说，优化本身也是一项投入，要按投入产出来判断优先级。等用量上来了、方向定了、底账也有了，这套流程的回报会明显得多。

先看清花在哪里，再判断哪些能换档，最后用闸门兜住意外——顺序错了，省下的往往只是感觉。