hero

這是一篇關於「認知失調」的文章——不是那種自我安慰式的「批評者不懂」，而是赤裸裸地承認：我知道所有批評 LLM 的論點都是對的，但我還是每天在用。作者 Jeremy Theocharis 上週在柏林的 Local-First Conf 親眼看到一個場景：全場鼓掌批判 LLM 的演講，同一個房間裡一堆人的筆電開著 Claude Code。這不是虛偽，這是一種還沒被命名的新型認知狀態。我翻譯這篇，因為它是極少數願意把這個矛盾攤開來、而不是選一邊站就完事的文章。

原文深度翻譯

開場：明明同意所有批評，為什麼還在用？

Jeremy Theocharis 在一開頭就攤牌：他幾乎同意所有 LLM 批評者的論點，但他仍然大量使用 LLM。他知道這聽起來像自我欺騙，有時他自己也這麼覺得，但他不認為自己是唯一有這種感覺的人。

上週在柏林的 Local-First Conf，這種矛盾無所不在。Flask 框架的創建者、Sentry 早期團隊成員 Armin Ronacher 剛做了一場關於「建造機器實體」的演講。他最近創辦了公司 Earendil，開發 Pi.dev——一個「開源 coding agent harness」。演講後觀眾可以透過 Discord 提問，由主持人在台上朗讀出來。Jeremy 問了一個問題：

你們接受 PR 嗎？或者說，你們怎麼處理 LLM 產生的大量 PR？

Armin 在台上，當著全場觀眾的面回答：他們幾乎自動關閉（auto-close）所有 PR 和 issue。但他補充說，不應該因此不敢開 PR，因為「人類永遠會從中脫穎而出」。

Jeremy 的觀察是：所以不只是我，顯然一些非常聰明的工程師也是如此。這群人正在打造一個跟 LLM 協作的工具，卻被自己創造的東西淹沒，為了保護自己只能全部 auto-close。而在他們的目的頁面上寫著：

在一個奔向 AI 的世界裡，我們相信人類是最好的 agent。

又是一個矛盾。

當 Jeremy 坐在觀眾席時，他看到很多人開著 Claude Code。然後講者們說出批判 LLM 的話，獲得全場熱烈掌聲——包括那些筆電上開著 Claude Code 的人。再一次，矛盾。

Jeremy 自己也在這場研討會上演講，事後跟一些人交談，發現他們描述的感覺得自己的非常相似——這讓他鬆了一口氣，因為他知道自己並不孤單。

所以這篇文章是他的嘗試：先整理所有合理且有效的 LLM 批評——那些會獲得滿堂掌聲的論點——然後解釋為什麼他仍然使用 LLM，最後分享他發現的一些使用模式，希望藉由具體例子讓其他人也能描述自己的經驗，一起理解這種矛盾。

LLM 很糟糕

Jeremy 說，光是聽人說話、聽演講、讀 Hacker News，他就能清楚掌握為什麼有些人拒絕使用 LLM。而讓整件事極其詭異的是：他幾乎同意他們的每一個論點。

訓練資料充滿版權素材——是的。對環境不好——是的。所有的倫理問題——是的。NVIDIA、OpenAI 之間那個錢滾錢的共謀循環不會有好下場——這是一個泡沫，它遲早會破。

然後他逐一展開最核心的批評。

1. LLM 產生大量 slop（垃圾內容）

最常見的批評就是「LLM 產生大量 slop」。Jeremy 的答案：是的，毫無疑問。

看看開源軟體的世界：越來越多 repo 和專案要嘛直接拒絕所有 LLM 貢獻，要嘛試著在前面放某種過濾器——就像 Armin 和他的 Earendil 團隊在做的 auto-close。

Jeremy 認為核心問題是「信任」。你本來就不該信任網路上隨機的人，但在 LLM 出現之前有個基本門檻：要產生一個有適當描述的、像樣的 PR，至少需要花一些人類時間，所以這道門檻自然排除了 troll 和低品質提交——或者至少你可以在幾秒內把它們過濾掉。即使一個新人來了，你可以相信這個人至少花了幾個小時在上面，那麼這個 PR 可能值得仔細看。

