為什麼「微管理」你的 AI Agent，反而會讓它們變笨？

今天隨便打開一個現代 GitHub repo 裡的 system_prompt.txt，你會看到什麼？通常是一大段密密麻麻、充滿焦慮的文字。「絕對不要做 X。你必須精準輸出三個重點。永遠不要使用這個函式庫。」

開發者們正把人類歷史上最先進的推理引擎，當作脆弱的正規表達式 (regex) 腳本在對待。

從歷史角度來看，這種偏執完全可以理解。就在一兩年前，早期的 LLM 還需要我們像牽小孩一樣手把手地指導，才能勉強保持在主題上。但時代變了。現代的模型已經聰明得令人難以置信，而我們寫 prompt 的方式，卻還像是在為 1980 年代的微波爐寫程式。我們試圖把「智慧」寫死 (hardcode) 在程式碼裡。

最近 Vercel 發生了一件很有趣的事，正好證明了這一點。他們的工程團隊發布了一篇關於如何改進 v0 產品的深度解析，詳細說明了一個違反直覺的舉動：他們移除了 agent 80% 的工具。

結果呢？系統並沒有崩潰。它反而變得更好了。透過剝除那些過度規定的工具和死板的限制，他們減少了模型的混淆，讓模型能專注發揮它最擅長的事——對問題進行推理。更少的摩擦，帶來了更好的程式碼。

對於現在任何正在打造 AI 應用的開發者來說，這裡有一個深刻的教訓：給予原則，而不是死板的規則。

當你一步步精確地告訴 LLM 該做什麼時，你迫使它將有限的注意力（運算資源）花在「服從指令」上，而不是「提升品質」。你剝奪了它利用龐大訓練數據，去尋找比你 hardcode 的方案更優雅的解決辦法的能力。

要看出其中的差異，我們可以看看大多數開發者是如何寫 agent prompt 的，以及他們應該怎麼寫。

糟糕的做法（死板的規則）：

「寫一個獲取使用者資料的 Python 函式。你必須使用 requests 函式庫。你必須用 try/except 區塊來處理錯誤。你必須回傳一個精準包含 'name'、'email' 和 'status' 鍵值的字典 (dictionary)。不要使用 async。每一行都要加上註解。」

好的做法（原則與目標）：

「寫一個穩健的 Python 函式來獲取使用者資料。傾向使用現代、標準的函式庫。程式碼必須達到 production-ready（生產環境就緒）的標準，這意味著它能優雅地處理網路錯誤和邊緣情況 (edge cases)。將可讀性和乾淨的架構置於賣弄聰明的寫法之上。下游系統預期接收標準的使用者個人資料格式 (name, email, status)。」

注意到這種轉變了嗎？第一個例子把 AI 當作一個不值得信任的初階開發者 (junior developer)。第二個例子則把它當作一個了解目標與脈絡的資深工程師 (senior engineer)。你告訴它好的產出長什麼樣子以及為什麼，然後你退一步，讓它自己去找出如何達成。

當然，這個規則有一個重大的例外。

當 agent 在與其他 agent 對話時——或者當上游 agent 將資料傳遞給嚴格的下游資料庫解析器時——你需要絕對的嚴謹。機器對機器 (Machine-to-machine) 的交接需要精確、毫不妥協的 JSON schema。但如果是為了推理、生成和解決問題呢？鬆開你的手吧。

如果你今天想立刻升級你的寫扣助手 (coding assistants)，請直接複製並貼上這段內容到你的 claude.md、memory.md，或是你 agent 的核心 system prompt 中：

## Prompt Writing Philosophy
When writing LLM prompts (system prompts, skill specs, subagent prompts): **give principles, not rigid rules.**
- Tell the LLM what good output looks like and why — let it figure out how
- Avoid prescribing exact fields, counts, or formats unless the output is a machine-consumed intermediate
- Exception: structured handoffs between agents can be rigid because downstream agents need consistent field names

別再試圖微觀管理 (micromanage) 機器了。相信現代的 LLM 吧。當我們不再把牠們當作什麼都不懂的小孩對待時，它們會變得更快、更聰明，而且能力無可限量。