聯繫我

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

• Email

前言

30 天，30 篇，走到終點了。

最後一天不講新東西，把前面 29 天濃縮成一份速查表——你之後不用重讀 30 篇文章，回來看這一篇就能找到大部分答案。 每個小節都會註明對應的完整篇章，需要細節時知道回哪裡查。

謝謝你跟著讀完這趟旅程。如果你是從某一天中途落地的讀者，也歡迎回頭挑感興趣的主題看——每篇都設計成能獨立閱讀。

本篇所有數字與規格，彙整自前 29 天已查證的內容，查證時間為 2026 年，閱讀時請留意時效性——這是本系列從第一天就強調的事：規格會變，結構性的判斷框架才是能留下來的東西。

目錄

一、四階模型速查（完整見 Day 1、Day 3、Day 4、Day 6）

選型判斷順序（Day 6）：先用 Day 3 的測試案例比較，不確定就從 Opus 5 起手；分類、路由判斷、高流量場景交給 Haiku 4.5；需要最強能力再上 Fable 5。

二、計價結構速查（完整見 Day 2、Day 9、Day 10）

批次處理（Batch API）：input／output 一律再打 5 折，可與快取疊加，命中率視流量模式落在 30%–98%。

帳單三乘數框架（Day 2）：總成本 = 單價 × 每次用量 × 呼叫次數——三者相乘，任何一項的改善都會被其他兩項放大。

三、省 Token 武器庫（完整見 Day 7-13）

四、設定調校速查（完整見 Day 14-20）

Effort 五檔位（output_config.effort，預設 high）：

Thinking 逐模型行為（完整表見 Day 15）：Fable 5 / Mythos 5 永遠開啟、拒絕 enabled 與 disabled；Opus 5 / Sonnet 5 預設開啟、Opus 5 在 effort xhigh/max 時額外拒絕 disabled；Haiku 4.5 僅支援 Extended 模式、拒絕 adaptive。

回答變淺排查順序（Day 16）：effort 是否被調低 → thinking 是否被停用 → 是否只是 display: omitted 看不到 → system prompt 有沒有抑制性措辭 → stop_reason 是否為 max_tokens。

Prompt 骨架七區塊（Day 17）：角色設定 → 情境動機 → 明確指令 → 範例 → XML 包裹的輸入資料 → 輸出格式規範 →（長文件）內容前置。

降低幻覺三招（Day 20）：允許說不知道、超過 20k token 先引用再推理、要求逐項引用驗證找不到就撤回。

五、開發者實戰速查（完整見 Day 21-26）

Claude Code：curl -fsSL https://claude.ai/install.sh | bash（macOS/Linux）；/clear 切換不相關任務、/compact 處理同任務歷史增長；CLAUDE.md 控制在 200 行內，專門流程搬去 skills。

MCP Connector：mcp_servers 定義連線、tools 裡的 mcp_toolset 定義權限；目前版本 mcp-client-2025-11-20；僅支援工具呼叫、伺服器須公開於 HTTP。

Messages API 三個必要參數：model、max_tokens、messages；API 無狀態，多輪對話要自行組完整歷史；金鑰絕對不能出現在前端程式碼裡。

Streaming 事件流程：message_start → content_block_start/delta/stop 循環 → message_delta（usage 為累積值）→ message_stop；中途錯誤以獨立 error 事件送出。

錯誤碼：429（你的責任，撞速率限制）vs 529（非你的責任，伺服器過載）；SDK 預設自動重試兩次、指數退避、尊重 retry-after；Messages API 沒有內建冪等鍵，有副作用的工具呼叫要自己做去重。

六、架構思維速查（完整見 Day 27-28）

模型分流的學術根據：FrugalGPT（Chen, Zaharia, Zou，史丹佛，2023，arXiv:2305.05176），LLM Cascade 概念的重要出處，成本最高可降 98%。Claude API 沒有內建自動分流功能，需自行設計。

三層架構：前置分流層（Haiku 分類）→ 主要處理層（依難度選模型/effort）→ 品質驗證層（不確定才升級）。分流本身失敗時，保守原則是預設當作複雜任務處理。

七、十個常見誤解總整理

這 30 天推翻的直覺，濃縮成一張表。可以把它紀錄下來!

補充一個最多人問、但答案跟直覺相反的

「我用空行、---- 分隔線、| 畫表格，是不是能幫 AI 更好地理解我的意思？」

這題值得單獨講，因為官方文件的說法跟多數人的假設不在同一個方向：

