解法可能是取消 AI 訂閱

thoughts.hmmz.org · 2026-05-31

原文連結： the solution might be cancelling my AI subscription

摘要

• 作者回顧自己用 AI 做出的一長串工具與玩具專案，從 Rust 語音辨識、郵件封存工具、Jellyfin 桌面 clone，到新聞站、遊戲、投資回測器與 SaaS；但除了 SaaS，多數都沒有真正有用，也不值得維護。
• 問題不在 AI 不強，而是 AI 太容易把「寫個小腳本」推進成一小時後的完整半成品，原本的痛點常常沒有被解決，反而多了一個要照顧的東西。
• 作者把這種體驗稱為注意力災難：低摩擦、低投入、高回饋的工具會鼓勵人同時開很多無法維持的專案，讓工程師更像在追逐新奇感，而不是做真正有承諾的產品。
• 他批評多數 AI 產品的商業目標都是更多使用量、更多 tokens、更多輸出；但快速吐出未測試的大量程式碼，對個人與商業環境都可能是負債。
• 文章也把 AI 工具連到 Cal Newport 所說的「偽生產力」：工具讓單一任務更快，卻可能製造更多淺層工作、訊息、草稿與 context switching。
• 作者最後的判斷很尖銳：在還不知道如何健康管理 AI 使用前，最實際的做法可能是限制使用，甚至取消訂閱，因為沒有摩擦的工具也可能沒有焦點。

· · ·

我正在試著列出所有用 AI 做出來的美妙東西：

• 用 Rust 寫的語音辨識系統
• 郵件封存渲染與引用折疊工具
• 用 GStreamer 和 Qt Quick 做的 Jellyfin 桌面 clone
• 用 Python 與 yt-dlp 做的 Invidious clone
• 從 Wine 原始碼移植、用 FLTK 做的忠實 Windows 95 notepad.exe clone
• 用 OpenCV 從公共街景攝影機計算交通流量的機器視覺工具
• 一個 Claude UI clone，可能是 Python 或 Rust 寫的，已經記不得了
• 一個原本沒打算做、但真的有流量的地方新聞網站，Python / Flask
• 一個基於既有多人遊戲協定、用 three.js 做的 3D 汽車遊戲
• 用 Python 寫的投資回測器
• 一個 Lightroom UI 的 HTML clone，看著成果驚嘆，然後永遠沒做 backend
• 一個 Markdown viewer，可能是 Qt、GTK，或其他東西，已經記不得了
• 一個替代筆電桌面環境世界時鐘 widget 的 GTK / C 工具
• 一個 JavaScript 網路同步音訊播放工具
• 一個從 Android app 逆向出來的中國 IP 攝影機 Rust client
• 一個規模不小的 Rust SaaS
• 也許還有 50 個已經刪掉的其他專案

除了那個 SaaS，幾乎沒有任何東西真正有用，而且我也不想維護它們。結果我不小心經營了一個新聞媒體，這肯定是一種責任風險。當然，這些東西幫我「學會 AI tooling」，而且其中很多工具我也真的會用；但我其實不需要它們。我負擔不起維護這些東西，不管是時間、承諾、信念、注意力，或 token 花費上的負擔。

我原本並沒有打算做出大多數這些東西。通常 Claude session 一開始只是像「幫 X 寫個快速腳本」這樣的小要求；一小時後，結果既不是「幫 X 的快速腳本」，通常也沒有解決我一開始真正遇到的問題，不管那個 itch 原本是什麼。

注意力才是一切

就最後那點來說，這項技術對注意力非常可怕。

它是熱核級的 ADHD 放大器，而且我在每一位成年朋友身上都看過同樣效果。大家同時開著三個螢幕，跑著完全無關的「專案」；這些專案大多沒有希望被維護，當事人對成果的承諾也低到很明顯是在浪費時間。

最近，至少每個月都會有人傳來截圖，說他們正在做一個很棒的工具。我會想說，哇，這真的有點東西，傳來的人也顯然很驕傲、很興奮。我盡量不問，但心裡總是想著：那你要去哪裡行銷它？因為當這個問題問到工程師頭上時，答案從 LLM 出現以前到現在都沒有變。

我最近面試時，聊到 AI 使用情況，對方回答大概是：「喔，我們用得算輕量，每個人最多有 5 個房間管理自己的 agents。」我立刻覺得胃一緊。

使用 Claude 幾個月後，我已經隱約感覺到這種效果。後來我把訂閱降到 Pro，以為 quota 限制可以緩解過度使用。接著 Claude 經歷一段服務品質不佳的時期，我轉去用 Codex。Codex CLI 比 Claude 好用很多，也明顯更快。然後使用量又開始爬升。

