為什麼我不“憑感覺編程”

作者：Jacob Harris
標題：Why I Don’t Vibe Code^[1]

最近網上關於“憑感覺編程”（Vibe Coding）以及大語言模型（LLM）將如何顛覆軟件開發的討論鋪天蓋地。據說，每一個新模型的發佈都會把我們帶入純粹生產力的天堂，讓我們能以光速發佈軟件，徹底消除產品開發中的所有摩擦和內耗。

或許吧，我姑且信之。但我自己，是不“憑感覺編程”的。

如果你覺得這套好用，那太棒了！我寫這篇文章並不是為了探討 LLM 的優劣，只是這玩意兒對我個人來說，從來沒對過胃口。這篇文章，算是我簡單盤點一下其中的種種原因。

我是個守財奴

我不是個原教旨主義者。我試過用集成在 IDE 裏的 LLM。對於那些描述起來很簡單、但自己動手又嫌煩的任務，它們確實挺好用的，比如把網格里的一堆方形圖片縮小。我本可以去查查圖像處理軟件 ImageMagick 的命令行參數，但這種事交給 AI 去幹再合適不過了。接着，我又試着用某個 AI 工具分析了我項目裏的一段代碼，還做了幾件小事，然後一切戛然而止。系統通知我：額度用光了。如果想繼續，請綁定信用卡購買更多 Token。

你得知道，我祖上兩邊都是出了名的鐵公雞。幾個世紀以來，無論是在大西洋的這頭還是那頭，我們家族一直精打細算、錙銖必較。舉個極端的例子：我的一位遠房祖先在 17 世紀的菲利普國王之戰中喪生，原因竟然是他在撤離房子時落下了點奶酪，非要跑出安全的堡壘去撿。

所以你一定要相信我：當我發現為了讓自己能“思考”，居然還要無休止地給一個服務交錢時，我渾身不自在，以至於連信用卡的影子都不想給他們看。我合上筆記本電腦，卸載了那個 IDE，甚至乖乖用回了極其硬核的純文本編輯器 Emacs。然後我發現，我壓根兒就沒覺得少了 AI 有什麼不習慣的。

我年紀大了

年紀大確實有點幫助。我寫代碼已經很多年了，尤其是在這個把只有 5 年經驗的開發者就稱為“高級工程師”的行業裏。有時候，經驗是緩解焦慮的一劑良藥（前提是，你焦慮的不是在這個 5 年就能稱“高級”的行業裏遇到的年齡歧視）。這波 AI 熱潮確實讓我想起了早年那些“低代碼”或“無代碼”工具所吹噓的重大突破。我不懷疑 AI 可以成為開發者手中的利器，我知道在很多任務上它能提供更好的工具支持。但這些爭論，總是讓我回想起關於“偶然複雜性”（accidental complexity）和“本質複雜性”（essential complexity）的經典理論。

即使在我還是個年輕碼農的時候，弗雷德·布魯克斯（Fred Brooks）也算得上是老前輩了。作為 IBM System 360 系列大型機（及配套操作系統）的項目經理，他曾在第一線親眼目睹瞭如今軟件項目中那些司空見慣的爛攤子。他將這些觀察整理成了《人月神話》一書，至今仍應是軟件工程課程的必讀經典。我手頭的那本是後來重印的新版，裏面收錄了他後期的一篇著名文章《沒有銀彈》。在這篇文章中，布魯克斯探討了新工具對開發者生產力的實際影響。要想像程序員一樣思考，你必須明白現實世界是極其複雜的。編程最好被理解為：在混亂的現實之上強加一種簡化的模型，我們稱之為“抽象”（abstractions），通過降低複雜性來讓世界變得可理解。

這讓我們能夠將特定的情況泛化成一個個可以層層疊加的結構。例如，“把花生醬抹到麪包上”這個具體動作，可以泛化成一個 spread(substance)（塗抹物質）的方法，這個方法既可以接受“花生醬”作為參數，也可以接受“奶油奶酪”。接着，我們可以用這些基礎方法構建出更高級的函數，比如 create_pbj()（製作花生醬果凍三明治）等等。在現代高級編程語言中寫代碼，就像是站在一座由抽象概念堆砌而成的金字塔頂端：只需一行代碼，就能在多個系統上觸發數以百萬計的底層操作。

