聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

「Haiku 能做什麼？」

這是大部分人問的問題，而我覺得它問錯了方向。

問「便宜的模型能做什麼」，預設立場是它比較弱，我們在盤點它的殘餘能力——像在問一個實習生「你會做什麼」。這樣問，答案永遠是一份令人失望的清單。

換個問法：「有哪些任務，根本不需要那些貴的能力？」

同一件事，立場完全反過來了。前者是在將就，後者是在配對。

我拿一個實際的數字讓你有感。Day 2 我們算過相對成本：Haiku 4.5 是 1×，Fable 5 是 10×。但這還只是標準價——如果把 Haiku 4.5 加上批次處理，跟 Fable 5 的標準價相比：

二十倍。

如果你手上有一批任務，是那種「量很大、每一筆都不難、但加起來很可觀」的任務——這二十倍就是你桌上的錢。

今天我們要弄清楚三件事：Haiku 4.5 到底是什麼、什麼任務適合它、以及它的天花板在哪裡。最後一點最重要，因為用錯地方的省，最後都會用更貴的方式還回去。

目錄

一、先誠實列出它「沒有」什麼

要用對一個工具，得先知道它的邊界在哪。我把 Haiku 4.5 相對於新世代三兄弟缺少的東西全部列出來——不美化：

這張表的最後三列，是我覺得最該提醒的：

effort 對它無效。 這件事很多人會踩到。你在 Day 14 學到的所有 effort 調校技巧，套到 Haiku 4.5 上完全沒用——因為它根本不在支援清單裡。它的思考深度只能用舊的 budget_tokens 參數設定（而且預設是關閉的）。

它的知識停在 2025 年 2 月。 這是四個模型裡最舊的，比 Opus 5 舊了一年三個月。任何跟「最近」有關的問題，它會很有自信地給你過時的答案。

它有一個新世代 Opus 沒有的東西：context awareness。 官方文件提到，Sonnet 5、Sonnet 4.6、Sonnet 4.5 和 Haiku 4.5 具備「脈絡感知」——API 會在系統提示裡告訴模型它的總預算，並在每次工具呼叫後更新剩餘量：

<budget:token_budget>200000</budget:token_budget>
<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

反而是 Opus 4.7 之後的 Opus 系列和 Fable 5 沒有這些注入標籤。又一個「越貴不一定越多」的例子。

二、四個問題，決定這個任務能不能交給 Haiku

Day 1 的自我挑戰我給過四個問題，今天把它變成正式的判斷流程。對任何一個任務，依序問：

① 這個任務需要超過 200k 的 context 嗎？

200k 大概是一份完整的技術文件加幾個檔案。如果你要餵整個 repo 進去——不行，換模型。

② 這個任務需要 2025 年 2 月之後的知識嗎？

注意，這裡問的是「需要模型自己知道」。如果你把最新資料直接放進 prompt 裡，那不算它的知識，那是 context——這題就過關了。很多看似需要新知識的任務，只要改成把資料餵進去就能降級。

③ 這個任務需要深度推理嗎？

判斷方式：這件事你自己做，需要「想一下」嗎？

「把這段話分成正面／中性／負面」——不用想，看一眼就知道。能降級。
「這段程式碼的並行邏輯有沒有 race condition」——要想，而且要想很久。不能降級。

④ 有人正在等這個回應嗎？

如果有——Haiku 4.5 是最快的那個，這反而是加分項。如果沒有——那你還能再疊一層批次折扣。

四題都通過，交給 Haiku 4.5。 有任何一題卡住，往上一階。

三、它真正擅長的五類任務

把上面的判準套用到實務上，會落在這五類：

① 分類與標記
情緒分析、垃圾訊息判定、工單分派、內容分級。輸入短、輸出更短、答案在固定集合內。

② 結構化抽取
從一段自由文字裡撈出欄位——發票金額、日期、人名、地址。這類任務的難度不在推理，在格式穩定，而 Haiku 4.5 配合 XML 標籤（Day 18）表現得相當可靠。

③ 格式轉換
Markdown 轉 HTML、JSON 重組、把口語紀錄整理成條列。原始資訊都在，只是換個殼。

④ 路由與前置判斷
這一類值得特別點名——用 Haiku 4.5 判斷「這個問題難不難」，難的才往上送給 Opus 5。這就是模型分流的骨架，Day 27、Day 28 會完整拆解。它是把「便宜模型」的價值放到最大的用法。

