场景设计五步通法
场景题考的不是会做多少菜，是会不会点菜。五步：澄清需求（四类问题、只花两分钟）、给基线（最土的方案能到什么水平）、加挂并说代价、谈评测（三条线，只在掉分时下沉）、谈演进（给触发信号不给时间表）。四张随身表把决策树、评测线、成本三刀、四道闸随身带着。
也叫：场景设计 · 五步答题结构 · 五步通法 · 系统设计题 · 四张随身表 · 综合设计
原理拆解出自 T8-1
第 ① 步 澄清需求：问四类问题，但只花两分钟
不要变成盘问。问四个问题就够，并且每个问题都要带上「你为什么问」，否则听起来像在拖延：
| 问什么 | 为什么问（一定要说出来） |
|---|---|
| 数据规模与更新频率 | 决定索引式还是检索式、要不要增量更新 |
| 答错的代价 | 决定「不知道就说不知道」的阈值和人工兜底的强度 |
| 数据出不出网、要不要权限隔离 | 决定能不能用公有云 API、隔离做在哪一层 |
| 现在有没有人在做、怎么做的 | 这条最值钱——现状就是你的基线 |
如果面试官说「你自己假设」，那就明确说出你的假设并继续，不要卡住。合格的表述是：「我按 10 万文档、日活 2000、答错只是效率损失不涉及资金来做，如果实际是金融场景我后面会改两处。」
第 ② 步 给基线：先说最土的方案能到什么水平
这一步是整道题的地基，也是最多人跳过的。基线的作用有三个：给增量一个参照物、给成本一个下限、给自己一个「什么时候可以停」的判据。
不同类型场景的典型基线：
文档问答类 → 切块 + 向量检索 + BM25 混合 + 重排 + 「找不到就说找不到」 任务执行类 → 写死的 workflow（if/else + 三五个工具），不上 Agent 数据查询类 → 预置 20 条常用查询模板 + 参数填充，不上 NL2SQL 生成类 → 一个好 prompt + 三个 few-shot，不微调
说基线时必须给一个数量级的预期，哪怕是估的：「这套东西在这类场景一般能到七成上下的可用率，剩下三成集中在表格、多跳和口语化查询。」有没有这句话，是「读过」和「做过」的分界。
第 ③ 步 加挂并说代价：本项目的三段式铁律
每加一样东西，必须同时说三件事——解决什么、代价是什么、什么时候不该用。这一条是项目的内容铁律，也是场景题里区分度最高的地方，因为它无法背诵，只能来自真实取舍。
选什么加挂，用三问决策树（骨架 A）：
模型不知道这件事 → 挂 RAG（知识注入） 模型知道但不会按要求做 → 先提 effort 档位 + 改 prompt → 还不行才 SFT → 有可验证奖励再 RLVR 能做但太贵 / 太慢 → 蒸馏、路由、缓存
注意第二支的顺序：答得浅的第一动作是提档位，不是加提示词。这是本项目的冻结口径之一，2026 年仍然是高频分水岭。
第 ④ 步 谈评测：三条线 + 只在掉分时下沉
三条线（骨架 C）互相佐证、不互相替代：
- 离线评测集——决定「能不能发」；
- 线上采样——决定「发完有没有变坏」；
- 业务指标——终审，但滞后。
层级下沉顺序（骨架 E）：先端到端，端到端掉分了才看轨迹级，轨迹级定位不了才拆到组件级。上来就做组件级评测是最常见的浪费——你会得到一堆很漂亮但和最终效果无关的分数。
再补两条本项目的冻结口径：零成本信号优先于 judge（转人工率、重问率、截断率、复制率最被低估）；分数变化必须过统计关（n=100、基线 80% 时 95% 置信区间大约 ±7.8 个百分点，涨了 3 个点什么都说明不了）。
第 ⑤ 步 谈演进：给触发信号，不给时间表
弱回答是「一期做 RAG，二期做 Agent，三期做微调」——这是排期不是演进。强回答是给出升级的触发信号：
出现「一个问题要跨三四篇文档才能答」→ 才考虑图结构 出现「查询需要多轮试探才能定位」 → 才考虑 Agentic 检索 出现「同一类需求每天几万次且稳定」 → 才考虑蒸馏小模型 出现「人工兜底率长期高于 X%」 → 才考虑扩流程而不是扩模型
同时要说反向条件：什么情况下这套要退回去。会说退路的人，比只会说前进的人可信得多。
以上节选自T8-1 场景设计题的五步通法与四张随身表，读全文能看到前后语境。