引言
2025 年底開始，一個新詞彙在開發者社群中快速傳播：Vibe Coding。Andrej Karpathy 用這個詞描述一種全新的寫程式方式——你不需要真的看懂程式碼，只要對著 LLM 描述你想要什麼，它就幫你生出來。對非工程師來說，這像是魔法；對專業工程師來說，這……讓人有點不安。
但故事還有另一面。當專業工程師開始使用 Claude Code、OpenAI Codex、Cursor 這類 coding agent 時，他們發現這不只是「幫你打字」那麼簡單。這些工具能生成程式碼、自己跑測試、看到錯誤再修正——形成一個完整的開發迴圈。這種工作方式，Simon Willison 稱之為 Agentic Engineering。
Simon Willison（Django 共同創始人、Datasette 作者）最近發布了一系列關於 Agentic Engineering Patterns 的文章，系統性地整理了他在實際使用 coding agent 過程中歸納出的工程模式。這篇文章，我們來拆解其中兩個最核心的 pattern。
什麼是 Agentic Engineering？
先釐清一個關鍵區別：
| Vibe Coding | Agentic Engineering | |
|---|---|---|
| 使用者 | 非工程師、初學者 | 專業軟體工程師 |
| 目標 | 快速做出東西 | 加速高品質開發 |
| 對程式碼的態度 | 不太看、不太懂 | 完全理解、主動審查 |
| 品質保證 | 能跑就好 | 測試、文件、可維護性 |
Vibe Coding 沒有錯——它讓更多人能夠用軟體解決問題，這是好事。但 Agentic Engineering 解決的是不同層次的問題：如何讓有經驗的工程師，透過 AI agent 達到更高的產出品質和速度？
核心概念是：coding agent 不只是自動補全（autocomplete），它是一個能夠獨立執行、測試、迭代的開發夥伴。你給它一個任務，它會寫 code、跑測試、看到失敗、修正、再跑——直到通過。這個「能自己跑起來驗證」的能力，才是 agent 和傳統程式碼生成工具的根本差異。
Pattern 1：寫程式碼現在很便宜了
這是 Simon 提出的第一個核心觀察，也是最容易被誤解的一個。
程式碼一直是昂貴的
一個資深工程師，一天能產出多少行「乾淨的、可以合併的」程式碼？幾百行已經算很好了。這不是因為打字慢，而是因為寫程式碼的成本從來不在「打字」上：
宏觀層面： 我們花大量時間在設計架構、估算工時、規劃迭代、開會對齊需求。真正坐下來寫 code 的時間，可能只佔一天的 30%。
微觀層面： 即使在寫 code 的時候，工程師每分鐘都在做 tradeoff 決策——這個變數要不要抽成常數？這段邏輯要不要拆成函式？錯誤處理要做到什麼程度？每一個決策都消耗認知資源。
Agent 改變了什麼？
Coding agent 把「打字寫 code」的邊際成本降到趨近於零。你可以用一句話讓 agent 生成一個完整的函式、一個 API endpoint、甚至一整個模組。這很驚人，但 Simon 強調了一個重要的但書：
寫程式碼變便宜了，但好的程式碼仍然昂貴。
什麼是「好的程式碼」？能正確執行、有完整測試覆蓋、有清楚的文件、容易維護、沒有安全漏洞、效能合理……這些特質不會因為 agent 幫你打字就自動出現。
重新校準直覺
這裡有一個深刻的洞察：我們每個工程師腦中都有一個「這值不值得做」的直覺。過去，因為寫 code 很貴，很多事情我們會選擇不做——不寫那個 edge case 的測試、不重構那段醜陋但能動的程式碼、不為內部工具寫文件。
現在，當「寫 code」的成本大幅下降，這些直覺需要重新校準。以前「不值得花兩小時做」的事，現在可能只需要跟 agent 說一句話、等三分鐘。
CaveGeek 觀點： 這讓我想到一個類比——當雲端儲存變便宜後，我們不再糾結「這個檔案值不值得留」。同樣地，當程式碼生成變便宜後，我們應該重新思考「這個測試值不值得寫」、「這段 code 值不值得重構」。答案很可能從「不值得」變成「讓 agent 去做吧」。
Pattern 2：Red/Green TDD
第二個 pattern 更具體、更可操作，也是我認為最適合立刻開始實踐的一個。
傳統 TDD 簡單回顧
Test-Driven Development（測試驅動開發）的核心流程：
- 🔴 Red： 先寫一個測試，描述你期望的行為。跑測試，確認它失敗（因為還沒有實作）。
- 🟢 Green： 寫最少量的程式碼，讓測試通過。
- 🔄 Refactor： 在測試保護下，重構程式碼。
這個方法論已經存在二十多年了，但說實話，很多團隊在實務上並不嚴格執行——因為「先寫測試」感覺很慢、很麻煩。
為什麼 TDD 和 Coding Agent 是絕配？
Simon 指出，Red/Green TDD 在 agent 時代變得特別重要，原因有三：
1. 測試是你給 agent 的「驗收標準」
當你先寫好測試（或讓 agent 先寫測試、你來審核），你就定義了「什麼叫做完成」。Agent 會寫 code、跑測試、看到紅燈、修改、再跑——直到全部綠燈。沒有測試，agent 怎麼知道自己寫的東西是對的？
2. 防止 agent 作弊
沒有測試約束的 agent，可能會生成「看起來對但其實沒用」的程式碼。有了測試，它必須通過具體的驗證才算完成。
3. 自動建立安全網
每次用 TDD 方式完成一個功能，你就多了一組測試。隨著時間累積，你的測試套件會越來越完整，未來不管是人類還是 agent 做修改，都有回歸測試保護。
實作超簡單
最棒的是，要讓 coding agent 用 TDD 方式工作，你只需要在 prompt 中加一句：
Use red/green TDD就這樣。Agent 會先寫測試、確認失敗、再實作、確認通過。這可能是投入產出比最高的一個 prompt engineering 技巧了。
CaveGeek 觀點： 我自己的經驗也驗證了這一點。讓 Claude Code 用 TDD 模式工作時，產出的程式碼品質明顯更高，而且我花在 review 上的時間反而更少——因為測試已經幫我驗證了大部分邏輯。更重要的是，它改變了我的心態：我從「review 每一行 code」變成「review 測試是否覆蓋了正確的場景」，這是更高效的品質把關方式。
對開發者的啟示
從這兩個 pattern 中，我們可以提煉出幾個對日常開發有用的啟示：
1. 從「寫 code 的人」轉型為「定義規格的人」
當 agent 負責生成程式碼，工程師的核心價值轉移到：定義正確的需求、設計合理的架構、撰寫精準的測試。這不是降級，而是升級——你在做更高層次的工程決策。
2. 投資測試基礎設施
如果你的專案還沒有完善的測試框架，現在是最好的時機。不是因為「測試很重要」這種老生常談，而是因為測試是你和 agent 之間的溝通協議。沒有測試，agent 就是在盲飛。
3. 重新審視「不值得做」清單
你的技術債清單上，有多少項目是因為「工時不夠」而擱置的？用 agent + TDD 的方式，重新評估一下——很多過去不划算的事，現在可能只需要十分鐘。
結語
Agentic Engineering 不是要取代工程師，而是重新定義工程師的工作內容。Simon Willison 的這些 pattern 提供了一個務實的框架：承認 AI 改變了成本結構，然後用工程紀律（像 TDD）確保品質不會因為速度提升而下降。
寫程式碼變便宜了，但軟體工程沒有變便宜。理解這個區別的工程師，會在 AI 時代走得更遠。
本文參考 Simon Willison 的 Agentic Engineering Patterns 系列。推薦閱讀原文獲取更完整的 pattern 列表和案例。