Interview Bank

Context Engineering in 5 Days

D1 Context Is the Scarcest Resource: the Window, Attention Decay, and Cost — From Prompt Engineering to Context Engineering

• Context windows keep growing. Why not just put everything potentially relevant into the prompt?窗口越来越大了，为什么不能把所有可能有用的资料都塞进去？

  Common in ChinaCommon overseasIntermediate#context-rot#attention-budget#cost

  How to reason about it · think before answering

  1. The hinge is whether you treat the window as capacity or attention as a budget. Answering only with cost reads as inexperience, since cost is the easiest and least dangerous of the three bills.
  2. Split into capability and cost. On capability, name context rot: recall accuracy degrades as context grows, rooted in the n-squared pairwise relationships a transformer maintains over n tokens, plus the fact that long-range parameters are underrepresented in training.
  3. Stress that this is a gradient, not a cliff. No specific length breaks; every thousand irrelevant tokens shaves a little accuracy. That phrasing distinguishes people who read primary sources.
  4. On cost, give three bills: money (the model is stateless, so every turn resends everything and the total is cumulative, not the last call), latency (slower time to first token), and accuracy (irrelevant content dilutes attention). The third is worst because it never raises an error, it just returns a plausible answer that violates a stated constraint.
  5. Expect the follow-up: how do you decide whether a given chunk earns its place? Give an operational test: if you cannot name the specific decision it changes, it does not go in.

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

  1. 这题的题眼是「你知不知道窗口是容量、注意力是预算」。只回答「太贵了」的人会被判成没做过工程，因为成本是三笔账里最容易想到、也最不致命的一笔。
  2. 怎么拆：分成能力和代价两条线。能力这条线要点出上下文腐烂——随着上下文变长，模型准确回忆其中信息的能力会下降，根源在于 Transformer 里 n 个 token 有 n 平方级别的两两关系，注意力被摊薄；而且训练语料里长序列本来就少，处理长距离依赖的参数不够多。
  3. 关键是要强调它是一条缓坡不是一道悬崖：没有哪个长度会突然崩掉，每多塞一千个不相干的 token，正确率就低一点点。这个措辞能立刻区分读过一手材料的人。
  4. 代价这条线给三笔账：钱（模型无状态，每轮全量重发，总输入是累加值不是最后那次的值）、延迟（首字返回变慢）、正确率（无关内容稀释注意力）。第三笔最贵，因为它不会报错，只会给出看起来合理但违反了约束的回答。
  5. 可预期的追问：那你怎么判断某段内容该不该加？给一条可执行的判据——说不出它会改变模型哪一个具体决定，就不该加。

  Key points

  • The window is capacity; attention is the budget. Fitting is not the same as being used well.
  • Context rot: recall degrades as context grows, as a gradient rather than a hard cliff.
  • Three bills: money (stateless models resend everything each turn, so cost is cumulative), latency, and accuracy.
  • Accuracy is the dangerous one because it fails silently with plausible answers that break stated constraints.
  • Test: if you cannot name the specific decision a chunk changes, leave it out.

  答题要点

  • 窗口是容量，注意力是预算；容量够不代表模型用得好。
  • 上下文腐烂：上下文越长，准确回忆的能力越差，是渐进的性能梯度而不是一道悬崖。
  • 三笔账：钱（每轮全量重发，成本是累加值）、延迟、正确率。
  • 正确率那一笔最危险，因为它不报错，只会给出看似合理却违反约束的回答。
  • 判据：说不出这段内容会改变哪一个具体决定，就不该放进去。
• Where is the line between prompt engineering and context engineering, and when do you switch?提示词工程和上下文工程的分界在哪？什么时候该从前者切换到后者？

  Common in ChinaCommon overseasIntermediate#prompt-engineering#context-engineering#scoping

  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. 可预期的追问：那上下文工程包含提示词工程吗？答：系统提示是上下文四块里的一块，所以提示词工程是上下文工程的一个子问题，但它解决不了另外三块——工具定义、历史和工具结果都不是靠把话写好能管住的。

  Key points

  • Prompt engineering shapes content; context engineering allocates budget across turns.
  • Classify by symptom: fixed by rephrasing is a prompt issue; drifting after many turns is a context issue; retrieved but reported missing is also a context issue.
  • Switch when the cause moves from single-turn phrasing to multi-turn accumulation, typically after adding tools, retrieval, or long-running sessions.
  • The system prompt is one of four parts, so good phrasing alone cannot control the other three.

  答题要点

  • 提示词工程处理内容，上下文工程处理预算分配；一个在单次调用内，一个跨多轮。
  • 症状分类法：换个说法就对是提示词问题；跑久了开始违反约束是上下文问题；查到了却说没有也是上下文问题。
  • 切换时机是问题成因从单次表达变成多轮累积，通常发生在加工具、加检索、开始长跑之后。
  • 系统提示只是上下文四块之一，所以写好提示词管不住另外三块。

