很多大模型应用项目在面试里会被一句话拆穿：“你只是调了一个模型接口吗？” 如果候选人只能回答提示词和模型名，项目很难显得深入。真正能拉开差距的，是上下文工程：给模型什么信息、不给什么信息、按什么顺序给、历史对话如何压缩、资料冲突如何处理。
同样的模型，在不同上下文下回答质量可能差很多。模型不是凭空理解业务，它依赖你提供的任务说明、用户问题、历史状态、检索资料、工具结果和输出约束。把这些输入组织好，比单纯换一个更大的模型更能体现工程能力。
先决定模型必须知道什么
很多人以为回答不好就多塞资料，结果反而更差。上下文太长会带来三个问题：成本上升、延迟上升、无关信息干扰模型。更糟的是，关键证据可能被埋在一堆材料中，模型抓不到重点。
一个更稳的上下文包通常包括五类信息：当前任务、用户问题、必要业务规则、少量高相关资料、历史状态摘要。注意这里是状态摘要，不是完整聊天记录。比如用户正在准备 Java 后端二面，系统应该告诉模型“目标是二面追问”“用户已掌握基础概念”“这次要补系统设计表达”，而不是把所有历史对话都塞进去。
资料排序会影响答案走向
如果项目里用了检索增强，不能只说“召回 topK”。面试官会继续问：topK 里的资料怎么排序？资料互相冲突怎么办？模型是否必须引用资料？
我会把资料按相关性、权威性、时效性排序；如果资料冲突，优先使用权威版本或更新版本；如果没有足够证据，就让模型说明无法确定，而不是编造。对于重要回答，可以要求模型给出依据片段，方便用户和系统检查。
这里的关键不是让模型“看起来有依据”，而是让系统能复盘。如果答案错了，要能知道是召回资料错、排序错、提示词约束不够，还是模型没有遵守证据。
提示词要能被回归测试
提示词不是玄学文案，而是系统约束。它应该明确角色、任务、可用资料、不能做的事、输出格式和不确定时的处理方式。每次修改提示词，都应该用坏例集回归，而不是凭感觉看一两个回答。
比如简历诊断场景，不应该只写“请给出专业建议”，而要明确：不要编造经历，不要承诺录取概率，指出风险时给出可修改版本，遇到信息不足时先追问。这样的约束越具体，越容易测试，也越容易让不同版本的模型保持一致表现。
面试里可以这样收束
大模型应用的质量，不只取决于模型参数。我的关注点会放在上下文选择、资料排序、历史压缩、提示词约束和坏例回归上。同时还要观察成本和延迟，因为上下文越长，用户等待和调用费用都会增加。
还有一个容易被忽略的细节：上下文工程要和产品状态打通。用户正在编辑简历、浏览岗位、准备某一轮技术面，系统给模型的上下文应该围绕当前任务，而不是把用户所有历史行为都塞进去。信息越贴近当前目标，模型越容易给出有用答案。面试里主动说出“上下文选择也是产品设计”，会比单纯说 prompt 更成熟。