面试题库

5 天上下文工程

D1 上下文是最稀缺的资源：窗口、注意力衰减与成本，从提示词工程走到上下文工程

• 一次 Agent 请求的上下文里都有什么？哪一块最容易失控，为什么？What actually goes into the context of a single agent request, and which part is most likely to blow up?

  国内高频海外高频基础#context-window#token-budget

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

  1. 这题在考你有没有真的量过。能背出「系统提示、工具定义、历史、工具结果」四块的人很多，能说出各自增长方式的人很少，区分度全在后半句。
  2. 怎么拆：按「每一轮会怎么变」给四块归类。系统提示和工具定义是每轮原样重发、长度基本不变；对话历史是线性增长，每轮加几十个 token；工具结果是阶梯增长，一次调用就能加两千。
  3. 结论：最容易失控的是工具结果，因为它的单次增量比其它三块大一到两个数量级，而且完全由外部系统决定，你写代码的时候看不到它会有多大。工具定义排第二，它随工具数量线性增长，而工具是最容易被顺手加上去的东西。
  4. 补一个容易被忽略的点：工具结果虽然写在 user 角色的消息里，但它是数据不是对话。按消息角色统计会把它算进历史，那张表就废了——要按内容块的类型拆。
  5. 可预期的追问：那你实际量出来是多少？给一个具体数字最有说服力，比如一次电商客服会话里工具结果占 72.9%，而大多数人事先都猜的是对话历史。

  How to reason about it · think before answering

  1. This question separates people who have measured from people who have read. Naming the four parts is easy; describing how each one grows is where the signal is.
  2. Classify the four by growth pattern: system prompt and tool definitions are resent verbatim every turn at roughly constant size; conversation history grows linearly by tens of tokens per turn; tool results grow in steps, often thousands of tokens per call.
  3. Conclusion: tool results are the most likely to blow up, because a single increment is one to two orders of magnitude larger than the others and its size is decided by an external system you do not control. Tool definitions come second since they scale with a tool count that only ever goes up.
  4. Add the subtlety: tool results live inside user-role messages but they are data, not dialogue. Bucketing by message role folds them into history and ruins the breakdown, so bucket by content block type instead.
  5. Expect the follow-up: what numbers did you actually see? A concrete figure lands best, for example tool results at 72.9 percent of a customer-support session while most people had guessed history.

  答题要点

  • 四块：系统提示、工具定义、对话历史、工具结果。
  • 按增长方式分：前两块每轮重发且基本恒定，历史线性增长，工具结果阶梯增长。
  • 最容易失控的是工具结果，单次增量最大且由外部系统决定；其次是工具定义，随工具数量增长。
  • 统计时要按内容块类型拆，不能按消息角色拆，否则工具结果会被算进对话历史。

  Key points

  • Four parts: system prompt, tool definitions, conversation history, tool results.
  • Group them by growth: the first two are resent every turn at near-constant size, history grows linearly, tool results grow in steps.
  • Tool results blow up first because a single call can add thousands of tokens and its size is set externally; tool definitions are second, scaling with tool count.
  • Bucket by content block type, not by message role, or tool results get miscounted as history.
• 窗口越来越大了，为什么不能把所有可能有用的资料都塞进去？Context windows keep growing. Why not just put everything potentially relevant into the prompt?

  国内高频海外高频进阶#context-rot#attention-budget#cost

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

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

  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.

  答题要点

  • 窗口是容量，注意力是预算；容量够不代表模型用得好。
  • 上下文腐烂：上下文越长，准确回忆的能力越差，是渐进的性能梯度而不是一道悬崖。
  • 三笔账：钱（每轮全量重发，成本是累加值）、延迟、正确率。
  • 正确率那一笔最危险，因为它不报错，只会给出看似合理却违反约束的回答。
  • 判据：说不出这段内容会改变哪一个具体决定，就不该放进去。

  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?

  国内高频海外高频进阶#prompt-engineering#context-engineering#scoping

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

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

  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.

  答题要点

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

  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 系统提示与指令层次：高度适中、持久指令文件、渐进披露，少即是多

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

  国内高频海外高频进阶#system-prompt#altitude

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

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

  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.

  答题要点

  • 高度太低是把业务分支硬编码进自然语言，脆且改漏无人知；太高是删掉也不改变行为的废话。
  • 判据：能不能为这条规则写出一个自动断言，断言写不出或要列举七种情况都是高度不对。
  • 太低的修法是把细节挪进引用文件、主提示只留入口规则；太高的修法是把对应事故翻译成可核对的规则。
  • 每加一条规则就记下它对应的失败案例，这是将来敢不敢删它的唯一依据。

  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?

  国内高频海外高频进阶#instruction-hierarchy#progressive-disclosure

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

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

  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.

  答题要点

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

  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.
