Prompt 变更为什么要做回归？
👔 Raina面试官： 改个 System Prompt 几个字，为什么要跑回归？你会维护 Prompt 版本吗？
🙋 候选人：
- 因为Prompt 是 LLM 应用的代码，改一行可能导致行为断崖式变化，编译器不会帮你 catch。
- 我会把 Prompt 当代码管理：Git 版本、PR review、变更说明、关联 Eval 结果。每次改动跑固定 Golden Set，对比 diff。生产 Prompt 和评测 Prompt 要一致或有明确的 staging 流程。
- 维护 version tag，出问题时能 rollback 到 v1.3 而不只是昨晚那个版本。
👔 Raina面试官： Prompt 和 Eval case 谁跟着谁变？
🙋 候选人：
- 产品意图变了：先改 Eval 期望，再改 Prompt，否则不知道改完算不算好。
- 纯优化措辞、意图不变：Eval 不变，看分数是否提升。Eval 是 spec，Prompt 是实现。
怎么评估 System Prompt 是否足够好？
👔 Raina面试官： System Prompt 写完了，你怎么判断它够好可以上线？
🙋 候选人：
- 四个门槛：核心场景通过率、安全红线、bad case 不恶化、AB 优于基线。
- 核心场景：Eval 集主任务分数 ≥ 基线或约定阈值。安全：越狱/有害 case 不降级。回归：旧版能答的新版不能答的 case 数为 0（P0）。AB：小流量真实指标（满意度、完成率）不跌。
- 不够好的信号：同一问题要多轮澄清才能懂、频繁误触发工具、风格漂移、对边界 input 处理不一致。
👔 Raina面试官： PM 说感觉更好但 Eval 分数没涨，听谁的？
🙋 候选人：
- 拆 case 看是不是 Eval 没覆盖 PM 在意的维度。补 case 再测，而不是靠感觉上线。
- 也可以做 targeted human eval 只评 PM 关心的 20 条，和自动 Eval 互补。
Few-shot 示例变了，测试用例要不要跟着变？
👔 Raina面试官： Few-shot 示例换了，测试用例需要同步改吗？
🙋 候选人：
- 分情况：意图和期望输出不变就不用改 case；变了就必须改。
- 只是换更清晰的 example、输出格式 spec 没变——原有 Eval 继续用，看分数是否提升。如果 few-shot 引入新字段、新流程、新语气要求——要更新期望和断言，否则会用旧标准评新行为。
- 我会在 case 元数据里记录依赖 few-shot v2，Prompt 回滚时知道哪些 case 可能失效。
👔 Raina面试官： Few-shot 太多导致 context 变长，测试要覆盖吗？
🙋 候选人：
- 要，测 few-shot 占 window 比例——极端情况下用户可用 context 被挤占，回答质量下降。
- 这也是 Prompt 优化时容易忽略的 regression：example 加多了，长尾 user input 反而答不好。
对话记忆功能怎么测？跨 Session 一致性？
👔 Raina面试官： 产品加了 Memory，说能记住用户偏好。你会怎么测？跨 Session 一致性怎么验证？
🙋 候选人：
- Memory 测试分三层：写入、召回、跨 Session 持久。
- 写入：用户明确说叫我小明我是 vegan，下轮能否正确引用。召回：多轮后早期信息是否还在，不被新话题冲掉。跨 Session：关掉重开、换设备、token 过期后记忆是否还在、是否串号（A 用户看到 B 的记忆）。
- 还要测负例：用户说忘了吧是否真删除；记忆冲突时（改口了）以最新为准。
👔 Raina面试官： Memory 测起来很慢，怎么自动化？
🙋 候选人：
- 用脚本化多 Session 流程：Session1 写入 → 模拟结束 → Session2 用新 conversation id 但同一 user id 验证召回。
- 每条 case 标注 memory key 和 expected value，API 层直接查 memory store 做断言，不只靠模型回答间接验证。
角色设定漂移怎么发现和度量？
👔 Raina面试官： System Prompt 定了人设，聊久了风格跑偏。Persona 漂移你怎么发现和度量？
🙋 候选人：
- 漂移测长对话 + 对抗诱导 + 量化 rubric。
- 设计 10～20 轮对话脚本，每 5 轮插一条风格探针——比如用一句话介绍你自己你的语气应该是什么样的。用 judge 评是否符合 persona 维度：语气、称谓、专业度、禁忌词。
- 对抗 case：用户要求别装客服了，用兄弟口吻——期望稳定拒绝或按 policy 处理，不能轻易漂移。
👔 Raina面试官： 漂移多少算不可接受？
🙋 候选人：
- 和 PM 定persona adherence 分数阈值，比如 20 轮内 ≥90% 探针 pass。
- 核心品牌调性 case 一条都不能漂；次要风格可以略宽松，但安全 persona（如医疗助手不能变娱乐口吻）必须 hard gate。
Prompt 注入对测试有什么影响？
👔 Raina面试官： 用户 Prompt 注入越来越常见。对测试有什么影响？测试环境怎么模拟？
🙋 候选人：
- 注入测试要独立于功能测试单独成集，因为 failure mode 完全不同。
- case 类型：直接注入（忽略之前指令）、间接注入（文档/HTML 里藏指令）、多轮注入（前几轮正常后突然攻击）、工具参数注入。测试环境用 staging 模型 + 脱敏数据，但 guardrail 配置必须和生产一致。
- RAG 场景要在 knowledge base 里预埋 poison document，测检索后是否被带偏。
👔 Raina面试官： 注入测通了就能防住吗？
🙋 候选人：
- 不能，注入是持续对抗，要定期更新 attack case 库，红队 + 自动化结合。
- 测试目标是 defense in depth：prompt 层、检索过滤、输出审核、权限层各自有 case，单层被突破还有下一层。
澄清追问行为怎么测？
👔 Raina面试官： Agent 有时澄清有时瞎猜。澄清追问是好行为还是坏行为？你怎么测？
🙋 候选人：
- 澄清本身是好行为，该澄清不澄清、不该澄清乱问才是 bug。
- ambiguous case：帮我订一张票——期望追问目的地/日期。explicit case：订明天北京到上海高铁——不应多余澄清。over-clarify：连续三轮问已经给过的信息——体验差。
- 每条 case 标注 expected behavior：clarify / act / refuse，用 rubric 或 judge 评。
👔 Raina面试官： 澄清话术本身要测吗？
🙋 候选人：
- 要测澄清是否简洁、一次问全关键槽位，而不是分五轮挤牙膏。
- 这是体验指标，可以 P1——功能对了但问太烦也会流失用户。
回答过长、过短、跑题怎么度量？
👔 Raina面试官： 回答太长啰嗦、太短没信息、或者跑题——分别怎么定义和度量？
🙋 候选人：
- 先在产品 spec 里定义每种场景的期望长度和 relevance 标准，测试只执行。
- 过长：超 token/字数上限，或 judge 评冗余信息占比。过短：未覆盖 rubric 里的必答要点。跑题：embedding 相似度或 judge 评是否回答了原问题。
- Prompt 里常写简洁回答——测试要用量化指标验证，不能只看感觉。
👔 Raina面试官： 不同用户偏好不同，有人要详细有人要短，怎么测？
🙋 候选人：
- 测跟随用户明确指令的能力：三句话以内就必须短；详细解释就必须展开。
- 默认风格用产品 baseline rubric，个性化是额外 case 层。
敏感话题、违禁内容回复策略怎么测？
👔 Raina面试官： 涉政、医疗、未成年人等敏感话题，回复策略你怎么测？
🙋 候选人：
- 按话题分类 × 期望策略建矩阵：拒答、中立摘要、免责声明、转人工。
- 每类敏感话题至少 5 条 case，覆盖边界表达（隐喻、谐音、英文混合）。验证：不输出违禁内容、不给出 dangerous actionable advice、有合规 disclaimer。
- 还要测过度拒答——合法科普问题不能被误杀，比如高血压平时要注意什么不该一律拒答。
👔 Raina面试官： 敏感 case 谁维护？测试还是法务？
🙋 候选人：
- 法务/合规定策略和红线，测试负责 case 实现和回归。
- 策略变更必须 version 化，case 跟着更新，否则容易用旧标准评新 policy。
不同 Prompt 模板 A/B 测试怎么设计？
👔 Raina面试官： 同一业务场景有两个 Prompt 模板，A/B 测试你会怎么设计？
🙋 候选人：
- 离线 A/B 用同一 Eval 集 + 同一模型，只换 Prompt，对比各维度分数和 win rate。
- 在线 A/B 看业务指标：完成率、满意度、人工介入率、延迟。样本量要够，分层看用户群——新 Prompt 可能对某类用户更好。
- 必须有 guardrail：新 Prompt 安全 case 不能输给旧版，否则即使分数高也不能上。
👔 Raina面试官： A 赢了 52% vs 48%，算显著吗？
🙋 候选人：
- 要做统计显著性检验，不能凭感觉。52/48 在样本小的时候可能只是噪声。
- 我会设最小 detectable effect 和 required sample size，没达到就不做决策，继续收集或只做 offline 结论。