down-skilling

降阶：Opus → Haiku 蒸馏

将你的推理能力转化为明确、结构化的指令，让 Haiku 5.5 能够可靠执行。你是一个编译器：输入是上下文、意图和领域知识；输出是适用于 Haiku 的提示词，其中包含决策流程和多样化示例。

核心原则

Opus 根据 WHY 推断。Haiku 根据 WHAT 和 HOW 执行。

你的任务：将隐含的推理、上下文判断和专业知识转化为明确的流程、具体的决策树和示范性示例。你会默默进行的每一项推断，都需要明确写给 Haiku。

经济性：为什么示例不再昂贵

Opus 5.5 的输入和输出价格都是 Haiku 5.5 的 40 倍（对于不超过 100K 个 token 的提示词，2026-10 定价分别为 $4/$20 和 $0.10/$0.50 每 MTok）；Sonnet 5.5 的价格则是 Haiku 的 20 倍。一个在 Opus 上耗费 $1.00 的任务，在 Haiku 上约耗费 $0.025，因此，重试不再会抵消节省的成本：Haiku 即使失败并重试十几次，成本仍低于在 Opus 上尝试一次。（Haiku 4.5 的价格为 $1/$5，是 5 倍差价，重试一次就会让节省的成本减半。）如今，失误的主要代价不再是金钱，而是未被发现的错误：看似合理、却没有被任何验证器发现的错误答案。

重要的计算：

• 输入 token 很便宜（Haiku 5.5：输入每 MTok $0.10，输出每 MTok $0.50）
• 添加 2,000 个 token 的示例，每次调用约花费 $0.0002
• 为编排器提供验证器和有依据的重试（先前的输出，以及检查失败时的输出）。在 2026-10-07 的修复测试组中，Haiku 5.5 通过这种方式挽救了所有第 1 级失误（agent-routing）
• 防止验证器无法发现的失误，需要在发布前运行测试集，而不是增加示例块的大小（见下文“从简开始”）

这对提示词设计的意义：

• 如果你要发送一份 8K token 的文档，就可以负担 3-4K token 的示例——示例的成本低于文档本身
• 冗长的输入提示词不会增加输出成本——输出定价与输入长度无关
• 限制因素不是 token 成本，而是收益递减：超过 5-7 个示例后，继续增加示例通常很难提升性能

总结： 按 5.5 的定价，token 不再是限制因素。代价高昂的错误，是发布时没有附上用于校准判断规则的示例，以及用示例代替测试集。这两种情况都会让错误答案流入生产环境。

Haiku 5.5：从精简提示词开始，只在出现错误时才添加内容

2026-10-07 测试了本技能提炼出的 3 个提示词（反馈提取、审核、SQL），每个提示词均按发布版本运行，移除了 <examples>，并采用精简版本（仅包含任务、标签名称和输出架构）；每个提示词运行两次（oaustegard/experiments → downskill-shots）：

组别	规则判定项	示例能够解决的项目
发布版本（规则 + 示例）	40/40	22/24
精简版（无规则、无示例）	38/40	20/24
仅规则，无示例	40/40	15/24

由此可得三点。Haiku 5.5 无需示例就能应用规则。为示例密集型提示词编写的规则，在移除示例后会误导它，因为它会按字面理解规则：“表面内容带有敌意 → 标记”导致一条对文章的尖锐评论被标记，而示例已将其标为 APPROVED。模型无法自行推断的团队惯例（支出仅统计已完成的订单）在 2 次运行中有 1 次通过示例得到迁移，因此应将其写成规则。

Haiku 5.5 的操作流程：

1. 编写精简提示词：角色、任务、所有有效标签、输出架构。
2. 编写 10–20 个测试输入及预期输出，其中至少三分之一位于判断边界。用精简提示词运行这些测试。
3. 对每个错误，只添加修正所需的最少内容：
   • 未声明的默认值或团队惯例（“some”表示 LIMIT 10；支出仅统计已完成的订单）→ 一条明确规则；
   • 判断边界（观点与骚扰、MIXED 与 NEGATIVE）→ 在该边界添加一个示例，并附上其 <reasoning>。绝不添加缺少校准示例的判断规则。
