显式判定标准（考点 4.1）· CCAF 备考

本页目录5

这个考点是什么

「显式判定标准（Explicit criteria）」考的不是某一个具体功能，而是一种贯穿 Prompt Engineering 的方法论：把「Claude 应该能猜到我想要什么」的隐性期待，转成写进 prompt 里、可核对的明确条件。

官方文档把 Claude 类比为「一个聪明但刚入职、不了解你团队规范的新员工」——它不会主动补全你没说出口的格式要求、执行意图或优先级，你说得越精确，结果越可控。

这条主线在具体技巧上体现为几件事：

用祈使句而不是委婉建议句表达「我要你做这件事」，避免 Claude 把「帮我看看能不能改进」误解为「只给建议、不动手」；
用 XML 标签（如 <instructions>、<context>、<input>）把 prompt 中不同性质的内容显式分隔，减少 Claude 对内容边界的猜测；
控制回复格式时说「要写成什么样」而不是「不要写成什么样」；
长文档（20k+ token）按官方建议放在 prompt 顶部、查询放最后，让「先读什么、后读什么」也变成显式安排，而不是随意堆叠。

反过来，「判定标准」写得含糊或位置放错——比如指令委婉、格式要求靠 prefill 硬凑、长文档和问题顺序颠倒——都会让 Claude 的行为退回到「凭感觉猜」，这正是该考点要考察的边界。

为什么考

这类题目的典型出题角度，是先给一个「隐性期待落空」的场景（Claude 只给建议不改代码、长文档场景下回答质量差、格式总是跑偏），再问按官方指南应该补上什么样的显式标准。

干扰项通常沿两个方向设置陷阱：

一是「矫枉过正」——比如用 CRITICAL: You MUST... 这类激进措辞去强逼 Claude 执行，文档明确指出这会导致 overtrigger，属于反例而非正确修正；
二是「张冠李戴」——把本该放在 system 参数、prompt 顶部或 XML 标签里的显式标准，错放到 tools、prefill、messages 的虚构字段等不存在或不对口的位置。

素材中的辨析记录也提示了一个常见坑：同一条「长文档置顶」规则会被拆成单选和多选反复考，备考时要注意区分「记住结论」和「知道结论适用的阈值与配套做法（如 XML 包裹、先抽取引文）」——单一子集式选项掌握了结论就能蒙对，但完整多选题要求连带记住配套细节。

核心辨析

1
golden rule 的落点是「测试方法」而不是「说清楚」这句空话
官方给的是可执行动作——把 prompt 给一个几乎不了解任务的同事看，他照做会不会卡壳；卡壳就说明标准不够显式。选项里凡是「让 Claude 自己推断」「用关键词代替完整句子」都是这条原则的反例。
2
tool use 场景里，祈使句和建议句是两种不同的显式判定标准
Change this function to improve its performance 会触发实际执行，而 Can you suggest some changes 官方文档里明确记录为只会得到建议、不会有实际改动。这条区分常被用来考「同一个意图，措辞不同导致行为不同」。
3
格式控制的正确做法和「看起来更强硬」的做法是反的
正确做法是说「要什么」（如具体 XML 标签包裹目标段落）、匹配 prompt 自身格式风格；而用大写、CRITICAL、MUST 等加重语气在新模型上反而会 overtrigger，官方建议 dial back，这与「标准越强硬越管用」的直觉相反。
4
XML 标签的作用边界要分清
它是让 Claude 消除内容类型歧义的显式结构化手段，不是 Messages API 的强制要求、不会压缩 token、也不会自动产出 schema 校验过的 JSON（那是 Structured Outputs / tool use 的职责）。把 XML 标签和「格式强制」「省 token」混为一谈是常见误判。
5
长文档顺序规则有明确阈值和方向，不是「越靠前越好」的模糊感觉
约 20k+ token 的长文档/输入应放在 query、instructions、examples 之上，查询放最后，官方数据里给出的效果是最多约 30% 的质量提升；题目常用「放最后」「顺序无关紧要」「拆开穿插」作为反例。
6
角色设定的显式标准是 system 参数，不是虚构的 API 字段
persona/role 通过顶层 system 设置以稳定影响整个对话，而不是通过不存在的 messages persona role、tools 或 output_config.role;assistant prefill 只影响单轮且在新模型上不再支持，不适合承担持续性的角色标准。

反模式对照

常见做法

用委婉建议式措辞（如「能不能帮我看看这里能不能改进」）期待 Claude 直接执行改动

正确做法

用清晰的祈使句明确表达执行意图，如「Change this function to improve its performance」

官方文档明确指出，措辞委婉时 Claude 更倾向只给建议而不动手，这不是模型「偷懒」，而是指令本身没有把「要执行」这条标准显式表达出来。

常见做法

为了让 Claude 更「听话」而使用 CRITICAL、You MUST 等加重语气的强制性措辞

正确做法

用平实、具体的指令表达要求，把标准写清楚而不是靠语气施压

官方指南指出，新模型对激进措辞更敏感，容易导致工具或动作被过度触发（overtrigger），效果和预期相反。

常见做法

把长文档放在 prompt 末尾，或者把文档内容和指令、问题交替穿插排列

正确做法

对 20k+ token 的长文档，将其放在 prompt 顶部，指令、示例、查询放在文档之后，查询尽量靠近末尾

官方测试显示，查询置后可以在复杂多文档场景下带来最多约 30% 的回答质量提升，顺序本身就是一种显式判定标准，不是无关紧要的排版选择。

常见做法

依赖 assistant 回复的 prefill 来控制输出格式或角色语气

正确做法

用格式指令 + XML 标签指示目标结构，或改用 Structured Outputs / tool use 来约束输出

Claude 4.6+ 模型已不再支持对最后一轮 assistant 消息做 prefill（会直接返回 400 错误），显式的格式指令和结构化输出机制才是文档推荐的替代方案。

练这个考点

练习模式支持按考点专练（需 Google 登录，不占用正式考机会）。

专练考点 4.1

该考点的公开题（免登录，含完整解析）：

← 返回考点目录