⑤ 高頻的小事
自動補全、即時建議、輸入檢查。這類任務單次都很便宜，但次數多到會累積成一筆可觀的帳。而且使用者盯著螢幕，速度就是體驗——Haiku 4.5 兩個優勢都佔到了。

四、它的天花板：三個不該交給它的地方

省錯地方的代價，通常比省下來的錢貴。三個紅線：

① 需要「發現你沒問的問題」的任務

「幫我 review 這段程式碼」——你要的其實是它找出你沒想到的問題。這需要主動探索，正是深度推理的核心。Haiku 4.5 會給你一份看起來很完整的 review，但它找到的都是表層的東西。

危險之處在於：它不會告訴你它漏掉了什麼。 你會拿到一份自信的答案，然後以為沒問題了。

② 多步驟、有狀態的工作流

它不支援 interleaved thinking（工具呼叫之間的思考），也不支援 adaptive thinking。跑一個要串五個工具、每步都得根據上一步結果調整的流程，它會在中途失去方向。

這正是 Fable 5 存在的理由（Day 1 的「跑馬拉松的那個」）——光譜的兩端。

③ 錯了不會被發現的任務

這條是原則，不只針對 Haiku。如果一個任務出錯之後沒有任何機制會抓到，那它就不該被降級。

分類錯了會被下游流程擋下來 → 可以降級。
摘要漏了關鍵資訊直接寄給客戶 → 不要降級。

這其實是 Day 3 那句話的延伸：降級的許可證是評測給的。 而當一個任務連「錯了」都偵測不到時，你根本沒辦法做評測——那就代表你沒有拿到許可證。

五、把折扣疊起來

如果任務通過了四道判準，而且不趕時間，折扣是可以疊加的。官方明載快取與批次的乘數會互相疊加：

❌ Before：五千筆客服對話分類，用 Fable 5 標準呼叫

for text in conversations:                      # 5,000 筆，逐一同步呼叫
    client.messages.create(
        model="claude-fable-5",                  # input 10× / output 50×
        max_tokens=16,
        messages=[{"role": "user", "content": SYSTEM_RULES + text}],
    )
# 每一筆都重付一次 SYSTEM_RULES 的 input

✅ After：換模型 + 快取共用前綴 + 批次提交

requests = [
    {
        "custom_id": f"conv-{i}",
        "params": {
            "model": "claude-haiku-4-5",         # input 1× / output 5×
            "max_tokens": 16,
            "system": [{
                "type": "text",
                "text": SYSTEM_RULES,
                "cache_control": {"type": "ephemeral"},   # 共用前綴進快取
            }],
            "messages": [{"role": "user", "content": text}],
        },
    }
    for i, text in enumerate(conversations)
]

client.messages.batches.create(requests=requests)        # 批次再打 5 折

拆開看這三層各省了什麼：

換模型：input 從 10× 降到 1×，這是最大的一刀。
快取：SYSTEM_RULES 那段分類規則五千筆都一樣，第一次寫入 1.25×，之後每次命中只要 0.1×。原本要重付五千次的東西，現在幾乎免費。
批次：input 和 output 再一起打 5 折，代價是不保證即時回來。

三層疊起來，同樣的工作、同樣的結果，帳單落在完全不同的量級。而且——這五千筆分類本來就不需要 Fable 5 的任何一項能力。 省下來的錢沒有換走任何東西。

（快取與批次的完整用法分別是 Day 9 和 Day 10，今天先讓你看到它們疊起來的樣子。）

六、換了模型，prompt 也得跟著換寫法

這是我自己踩過、而且踩得最重的一個坑：把原本給 Opus 5 用的 prompt 原封不動搬到 Haiku 4.5 上，然後判定「Haiku 不行」。

那不是 Haiku 不行，那是我沒改 prompt。

差別在哪？能力強的模型會自己補完你的意圖。 你寫「幫我看一下這則評論」，Opus 5 會自己判斷你大概想要情緒分析，然後給你一個結構合理的答案。Haiku 4.5 不會做這種推測——它會照字面做，然後你拿到一段沒有固定格式的自由發揮。

所以降級的時候，prompt 要跟著做三件事：

① 把開放式改成封閉式

不要問「這則評論怎麼樣」，要問「這則評論屬於下列哪一類：正面 / 中性 / 負面」。

限定輸出空間是對便宜模型最有效的一招。選項越明確，它越不會發散。

② 給範例，不要只給描述

「請判斷情緒」是描述。給它兩三個實際的輸入輸出範例（few-shot），效果好得多。

