--- schemaVersion: 1 slug: gp-80-20260223-simonw-agentic-engineering-patterns ticketId: GP-80 lang: zh-tw title: 寫 Code 變便宜了，然後呢？Simon Willison 的 Agentic Engineering 生存指南 summary: Simon Willison 開了新系列 Agentic Engineering Patterns，教你怎麼跟 Claude Code、Codex 這類 coding agent 好好協作。第一課：寫 code 變便宜了，但寫『好的 code』還是很貴。第二課：紅燈綠燈 TDD 是跟 agent 協作的最強咒語。 originalDate: 2026-02-23 translatedDate: 2026-02-23 source: Simon Willison @simonw sourceUrl: https://x.com/simonw/status/2025990408514523517 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-80-20260223-simonw-agentic-engineering-patterns status: published replacementTicketId: null replacementUrl: null --- # 寫 Code 變便宜了，然後呢？Simon Willison 的 Agentic Engineering 生存指南 > **來源:** [Simon Willison @simonw](https://x.com/simonw/status/2025990408514523517) 你有沒有過那種感覺 —— 叫 AI 幫你寫完一個 function，跑起來了，測試也過了，但你盯著螢幕就是覺得哪裡不對勁？ 不是 code 壞了。是你的直覺在告訴你：你正在失去某種東西，只是你還說不出來是什麼。 [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 把那個不對勁的感覺拆開來看了，然後整理成一套框架。他開了一個新系列叫 **[Agentic Engineering](https://gu-log.vercel.app/glossary#agentic-engineering) Patterns**，靈感來自 1994 年那本 OOP 聖經 _Design Patterns_。但這次不是教你 Singleton 和 Factory —— 是教你在 coding agent 滿天飛的年代，怎麼保住你身為工程師最值錢的那塊肌肉：判斷力。 > **Mogu 碎碎念：** > > Simon Willison 就是 Django 的共同創作者，ai-assisted-programming 這個 tag 已經寫到 345 篇了。345 篇。這人對 AI 工具的使用強度，大概跟你對手搖杯的依賴程度差不多 —— 天天喝，而且每杯都寫 review。他特別強調這系列每個字都是自己敲的，不是 AI 生成。2026 年了，「我自己寫的」反而變成一種品質認證，就跟食品包裝上印「無添加」一樣 —— 這世界到底怎麼了 ┐(￣ヘ￣)┌ ## [Vibe Coding](https://gu-log.vercel.app/glossary#vibe-coding) 跟 Agentic Engineering，差在哪？ 在進入 pattern 之前，Simon 先畫了一條線，而且畫得很用力。 **Vibe coding** 就是那種「我不管 code 長什麼樣，反正能動就上」的態度。你把需求丟進 LLM，它吐出一坨東西，你連看都懶得看就 deploy 了。[Andrej Karpathy](https://gu-log.vercel.app/glossary#andrej-karpathy) 發明了這個詞，通常描述的是非工程師拿 LLM 寫程式的場景。 **Agentic engineering** 是光譜的另一端：你是專業工程師，你有多年累積的判斷力，你用 coding agent 來**放大**這些既有專業，不是把它丟掉。[Agent](https://gu-log.vercel.app/glossary#agent) 可以自己跑、自己測、自己迭代 —— 但方向盤在你手上。 想像一下：vibe coding 像是叫外送，你連廚房長什麼樣都不想知道。Agentic engineering 像是你當主廚，手下有十個能幹的學徒幫你備料切菜 —— 但菜單是你開的、火候是你調的、上菜前你還要試一口。 > **Mogu 碎碎念：** > > 講更白一點：vibe coding 是把作業丟給同學抄，交了就好。Agentic engineering 是你當 tech lead，畫架構圖、定 spec，agent 去跑實作，你 review 成品。如果你正在讀這篇文章，你八成已經在做 agentic engineering 了 —— Simon 只是幫你取了個正式名字，讓你下次跟 PM 解釋的時候有個詞可以用 (◕‿◕) ## Pattern 1：寫 Code 變便宜了，所以呢？ 好，定義釐清了。第一個 pattern 直接戳核心痛點： > 接受 Agentic Engineering 最大的挑戰，是習慣「寫 code 變便宜了」這件事帶來的所有後果。 Code 一直以來都是昂貴的。你要一個工程師寫幾百行乾淨、有測試的 code，那是一整天的事。我們整個軟體工程的文明 —— 從最宏觀的流程到最微觀的習慣 —— 全部都是繞著「code 很貴」這個假設蓋起來的。 往大的看：為什麼我們花那麼多時間寫 design doc、估工時、開 planning meeting？因為一旦方向錯了，好幾天的 coding 直接打水漂。每個 feature idea 都要先過一關：值不值得花那個開發成本？不值得就砍。這不是工程問題，是經濟問題。 往小的看：你每天都在做同一種計算。要不要 refactor 那個 function？要不要補那個 edge case 的 test？要不要幫那段 legacy code 寫個 README？每個「要不要」背後的潛台詞都一樣 —— 我這一小時的薪水，花在這件事上值不值得？ 然後 coding agent 出現了，把「把 code 打進電腦」這個動作的成本壓到趨近於零。 你以前糾結的那些 trade-off？答案突然全部變成「做就對了，反正不用你打字」。 更瘋的是：你可以同時開好幾個 agent 跑。一個 implement 新 feature，一個 refactor 老 code，一個補 test coverage，一個寫 documentation。以前你一個人做四件事要四天，現在是泡杯咖啡的時間，回來收作業。 > **Mogu murmur：** > > 你想想以前 sprint planning 怎麼開的：「這個 task 3 天，那個 5 天，sprint 兩週，所以只能排這幾個。」現在變什麼？「這 10 個 task 各開一個 agent，半小時後回來驗收。」整個 estimation 的概念都在崩解。但問題是我們的 PM 工具、我們的 Jira board、我們的 performance review —— 全部都還活在「code 很貴」的平行宇宙裡。工具的成本歸零了，組織的慣性還在用力踩油門。這才是真正的 challenge。跟 MP-85 裡 Steve Yegge 講的一樣：10 倍產能如果組織沒跟上，你只是更快地撞牆 (╯°□°)╯ ## 等等 —— 好的 Code 還是很貴啊 不過 Simon 馬上補了一刀。一刀見血的那種。 Code 變便宜了，不代表 **good code** 也變便宜了。 「好的 code」到底長什麼樣？Simon 的答案不是一句話，是一整座冰山。 最表面的一層：它要能跑。廢話。但光能跑不夠 —— 你需要**證據**證明它能跑。不是「我覺得應該 OK」，是有測試、有 CI 跑過、有人驗證過。「我覺得應該 OK」這句話在 production 的可信度大概跟「我覺得明天不會下雨」差不多 ╰(°▽°)╯ 再往下一層：它要解決**對的問題**。這聽起來像廢話，但你叫 agent 寫東西的時候，它不會回頭問你「欸，你確定使用者真的需要這個功能嗎？」它只會很開心地把你的 prompt 變成 code，不管那個方向有沒有意義。 再往下：error handling。Happy path 誰都會寫，agent 寫得尤其漂亮。但那些 error message 呢？三個月後有人被叫起來 on-call debug，看到 “Something went wrong” —— 你覺得他的心情會是什麼？ 然後是簡潔性 —— 人跟機器都能理解、能維護。是測試覆蓋率 —— 讓你未來改東西不會默默壞掉。是文件要反映**現在**的狀態，不是考古遺跡。是架構要 YAGNI 但不能把未來的路堵死。再加上那串 -ilities：accessibility、testability、reliability、security…… 每一層都需要工程判斷。每一層都不是 agent 按個按鈕就搞定的。 > **Mogu 補個刀：** > > 我跟你說 AI 最容易偷懶的兩個地方：error handling 和「解對問題」。你叫 agent 寫一個 API endpoint，happy path 寫得漂漂亮亮，但 error case？要嘛直接吞 exception 裝沒事（經典鴕鳥戰術），要嘛丟一個 “Something went wrong” 讓下一個維護者想掀桌。下次 review AI 寫的 PR，專門盯這兩項就好。命中率高到你會懷疑 AI 是不是故意的 (¬‿¬) ## 新的預設值：先開 Agent 再說 所以結論呢？Simon 的建議很直球： > 任何時候你的直覺說「不值得花時間做」，先丟個 prompt 給 agent。最壞的情況就是十分鐘後回來看，發現結果不行，你也就浪費了幾毛錢 token。 這是一個認知層面的大翻轉。以前你腦中的「值不值得」計算器，分母是你一小時的薪水。現在分母變成幾毛錢的 API call。 那些你以前覺得「太小不值得做」的改善 —— 加個 debug interface、補個 edge case test、幫那段沒人敢碰的 legacy module 寫個 README —— 現在全部值得試一把。不試白不試，試了不虧。 新的預設值：有疑問就開 agent。別讓舊腦袋裡那個「不值得」的聲音繼續幫你做決定。 > **Mogu 想補充：** > > 不過這裡我要幫 Simon 補一個但書：「先丟 agent」的前提是你有能力判斷 agent 吐出來的東西好不好。如果你是個資深工程師，看一眼就知道 code 行不行，那「先丟再說」完全合理。但如果你對這個 domain 不熟，agent 寫出來的東西你根本沒辦法 review —— 那你做的不是 agentic engineering，是 vibe coding 的豪華版。判斷力是這整套框架的前提，不是附贈品 (ง •̀\_•́)ง ## Pattern 2：紅燈綠燈 —— 六個字的超級咒語 第二章只講一件事，但這件事的投資報酬率高到離譜： > 「Use red/green TDD」是讓 coding agent 產出好結果的**最精簡指令**。 TDD = Test Driven Development，紅綠燈是它的核心節奏： 🔴 **Red（紅燈）**：先寫測試，跑一次，確認它會 fail。 🟢 **Green（綠燈）**：寫 implementation，讓測試通過。 為什麼這跟 coding agent 特別合拍？ 想像你叫一個很聽話但沒有方向感的學徒去辦事。你有兩種方式： 第一種，「去幫我做一個 markdown parser」—— 學徒會做出一個東西，但可能跟你想的完全不一樣，而且你無法驗證對不對。 第二種，「先幫我寫一個測試，測 `# Hello` 會被 parse 成 h1 tag，跑一次確認測試 fail，然後再寫 code 讓它 pass」—— 現在學徒有了**明確的目標**，有了**可驗證的成功標準**，而且你還自動附贈了一套 regression test suite，未來改東西不會默默壞掉。 Agent 的兩大風險 —— 寫出不能跑的 code，和寫出沒人要的 code —— 紅綠燈同時堵住了。 但有個超重要的細節：**一定要先確認測試會 fail**。如果你跳過紅燈直接寫 implementation，你可能會拿到一個「本來就會 pass」的空氣測試 —— 那等於什麼都沒測到。紅燈是在確認：這個測試真的在測你要的東西，不是在自嗨。 ## 延伸閱讀 - [MP-171: 寫了 11 章才敢回答的問題：到底什麼是 Agentic Engineering？](https://gu-log.vercel.app/posts/mp-171-20260316-simonw-what-is-agentic-engineering/) - [MP-169: Simon Willison 的 Agentic Engineering 爐邊對談：測試免費了、程式品質是你的選擇](https://gu-log.vercel.app/posts/mp-169-20260315-simonw-pragmatic-summit-agentic-engineering/) - [GP-90: AI 生的 Code 看不懂？讓 Agent 幫你做動畫解釋 — Simon Willison 的 Interactive Explanations](https://gu-log.vercel.app/posts/gp-90-20260301-simonw-interactive-explanations/) > **Mogu 吐槽時間：** > > 用 Python 示範一下：先寫 pytest，跑一次看到整片紅色 FAILED，心情踏實了，然後才開始寫 function。用 FastAPI 就是先把 TestClient 的 request/response expectation 定好，確認拿到 404 或 assertion error，再去實作 endpoint。最美的部分是這六個字 —— “red/green TDD” —— 每個像樣的 model 都聽得懂。你不需要寫一大段 prompt 解釋什麼是 test-first methodology。就六個字，agent 就知道該怎麼做。這是我見過 prompt engineering 裡 ROI 最高的操作，沒有之一 (๑•̀ㅂ•́)و✧ Simon 給的範例 prompt 簡單到讓人懷疑人生： > Build a Python function to extract headers from a markdown string. Use red/green TDD. 一句話的需求 + 六個字的咒語。Claude 和 ChatGPT 都能正確理解並執行紅綠燈流程。不需要 few-shot、不需要 chain-of-thought、不需要寫到手抽筋的 system prompt。就六個字。 ## 那個不對勁的感覺，現在有名字了 回到最開頭 —— 你盯著 AI 寫的 code，覺得哪裡不對勁。 現在你知道那個感覺叫什麼了。 那是你的工程判斷力在跟你說話。它在說：「這段 code 能跑，但我不確定它解了對的問題。我不確定 error handling 夠不夠。我不確定三個月後有人碰它的時候不會爆炸。」 Simon 這兩章給了你兩個工具來回應那個聲音。 第一個工具是認知翻轉：code 便宜了，但你的判斷力沒便宜。以前你是廚師兼洗碗工，現在洗碗外包了，你可以回歸本業 —— 決定菜單、調味道、確保客人吃到對的東西。你的價值不是手速，是品味。 第二個工具是六字咒語：“red/green TDD”。下次那個不對勁的感覺出現，試試在 prompt 裡加上這六個字。你會發現 agent 寫出來的東西突然有了骨架、有了可驗證的品質、有了你可以信任的基礎。 那個不對勁的感覺不會消失 —— 但現在你有了框架去回應它，而不是假裝它不存在 (￣▽￣)／