上週 Hacker News 上有一篇討論炸到 276 分、225 則留言，標題很直白：「AI coding agents generate more code, but not more software」——AI 寫程式代理產出更多程式碼，但沒有產出更多軟體。同一時間還有另一篇 133 分的文章，Rich Hickey 直接開嗆「『AI』不是工具」。

這兩個討論放在一起看，其實在講同一件事：你以為把 AI 接進編輯器就等於生產力翻倍，結果只是製造了一堆沒人敢上線的程式碼。

如果你在 HK 或 TW 的團隊裡已經開始用 Cursor、Claude Code、Codex 這類 AI coding agent，這篇就是寫給你的。我會帶你走一遍五個實戰步驟：怎麼讓 AI 寫的程式碼真的變成能交付的產品，而不是堆在 repo 裡長灰塵。整套流程不需要你是什麼十年老手，只要你有基本 Git 概念就能跟著做。

為什麼 AI 寫得快，軟體卻沒變多？

先講一個很多人心裡有、但沒說出口的場景。你打開 AI agent，輸入「幫我做一個會員登入功能」，兩分鐘後它吐了 400 行程式碼、三個新檔案、兩支測試。你眼睛一亮，按了接受。

三天後你要串金流，才發現它自己發明了一套 session 機制；你要改密碼規則，發現驗證邏輯散在五個地方；你想請同事 review，同事看了十分鐘說「這個我不熟，你自己看吧」。

這就是 HN 那篇文的真實寫照。AI 讓「打字」變快，但軟體交付的瓶頸從來不在打字。 瓶頸在於理解、驗證、整合、維護——而這些恰恰是 AI 最容易幫倒忙的地方。

Rich Hickey 那篇更狠，他說工具應該是「你拿起來用完就放下」的東西，但現在很多 AI 工具是「你要反過來服務它」——你得學它的脾氣、繞它的限制、修它捅的婁子。這句話值得每個正在導入 AI coding agent 的人貼在螢幕邊。

所以問題不是「要不要用 AI 寫程式」，而是「怎麼用才不會被它拖著跑」。以下五步是我自己在專案裡反覆調整後留下來的做法。

第一步：先寫規格，再開 AI

最多人犯的錯，就是直接把一句話需求丟給 agent。你丟「做一個會員系統」，它就自由發揮；你丟的資訊越少，它填進去的「創意」就越多，而這些創意就是你三天後的債。

正確做法是：在打開 AI 之前，先花十分鐘寫一份「給 AI 看的規格」。不用很正式，但要包含四件事——功能清單、資料長什麼樣、邊界條件、以及「不要做什麼」。

舉個具體例子。與其說「做會員登入」，你可以寫：

  • 功能：Email + 密碼登入，密碼用 bcrypt 雜湊
  • 資料表：users(id, email, password_hash, created_at)
  • 邊界：Email 重複要回 409、密碼少於 8 碼回 400
  • 不要做：不要自己產生 JWT 套件，用專案裡已有的 jsonwebtoken

光是「不要做什麼」這一行，就能省下你後面兩小時的拆除工程。你給 AI 的約束越多，它給你的驚喜越少——而寫程式時，驚喜通常是壞消息。

第二步：一次只讓它做一件事

AI agent 最誘人的地方是可以「一次做完一個大功能」。但這正是災難的來源。一次改動越大，出錯時你越難定位，review 時越難消化。

我的做法是：把每個任務切到「一次 commit 能講清楚」的大小。 例如「新增 users 資料表與 migration」是一個任務，「實作註冊 API」是另一個，「加上註冊的表單驗證」再一個。每個任務完成、你確認過、commit 之後，才開下一個。

這樣做有三個好處。第一，出錯時範圍小，你一眼看得出問題在哪。第二，Git 歷史乾淨，將來要 revert 不會牽一髮動全身。第三，也是最重要的——你被迫真的讀懂每一段 AI 寫的東西，而不是整包按接受。

聽起來很慢？實際上它比「一次生成 800 行、然後花半天 debug」快得多。這也正是 HN 那篇文想說的：速度快不等於產出多。

第三步：把測試當成你的翻譯機

AI 寫的程式碼最麻煩的地方，不是它錯，而是「你不太確定它對不對」。這時候測試就是你的救星。

但這裡有個關鍵轉折：不要讓 AI 同時寫程式碼又寫測試，然後兩個一起按接受。 那等於自己出題自己改考卷。比較好的做法是——AI 寫完功能程式碼後，你先讀一遍，然後自己描述測試案例給 AI，讓它照你的描述寫測試。

