AI 寫程式很便宜，好程式沒有——Simon Willison《Agentic Engineering Patterns》導讀

2026-06-14 · 作者 / 史旺基

關於 AI 寫程式的內容，現在多到爆炸。但老實說，大部分都是技巧型的——這個快捷鍵、那個外掛、某個 prompt 模板——很實用，可是過幾個月工具一改版就半數失效。

最近讀到一份難得的例外。

Simon Willison 把他這一兩年用 coding agent 開發的實戰，整理成一份叫做 《Agentic Engineering Patterns》 的指南。如果你不認識他——他是 Django 框架的共同作者、開源工具 Datasette 的作者，也是這幾年寫 LLM 實務寫得最勤、最務實的人之一。

這份指南刻意不寫「某個工具怎麼操作」，而是去萃取那些能被實際驗證有效、又不太會因為工具進步就過時的原則。它分成六大主題、十幾篇文章，而且他明講這是一份「持續進行中」的活文件，沒有任何一章算完稿。

我把全文從頭到尾讀完，這篇是我的導讀。我會挑出我認為台灣技術團隊最該吸收的幾個重點，配上我自己在公司帶 Claude Code 導入時的對照。文末有原文連結，我強烈建議你直接去讀原文——以下是我的整理與觀點，引用到 Simon 的句子我都會標出來。

先把詞講清楚：agentic engineering 不是 vibe coding

Simon 對「代理式工程（agentic engineering）」的定義很樸素：借助程式代理（coding agent）來開發軟體。而他對「代理（agent）」的定義更精煉：

“Agents run tools in a loop to achieve a goal.” —— Simon Willison

代理，就是「在一個迴圈裡反覆呼叫工具、以達成某個目標」的東西。對程式代理來說，這組工具裡最關鍵的一個，就是能夠執行程式碼。他甚至把這件事提到決定性的高度——少了執行能力，大型語言模型（LLM）吐出來的內容價值有限；一旦能執行、能反覆驗證，單純的文字生成才被提升成了工程。

接著他做了一件我很認同的事：把 agentic engineering 跟 vibe coding 清楚分開。

vibe coding（憑感覺寫程式）這個詞是 Andrej Karpathy 提出的，原意很特定——你對 AI 下提示詞、把它生出來的東西直接接受，甚至不去管它對不對。很多人後來把這個詞擴大成「只要用 AI 產程式碼」都算，但 Simon 明確反對：

“Some people extend that definition to cover any time an LLM is used to produce code at all, but I think that’s a mistake.” —— Simon Willison

他主張的分界線是：vibe coding 指的是未經審查、原型品質的產出；而代理式工程，是要把程式碼提升到上線品質、由作者親自把關過的。差別不在用不用 AI，而在有沒有人審查、有沒有達到可交付的標準。

這跟我一直在講的兩件事完全是同一回事——把 AI 當成「需要被好好帶領的高級實習生」，以及越懂工程的人越能把 AI 用出價值。工具把打字變便宜了，但「判斷該寫什麼、把關品質」這件事，依然牢牢握在人手上。

整份指南最該被框起來的一句：好程式仍有成本

如果這份指南只能記一句話，我會選這句的概念：

“Delivering new code has dropped in price to almost free … but delivering good code remains significantly more expensive than that.” —— Simon Willison

交付「會動的程式碼」已經幾乎免費；但交付「好程式」，依然很貴。 這兩件事不是同一回事。

而且 Simon 不是含糊喊口號，他把「好程式」攤開成一張很具體的清單：功能正確、解對問題、錯誤處理得宜、夠簡潔、有測試覆蓋、文件最新、設計可維護，還有一整排非功能性需求——可及性、安全性、可測試性、可靠性、可觀測性、可擴展性。

工具能幫你做掉上面很多項，但他畫了一條關鍵的責任線：工具能分攤勞動，卻不能轉移責任。 最終產出是不是「好程式」，仍由握方向盤的人負責。

這一點，我認為台灣團隊要特別警惕。我們很多團隊本來就背著沉重的技術債，最危險的就是把「寫程式變便宜了」誤讀成「可以免洗」——省掉測試、跳過文件、忽略可及性與安全性。正確的方向剛好相反：當 AI 把產出加速了，你反而更有餘裕、也更該嚴格地守住這些非功能性需求。

指南裡還有一個我很喜歡的習慣轉變。過去因為寫程式很貴，遇到沒把握的邊際點子，理性的反應是「別做，不值得花時間」。但現在 token 很便宜、真正稀缺的是人的注意力——所以該把「先否決」的本能，換成「先丟一個 prompt 去非同步跑跑看」。最壞不過是十分鐘後回來看一眼，發現果然不值得。守門的直覺，該被便宜的實驗取代。

