Interview Bank

How to reason about it · think before answering

1. Saying 'summarize it' earns nothing — everyone says that. The signal is whether you name a trigger point and a keep-list; without those you sound like someone who never ran a long conversation in production.
2. Split it into three questions before answering: when to compress, what to drop, what to keep. The split itself scores, because it frames compression as a policy rather than a function.
3. Trigger on a threshold, not a timer, and never on an error. Give a number and justify it: compress at roughly 70% of the history budget, because summarizing is itself a model call that can be slow or fail. Waiting until 90% means one timed-out summary call and the next turn slams into the window limit.
4. Drop the process: intermediate reasoning, raw tool payloads already consumed, requirements the user later reversed — their value has already settled into later conclusions. Keep the system prompt (it is not history), the most recent turns verbatim, and any constraint or fact the user stated explicitly. Getting that last one wrong makes the model visibly forget.
5. Add the detail others miss: the cut must land on a turn boundary. Slicing between an assistant tool_calls message and its matching tool result leaves a dangling call, and most providers reject that request with a 400. This is the line that proves hands-on experience.
6. Two follow-ups to expect. Which model summarizes? A cheap small one — summarization is extraction, not reasoning, which ties back to tiered routing. And what if the summary call fails? Degrade to a plain sliding window that drops the oldest turns, so a failed compression never fails the whole turn.

分析过程 · 先想清楚再作答

1. 这题的区分度不在「用摘要」三个字上，几乎人人都答得出。区分度在你有没有说出触发时机和保留清单——只答「让模型总结一下前面的对话」的，面试官会判定你没在长对话上线过。
2. 先把问题拆成三问再逐个答：什么时候压、压掉什么、保留什么。这个拆法本身就是加分项，因为它说明你把压缩当成一个策略而不是一个函数。
3. 触发用阈值不用定时器，也不能等报错。给一个具体数字并解释它：历史占用到预算的七成就动手，因为摘要本身是一次模型调用，有延迟也可能失败，卡到九成再压，一旦摘要超时下一轮就直接撞窗口上限了——七成是留给自己的抢救时间。
4. 压掉的是过程性内容：中间推理、已经被消费完的工具原始返回值、用户后来推翻的需求。它们的共同点是价值已经沉淀进后面的结论里。保留的是系统提示词（它不属于历史）、最近若干条原文、以及用户明确声明过的约束和事实——后者写错了模型会当场失忆。
5. 再补一条别人不会说的：切口必须对齐到一轮的开头。切在 assistant 的 tool_calls 和对应的 tool 结果中间，下一次请求就有了悬空调用，多数厂商的 API 直接返回 400。这一条最能证明你真的调过。
6. 可以预期的追问有两个。一是摘要该用哪个模型：用便宜的小模型就行，摘要是抽取任务不是推理任务，这也接上了 D4 的分层路由。二是摘要调用失败了怎么办：降级到不摘要的滑动窗口（直接丢最早的几轮），保证请求发得出去，别让压缩失败连带整轮对话失败。

How to reason about it · think before answering

1. The trap is answering that context engineering is just prompt engineering leveled up. Interviewers want a rule they can apply to classify a live problem.
2. Start with the object of each. Prompt engineering shapes content: how to phrase one instruction precisely. Context engineering allocates budget: how much of the window each part gets and when to drop things. One optimizes inside a single call, the other manages state across turns.
3. Then give a symptom-based test. Wrong once but right after rephrasing means a prompt problem. Fine for five turns and violating the original constraints by turn twenty means a context problem. Retrieving the data and then claiming it does not exist is also a context problem: the information is in the window but buried.
4. Conclusion: you switch not when the prompt is good enough, but when the cause moves from single-turn phrasing to multi-turn accumulation. Adding tools, adding retrieval, or running long sessions each trigger the switch.
5. Expect the follow-up: does context engineering subsume prompt engineering? The system prompt is one of the four parts, so prompt engineering is a subproblem, but it cannot touch tool definitions, history, or tool results.

分析过程 · 先想清楚再作答

1. 这题最容易答成「上下文工程是提示词工程的升级版」，那是营销话术。面试官想听的是一条能当场用来分类问题的判据。
2. 怎么拆：先给对象的差别。提示词工程处理的是内容——一段话怎么写才准确；上下文工程处理的是预算分配——整只箱子里各块占多少、什么时候该扔。前者是单次调用内的优化，后者是跨多轮的状态管理。
3. 再给一条现场可用的分类法，用症状反推：同一个问题问一次答错、换个说法就对，是提示词问题；前五轮正常、第二十轮开始违反最初约束，是上下文问题；明明查到了数据模型却说没有，也是上下文问题——信息在窗口里，只是被淹没了。
4. 结论：切换的时机不是「提示词写得够好了」，而是「问题的成因从单次表达变成了多轮累积」。加了工具、加了检索、开始多轮长跑，这三件事任何一件发生，都意味着该切换了。
5. 可预期的追问：那上下文工程包含提示词工程吗？答：系统提示是上下文四块里的一块，所以提示词工程是上下文工程的一个子问题，但它解决不了另外三块——工具定义、历史和工具结果都不是靠把话写好能管住的。