前陣子在群組裡跟朋友聊起，他還在苦惱怎麼寫出「完美 Prompt」，把公司的 SOP 一條條塞進系統提示詞裡，塞到 Token 都快爆了，結果 AI 還是三不五時忘記某個規則，或是把步驟做錯順序。我看了看，只跟他說了一句：「你現在煩惱的問題，已經是上一代的問題了。」

這一年多我自己在專案裡，明顯感覺到 AI 助理的架構正在經歷一次轉型：以前是你把知識餵給它，它負責回答；現在是你把工具和權限交給它，它自己去把事情做完。前者是 Prompt 工程，後者就是現在 Claude Skills、MCP（Model Context Protocol）在做的事。

Prompt 工程：把知識塞進一份說明書

Prompt 工程的核心邏輯很單純：模型的能力是固定的，我們能動的只有「餵給它什麼文字」。所以整個工作變成不斷調整系統提示詞——把公司規範、範例、格式要求、邊界條件，全部寫進一份越來越長的說明書，期待模型讀完之後乖乖照做。

這個做法有它的天花板。說明書寫得越詳細，Token 成本越高，模型越容易在一堆規則裡選錯優先順序；而且每次流程一變，你就得回頭改說明書，改完還要重新測試會不會把別的規則弄壞。說到底，你只是在用文字去描述系統應該有的能力，文字終究只是文字，模型讀得懂不代表它真的能穩定做到。

Skills / MCP：把能力直接交給它

Skills 和 MCP 做的是另一件事：與其用文字去描述一個工具該怎麼用，不如直接把那個工具接上去，讓模型能真的呼叫它、拿到真實的回傳結果，再決定下一步。MCP 定義的是一套標準協議，讓任何服務（資料庫、內部系統、第三方 API）都能用同一種方式被 AI 助理發現、理解、呼叫；Skills 則是把一套做事的最佳實踐包裝成模型可以隨時載入的模組，需要的時候才讀，不需要就不佔用上下文。

這個差異用架構師的話講，很像介面跟文件的差別。以前我們寫一份很詳細的操作手冊，指望開發者（也就是模型）看完手冊自己在腦中組裝出正確的行為；現在我們直接定義好 Interface，讓模型呼叫，拿到的是結構化、可驗證的結果，猜測的空間小很多。

我自己在專案裡明顯感覺到三個轉變：

第一，錯誤的性質變了。以前模型出錯，多半是理解錯了規則，或是編出了根本不存在的東西；現在模型出錯，更多是呼叫工具時參數給錯，這種錯誤反而更好抓——工具呼叫失敗會直接回傳錯誤訊息，模型甚至可以自己重試修正，比起藏在文字裡的幻覺好抓多了。

第二，可維護性變了。以前規則變更要改提示詞、要重新測試整份說明書有沒有互相打架；現在規則變更多半發生在工具本身或 Skill 的定義裡，AI 助理端幾乎不需要重新調教，因為它一直都是照著介面呼叫，介面背後怎麼變是另一回事。

第三，權限跟責任的邊界變清楚了。這其實跟我前陣子寫的「別讓權限限制了效率」是同一個道理——與其在提示詞裡寫一堆「請不要做 XX」，不如根本不要把那個工具開放給它。能力邊界用架構去畫，比用文字去勸說牢靠得多。

這對開發者意味著什麼

我覺得這波轉變對工程師來說，其實是好消息。過去把 AI 導入產品，很大一部分工作是在調教語言；現在這部分工作正在轉移成設計工具介面——這是我們本來就擅長的事：定義清楚的 API、明確的輸入輸出、可預期的錯誤處理。

Prompt 工程不會消失，清楚的指令跟情境描述還是需要，只是它會慢慢從主戰場退回配角的位置。真正決定一個 AI 助理好不好用的，是你幫它接上了哪些工具、那些工具的介面設計得多乾淨，系統提示詞寫得再長也補不回來。

跟 TDD 那篇的結論有點像：AI 越來越像一個隨叫隨到、動作很快的工程師，但真正決定它能不能把事情做對、做得穩，靠的還是我們有沒有把系統的骨架——工具、介面、邊界——設計清楚。這件事，永遠不會過時。