面试题库

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

D4 扩展 Claude Code：hooks（确定性）vs CLAUDE.md（建议性）、skills、subagents、plugins、接 MCP server、CLI 工具优先

• subagent 解决了什么问题？它看得到主会话的历史吗？什么时候不该用？What problem do subagents solve? Do they see the main conversation's history? When should you not use one?

  国内高频海外高频进阶#subagents#context

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

  1. 题眼是「解决了什么问题」——答案是保护主会话的上下文窗口，而不是「并行」或「专业化」这些附带好处。第二问是常见误区，第三问考边界感。
  2. 推导：查资料、审代码这类任务的特征是「读很多、留很少」——读三十个文件只为一段结论。放在主会话里做，三十个文件全进窗口，真正的实现反而没地方放。subagent 拥有独立的上下文窗口，读完只把总结带回来，主会话只付总结的成本。
  3. 第二问：看不到。subagent 起步时只有系统提示、你派给它的任务描述、CLAUDE.md、git 状态快照；主会话的历史、你之前读过的文件、之前加载的 skill 都不在。这是限制也是优点：一个没有「刚写完这段代码」记忆的审查者更容易挑出毛病，D5 的对抗式审查就靠这个性质。
  4. 配置：.claude/agents/<name>.md，frontmatter 的 tools 限定它能用什么（审查者不给 Edit）、model 可以配更便宜或更强的模型；内置的 Explore 只读、Plan 用于计划模式、general-purpose 全能。
  5. 不该用的场景：需要多轮来回讨论的活（每次派出去都要重新交代）、几个阶段要共享大量上下文的活、一句话就能改完的活（交代 + 总结的开销大于任务本身）。可预期的追问：subagent 与 /compact 的关系——一个是不让东西进窗口，一个是进了以后压缩，前者更省。

  How to reason about it · think before answering

  1. The key is the problem solved: protecting the main conversation's context window, not the side benefits of parallelism or specialization. The second part is a common misconception; the third tests judgment.
  2. Chain: research and review tasks read a lot and keep little — thirty files for one conclusion. Done in the main session, all thirty land in the window and crowd out the actual implementation. A subagent has its own context window, reads everything, and returns only a summary; the main session pays only for the summary.
  3. Second part: no. A subagent starts with the system prompt, the task you delegated, CLAUDE.md, and a git status snapshot — not the main history, your earlier file reads, or previously loaded skills. That is both a limit and a strength: a reviewer without the memory of having just written the code finds more faults, which is what adversarial review in D5 relies on.
  4. Configuration: .claude/agents/<name>.md with tools restricting what it may use (no Edit for a reviewer) and model to pick a cheaper or stronger model; built-ins are Explore (read-only), Plan (plan mode research), and general-purpose.
  5. When not to: tasks needing multi-turn back-and-forth (every dispatch re-explains), phases that share heavy context, and one-line fixes where dispatch plus summary costs more than the work. Follow-up: subagent versus /compact — one keeps content out of the window, the other compresses it afterward; the former is cheaper.

  答题要点

  • 解决的是主会话上下文被「读很多留很少」的任务撑满；subagent 独立窗口，只带回总结
  • 看不到主会话历史，只有任务描述、CLAUDE.md、git 快照；因此审查更客观
  • tools 限定权限、model 选模型；内置 Explore / Plan / general-purpose
  • 不该用：多轮讨论、多阶段共享上下文、一句话能改完的小活

  Key points

  • Solves the main window being flooded by read-heavy, keep-little tasks; a subagent has its own window and returns a summary
  • It does not see the main history — only the task, CLAUDE.md, and a git snapshot — which makes its review more objective
  • tools restricts permissions, model picks the model; built-ins are Explore, Plan, general-purpose
  • Avoid for multi-turn discussion, heavy shared context across phases, and one-line fixes

D5 自动化与规模化：headless -p 进 CI、并行会话与 worktree、Writer / Reviewer 双会话、对抗式审查、常见失败模式；Agent SDK 20 行最小 agent

• 为什么 Writer / Reviewer 双会话的审查比同一个会话自查更有效？审查者报出来的问题要全改吗？Why is a Writer / Reviewer two-session review more effective than self-review in one session, and should you fix everything the reviewer reports?

  国内高频海外高频进阶#review#subagents

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

  1. 题眼是「为什么」和后半句。答「多一双眼睛」是常识；要说清上下文在这里扮演的角色，以及审查的副作用。
  2. 推导：写完实现的会话，上下文里装满了「我为什么这么写」的推理；让它自审，它倾向于确认而不是质疑——这不是态度问题，是上下文偏置。Reviewer 换一个全新的上下文，只看到 diff 和你给的标准，不知道 Writer 的理由，所以挑的是代码本身的毛病。这和人类 code review 要求「非作者审」是同一个道理。
  3. 形态有三种：两个终端手动传递输出；一个 subagent 做对抗式审查（独立上下文天然就是无记忆的审查者，而且结果直接回到主会话可以立刻修）；内置的 /code-review 在新 subagent 里审当前 diff。同样的思路可以反过来用：一个会话写测试，另一个写实现去通过。
  4. 后半句是区分度：不要全改。被要求找问题的审查者一定会报出问题来，哪怕代码没毛病；照单全收会导致过度工程——多余抽象、防御不存在情况的代码、测不可能发生的用例。审查提示词里要写「只报告影响正确性或明确需求的差距，其余视为可选」，最终由人判断。
  5. 可预期的追问：Reviewer 需要什么输入？diff、计划或需求（PLAN.md）、明确的判据；给它 Writer 的推理过程反而会削弱独立性。再追问「能不能自动化」——能，-p 模式里一条命令跑 Reviewer，结果贴回 PR。

  How to reason about it · think before answering

  1. The point is the why and the second half. 'A second pair of eyes' is common sense; explain the role of context and the side effect of review.
  2. Chain: the session that wrote the code has a context full of its own reasoning; asked to review, it tends to confirm rather than challenge — a context bias, not an attitude problem. A Reviewer in a fresh context sees only the diff and your criteria, not the Writer's reasons, so it critiques the code itself. Same principle as non-author code review among humans.
  3. Three shapes: two terminals passing output by hand; a subagent doing adversarial review (its isolated context is the memoryless reviewer, and findings land back in the main session for immediate fixing); the built-in /code-review that reviews the current diff in a fresh subagent. The idea also inverts: one session writes tests, another writes the implementation to pass them.
  4. The second half separates candidates: don't fix everything. A reviewer told to find gaps will report some even in sound code; accepting all of it leads to over-engineering — extra abstraction, defensive code for impossible cases, tests for unreachable paths. Tell it to flag only gaps affecting correctness or stated requirements, and let a human decide.
  5. Follow-ups: what does the Reviewer need? The diff, the plan or requirements, explicit criteria; feeding it the Writer's reasoning weakens independence. Can it be automated? Yes — run the Reviewer via -p and post results to the PR.

  答题要点

  • 自审受上下文偏置：装满自己推理的会话倾向于确认而非质疑
  • Reviewer 用全新上下文，只看 diff 与判据，挑的是代码本身的毛病
  • 形态：双终端、subagent 对抗式审查、内置 /code-review；反向可用于测试先行
  • 不要全改：审查者必报问题，照单全收导致过度工程；限定只报影响正确性的差距

  Key points

  • Self-review suffers context bias: a session full of its own reasoning confirms rather than challenges
  • A Reviewer in a fresh context sees only the diff and criteria, so it critiques the code itself
  • Shapes: two terminals, an adversarial subagent, built-in /code-review; invert for test-first
  • Don't fix everything: reviewers always report something; limit findings to correctness and stated requirements