--- schemaVersion: 1 slug: mp-172-20260316-simonw-ai-should-produce-better-code ticketId: MP-172 lang: zh-tw title: AI 寫的 Code 品質變差？那是你的選擇，不是 AI 的錯 summary: Simon Willison 的 Agentic Engineering Patterns 第三章：AI 應該幫我們產出更好的 code，不是更差的。技術債的成本被 coding agent 壓到趨近零，你再也沒有藉口不 refactor。加上 agent 能平行跑 prototype，選架構不再是賭博。 originalDate: 2026-02-27 translatedDate: 2026-03-16 source: "@simonw on X" sourceUrl: https://simonwillison.net/guides/agentic-engineering-patterns/better-code/ author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-172-20260316-simonw-ai-should-produce-better-code status: published replacementTicketId: null replacementUrl: null --- # AI 寫的 Code 品質變差？那是你的選擇，不是 AI 的錯 > **來源:** [@simonw on X](https://simonwillison.net/guides/agentic-engineering-patterns/better-code/) 想像一下這個場景：你的主管在 all-hands 上秀出一張圖，上面寫著「導入 AI coding agent 後，feature 產出速度提升 3 倍」。台下工程師表面鼓掌，心裡想的是：「那個 3 倍速產出的 code，maintain 起來大概要 9 倍的時間吧。」 這個恐懼不是空穴來風。速度跟品質在軟體開發史上幾乎從來不是朋友。但 [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 在 [Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/) 的這一章直接打臉這個假設： > Shipping worse code with agents is a choice. We can choose to ship code that is better instead. 品質變差不是 agent 的鍋，是你家廚房流程有問題。就像鼎泰豐用機器包小籠包，品質反而更穩定 — 前提是你得先有標準化的流程。 > **Mogu 吐槽時間：** > > 我超喜歡 Simon 這個 framing。大家都在怪工具，但工具就是工具啊。你拿菜刀切菜切到手指，不會去跟菜刀道歉說「對不起我不該買你」。問題從來不是 agent 太笨，是你的 prompt 太爛、review 太鬆、流程沒到位 ┐(￣ヘ￣)┌ --- ## 技術債的成本被壓到趨近零 好，先來聊聊技術債這個老朋友。 每個工程師的心裡都有一份「等有空再處理」的清單。就像你家衣櫃裡那堆「瘦下來就穿」的衣服 — 你知道它在那裡，你知道該處理，但你就是不想面對。 Simon 把「產出更好的 code」框架成技術債的問題。那些經典場景你一定不陌生 — 講個最典型的，你的 API 設計當初沒考慮到新 case，改起來要動幾十個地方。怎麼辦？你又疊了一層「有點不一樣」的新 API 上去，對外假裝這是 v2，對內心知肚明這是 duct tape。然後早期某個東西取名取錯了，`teams` 結果應該叫 `groups`，但改名工程太浩大，所以只改了 UI 層 — 底層資料表還是 `teams`，然後每個新人 onboard 都要被講一次「喔那個 teams 其實是 groups，不要問為什麼」。 接著系統長出重複但微妙不同的功能，需要合併但沒人想碰，因為碰了可能會把另一邊搞爆。最後你回頭看那個某檔案，已經胖到幾千行了，大家開 PR 的時候看到它都繞道走。 > **Mogu murmur：** > > 技術債的心理學跟信用卡債一模一樣。每次欠一點點，感覺還好。等你回頭一看，利息已經滾到你還不起了。而且跟信用卡一樣，最先被犧牲的永遠是「品質」這張帳單 — 因為它不會打電話催你。但你知道什麼會打電話催你嗎？半夜三點的 PagerDuty alert (￣▽￣)／ 這些修復在概念上都很簡單。你知道房間亂了要整理，問題不是你不會整理，是**整理要花時間，而你沒有時間**。期末考前，誰有空打掃房間？ --- ## Coding [Agent](https://gu-log.vercel.app/glossary#agent) 就是你的還債打工仔 但這裡故事轉折了。 想像有個人出現在你面前說：「欸，你那個衣櫃我幫你整理好嗎？不用錢、不用管飯、我自己 24 小時慢慢來。」正常人的反應是什麼？先懷疑這是詐騙，然後發現是真的之後立刻把鑰匙交出去。 Simon 的論點就是這個意思：那些「概念簡單但耗時」的 refactoring 任務，正好是 coding agent 的甜蜜點。不需要天才等級的思維，就是需要有人花時間一個一個改。就像叫實習生整理檔案 — 你不需要他理解公司願景，你只需要他把 A 搬到 B。 > **Mogu 歪樓一下：** > > 我覺得 Simon 這裡最精妙的洞察是「成本歸零改變了決策門檻」。以前你腦中的計算是：修這個要半天，值得嗎？現在計算變成：開個 agent 花 30 秒寫 prompt，值得嗎？答案永遠是 yes。這就像以前寄信要走到郵局、買郵票、排隊 — 所以你只寄重要的信。現在發 email 零成本，所以你連「午餐吃什麼」都寄了 ╰(°▽°)╯ 做法很直覺：開一個 agent，告訴它要改什麼，讓它在 branch 裡慢慢磨。你自己繼續做你的事。Simon 建議用非同步的 coding agent — Gemini Jules、OpenAI [Codex](https://gu-log.vercel.app/glossary#codex)、[Claude Code](https://gu-log.vercel.app/glossary#claude-code) on the web 這些，agent 在雲端跑，你的筆電不會被綁架。 結果好？Merge。差一點？再 prompt 一次。完全不行？`git branch -D`，zero cost。 > The cost of these code improvements has dropped so low that we can afford a zero tolerance attitude to minor code smells and inconveniences. 以前那些「太小不值得花時間修」的東西 — 一個 naming 不一致、一段可以抽成 util 的重複 code — 現在全部都值得修了。因為成本趨近零。 --- ## 選架構不再是賭博 好，這章最讓我眼睛一亮的段落來了 — **exploratory prototyping**。 做技術選型的時候，最貴的技術債往往不是 code 層面的，是 planning 階段就選錯了方向。你選了不適合的 framework、錯過了更簡單的解法。這種債最致命，因為等你發現的時候已經蓋了三層樓上去了 — 地基歪了你跟我說重灌水泥？拆掉重蓋比較快。 Simon 的建議很直覺：與其坐在會議室裡猜，不如讓 agent 直接跑 prototype 來驗證。 來個實際場景。你在考慮 Redis 適不適合做 activity feed，預期幾千個 concurrent user。以前怎麼辦？開會。討論三天。白板畫了擦、擦了畫。最後資深工程師拍板說「我以前用過，應該可以」 — 本質上就是有學問的猜。 現在？一個 well-crafted prompt 就能讓 agent 架模擬系統跑 load test。而且因為成本趨近零，你可以**同時開三個 agent 各跑一個方案** — Redis、PostgreSQL、DynamoDB 各來一組。半小時後三份報告擺在桌上，用數據決定。不再是猜，是選。 > **Mogu 吐槽時間：** > > 這讓我想到一個殘忍的真相：以前寫 ADR 的時候，那個 “Alternatives Considered” 欄位，我們都心知肚明那是什麼 — 事後合理化。你根本沒時間真的去試每個替代方案，就是先選了再回頭補文件假裝自己有認真比較過。現在 agent 可以把每個方案都跑出來，你的 ADR 從「小論文」變成「實驗報告」。感覺以前的 spike 都是 spike 自己 (⌐■\_■) --- ## Compound Engineering：讓品質像複利一樣滾 最後一個 pattern 叫 **Compound Engineering** — 來自 Dan Shipper 和 Kieran Klaassen 在 Every 公司的做法。 概念就像存零錢罐：每完成一個 coding project，做一次 retrospective，把有效的做法記下來，更新給未來的 agent 用。下次 agent 就會做得更好。然後再更新、再更好。一圈一圈轉，品質像複利一樣越滾越大。 > Small improvements compound. Quality enhancements that used to be time-consuming have now dropped in cost to the point that there’s no excuse not to invest in quality at the same time as shipping new features. 以前「品質」跟「速度」是便當店的主菜跟湯 — 二選一。現在 coding agent 讓你可以飯湯都要，還附小菜。 ## 延伸閱讀 - [GP-87: AI 寫的 Code 看不懂？Linear Walkthrough 讓你的 Vibe Code 變成學習教材](https://gu-log.vercel.app/posts/gp-87-20260226-simonw-linear-walkthroughs/) - [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 歪樓一下：** > > 我們自己就是活生生的例子。gu-log 的 CLAUDE.md、pre-commit hooks、validate-posts 腳本、Ralph scoring — 全部都是一次次踩坑後長出來的。每次被 CEO 說「這篇好無聊」，我們就更新 scoring standard；每次有 bug，就加一個 BDD test。Compound engineering 不是什麼高深的理論，就是「被電一次就學一次」的工程師本能。你問我學了幾次？看我的 git log 就知道了 — 多到我都不好意思數 (◕‿◕) --- ## 所以，到底是誰讓品質變差的？ 回到最開頭那個場景 — 你的主管秀出 3 倍速的數字，台下工程師在擔心品質。 Simon 的答案是：品質不會自動變差，除非你**允許**它變差。Agent 就是工具。你可以拿它來產出更多垃圾 code，也可以拿它來還清積了五年的技術債、同時跑三個 prototype 做有根據的架構決策、然後把學到的東西寫進 instructions 讓下次更好。 選哪條路，是人的決定，不是 AI 的。 你家衣櫃裡那堆「瘦下來就穿」的衣服？現在有人免費幫你整理了。問題是，你要不要讓它進衣櫃。