那麼，如果我們繼續往下走，把“編程”這個行為本身也抽象掉呢？這就是 AI 智能體的終極夢想：成羣結隊的智能體接受任務，然後在無人監督的情況下自動實現它們。聽起來棒極了！但這解決的僅僅是布魯克斯所說的偶然複雜性，也就是編寫代碼本身那些繁瑣、笨重的地方。自從那篇文章發表以來，軟件開發在應對偶然複雜性方面已經取得了巨大的進步。我們不用再寫底層的機器碼，而是使用現代的動態解釋型語言；我不需要再從頭記住如何手寫一個快速排序，只需調用標準庫裏的排序方法即可；我也不用再從零開始搭建整個 Web 應用，而是直接使用現成的框架。如果我想重命名或者重構某段代碼，我的編輯器可以代勞。

AI 似乎只是這一進程的最新迭代，一些編輯器已經用不可預測的 AI 智能體，取代了過去那些可預測的老式重命名和重構工具。誠然，這聽起來像是在擲骰子碰運氣，但在實際開發中，那種災難性的大翻車又能有多常見呢？

然而，即便更好的工具削弱了偶然複雜性，本質複雜性還在那兒。設計出正確、優雅、清晰且易於維護的抽象架構和系統，依然是一項無比艱鉅的工作，這種複雜性哪兒也去不了。這項工作需要技能、經驗，以及從過去系統崩潰的血淚史中艱難汲取的智慧。LLM 那種花哨的“高級自動補全”，面對這種很難直接找到標準答案的複雜性，到底能發揮多大作用？也許通過精心設計提示詞，你可以引導它走向你心儀的方案，但到了那個地步，負責引導的人還不如自己乾脆把方案設計出來算了，因為 LLM 根本無法向你解釋它為什麼選擇了某條特定的路徑。本質複雜性往往是怪異、罕見且混亂的。也許我錯了，也許模型在處理這些混亂情況方面正變得越來越好，但我發現這通常需要一種非常特定的人類思維模式和方法。幸運的是，我超愛這種亂糟糟的東西。

我愛死這些混亂了

前面我一直在談論軟件如何抽象流程，但其實我們也利用抽象的“簡化”特性，作為理解世界的一種工具。在經典名著《國家的視角》中，詹姆斯·斯科特（James Scott）描述了後啓蒙時代的一個核心動機：通過抽象和分類，讓人口和財產變得清晰可辨。能量化的東西，就能被改造。例如，一個國家在看待其森林時，可能不再將其視為複雜的生態系統，而是僅僅通過“能用於造船的木材比例”來評估。這種視角隨之促使國家採取行動，比如用單一樹種的林場取代原生森林。於是，一片森林被抽象成了一個“種植船桅的系統”。

這種方法催生了官僚機構和紙質表格，進而演變成了今天的網頁表單和數據庫。作為程序員，為了對世界採取行動，我們必須減少現實數據中的混亂。我們期望日期必須是精確的，期望人的名字相對簡單規範，期望數據在輸入時是完整的且隨着時間推移保持一致。每一個程序員和每一次系統設計，都在做出一種削足適履的強制妥協：我們決定系統應該反映現實的哪些方面，又該丟棄哪些方面。我這麼說並非為了批評，因為要想構建出不被無數特殊情況（我們稱之為“邊緣用例”，因為它們本應是處於邊緣的罕見情況）所拖垮的系統，這是唯一的方法。

但是，這個過程如此根深蒂固，以至於我們有時會忘記它同時也是一種人為的造作，尤其是在用它來描述人的時候。強制性別字段只接受“男”或“女”，並不能迫使性別的本質變得非黑即白；我們對種族的定義是一種不斷變化的社會建構。我們簡化的模型可能會給我們提供洞見（過去 20 年自閉症診斷率猛增了 300%！），但卻無法捕捉到這些洞見背後的潛在因素（這很可能只是因為我們對自閉症定義的改變以及篩查力度的加大）。退一步去審視任何模型是如何構建的，以及它遺漏了哪種類型的知識，這非常重要。每一次抽象，同樣也是一次遮蔽。

作為一名前數據記者，我學會了如何“審問”數據，並且嚴謹地防範我得出的答案可能會在哪些方面產生誤導。如果你想避免發佈令人尷尬的更正聲明，“迫害妄想症”絕對是數據記者最好的朋友。你不僅要能思考數據說了什麼，還要能思考它沒有包含什麼。

