用途：把原本依赖 Opus 隐式推理的任务，编译成 Haiku 5.5 能稳定执行的显式提示词。核心原则是 Opus 从“为什么”推断，Haiku 从“做什么、怎么做”执行，因此需把默认值、判断边界、输出校准等写成明确规则。
主要能力：按固定结构生成提示词，顺序为 role、task、rules、process、examples、context；用 XML 标签分隔各段，句子尽量短，一条指令一句，流程用编号步骤（最多 7 步），并显式给出字数或 token 预算、输出模板与不确定时的回退格式。对分类任务枚举全部有效类别，对抽取任务要求结构化输出。
使用方式：先判断任务是否需要蒸馏——输出可机械校验（schema、测试、计数、正则）时，用最小提示词加确定性校验器与失败重试更划算；需要判断（语气、相关性、质量、歧义）时才完整蒸馏；混合任务则拆分。Haiku 5.5 建议先写裸提示词（角色、任务、全部标签、输出 schema），用 10–20 条含边界情况的测试输入跑一遍，只针对失败处补最小规则或边界示例，通常收敛到 0–3 个示例。Haiku 4.5 则按 4–7 个多样示例设计，覆盖典型、第二典型、边缘、BAD/GOOD 负例与棘手边界，示例输出中的每个具体事实都必须能从该示例输入推出，且示例长度要落在规定区间内。
限制：资料未提供安装命令、价格以外的平台信息与完整代码示例；成本数据为 2026-10 定价，Opus 5.5 为 Haiku 5.5 的 40 倍、Sonnet 5.5 为 20 倍。不要指示 Haiku 5.5 的思考内容，需要的结果应放进可见输出；不要让它盲目循环自我改进，迭代需外部校验并保留最优、首次退化即停。改写与摘要需显式禁止编造。