准备应用开发面试时，可以构造一条保修问答的请求轨迹，包含产品信息、查询条件、候选政策片段、最终上下文与输出解析结果。使用相同输入分别排查版本错误、证据遗漏和内容误读，再说明各自修复方式。这样的演练把技术栈放进了可解释的调用过程，也能避免只背架构图。
先给问题设边界
拿一个具体用户任务，写下输入、期望输出、不可接受的错误和允许的等待时间，再解释为何需要模型参与。比如合同问答的核心是回答有出处，而营销文案可能更重视风格一致。没有任务边界，模型大小、框架名称和召回参数都缺少评价坐标。回答时应把业务指标转为可观测事件，避免用听起来专业的配置替代需求。
沿证据拆解追问
为模拟题准备一条完整请求轨迹，依次展示检索结果、提示内容、模型输出和后处理决定，解释失败发生在哪一层。答案错误不必然需要换模型，可能是旧版文档被索引、权限过滤遗漏或输出解析失败。每提出一种修复，都说明需要什么对照样本才能证伪自己的判断，让面试官看到可复现的调查路径。
主题概念图
承认取舍比宣称万能更有力
给每个方案补充适用条件和撤回条件，例如先优化切块与排序，若证据已经充分但格式仍不稳定，再评估微调。这样的顺序并非任何项目的固定答案；当延迟、预算或数据授权条件改变，方案也应改变。原创模拟题考察的是约束下的决策过程，不代表任何企业实际题库，更不能用虚构上线收益包装经验。
把"回答错了"拆成能定位的现象
面对"保修期答错"的追问，先确认用户问的是购买时规则还是当前规则，设备属于哪个型号，是否存在地区差异。若这些条件没有确定，错误可能从问题理解就开始了。接着查看请求实际使用的文档版本：界面上展示新版文件，不代表后台索引已更新；检索结果标题相符，也不代表正文覆盖该型号。面试中把输入条件讲细，能说明你没有拿一个含糊需求直接套方案。
再沿调用过程寻找最早出现偏差的位置。正确条款没有进入候选集合，应研究解析和召回；候选集合有条款但最终上下文没有，应检查排序与长度裁剪；上下文明确写着两年，答案却说三年，才集中调查生成和后处理。这里的顺序是一种缩小范围的方法，不保证所有系统都按同样步骤实现。关键是把"看到的现象"和"推断的原因"分开，避免先宣布根因，再挑日志证明自己。
叙述时可先给出最小事实，例如"候选中缺少A型条款"，再说假设是版本过滤不当。若随后发现原文也没覆盖该型号，就撤回假设，转为说明信息不足；这种调整能体现调查而非背答案。
修复建议要能回答追问中的反例
假如你建议"过滤旧文档"，面试官继续问："用户是在查询去年买的设备呢？"这时就需要区分资料更新时间、政策生效区间和用户事件时间。旧文件可能仍是历史问题的正确依据，直接删除会修好新问题却破坏旧问题。更完整的回答应说明查询的适用时间怎样确定，缺少购买日期时怎样追问，以及冲突政策怎样交给人工核对。
比较方案时，也要说清它们分别牺牲什么。增加重排步骤可能提高关键条款进入上下文的机会，却增加等待；扩大候选集合可能找回遗漏，也可能引入相似型号噪声。可以提出一个小型对照：固定同一批型号与日期组合，只改一个环节，同时检查错误类型是否减少。数字尚未测得就不填写。"我会如何验证"与"我已经验证得到什么"分开表达，反而能让模拟题保持可信，也为后续追问留下清楚的调查路线。
还可以补一个负面对照：不受政策变化影响的旧型号题应该维持原结果。如果修复使新政策题正确，却让旧题普遍失效，就说明范围处理仍有问题，需要重新检查变更边界与历史查询需求。
案例
假设一家设备售后平台要回答保修问题。用户说"去年买的A型设备还能免费维修吗"，资料库同时存有今年新版政策和去年旧版政策。模拟回答先指出缺少购买日期与故障类型，不能直接给出结论；随后检查两版政策的生效范围，再说明为何按事件时间选择条款。如果条款检索到了却被上下文裁剪，就讨论排序；如果源文件日期识别错误，就检查入库。练习的目标是讲清推断如何随证据变化，不给这个虚构平台补写上线收益或真实面试评价。若面试追问修复收益，练习者只描述准备比较哪些样本，不为虚构平台填写命中率或满意度数字。
准备一份分层故障题卡
给同一个保修问题分别设置三种输入：源文件没有例外条款、条款在候选中但未进入上下文、上下文正确但答案遗漏条件。每种题卡记录应该查看的字段与可能修复点，避免三个问题都回答"调提示词"。版本标识、查询条件、候选片段ID和最终上下文应能够互相对应；若某一环没有记录，就先补观察信息，再对模型能力下结论。题卡中同时保存问题日期，避免历史查询被误当当前政策。
实践步骤
- 从熟悉的应用挑一个失败请求，保存预期行为、实际输出和原始输入，明确用户真正需要完成的事情。
- 按数据、检索、生成、后处理列出排查证据，为每个修复建议写一个能够推翻它的对照样本。
- 整理目标、定位、取舍与验证的一页回答卡，逐条删除无法核查的数字，并用连续追问检查前后逻辑。
常见问题
- 把所有回答都收束到换更强模型，忽略上游数据错误。
- 把模拟项目说成真实上线经历，导致无法提供可核查细节。
练习
选一个你真正理解的应用，整理一页回答卡：用户目标、失败样本、定位证据、备选方案和验证方式各写一句。再用追问检查每个结论是否有依据，删除无法解释的夸大数字。练习时保留不确定性，能清楚说明下一步如何查证，通常比背出更多缩写更能体现工程能力。