Scenario 5 · 主考 Domain 3 / 4
S5 · Claude Code for CI
自动 code review、测试生成、PR 反馈
官方设定：把 Claude Code 接进 CI/CD 流水线，系统跑自动化 code review、生成测试用例、给 pull request 反馈；需要设计出可执行的反馈并最小化 false positives。 官方样题里有三道（Q10、Q11、Q12）出自这里，且 Q10 是全卷唯一一道纯记忆题。
设定里的两个目标是一对张力 — 「actionable feedback」要求报得够细，「minimize false positives」要求报得够准。这个场景的题基本都在这条张力线上：怎么在不牺牲召回的前提下提精度。答案几乎总在显式准则与输入结构上，不在「让它更保守」上。
一、从零设计：CI 里的 Claude Code
第一步：让它别挂住
claude -p "Review the diff for security issues" ✔ 真实存在 · 非交互，处理完输出到 stdout 并退出
claude --print "…" ✔ 真实存在 · -p 的长写法
claude -p "…" --output-format json --json-schema f.json ✔ 真实存在 · 结构化 findings，可直接发 inline PR comment
claude --batch "…" ✘ 不存在 · 官方样题 Q10 的 D 选项
CLAUDE_HEADLESS=true claude "…" ✘ 不存在 · 官方样题 Q10 的 B 选项官方样题 Q10 的场景就是不加 -p 导致 job 无限期挂起等待交互输入。除了两个捏造物，还有一个 C 选项值得记住：< /dev/null 重定向 stdin——官方解析把它归为「不能正确处理 Claude Code 命令语法的 Unix workaround」。shell 技巧输给产品自带的 flag，这条规律在考场上很好用。
第二步：让它知道项目的规矩
CI 里没人坐在旁边补充信息，Claude Code 知道的一切都来自仓库。CLAUDE.md 是给 CI 提供项目上下文的机制：testing standards、fixture conventions、review criteria、以及「什么样的测试算有价值」。
第三步：让它别当自己的裁判
生成代码的那个 session 不适合审查自己的改动——它保留着生成时的推理惯性。用独立的 review 实例。
二、上线：四次踩坑
① 输出解析每周坏一次
用正则从散文里抠 file:line，措辞一变就崩。正解是 --output-format json + --json-schema——把结构化的约束交给机制，而不是靠 prompt 措辞约定格式。
② 同样的三条评论贴了六遍
每次 push 都重跑，每次都重新发现同样的问题。正解：重跑时把既往 findings 放进上下文，指示 Claude 只报新增或仍未解决的问题。 注意它同时保留了「仍未解决」的可见性——直接跳过已报过的问题会让真 bug 悄悄消失。
③ 生成的测试六成被丢弃
重复已有覆盖、自造 fixture、断言 trivial getter。三个症状对应两条 skill：把已有测试文件放进上下文（防重复场景），把测试标准/fixture 约定/什么算有价值写进 CLAUDE.md（防自造与低价值）。
④ 14 个文件一遍审，结论自相矛盾
官方样题 Q12：单遍审查 14 个文件，结果深浅不一、漏掉明显 bug、同一模式在一个文件被标问题在另一个被放行。正解是拆成逐文件 local pass + 单独的 cross-file integration pass。三个错法：要求开发者拆小 PR（把负担转嫁给开发者而不改进系统）、换更大 context window 的模型（更大的窗口不解决注意力质量）、跑三遍取至少两遍都报的（反而会压掉只被间歇性发现的真 bug）。
三、成本：什么能进 batch
官方样题 Q11：两个负载——阻塞的 pre-merge check（开发者等着合并）与过夜生成的技术债报告。正解是只把技术债报告转 Batches API，pre-merge 保持实时。
四个选项覆盖了这条轴的四个位置，三个错法各有其名：全转 batch + 轮询（依赖「往往更快」对阻塞流程不可接受）、全留同步（理由是「batch 结果顺序会乱」——这是误解，custom_id 就是用来关联请求与响应的）、全转 batch + 超时回退实时（在「各配各的」这个更简单的方案存在时引入不必要的复杂度）。
还有一条能力边界要记住：batch 不支持单个请求内的 multi-turn tool calling。 一个需要「调工具 → 看结果 → 再决定」的 agentic review 流程不能整段塞进一次 batch 请求——延迟容忍只是必要条件，不是充分条件。
四、精度：怎么把 false positive 压下去
- 显式分类准则取代模糊指令：写清楚报什么（bugs、security）、跳什么（minor style、本仓库的局部惯例），而不是 "be conservative"。
- 每个 severity 级别配具体代码示例，让分类有可对照的锚点。
- few-shot 区分可接受写法与真问题，在降误报的同时保留泛化能力。
- 临时禁用高误报类别先救回信任，同时离线改进那些类别的 prompt——因为高误报类别会拖垮准确类别的可信度。
detected_pattern字段记录是哪类代码构造触发了发现，让 dismissal 可以按 pattern 聚合分析。
五、坑位地图
| 决策点 | 正确直觉 | 常见干扰项工艺 |
|---|---|---|
| 1. CI job 挂起 | -p / --print | D1 CLAUDE_HEADLESS、--batch；D3 < /dev/null |
| 2. 输出难解析 | --output-format json + --json-schema | D6 用 prompt 约定格式；D3 加固正则 |
| 3. 重复评论 | 重跑带上既往 findings，只报新增/未解决 | D5 只审首次 push；D3 CI 侧哈希去重 |
| 4. 低价值测试 | 给已有测试文件 + CLAUDE.md 写测试标准与 fixture 约定 | D3「只生成高价值测试」；D2 加一道过滤实例 |
| 5. 大 PR 结论矛盾 | per-file pass + 单独 integration pass | D4 要求开发者拆 PR；D3 换大 context window；D2 三跑取交集 |
| 6. 自审太宽松 | 独立 review 实例 | D6「请怀疑自己」；D3 开 extended thinking |
| 7. 成本优化 | 只把非阻塞的过夜作业转 batch | D6「通常一小时内完成」；D2 超时回退；D1「batch 顺序会乱」 |
| 8. 误报率高 | 显式分类准则 + severity 代码示例 + few-shot | D3 "be conservative"；D6 自报 confidence 过滤 |
外部课程 · CertSafari — 本章 7 个考点（展开查看）
用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。
- TS 3.5 · Examples, Tests First and the Interview Pattern
- TS 3.6 · Headless Claude Code in CI: -p, Tool Permissions and JSON Output
- TS 4.1 · Explicit Review Criteria vs Vague Instructions in Claude Prompts
- TS 4.2 · Few-Shot Prompting for Consistent Output Format
- TS 4.4 · Retry with Error Feedback in Extraction Pipelines
- TS 4.5 · Message Batches API: When to Batch and When to Stay Synchronous
- TS 4.6 · Independent Review Instances vs Self-Review
考点回链 — 本场景覆盖：TS 3.5、TS 3.6、TS 4.1、TS 4.2、TS 4.4、TS 4.5、TS 4.6。官方样题精讲：Q10（
-p flag）、Q11（仅过夜任务转 batch）、Q12（per-file + integration pass）。场景题组
ch19 · Q1 · 准则 P1
Your CI job invokes
claude "List the migrations touched by this branch" and never finishes; it consumes the full job timeout every run, with no output after startup. What is the correct fix?正确 CTS 3.6 与官方样题 Q10：
-p / --print 是在自动化流水线中以非交互模式运行 Claude Code 的既定方式——处理 prompt、输出到 stdout、退出，正是 CI 需要的语义。D1 凭空捏造违反 P1A：
--batch flag 不存在（官方样题 Q10 的 D 选项）。它容易与 Message Batches API 混淆，但那是 API 侧机制，不是 CLI flag。D1 凭空捏造违反 P1B：
CLAUDE_HEADLESS 环境变量不存在（官方样题 Q10 的 B 选项）。名字「顺理成章」正是 D1 的识别信号。D3 治标不治本违反 P2D：官方解析把它归为「不能正确处理 Claude Code 命令语法的 Unix workaround」——可能让进程不再阻塞，但绕开了产品自带、语义正确的机制。
ch19 · Q2 · 准则 P7
Your nightly review covers a service split across 20+ modules. Findings arrive at wildly uneven depth, and reviewers note that the reviewer never flags problems that only show up where two modules interact — a caller that assumes a nullable return, a retry that duplicates a non-idempotent write. Per-module findings themselves are reasonable. How should you restructure the review?
正确 ATS 4.6 / TS 1.6：局部问题与跨文件数据流是两类关注点，需要两类 pass。题干把它说得很清楚——单模块发现本身是合理的，缺的是从来没有人专门看接口。
D6 概率当保证违反 P7B：在同一遍里追加一句「也想想模块间的交互」，等于要求模型在已经稀释的注意力里再开一条战线；集成视角需要独立的一遍，而不是一句附加指令。
D3 治标不治本违反 P7C：预算不是瓶颈。把更多模块塞进同一遍，只会让注意力更稀释——深浅不一这个症状正是它造成的。
D5 吞错或炸链违反 P6D：只深审三分之一，等于主动放弃其余模块的覆盖；而跨模块缺陷恰恰常常一端在「低风险」模块里。
ch19 · Q3 · 准则 P5
Your platform runs Claude in two places: a lint-and-explain step that runs while a developer waits on the PR page, and a monthly license-compliance sweep over every dependency manifest in the org, read by legal the following week. Procurement asks you to cut the spend without slowing developers down. What do you propose?
正确 DTS 4.5 与官方样题 Q11：batch 提供 50% 成本节省但处理窗口最长 24 小时且无 latency SLA——不适合开发者在 PR 页面等着结果的 lint-and-explain 步骤，适合月度 license-compliance 扫描这类「下周才被法务读到」的延迟容忍作业。
D6 概率当保证违反 P5A：把无 SLA 的经验分布当保证。官方解析原判：依赖「往往更快」对阻塞流程不可接受。
D1 凭空捏造违反 P1B：理由是错的——batch 结果可通过
custom_id 精确关联请求与响应。官方样题 Q11 的 C 选项被点名的正是这个误解。D2 过度工程违反 P5C：在「各配各的」这个更简单的方案存在时引入混合回退；而且需要为阻塞流程兜底本身就说明 batch 不适合它。
ch19 · Q4 · 准则 P8
Your reviewer reports "possibly unused variable" on 31 of 40 PRs; sampling shows 27 are variables intentionally retained for a documented debugging pattern in this codebase. Developers have started ignoring the bot entirely, including its security findings. What should you do?
正确 ATS 4.1 的两条合用：高误报类别会拖垮准确类别的可信度（题干的「连 security 一起无视」正是这个现象），官方给的动作就是临时禁用高误报类别以恢复信任、同时改进其 prompt；TS 4.2 补上 few-shot 区分可接受写法与真问题。
D3 治标不治本违反 P8B：TS 4.1 直接点名 "be conservative" / "only report high-confidence findings" 这类通用指令无法像具体分类准则那样提升 precision。它没给模型任何新判据。
D4 甩锅错位违反 P8C：把判断负担转回给已经失去耐心的开发者，且要求他们每条做统计推理。信任是被噪音总量摧毁的，加元数据不减少噪音。
D6 概率当保证违反 P8D：未校准的自报 confidence 不可作过滤依据——模型恰恰会在判错的地方自信。TS 4.1 明确要求写具体准则而不是依赖 confidence-based filtering。
ch19 · Q5 · 准则 P5
Your CI posts review results by grepping Claude's prose output for lines beginning "FINDING:" and parsing file paths and line numbers with a regex. It breaks roughly weekly when phrasing shifts. Findings must land as inline PR comments. What should change?
正确 CTS 3.6：
--output-format json 搭配 --json-schema 正是为「产出机器可解析的结构化 findings 以便自动发成 inline PR comment」设计的。需要机器解析就用结构化输出机制，不要在自然语言上做解析。D6 概率当保证违反 P3A：靠 prompt 约束输出格式是概率性合规，而 CI 解析要求确定性。题干已证明「每周坏一次」，现成的 schema 约束机制却没用。
D3 治标不治本违反 P1B：根因是「在自然语言上做结构化解析」，加固正则只把下次崩溃推后；fallback 把结构化评论降级成一坨原文，还损失了 inline 定位能力。
D2 过度工程违反 P2D：多花一次调用做一件 flag 免费提供的事，且第二次调用同样可能格式跑偏——不确定性被引入了两遍。
ch19 · Q6 · 准则 P1
On a PR with seven pushes, developers received the same four comments seven times each. The findings were valid the first time and remain unaddressed. What should you change?
正确 BTS 3.6 的原话级 skill：新 commit 后重跑 review 时把既往 findings 放进上下文，指示 Claude 只报新增或仍未解决的问题以避免重复评论。它同时保留了「仍未解决」的可见性——题干那四条确实还没修。
D5 吞错或炸链违反 P6A：只审首次推送等于放弃对后续全部改动的审查——为消除重复而关掉了这个步骤的主要价值。
D3 治标不治本违反 P1C：题干明说这些 findings 有效。问题是重复不是过多；收紧准则会误伤真实问题，把投递问题当成了精度问题。
D3 治标不治本违反 P1D：CI 侧去重能压住重复，但 Claude 每轮仍在无谓地重新发现同样的问题；措辞稍变哈希就不同，重复又会漏出来。它模拟了正解的效果却没把既往上下文交给模型。
ch19 · Q7 · 准则 P7
Your pipeline has Claude generate a service module, then asks the same session to review that code for defects before opening the PR. The review approves its own output almost every time; defects surface in QA. What is the most effective change?
正确 DTS 3.6 与 TS 4.6 说的是同一件事：同 session 保留生成时的推理上下文，模型不易质疑自己的决定；没有先验推理上下文的独立实例在抓细微问题上更有效。
D6 概率当保证违反 P8A：TS 4.6 明确指出独立实例优于 self-review 指令。「要怀疑自己」是模糊指令，改变不了推理惯性这个结构性因素。
D3 治标不治本违反 P7B：guide 把 extended thinking 与 self-review 指令并列，明说独立实例优于两者。想得更久不等于跳出自己的前提。
D2 过度工程违反 P7C：摘要步骤仍在同一 session 内，推理上下文没被真正切断；而且压缩会丢掉审查最需要的细节——为模拟「独立」损失了信息。
ch19 · Q8 · 准则 P1
Your CI test-generation step produces tests that duplicate scenarios the suite already covers, hand-roll fixtures instead of using the repo's shared factories, and assert trivial getters. Reviewers discard roughly 60%. What combination addresses this?
正确 BTS 3.6 的两条 skill 正好覆盖三个症状：把已有测试文件放进上下文（防重复场景）；把测试标准、fixture 约定与「什么样的测试有价值」写进 CLAUDE.md（防自造 fixture 与低价值测试）。CI 里的 Claude Code 只知道仓库告诉它的事。
D3 治标不治本违反 P8A：「只生成高价值测试」正是 TS 4.1 点名的模糊指令——模型并不知道这个仓库里什么算高价值，也看不到已有覆盖。缺的是信息，不是措辞强度。
D2 过度工程违反 P2C：加一道过滤把成本翻倍，而生成端仍在盲写——它治产出物不治「它不知道仓库有什么」这个根因。轻量手段（把上下文给够）尚未使用。
D3 治标不治本违反 P1D：覆盖率阈值能减少一部分重复场景，但对「自造 fixture」与「断言 trivial getter」毫无作用——低覆盖文件里照样能写出低价值测试。
ch19 · Q9 · 准则 P5
You plan to move your nightly review job to the Message Batches API. The job currently runs an agent that, per repository, calls a coverage tool, reads the result, then calls a static-analysis tool chosen based on that result, then writes a summary. What is the correct assessment?
正确 ATS 4.5 的硬性能力边界：batch API 不支持单个请求内的 multi-turn tool calling（无法在请求中途执行工具并把结果送回）。延迟容忍只是必要条件，工作流的形态也必须是「一次输入一次输出」。
D3 治标不治本违反 P5B：只检查了延迟维度就下结论。batch 的适配判断有两个维度，另一个是能力边界——这是本条最容易中的陷阱。
D1 凭空捏造违反 P5C：
custom_id 用于关联请求与响应，它不会让 batch 具备执行多轮工具调用的能力。给真实机制安上它没有的语义。D1 凭空捏造违反 P5D：
tool_choice: "any" 保证模型调用某个工具，它不负责执行工具、更不会把结果回灌进同一次请求。它管输出形态，不管运行时能力。