Chapter 08 · Domain 4（权重 20%）

显式准则与 Few-shot
把「be conservative」翻译成可执行的判据

本章是 P8「显式准则胜过模糊置信」的方法论层。它的适用面远超 CI code review——凡是题干出现「误报率高」「输出不一致」「模型在边界案例上判断不稳」，答案基本都在这两个手段里。官方样题 Q3 直接考它。

一、为什么模糊指令不管用

"be conservative"、"only report high-confidence findings"、"use good judgment" 这类指令不会提升 precision。原因不是模型不听话，而是这些词对模型和对你不是同一个意思——你说 "conservative" 时脑子里有一条具体的界线，模型没有。

模糊指令 ✘	显式分类准则 ✔
"Check that comments are accurate."	"Flag a comment only when the claimed behavior contradicts the actual code behavior."
"Be conservative; only report high-confidence findings."	"Report: bugs, security issues. Skip: minor style, patterns that are local conventions in this repo."
"Rate the severity appropriately."	每个 severity 级别配一段具体代码示例，说明什么样的代码算 critical、什么样算 minor。

右列的共同点是：可判定。一个新来的工程师拿着右列的准则，能对同一段代码做出和你一样的判断；拿着左列的，不能。这就是「显式」的操作性定义。

误报的传染性

guide 特别点出一条：高误报的类别会拖垮准确类别的可信度。开发者不会精细地区分「这个 bot 在 security 上很准、在 style 上很吵」——他们只会整体降低信任，最后连真 bug 也不看。

由此得到一个反直觉但被官方背书的动作：临时禁用误报率高的类别，先把信任救回来，同时离线改进那些类别的 prompt，改好再启用。考场识别信号：题干出现「开发者已经开始无视/静音这个工具」时，「先关掉最吵的那一类」是正确选项的一部分，而不是逃避问题。

与 P8 的关系 — 注意 TS 4.1 明确说了应当写具体的 review 准则，而不是依赖基于 confidence 的过滤。这是「显式准则 vs 模糊置信」这条轴的原始出处。未校准的自报 confidence 不能当过滤器，也不能当路由依据——后者见 ch14 的 TS 5.5。

二、Few-shot：什么时候用、用几个

Few-shot 不是「多给点例子总没错」，guide 给了明确的适应症和剂量：

适应症	形态
格式不一致——详细指令已经写了，输出格式还是飘	示范期望的输出格式：location、issue、severity、suggested fix
歧义案例判不准——工具选择、分支级测试覆盖缺口这类「两边都说得通」的情况	示范推理过程：为什么选 A 而不是同样合理的 B
误报多——把正常写法当问题报	示范可接受的代码模式 vs 真问题，让模型学会区分而非死记
抽取幻觉——非正式计量单位、文档结构多样	示范不同结构下的正确抽取（inline citations vs bibliographies）
必填字段被空/null	示范从不同格式文档里正确抽出该字段

剂量：2–4 个针对性示例。 关键词是 targeted（针对性）——针对的是歧义场景，不是常见场景。给五个一眼就该选 A 的例子毫无价值；给两个「A 和 B 都像但应该选 A、并说明为什么」的例子才有价值。

示例要能泛化。guide 强调 few-shot 的目标是让模型把判断力推广到新模式，而不是只匹配预先列出的案例。这一条在考场上很有用：如果一个选项说「列出全部已知的边界情况」，它通常输给「给 2–4 个示范推理过程的例子」——前者穷举不完，后者可迁移。

三、两个手段怎么配合

官方样题 Q3 的正确答案是两者一起上：在 system prompt 里加显式 escalation criteria + few-shot examples 示范何时升级、何时自主解决。这不是巧合，两者分工明确：

显式准则划定边界在哪——把「什么该报/什么该跳过」写成可判定的分类。
Few-shot示范边界怎么走——用 2–4 个歧义案例演示推理，让模型在准则覆盖不到的新情形里也能类推。

对照：只给准则 → 边界清楚但难例仍然判错；只给例子 → 会模仿格式但不知道原则，稍偏离就崩。

值得注意的是这套组合在 P2 比例阶梯上的位置：它是轻量级手段——改的是 prompt，不动基础设施。官方样题 Q3 的三个错误选项（训练分类器、自报 confidence 路由、情绪分析）都在阶梯更上层或干脆走错了轴。这解释了为什么 Domain 4 的题里「加显式准则 + few-shot」出现频率这么高：它几乎总是那个「还没试过的最轻手段」。

外部课程 · CertSafari — 本章 2 个考点（展开查看）

用于补读和错题复盘；第三方 AI 生成练习材料，非官方题库。核验答案时以 Exam Guide 和官方文档为依据。复盘方法 · 链接核对：2026-10-16。

