面试题库

Claude 高效使用：从对话到 Claude Code

D2 长文档、多模态与 API 初见：大上下文怎么用、prompt caching 省钱、PDF 与图片输入、带引用回答；Messages API 最小调用

• 为什么说上下文窗口是 LLM 应用里最稀缺的资源？窗口已经有一百万 token 了，这个说法还成立吗？Why is the context window called the scarcest resource in LLM applications? With million-token windows, does that still hold?

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

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

  1. 题眼在第二句。只答「窗口有上限」已经过时了，面试官想听的是「窗口变大之后为什么还稀缺」。
  2. 从三条因果链推：一、模型无状态，每次请求都把全部输入重读一遍，输入 token 按次计费——窗口大只解决了放得下，没解决每次都要重搬；二、上下文越长，延迟越高、注意力越稀释，模型对早期指令的遵守度会下降，也就是「性能随填充度下降」；三、Agent 场景里每读一个文件、每跑一条命令的输出都进同一个窗口，填得比聊天快得多。
  3. 结论：窗口大了，稀缺性从「放不下」变成了「每一 token 都在花钱和稀释注意力」，所以管理手段变成了主动管：只放必要的、把不变的缓存起来、把查资料的活派给独立上下文的子代理、该清就清。
  4. 生产视角：算一笔账——60 页 PDF 约 10 万 token，围着它问 10 个问题就是 100 万输入 token；不用缓存和不用缓存的差价是一个量级。
  5. 可预期的追问：那什么时候应该让上下文积累？在一个复杂问题里深挖时历史是有价值的；判据是「这段历史下一步还会不会用到」。

  How to reason about it · think before answering

  1. The second sentence is the point. 'The window has a limit' is a dated answer; explain why scarcity survives large windows.
  2. Three causal chains: models are stateless so every request re-reads the whole input and bills it, a big window only solves fitting, not re-sending; longer context means more latency and diluted attention, so adherence to early instructions degrades as the window fills; and in agent workflows every file read and command output lands in the same window, filling it far faster than chat does.
  3. Conclusion: scarcity shifted from 'won't fit' to 'every token costs money and attention', so the discipline becomes active management — include only what is needed, cache the stable prefix, delegate research to subagents with their own context, and clear between tasks.
  4. Production math: a 60-page PDF is roughly 100k tokens; ten questions about it are a million input tokens; caching versus not caching is an order of magnitude apart.
  5. Follow-up: when should context accumulate? While deep in one complex problem where the history is still load-bearing; the test is whether the next step will use it.

  答题要点

  • 模型无状态，每次请求重读全部输入并计费；窗口大只解决放得下，不解决每次重搬
  • 上下文越长延迟越高、注意力越稀释，早期指令遵守度下降
  • Agent 场景每次读文件、跑命令的输出都进窗口，填得比聊天快得多
  • 对策：只放必要的、缓存不变前缀、用子代理隔离查资料、任务之间清空

  Key points

  • Models are stateless: every request re-reads and bills the full input; a large window solves fitting, not re-sending
  • Longer context raises latency and dilutes attention; adherence to early instructions drops
  • Agent workflows dump every file read and command output into the same window
  • Tactics: include only what's needed, cache the stable prefix, isolate research in subagents, clear between tasks

D3 Claude Code 入门与上下文管理：安装、CLAUDE.md 写法与「删到不能再删」、权限模式、Plan Mode「先探索再计划再写」、/clear /compact /rewind、给 Claude 一个可验证的检查

• 在 Claude Code 里为什么上下文窗口需要主动管理？/clear、/compact、/rewind 分别在什么时候用？Why does the context window need active management in Claude Code, and when do you use /clear, /compact, and /rewind respectively?

  国内高频海外高频进阶#context-window#claude-code

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

  1. 题眼是「主动」。被动等自动压缩也能用，面试官想知道你是否理解「窗口填满之前性能就已经在下降」。
  2. 先说为什么：Claude Code 读的每个文件、跑的每条命令输出、每轮对话都进同一个窗口，一次调试就是几万 token；窗口越满模型越容易忘掉早先的指令、越容易出错，所以不是满了才处理，而是从一开始就控制进什么。
  3. 再分三个命令，判据是「这段历史还有没有用」：任务切换且历史无用——/clear 清零；任务未完但窗口快满、历史有用——/compact 压缩成摘要，可带指令指定保留什么；走错了方向、想回到某个点——/rewind（Esc Esc）恢复对话或代码到检查点，也能只对某一段做摘要。
  4. 补两条经验规则：同一问题纠正两次还不对就 /clear 重开，失败的尝试留在窗口里只会继续污染；旁枝问题用 /btw，答案不进历史；查资料派给 subagent，让它在自己的窗口里翻。
  5. 可预期的追问：什么时候应该让上下文积累？深挖一个复杂问题、历史仍在被引用时；判据是下一步还会不会用到这段历史。再追问 rewind 的边界：只追踪 Claude 用编辑工具做的改动，Bash 改的文件不在其中，不替代 git。

  How to reason about it · think before answering

  1. The keyword is active. Waiting for auto-compaction works, but the interviewer wants to hear that performance degrades before the window is full.
  2. Why: every file read, command output, and turn lands in one window; a single debugging pass can be tens of thousands of tokens; as it fills the model forgets earlier instructions and errs more, so the discipline is controlling what enters from the start.
  3. Then the three commands, keyed on whether the history is still useful: switching tasks with useless history — /clear; mid-task with useful history but a filling window — /compact, optionally with instructions on what to keep; wrong direction — /rewind (Esc Esc) to restore conversation or code to a checkpoint, or summarize just one span.
  4. Two rules of thumb: after two failed corrections, /clear and rewrite the prompt — failed attempts keep polluting; use /btw for side questions that shouldn't enter history; delegate research to a subagent with its own window.
  5. Follow-ups: when should context accumulate? While deep in one problem where history is still referenced. Limits of rewind: it tracks only edits made through Claude's editing tools, not Bash-driven changes, and is no substitute for git.

  答题要点

  • 所有文件读取、命令输出、对话都进同一窗口；越满越容易忘指令、出错，要从一开始控制
  • /clear：切换任务、历史无用时清零；两次纠正无效也清
  • /compact：任务未完、历史有用但窗口快满；可带指令指定保留内容
  • /rewind：回到检查点恢复对话或代码，或只对一段做摘要；不替代 git

  Key points

  • Every read, output, and turn shares one window; fullness degrades adherence, so control inputs from the start
  • /clear between unrelated tasks or after two failed corrections
  • /compact mid-task when history matters but space runs low; pass instructions on what to keep
  • /rewind to a checkpoint for conversation or code, or summarize a span; not a git replacement

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.