聯繫我

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

• Email

前言

前七天講了不少原理：計價結構、context window、token 怎麼切。今天換個角度——不寫一行程式碼，你今天就能套用的五個習慣。

這篇特別寫給兩種人看：一種是每天在 claude.ai 網頁版或 App 上聊天、寫作、整理資料的一般使用者；另一種是會呼叫 API、但還沒把前面幾天的知識轉成具體動作的工程師。兩種情境的技巧其實共用同一套邏輯，只是動手的地方不一樣。

先講結論，再逐條拆解：省錢的優先順序，永遠是先管輸出、再管重複、最後才輪到精簡輸入。 這是 Day 2 就定調的順位，今天把它變成五個可以直接照做的動作。

目錄

技巧一：明確要求輸出長度與格式

Day 2 算過，output 單價是 input 的 5 倍。這代表任何能讓輸出變短的動作，效益都是同等輸入操作的 5 倍。

一般使用者在聊天視窗裡就能做——在問題後面直接加一句限制：

❌ 「幫我分析這份提案的優缺點」
✅ 「幫我分析這份提案的優缺點，用條列式列出最多 3 個優點、3 個缺點，每點限一句話」

開發者版本則是在 API 呼叫裡同時做兩件事：

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=500,                 # 設一道防線，不讓輸出失控
    messages=[{"role": "user", "content": "分析這份提案的優缺點，條列前3個優點與3個缺點"}],
)

max_tokens 是輸出長度的硬上限，但它不會讓模型「更精簡」，只會在超過時直接截斷。真正決定輸出品質與長度的是你的指令，max_tokens 只是保險絲，兩個一起用才踏實。

技巧二：先篩選，再貼上——不要整份丟進去

Day 5 講過 context rot：塞越多，模型越容易漏東西，而且輸出本身也算 context window 的一部分，塞多了不只貴，還可能讓答案變差。

一般使用者的動作：貼上長文件前，先花 10 秒鐘想「我真正想問的是哪一段」，只貼相關段落，而不是整份 PDF 或整封信件串。

開發者的動作是把這件事自動化——用便宜的方式（grep、關鍵字比對，甚至用 Haiku 4.5 做一輪前置篩選）先縮小範圍，再把篩過的內容送進主模型。這是 Day 5 提過的「用便宜的東西保護貴的東西」，在這裡是同一個原則的延伸。

技巧三：長對話適時開新的

多輪對話有一個反直覺的地方：每一輪 Claude 都要重新讀一次前面所有的對話歷史，才能生成這一輪的回答。 對話越長，每一次呼叫的 input token 就越多——即使你這一輪只問了一句話。

一般使用者可以做的事很簡單：如果話題已經轉向了、或者你只是想問一個跟前面無關的新問題，開一個新對話，而不是在原本已經很長的對話串裡繼續往下問。

如果你的工作真的需要維持一個很長的上下文（例如長時間的代理任務、跨多輪的專案協作），官方也提供了伺服器端的因應機制——這是 Day 12 的完整主題，今天先記住這個判斷原則就好。

技巧四：留意圖片與附件的隱藏成本

Day 5 提過，圖片與 PDF 一樣會佔用 context window、一樣算 input token，而且圖片的 token 成本通常不小——官方文件裡一張範例圖片就估算出破千 token。

一般使用者：如果你要問的問題只跟圖片裡的一小塊資訊有關（例如一張截圖裡的某個數字），考慮先裁切成只包含相關區域的圖片，而不是整張高解析度截圖直接貼上去。同一份文件如果要問很多次，也可以評估一次性讓 Claude 幫你把重點轉成文字，之後的追問改用文字溝通,而不是每次都重新解析同一張圖或同一份 PDF。

技巧五：把「重複的部分」跟「每次都變的部分」分開

這是本篇最偏開發者向、但一般使用者也能借用直覺的一條。

如果你每次呼叫都會帶一段固定不變的內容——公司的寫作風格指南、產品規格書、系統角色設定——這段內容值得被「快取」而不是每次原價重付。Day 9 會完整講怎麼設定，但今天你可以先建立這個直覺：

把穩定不變的內容放在前面、常常變動的內容放在後面。 這不只是為了快取（Day 9 的主題），也讓你的 prompt 結構更清楚——哪些是規則、哪些是這次的具體請求，一目了然。

一般使用者的類比版本：如果你常常用同一段「角色設定」開場（例如「你是一位資深文案編輯，語氣要...」），把它存成一個範本，每次貼上完全相同的文字，而不是每次都憑印象重新打一遍、每次都寫得不太一樣。內容穩定，才有被系統識別、被有效處理的基礎。