現在這個基本門檻不存在了。任何人都可以建一個新的 GitHub 帳號、放 LLM 出去跑，然後作為維護者你無法輕易判斷：這個人是否花了大量時間在 PR 上（可能只是用 Claude 寫 PR 描述），或者這只是一個 OpenClaw 機器在自動運作。像 Zig 或 Gentoo 這樣的專案已經拒絕接受 LLM 生成的 PR——但 Jeremy 不認為這是解法，因為你要怎麼判斷？

Jeremy 提出一個更嚴重的擔憂：LLM 可能真的有能力殺死開源，如果我們找不到方法重建信任的話。一個可能的想法是只允許一小群經過驗證的人貢獻專案，而要被驗證你需要去參加真實世界的線下聚會之類的。

2. 初階工程師的雙重困境

這裡有兩個獨立的問題。

第一個：你再也無法信任初階工程師程式碼背後的「努力」。資深的人本來就一直在修正初階的程式碼，初階的人本來就寫過一些很爛的程式碼（Jeremy 承認自己最爛的程式碼是 LLM 時代之前寫的）。差別在於，現在作為資深審查者，你不知道那個初階工程師是花十分鐘用 vibe coding 生出來的，還是他真的坐在那裡好幾個小時但就是缺了一些好的洞察。

第二個：教學問題，也就是「我們怎麼教新人？」以前有個平衡——「初階做無聊的例行任務，資深陪他一起審查並幫他成長」。現在作為資深的人，你不需要初階工程師了。那些例行任務——至少 Jeremy 發現很多人同意這點——完全可以外包給 LLM。那為什麼還要僱用初階？

3. 地緣政治風險

如果中國或美國一夜之間把我們從這些技術中切斷怎麼辦？就在幾週前，美國政府展示了自己有能力且願意切斷非美國公民對 Anthropic 最新前沿模型的訪問——Anthropic 自己在 2026 年 6 月 12 日的聲明指出，一道美國出口管制指令迫使他們突然對所有客戶停用 Fable 5 和 Mythos 5。

Jeremy 不想當末日預言家，但他引用 Martin Kleppmann 在台上說的一句話：

歐洲和美國之間發生衝突的機率仍然很低。但去年，這個機率是零。

4. LLM 會悄悄同化你的觀點

即使只是在研究時使用 LLM，它們也有一種自然傾向：會悄悄滲入訓練資料中多數意見的思維，有時甚至是建立模型者本身的政治信念。

Jeremy 的比喻是：這就像兩個人長期對話一樣，他們的意見會慢慢融合。你有沒有注意到某個朋友一直用一個奇怪的詞，然後幾週後你整個朋友圈都在用？LLM 就是這樣，只是對象換成了「意見」。而且對話的其中一方不是人類。

LLM 也很好

但我們已經無法讓它們完全消失了。它們在這裡，而且會留在這裡。與其逆流而行，不如順流——然後去控制它、塑造它。

1. 本地模型是真正的防線

例如，確保模型可以在你的筆電上跑。它們已經越來越好，而且讓我們程式設計師獨立於那些大公司。當補貼結束、價格上漲時，是開放權重的模型在牽制大型供應商。而一個在你自己的硬體上本地執行的模型，任何政府都無法一夜之間切斷。Jeremy 甚至認為，當泡沫破裂時會對世界經濟造成重大損害，很多公司會倒下，但開放權重的模型不會去任何地方——我們程式設計師可以退回到它們身上。即使在這個研討會上，跟 AI 相關的演講也大多認真看待本地模型。

2. 人類押上自己的信譽，這才是關鍵

在很多演講中，AI 只是順帶出現：「我們用 Claude Code 做了這個。」有些講者甚至公開說：「對，我就是丟給 Claude Code。」但他們的演講被接受了，而且獲得全場熱烈掌聲——包括一些相當資深且備受尊敬的人。

