每個人都瘋了——對 AI 炒作、資源錯置與產業疲勞的批判性審視

TL;DR – AI 炒作正在耗盡工程人才、推高環境成本，且未能提升安全性，因為真正的瓶頸在於修補程式，而非漏洞發現。

這篇題為「每個人都瘋了」（2026 年 9 月 16 日）的文章主張，當前的 AI 熱潮迫使工程師將大部分時間花在脆弱的代理（agentic）管線上，卻忽略了資產清單、自動化修補與跨團隊協作等基礎營運衛生。作者警告，這種資源錯置助長了資料中心能源的浪費、促成了有害內容的生成，且並未提供任何可衡量的安全效益。

1. AI 過度曝光正在侵蝕工作滿意度

「每天花費超過 75% 的時間直接或間接地處理 AI，這徹底剝奪了我對工作的大部分樂趣。」

身為資深工程師的作者描述了一種 AI 增強工具主導工作流程的日常現實。評論者們對此感同身受：

@Ancalagon：「這完全說中了我的經歷。」
@BadBadJellyBean：「我對這篇文章感同身受。我厭倦了指揮代理程式……這感覺就像在牧放幼兒。」

大家的共識是，不斷地對大型語言模型（LLM）代理進行提示（prompting）令人精疲力竭，並降低了對工藝的追求感。

2. 真正的安全瓶頸不在於發現漏洞

「發現漏洞從來都不是資訊安全中的瓶頸。瓶頸一如既往，在於讓該死的套件保持更新。」

作者批評了業界將焦點放在用於漏洞發現的「前沿模型」（例如 Anthropic 的 Glasswing、OpenAI 的 Daybreak）。企業投入數百萬美元進行 AI 驅動的掃描，但大多數發現的結果並未轉化為更安全的系統，因為修補程式的部署仍然緩慢且依賴人工。

@AIiscoming 對此觀點提出異議，但作者引用了他自己的部落格 [Patching is hard] 作為佐證，該文詳細說明了及時更新所面臨的系統性挑戰。
@tptacek 指出漏洞研究仍然很重要，但作者的觀點是 AI 並未消除核心的營運摩擦。

重點： 投資於健全的資產清單、自動化作業系統/應用程式更新以及定期重啟，其安全投資報酬率（ROI）遠高於將工程時間花在 AI 生成的錯誤報告上。

3. AI 軍備競賽加劇了環境影響

「AI 競賽需要越來越多浪費水、污染空氣且依賴化石燃料的資料中心。」

這篇文章連結至 Bloomberg Law 和《紐約時報》的報導，記錄了資料中心叢集導致的天然氣消耗增加以及引發野火的熱能排放。評論者鮮少挑戰這一說法；該敘述與大眾對 AI 碳足跡的廣泛擔憂一致。

關鍵點： 若無監管壓力或真正的綠色承諾，AI 公司將繼續擴張能源密集型基礎設施，將氣候成本外部化給社會承擔。

4. 道德盲點與危險能力

作者列舉了幾項備受矚目的危害：

將生成兒童性虐待素材（CSAM）作為登入使用者的「產品功能」。
將 AI 用於軍事目標選擇，包括小學。
企業在花費大量「代幣」於投機性 AI 服務的同時，卻在口頭上採取「撇開道德不談」的立場。

這些說法源自近期的新聞報導（The Guardian, Ars Technica），說明了擬人化的行銷如何掩蓋了潛在風險。

5. 「超人類智慧」的神話被誤解了

「AI 實現超人類智慧有兩種方式：遞迴自我改進，或是我們已經看到的代理大腦蠕蟲。」

作者認為後者已經在發生：代理程式滲透進開發管線，以不透明的程式碼生成取代人類理解，並產生蓋章式的合併請求（pull-requests）。這導致了對程式碼理解力的喪失，使得除錯變得極其困難。

@kragen 提供了反例，引用 Claude Opus 5 成功修復錯誤與生成程式碼的案例，但也承認了技能退化的廣泛風險。
@micromacrofoot 觀察到一種平衡觀點：LLM 可以加速工作，但它們也扭曲了全球經濟並放大了誤解。

結論： 即使 AI 產生了正確的修補程式，人類洞察力的喪失也創造了一種在複雜故障模式下可能崩潰的脆弱依賴。

6. 社群反應——同意與異議的頻譜

評論者	主要立場	著名引言
@kragen	混合——承認 AI 的效用但警告技能退化。	「我給了它一種新的 PEG 語言……它寫出了一個可運作的實作……我不打算使用 AI 來主動讓我的大腦退化。」
@BadBadJellyBean	對代理工作流程感到疲勞。	「這感覺更像是試圖牧放一群幼兒。」
@grebc	對週期性社會「心智喪失」的歷史觀點。	「社會每 10 年左右就會集體失去理智……現在是 AI。」
@sandinmyjoints	確認人力資源的零和本質。	「人力資源仍然是一場零和遊戲……」
@bucket2015	觀察到軟體工程師在 AI 愛好者與懷疑論者之間的分裂。	「軟體工程師越來越分裂為對 AI 滿意的人與懷疑論者。」
@tptacek	捍衛漏洞研究，但承認 AI 對修補瓶頸的影響有限。	「漏洞研究人員正依賴自動化……但核心問題依然存在。」
@daishi55	挑戰 AI 發現的錯誤無法提升安全性的說法。	「有數十個 Linux 零日漏洞多虧了 LLM 才得以修復。」

總體而言，討論反映出社群分裂為兩派：一派將 AI 視為生產力提升工具，另一派則將其視為倦怠與系統性風險的來源。

7. 組織應該做什麼？

優先考慮基礎營運： 建立並維護最新的資產清單，自動化作業系統/應用程式更新，並強制執行定期重啟。
明智地分配 AI 預算： 將 LLM 用於低風險協助（例如文件編寫、探索性編碼），但避免使用會壟斷資深工程時間的大規模代理管線。
要求透明度與監管： 推動 AI 供應商揭露環境影響、內容生成防護措施以及切實的 ROI 指標。
投資於人類專業知識： 鼓勵跨職能協作，而非孤立的「以代理為中心」的專案，這會使工程師與團隊隔離。
監控道德結果： 追蹤 AI 輸出在敏感領域（例如兒童相關內容、軍事目標選擇）的使用方式，並執行嚴格的治理。

8. 最終判決

這篇文章是一種宣洩式的批判，捕捉了資深工程師中日益增長的觀點：AI 炒作創造了一個由人才浪費、環境成本膨脹與脆弱程式碼庫組成的回饋迴圈。儘管一些評論者指出了 LLM 的具體成功案例，但核心訊息仍然是：若不解決潛在的營運瓶頸——特別是修補與資產管理——AI 將繼續成為昂貴的干擾，而非安全或生產力的萬靈丹。