考点回链 — 本章覆盖：TS 4.1（显式分类准则 vs 模糊指令、误报拖垮整体信任、临时禁用高误报类别、每个 severity 配具体代码示例、不依赖 confidence 过滤）、TS 4.2（few-shot 用于格式一致性/歧义案例/降误报/抽取幻觉/空字段、2–4 个针对性示例、示范推理以支持泛化）。相邻考点：结构化输出见 ch09，多遍审查见 ch10，confidence 校准见 ch14。

本章题组

ch08 · Q1 · 准则 P8

Your CI reviewer reports stale-comment issues on 34 of 40 PRs. Sampling shows 29 of those 34 are cases where the comment is merely terse or slightly outdated in wording, not wrong. The current prompt says "check that comments are accurate and report inaccuracies." What is the most effective change?

正确 ATS 4.1 的原例几乎逐字：用「仅当注释声称的行为与代码实际行为矛盾时才 flag」这类具体准则，替代「检查注释是否准确」这类模糊指令。它把一个主观形容词换成了一个可判定的条件——29/34 的误报正是「accurate」定义过宽造成的。

D3 治标不治本违反 P8B：TS 4.1 直接点名 "be conservative" / "only report high-confidence findings" 这类通用指令无法像具体分类准则那样提升 precision。它没有给模型任何新的判据。

D6 概率当保证违反 P8C：未校准的自报 confidence 不可作过滤依据——TS 4.1 明确要求写具体 review 准则而不是依赖 confidence-based filtering。模型恰恰会在判错的地方自信。

D5 吞错或炸链违反 P6D：34 例里有 5 例是真问题。整类关停会把它们一起丢掉。注意与「临时禁用高误报类别」的区别：后者是边关停边改进 prompt、改好再启用的过渡措施，而这里给的是永久放弃且不打算修。

ch08 · Q2 · 准则 P2

Your review bot has four finding categories. Security and concurrency findings are accurate (roughly 90% accepted). Naming-convention and "possible dead code" findings are accepted about 15% of the time. Developers have begun collapsing all bot comments without reading them, including the security ones. What should you do?

正确 DTS 4.1 的两条合用：高误报类别会拖垮准确类别的可信度（题干的「连 security 一起折叠」正是这个现象），而官方给的动作就是临时禁用高误报类别以恢复信任、同时改进其 prompt。注意「temporarily」与「before re-enabling」——这是过渡措施，不是放弃。

D3 治标不治本违反 P1A：排序改变的是阅读顺序，不是信噪比。开发者已经在整体层面停止阅读，把噪音排到后面并不会让他们重新开始读第一条。

D4 甩锅错位违反 P1B：把判断负担转回给已经失去耐心的开发者，且要求他们每次做统计推理。信任是被噪音总量摧毁的，加元数据不减少噪音。

D2 过度工程违反 P2C：为 15% 命中率的两个类别新建一条投递通道并维护它，而更轻的手段（先关掉、改好准则再开）尚未使用。而且异步低优先级通道在实践中等同于无人阅读，只是把噪音换了个地方堆。

ch08 · Q3 · 准则 P8

Your extraction prompt for lab reports has detailed prose instructions, yet output formatting still varies run to run: units are sometimes normalized and sometimes copied verbatim, and the "method" field is sometimes a sentence and sometimes a code. The instructions themselves are not ambiguous to a human reader. What is the most effective technique?

正确 ATS 4.2 的第一条：当详细指令本身已经产出不一致结果时，few-shot examples 是达成格式一致性最有效的手段，剂量 2–4 个。题干把前提写明了——指令对人类读者并不含糊，问题出在「指令 → 输出格式」这一跳。

D3 治标不治本违反 P5B：位置效应（TS 5.1 的 lost-in-the-middle）治的是长输入中段被漏读。这里指令并没有被漏读——它被读到了，只是被不同地实现了。用错机制的适配轴。

D3 治标不治本违反 P8C：「要保持一致、严格遵守格式」是 TS 4.1 点名的模糊指令的近亲。它没有新增任何模型可判定的信息。

D2 过度工程违反 P2D：穷举清单既维护不动（新单位随时出现），又与 few-shot 的设计目标相悖——guide 强调示例的价值在于让模型泛化到新模式，而不是匹配预先列出的全部案例。

ch08 · Q4 · 准则 P8

Your agent must choose between lookup_order and check_shipment for requests like "where's my package" — genuinely ambiguous phrasing where either tool can be defensible depending on whether the order has shipped. Both tool descriptions are already detailed and distinct. Selection is correct about 70% of the time. What is the appropriate next step?