五個技巧的優先順序：出手前先問哪一題

五個技巧不是平行的清單，套用時有先後順序。遇到任何一次 Claude 互動，可以照這個順序問自己：

① 這次的輸出需要這麼長嗎？（技巧一）——這一題永遠先問，因為它命中的是 5 倍單價的那一端，效益最大。

② 我是不是把不相關的東西也貼進去了？（技巧二）——如果答案是「有」，先刪減，因為多餘的輸入不只花錢，還可能讓答案變差（context rot）。

③ 這是新話題還是延續？（技巧三）——延續就留在原對話，新話題就換一個乾淨的開始，不要讓歷史無限累積。

④ 附件是不是比需要的更大？（技巧四）——截圖裁切一下、PDF 只挑相關頁面，這一步常常被跳過，因為附件感覺「反正就是要傳」。

⑤ 這段內容我以後還會不會重複用到？（技巧五）——如果會，把它結構化成固定不變的模板，為 Day 9 的快取鋪路。

這個順序背後的邏輯，其實就是 Day 2 那個「單價 × 每次用量 × 呼叫次數」框架的簡化版：技巧一二四動的是「每次用量」，技巧三動的是「呼叫次數與每次基數」，技巧五動的是「單價」。 五個技巧看起來獨立，實際上分別對應著同一套帳單結構裡的不同乘數。

Before / After：把五個技巧疊在一起看

單獨看每個技巧，效益可能都不驚人。但實務上這五個習慣通常是疊加在同一次任務裡的：

❌ Before：一次典型的「隨手用」

使用者：把這整份 50 頁的年度報告，還有我們過去三個月的所有對話紀錄都貼給你，
       幫我寫一份給主管看的摘要，越詳細越好。

這個問法同時踩中四個雷：整份報告沒篩選（技巧二）、拖著三個月的舊對話歷史（技巧三）、沒有限制輸出長度、還要求「越詳細越好」（技巧一反著做）。

✅ After：套用技巧後的問法

使用者：（開一個新對話，只貼上年度報告裡「財務表現」與「明年計畫」兩章）
       幫我寫一份給主管看的摘要，限 300 字以內，用 3 個重點條列，
       每點附一個具體數字佐證。

同一個任務，After 版本開了新對話（技巧三）、只貼相關章節（技巧二）、明確限制長度與格式（技巧一）。三個技巧疊加後，這次請求的 input 和 output token 數，很可能只有 Before 版本的一小部分——而且因為餵給模型的內容更聚焦，答案的品質通常也更貼近你要的東西，不是「更詳細」而是「更準」。

本篇自我挑戰

• 今日挑戰：挑選你這週跟 Claude 最常見的一種互動模式（可能是聊天問答、可能是 API 呼叫），對照上面五個技巧，找出哪一個你完全沒做過。今天就套用一次，比較前後的 usage（API 使用者）或你自己感受到的回應長度（一般使用者）。

• 反思：這五個技巧裡，哪一個是你原本以為「無所謂」、但看完才發現其實影響很大的？我自己是技巧三——我以前總覺得「反正是同一個話題，就繼續往下問吧」，直到真正算過長對話的 token 消耗才改掉這個習慣。你有沒有類似「憑直覺以為沒差、但其實差很多」的地方？

總結

五個技巧背後其實是同一套邏輯的五種應用：先管貴的（output），再管重複的（快取），最後才是精簡輸入。

限制輸出長度直接命中 5 倍單價的那一端；篩選再貼上避免了 context rot 跟不必要的輸入成本；適時開新對話,避免每輪都重付整段歷史;注意附件成本,是很多人忽略的隱藏支出;把穩定內容跟變動內容分開,則是幫你的下一步——Prompt Caching——先鋪好路。

這些習慣沒有一個需要寫程式,今天就能開始用。

本日關鍵字回顧

• 輸出長度限制：在指令中明確要求格式與字數上限，命中 output 5 倍單價的優化槓桿。
• max_tokens：API 端的輸出上限保險絲,防止意外的超長輸出,但不取代明確指令。
• Context rot 的實務對策：先篩選再貼上,而非整份丟給模型判斷。
• 對話重複效應：每一輪都要重新讀完整段歷史,對話越長單輪成本越高。
• 穩定內容前置：把不常變動的內容放在 prompt 前段,是後續快取策略的基礎直覺。

明天我們把技巧五展開成完整篇章——Prompt Caching 到底怎麼運作、快取命中省下的 90% 是怎麼算出來的,以及什麼情況下設快取反而會虧錢。

Day 9，讓重複內容只算 10% 費用的秘密。