"The formatting style used in your prompt may influence Claude's response style. (...) For example, removing markdown from your prompt can reduce the volume of markdown in the output."

（你在 prompt 裡使用的排版風格，可能會影響 Claude 的回應風格。（⋯）舉例來說，把 markdown 從你的 prompt 裡拿掉，可以減少輸出中 markdown 的數量。）

注意它講的是「回應風格」，不是「理解程度」。

換句話說，官方明確記載的效果在輸出端——你的 prompt 長什麼樣，它的回答就傾向長什麼樣。你塞滿條列，它就回你一堆條列；你寫成流暢的段落，它也比較會用段落回你。

那到底什麼排版是官方明確推薦的？ 兩件事：

• XML 標籤——這是官方唯一明確背書的結構化方式，用來區隔指令、背景、輸入資料（Day 18 完整講過）
• 有順序性的步驟用編號清單——但官方加了條件：「當順序或完整性真的重要時」

而「---- 分隔線」「| 表格」「多打幾個空行」這些具體寫法，我沒有找到官方的逐字說明。 照這系列的規矩，這裡就留白——不是說它們沒用，是說我查不到官方依據，不能替它們背書。

如果你要一個實用的結論：想讓它更懂你，用 XML 標籤；想讓它換個方式回你，改變你自己的排版風格。 這兩件事都有官方依據，其餘的靠你自己實測。

八、30 天知識地圖：三條主線怎麼交織

回頭看，這 30 天其實只在講三件事,只是排列組合出了 30 種角度：

主線一：計價結構（Day 2 起）→ 具體化成省錢技巧（Day 7-13）→ 收斂成分流架構（Day 27-28）。

主線二：模型與參數的行為（Day 1、Day 14、Day 15）→ 具體化成 prompt 與除錯技巧（Day 16-20）→ 落地成開發實戰（Day 21-26）。

主線三：怎麼問、以及怎麼判斷答案可不可信（Day 17-20 的 prompt 與防幻覺，Day 29 收在「你不知道要問什麼」的盲區）→ 這條線不是知識本身，是取得所有知識時該有的警覺。

如果你只能記住一件事，記住這句話——規格、價格、參數會變，但「先理解結構、再套用技巧、遇到不確定就查證而不是憑印象」這個做事方法不會過期。

九、如果你只有五分鐘：三個立刻能做的動作

不想重讀速查表，只想要三個現在就能動手做的事：

① 打開你最近一次的 Claude API 呼叫紀錄，看 usage 欄位。 檢查 cache_read_input_tokens 是不是 0——如果是，代表快取完全沒有在運作，Day 9 的內容值得回頭看一次。

② 檢查你的 system prompt 或角色設定，問自己「拿掉這句話，行為會不會有具體改變」。 答案是「不會」的句子，就是 Day 19 講的裝飾性角色，值得改寫成有具體標準的版本。

③ 找一個你目前不管任務難易度都用同一個模型處理的地方，估算看看如果分流,能省多少。 哪怕只是先做這筆估算,不真的動手改架構,也能讓你對 Day 27、Day 28 的內容有具體的感受，而不只是抽象的原則。

十、寫在最後：我對「AI 會不會取代工程師」的判斷

前面九節都在講怎麼把工具用對。最後這一節不查文件、不列表格，我想講一件跟參數和價格都無關的事——這是我寫完 30 天之後，真正想說的話。

「AI 會不會取代工程師？」這題你一定看過無數次。多數人的答案是「不會啦，它只是輔助」。

我的答案是：會。

我不覺得說「會」是在製造恐慌。我反而覺得那句「不會啦，它只是工具」才是真的沒幫上忙——它讓人安心，然後什麼都不用改變。

但我得先把「取代」這兩個字講清楚，不然很容易被誤讀。

被取代的不是「人」，是「門檻」

沒有人天生就該做什麼職業。

「工程師」之所以曾經是一種職業，很大一部分原因是：「把一個想法變成能跑的東西」這件事，過去有很高的技術門檻。 你得先學語法、學框架、學部署，才跨得過那道牆。那道牆，就是這個職業的護城河。

現在那道牆正在垮。而且我認為它不只對工程師垮——是對每個人垮。 往後，「把自己的想法實現出來」不會是某一群人的專業，它會變得像打字、像用試算表一樣，是每個人都該會、也做得到的基本能力。

所以真正被取代的，是「會寫程式」這件事本身作為身分標籤的價值。

那我們往哪裡走？

AI 本來就強的地方，就讓它做。它寫得比你快、改得比你勤、而且不會累，跟它比這個沒有意義。