4. 重新运行。测试集全部通过后即停止；此处添加典型案例示例没有帮助。
5. 对于改写和摘要，保留明确的禁止编造规则：没有这条规则时，8 次改写中有 3 次陈述了源文未提及的事实（“我们在各种工作负载下测试了它”）。不要指望事实列表步骤能防止编造。在 5.5 上，无论该步骤在过程中不可见、以可见的 <facts> 块呈现、作为提示词中的列表提供，还是完全缺省，64 次改写中都没有一次编造技术细节（2026-10-08 重新测试）。反编造示例（让沉默保持原样）也是可选的：曾让 Haiku 4.5 在 20 次中达到 19 次成功的示例集，在 5.5 上 8 次中成功了 0 次。
6. 事实列表决定改写会保留哪些内容，因此要有意选择：
   • Haiku 自行编写的列表会把源文对自身的描述记录为事实（“团队称其为范式转变”），改写也会重复这些描述（8/8）。如果不应保留这些内容，请将其写成规则。
   • 提示词中提供的列表会被严格遵循，包括其中的遗漏：一份漏掉“即将推出”的列表，导致 8 次改写中有 2 次称该产品“处于测试版”。只有在对照源文核查过后才提供列表。
7. 不要指示 Haiku 5.5 如何推理（“分 3–5 步思考”“在推理中，先列出……”）。Anthropic 的系统卡测得，它遵循关于自身思考内容的指示的比例接近 0%（图 6.4.2.4.A）。需要其结果的任何步骤，都应放入可见输出中，以便核查；并通过 effort 参数设置推理长度。

通常最后只需 0–3 个示例，而非 4–7 个。本文件其余部分介绍的是 Haiku 4.5 的方法。对 Haiku 4.5，以及第 3 步要求的边界示例，请使用该方法。

精简提示词之前：先确认任务是否需要这样做（2026-07 校准）

此技能的差距目录最初源自模型卡先验。 2026-07-15 的实证校准（对 Haiku 4.5 进行了 300 次测量调用；数据见 agent-routing 技能的 references/calibration-2026-07-15.md）发现， Haiku 4.5 在可机械检查的任务上远强于这些先验：嵌套模运算 （16 个叶节点的表达式树）240/240，30 跳函数链、25 步状态跟踪、 设有陷阱的文字数学题，以及同时满足 5 项约束的句子生成（精确词数、 必需／禁用词元、避用特定字母）——均在 effort: low 下完成， 且其中一项对照测试完全抑制了思维链。同一组测试中，Sonnet 在低 effort 下得分为 17/20，未能满足 Haiku 已满足的精确计数约束。

在投入完整的精简工作之前，先进行分流：

1. 输出可机械检查（架构验证通过、测试运行、计数正确、正则表达式匹配）？→ 精简提示词 + 确定性验证器 + 失败时重试或升级处理，比堆满示例却没有验证器的提示词更省钱、更可靠。把精力花在编写检查器上，而不是示例上。当提示词明确规定计数规则时（“一个词 = 任意连续的字母或撇号”），精确约束（“恰好 N 个词”）能可靠满足——起作用的是定义的精确性，而非脚手架的数量。
2. 输出需要判断（语气、相关性、质量、歧义消解）？→ 这正是本技能其余部分的用途。进行完整精简：流程、评分标准、少样本示例。
3. 混合型？ → 拆分任务。按（1）处理可检查的部分；只精简需要判断的部分。

迭代警告（同一校准中的测量结果）： 切勿让 Haiku 在循环中盲目地反复改进自己的输出。对于正确答案，重新应用后结果保持不变（96 组循环配对中有 0 处变化）；唯一发生变化的输出在第二轮质量下降，之后所有轮次都停留在退化文本上。如果要迭代，请用外部检查器或评判器为每次迭代评分，保留 argmax，并在首次退化时停止。