D2 System Prompts and the Instruction Hierarchy: the Right Altitude, Persistent Instruction Files, Progressive Disclosure, Less Is More

• How do you calibrate the altitude of a system prompt, and what goes wrong at each extreme?系统提示的高度怎么把握？写太具体和写太笼统各会出什么问题？

  Common in ChinaCommon overseasIntermediate#system-prompt#altitude

  How to reason about it · think before answering

  1. This tests whether you have an operational yardstick. Answering that it should be specific but not too specific fails, because that sentence cannot guide a single concrete edit.
  2. Name both failure modes. Too low means business logic hardcoded into prose: seven order states become seven branches, every new state forces a prompt edit, and no test tells you when you missed one. Too high means text that reads well and changes nothing if deleted.
  3. Give the yardstick: can you write an automated assertion that checks whether the rule was followed? If not, the rule is too high. If the assertion needs to enumerate seven cases, the rule is too low. A short assertion means the altitude is right.
  4. Then the fixes. For too low, relocate rather than shorten: keep the entry rule and push branch detail into a reference file loaded on demand. For too high, translate the incident that produced it into a checkable rule instead of just deleting it, or the incident recurs.
  5. Expect the follow-up: how do you know why a rule was added? Record the failing case beside the rule when you add it. Without that note, nobody will dare delete anything six months later.

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

  1. 这题在考你有没有一把可操作的尺子。凡是答「要恰到好处」「要具体但不要太具体」的，都会被归到没做过工程那一类，因为这句话不能指导任何一次具体修改。
  2. 怎么拆：先把两端的病症说清楚。写太具体是把业务逻辑硬编码进了自然语言——七种订单状态写成七条分支，加一个状态就要改提示词，而且没有任何测试会告诉你改漏了。写太笼统是一段读起来无可指摘、删掉之后模型行为却完全不变的话。
  3. 给尺子：你能为这条规则写出一个自动检查它有没有被遵守的断言吗。写不出来说明飞太高；写得出来但断言要列举七种情况说明飞太低；写得出来且断言很短，高度就合适。这把尺子的好处是能当场逐条判定，不需要争论。
  4. 结论加修法：太低的修法是挪走而不是缩写——留下入口规则，把分支细节搬进引用文件按需读取；太高的修法是把它当初对应的那次事故翻译成可核对的规则，而不是直接删掉，否则同一个事故会再来一次。
  5. 可预期的追问：那怎么知道一条规则当初是为什么加的？答：加规则的时候就在旁边记下它是为哪个失败案例加的。没有这句注释，半年后没人敢删任何一条。

  Key points

  • Too low hardcodes business branches into prose: brittle, and silent when it goes stale. Too high is text that changes nothing when removed.
  • Test: can you write an automated assertion for the rule? No assertion, or one that enumerates seven cases, means the altitude is wrong.
  • Fix too low by relocating detail into on-demand reference files and keeping only the entry rule; fix too high by translating the originating incident into a checkable rule.
  • Record the failing case beside every rule you add; it is the only basis for deleting it later.

  答题要点

  • 高度太低是把业务分支硬编码进自然语言，脆且改漏无人知；太高是删掉也不改变行为的废话。
  • 判据：能不能为这条规则写出一个自动断言，断言写不出或要列举七种情况都是高度不对。
  • 太低的修法是把细节挪进引用文件、主提示只留入口规则；太高的修法是把对应事故翻译成可核对的规则。
  • 每加一条规则就记下它对应的失败案例，这是将来敢不敢删它的唯一依据。
