為什麼我不「憑感覺編程」 (Why I Don’t Vibe Code)

原始來源與檔名：2026-05-19T092706+0800-为什么我不“凭感觉编程”.md

NAPKIN | 餐巾纸

餐巾紙公式

軟體開發的真實價值 = 本質複雜度的克服 + 透過摩擦建立的深刻理解 + 道德與責任感的承擔

一句話

AI 只能解決「偶然複雜度」，但消除所有「摩擦」的代價，是喪失對「本質複雜度」的理解與掌控；真正的編程不僅是產出程式碼，更是一種建構抽象模型與承擔道德責任的社會實踐。

餐巾紙草圖

[Vibe Coding] 消除摩擦 -> 無意識生成 -> 喪失架構直覺與技術掌控力 (盲目飛行)
[傳統編程] 擁抱摩擦 -> 深入思索抽象與邊界 -> 獲得深層理解與架構演進 (建立心智模型)

ROUND 1: SKELETON | 骨架掃描

核心問題: 為什麼在 AI 時代「憑感覺編程 (Vibe Coding)」被吹捧為未來，但資深工程師卻拒絕這種無摩擦的開發方式？
核心答案: 因為消除摩擦的同時也消除了學習。LLM 無法處理軟體工程中的「本質複雜度」，缺乏後設認知 (Meta-cognition)，無法為程式碼負責，且會摧毀團隊協作的意義與樂趣。
論證結構: 經驗反思 -> 理論支撐 (人月神話) -> 數據陷阱分析 -> 價值觀辯護。

章節骨架

本質與偶然的二元對立: AI 只解決了敲鍵盤的「偶然複雜度」，卻無法應對設計優雅系統的「本質複雜度」。
抽象的盲點: 程式設計是簡化現實的過程。LLM 無法跳脫模型本身去思考「什麼被遺漏了」(缺乏後設認知)。
摩擦是上天的恩賜: 在死磕程式碼與架構決策 (ADR) 的「摩擦」中，我們才學會了「為什麼這樣設計」而非僅僅是「寫出程式碼」。
道德外包的荒謬: AI 沒有意識，不會懊悔。把開發變成純粹的指令生成，是在逃避對產品與社會的個人道德責任。
反烏托邦的工作文化: Vibe Coding 的倡導者並未用省下的時間去享受生活，反而擁抱了更病態的自我壓榨 (996)。

ROUND 2: DISSECTION | 血肉解剖

隱形假設: 軟體的價值在於解決人類真實世界的問題，這需要高度的同理心、脈絡感知與責任感，而這些是基於統計學機率的 LLM 永遠無法具備的。
邊界條件: 若任務是縮放圖片、寫樣板程式碼或是一次性腳本，AI 的確極其高效；但若涉及核心架構設計、牽涉公眾利益的資料分析，AI 的幻覺與缺乏常識將帶來災難。

ROUND 3: SOUL | 靈魂提取

知識連結: 呼應 Fred Brooks 在《人月神話》中提出的「沒有銀彈 (No Silver Bullet)」理論；以及技術官僚主義將複雜現實強行量化的危害。
深層洞見: 摩擦 (Friction) 不是系統的 Bug，而是學習的 Feature。如果 LLM 把所有苦差事都代勞了，工程師將淪為只能閱讀而無法創作的技術文盲，留下無人能理解的「AI 屎山」。
行動呼籲: 不要把大腦外包給機器。在遇到困難時，強迫自己停下來寫架構決策紀錄 (ADR)；把編程視為一種創造力的表達，拒絕讓渡這份純粹的快樂與責任。

為什麼我不「憑感覺編程」 (Architectural Deep Dive)

前言/背景

近期科技圈熱炒「憑感覺編程 (Vibe Coding)」，鼓吹完全依賴 LLM 自動生成應用程式的烏托邦。本文作者 (資深開發者 Jacob Harris) 從根本上反駁了這種去脈絡化的開發狂熱。他指出，編程不只是製造會動的程式碼，更是透過「抽象」理解世界的過程。過度依賴 AI 將剝夺開發者與系統「摩擦」中產生的深刻理解，並將最終的道德責任與工程紀律消解於無形。

章節詳細總結

複雜度的永恆難題 (偶然複雜度 vs. 本質複雜度)

偶然複雜度 (Accidental Complexity)：撰寫語法、編譯流程、API 調用。這些確實是繁瑣的勞動，AI 就像更高級的編譯器，極大地削弱了這部分的負擔。
本質複雜度 (Essential Complexity)：設計出正確、優雅、可維護的系統架構，處理現實世界中詭異且混亂的邊緣案例。這項挑戰永遠不會消失。LLM 無法解釋它為何選擇特定架構，也無法應對無法直接套用標準答案的複雜性。

缺乏後設認知的 AI 陷阱 (抽象的遮蔽性)

抽象即遮蔽：寫程式的本質是建立抽象模型（如把森林抽象為木材產量）。但每次抽象必定會丟棄部分現實。人類開發者 (如資料記者) 會隨時保持警覺，質問數據背後隱藏了什麼。
LLM 的視角極限：LLM 無法進行後設認知 (Meta-cognition)。對它而言，字元標記 (Tokens) 就是整個現實。它無法意識到資料的荒謬性，只會盲目迎合使用者的偏見（例如 DOGE 錯誤分析社會安全局數據的案例）。

摩擦是工程師的導師 (摩擦是上天的恩赐)

摩擦即回饋：當寫程式感覺極度困難時，這不是在呼喚 AI 幫忙硬幹，而是一個架構警報，提醒你設計方向走偏了。
知其所以然：在陌生的程式碼中「泡著入味」是必須的。如果你只看 AI 生成的總結，你只知道系統「做了什麼」，卻永遠無法理解設計者「為什麼這麼做」。
沒有 ADR 的災難：LLM 面對摩擦的解法是「強行生成代碼」。最終留下的只是一堆難以理解的抽象邏輯，以及幾行無法逆向工程的 Prompt，徹底摧毀了系統的長期可維護性。

協作的溫度與道德的重量 (责任感太关键了)

不可推卸的責任：軟體系統深刻影響著公眾生活。LLM 只是一個把字詞機率性串聯的統計模型，它沒有意識，不會感到懊悔。將開發工作全盤交由 LLM，等同於逃避人類的道德責任。
軟體工程是社會實踐：砍掉團隊中的 PM、設計師與審查機制，換上 AI 幽靈，或許能極速發布產品，但這不僅會讓產品質量下降，更會讓開發過程變得極度孤獨與病態（諷刺的是，省下的時間反而被用來進行更深度的自我壓榨 996）。

總結與結論

不要神化 AI 工具：AI 是降低偶然複雜度的利器，但它絕不是軟體工程的「銀彈」。
擁抱心智摩擦：保留對程式設計的熱愛，將克服困難視為建立心智模型與架構直覺的必要修煉。
堅守專業底線：在系統崩潰或造成社會傷害時，沒有人可以把責任推給「提示詞寫得不好」。軟體工程師必須對自己設計的抽象模型負起最終的道德責任。