我們的位置是往上移一層：把一個想法的「安全界線」，有邏輯地規劃出來。

界線是什麼？是這個東西在什麼條件下可以用、什麼條件下不行；是資料放在哪裡、誰看得到；是失敗的時候會發生什麼事、有沒有人會因此受損；是它跑錯了，你多久會發現。

這些事情，AI 不會主動替你想——這正是 Day 29 整篇在講的：門檻降低的是「做出來」，不是「做對」。

打個比方：AI 等於發了駕照給所有人。但會開車，跟能載客上路，中間隔著保險、路權、定期檢驗，以及出事時你要負的責任。 現在很多討論停在「我也會開車了」，而真正的專業，從來都在後面那一段。

請把一個舊問題放下

我想請大家別再把力氣花在這個問題上：「AI 哪天壞掉怎麼辦？」「不能用了怎麼辦？」

這問題預設了 AI 是一個外掛的、可有可無的東西。但它現在更接近電力——你不會因為「停電怎麼辦」就決定不裝電燈，你會做的是確認線路安全、裝上斷路器。

而且說實話，真正的風險不是它壞掉，是它好好地運作，而你不知道它做出來的東西哪裡有洞。 壞掉你至少看得見；這種你看不見。

變化速度，決定了你該學什麼

我寫這 30 天的過程中，模型換代、版本更新一路沒停過。連我自己查證過、白紙黑字寫進文章裡的價格資訊，都因為官方中途調整而必須回頭訂正——這系列從 Day 1 開始寫到現在就變了好幾次。

告訴我們什麼? 所以我的建議很直接：不要把力氣花在背某一家的規格。

規格會過期，但下面這三件事跨模型都通用，而且不會過期：

• 怎麼使用——它的輸入輸出結構、它擅長與不擅長的任務形狀
• 安全界線在哪——什麼能給它、什麼絕對不能給、輸出要驗證什麼
• 底層機制是什麼——為什麼它會這樣回答，而不是背下它這次回答了什麼

這正是整個系列從第一天就在做的事：不背價目表，理解計價結構；不抄 prompt 模板，理解骨架為什麼長這樣。

最後：做出來，跟做得起來，是兩件事

也因為這樣，我對「你看我用 AI 做出了某某網頁」這種展示，感受一直很複雜。

做出來，只證明你有想法，不證明你會正確用 AI。

我認為接下來真正值錢的是這幾件事：怎麼保護你的想法、怎麼讓它能安全地上線、怎麼讓別人敢放心地用、怎麼讓它真的帶得出價值。

一個跑得起來的 demo，跟一個能交到使用者手上的產品，中間那段距離 AI 不會主動告訴你——你得自己知道要問。

本篇自我挑戰

• 今日挑戰：把這篇存起來當書籤。下次遇到「這個設定該怎麼用」的疑問時，先回來查這篇的速查表，找不到答案再回頭讀對應天數的完整篇章。

• 反思：30 天走完，你對「用得對、用得省」這兩件事的理解，跟第一天開始讀的時候比,有什麼具體的改變?如果要用一句話總結你自己的收穫，會是哪一句?

總結

30 天到這裡結束了。從 Day 1 的四階模型比較，到今天的總整理，這系列想證明的事情很單純：Claude 的使用不是一堆零散的技巧,是一套可以被理解的結構——計價怎麼算、模型怎麼選、參數怎麼調、架構怎麼搭,每一層都有邏輯可循,不需要死背。

謝謝你讀到這裡。如果這系列對你有幫助，歡迎透過開頭的 Email 告訴我、或是留言；如果你發現任何過期或該修正的地方，也請告訴我。

很謝謝你看完這 30 天。我已經開始期待明年——期待在鐵人賽再見到大家，也期待到時候我們要面對的，會是一個比現在更衝擊、更難預測的 IT 新生態。

本日關鍵字回顧（全系列 30 個關鍵詞速記）

• 1:5 計價比例、三個乘數框架、Context rot、Prompt Caching、Batch API、Tokenizer 換代、Compaction、Cache-aware ITPM、Effort 五檔位、Adaptive Thinking、Prompt 骨架七區塊、XML 標籤、功能性角色設定、先引用再推理、CLAUDE.md 200 行原則、MCP Connector、無狀態 API、SSE 事件流程、429 vs 529、LLM Cascade、三層分流架構——這 21 個詞，加上前面五節速查表裡的所有數字，就是這 30 天最濃縮的版本。

《Claude 用得對，也用得省：工程師帶你搞懂選模型、Token 優化與底層邏輯》，全系列完，明年見^^!