• What belongs in the system prompt, what belongs in a persistent instruction file, and what should be loaded on demand?哪些内容该进系统提示，哪些该进持久指令文件，哪些该按需加载？

  Common in ChinaCommon overseasIntermediate#instruction-hierarchy#progressive-disclosure

  How to reason about it · think before answering

  1. This tests layering. Answering that frequently used content goes in the system prompt is circular, since defining frequently used is the actual question. Give an ordered decision procedure instead.
  2. Three questions, first yes wins. Would the model get it wrong without this rule? If not, delete. Is it needed for every class of task? If not, push it into a reference file and leave a one-line index. Whatever remains stays, rewritten as a mechanically checkable sentence.
  3. Add the category people miss: runtime facts that change over time, such as whether it is currently night hours, whether holiday shipping delays apply, or this session's order id. They look like rules but start lying to users hours later. They belong in tool output or in the user message.
  4. Conclusion: sort by stability and frequency. The more stable, the earlier; the rarer, the later; anything that changes every call never enters the system prompt. Bonus: this ordering is what makes a cache prefix hittable, so editing a task variable does not invalidate everything.
  5. Expect the follow-up: is pushing content down safer than deleting it? No. Reference files still have to be maintained and still consume context when read, just later and less often. Keeping things just in case is the main cause of prompt bloat.

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

  1. 这题在考分层意识。只回答「常用的放系统提示」是循环论证——问题恰恰是怎么定义常用。面试官想听的是一条排序明确的判定流程。
  2. 怎么拆：给三问，第一个答是就落定。第一问，模型不看这条会做错吗，不会就删除；第二问，是不是每一类任务都用得上，不是就下沉到引用文件、主提示里只留一句索引；剩下的保留，并重写成能被机械核对的一句话。
  3. 补一层常被漏掉的划分：还有一类内容根本不属于以上三者——随时间变化的运行时事实，比如当前是不是夜间、是不是节假日延迟期、本次会话的订单号。它们看着像规则，写死在系统提示里就会在半天之后开始骗用户，应该由工具返回或每次拼进用户消息。
  4. 结论：判据是稳定程度加使用频率。越稳定越靠前，越少用越靠后；而每次都变的东西根本不进系统提示。附带一个工程收益——按稳定程度排序之后，缓存前缀才有机会命中，改一条任务变量不会打掉整段缓存。
  5. 可预期的追问：下沉是不是比删除安全？不是。搬进引用文件的内容仍然要维护、仍然会在需要时占上下文，只是晚一点少一点。真正没用的条目要删，「先留着以防万一」正是提示词膨胀的主因。

  Key points

  • Three questions decide placement: would the model err without it (no means delete), is it needed by every task class (no means push down), and the rest stays as a checkable sentence.
  • A fourth category is runtime fact (time of day, holiday delays, this session's order id); it belongs in tool output or the user message, not the system prompt.
  • Order layers by stability so the cache prefix stays hittable.
  • Pushing down is not free: reference files still cost maintenance and context, so genuinely useless rules should be deleted.

  答题要点

  • 三问定去处：模型不看会做错吗（不会就删）、每类任务都用得上吗（不是就下沉）、剩下的保留并重写成可核对的一句话。
  • 第四类是运行时事实（时间、节假日、本次订单号），不属于系统提示，应由工具返回或拼进用户消息。
  • 分层顺序按稳定程度排，稳定的在前，这样缓存前缀才有机会命中。
  • 下沉不是免罪符：引用文件仍要维护、仍会占上下文，没用的要删掉。

D3 Managing Context for Tool Results and Retrieval: Loading on Demand, Summarizing and Pruning, Structured Returns

• An agent has thirty tools mounted and it is clearly struggling. How do you cut the list, and on what basis?Agent 挂了三十个工具，明显吃不消了。你会怎么裁？依据是什么？

  Common in ChinaCommon overseasIntermediate#tool-design#tool-budget

  How to reason about it · think before answering

  1. The question separates people who see only the token bill from people who also see the selection cost. Answering with token count alone covers half the problem.
  2. Two distinct costs. Budget: tool definitions are resent every turn, roughly 308 tokens for three tools and 731 for eight, so thirty tools burn a couple thousand tokens per turn. Selection: more tools means more wrong choices, and the sharp test is that if a human engineer cannot say which tool applies, the model cannot either.
  3. Give four ordered criteria: overlapping responsibility (merge, or write the boundary into the description), call frequency across the last hundred real sessions (zero calls means remove), whether the task type can be determined up front (if so, mount per task), and whether several query tools can collapse into one parameterized tool.
  4. Conclusion: the third usually wins biggest. Most agents mount the full set at startup and keep it for the whole session, while any given session belongs to only two or three task classes, so per-task mounting typically halves the definitions immediately.
  5. Expect the follow-up on side effects: tool definitions sit at the very front of the cache prefix, so changing them invalidates everything after. Mount by coarse task class once at session start rather than recomputing every turn.

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

  1. 这题在考你能不能区分两类完全不同的代价。只答「工具定义占 token」的人只看到了一半，面试官真正在意的是另一半——选择成本。
  2. 怎么拆：先分两类问题。预算问题是工具定义每一轮都重发，3 个工具约 308 token、8 个约 731，挂三十个就是两千多，每轮都在花。选择问题是工具越多模型越容易选错，判据很硬：如果一个人类工程师都说不清什么时候该用哪个工具，那模型也做不到。
  3. 给四条可执行的裁剪判据，按顺序问：职责有没有重叠（有就合并或把边界写进描述）、过去一百次真实会话里被调用过几次（零次直接摘掉）、任务类型能不能提前判断（能就按任务动态挂载）、能不能把几个查询合并成一个带参数的工具。
  4. 结论：第三条通常收益最大。多数 Agent 的工具清单是静态的，启动时挂全集挂到会话结束，而一次会话往往只属于两三类任务中的一类，按任务大类动态挂载一步就能砍掉一半。
  5. 可预期的追问：动态挂载有什么副作用？工具定义排在缓存前缀最前面，改它会让整段前缀失效，所以只能按任务大类切几档，不能每轮重算——会话开始时定一次，中途除非任务类型真变了否则不动。

  Key points

  • Two costs: budget (definitions resent every turn, growing with count) and selection (overlapping tools make the model waver at decision points).
  • Test: if a human cannot say which tool applies, neither can the model.
  • Four cuts in order: merge overlaps, drop never-called tools, mount per task type, collapse several queries into one parameterized tool.
  • Per-task mounting pays most but invalidates the cache prefix, so switch by coarse task class once per session.

  答题要点

  • 两类代价：预算（工具定义每轮重发，随数量线性增长）与选择（重叠工具让模型在决策点上摇摆）。
  • 判据：人类说不清该用哪个，模型也做不到。
  • 四条裁剪顺序：合并职责重叠的、摘掉零调用的、按任务类型动态挂载、把多个查询合并成带参数的一个。
  • 动态挂载收益最大，但会打掉缓存前缀，所以按任务大类切档、会话内不再变。
• How do you choose between just-in-time loading and pre-inference retrieval, and how would you combine them?按需加载和预先检索怎么选？混合策略应该怎么搭？

  Common in ChinaCommon overseasIntermediate#retrieval#just-in-time#hybrid

  How to reason about it · think before answering

  1. This tests situational judgment. Calling just-in-time more advanced reads as trend-following, because pre-inference retrieval is genuinely better in many cases.
  2. Separate with three questions: can the needed material be scoped in advance (yes favors pre-retrieval), how fast does the material change (fast means indexes go stale, favoring just-in-time), and can it be fetched in one shot (multi-hop exploration forces just-in-time).
  3. Name the underlying difference: pre-retrieval hands the what-to-fetch decision to a retrieval algorithm and settles it before inference; just-in-time hands it to the model and spreads it across the run. The first is faster and more predictable, the second handles not knowing in advance.
  4. Conclusion is hybrid: preload the small, stable, always-relevant slice such as a project's standing instruction file, and use runtime search primitives for the rest. That gives a fast start without stale indexing, which is what coding agents converge on.
  5. Expect the follow-up on cost: just-in-time adds round trips and latency, and every fetched body stays in context consuming budget, so it must be paired with trimming.

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

  1. 这题在考场景判断。答「按需加载更先进」的会被当成跟风，因为预先检索在很多场景里就是更好的选择，说不出它好在哪说明没做过。
  2. 怎么拆：用三个问题分开。需要的资料范围事先能不能确定（能就预先检索）、资料变化快不快（变得快索引一建就旧，偏按需加载）、一次能不能取完（要顺着线索翻好几层就只能按需）。
  3. 把两者的本质差别点出来：预先检索把「取什么」的决定权交给检索算法，在推理之前一次性做完；按需加载把这个决定权交给模型自己，在推理过程中分多次做。前者延迟低、可预测，后者能应付事先不知道要什么的情况。
  4. 结论是混合：把最稳定最常用的一小部分预先放进去（比如项目的常驻说明文件），其余靠运行时的搜索原语现取。这样既有起步速度，又不会被过期索引拖住。这也是编码类 Agent 的主流做法。
  5. 可预期的追问：按需加载的成本在哪？多了几轮往返，延迟更高，而且每一次取回的正文都会留在上下文里继续占预算——所以它必须和裁剪配套，取回来的东西该扔的时候要扔。

  Key points

  • Three questions: can scope be fixed in advance, how fast does the data change, and can it be fetched in one shot.
  • Pre-retrieval delegates the fetch decision to an algorithm before inference; just-in-time delegates it to the model during the run.
  • Most real systems are hybrid: preload the stable core, use runtime search for the rest, avoiding stale indexes.
  • Just-in-time costs round trips and latency, and fetched bodies keep consuming budget, so pair it with trimming.

  答题要点

  • 三个判断：范围能不能事先确定、资料变化快不快、一次能不能取完。
  • 预先检索把取什么的决定交给检索算法并在推理前做完；按需加载把它交给模型并分多次做。
  • 多数真实项目是混合：稳定常用的一小部分预加载，其余靠运行时搜索原语现取，避开索引过期。
  • 按需加载的代价是多轮往返与延迟，且取回的正文会继续占预算，必须和裁剪配套。

D4 Long-Running Sessions: Compression, Notes and Memory Files, Subagent Isolation and Handoff Summaries

• When should you compact the context, and when should you just move to a larger context window?什么时候该压缩上下文，什么时候该直接换一个更大的窗口？

  Common in ChinaCommon overseasIntermediate#compaction#context-rot

  How to reason about it · think before answering

  1. This checks whether you treat the window as capacity and attention as a budget. Answering only that you compact when it does not fit misses half the cases, since plenty of sessions should be compacted while the window is still mostly empty.
  2. Separate the two problems. Not fitting is capacity, and a bigger window fixes it. But a bigger window does not fix context rot: recall degrades as context grows, on a gradient, so a large nominal window is not a promise of stable behavior at that length. Fitting and being used well are different.
  3. Give the test: watch two signals, not one. High window occupancy means compact for capacity. Low occupancy with a low share of actually-useful tokens also means compact, for attention. The second is the one people miss because nothing looks urgent.
  4. Then order the tactics. Compaction is not the first move. Clear stale tool results first, since that needs no model call, is deterministic, and is reversible. Only then summarize history. Doing it the other way costs an extra call and risks losing information while usually treating the smaller bucket.
  5. Expect the follow-up: when is compaction itself not enough? When the state is an accumulating ledger rather than a summarizable conclusion, such as exact tallies, maps, or a long-term plan. Those belong in files outside the window.

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

  1. 这题在考你有没有把窗口当容量、把注意力当预算。只回答「窗口不够就压缩」的人漏掉了一半——很多时候窗口还很空，但已经该压了。
  2. 怎么拆：先把两个问题分开。窗口不够是容量问题，换大窗口确实能解决；但换大窗口解决不了上下文腐烂——上下文越长模型准确回忆的能力越差，这是一条缓坡，标称窗口大不等于在那个长度上表现稳定。所以「装得下」和「用得好」是两件事。
  3. 给判据：看两个指标而不是一个。窗口占用率高就该压（容量问题）；占用率不高但有效信息占比很低，也该压（注意力问题）——后者最容易被忽略，因为看起来毫无压力。
  4. 再给顺序上的结论：压缩不是第一手段。先清掉旧的工具结果（不用调模型、确定、可逆），不够再摘要历史。反过来做的人很多，因为摘要听起来更高级，但摘要要多花一次调用、要承担丢信息的风险，而它治的往往不是大头。
  5. 可预期的追问：那什么时候压缩也不够？当状态是渐进积累的账本而不是可总结的结论时——比如精确计数、地图、长期计划。这类东西要写到窗口外面的文件里，不能靠摘要保住。

  Key points

  • Not fitting is capacity and a larger window solves it; context rot is attention and a larger window does not.
  • Two triggers: high window occupancy, or low occupancy with a low share of useful tokens.
  • Clear stale tool results first (no model call, deterministic, reversible), then summarize history.
  • If the state is an accumulating ledger such as tallies, maps, or a plan, use external files instead of compaction.

  答题要点

  • 窗口不够是容量问题，换大窗口能解决；上下文腐烂是注意力问题，换大窗口解决不了。
  • 两个触发信号：窗口占用率高，或占用率不高但有效信息占比很低。
  • 顺序上先清旧工具结果（不调模型、确定、可逆），不够再摘要历史。
  • 如果状态是渐进积累的账本（计数、地图、长期计划），压缩救不了，要写到窗口外的文件里。

D5 Measuring and Tuning: the Token Bill, Context Utilization, Failure-Mode Triage, and a Comprehensive Interview Deep Dive

• When context is the problem, how do you localize which of the four buckets is at fault?上下文出问题的时候，你怎么定位是四块里的哪一块？

  Common in ChinaCommon overseasIntermediate#diagnostics#metrics

  How to reason about it · think before answering

  1. This tests a diagnostic path. Answering with check the logs or try again reads as having no method; interviewers want a fixed chain from symptom to metric to change.
  2. Start with two metrics. Window occupancy is per-turn input over the window limit and governs whether you will overflow. Useful-token share is the tokens later steps actually use over total tokens and governs whether the spend is worth it. Approximate the latter with your trimmer: whatever survives trimming is the numerator.
  3. Then four failure modes with their fingerprints: overstuffed (early instructions ignored, high occupancy), buried (the fact is in the window yet the model denies it, low useful share), underspecified (answers waver across identical questions, low occupancy but high error rate), and drifting (original constraints violated late in the session, retention checks failing after compaction).
  4. Highlight the two most misdiagnosed. Buried is routinely blamed on model capability; the test is to print the context and search for the fact by hand, and if it is there the problem is context, not the model. Underspecified is blamed on instability, when it usually means contradictory rules in the system prompt or two overlapping tools making the model waver.
  5. Expect the follow-up on conflicting metrics. Low occupancy with a low useful share is the dangerous combination, because nothing looks urgent while you pay full price to move noise and dilute attention. Trust the useful-token share there.

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

  1. 这题在考排查路径。答「先看日志」「多试几次」的会被判成没有方法论，面试官想听的是从现象到指标再到改动的一条固定链路。
  2. 怎么拆：先给两个指标。窗口占用率是单轮输入除以窗口上限，管的是会不会撑爆；有效信息占比是后续步骤真正用到的 token 除以总 token，管的是值不值。后者可以用裁剪器近似量：裁完还剩的那部分就是分子。
  3. 再给四种失败模式与各自的指纹：塞太满（漏读早期指令，占用率高）、找不到（信息在窗口里但模型说没有，有效信息占比低）、说不清（同类问题答法摇摆，占用率不高但错误率高）、越走越偏（跑久了违反最初约束，压缩前后的保留检查出现失败项）。
  4. 结论给最容易误判的两种。「找不到」常被误判成模型能力不足，判据是把上下文打印出来人肉搜一遍那条信息在不在——在就是上下文问题，不是模型问题。「说不清」常被误判成模型不稳定，实际多半是系统提示里有互相矛盾的规则，或者两个职责重叠的工具让模型在决策点上横跳。
  5. 可预期的追问：两个指标冲突时听谁的？答：占用率低但有效信息占比也低的情况最危险，因为看起来毫无压力却在按原价搬运垃圾，同时还在稀释注意力。这时应该以有效信息占比为准。

  Key points

  • Two metrics: occupancy for overflow risk, useful-token share for whether the spend earns its place, approximated with a trimmer.
  • Each mode has a fingerprint: occupancy for overstuffed, useful share for buried, error rate for underspecified, post-compaction retention checks for drifting.
  • Buried is most often misdiagnosed as model capability; print the context and search by hand.
  • Underspecified usually means contradictory rules or overlapping tools; hunt the contradiction rather than swapping models.

  答题要点

  • 两个指标：窗口占用率管会不会撑爆，有效信息占比管值不值，后者可用裁剪器近似量。
  • 四种模式各有指纹：塞太满看占用率、找不到看有效信息占比、说不清看错误率、越走越偏看压缩后的保留检查。
  • 找不到最容易被误判成模型能力问题，判据是把上下文打印出来人肉搜一遍。
  • 说不清多半是规则互相矛盾或工具职责重叠，去搜矛盾比换模型有用。
• How much context engineering is enough, and how do you know when to stop?上下文工程做到什么程度算够？你怎么知道该停手了？

  Common in ChinaCommon overseasIntermediate#tuning#stopping-criteria

  How to reason about it · think before answering

  1. This is open-ended but has a clear right shape. Saying more optimization is always better reads as lacking cost awareness, because context work is unbounded and will be overdone without a stopping rule.
  2. Name the concrete cost of overdoing it rather than stopping at wasted time. Trim too hard and you cut fields needed later; compact too hard and you lose hard requirements that do not read like conclusions; cut tools too far and the agent cannot finish the task. None of these raise errors; they show up only in accuracy, the most expensive bill.
  3. Give at least three checkable stopping conditions: useful-token share stable in a healthy band such as above fifty percent with no headroom across several measurements; per-turn occupancy under fifty percent on your longest case; and the last change delivering less than a five percent bill reduction.
  4. Land on the third: a sub-five-percent gain means what remains is necessary overhead, and squeezing further trades accuracy for money. It matters most because it is the only condition that transfers across projects unchanged.
  5. Expect the follow-up on preventing regression. Freeze the measurement into a regression suite: fixed cases, rerun on every change, bill and both metrics under monitoring. Model upgrades, tool churn, and downstream field changes each degrade it again.

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

  1. 这题是开放题，但它有明确的好坏。答「越优化越好」的人会被判成没有成本意识，因为上下文工程是个能无限做下去的活，不定停手判据就一定会做过头。
  2. 怎么拆：先说清过度优化的具体代价，不要停在「浪费时间」。裁得太狠会把后面才用得上的字段裁掉，压得太狠会丢掉不像结论的硬性要求，工具裁得太少会让模型没法完成任务。这些都不报错，只在正确率上体现，而正确率是最贵的一笔账。
  3. 给可核对的停手条件，至少三条：有效信息占比稳定在一个合理区间（比如 50% 以上）且连续几次测量没有上升空间；最长那条用例上的单轮窗口占用率不超过 50%；最近一次改动带来的账单降幅低于 5%。
  4. 结论落在第三条：降幅低于 5% 说明剩下的都是必要开销，继续压就是在拿正确率换钱。这条比前两条更重要，因为它是唯一一条与具体项目无关、可以直接复用的判据。
  5. 可预期的追问：那怎么保证停手之后不退化？把这套度量固化成回归：一批固定用例、每次改动都重跑、账单与两个指标进监控。上下文工程不是一次性项目，模型换代、工具增减、下游接口改字段，任何一件都会让它重新变差。

  Key points

  • Overdoing it fails silently in accuracy: fields needed later get cut, hard requirements get summarized away, and too few tools leave the task unfinishable.
  • Three stopping conditions: a stable useful-token share with no headroom, per-turn occupancy under fifty percent on the longest case, and a last change worth under five percent of the bill.
  • The third transfers best: under five percent means what remains is necessary overhead and further squeezing trades accuracy for money.
  • After stopping, freeze it into regression: fixed cases, rerun on every change, and monitor the bill plus both metrics.

  答题要点

  • 过度优化的代价不报错，只在正确率上体现：裁掉后面才用的字段、压掉不像结论的硬性要求、工具少到做不完任务。
  • 三条停手判据：有效信息占比稳定且无上升空间、最长用例的单轮占用率不超过 50%、最近一次改动账单降幅低于 5%。
  • 第三条最通用：降幅低于 5% 说明剩下的是必要开销，再压就是拿正确率换钱。
  • 停手后要固化成回归：固定用例、每次改动重跑、账单与两个指标进监控。