激活

触发后，执行以下步骤：

1. 提取任务背景：从对话中判断用户想要达成什么目标、适用哪些领域知识，以及哪些质量标准很重要。

2. 找出推理缺口——Opus 会自动推断、但 Haiku 需要明确说明的内容。常见缺口包括：

   • 消除歧义（Opus 会选择合理的解释；Haiku 需要决策规则）
   • 质量判断（Opus 知道什么是“足够好”；Haiku 需要明确标准）
   • 边缘情况处理（Opus 能推理新情况；Haiku 需要列举具体情况）
   • 输出校准（Opus 会直觉地把握语气和长度；Haiku 需要明确限制）

3. 按照 提示词架构中的结构，生成精简后的提示词。

4. 添加示例。 对于 Haiku 5.5，只添加裸跑遗漏之处的边界示例（参见先裸跑，再只添加遗漏所需内容），通常为 0–3 个。对于 Haiku 4.5，按照示例设计生成 4–7 个不同的示例；这在该版本中是最能提升效果的一步。

5. 交付前审核示例集。 必须通过以下两项检查：

   • 来源锚定：对于每个示例输出，其中每个具体事实（具名技术、数字、比较、引述语句）都必须能从该示例输入中推断出来。如果只看输入无法复现输出，就应将相关细节添加到输入中，或从输出中删除。示例中虚构的事实会导致 Haiku 在运行时模仿这种虚构模式。
   • 长度校准：示例输出长度必须落在规定的输出范围内。如果规则要求“60–90 个词”，但示例平均只有 35 个词，这条规则就不会生效——Haiku 会遵循示例的集中趋势。

   如果任一项未通过，请在交付前重新生成不合格的示例。示例胜过规则；与规则不一致的示例甚至会压过与规则一致的示例。

6. 交付完整且适用于 Haiku 的提示词，作为可复制的内容或文件提供，并根据需要包含系统提示词和用户提示词组件。

提示词架构

每个精简后的提示词都必须按以下顺序包含这些组件。 Haiku 对这种特定的排列顺序响应最佳：

<role>
[Single sentence: who Haiku is and what it does]
</role>

<task>
[2-3 sentences: the specific task, its purpose, and the deliverable]
</task>

<rules>
[Numbered list of explicit constraints. Be precise about:]
- Output format (JSON schema, markdown structure, etc.)
- Length bounds (word/token counts, not vague "brief"/"detailed")
- Required elements (must-include fields or sections)
- Prohibited behaviors (specific failure modes to avoid)
- Decision rules for ambiguous cases
</rules>

<process>
[Numbered steps. Maximum 7 steps. Each step is one action.]
[Include validation checkpoints: "Before proceeding, verify X"]
[Include decision points: "If X, do Y. If Z, do W."]
</process>

<examples>
[Haiku 5.5: 0-3 boundary examples, each calibrating a judgment rule]
[Haiku 4.5: 4-7 diverse examples; the LARGEST part of the prompt]
[See Example Design section for distribution requirements]
</examples>

<context>
[Task-specific data, reference material, or domain knowledge]
[Use labels: [Context], [Policy], [Reference]]
</context>

Haiku 优化规则

生成面向 Haiku 的提示词时，应用以下规则：

结构与语法

• 使用 XML 标签界定每个部分——Haiku 能遵循带标签的边界
• 尽可能将句子控制在 25 个词以内
• 每句话只写一条指令；拆分复合指令
• 使用编号步骤，而非散文段落，来描述流程
• 明确指定词元或词数预算：“用 80–120 个词作答”

推理支持

• 用决策准则取代开放式判断： 不佳：“评估代码是否适合用于生产环境” 良好：“检查：(a) 没有 TODO 注释；(b) 所有函数都包含错误处理；(c) 没有硬编码密钥。对每项评定通过或不通过。”
• 限定推理深度：“分 3–5 步思考，然后给出答案”（适用于 Haiku 4.5；对于 5.5，这会导致它进行并不遵循指令的推理，参见上文第 7 步）
• 为不确定情况提供后备方案：“如果无法确定 X，请回复：‘UNCERTAIN: [简要原因]’”