不幸的是，這種試圖跳出來審視系統本身的元認知，是 LLM 永遠無法做到的。對它們來說，模型本身就是現實。正如 Robin Sloan 在其引人入勝的文章《語言模型是在地獄裏嗎？》中精闢指出的那樣：AI 模型的構建基礎和它們看待世界的方式，都被極度剝離了細節。當你我看着一段文字時，我們能看到它的上下文（比如文本格式、標題、作者簡介、提供連結的網站等），而 LLM 僅僅在一個純粹由字母構成的世界裏運轉（嚴格來說，它們接收的是子詞標記，這就是為什麼早期的模型數不清單詞 'strawberry' 裏有幾個字母 'r'）。要求 LLM 去認識到它所看到的現實是有侷限性的，就像是問金魚水温怎麼樣一樣，對牛彈琴。

寫到這一節時，我滿腦子都是 DOGE（政府效率部）在社會保障局（SSA）試圖揪出欺詐行為時的那些拙劣表演。舉個例子，DOGE 審查了 SSA 的數據庫，發現裏面有超過 900 萬條記錄的出生日期在 120 多年前，卻沒有記錄死亡日期。馬斯克斷言，唯一的解釋就是數以百萬計的人在欺詐性地領取福利。但他對問題的起因和嚴重程度都判斷錯了。DOGE 本可以質疑數據質量，本可以去查查實際是否有錢打進了這些賬户，甚至本可以隨便找個 SSA 的專家給他們解釋一下。但他們沒有，他們直接照單全收了字面數據，並草率地得出了錯誤的結論。

這個套路他們玩了一遍又一遍。在另一個關於付款的欺詐指控中：

據查閲相關文件及知情人士向《紐約時報》透露，在隨後的廣泛分析中，政府機構專家仔細記錄了 DOGE 工作中的邏輯謬誤。
代理副局長肖恩·布倫在一份審查其中一個問題的備忘錄中寫道：“這些付款是合法有效的。”（財政部發言人拒絕置評。）
但據熟悉魯索先生言論的人士稱（魯索未回應置評請求），他表示 DOGE 不會信任這些職業公務員。相反，他堅持讓阿卡什·博巴，一名 21 歲、曾在帕蘭提爾實習併成為 DOGE 核心程序員的年輕人，來進行他自己的分析。

以他們自己狂野的方式，DOGE 團隊正在重演導致 LLM 走偏的同款邏輯。他們拒絕考慮任何在數據字面意思之外的替代解釋，拒絕與自己圈子之外的任何人交流，死死咬住一個極其簡化的解釋，僅僅因為這太合他們胃口了：這完美印證了他們“政府員工全都是蠢貨、欺詐行為無處不在”的世界觀。

我本人因為極其害怕讓自己看起來像個白痴，絕不希望把數據分析工作外包給 LLM。但有大把的人願意這麼幹。我擔心這個問題只會越來越糟。

摩擦是上天的恩賜

大語言模型驅動開發的魅力在於，它標榜能消除一切摩擦。吹鼓手們編織出美好的神話：開發團隊一天就能發佈幾十個新功能，在越來越奇葩的網絡拓撲結構下，指揮着好幾個 AI 智能體團隊自主運轉。我懂，軟件開發有時候確實枯燥又讓人抓狂。能夠以不可思議的速度瘋狂產出代碼，把玩着打磨精美的產品而不是半成品原型，那種感覺一定超級刺激。

但我需要這種摩擦。

剛開始學習一門新語言或新框架時，我連做最基礎的事情都要和摩擦搏鬥，這感覺糟透了。而當我在處理一個陌生的代碼庫或數據源時，我需要預留出幾個小時的時間去仔細審視它。我經常會做一些逐字逐句的深度死磕，打開特定的文件，一行一行地看，直到我完全理解它們的上下文，以及開發者做出這些選擇的原因。我知道，我大可以叫 LLM 幫我總結一下整個項目，省下這大把時間，但我真的需要這個在代碼裏“泡着入味”的過程。我需要的不僅是知道開發者做了什麼選擇，我還需要知道他們為什麼這麼選，以及這些選擇是如何反映出這門語言的侷限性或編程習慣的。我在失敗中學習，如果 LLM 把這部分苦差事替我幹了，我將永遠無法真正理解我到底在做什麼。

