Interview Bank

Mastering Claude: From Conversation to Claude Code in 5 Days

D2 Long Documents, Multimodal Input, and a First Look at the API: Using Large Context, Saving Money With Prompt Caching, PDF and Image Input, Citation-Backed Answers; a Minimal Messages API Call

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

  Common in ChinaCommon overseasBasic#context-window#cost

  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.

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

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

  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

  答题要点

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

D3 Getting Started With Claude Code and Managing Context: Install, Writing CLAUDE.md and "Trim Until You Can't", Permission Modes, Plan Mode's "Explore, Then Plan, Then Write", /clear /compact /rewind, Giving Claude a Verifiable Check

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

  Common in ChinaCommon overseasIntermediate#context-window#claude-code

  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.

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

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

  答题要点

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