上下文管理

• 将关键指令放在前面（Haiku 对前置内容关注度较高）
• 经验性预算规则（Haiku 4.5）：指令和规则合计不超过 800 个词元，剩余预算用于示例。对于处理 8K 文档的任务，使用 3–4K 个词元的示例完全在预算范围内，而且能显著提升可靠性
• 只提供 1–3 段最相关的上下文片段，而不是完整文档
• 在上下文与指令之间使用明确的分隔符

输出控制

• 对可提取结果，要求使用结构化输出（JSON、带标签的部分）
• 提供 Haiku 可填写的输出模板
• 指定回复的开头内容：“回复请以……开头”
• 对分类任务，列出所有有效类别

预防失败

• 预判 Haiku 常见的失败模式，并添加防护措施：
  • 幻觉：“只能使用所提供上下文中的信息。 如果上下文中没有答案，请说‘来源中未找到。’”
  • 冗长：“最多 150 个词。不要添加开场白或保留意见。”
  • 格式偏移：在规则和示例中都包含输出架构
  • 跳过指令：为所有约束编号；在流程步骤中引用它们：“应用 中的规则 2-4”

示例设计

对于 Haiku 4.5，示例是投入产出比最高的单项投资。 对于 Haiku 5.5，示例的作用更局限于校准判断规则，并展示哪些内容应当省略；请参阅 从简开始，再只添加遗漏所需内容。本节其余内容介绍的是 4.5 方法。 规则告诉 Haiku 要做什么；示例则展示“正确完成”的样子。当规则与示例冲突时，Haiku 会遵循示例。 当规则含糊不清时，Haiku 会根据示例推断。这使示例成为主要的引导机制——不是规则的补充，而是起主导作用的信号。

考虑到成本效益（请参阅成本效益——示例是免费的）， 你应在此投入大量精力。一个包含 800 个词规则和 3,000 个词示例的提示词，几乎总会优于包含 2,000 个词规则和 500 个词示例的提示词。

最少示例数量：4 个（Haiku 4.5）

对于 Haiku 4.5，每个提炼后的提示词应生成 4-7 个多样化示例。少于 4 个就属于投入不足。与可靠性提升相比，每个示例的边际成本微乎其微。采用以下分布：

#	作用	用途
1	典型案例	最常见、最直接的输入。确立基准模式。
2	第二个典型变体	不同但常见的输入——在长度、领域或结构上与 #1 不同。防止 Haiku 对单一模式过度拟合。
3	边缘案例	不常见但有效的输入：字段为空、文本很长、特殊字符、边界条件、表述含糊。
4	反例（标记为 BAD/GOOD 的成对示例）	对于 Haiku 可能输出看似合理但实际错误内容的任务（改写、摘要、NL→命令，以及任何会诱使其自信地给出具体内容的任务），加入一组成对示例，分别标记为“BAD output:”和“GOOD output:”，展示你希望避免的、针对该任务的具体失败模式——虚构架构细节、虚构 CLI 标志、虚构数字等。与点明 Haiku 最可能犯错类别的示例相比，泛泛的“错误输出”示例效果要差得多。
5+	棘手／边界案例	接近决策边界、Haiku 最可能出错的输入。可用作测试套件的案例。

**为什么第二个典型案例很重要：**只有一个典型示例时， Haiku 可能会抓住该示例的偶然特征（长度、 用词、领域）。从不同角度提供第二个典型案例，可以让 Haiku 分清哪些特征与任务有关，哪些只是巧合。

示例格式

<example>
<input>
[Realistic input data — use real-world length and complexity]
</input>
<output>
[Exact format Haiku should produce — not a description, the actual output]
</output>
<reasoning>
[1-2 sentences: WHY this output is correct. Which rules applied.
 What Haiku might have gotten wrong without this example.]
</reasoning>
</example>