想把 AI 用好，先懂它怎麼運作

很多人用 coding agent 像在用黑盒子。Simon 花了一整章拆解它的內部：說到底，就是 LLM ＋系統提示（system prompt）＋一組工具，在一個迴圈裡反覆對話；他也解釋了 token 快取為什麼重要。

為什麼工程師該懂這層？因為它直接決定你的操作習慣——你會更知道怎麼寫 prompt、怎麼管理 context、為什麼不該在一個 session 裡反覆橫跳把快取打壞。理解原理的人，才不會把 AI 當神諭亂拜。

這一段裡我覺得最實用的是子代理（subagents）：用像 Claude Code 的 Explore 子代理去讀檔、探索，把摘要帶回來，讓主對話的 context 保持乾淨；需要時開平行子代理同時跑多個任務；甚至建立固定用途的專家子代理。這跟我之前整理 Claude Code 實戰技巧時談到的平行工作流、用子代理保持主脈絡乾淨，是完全一致的方向。

測試與 QA：把「自我驗證」變成預設

整份指南有三章都在談測試，這個比重本身就是一種主張。它們講紅燈／綠燈 TDD、講「先把測試跑起來」、講代理式手動測試——讓代理用瀏覽器自動化自己去點、自己驗 UI、自己截圖記錄過程。

三章其實指向同一件事：給 AI 一個能自己判斷對錯的迴路，而不是讓它做一步就把半成品丟回來叫你看。

這正是我反覆強調的「工作閉環」。我帶團隊時最常修正同仁的一個地方，就是不要接受 AI 說「請你打開檔案確認一下」——那只是把工作切碎丟回給你。成熟的用法是要求它形成完整迴路：

理解任務 → 執行任務 → 自我檢查 → 修正問題 → 交付可驗收成果。

落到操作上很簡單：把「跑測試，若失敗就修到通過再結束」直接寫進你的交辦 prompt。一句話，成果品質就明顯不同。

理解陌生程式碼的新玩法

這部分對接手舊系統、帶新人的人特別有感。Simon 介紹了用 AI 做線性逐步導覽與互動式解說——讓 AI 針對一段陌生的程式碼或一份資料，產生一份一次性的、甚至可互動的解說（有時就是一個小工具），幫你快速建立理解。

我自己的對照是：把 AI 當「程式碼導覽員」，是新人上手與接手 legacy 專案時最低風險、最高報酬的用法之一。先不要叫它改大功能，先請它帶你讀懂這塊地形。

附錄才是隱藏寶藏：把提示詞當資產，和一條紅線

很多人會跳過附錄，但這份指南的附錄我認為價值最高。Simon 把自己日常在用的幾個 prompt 直接公開——校稿、寫圖片替代文字（alt text）、從 podcast 逐字稿挑金句、用 Claude 做可攜的小工具。

它們有一個共同的設計哲學：幾乎都被沉澱成 Claude 專案的自訂指令，而不是每次重打。換句話說，他把「重複使用的意圖」固定成一段系統提示，之後只要把素材丟進去，就能得到穩定一致的輸出。這呼應了指南另一個核心概念——把你會做、好用的東西「囤積」起來、重組，變成可重複呼叫的資產。好的 prompt 不該是一次性的靈感，而該是版本控管得起來的團隊資產。

附錄裡還有一條紅線，我非常認同。Simon 會用 LLM 校稿、更新文件，但他立了一條界線：

“My hard line is that anything that expresses opinions or uses ‘I’ pronouns needs to have been written by me.” —— Simon Willison

凡是表達觀點、會掛上他名字、用到「我」的內容，都必須他本人親手寫。

我會把這條延伸成一個給團隊的建議：每個團隊都該有一份簡單的 AI 使用守則，講清楚哪些工作可以交給機器（格式整理、挑錯、寫草稿、篩選資料），哪些必須由人親手把關（觀點、判斷、對外掛名的內容）。把這條線講清楚，不會限制效率，反而會建立讀者與客戶對你的信任。

結語：在喧囂裡，它給的是不會過時的原則

我讀完最大的感受是：這份指南真正珍貴的，不是任何一個單一技巧，而是它刻意只萃取原則。工具每幾個月就換一輪，但「好程式仍有成本」「給 AI 自我驗證的迴路」「把提示詞變資產」「掛名的內容自己寫」這些，會跟著你很久。它還是一份會持續更新的活文件——這本身就是面對這個領域該有的態度：與其追逐技巧，不如沉澱原則。

如果你讀完只想先做三件事，我的建議是：