真正的關鍵是：有「人類」把自己的信譽押在上面。而這讓你願意聽。如果他們呈現的內容帶有 AI slop，他們會失去信譽。Jeremy 認為這讓他們以不同的方式使用 AI。他們說「我只是叫 Fable 5 實作它」——聽起來像個 tech-bro，而 Jeremy 自己也會這樣描述。但他推測（他只能代表自己）：他們不是讓 LLM 來思考。那是他們自己的想法，只是被超級充電、打了一針興奮劑。

LLM 放大你本來就有的東西：觀點、結構、框架。如果你有想法，它們出來得更鋒利、更快。它們擅長協助腦力激盪、檢查文法、迭代句子、提供替代方案、扮演橡皮鴨或魔鬼代言人。如果你什麼都沒有，那什麼都不會出來——只會很流暢地出來一堆沒有人會在觀眾面前朗讀的內容。

Jeremy 認為價值就在這裡：他可以讓東西的品質比他單獨能做到的更高。他可以用 LLM 做更多事，但他選擇是：用 LLM 讓「更少的事情」做得品質更高。他會消耗極大量的 token，只為了準備幾句話給一個人類看。他認為這是 LLM 的一種好用法。

3. 信任是唯一的貨幣，但它從外面看不出來

Jeremy 強烈同意「書寫的文字應該是從人到人」。但他仍然用 LLM 寫所有的文字，而且他不覺得這矛盾。

區分「AI slop」和「好文章」的關鍵是：有沒有人類把思想放在背後。而思考是無法外包的。但問題就在這裡：有沒有人類把思想放在背後，恰好是你從外面看不出來的。「我用 AI 來更好地思考」這句話，從 Jeremy 口中說出來和從某個隨機 AI tech-bro 口中說出來，字面上完全一樣，你無法判斷是 bullshit 還是真的。你就是做不到。因為被放大的 bullshit 聽起來像天才，最後剩下的只有「信任」。而信任很難獲得，很容易失去——尤其在 LLM 時代。

Jeremy 自己也會中招：一個全形破折號（em dash）就可以讓整篇文章在他心中失效，他會忍不住想「這個人至少能不能把 AI slop 的明顯痕跡去掉？」

在研討會的 Discord 中，有人問其他人怎麼處理這種張力：很多在政治上對 local-first 感興趣的人，同時也是堅定的反 LLM 派。用 LLM 做軟體，知道可能會被社群拒絕，這讓他們擔心嗎？有人回答：很多講者——包括當時在台上的那位——對這件事有「複雜的想法」。

Jeremy 自己也有點害怕說出這件事：上個月他花了將近一萬美元在 token 上，聽起來太瘋狂了。他後來做了兩個調整：Fable 現在只在非常選擇性的時候用，太貴了；純程式碼執行他改用 OpenRouter 和更便宜的模型如 GLM 5.2。但他的結論是：一個人真的可以從中獲得大量價值，而他認為這是值得的。

4. 信譽來自你敢不敢在觀眾面前唸出來

當 AI 還是新東西的時候，Jeremy 曾經部分毀掉自己的信譽。但他後來意識到，信譽就是你如何贏得信任的方式：你願不願意站在觀眾面前把它唸出來？如果答案是「呃，我會解釋它的意思」，那它就是 slop。如果你真的會逐字逐句唸出來，而且不覺得羞愧——恭喜，這是一篇好文字。

我發現的一些使用模式

Jeremy 說，有一條難以描述的、只能透過開放心態使用這些工具才能體驗和學習的「細線」。他試著描述一些他發現的模式，不是作為「你應該這樣做」的指南，而是希望幫助釐清狀況。

1. grill-me 技能：強迫你自己形成想法

是的，LLM 在不理解實際問題和需求時會寫出爛軟體。有正確的技能和工具，你可以產出相當不錯的軟體。但在你和那個不錯的軟體之間，橫著一個障礙叫做「agreeableness」——LLM 不會告訴你它沒理解某件事，它就直接做了。這就是為什麼 /grill-me 技能如此強大。

這個技能改編自 Matt Pocock 的「grill me」技巧，內容極短：它要求 LLM 無情地盤問你關於這件事的每一個面向，直到達成共識；每次問一個問題，等你回答再繼續；可以從環境中找到的事實就不要問你；決定權在你，但每個決定都要你確認。

