Chapter 07 · Domain 3（权重 20%）
CI/CD 集成与迭代精化
-p、--json-schema、test-driven iteration、interview pattern
本章是 Domain 3 里唯一有「精确到字符」记忆要求的一章——CLI flag 记错就直接丢分（官方样题 Q10 就是一道纯 flag 题，三个干扰项全是捏造物）。后半章的迭代精化则相反，全是判断题：什么时候给例子、什么时候写测试、什么时候一次性提所有问题。
一、CLI 速查与真伪栏
claude -p "Analyze this PR for security issues" ✔ 真实存在 · 非交互模式，防 CI 挂起等待输入
claude --print "…" ✔ 真实存在 · -p 的长写法
claude -p "…" --output-format json ✔ 真实存在 · 结构化输出，机器可解析
claude -p "…" --output-format json --json-schema s.json ✔ 真实存在 · 按 schema 约束 CI 输出
claude --batch "…" ✘ 不存在 · 官方样题 Q10 的 D 选项
CLAUDE_HEADLESS=true claude "…" ✘ 不存在 · 官方样题 Q10 的 B 选项-p 解决的具体问题：不加它，Claude Code 进入交互模式并等待用户输入——在 CI 里没有人来输入，job 就永久挂起。-p 让它处理完 prompt、把结果打到 stdout、然后退出。 官方样题 Q10 的 C 选项（< /dev/null 重定向 stdin）值得单独一提：它是个「Unix 老手的直觉」，但官方解析明确说它是绕过命令语法的 workaround，不是正确做法。考试里，「用 shell 技巧绕过」通常输给「用产品自带的 flag」。
--output-format json + --json-schema 解决的问题：CI 需要把结果程序化地变成 PR 上的 inline comment。散文输出要靠正则去抠，schema 约束的 JSON 直接可解析。这两个 flag 通常一起出现。
二、CI 里的 Claude Code 需要什么上下文
CI 调用的 Claude Code 没有人坐在旁边补充信息，它知道的一切都来自仓库。CLAUDE.md 就是给 CI 提供项目上下文的机制，guide 点名了三类内容：
| 写进 CLAUDE.md 的内容 | 不写会怎样 |
|---|---|
| testing standards（测试标准） | 生成的测试风格与仓库不符，reviewer 每次都要改 |
| fixture conventions（可用的 fixture 约定） | 重新造一遍已有的测试夹具，或者硬编码数据 |
| review criteria（review 准则） | 报一堆 minor style，淹没真正的 bug（见 ch08） |
| 「什么样的测试有价值」的判据 | 产出大量低价值测试（testing getters、断言常量） |
三条防重复的 skill
- re-run 时带上既往 findings——新 commit 触发重跑时，把上一轮的 findings 放进上下文，并指示 Claude只报新增或仍未解决的问题。不这么做，同一条意见会在 PR 上反复贴，开发者很快就会开始无视机器人。
- 生成测试时提供已有测试文件——否则会建议一堆测试套件里已经覆盖过的场景。
- 用独立实例 review，不要用生成代码的那个 session——同一个 session 保留着生成时的推理惯性，对自己的产物提不出质疑（TS 3.6 与 TS 4.6 从两个角度说了同一件事，详见 ch10）。
三、迭代精化的四个手段
当 Claude 的输出「不太对但说不清哪不对」，TS 3.5 给了四个手段。它们不是并列可选，而是各有触发条件：
| 手段 | 触发条件 | 形态 |
|---|---|---|
| 具体 I/O 示例 | 散文描述被反复不一致地理解 | 2–3 个具体的输入/输出示例，胜过再写三段说明 |
| Test-driven iteration | 需求可以用测试表达（含边界与性能要求） | 先写测试套件 → 跑 → 把失败结果分享给 Claude → 迭代改进 |
| Interview pattern | 你自己对这个领域不熟，不知道该问什么 | 让 Claude 先向你提问，暴露你没预料到的设计考量（缓存失效策略、失败模式） |
| 一次性 vs 顺序修复 | 看问题之间是否相互作用 | 相互作用的问题一次性在同一条消息里给全；独立的问题顺序修 |
最后一条的逻辑值得说破：如果三个问题的修复会互相影响（改了 A 的方案会决定 B 怎么修），分三次说会让前两次的修复被第三次推翻——白做两轮。反过来，三个独立问题一次性丢过去，只会稀释注意力（P7）。判据是耦合性，不是数量。
Test-driven iteration 在 CI 场景里有一个额外好处：测试套件本身就是「review criteria 的可执行版本」。团队常见的做法是把「什么样的测试有价值」写进 CLAUDE.md，把「代码必须满足什么」写成测试——前者约束生成、后者验证生成。Exam Guide 分别在 TS 3.5 与 TS 3.6 里提到这两侧，但没有把它们合并成一条方法论，所以考试不会考这个组合本身。
外部课程 · CertSafari — 本章 2 个考点（展开查看）
用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。
考点回链 — 本章覆盖：TS 3.6（
-p/--print 非交互、--output-format json 与 --json-schema、CLAUDE.md 供给 CI 上下文、带既往 findings 防重复评论、提供已有测试防重复用例、同 session 自审弱于独立实例）、TS 3.5（2–3 个具体 I/O 示例、test-driven iteration、interview pattern、相互作用问题一次性给全 vs 独立问题顺序修）。相邻考点：显式 review 准则见 ch08，多实例审查见 ch10。本章题组
ch07 · Q1 · 准则 P1
Your GitHub Actions job runs
claude "Review the diff and report security issues". The job never completes; it burns its 30-minute timeout every run. Job logs show Claude Code started and then produced no further output. What is the correct fix?正确 DTS 3.6 与官方样题 Q10：
-p / --print 是在自动化流水线里以非交互模式运行 Claude Code 的既定方式——处理 prompt、输出到 stdout、退出，正是 CI 需要的语义。D1 凭空捏造违反 P1A：
CLAUDE_HEADLESS 这个环境变量不存在。它是官方样题 Q10 的 B 选项——名字「顺理成章」正是 D1 的识别信号。D3 治标不治本违反 P2B：官方解析把它归为「不能正确处理 Claude Code 命令语法的 Unix workaround」。它可能让进程不再阻塞，但绕开了产品自带的、语义正确的机制。考试的一般规律：shell 技巧输给官方 flag。
D1 凭空捏造违反 P1C：
--batch flag 不存在（官方样题 Q10 的 D 选项）。它还容易与 Message Batches API 混淆——那是 API 侧的机制，不是 CLI flag。ch07 · Q2 · 准则 P5
Your CI review step works, but posting results is brittle: a shell script greps Claude's prose output for lines starting with "ISSUE:" and parses file and line numbers with a regex. It breaks roughly once a week when phrasing changes. You need findings posted as inline PR comments. What should you change?
正确 ATS 3.6：
--output-format json 搭配 --json-schema 正是为「产出机器可解析的结构化 findings 以便自动发成 inline PR comment」设计的。P5 机制匹配负载——需要机器解析就用结构化输出机制，不要在自然语言上做解析。D6 概率当保证违反 P3B：靠 prompt 约束输出格式是概率性合规，而 CI 解析要求确定性。题干已经证明「每周坏一次」——现成的 schema 约束机制没用，却去赌措辞。
D3 治标不治本违反 P1C：根因是「在自然语言上做结构化解析」，加固正则只是把下次崩溃推后；fallback 把结构化评论降级成一坨原文，反而损失了 inline 定位能力。
D2 过度工程违反 P2D：多花一次调用去做一件 flag 免费提供的事，还把「散文 → 结构」的不确定性又引入了一遍（第二次调用同样可能格式跑偏）。
ch07 · Q3 · 准则 P1
Your CI review posts comments on every push. On a PR with 6 pushes, developers received the same three comments six times each. The findings were legitimate the first time and remain unaddressed. Developers have started muting the bot. What should you change?
正确 DTS 3.6 的原话级 skill：新 commit 后重跑 review 时，把既往 findings 放进上下文，指示 Claude 只报新增或仍未解决的问题，以避免重复评论。它同时保留了「仍未解决」的可见性——这正是题干需要的，因为那三条意见确实还没被修。
D5 吞错或炸链违反 P6A：只审第一次推送，等于放弃对后续所有改动的审查——为了消除重复评论，把这个 CI 步骤的主要价值一起关掉了。
D3 治标不治本违反 P1B：CI 侧去重能压住重复，但 Claude 每轮仍在无谓地重新发现同样的问题；更关键的是措辞稍变哈希就不同，重复又会漏出来。它模拟了正解的效果，却没有把既往上下文交给模型。
D3 治标不治本违反 P1C：题干明说这些 findings 是合法的（legitimate）。问题是重复，不是过多；收紧准则会误伤真实问题，把一个投递问题当成了精度问题。
ch07 · Q4 · 准则 P2
You ask Claude to convert legacy log lines into a normalized event record. You have described the transformation in three paragraphs of prose, twice, and the output still varies: sometimes timestamps stay local, sometimes severity is lowercased, sometimes the raw line is preserved and sometimes dropped. What is the most effective next step?
正确 BTS 3.5 的第一条：当散文描述被反复不一致地理解时，具体的输入/输出示例是沟通期望转换最有效的方式，guide 给的量是 2–3 个。题干把前提铺满了——散文写了两轮仍不一致。
D3 治标不治本违反 P1A：第三遍散文仍然是散文。题干的数据已经证明这条路径失效两次，再走一次是同一手段的重复，不是升级。
D2 过度工程违反 P2C：interview pattern 的触发条件是你自己不清楚该考虑什么（陌生领域的设计考量）。这里你非常清楚要什么——只是没能传达清楚。用错手段的适配轴。
D2 过度工程违反 P2D：验证-重试循环（TS 4.4）解决的是格式/结构错误的自纠，代价是每次失败都要多跑一轮。在还没试过「给两个例子」这个近乎零成本的手段之前就上重试基础设施，比例倒置。
ch07 · Q5 · 准则 P5
You need Claude to implement a rate limiter for an internal service. You have not built one before and are unsure which questions matter (burst behavior? per-tenant vs global? what happens on clock skew? what should a rejected request return?). What technique fits this situation?
正确 CTS 3.5 的 interview pattern：让 Claude 先提问，以暴露开发者未曾预料的设计考量——guide 举的例子正是缓存失效策略与失败模式这类「你不知道自己不知道」的东西。题干把触发条件写死了：你不确定哪些问题重要。
D3 治标不治本违反 P5A：I/O 示例的适配轴是你知道要什么但表达不清。这里你还没决定 burst 行为和 per-tenant 语义，举不出正确的例子——举出来的例子反而会把一个未经思考的默认固化下来。
D3 治标不治本违反 P5B：test-driven iteration 需要你先能写出「期望行为」。同样的问题：你正是不确定期望行为是什么。它是 interview 之后的下一步，不是替代品。
D2 过度工程违反 P2D：三份实现的成本三倍，而「通过最多 edge case」的前提是你已经有一套覆盖完整的 edge case——这恰恰是你缺的东西。
ch07 · Q6 · 准则 P7
Claude generated a data migration script. Review found four problems: (1) the batch size interacts with (2) the transaction boundary choice, and (3) the null-handling strategy determines (4) how the rollback path must be written. Problems (1)(2) are independent of (3)(4). How should you feed these back?
正确 CTS 3.5 的判据是耦合性：相互作用的问题要在同一条消息里一次给全（否则先修的会被后修的推翻），独立的问题顺序处理（否则注意力被稀释）。题干精确地给出了两个耦合对与它们之间的独立性——直接对号入座。
D3 治标不治本违反 P7A：把四个问题全塞进一条消息，让两组互不相干的约束在同一个注意力预算里竞争。「看到完整图景就能全局优化」是听起来合理的过度概括——guide 的规则是按耦合分组，不是越全越好。
D3 治标不治本违反 P5B：严重度不是这道题的分组轴。逐条修会让 (1) 的修法在 (2) 被提出后失效——耦合问题分次给，正是 guide 点名要避免的浪费。
D5 吞错或炸链违反 P6D：已经诊断出来的问题不反馈，指望它「自己不再复现」，是主动丢弃已有信息；而且 (3)(4) 是耦合对，只修其中之一会留下不一致的回滚路径。
ch07 · Q7 · 准则 P1
Your CI test-generation step produces tests that duplicate scenarios already covered by the existing suite, use hand-rolled fixtures instead of the repo's shared factories, and frequently assert trivial getters. Reviewers discard about 60% of generated tests. What combination addresses this?
正确 BTS 3.6 的两条 skill 正好对上题干的三个症状：把已有测试文件放进上下文（防重复场景），把测试标准、fixture 约定与「什么样的测试有价值」写进 CLAUDE.md（防自造 fixture、防低价值测试）。CI 调用的 Claude Code 只知道仓库告诉它的事。
D2 过度工程违反 P2A：加一道过滤把成本翻倍，而生成端仍在盲写——它治的是产出物，不是「它不知道仓库有什么」这个根因。轻量手段（把上下文给够）尚未使用。
D3 治标不治本违反 P8C：「只生成高价值测试」正是 TS 4.1 点名的模糊指令——模型并不知道这个仓库里什么算高价值，也看不到已有覆盖。缺的是信息，不是措辞强度。
D3 治标不治本违反 P1D：覆盖率阈值能减少重复场景的一部分，但对「自造 fixture」和「断言 trivial getter」这两个症状毫无作用——低覆盖文件里照样可以写出低价值测试。