正确 CTS 4.2 点名的适应症之一就是「歧义请求下的工具选择」，且指定形态是 2–4 个示范推理过程的示例——展示为什么在两个都合理的选项中选了这一个。题干强调歧义真实存在、描述已经详尽，正是 few-shot 而非描述扩写的场景。

D2 过度工程违反 P2A：合并工具是有效的架构手段（TS 2.1 提到过拆分与合并），但它是重手术；官方样题 Q2 的 D 选项正因为「作为第一步过重」被判错。这里更轻的 few-shot 尚未尝试。

D2 过度工程违反 P2B：关键词预路由绕开了 LLM 的自然语言理解（官方样题 Q2 的 C 选项被点名 over-engineered）；而且这类请求的正确选择取决于订单是否已发货这一状态，关键词根本判不出来。「把概率换成确定性」听起来正对 P3，但确定地按一个判不准的依据路由，只是把 30% 的随机错误换成了系统性错误。

D3 治标不治本违反 P1D：描述扩写是 TS 2.1 对付「描述简陋导致误选」的正解，但题干已明确两个描述详尽且互相区分。继续加描述是在一个已经不是瓶颈的地方加码。

ch08 · Q5 · 准则 P8

Reviewers complain that severity labels are inconsistent: the same class of unchecked error return is labeled "critical" in one PR and "minor" in another. The prompt currently lists severity levels with one-line definitions ("critical: could cause data loss or outage"). What improves consistency most?

正确 BTS 4.1 的第三条 skill：为每个 severity 级别定义显式准则并配具体代码示例，以达成一致的分类。一行定义仍然要靠解释（「could cause data loss」是个判断），一段示例代码则给了可对照的锚点。

D3 治标不治本违反 P8A：把刻度变粗只是把不一致挪到新的分界线上——同一个 unchecked error return 照样可能一次被判 blocking、一次 non-blocking。分类标准的模糊性没有被触及。

D6 概率当保证违反 P8C：把一个未定义的定性判断换成一个未校准的定量分数，模糊性原封不动地转移了。数值看起来客观，但产生它的判断依据仍然是同一段一行定义。

D2 过度工程违反 P2D：双跑取高把成本翻倍并系统性抬高严重度（引入新的偏差），而最轻的手段——把准则写具体——尚未使用。它买到的「一致」也是假的：取高只是把两次分歧压成一个稳定的高值，同一段代码在另一对采样下照样可能两次都判 minor。

ch08 · Q6 · 准则 P1

Your extraction pipeline returns null for the required "sample volume" field in 22% of lab documents. Inspection shows the value is present in those documents but written informally ("about a teaspoon", "2 tbsp", "filled the vial to the neck") rather than as a numeric measurement. What should you do?

正确 BTS 4.2 点名了两条正好命中的适应症：few-shot 可降低抽取幻觉（明确举了「非正式计量」与文档结构多样），也可用于解决必填字段被空/null 抽取的问题——通过示范从不同格式的文档中正确抽取。

D5 吞错或炸链违反 P6A：TS 4.3 的方向正好相反——字段设成 optional/nullable 是为了防止模型为满足 required 而编造值。强制必填会把 22% 的 null 变成 22% 的杜撰数字，问题从可见变成不可见。

D2 过度工程违反 P2C：TS 4.4 明确指出 retry 对「格式/结构错误」有效。这里模型不是格式出错，而是不认为这些表述算数——同一个 prompt 重跑一遍，多半返回同样的 null，只是多花一次钱。

D2 过度工程违反 P2D：用正则去理解「filled the vial to the neck」这类自然语言表述，是把最适合 LLM 的工作交给最不适合的工具；而且它要长期维护一份永远追不全的表述清单。

ch08 · Q7 · 准则 P2 + P8

Your support agent resolves only 55% of contacts without escalation, well below the 80% target. Logs show it escalates routine cases (standard damage replacement with photo evidence) while attempting to handle cases that need documented policy exceptions. What is the most effective improvement?

正确 D官方样题 Q3 的正确答案形态：显式准则划边界 + few-shot 示范边界怎么走，直接对准根因（决策边界不清），且是比例得当的第一反应——改 prompt，不动基础设施。TS 4.1 + TS 4.2 + TS 5.2 三处交汇。

D2 过度工程违反 P2A：需要标注数据与 ML 基础设施，而 prompt 优化根本还没试过。官方解析对这个选项的原判就是 over-engineered。

D3 治标不治本违反 P1B：解决的是另一个问题。TS 5.2 明确说 sentiment 不是案件复杂度的可靠代理——题干里判错的恰恰是「有照片证据的常规换货」，客户情绪与它该不该升级无关。