AI 岗位预备 · 熟练
面试官问上下文，你在答哪一层？
概念 · 预算 · 位置——三问答完才算答完
这道题看起来在问概念，实际在筛三种人：能把「模型眼前该出现哪些信息」当成一门工程的人、把上下文当有限预算在算的人、知道「塞进去了不等于模型会看」的人。本页按面试现场的顺序拆：先用一句话把 Prompt Engineering 与 Context Engineering 分开，再给五块预算与超预算时的裁剪顺序，然后补上最容易漏的位置偏见；最后给一段能直接背下来的救急答案，以及面试官会接着追问的三条。
先说结论
一句话先定调：Prompt Engineering 管「这句话怎么写」，Context Engineering 管「模型眼前应该出现哪些信息」——前者是写死就固定的一段文本，后者是每一轮都在变的组合：system、工具定义、检索片段、历史、当前问题，五块一起抢同一个窗口。
追问现场 · 面试真题
“你们现在还在调 prompt 吗？如果让你负责一个 Agent 系统的上下文管理，你会怎么设计？上下文超预算了怎么办？”
大多数人的第一反应：把上下文工程说成「提示词写得好」，然后开始背 system prompt 的写法——面试官听到第二句就知道你没跑过长会话。
这道题考的不是「你会不会写提示词」，是三件事：你能不能把「模型眼前该出现哪些信息」当成一门工程；你有没有把上下文当成一份有限预算在算；你知不知道「塞进去了 ≠ 模型会看」。三件答齐是及格线，能说出失效模式才是加分。
基础层 · 行业方案
五块预算：system 通常占一成左右；工具定义的 JSON schema 在工具多时能吃掉两成以上；检索片段常常是最大头；历史随轮次线性增长、是超预算的第一嫌疑人；当前问题占比最小，但优先级最高。
裁剪顺序：先压历史（摘要在前、原文丢弃）→ 再降检索片段条数 → 最后才动 system 与 query。理由是：砍 system 等于改行为，砍 query 等于改需求。
位置也是信息：模型对开头与结尾的注意力最强、中间 30%~70% 明显减弱。生产里的做法不是按相关度从高到低平铺，而是把最相关的放首尾、最弱的塞中间。
执行层 · 我们的增量
先报「窗口的账」再谈设计：说清这条链路一轮的固定开销是多少（system + 工具 schema）、增长部分是谁（历史 / 工具返回）、峰值出现在第几轮。会算账的人，才做得出可维护的系统。
把「谁决定放什么」讲清楚：固定内容在前、增长内容在后（保住前缀缓存）；工具返回先在沙箱里存成引用，只把摘要与句柄交给模型。这两句一说，面试官就知道你真跑过。
给一条可验证的判据：改动之后，同一批问题在「首轮 / 第 20 轮 / 压缩之后」三处的结果要能对齐。只测首轮，等于没测上下文工程。
真实事故（事后回看）：最常被追问的一刀：把安全规则写进 system，它在第三轮压缩里消失了——模型照旧干活、没有任何报错。公开的实测口径是压缩一轮后安全规则只剩约一半、五轮只剩一成。
事后补的防御（避免重演）：把「必须存活」的东西列成显式允许清单（安全约束 / 生效中的审批 / 未完成的承诺），压缩步骤只允许动清单之外的内容；压缩后再跑一次固定用例，确认这些约束仍在生效。
面试官想听什么
能一句话分清 PE 与 CE，并说得出「上下文是每轮都在变的组合」。
能给出五块预算与裁剪顺序，并解释为什么 system 与 query 最后才动。
能说出位置偏见，并给出「关键信息放首尾」的具体做法。
被追问「怎么证明改好了」时，答得出三段对齐（首轮 / 第 20 轮 / 压缩后）。
加分项：主动说出「压缩会吃掉规则」这个失效模式，并给出显式允许清单——这一步很少有人答得出来。
可复制 · 救急段
Prompt Engineering 管「这句话怎么写」，Context Engineering 管「模型眼前该出现哪些信息」——后者是每轮都在变的五块：system、工具定义、检索片段、历史、当前问题，一起抢同一个窗口。超预算的裁剪顺序：先压历史 → 再降检索片段条数 → 最后才动 system 和 query，因为砍 system 是改行为、砍 query 是改需求。还有一条容易被忽略：模型对开头与结尾注意力最强、中间最弱，所以最相关的放首尾、最弱的塞中间。最后，压缩会把安全规则一起吃掉（公开实测：一轮只剩约一半、五轮只剩一成），必须给「必须存活」的东西列一份显式允许清单。