Jeremy 說，這個 grill-me 感覺非常好——因為它強迫你一個問題接一個問題地形成自己的想法。他現在把這種逐步推進的方法用在所有事情上，就是那種「為了一句話燒掉大量 token」的方法，例如寫文章。他這篇文章的寫法就是：先混亂地把想法全部倒出來，然後逐句讓 LLM 狠狠地 roast。

2. Basecamp Pitch：三句話強迫你讀

每當他寫程式——即使是小事——他遵循 Basecamp 的「Pitch」格式，非常非常認真地想一個簡短的「問題」、「我們要交付什麼」、「我們不交付什麼」。他強迫自己寫一個三句話的問題陳述。

這超級容易——尤其有 LLM 時更容易填充內容——但要把它做好卻極其困難。Jeremy 認為這在 LLM 工作流中如此有效，恰好因為它是為人類設計的：三句話強迫你真正去「讀」它們。而如果你會讀，另一個人類也可以讀。他承認自己現在幾乎不再真正閱讀大部分 LLM 輸出，只是瀏覽一下，感受一下「我對這個 vibe 有沒有感覺」。但一個三句話的問題陳述，他會極其認真地核實事實。

就像 code review 一樣：一千行 code 的 review 只會得到「LGTM」，一百行的 review 會得到十五條評論。

3. Ralph Wiggum 迴圈：讓 LLM 互相撕碎

另一個他喜歡的技巧是「Ralph Wiggum 迴圈」或更現代的名稱「Claude 的 ultracode」：把 LLM 鎖定在一段文字、計劃、陳述或程式碼中，然後不斷生成子 agent（具有全新 context 的 LLM），它們唯一的任務就是把那個 context 撕碎。一直這樣做，直到它們被逼到開始幻覺問題為止——然後才繼續工作流。

如果 LLM 被逼到開始幻覺，你其實可以利用它們的弱點：它們試圖同意你「這裡面有問題」，但它們找不到任何問題。

尤其搭配 grill-me 技能使用時，你會得到一個結果：作為人類的你沒有任何進一步的評論或想法——連最微小的想法都沒有。LLM 已經試圖撕碎你的想法了，有時候 roast 了你好幾個小時，強迫你形成自己的想法。

4. 把幻覺變成測試工具

甚至還有一種利用幻覺的方法：在去年的研討會上，Anselm Eickhoff 描述了你可以讓 LLM 在「看到真正的東西之前」先幻覺出它預期的 API 或 UX。LLM 猜的結果，大概就是大多數人類也會猜的。所以與其對抗幻覺，你把它當成一種廉價測試：你的設計是否符合人們的預期。Jeremy 也把這做成了一個 skill。

5. 你必須能判斷結果好壞

所有這些模式有一個前提：Jeremy 必須能判斷結果是好是壞。而他越用 LLM，就越常進入他不熟悉的領域——這時候他就需要專家。因為他只能在他理解的事情上寫程式。這就像 delegating：他只把任務交給團隊成員，前提是他至少理解基礎、知道什麼是「好」。LLM 也是一樣。

如果他很熟悉某件事，他可以快速區分「好」跟「徹頭徹尾的垃圾」。如果他不熟悉，他只會用 LLM 來幫助自己學習。因為如果他在還無法區分好壞的時候就使用 LLM，他會變成全面的 slop 生產機。

6. 兩種學習路徑：有明確對錯的 vs. 充滿意見的

Jeremy 區分了兩種學習情境。

第一種是結果可以明確被區分為對或錯的情境——不是「程式碼好不好」這種主觀問題，而是程式碼有沒有編譯過、測試套件有沒有變綠、協定有沒有解碼成功。在這種有明確檢查機制的領域，你可以讓 LLM 指向它，然後一起學習。研討會上有個人描述他如何用 Opus 4.6 逆向工程二進位檔案和協定——他只需要基本的逆向工程知識。要嘛他的修改過的二進位檔案能跑，要嘛它把裝置變磚頭，結果是對是錯一目了然，所以他甚至能在過程中發展出自己的技巧。