对于复杂任务，<reasoning> 标签不可或缺。 它作为思维链锚点，向 Haiku 展示应遵循的推理模式。 对于分类和提取任务，推理应引用影响判断的具体规则编号。

当输入可能较为抽象时：对沉默进行建模

有些任务（改写、摘要、语气／文体编辑、根据源内容进行解释）的输入，其源内容本身就很抽象——营销文案、含糊的描述、高层摘要。这类任务特别容易出现一种失败模式：Haiku 会编造一些听起来符合领域常识、但源内容中并不存在的具体细节。

**症状：**输出信誓旦旦地提及输入中没有的具体内容——算法名称、技术选型、百分位数、版本对比等。

解决方法：加入一个示例对，其中的输入确实很抽象，而输出会明确指出哪些信息未作说明，而不是用听起来合理的推断填补空白。模式如下：

<example>
<input>
"We're excited to release our new search backend. We think it's a
massive upgrade over the old one."
</input>
<output>
New search backend released. The announcement does not specify the
underlying changes — whether they affect indexing, ranking, query
parsing, or operational characteristics is not stated. Migration
guidance will follow. The old search path remains available during
transition.
</output>
<reasoning>
The source provides only one factual claim ("released") and one
unverifiable claim ("upgrade"). The output stays at the source's
level of abstraction and explicitly names the categories of
information the source omits, rather than inventing plausible
specifics (algorithm changes, performance numbers, technology names).
</reasoning>
</example>

将此示例与带有 BAD/GOOD 标记的负面示例（上方分布表中的第 4 行）搭配使用，展示你希望避免的确切臆造内容。在一项语气改写任务中，将示例从缺乏依据的模式改为此模式后，Haiku 的架构幻觉率从 95% 降至 0%（两个探测共 n=25）。

示例长度指南（Haiku 4.5）

任务处理的输入……	建议的示例预算
短输入（<500 个 token）	1,500-2,500 个 token 的示例（4-5 个示例）
中等长度输入（500-4K 个 token）	2,500-4,000 个 token 的示例（4-6 个示例）
长输入（4K-8K 个 token）	3,000-5,000 个 token 的示例（5-7 个示例）

这里不受上下文限制：Haiku 5.5 的上下文窗口为 1M，不过超过 100K 个 token 的提示词，两端的计费都是 5 倍（$0.50/$2.50 每 MTok）。限制在于收益递减：超过 7 个示例后，边际收益会急剧下降，除非任务的分类空间非常大。

示例质量标准

• 示例必须真实可信，不能是玩具数据——要匹配真实输入的复杂性和杂乱程度
• 所有示例的输出格式必须完全一致——Haiku 会将格式不一致视为格式无关紧要的信号
• 包含你预计 Haiku 需要处理的最难案例
• 改变输入特征：长度、复杂性、领域、语气
• 切勿加入与规则相矛盾的示例
• 按由简到繁的顺序排列示例——循序渐进的难度有助于 Haiku 逐步建立理解
• **每个具体事实都必须以源内容为依据。**示例输出中的每个具体名词、数字或主张，都必须能够从该示例的输入中推断出来。如果示例输出编造了一个看似合理的架构细节，即使真实输入并不支持这种内容，Haiku 也会照搬这种臆造模式。审核时遮住输入并自问：“仅凭输入，我能否得出这个输出？”如果不能，就修改输入或输出。
• **示例长度应与规定的输出范围相符。**示例对长度的影响大于规则。如果规则要求“输出 60–90 个词”，但示例平均只有 35 个词，Haiku 就会生成约 35 个词。调整示例输出长度，使其处于（或略高于）规定的输出范围。

交付格式

将提炼后的提示词放在代码块或制品中，并用清晰的章节标记。包括：

1. 系统提示词（如适用）：角色 + 持续适用的规则
2. 用户提示词模板：使用 {{placeholders}} 表示可变内容
3. 示例：嵌入提示词中，或单独放在少样本示例部分
4. 使用说明：提示词可能失效的情况，以及需要留意的事项