• 系统提示越写越长是怎么发生的？你会怎么止住这个过程？How do system prompts keep growing, and how would you stop it?

  国内高频海外高频基础#prompt-bloat#maintenance

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

  1. 这题看着像吐槽题，其实在考流程意识。能答出成因的人不少，能给出一条可执行的止损机制的人很少。
  2. 怎么拆：先讲成因，它是一条单向棘轮。每次线上出问题，最快的止血手段就是往系统提示里加一句；加的人当时知道为什么加，但没写下来；半年后没人敢删，因为删了万一那个事故重来一次，责任在删的人身上。于是只进不出。
  3. 再指出成因里最隐蔽的一层：很多规则是为了绕过某一代模型的具体毛病写的。模型换代之后它们不但没用，还在继续消耗每一轮的输入预算，而且没有任何信号提示你它们已经过期。
  4. 结论给三条机制：一是加规则时强制记录它对应的失败案例，这是将来敢删的唯一依据；二是最小起步——先用最少的规则跑一批真实用例，按观察到的失败逐条加，而不是上线前把能想到的都写上；三是定期做一次逐条判定，用「能不能写出断言」当尺子，并在换模型之后重跑一次。
  5. 可预期的追问：删规则的风险怎么控？答：把每条规则对应的失败案例沉淀成回归用例，删之前先跑一遍。没有用例支撑的规则，本来就没有资格待在那里。

  How to reason about it · think before answering

  1. It sounds like a complaint prompt but it tests process thinking. Many can name the cause; few offer a mechanism that actually stops the growth.
  2. The cause is a one-way ratchet. Every production incident is fastest to patch by appending a sentence to the system prompt. The person who added it knew why but did not write it down. Six months later nobody dares delete it, because if the incident recurs the blame lands on whoever deleted it.
  3. Name the subtle layer too: many rules exist to work around a specific model generation's quirks. After a model upgrade they are useless yet still consume input budget every turn, and nothing signals that they expired.
  4. Give three mechanisms. Record the failing case beside each rule when adding it. Start minimal and add rules only for observed failures rather than writing everything imaginable before launch. Periodically re-audit rule by rule using the can-you-write-an-assertion test, and re-run that audit after every model upgrade.
  5. Expect the follow-up: how do you de-risk deletion? Turn each rule's originating failure into a regression case and run it before deleting. A rule with no supporting case never earned its place.

  答题要点

  • 成因是单向棘轮：出事就加一句，加的理由没记录，之后没人敢删。
  • 隐蔽的一层：很多规则是为绕过某代模型的毛病写的，换代后过期却没有任何信号。
  • 止损三招：加规则时记录对应失败案例、最小起步按失败驱动增加、定期用断言尺子逐条重判。
  • 删除风险靠回归用例控制：每条规则对应的失败案例应沉淀成用例，删前先跑。

  Key points

  • The cause is a ratchet: incidents are patched by appending a line, the reason is never recorded, and nobody dares delete it later.
  • Subtle layer: many rules work around one model generation's quirks and silently expire after an upgrade.
  • Three fixes: record the originating failure with each rule, start minimal and add only for observed failures, and re-audit periodically with the assertion test.
  • Control deletion risk with regression cases derived from each rule's originating failure.

