Interview Bank

Mastering Codex and the OpenAI Agents SDK in 5 Days

D2 Codex, Level Up: Cloud Tasks, Code Review, MCP Integration, Custom Instructions, IDE Integration

• If the same model both writes and reviews code, is the review still meaningful? How do you make it more independent?让同一个模型既写代码又审代码，审查还有意义吗？怎么让审查更独立？

  Common in ChinaCommon overseasIntermediate#code-review#coding-agent#workflow

  How to reason about it · think before answering

  1. The crux is 'still meaningful'; a flat yes or no fails. Explain what it catches and what it misses.
  2. What it catches: the input changes (diff instead of requirements) and the stance changes (find faults instead of finish the job), which surfaces missed edge cases, unsynced callers and style violations.
  3. What it misses: reviewer and author share one understanding of the requirement, so a misread requirement passes; they share blind spots too.
  4. Conclude with three independence levers: review with a different vendor's model, feed the reviewer different information (original requirement plus acceptance criteria, not just the diff), and run deterministic checks first.
  5. Expect the follow-up: auto-apply review comments? No; review is input, not verdict, and both false positives and misses exist.

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

  1. 题眼在「还有意义吗」——直接答「没意义」或「有意义」都不及格，要说清它能抓什么、抓不到什么。
  2. 先说能抓的：审查时输入变了（看 diff 而不是需求）、立场变了（找问题而不是完成任务），这种角色切换能抓出漏掉的边界情况、没同步的调用方、明显的风格违规。
  3. 再说抓不到的：审查者和生成者共享同一份对需求的理解，需求理解错了两边一起错；也共享同样的盲区与偏好。
  4. 结论给三条提高独立性的手段：换一家模型审、给审查者不同的信息（需求原文加验收标准而不是只给 diff）、用确定性工具（测试、lint、类型检查）做第一道审查。
  5. 可预期的追问：审查意见要不要自动应用？不要，审查是输入不是判决，误报与漏报都存在，最终判断留给人。

  Key points

  • Yes: the switch of input and stance catches edge cases, unsynced callers and style issues
  • It misses requirement misreads because author and reviewer share one understanding
  • Increase independence: a different vendor's model, richer reviewer context, deterministic checks first
  • Treat comments as input, never auto-apply

  答题要点

  • 有意义：输入与立场的切换能抓出边界情况、未同步的调用方、风格违规
  • 抓不到与需求理解相关的错误，因为审查者与生成者共享同一份理解
  • 提高独立性：换一家模型审、给审查者需求原文与验收标准、先跑确定性检查
  • 审查意见是输入不是判决，不要自动应用

D5 Choosing and Combining Claude and Codex: A Real Side-by-Side on the Same Task, a Write-One-Review-One Mixed Workflow

• Where does the 'one vendor writes, the other reviews' workflow pay off, and when is it not worth it?「一家写、另一家审」的混用工作流收益在哪？什么情况下不值得？

  Common in ChinaCommon overseasIntermediate#code-review#workflow#coding-agent

  How to reason about it · think before answering

  1. The crux is 'not worth it'; listing benefits without costs reads as never having sat in front of a budget.
  2. Source of value: when one model both writes and reviews, they share one reading of the requirement, so misreads slip through; a second vendor catches exactly those, plus complementary blind spots.
  3. How to make it pay: the reviewer needs the original requirement and acceptance criteria, not just the diff, or it degrades into lint; demand structured output so acceptance can be measured; a human makes the final call.
  4. Not worth it when the task is smaller than the review, when only one vendor's quota exists and the extra bill outweighs extra findings, or when nobody reads review comments carefully.
  5. Most worth it when a change touches many callers, the requirement is ambiguous, or the change ships to production; one caught misread pays for it.
  6. Expect the follow-up: can it be automated? Both vendors have headless modes so writing and reviewing can be scripted, but the human adjudication step cannot be removed.

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

  1. 题眼在「不值得」。只讲收益不讲代价，是没在预算表前坐过的人的答法。
  2. 先说收益的来源：同一家模型写与审共享同一份对需求的理解，需求理解偏差抓不出来；换一家审，最大的增量正是这类偏差，其次是不同模型的盲区互补。
  3. 再说怎么做才有收益：审查方必须拿到需求原文与验收标准而不只是 diff，否则退化成 lint；必须要求结构化输出，否则无法统计采纳率；最后一步必须由人裁决。
  4. 不值得的三种情况：任务小到审查成本高于任务本身；团队只有一家的额度，跨家意味着双份账单且多抓出的问题不值这笔钱；审查意见没人认真看，多一家只是多一层噪音。
  5. 最值的三种情况：改动影响多个调用方、需求本身有歧义、改动要上生产——抓出一个理解偏差就回本。
  6. 可预期的追问：能不能自动化？两家都有脱手模式，写与审都能脚本化，但「人裁决」这一步不能省，否则前两步就是浪费。

  Key points

  • Value comes from an independent reading of the requirement, catching misreads a same-vendor review misses
  • The reviewer needs the requirement and acceptance criteria, must output structured findings, and a human adjudicates
  • Not worth it for tiny tasks, single-vendor budgets, or teams that do not read reviews
  • Most valuable for multi-caller changes, ambiguous requirements and production deploys

  答题要点

  • 收益来自独立的需求理解：换一家审能抓出同家审查抓不到的理解偏差
  • 审查方要拿到需求原文与验收标准、输出结构化意见，最后由人裁决
  • 不值得：任务太小、只有一家额度、没人认真看意见
  • 最值：影响多个调用方、需求有歧义、要上生产