而且這招對便宜模型的邊際效益明顯大於對貴模型——貴模型光看描述就能推斷你要什麼，便宜模型需要你直接示範。

③ 用結構鎖住格式

XML 標籤（Day 18 的主題）在這裡特別有用。與其在指令裡拜託它「請只回答分類結果」，不如直接要求它把答案放進 <result></result> 裡——這樣你的程式也好解析。

❌ Before：直接把貴模型的 prompt 搬過來

prompt = f"幫我分析一下這則客戶評論：\n{review}"
# Haiku 4.5 回：一段三百字的自由發揮，格式每次都不一樣

✅ After：限定空間、給範例、鎖住格式

prompt = f"""將客戶評論分類為 positive、neutral、negative 其中之一。

<examples>
<example><input>東西很好用，出貨也快</input><result>positive</result></example>
<example><input>還可以，沒什麼特別的</input><result>neutral</result></example>
<example><input>等了兩週還沒到，客服也不回</input><result>negative</result></example>
</examples>

<input>{review}</input>

只輸出 <result> 標籤及其內容，不要其他文字。"""

後者多花的 input token 大概一百出頭——但它換來的是穩定可解析的輸出，而且省下 output（三百字變成一個詞，那可是 5× 單價的東西）。

更重要的是：它讓「Haiku 到底行不行」變成一個可以公平回答的問題。 用沒調整過的 prompt 去測便宜模型，測到的不是模型能力，是你的 prompt 有多依賴模型的腦補。

換句話說——降級失敗時，先檢查是不是 prompt 沒跟著降級。

本篇自我挑戰

• 今日挑戰：拿 Day 3 你列的那 20 個測試輸入，用 Haiku 4.5 跑一遍，跟 Opus 5 的基準逐案比對。

  但比對時請只看那 3~5 個難的案例。簡單案例通過是理所當然的，沒有資訊量。真正要記錄的是：它在哪一個案例上開始失守？失守的方式是什麼？（是答錯？還是格式跑掉？還是它自信地漏掉了東西？）

  失守的方式比失守這件事本身更有價值——它會告訴你 Day 27 的分流條件該怎麼寫。

• 反思：文中我說「它不會告訴你它漏掉了什麼」，這其實是所有便宜模型最危險的地方——失敗是靜默的。你有沒有遇過這種情況：一個結果看起來完全合理，你採信了，過了很久才發現它少了關鍵的一塊？那次你是怎麼發現的？如果重來一次，你會在流程的哪個位置放一道檢查？

總結

今天想改掉一個問法。不要問「便宜的模型能做什麼」，要問「有哪些任務不需要那些貴的能力」——前者是將就，後者是配對。

Haiku 4.5 確實少了很多東西：200k context、知識停在 2025 年 2 月、不支援 adaptive thinking、甚至不在 effort 參數的支援清單裡。但它有一件事做得最好——又快又便宜地處理不需要思考的事。分類、抽取、格式轉換、路由前置判斷、高頻小事，這五類是它的主場。

判斷方法是四個問題：要不要超過 200k？要不要新知識？要不要深度推理？有沒有人在等？ 四題都過，交給它；任一題卡住，往上一階。

而三條紅線要記牢：需要「發現你沒問的問題」的任務、多步驟有狀態的工作流、以及錯了不會被發現的任務——最後這條最重要，因為那代表你根本無法評測，也就拿不到降級的許可證。

本日關鍵字回顧

• Context awareness（脈絡感知）：模型追蹤自身剩餘 token 預算的能力。Haiku 4.5 與 Sonnet 系列具備，Opus 4.7 之後與 Fable 5 反而沒有。
• budget_tokens：extended thinking 的思考預算參數。Haiku 4.5 只能用它，不能用 effort。
• 靜默失敗（Silent failure）：模型給出看似合理但實際遺漏或錯誤的結果，且不主動示警。降級最主要的風險。
• 折扣疊加：Prompt Caching 的乘數與 Batch API 的 5 折可同時生效，官方明載兩者相乘。
• 路由前置判斷：用便宜模型先判斷任務難度，再決定是否上送——模型分流的基本骨架。
• Prompt 也要降級：便宜模型不會腦補意圖。降級時需限定輸出空間、給 few-shot 範例、用標籤鎖住格式。

明天我們處理另一個被誤解的東西：1M context。大家聽到「能塞一百萬 token」的第一反應都是「太好了，全部丟進去」。但官方文件裡有一句很直白的警告——「more context isn't automatically better」，而且他們給這個現象取了名字。

Day 5，我們聊 context window 與「脈絡腐化」。