用于 API 时，请包含模型参数和建议设置：

model: claude-haiku-4-5-20251001
max_tokens: [appropriate for task]
temperature: 0 (for deterministic tasks) or 0.3 (for creative tasks)

Agent 式资源选择

此技能包含两个存放细分参考文件的目录。请勿全部读取。先浏览下方索引，然后只读取与当前任务相关的文件。

gaps/

每个文件都记录了一种推理模式：Haiku 在该模式下与 Opus 存在差异，并提供经过测试的缓解策略。每项任务阅读 2-4 个文件。

文件	适用于涉及以下内容的任务……
ambiguity-resolution.md	存在多种有效解读的输入；含糊的用户请求
code-generation.md	生成代码、脚本或查询；匹配现有代码的风格
comparative-analysis.md	比较选项、分析优缺点和权衡
conditional-logic.md	决策树、分支规则、嵌套的 if/then 逻辑
context-utilization.md	长上下文窗口、超过 2K token 的文档、对位置敏感的信息
counting-enumeration.md	“恰好生成 N 项”、统计出现次数、列表长度
creative-generation.md	写作、语气调整、保持角色一致性、匹配风格
implicit-constraints.md	默认但未明确说明语气、受众或格式规范的任务
instruction-density.md	需要同时遵守 8 条以上约束的任务；复杂规则集
multi-hop-reasoning.md	3 步以上的推理链；因果与后果分析
multi-turn-consistency.md	聊天机器人行为、有状态对话、维持角色设定
negation-handling.md	以“不要”“绝不”“避免”等措辞表述的约束；禁止事项
nuanced-classification.md	边界案例、多标签分类、类别重叠
output-calibration.md	长度控制、格式精度、详略管理（务必阅读）
parallel-consistency.md	生成多个相似项目；要求格式统一的列表
partial-information.md	字段缺失、输入不完整、可选数据、错误状态
schema-adherence.md	必须能够处理边缘案例输入的结构化输出（JSON、表格）
self-correction.md	需要验证的任务；输出前的质量检查
summarization-fidelity.md	总结文档，同时避免失真、位置偏差或编造内容
tool-use-planning.md	多工具工作流、API 编排、依赖顺序

examples/

完整的前后对照示例。每个示例都展示一项 Opus 级任务 → 针对 Haiku 优化的提示词，并附有说明。阅读 1-2 个与当前任务领域最接近的示例。

文件	适用于提炼……
api-orchestration.md	存在依赖和分支的多步骤工具/API 工作流
code-review-triage.md	带严重性分类和结构化 JSON 输出的分析任务
content-moderation.md	安全关键型分类，以及“不确定时”的默认处理方式
creative-rewriting.md	语气调整、面向受众的改写、风格迁移
data-extraction.md	将非结构化文本按 Schema 要求提取为 JSON
document-qa.md	基于 RAG / 检索结果的问答，包含引用和“未找到”处理
email-summarization.md	从对话/邮件串中提取信息并整理成不同部分
meeting-notes.md	将转录内容整理为决策、行动项和后续步骤
resume-screening.md	多标准评估，采用并行评分结构
sql-generation.md	在 Schema 约束和错误处理下，将自然语言转换为代码
step-by-step-analysis.md	多步骤分析推理，采用明确的决策标准
text-classification.md	多标签分类，处理置信度和歧义

自检

交付前，请根据以下标准验证提炼后的提示词：

• 明确说明每一项 Opus 推理
• 所有约束均已编号并相互引用
• 提供 4 个或更多多样化示例，且输出格式一致
• 示例包括：2 个典型案例、至少 1 个边缘案例、1 个或更多负面/拒绝案例
• 示例的词元数 ≥ 规则的 2 倍（示例应构成提示词的主体）
• 不含假设 Haiku 会“自行领会”的指令
• 决策点均设有明确的分支，而非开放式判断
• 展示输出格式，而非仅作描述
• <reasoning> 标签说明每个示例输出正确的原因