例如你可以說：「幫我寫測試：Email 格式錯誤要回 400、密碼正確要回 200 並帶 token、密碼錯誤要回 401。」你描述的是「行為」，AI 負責把它翻成程式。這樣測試驗證的是你的意圖，而不是 AI 自己的假設。

這一步做完，你手上就有了一份「這個功能該怎麼動」的白紙黑字。將來同事要接手、或半年後的你要改，看測試比看程式碼快十倍。

第四步：用「最小可運行」驗證，不要等到最後

很多人的流程是：讓 AI 寫完一整個模組，才第一次跑起來。然後一跑就爆炸，錯誤訊息洗版，你根本不知道從何修起。

改成這樣：每完成一個小任務，就讓整個專案跑起來一次。 不一定要完整測試，至少讓它編譯過、伺服器起得來、那個 endpoint 打得到。哪怕只是回一個「hello」，都比「寫完才發現整包不能跑」好太多。

這聽起來很基本，但 AI 時代特別重要——因為 AI 很會寫「看起來對、但跑不起來」的程式碼。它會引用不存在的函式、用錯版本的 API、假設你裝了某個套件。這些問題在「最小可運行」的檢查點會立刻現形，拖到最後就變成考古現場。

順帶一提，如果你用的是有終端機權限的 agent（例如 Claude Code 這類），讓它自己跑測試、自己看錯誤訊息、自己修，效果通常比你把錯誤訊息複製貼上好。前提是你已經照第二步把任務切小了，不然它會越修越歪。

第五步：留下「為什麼」，不只是「什麼」

最後一步最容易被忽略，但它決定了三個月後你會不會恨自己。

AI 生成的程式碼有個通病：它會告訴你「做了什麼」，但不會告訴你「為什麼這樣做」。為什麼這裡用了 retry、為什麼那個欄位是 nullable、為什麼要繞這條路——這些上下文只有你知道。

所以每完成一個任務，在 commit message 或程式碼註解裡補上「為什麼」。不用長，一兩句就夠。例如：「此處加 retry 是因為第三方 API 偶爾 502，已與對方確認非我方問題。」這種句子，AI 寫不出來，但它會在未來某一天救你一命。

把這五步串起來，你的流程會變成：寫規格 → 切小任務 → 自己定義測試 → 每步都跑起來 → 留下決策脈絡。 看起來比「一句話叫 AI 做完」囉嗦很多，但它換來的是「真的能上線的軟體」，而不是 repo 裡一堆沒人敢動的程式碼。

回到開頭那兩篇 HN 熱文。它們不是在唱衰 AI，而是在提醒：AI 是工具，但用得好需要技能。 那個技能不是「怎麼下 prompt」，而是「怎麼當一個能把關的工程師」。工具越強，把關的人越重要。

所以別再追求「AI 幫我寫了多少行」。從今天開始，換一個指標：這週我交付了幾個真的能用的功能？ 你會發現，慢一點，反而快很多。

延伸閱讀

常見問題

Q: 我完全不會寫程式，可以用 AI coding agent 做出一個 App 嗎？

A: 可以做出「能跑的東西」，但很難做出「能維護、能上線收費的東西」。 AI 能幫你跨過語法門檻，但除錯、架構決策、安全性把關仍然需要人。建議先用它做小工具或原型，累積對程式碼的基本判斷力，再挑戰正式產品。

Q: AI 寫的程式碼一定要全部讀過嗎？這樣不是很花時間？

A: 核心邏輯、資料處理、金流與權限相關的程式碼，一定要讀。 樣板、設定檔、重複性的 UI 元件可以略讀。原則是：這段程式碼出錯時，你賠得起嗎？賠不起的，就讀。

Q: 用 Cursor、Claude Code 還是 GitHub Copilot 比較好？

A: 沒有標準答案，取決於你的工作型態。 喜歡在編輯器裡即時補完的選 Copilot 類；想讓 agent 自己跑終端機、改多個檔案的選 Claude Code 類；想要兩者兼具的可以試 Cursor。重點不是工具，而是你有沒有照上面五步建立自己的把關流程。

Q: 團隊要怎麼一起用 AI coding agent 才不會各寫各的？

A: 先統一「給 AI 的規格格式」與「commit 規範」。 例如規定每個任務都要附功能清單與邊界條件、commit message 要寫「為什麼」。工具可以各用各的，但產出的程式碼要能被同一個人 review 得下去。

Q: 如果 AI 一直修不好同一個 bug 怎麼辦？

A: 停下來，自己動手，或把問題切得更小。 AI 陷入迴圈通常代表它對問題的理解已經歪了，繼續餵它錯誤訊息只會越修越糟。這時候人工介入、重新定義問題，往往五分鐘就解決。