D3 工具结果与检索的上下文管理：按需加载、摘要与裁剪、结构化返回

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

  国内高频海外高频进阶#tool-design#tool-budget

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

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

  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.

  答题要点

  • 两类代价：预算（工具定义每轮重发，随数量线性增长）与选择（重叠工具让模型在决策点上摇摆）。
  • 判据：人类说不清该用哪个，模型也做不到。
  • 四条裁剪顺序：合并职责重叠的、摘掉零调用的、按任务类型动态挂载、把多个查询合并成带参数的一个。
  • 动态挂载收益最大，但会打掉缓存前缀，所以按任务大类切档、会话内不再变。

  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?

  国内高频海外高频进阶#retrieval#just-in-time#hybrid

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

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

  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.

  答题要点

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

  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.
• 为什么说工具返回的内容是不可信输入？做了字段白名单裁剪之后还需要担心吗？Why are tool results untrusted input, and does field whitelisting make the concern go away?

  国内高频海外高频深入#prompt-injection#trust-boundary

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

  1. 这题有个陷阱：很多人会把它当成上下文工程题来答，说「裁剪之后就干净了」。它其实在考你分不分得清预算问题和安全问题。
  2. 怎么拆：先说清楚为什么不可信。工具返回的内容来自第三方接口、用户上传的文件、网页抓取的结果，不是你写的；而模型读到它的时候，和读你的系统提示是在同一个上下文里，没有天然的权限分层。里面可以藏一句「忽略之前的所有指令」，这就是提示注入。
  3. 关键结论：字段白名单一点都不解决这个问题，甚至更危险——你把字段裁到只剩四个，会产生一种「已经清理过了」的错觉，但那四个字段的值仍然是外部可控的自由文本，注入照样能进来。裁剪管的是体积，不是内容的可信度。
  4. 给出正确的分层：上下文工程负责决定装什么进去，安全机制负责决定装进来的东西能做什么。后者要靠最小权限、工具白名单、把外部内容和指令在结构上分开、以及对有副作用的操作加确认，而不是靠裁剪。
  5. 可预期的追问：那能不能在裁剪层顺手做过滤？可以做一些低成本的（比如剥掉控制字符、给外部内容加明确的包裹标记），但不要把它当成防线——基于关键词的过滤对提示注入几乎无效，真正的边界在权限层。

  How to reason about it · think before answering

  1. There is a trap here: many answer it as a context question and claim trimming cleans the data. It actually tests whether you separate budget problems from security problems.
  2. Explain the untrust first. Tool results come from third-party APIs, user-uploaded files, or scraped pages. You did not write them, yet the model reads them in the same context as your system prompt, with no inherent privilege boundary. A line saying to ignore prior instructions can ride along; that is prompt injection.
  3. The key point: field whitelisting does nothing about this and can make it worse by creating a feeling of sanitization. The four surviving fields still carry externally controlled free text. Trimming governs volume, not trustworthiness.
  4. Give the right layering: context engineering decides what goes in; security decides what the content is allowed to cause. That means least privilege, tool allowlists, structurally separating external content from instructions, and confirmation on side-effecting actions.
  5. Expect the follow-up: can the trimming layer filter too? Cheap hygiene like stripping control characters or wrapping external content in explicit delimiters is fine, but keyword filtering is close to useless against injection. The real boundary is the permission layer.

  答题要点

  • 工具结果来自外部系统，模型读它和读系统提示在同一个上下文里，没有天然的权限分层。
  • 字段白名单只减体积，不改变内容的可信度，反而容易造成已清理的错觉。
  • 正确分层：上下文工程决定装什么，安全机制决定装进来的东西能做什么。
  • 防线在最小权限、工具白名单、结构上隔离外部内容、有副作用的操作加确认，不在关键词过滤。

  Key points

  • Tool results originate outside your system yet share a context with your instructions, with no built-in privilege boundary.
  • Field whitelisting reduces volume only; it does not change trustworthiness and can create a false sense of sanitization.
  • Correct layering: context engineering decides what enters, security decides what it may cause.
  • Defenses live in least privilege, tool allowlists, structural separation of external content, and confirmation on side effects, not keyword filters.

D4 长时程会话：压缩、笔记与记忆文件、子代理隔离与交接摘要

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

  国内高频海外高频进阶#compaction#context-rot

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

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

  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.

  答题要点

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

  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.