即使是在熟悉的語言環境裏寫我自己的代碼，我依然嚴重依賴摩擦作為重要的線索。當寫代碼變得非常困難時，這說明在當前的架構下我正走向一條歧路。它在提醒我，應該認真考慮重新設計，以便未來的擴展能更順暢。

遇到這種情況，我通常會出去散個長步（或者直接打卡下班），給大腦留點空間，退一步換個角度思考問題。這招真的管用。我發現這種停頓極其有效，以至於即便思路清晰，我也會強迫自己停下來。在開發大型軟件項目時，在開始為一個新功能寫代碼之前，我會先強制自己寫一份架構決策記錄（Architectural Decision Record，ADR），描述我想做什麼。這些文檔逼着我記錄下這一刻我的想法、我對問題的假設，以及我這套方案可能帶來的後果。有時候，寫着寫着我就意識到，我對自己最初的直覺太盲目自信了，以至於都沒發現它會把項目帶進溝裏；同時，對於未來接手我工作的繼任者來說，這也永遠是記錄“當年那幫傢伙到底在想什麼？”的絕佳途徑。

而 LLM 驅動開發對待摩擦的態度，就是不管三七二十一，閉着眼睛直接寫過去。LLM 會極其配合。它大概率能寫出能跑通的代碼，性能指標可能不錯，測試也能通過（尤其是如果測試也是 LLM 寫的話）。但它根本不知道自己為什麼選擇了那條路，它感受不到摩擦，也無法向你解釋一種架構方案是否感覺比另一種更清晰優雅。如果負責寫提示詞的工程師本身缺乏洞察力，不知道好壞方案的差別，他們就會陷入一種死循環：一遍又一遍地讓 AI 強行穿越重重摩擦寫代碼。最終生成一堆奇形怪狀的抽象邏輯，而留給未來團隊的唯一設計文檔，就是幾年前一個用來指示 AI 模型的 Markdown 孤本文件。祝你從那玩意兒裏重構出當年的架構決策好運吧！

不難看出，我所見到的大多數憑感覺編程的成功案例，要麼是開發者本身已經是該領域的專家（因此能夠駕馭 AI 的工作），要麼是那些哪怕搞砸了也無傷大雅的小項目。至於其他情況，我們只能想辦法自己判斷那著名的“如何畫貓頭鷹”梗圖中剩下沒畫完的部分到底畫得好不好、安不安全了。

還有一個讓我耿耿於懷的點：當 LLM 的推銷員們將“摩擦”視為眼中釘時，他們實際上在暗示什麼。在廣告、現場演示和 LinkedIn 帖子裏，大多數 LLM 營銷都在刻畫一位孤膽英雄般的工程師（或者一個單兵團隊），英勇地利用 LLM 驅動編程，以迅雷不及掩耳之勢噴射出一堆應用或網站併火速上線。但是，行業真正想要的是開發者在日常工作中使用 LLM，而在實際工作中，所謂的“摩擦”通常是指那些旨在防止缺陷或糟糕創意流入生產環境的既定流程和規範。

不可避免地，對“LLM 驅動速度”的狂熱追求，最終會把矛頭指向人本身，包括其他工程師、產品經理、項目經理、測試人員、合規審查員或者設計師。因為這些職位，現在也被視為了“摩擦”。既然我們能捏出 AI 用戶畫像，還要什麼用戶調研？既然 AI 工具能直接吐出網頁排版，還要什麼設計師？既然我們自己就是統帥 AI 智能體大軍的經理，還要什麼項目經理？如果我們不再需要等另一個開發者來審查我們的代碼，只要通過了測試和掃描就自動合併，那該多爽？如果我們再也不用把工作時間浪費在跟別人溝通上，而是直接飛昇到一個只剩純粹編碼的境界裏，那該多美？

但是，軟件開發是一項協作的過程，團隊裏的每一個成員都在為打造優秀產品貢獻力量。砍掉這些角色，或者用沾染着 LLM 氣息的代碼幽靈去替代他們，肯定能讓團隊跑得更快，但這絕不意味着他們交付的產品會更好。而且，這個過程絕對會變得無比孤獨。

我極其在乎

