降本增效方案措施

团队用 AI 的钱越花越多，但让你说清楚「哪一笔该砍、砍了会不会出事」，多数人答不上来。降本增效不是把单价压到最低，而是在不牺牲交付的前提下，把浪费的部分找出来。这篇给一套分层排查清单：从用量、模型选择、流程习惯到采购与组织分工，每层告诉你先看什么、动什么、什么情况下别动。

团队用 AI 的钱越花越多，但让你说清楚「哪一笔该砍、砍了会不会出事」，多数人答不上来。降本增效不是把单价压到最低，而是在不牺牲交付的前提下，把浪费的部分找出来。真正花钱的地方往往不是单价，而是重复调用、选错模型、流程漏点和采购方式。

这篇给一套分层排查清单：从用量、模型选择、流程习惯到采购与组织分工，每层告诉你先看什么、动什么、什么情况下别动。你可以直接从自己最不确定的那一层开始，但跳过第一层直接砍单价，基本等于蒙。

先量再砍：没有基线就没有降本

动手前先拿到三个数：月度总花费、按项目的花费分布、单位产出成本（比如一次客服会话、一篇文案）。没有这三个数，任何「省钱」判断都是拍脑袋。这三样凑不齐，就先别谈优化模型和换供应商，因为改完你也不知道是变好了还是变差了。

• 用量日志至少要能按调用方、模型、任务类型拆开；字段缺哪个就补哪个，补完再谈优化
• 拿你自己业务的延迟基线，在站内 /tools/speed-test 跑一遍，别用别人的跑分当自己的标准
• 单位产出成本要选一个你天天在看的指标，不要用「调用次数」这种跟业务不挂钩的数
• 把每次调整前后的同一指标记在同一张表里，否则第二次调整就得从头再来

用量层：把重复和冗余的调用挑出来

排查顺序建议：重复请求、超长输入、无效重试、闲聊式调用。前两项通常占浪费的大头，改起来也最快。不要一上来就研究怎么把单价压下去，先把明显重复的部分砍掉，效果比换模型直接得多。

1. 抓重复请求按「同一输入指纹 + 短时间内多次调用」筛一遍，看有没有相同任务被反复触发；能合并的合并，能缓存的缓存。
2. 截超长输入同一份长文档被整篇反复传入，是典型浪费。先做一次摘要或抽取，后续任务基于中间结果，而不是每次把原文重塞。
3. 收紧重试重试要有上限和退避。接口被限速后无脑重发既烧钱又拿不到结果，把重试次数、超时、失败兜底写进调用封装，别散在各处。
4. 验证改完再看一遍这几个数，确认调用量确实降下来了，而不是被挪到别的地方去了。

判断标准：如果某类任务的成本波动明显高于其他任务，先怀疑调用量本身，而不是单价。至于具体的单价和倍率数字，会随渠道和时间变，一律到站内 /price-watch 核对当时的数值，不要凭记忆写进内部文档。

模型层：分层用模型，而不是一刀切

按任务难度分档：格式转换、分类、抽取这类确定性高的活交给轻量档；只有需要推理和长链路的任务才上高档模型。分层的目的不是永远用最便宜的，而是让每一类任务只付它需要的成本。

对比方法用任务级而不是单价级：同一个任务在两个候选模型上各跑一批，比总花费和返工率。换算口径时，把倍率、赠送额度、缓存计价这些差异抹平，否则比出来的结论是错的。站内 /tools/model-cost-calculator 和 /tools/token-price-calculator 可以用来做这层换算，具体价格和档位到 /models 看当期数字。

换模型省下的钱，如果被返工和人工校验吃回去，那就是白折腾。

流程与采购：钱花在流程漏点上最冤

给每个项目和环境设预算告警与硬上限，思路是分层设闸，先把「跑飞一整晚」这类事故堵住。订阅与按量混用时，先算清楚哪些人适合用订阅、哪些任务必须走 API，避免出现订阅闲置、API 爆量的双付情况。订阅档位对照看 /plans 和 /coding-plans。

• 预算告警按项目、按环境分别设，一人一个总额度等于没设
• 每月固定做一次账单与充值记录核对，用流程而不是想起来才查
• 采购前把候选集中在中转站目录 /sites 和厂商目录里横向比一遍
• 核对时注意区分官方直连和转售渠道的额度折算差异，口径不一样就没法比
• 把每次采购决策和当时的对比依据记一行，下次续费不用从头查

站内已经有预算告警和账单核对的现成做法，可以直接套用，不用自己从零设计。真正要自己判断的只有一件事：这条措施省下的钱，够不够覆盖你花在管理它上面的时间。

别把钱省在错的地方：降本与增效的边界

降本是砍支出，增效是提高单位投入的产出。把研发时间、等待时间、返工成本算进来，很多「便宜方案」其实更贵。给每条措施标上四件事：省多少、影响谁、多久见效、什么条件下回退。没有回退路径的措施不要上线。

不建议动的部分：直接影响交付质量的关键链路、合规与安全相关的支出、以及你自己还没有稳定观测手段的环节。这三类先放着，等观测补上了再谈优化。量化的部分不要凭记忆，单价、额度、档位这类数字会变，一律到站内对应页面看当期数值。