• 压缩最容易丢什么？你怎么验证一次压缩没有丢掉关键信息？What does compaction lose most easily, and how do you verify that a given compaction kept what mattered?

  国内高频海外高频深入#compaction#verification

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

  1. 这题的区分度全在后半句。谈「要保留重要信息」是空话，面试官想听的是一个可执行的验证机制，以及你有没有真的被它拦下来过。
  2. 怎么拆：先说清压缩为什么比裁剪危险。裁剪动结构，删掉一个字段你知道删了什么、也能取回来；压缩动语言，丢掉了什么是模型决定的，而且丢完不留任何标识。
  3. 点出最脆弱的两类内容：一是最近几轮正在进行的事，一折叠就失去指代对象，模型下一句就会问你说的是哪一单；二是形式上不像结论的硬性要求，比如用户提出的时间点、情绪化诉求、口头承诺——它们在语言上不重要，在业务上是全部。还有一类是标识符，摘要很容易把订单号写成「相关订单」。
  4. 结论给验证机制：预置一组「压缩后必须还能找到」的关键事实，每次压完逐条核对，不通过就拒绝这次压缩或调大保留轮数。三条配套措施是：保留最近若干轮原文、在摘要提示词里让硬性要求单独成段、明确要求逐字保留标识符。
  5. 可预期的追问：你被这个检查拦下来过吗？给一个具体例子最有力，比如把保留轮数从 6 调到 1 时压缩率从 68% 涨到 87%，但「用户要求周五 18:00 前答复」这条直接消失——因为它只活在最近几轮原文里，而且它不像一条结论。

  How to reason about it · think before answering

  1. The signal is entirely in the second half. Saying you keep the important parts is empty; interviewers want an executable verification step and evidence it has actually caught something.
  2. Explain why compaction is riskier than trimming. Trimming changes structure: you know which field you removed and you can fetch it back. Compaction changes language: what got dropped is the model's choice, and nothing marks the loss.
  3. Name the fragile categories. First, whatever is currently in flight in the last few turns, which loses its referent the moment it is folded. Second, hard requirements that do not look like conclusions, such as user-stated deadlines, emotional demands, or verbal commitments. Third, identifiers, which summaries happily rewrite from an order number into the relevant order.
  4. Conclusion: preset a list of facts that must remain findable after compaction and check them every time, rejecting the compaction or widening the verbatim window on failure. Support it with three measures: keep recent turns verbatim, give hard requirements their own section in the summary prompt, and demand verbatim preservation of identifiers.
  5. Expect the follow-up asking whether it ever caught you. A concrete case lands best: dropping the verbatim window from six turns to one raised the compression ratio from 68 to 87 percent but silently deleted a user's stated Friday deadline, because it lived only in recent turns and did not read like a conclusion.

  答题要点

  • 压缩比裁剪危险：裁剪动结构可回溯，压缩动语言且丢失无标识。
  • 最容易丢的三类：最近几轮正在进行的事、不像结论的硬性要求、标识符。
  • 验证机制：预置一组必须存活的关键事实，每次压完逐条核对，不通过就不采纳这次压缩。
  • 配套三招：保留最近若干轮原文、硬性要求在摘要里单独成段、要求逐字保留标识符。

  Key points

  • Compaction is riskier than trimming: structure is recoverable, language loss is silent.
  • Three fragile categories: what is in flight in recent turns, hard requirements that do not look like conclusions, and identifiers.
  • Verification: preset facts that must survive and check each one after every compaction, rejecting it on failure.
  • Support with a verbatim recent window, a dedicated section for hard requirements, and explicit verbatim preservation of identifiers.