我不使用 LLM 的最簡單的理由，或許就是我太熱愛編程了，以至於我一點也不想把它拱手讓給機器。就像如果我是個畫家或音樂家就不會求助於 AI 一樣，編程是我表達創造力的一種方式，我絕不讓出這份純粹的快樂。儘管有時候它能把人逼瘋，但把一個朦朧的想法一點點塑造變成真實的系統，特別是如果其中還包含着優雅的實現或有趣的挑戰，這其中藴含着巨大的喜悦。有些晚上，我會合上工作用的電腦，打開私人的筆記本，一頭扎進我想做的某個好玩的新玩意兒裏。而在工作中，作為團隊的一員去構建軟件，那種感覺甚至更棒！我熱愛團隊協作，熱愛一起打磨軟件的過程，尤其是看到大家挺身而出、主動承擔解決問題的責任時。當團隊只是在“承擔提示詞的責任”，而由 LLM 助手在幹活時，我不認為這種動力還能維持原樣；或者更糟，當 LLM 助手直接取代了團隊的部分成員時。

責任感太關鍵了。在過去的幾十年裏，我在不同的崗位上培養出了強烈的個人責任感。作為一名前數據記者，代碼裏的一個 Bug 可能會導致極其難堪的報紙更正，或者引來滅頂之災般的訴訟。在公共科技領域，錯誤可能意味着為公眾提供服務和福利的系統徹底崩潰，無論是波及全體弱勢羣體，還是僅僅影響到一個普通人。我不敢說我從未犯錯，但我真的極其在乎把事情做對，因為我在乎這份工作的使命。我有幸曾與許多同樣在乎、同樣想盡全力為人民服務的同事並肩作戰。

而 LLM 是不可能“在乎”的。當然，它可以裝得非常逼真，但它依然只是一個試圖模仿人類心智的贗品，所做的只是把那些在統計學上更容易同時出現的詞組串在一起罷了。它不會因為犯錯而感到懊惱，也不會努力試圖改進，因為它沒有內在的意識，更別提什麼道德良知了。它永遠無法被追責，因此，我永遠也不能把我的道德責任外包給它。

當 LLM 表現良好時，它是即將取代所有程序員的天才；而當 LLM 刪除了你所有的基礎設施，或者在測試結果上“撒謊”時，錯的卻是你。畢竟，誰叫你沒把提示詞和工作流精確地配置好，沒能“哄”着 LLM 給出正確輸出呢？哎呀，再試一次吧，再試一次。我讀過的大量 LLM 教程都在反覆強調：你必須在一開始就把所有必要的指令、修正條款和附加說明統統餵給它，否則系統就會把事情搞砸。這種思維模式和敏捷開發完全背道而馳，敏捷開發講究的是頻繁修正方向、及時拿到反饋、信任團隊能做出正確的選擇。我們似乎正在倒退回一種類似於 1950 年代早期計算機的分時共享模式。只不過這一次，孤單的程序員不再是抱着一沓打孔紙帶排隊上機，而是拿着厚厚的“法律合同”指望機器把它變成程序。

我開個玩笑；這裏其實不涉及什麼法律責任。考慮到兩者受眾羣體的相似度，這也許不足為奇，但 LLM 供應商正在重演特斯拉的套路。他們在沒有進行安全測試的情況下就把新功能推送給用戶，而且詭異的是，就像特斯拉的狂熱死忠粉一樣，LLM 的鼓吹者們在面對災難性後果時，往往會責怪自己和他人，聲稱這是因為用戶的提示詞寫得不夠好。我實在不知道該怎麼評價這種現象，但科技界正在將一種極端的資本主義標準化，讓消費者承擔更多的風險，因為企業和政府雙雙放棄了他們的監管責任，這讓我感到極度不安。當初僅僅因為砸死了一個孩子，我們就全面封殺了容易誤傷致命的草地飛鏢遊戲，但逼得用戶自殺或精神失常的 AI 聊天機器人，卻被視為了 AI 創新必須付出的合理代價。是不是非得等到憑感覺編程引發系統崩潰導致人員傷亡，而不是僅僅死於尷尬時，情況才會有所改變？

