你的方案预算砍一半，先砍什么？
谁在问：三面 / 技术负责人 / 业务负责人；通常紧跟在一道场景设计题之后，作为压力追问出现
口语化问法
- 你刚才这套方案，预算只给一半，你砍什么？
- 老板说这个项目太贵了，要降一半成本，你怎么办？
- 如果只能留一样，你留哪个？
考察意图
这道题几乎总是紧跟在场景设计题之后出现，它考的不是省钱技巧，是三件事：
- 你知不知道自己的钱花在哪。答不出成本结构的人，砍起来只能凭感觉。
- 你有没有给每个组件估过边际收益。一个方案里通常有一两样贡献了大部分效果，其余是锦上添花；能不能指出来，是「设计过」和「堆过」的分界。
- 你敢不敢砍功能。技术人本能地想在技术里找省法，而很多时候最大的一刀是「这个功能本来就没人用」。
还有一层隐含考察：你会不会问清「砍的是什么钱」。多数人默认是推理费用，但预算里往往还有人力、基础设施和时间。
参考答案
60 分答案（及格线）
先看成本主要花在哪儿。一般是模型调用最贵，可以换更便宜的模型、加缓存、把不需要复杂推理的请求路由到小模型。检索侧可以降低召回数和重排数量。如果还不够，就砍掉一些非核心功能，比如多轮追问、复杂的图检索这些。
思路没错，及格。但它是从「有哪些省法」出发的，不是从「我的钱花在哪」出发的——顺序反了。而且「换更便宜的模型」放在第一位，是最常见的错误起手。
90 分答案（有生产经验的回答）
① 先澄清：砍的是哪一笔钱。 推理费用、人力投入、基础设施、还是交付时间？如果砍的是人力和时间，答案完全不同——那时候第一刀应该砍范围，而不是砍单价。假设砍的是推理费用。
② 回到基线：先量化每个组件的边际收益。 我不会直接开始砍，第一步是把方案拆成组件，各自回答两个问题：它花了多少钱、去掉它掉多少分。这一步靠消融实验——把每个加挂逐个关掉跑一遍评测集。经验上结果几乎总是同一个形状：一两样贡献了大部分效果，剩下的一堆各自贡献很小但成本不低。没做过这一步的人，砍的时候只能砍自己最不心疼的，而不是收益最低的。
③ 归因用成本三刀，然后按降本九步的顺序砍。
第一刀 切输入侧 / 输出侧 输出比输入贵 5–6 倍，且思考 token 计在输出侧 第二刀 切各侧内部 输入侧看缓存命中与重复注入；输出侧看轮次、档位、有没有话痨 第三刀 才是单价 且只有降两档才有意义顺序的逻辑是从「不影响正确性」走到「影响正确性」：
1 精确缓存 2 前缀缓存 3 批处理 4 削工具结果 5 降 effort 档位 6 修检索命中率 7 模型路由 8 语义缓存 9 减功能前四步基本不动效果；第五步开始有代价；后面越来越贵。我会把 1–4 全做完再考虑第 5 步。
④ 每一刀的代价我都要说清：
- 前缀缓存是性价比最高的一刀，但要注意什么会打穿它：静态前缀里放时间戳、工具顺序不确定、中途换模型或改 effort 档位。很多团队以为自己有缓存，实际命中率个位数。
- 批处理在离线场景是白捡的——价格通常是标准价的一半，代价只是延迟。先看有没有任务其实不需要实时。
- 削工具结果常被低估：工具返回的内容默认是上下文的永久居民，成本按剩余轮次复利。截断和摘要工具结果，往往比换模型省得多。
- 降 effort 档位要小心：它降的不只是思考长度，还会减少工具调用次数，可能导致一次做不对、返工反而更贵。要按任务类型分档降，不要全局降。
- 语义缓存排在第八不是因为它省得少，而是因为它的正确性责任完全转移到你——阈值买的是命中率不是准确率，误命中是结构性的。省钱和答错之间，这一刀的风险最高。
- 减功能排最后，但它经常是最正确的一刀。先看使用数据：哪些功能的使用率低到可以直接下线。砍一个没人用的功能，是唯一一刀零代价的省法。
⑤ 怎么验证砍对了、什么时候加回来：砍完必须跑同一套评测集并过统计关——n=100、基线 80% 时 95% 置信区间约 ±7.8 个百分点，掉三个点说明不了问题，掉十个点就要回退。线上盯零成本信号：转人工率、重问率、拒答率。加回来的触发条件要事先写好——比如「转人工率连续两周高于某值」就恢复某个组件。
还有一个 2026 年的新陷阱要说：有的新模型换了 tokenizer，同样文本的 token 数会明显变多。单价降三成、token 涨三成，账单没降——比价必须比「每次请求的实际花费」，不能比单价。
追问链
你第一步先算什么？
期望先切输入侧 / 输出侧，不比单价 —— 两侧差 5–6 倍且思考 token 计在输出侧，结构不同省法不同。输入侧偏高 → 查缓存命中、整块内容反复注入、工具结果赖在上下文；输出侧偏高 → 查轮次失控、effort档位被调高、大段没人看的解释。加分：按请求类型分桶，总账掩盖结构信号先说「看单价对比」→ 没做过归因；先说「切输入输出」并说得出为什么 → 用的是标准结构降 effort 档位到底省不省？
期望省，但分档降不能全局降：①effort管的是全部输出 token，含工具调用次数，低档倾向合并操作、少发调用；② 降档拉低一次做对的概率，返工以更贵的方式回来，多轮 agent 尤甚；③ 判据清晰的降档，需多步推理试探的不降。会话内切effort会击穿提示缓存，开场定死信号说得出「effort影响工具调用次数」和「中途改会击穿缓存」→ 读过官方口径；只说「少想一会儿」→ 理解得浅语义缓存能省很多钱，为什么排在第八？
期望九步里唯一改变正确性责任归属的一刀：精确/前缀缓存零风险，命中同一段内容；语义缓存靠相似度判「两个问题算不算一个」，判断从供应商转到你。阈值调高只降命中率不提准确率，误命中是结构性的。只用于容忍度高的场景，不碰个性化、时效、权限、金额；权限场景缓存键须含身份，否则就是越权通道信号说得出「正确性责任转移到你」→ 口径准确；只说「可能会答错」→ 没抓住责任归属这层砍功能怎么砍？总不能随便下线。
期望三条判据：① 使用率 —— 低使用率是第一候选，唯一零代价的一刀；② 边际收益 —— 消融看去掉它掉多少分，掉不到统计显著就该砍；③ 代价不对称 —— 涉及钱、权限、安全兜底的不砍，哪怕使用率低，它们的价值在「没发生的事」。路径渐进：灰度关 → 看指标 → 全量下线，留恢复开关信号提出「安全兜底类即使低使用率也不能砍」→ 理解了代价不对称；只按使用率排序 → 会砍掉护栏砍完效果掉了，业务方要求恢复但不给预算，怎么办？
期望① 确认「掉了」是真的：评测集加线上信号过统计关再下结论，也可能是流量或上游变了 → ② 按九步逆序逐刀回滚定位，通常在第 5 步之后，前四刀不影响效果 → ③ 同预算内置换而不是要钱：加回这一刀，同时下线低使用率功能、非实时转批处理、某类请求走小模型 → ④ 置换不出来就把「恢复成本」与「不恢复的代价」摆同表让业务方选 → ⑤ 影响真的小就诚实说不该恢复信号提「同预算内置换」和「先验证掉了是不是真的」→ 真管过项目；只会「不加预算效果就保证不了」→ 缺协作能力
评分要点
- 先澄清砍的是哪一笔钱（推理 / 人力 / 基础设施 / 时间）
- 砍之前先做消融，量化每个组件的边际收益
- 归因走成本三刀，先切输入输出结构，不先比单价
- 按降本九步的顺序砍，逻辑是从不影响正确性到影响正确性
- 说得清前缀缓存被打穿的常见原因
- 知道削工具结果的复利效应（工具结果是上下文永久居民）
- 知道降 effort 会减少工具调用次数，且中途改会击穿缓存
- 知道语义缓存的正确性责任转移，所以排在后面
- 敢砍功能，且对安全兜底类功能给出例外判据
- 砍完要过统计关验证，并事先写好加回来的触发条件
- 知道 tokenizer 变化会吃掉降价，比价要比每次请求实际花费