• 子代理为什么只回传摘要而不回传全过程？主代理该怎么写交接要求？Why does a subagent return only a summary instead of its full transcript, and how should the lead agent specify the handoff?

  国内高频海外高频深入#subagents#handoff#cost

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

  1. 这题在考架构意图。答「为了省 token」只对了一半，而且是次要的那一半——子代理架构整体上是更贵的，不是更省的。
  2. 怎么拆：先说清目的。子代理隔离买的不是省钱，是主线上下文的干净。子代理可以在自己独立的窗口里烧掉几万 token 反复探索，主线只多了一两千 token 的浓缩结论，中间过程一个字都没进主线。这是关注点分离在上下文层面的落地。
  3. 把代价摆出来，这是最能体现做过工程的地方：Agent 类应用本来就比聊天多用约 4 倍 token，多 Agent 系统约 15 倍。所以适用面很窄——探索量大但产出能浓缩、子任务彼此独立可并行、主线确实不需要看中间过程，三条缺一就该退回压缩。
  4. 结论给交接契约：三段式（已定结论、待办事项、硬约束），且每条结论必须带来源标识（文件路径、订单号、URL）。原因是没有标识的结论不可复查，主线只能全盘相信或全盘重做；带标识之后主线可以只对存疑的那条做定点核实。硬约束那一段没有也要写「无」，不能省略，否则主线分不清是没有还是忘了写。
  5. 可预期的追问：主代理自己的计划怎么办？也该写到窗口外面。长任务后期一旦触发截断或压缩，最先丢的往往就是最初那份计划，而它恰恰最不该丢。

  How to reason about it · think before answering

  1. This tests architectural intent. Saying it saves tokens is only half right, and the lesser half: multi-agent setups are more expensive overall, not cheaper.
  2. State the purpose. Subagent isolation buys a clean main context, not a smaller bill. A subagent can burn tens of thousands of tokens exploring in its own window while the main thread gains only a condensed result of one or two thousand tokens. It is separation of concerns applied to context.
  3. Put the cost on the table, which is where engineering experience shows: agentic applications use roughly four times the tokens of chat, and multi-agent systems roughly fifteen times. So the fit is narrow: heavy exploration with a condensable result, independent parallelizable subtasks, and a main thread that genuinely does not need the intermediate steps. Missing any one, fall back to compaction.
  4. Conclusion: specify a handoff contract of three sections (settled conclusions, open items, hard constraints), with every conclusion carrying a source identifier such as a file path, order id, or URL. Without identifiers the main thread can only trust everything or redo everything; with them it can spot-check the one claim it doubts. Require the constraints section even when empty, or the main thread cannot tell absent from forgotten.
  5. Expect the follow-up about the lead agent's own plan: write it outside the window too, since truncation or compaction late in a long task tends to eat the original plan first.

  答题要点

  • 隔离买的是主线上下文的干净，不是省钱；多 Agent 整体更贵。
  • 代价数量级：Agent 约为聊天的 4 倍 token，多 Agent 约 15 倍。
  • 适用三条：探索量大且产出可浓缩、子任务独立可并行、主线不需要中间过程；缺一就退回压缩。
  • 交接契约三段式，每条结论必须带来源标识，硬约束段即使为空也要显式写「无」。
  • 主代理自己的计划也要写到窗口外，长任务里它最容易被截断或压缩吃掉。

  Key points

  • Isolation buys a clean main context, not savings; multi-agent is more expensive overall.
  • Magnitudes: agents use about four times chat tokens, multi-agent about fifteen times.
  • Fits when exploration is heavy but condensable, subtasks are independent and parallel, and the main thread does not need intermediate steps.
  • Handoff contract in three sections, every conclusion carrying a source identifier, and an explicit none when constraints are empty.
  • Persist the lead agent's plan outside the window, since it is the first casualty of truncation late in long tasks.

D5 度量与调优：token 账单、上下文利用率、失败模式排查与综合面试专题