在艱難的時刻，寫代碼也一直是我的慰藉。有研究表明，玩俄羅斯方塊是預防創傷後應激障礙（PTSD）的有效方法。這個理論認為，讓大腦中負責排列和旋轉圖形的部分保持活躍，能阻礙創傷記憶的形成。如今，我很幸運沒有患上 PTSD（我絕不是在拿患者開玩笑），但我對這個概念深有共鳴。編程就像是在解一個複雜的謎題，在黑暗的時期，它常常是我的避風港。正像前面提到的例子所暗示的，我對 DOGE 非常瞭解，因為在過去的一年裏，我一直在構建和維護一個追蹤他們瘋狂行徑的系統。與工作項目不同，這完全是一場收集並拼湊數據集的練習，目的是讓一個拼命想要隱藏自己的組織暴露在陽光下。這是一個極其充實的過程，也是我將絕望轉化為希望能有些用的東西的途徑。這已經不是我第一次用代碼作為化解悲傷的手段了，它之所以管用，正是因為它是一項需要投入精力的工作。如果我只盯着最終的結果，這個療愈的過程就會大打折扣。

其他幾個可笑的理由

這篇小文的長度已經遠遠超出了我的預期，畢竟它最初只是我想發在 Bluesky 上的幾段簡短牢騷。在結束之前，再快速補充幾個理由。

首先，我極度反感 AI 聊天機器人默認的那種油腔滑調的語氣。作為一個在美國東海岸城市長大的人，當一個我不認識的人突然對我表現得熱情過頭、客氣得有些詭異時，我就會本能地警覺起來，因為這通常意味着他們要麼準備騙我的錢，要麼準備向我傳教。讀 LLM 的聊天記錄會讓我起雞皮疙瘩。是的，我知道我可以通過設定讓 LLM 換一種語氣，但不知為何，這隻會讓整個事兒感覺更糟。

和許多開發者一樣，我也存了整整一個文件夾的草稿，裏面全是那些永遠沒填完坑的業餘項目。比如，我曾經打算用 Clojurescript 寫一個拼字遊戲的克隆版，因為這樣我就可以利用 Blabrecs 裏的代碼生成一堆根本不存在的假詞，故意把遊戲搞得讓人抓狂。好吧，我承認這可能只是我個人的惡趣味，你得設身處地才能 get 到笑點。從 LLM 的角度來看，這些都是裝滿失敗的文件夾，我確實可以用 LLM 來搞個“一天做一個 App”之類的挑戰。然而，過程遠比結果重要。不是每一個突發奇想的腦洞都必須變成現實產品，通常情況下，我從頭腦風暴的樂趣中，以及為了證明“我沒必要把這玩意做完”而學習新知識的過程中，獲得的收穫要多得多。

我原本不打算在這篇文章裏討論在工作中使用 LLM 的道德問題。不是因為我不在乎，而是因為已經有太多比我聰明的人，極其深刻地論述過這項技術所帶來的令人憂慮的隱患。在當下這個 LLM 正在向帶有兒童的學校發送炸彈威脅，或者按需生成兒童色情內容的時代，我真的不放心使用它們。如果我連提都不提這方面，我心裏也會過意不去。在資本主義的框架下，也許確實不存在絕對道德的消費，但就算見鬼，我也至少要努力去嘗試一下。我們不可能用一種讓如此多的人陷入悲慘境地的工具，來建設一個更美好的世界。

說來也怪，似乎沒有誰比這幫 LLM 的吹鼓手們活得更苦大仇深了。如果開發者們利用他們新獲得的“生產力暴漲”，終於過上了 10 年前這幫極客們假裝膜拜的每週工作 4 小時的烏托邦生活，我可能還真會被打動。但病態的是，硅谷的許多人似乎把工作外包給了 AI 智能體之後，反而利用節省下來的業餘時間去接了更多的工作。他們沒有把時間用來休息、搞藝術或享受生活，而是擁抱了 996 工作制，以及一個高度量化的工作環境，這甚至會讓以極度壓榨著稱的科學管理學派祖師爺弗雷德裏克·泰勒看了都直冒冷汗。也許 LLM 革命最終會席捲我和我的飯碗，但在那之前，我可不想先把自己捲進墳墓裏。

未來路在何方？

我不會假裝自己能預知未來。也許這項技術真的會發展到不可思議的地步，以至於我會後悔當初沒有積累足夠的經驗去熟悉它。又或者，它也許會陷入停滯，整個建立在炒作之上的金融紙牌屋轟然倒塌。如果那一天真的到來，我希望我們能把軟件開發重新建設成一種充滿人性關懷的實踐。

引用連結

[1] Why I Don’t Vibe Code: https://jacobharr.is/personal/i-dont-vibe-code