Interview Bank

Mastering Claude: From Conversation to Claude Code in 5 Days

D5 Automation and Scale: Headless -p Into CI, Parallel Sessions and Worktrees, Writer/Reviewer Dual Sessions, Adversarial Review, Common Failure Modes; a 20-Line Minimal Agent SDK Agent

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

  Common in ChinaCommon overseasIntermediate#review#subagents

  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.

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

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

  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

  答题要点

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