分類：AI Agent
來源：Simon Willison / HackerNews（熱度 1073）
原始文章：Vibe coding and agentic engineering are getting closer than I’d like
「我希望我寫的所有東西，都比以前更好。」
這句話出自 Simon Willison——一位有 25 年經驗的軟體工程師，Django 框架的核心貢獻者，也是業界最常公開反思 AI 工具的開發者之一。他對 AI 的態度不是激進的狂熱派，也不是全盤否定的保守派，而是那種「認真想弄清楚界線在哪裡」的人。
但他在最近與 Heavybit 的 podcast 訪談中，說了一句讓開發者坐立難安的話：「我已經不再審查每一行程式碼了——即使是生產環境的程式碼。」
你不是一個人。這句話之所以讓人不安，是因為它太真實了。許多開發者——特別是在台灣的獨立開發者和小團隊——正在默默經歷相同的轉變。不是因為偷懶，不是因為不在乎品質，而是因為 AI 助手已經變得……太好用了。好到讓一個一輩子堅持 Code Review 的人，開始感到內疚。
這不是一篇反 AI 的文章，而是一個誠實的自我檢視。當 vibe coding 和專業軟體開發之間的界線逐漸模糊——連 Simon Willison 都承認他無法清楚分辨——你準備好了嗎？
從兩道清晰的界線開始
去年三月，當「vibe coding」這個詞第一次出現時，Simon Willison 是最早為它劃界的人。他寫了一篇文章，把 AI 輔助程式開發分成兩個涇渭分明的陣營，核心訊息非常清楚：
- Vibe coding：你甚至不看程式碼。你可能根本不會寫程式。你對 AI 說「做這個」，它做出來了，你覺得不錯就用。出錯也無所謂，因為影響的只有你自己。
- Agentic engineering：你是一個專業軟體工程師，理解安全性、可維護性、效能、營運——所有專業開發者該懂的東西。AI 只是你的加速器，你仍然帶著多年經驗在判斷每個建議。
這兩種模式的核心差異，在於審查的責任。Vibe coding 把審查外包給運氣；agentic engineering 把審查保留在人類手中。這是當時 Simon 的判斷，他也認為這是一道穩固的界線——至少看起來如此。
那條線為什麼消失了？
在 Heavybit 的 podcast 中，當主持人 Joseph Ruscio 問到兩者的區別時，Simon 突然發現一件讓他自己也不太舒服的事：「奇怪的是，現在它們已經開始模糊了——這讓我有點沮喪。」
為什麼？不是他的標準降低了，而是 AI 的可靠性大幅提高了。他說了一個具體的經驗：如果你叫 Claude Code 寫一個 JSON API 端點，執行 SQL 查詢然後回傳 JSON 結果——「它就是會做對。它不會搞砸。你叫它加自動測試，它會加。你叫它寫文件，它會寫。」
問題在於：他不再看那些程式碼了。
但如果不看程式碼就敢上線，這算負責任嗎？Simon 誠實地回答：他不知道答案。他感到內疚，但他的行為已經在改變了。
心理學：你其實一直都在信任「黑盒子」
這是整篇文章最重要的洞察，也是 Simon 找到的自我說服方式：
他回想過去在大型組織當工程主管的經驗。隔壁團隊提供了一個圖片處理服務——「這是 resize API，這是文件，用這個來縮圖。」他不會去讀對方寫的每一行程式碼，只會照著文件用，出問題才翻原始碼。
他開始用同樣的方式看待 AI。
我把這種心態稱為團隊信任的延伸。人類在組織中學會了信任——透過聲譽、歷史紀錄、過往表現——來降低協作成本。Simon 說：「一個團隊可以建立信譽。我可以說『我信任那個團隊，他們過去做得好』。」但關鍵是——「Claude Code 沒有職業聲譽。」
它無法為自己做的事負責。可是它一直在證明自己——一次又一次，那些直來直往的程式碼，它總是寫對，而且是用 Simon 喜歡的風格。不知不覺中，Simon 把它當成了一個「值得信賴的同事」。
這其實是一種 常態化偏誤（normalization of deviance）——這個概念原本來自 NASA 挑戰者號災難的分析：當一個異常狀況發生後沒有造成立即災難，人們就會慢慢降低對這個異常的警戒，直到它變成「正常」。在 AI 開發中，每一次模型正確寫出程式碼而沒被仔細檢查，就增加了一點信心，檢查門檻就降低一點。直到完全信賴它，然後在某個意想不到的地方犯一個讓你後悔的錯誤。
Simon 說：「每次模型不需要我仔細監控就寫對了程式碼，就增加了一點風險——未來我在錯誤的時刻信任它，然後被燙傷。」這不是 AI 的 bug，而是人性的 bug。我們的大腦不擅長處理「經常正確但有時會錯得很離譜」的系統，傾向於把 95% 的正確率解讀為 100%。
更嚇人的問題：你怎麼判斷程式碼的好壞？
這不是信任不信任的問題——而是從根本上，你已經失去了判斷程式碼品質的能力。
以前，如果你在 GitHub 上找到一個有一百次 commit、漂亮的 README、有自動測試的專案，你大概可以放心。這是開發社群默認的「品質信號系統」：星數、commit 頻率、文件品質、測試涵蓋率——這些指標共同構成判斷依據。
但現在呢？Simon 說：「我可以在半小時內做出一個有一百次 commit、漂亮的 README、全面的測試涵蓋的儲存庫！它看起來跟那些花了很多心力維護的專案一模一樣。也許它真的跟它們一樣好。我不知道。光看我無法判斷。連我自己的專案，我都無法判斷。」
最後一句話是最震撼的。如果一個寫了 25 年程式的工程師都分不出來——你要如何在 GitHub 上挑選一個可靠的套件？同事交了一個 Pull Request，裡面 20 個檔案、3000 行程式碼全部是 Claude Code 寫的——你要怎麼 review？如果連「這個專案有沒有被認真對待」都無法判斷，那你仰賴的信號系統其實已經崩潰了。
這不是說 AI 產出的程式碼比較差，而是說 你無法區分。而無法區分這件事本身，就是系統性風險。
Simon 的應對方式很直覺，也很有智慧：「我現在最重視的不是程式碼品質或測試完善度，而是『有人真的用過它』。如果你的 vibe coding 產物你自己每天用了兩個禮拜——那對我來說，比一個剛吐出來、連你自己都沒跑過的專案有價值得多。」
使用紀錄 > 封裝品質。
一個被每天使用兩週的工具，比一個靜態看起來完美的專案更值得信賴。因為使用會暴露問題，問題暴露後會被修復——這個過程本身，才是真正的品質保證。Simon 在 podcast 中把這個觀念說得更直接：「如果一個 vibe coding 的產物你每天自己用了兩週——那對我來說，比一個剛吐出來、連你自己都沒跑過的專案有價值得多。」簡單來說：人用過的 > 機器產生的。
這個觀點對開源社群的影響尤其深遠。以前我們說「很多星星 = 好專案」，現在這個信號愈來愈不可靠。真實使用者的口碑和 issue 追蹤的深度，反而成為更有價值的判斷依據。
當生產力翻十倍，什麼東西會壞掉？
如果你從每天產出 200 行程式碼變成 2,000 行，整個軟體開發生命週期都會受到衝擊。因為它從根本上就是按照「工程師很慢」這個假設來設計的：設計師先做規格、PM 先排時程、QA 最後測試——因為改程式碼很慢，所以必須先想清楚。但當你想清楚的時候，AI 已經把東西做出來了。
Simon 提到 Anthropic 的設計總監 Jenny Wen 的一場演講：「我們所有的設計流程都是建立在『設計錯了就完了』的假設上——因為你一旦把規格交給工程師，他們要花三個月蓋出錯的東西，那是災難。」但如果三個月變成三天呢？「也許設計流程可以更大膽一點，因為犯錯的成本實在降低太多了。」
這句話可以從兩個方向解讀。
樂觀面：快速迭代。設計錯了沒關係，快速做出 prototype、測試、修正。不再是線性流程，而是設計→開發→測試的快速循環。
悲觀面：當你不再害怕犯錯，錯誤反而更多。GitHub 上已經可以看到越來越多「一次 commit 就整個專案」的儲存庫——沒有迭代過程、沒有人類開發的歷史痕跡。那些 commit log 上的「fix typo」「oops forgot to add this」——曾經是判斷工程師投入程度的間接證據——正在消失。
Simon 自己也坦言：「這不只是下遊的問題，上遊也是。」當你無法透過 commit 歷史、測試涵蓋率、README 品質來判斷一個專案的好壞時，整個開放原始碼社群的信號體系都在被重新定義。誰能先建立新的信號機制——不論是使用者的真實回饋、issue 的討論深度，還是 release note 的品質——誰就能在新的開發環境中佔據優勢。
四項具體建議
如果你看完以上分析感到不安——那是正常的。但不安之後，你需要具體的行動方針：
一、建立信任層級，不是黑白判斷
不是「信賴 AI」或「不信賴 AI」的二元選擇，而是針對不同任務設定不同信任等級：
– 個人腳本、一次性工具：信任高，錯了自負
– 內部工具、小團隊服務：中等信任，每週抽查
– 對外 API、金流相關、使用者資料：低信任，嚴格審查
二、把「驗證時間」納入開發時程
AI 讓你寫得快，但沒有讓你判斷得快。如果你的開發時間從一天縮減到一小時，剩下的時間應該用來驗證——手動跑過流程、確認 side effect、檢查邊界案例。
三、建立「意外清單」
每當 AI 寫出 review 時沒發現的 bug——不是有意忽略，而是根本沒預料到——記錄下來。隨著時間累積，這份清單會告訴你哪些類型的程式碼你真的可以信任 AI，哪些不行。這不是只是防禦性的做法——它還能幫助你理解 AI 模型的盲點。例如你可能會發現 Claude Code 在處理複雜的錯誤處理邏輯時容易漏 case，但在撰寫 CRUD 端點時幾乎零失誤。這份「實戰日記」將成為你個人化的 AI 協作指南。
四、分享程式碼給真人看
雖然 AI 也可以做 code review，但人類的回饋仍然是最珍貴的信號。把 AI 生成的程式碼分享給同事或社群——你不必審查每一行，但讓另一個人看過，能大幅降低常態化偏誤的風險。
Simon Willison 這篇文章最珍貴的地方不是它的結論——因為它根本沒有結論——而是它的誠實。他沒有說「你應該這樣做」，他說的是「我也還在摸索」。
這讓我想起另一個值得留意的細節：Simon 在文章中提到了自己之前寫過的「常態化偏誤」概念。他說當你一次又一次看到 AI 做對了，你會不自覺地放鬆警惕。而這個過程——就像溫水煮青蛙——是你自己無法察覺的。這也是為什麼他建議開發者要有意識地建立「停下來檢查」的習慣，而不是完全依賴直覺。
如果你還在為「我到底該不該信任 AI 寫的程式碼」而煩惱——你不是落後，而是清醒。那種不安感不是弱點，而是你的直覺在提醒你：這件事還沒有被真正搞清楚。
工具越強大，判斷力越珍貴。而判斷力——不是靠工具練的，是靠經驗、犯錯和誠實的自我檢視累積起來的。
AI 可以幫你寫程式碼。但它沒辦法幫你決定什麼時候該信任它。
那個決定，只能由你來。