• 怎么给一个 Agent 算一次任务的 token 账单？哪些部分是可以被缓存掉的？How do you compute the token bill for one agent task, and which parts can be cached away?

  国内高频海外高频深入#token-accounting#prompt-caching

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

  1. 这题的第一个坑在「一次任务」四个字。很多人报的是单次请求的输入量，那是称重不是账单——模型没有记忆，每一轮都要把前面全部重发，账单是整场会话每轮输入的累加值。
  2. 怎么拆：按四块各自的增长方式分别求和。稳定前缀（系统提示加工具定义）每轮原样重发，乘轮数；对话历史线性增长，是等差数列求和；工具结果阶梯增长，按调用次数与每次体积估。举个量级：一个 20 轮的客服任务，最后一轮单次输入 11256，整场累加是 133502，差了将近 12 倍。
  3. 再谈缓存。可缓存的是稳定前缀这一段，顺序是工具定义、系统提示、消息，改前面的会让后面全部失效。经济学是写入约 1.25 倍原价（一小时存活期约 2 倍）、命中约 0.1 倍，所以 20 轮的前缀从 20 次全价变成一次写入加十九次命中，能便宜八成以上。
  4. 结论要带上那条门槛：前缀必须达到模型的最小可缓存长度才生效，达不到既不报错也不告警。这直接导致一个反直觉现象——把系统提示精简掉一半，token 数降了，账单反而可能涨，因为前缀掉到门槛以下、缓存静默失效。
  5. 可预期的追问：那还该不该精简？该，但要同时报两个数——不含缓存的 token 降幅与含缓存的等效开销降幅，并检查前缀有没有跨过门槛。跨过了就把稳定的引用内容放回前缀抬回去，或者换一个门槛更低的模型。

  How to reason about it · think before answering

  1. The first trap is the phrase one task. Many people quote a single request's input size, which is a weight reading, not a bill. Stateless models resend everything each turn, so the bill is the sum of every turn's input.
  2. Sum the four buckets by their growth patterns. The stable prefix (system prompt plus tool definitions) is resent verbatim, so multiply by turn count. History grows linearly, so it is an arithmetic series. Tool results grow in steps, so estimate calls times size. For scale: a twenty-turn support task whose final request is 11256 tokens totals 133502 across the session, nearly twelve times larger.
  3. Then caching. The cacheable part is the stable prefix, ordered tools, system, messages, where editing anything earlier invalidates everything after. Writes cost about 1.25 times base (about 2 times for a one-hour lifetime) and hits about 0.1 times, so twenty full-price prefixes become one write plus nineteen hits, an eighty percent saving.
  4. State the threshold: the prefix must reach the model's minimum cacheable length or caching silently does nothing. That produces the counterintuitive result where halving your system prompt lowers token count but raises the bill, because the prefix fell below the threshold.
  5. Expect the follow-up on whether to trim anyway. Yes, but report two numbers: the raw token reduction and the cache-adjusted effective reduction, and check whether the prefix crossed the threshold. If it did, add stable reference content back into the prefix or move to a model with a lower threshold.

  答题要点

  • 账单是整场会话每轮输入的累加值，不是最后一次请求的输入量。
  • 按四块的增长方式分别求和：前缀乘轮数、历史等差求和、工具结果按调用次数估。
  • 可缓存的是稳定前缀，顺序是工具定义、系统提示、消息，改前面会让后面全失效。
  • 写入约 1.25 倍、命中约 0.1 倍；但前缀必须达到最小可缓存长度，否则静默失效。
  • 所以精简可能让 token 降而账单涨，必须同时报含缓存与不含缓存两个口径。

  Key points

  • The bill is the sum of every turn's input across the session, not the last request's size.
  • Sum by growth pattern: prefix times turns, history as an arithmetic series, tool results by call count.
  • The cacheable part is the stable prefix ordered tools, system, messages; editing earlier segments invalidates later ones.
  • Writes cost about 1.25 times base and hits about 0.1 times, but only above the model's minimum cacheable length, which fails silently.
  • So trimming can lower tokens while raising cost; always report both cached and uncached figures.
• 上下文出问题的时候，你怎么定位是四块里的哪一块？When context is the problem, how do you localize which of the four buckets is at fault?

  国内高频海外高频进阶#diagnostics#metrics

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

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

  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.

  答题要点

  • 两个指标：窗口占用率管会不会撑爆，有效信息占比管值不值，后者可用裁剪器近似量。
  • 四种模式各有指纹：塞太满看占用率、找不到看有效信息占比、说不清看错误率、越走越偏看压缩后的保留检查。
  • 找不到最容易被误判成模型能力问题，判据是把上下文打印出来人肉搜一遍。
  • 说不清多半是规则互相矛盾或工具职责重叠，去搜矛盾比换模型有用。

  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?

  国内高频海外高频进阶#tuning#stopping-criteria

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

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

  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.

  答题要点

  • 过度优化的代价不报错，只在正确率上体现：裁掉后面才用的字段、压掉不像结论的硬性要求、工具少到做不完任务。
  • 三条停手判据：有效信息占比稳定且无上升空间、最长用例的单轮占用率不超过 50%、最近一次改动账单降幅低于 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.