第二種是充滿意見的領域，像是程式設計。在這種領域，LLM 只會告訴你大多數人想要什麼——最流行的技巧——但那可能不是對你案子最好的技巧。Jeremy 舉例：他們團隊有次討論，有人說某段程式碼是 AI slop，是一個普遍的 AI 問題。深入聊下去後發現，他們其實是不喜歡 TDD。但團隊裡還有另一個成員，在 LLM 時代之前就大量做 TDD。於是「AI slop」突然不再是關於 AI slop 了，而是關於人類有不同的意見。而 LLM 只會放大——你可以用它來放大你的意見。在這裡你需要人類，來幫你指出大致正確的方向、給你好的起始意見，然後你用它直到你能自己繼續前進。

我不孤單

Jeremy 在結尾說，他希望讀者能信任他，但他完全理解如果不行。唯一真正知道的方法是接觸他的內容，但這需要大量時間。如果你讀到了這裡，你以經跟這篇文章互動了相當長的時間——也許你已經知道這篇文章投入了大量心力，不是什麼明顯的 slop。

他不是唯一有這種矛盾的人。在寫這篇文章的過程中，他翻遍了研討會的 Discord、直接問了研討會上的人、回顧了過去幾週的 HN 文章——這些都讓他看到：其他人也在描述同樣的矛盾。

他希望其他人也能描述他們的經驗和學習路徑，來釐清那條細線。在所有這些混亂中，存在著真正的好東西——不是炒作，而是一個真正能豐富你思考的好工具。但它永遠不會取代你的思考。

去吧，試試看。他知道這正是 tech-bro 會說的話——他沒辦法用別的方式說出口。

最後他感謝所有在 Local-First Conf 遇見的人：「你們讓我的腦袋資訊爆炸。」

城武觀點

這篇文章的價值不在於「批評者是對的但我還是用」——這太容易了。真正的張力在於 Jeremy 描述的那個場景：全場鼓掌批判 LLM 的演講，同一群人的筆電上 Claude Code 開著。這不是虛偽，這是一種還沒被命名的新型認知狀態。

LLM 批評者的論點在抽象層次完全正確——版權、環境、slop、地緣政治風險，每一條都對。但在具體的工作流中，這些論點完全無用。不是因為它們錯了，而是因為批評框架還停留在「工具 vs 人」的二元對立：工具是壞的，人是好的，所以要抗拒工具。但實際使用者的體驗不是這樣——實際體驗是「我在用一個同時讓我變強也讓我變懶的東西」。它讓你能做到以前做不到的事，同時也讓你失去了一些以前擁有的能力。批評者需要更新他們的框架：問題不是「用還是不用」，而是「用了之後我變成了什麼樣的人」。那個鼓掌時開著 Claude Code 的工程師不是在說謊——他只是在用一個舊的語言描述一個新的狀態，而詞彙還沒被發明。

Armin Ronacher 的案例特別有意思：一個正在做 AI coding agent 的人，被迫 auto-close 所有 LLM 生成的 PR。城武立場很明確：這不是 bug，是 feature。

LLM 同時降低了兩個東西：貢獻的門檻，和貢獻的品質。當門檻降到零（一個 GitHub 帳號 + 一句 prompt），品質的分佈就從「大部分可接受，少數垃圾」變成「大部分垃圾，少數可接受」。在這種分佈下，維護者的審查成本超過審查收益——你花三十分鐘看十個 PR，九個是垃圾，唯一的成本效益解法就是 auto-close。這不是懶惰，是數學。

這是開源維護者未來十年的核心矛盾。auto-close 只是第一道防線，真正的解法不是更好的過濾器（因為 LLM 也會變得更難過濾），而是從新定義「貢獻」的意義。也許未來的貢獻不是「我幫你寫了這段 code」，而是「我幫你驗證了這個假設」「我幫你定位了這個 bug 的邊界條件」「我幫你寫了這份測試矩陣」。問題不是人變懶了，而是我們還在用舊的貢獻定義丈量新的生產方式。

城武的未解檔案——當全場鼓掌罵 LLM 的人筆電上都開著 Claude Code，你不是看到虛偽，你是看到人類還來不及發明詞彙來描述自己正在變成什麼。