這項技術在打磨得宜時，真的非常驚人。叫它 zero-shot 寫一個冷門語言裡的冷門 grammar parser，還要附完整測試，它就完成了。但今天這些工具存在的樣子，完全沒有促進那種審慎使用所需的專注。

幾乎每個供應商、每個工具的意圖都剛好相反：更多使用、更多 tokens、更多輸出。你問 ChatGPT 一個簡單的是非題，都能清楚看到它被硬塞了一個相關追問，目的就是促進過度互動。

5 分鐘吐出一坨 10,000 行、沒測試過的 Python / JavaScript 混亂程式碼，對任何人都沒有幫助。想到這件事正在每個商業環境同時發生，就令人害怕。

摩擦等於專注，專注等於產品

我早期的一個 AI 實驗，是把 AI 當成 Marshall McLuhan 式思考中的一種鏡頭：我把語音辨識接到一條 pipeline，另一端會產生 blog posts。我當時相信這會鼓勵自己捕捉想法。所有操作只需要在 Telegram 頻道按一下語音筆記按鈕，另一端就會吐出一篇 Opus 格式的文章。

輸出是完全不受控制的垃圾。因為努力被移除，承諾也一起被移除；承諾被移除，專注也跟著消失；專注消失後，任何有意義的產品也都不見了。高品質寫作不是把口語英文丟進一個濾鏡就會出現的東西：口語英文是低 bit rate 的噪音，高品質寫作則是在試圖用更成形的概念捕捉高 bit rate 的資訊。這件事本來在開始前就應該很明顯。

我也想過把這條 pipeline 改成捕捉私人筆記，但我不需要私人筆記。那會破壞「噪音自然被遺忘」的過程。它只是更多過度工具使用。

從這點延伸出去，只要品質還重要，手寫就永遠不可能過時。

感覺我們正在走向一場危機，而我懷疑答案不是「更好的模型」或「更好的工具」。Cal Newport 把這件事和偽生產力連在一起：

講者主張，數位生產力工具，包括 AI 和 email，常常製造一種「數位生產力悖論」：它們讓個別任務變得更快或更容易，卻可能讓知識工作者更忙、更分心，整體上更不生產。他引用研究指出，AI 使用者花更多時間在 email、messaging、chat 和 business-management tools 上，卻花更少時間在專注、不中斷的工作裡。他的核心主張是，為了降低摩擦而設計的工具，往往會增加淺層任務與 context switching 的總量，進而削弱 deep work 和高價值產出。

他解釋，這之所以會發生，是因為知識工作經常依賴「偽生產力」：把可見的忙碌當成真正價值的 proxy。數位工具會強化這點，因為它們讓人看起來更活躍：送出更多訊息、產出更多草稿、參加更多會議、生成更多工作 artifact。為了避免落入陷阱，他建議要衡量真正成果、找出工作中的真實瓶頸，並把 deep work 和 shallow work 分開，讓數位工具支援有意義的進展，而不是吃掉注意力。

– 機器人摘要

這些經驗讓我對所有工具使用有了新的感知，因為在這一切底下，問題並不是「更快開發等於更多 app」或「更快 email 等於更多溝通」是否值得追求。更一般地說，問題是一個人生命中的單位時間，以及它如何被有意義地使用。

我現在完全不知道該如何管理 AI，除了限制使用以外沒有答案；因為一個用最少輸入、沒有摩擦就能產生廉價回饋的工具，只可能成為負債。而意識到這件事，可能才是 AI 迄今唯一真正的貢獻。

· · ·

真正稀缺的是注意力

這篇文章的價值不在於反 AI，而是在提醒一個更難承認的問題：AI 把「做出東西」的邊際成本壓低後，真正的瓶頸會移到選題、承諾、維護與注意力。能快速生成一個工具，不等於那個工具值得存在；能快速完成一個版本，也不等於後續有人願意為它負責。

對開發者來說，這不是「要不要用 AI」的二元題，而是「在哪些環節保留摩擦」的設計題。規格拆解、測試、review、維護成本估算、使用者取得與關閉條件，可能都需要刻意慢下來。否則 AI 會讓人把每個小念頭都變成半個專案，再讓這些半成品回頭消耗注意力。

比較務實的做法，是把 AI 從「自動把任何想法變成產品」降級成「針對已承諾問題的加速器」。如果問題不值得手寫一段 spec、不值得定義成功條件、不值得安排維護方式，那它通常也不值得開 agent 跑一輪。這種摩擦不是落後，而是避免把人生變成無限 side project queue 的安全閘。