四十八個德瑞克

在 LLM 的世界裡，如何繼續享受程式設計——Haskell 論壇長文翻譯與 HN 討論整理

derekhsu
冷色調自動化工廠中，一角暖光小房間裡獨自手寫筆記的程式員插畫

原文翻譯：《在 LLM 的世界裡，如何繼續享受程式設計》

Haskell 論壇一篇長文的完整翻譯，後附論壇回應與 Hacker News 討論整理。

以下先全文翻譯原文，再整理論壇 12 則回應與 HN 的討論主軸。

一、原文全文翻譯

你正在走向 AI 倦怠嗎？怕自己的工作被一個程式能力平平、毫無品質執念、但手握鉅額 Claude 帳戶的人搶走嗎？對專案的程式碼品質失望，或者更糟——對「自己寫的」程式碼失望？這篇文章就是寫給你的。

關於大型科技公司營運的前沿 LLM（frontier LLM），確實有重大且正當的倫理疑慮，那些已經討論過很多，我知情也同意，但這篇不是要談那些。請別把我誤認成捧 LLM 的科技小子。

還有一件事：以前有人把我的文章誤當成 LLM 生成的，所以先聲明，這篇是百分之百人工撰寫，沒有任何 AI 協助。

偉大機器中的靈魂

Sean McMullen（尚克麥默倫）有本我很喜歡的小說就叫這個書名，年輕時讀過。乍看之下，它描述的正是我們處境的反面：一台大電腦，組成零件是人類，協同運作構成計算單元。而 LLM 本身跑在真實的電腦上，卻假裝自己是（超）人類。再看一眼，故事與現實其實沒那麼遠：我們在軟體生產過程中的角色，正慢慢從參與者貶為機器裡的齒輪。規格驅動的反烏托邦是：我們只會被丟下一份規格，把它敲進 LLM 裡，然後在 token 用光時哭泣——因為某位科技封建領主決定少發一點 token。

身為 Haskell 程式員，我享受寫 Haskell。沒錯，我很喜歡公司在做的產品，也很喜歡我的開源函式庫能做到什麼。但我真心享受的，是用這門語言表達想法的過程本身。我假設你們大多數人也是如此，而且這在很多其他語言裡未必成立——這也部分解釋了為什麼不同語言的愛好者，對 LLM 輔助的未來是光明還是黑暗有不同看法。

當我讓程式碼被生成時，那種享受有很大一部分會冒險。所以，也許就別生成吧。我想繼續寫 Haskell 程式（至少享受其中有趣的部分），而不需要讀和審（太多）生成出來的程式碼。與此同時，我想把那些 token 用在不會慢慢燒壞我腦袋的用途上。

我想告訴你一個方法：既能繼續享受寫程式，又能藉由 LLM 適度提高產出——而不是表面上產出暴增、卻失去所有樂趣。

如果你就想完全不碰 LLM，那也很好，你本來就知道自己在幹嘛。但你可能有不想這麼做的理由，例如你得拿出實質的生產力成長，或者你不想眼睜睜看著團隊、公司、整個產業都在用 LLM 而被拋在後頭。

繼續寫程式

想繼續掌握你的程式碼庫，就必須繼續寫一部分程式。如果全部讓它生成，程式碼庫會變成 LLM 荒原，只有你的 coding agent 才能在其上生存。所以你該繼續寫，否則你的程式碼庫終將失守。

繼續寫程式的另一個理由，是持續當一個好程式員。技能會因不練習而流失，而這裡風險特別高，因為把 coding 工作交給 agent 的門檻低到不行。只要幾週不寫程式、凡事交給 agent，你就會發現很難回到自己寫。

LLM 產出好的、人類可讀的程式碼的能力，遠比宣傳的糟糕。它們對「之後只有自己接手維護」的程式碼還算可以。但我相信你一定經歷過那種絕望：看著一個完全生成的檔案，裡面必定藏著某個 bug，而你身為人類卻找不到——因為整片地形陌生到不像人類世界。

那麼，如果不讓 agent 寫程式，要怎麼拿到那些生產力收益？讓它們去做幾乎其他所有事情。特別是那些讓你頭痛的無聊工作。理想上是那些不太難做對、又容易檢查的任務。

規劃

從電腦最早的歷史開始，它們一直被當作記帳工具。就這樣用 LLM。除此之外，它是一個你能用自然語言而非正式介面呼叫的記帳工具。把領域專家之間冗長的書面對談，轉成可執行的 todo。測試某樣東西，記下測試結果，讓它整理成修復缺陷的計畫。

用 todo 工具，或者更好，用帶 frontmatter 的 markdown 檔，讓它正確追蹤規劃項目。LLM 的 context 可以很大，但塞太滿時它會靜默丟失資訊。

但別讓它做任何關鍵決策。要讓它問你。如果你看不懂問題在哪，那是 LLM 沒給足相關 context 的錯（或者你太累了需要休息）。如果你反覆回到同樣的問題，就離開螢幕想一想，等你有清楚的圖景再回來。

做研究

把研究任務交給 agent 時，你會很想盯著它查詢和「思考」，或者開另一個專案的 agent，或者去泡咖啡。三者之中，泡咖啡是最好的選項。更好的選項是：你自己用老式搜尋引擎並行研究。至少要大致掌握 agent 將要知道的一切。

別讓它研究完就把結果當事實、然後照此規劃。那會造成尷尬的技術欠債（原文把 debt 誤寫成 dept，是作者故意玩的雙關）。

讓 agent 做研究的意義，不是讓它把相關知識端到你面前，也不是讓它做出比你更好的決策。意義在於你不必替它「幫你 Google 一下」。你對自己要建模的領域，理解程度該跟 agent 一樣好，理想上更好。

讓 agent 把研究結果連同引用來源寫下來。當它日後回來給你一個奇怪的提案，就問它研究怎麼說、哪個來源這樣說。一半機率它會發現自己的錯誤。另一半情況下你就去讀，那時你就有條件自己做好的決策。

你才是寫程式的人

這是關鍵轉折。

典型的 coding 工具誘導你「先規劃，然後讓 agent 寫」。拒絕。一起規劃，但程式你來寫。叫 LLM 研究你的程式碼庫，叫它告訴你目前的 todo、列出所有需要修改的地方、提示潛在陷阱、提醒你相關的背景研究。

我就是用這套流程工作，非常有趣。我享受我的工作，有時候比 LLM 出現之前還享受。我永遠有清楚的 todo，不用操心整體計畫，可以專注，而且因為計畫周全，很快就能完成 todo。這就像敏捷開發，但沒有那些惱人的流程。

讓 agent 圍繞你的工作方式轉，而不是反過來。也許你是經驗豐富的程式員，本來就知道自己怎麼工作最順。讓 agent 做你周遭所有你沒那麼喜歡的附帶工作。

這套流程有多個優點：

coding agent 少數有用的場合

理想上用於清理、小任務、例行工作、低風險重構。你在程式裡留了 FIXME（也許是故意的，為了省力氣）？你寫了 3 個有趣的案例、剩下 7 個相似但無聊的沒寫？你有個模組重組的想法想要基準測試？有個沒人維護的函式庫，想換成更好的？這些都是合理用途。從零設計複雜的東西大概不是。

有時候你沒時間了但想把事情做完，而計畫裡其餘 todo 是明顯的低風險任務。跟你的主管 agent 說「我離開一下，把它做完」沒問題，運氣好的話，隔早醒來就有完成的功能。但大部分 coding 工作親自做很重要。

這裡有些小陷阱：

審查循環

你還記得 AI 生成圖像因為生成對抗網路（GAN）突然變得真實很多嗎？簡言之，一個模型（生成器）產生圖像，另一個（鑑別器）告訴它表現如何。兩者合起來能產生遠比生成器單獨運作更好的結果。把這個想法（其廣義形式一點也不新）套用到 LLM 輔助 coding，就得到自動審查循環。

沒有自動審查循環，就不要接受、甚至不要閱讀任何 LLM 產出的東西。這當然直接適用於程式碼（在你仍然讓它生成的情況下），但特別也適用於規劃。當 agent 寫完東西，交付時工作還沒完成，工作完成（即可以給人類看），是審查 agent 挑不出毛病了。計畫也一樣。計畫裡常有邏輯漏洞：todo 2 要重構的函式，卻計畫在 todo 7 才撰寫。逐一抓出這些漏洞非常累人，所以加一個審查 agent 來做這件事。

我發現讓別人審查自己的程式碼出奇地有用。有時候它只挑些雞毛蒜皮，或者堅持把 Haddock 文件灌水，但常常真的找出 bug 或疏漏，並讓我把注意力拉回真正的 todo。我建議也為你自己的工作加上審查循環，但我完全理解你不想讀 LLM 對你程式碼的審查。一個變通辦法是叫它自己把剩下的小問題修掉。

前沿模型

「你完全沒有發揮前沿模型的能力。」——某個網路 vibe coder 說。

是的。這正是我論點的邏輯結果。

但依賴前沿模型的功能有多個壞處：

說到底，你做的是複雜的工作。在某些面向上，LLM 表現相同、甚至略好。但這遠遠不足以讓你對它們俯首，因為缺點太多。LLM 必須比人類開發者好上許多倍、用更少資源、在複雜現實情境中更可靠、對齊程度至少一樣好、並且以某種方式對其結果負責，才能在核心工作上取代人類開發者。

token 用光了？

也許你經歷過工作因為 token 耗盡而停擺。很煩人。你的工作流程圍繞著一個工具建立，而你突然無法再使用它。極端情況下，你什麼都做不下去。把這張 xkcd 想成「no tokens」而不是「compiling」，用健康的方式處理這種處境。

如果發生幾次，你可能覺得被背叛了。你是對的，你確實被背叛了。你在某個方案某次會話中能有多少 token，是個不透明的數字，隨某位科技封建領主的心情而變。它不像你在公平市場上買到、然後可預期使用的商品。

你必須停止把 token 耗盡理解成「買太少」，而要把它當成它真正的樣子：服務中斷。你的 LLM 公司賣給你一項承諾：可以用它的 LLM。而他們沒有兌現。你會話中的最大 token 數可能在你不知情、也無法影響的情況下改變，所以你根本沒辦法規劃。

當然，節省是必要的。重新檢視你的 agent 設定、使用量、context 大小、skills 等等來省 token。但即使如此，即使你買了更大的席位，可能還是不夠。

與其在你已經盡力節省後 token 耗盡時視為「自己的錯」，不如把它當成需要準備的技術故障。如果你在火車或飛機上工作過，你就知道必須隨時準備好沒有網路。事先下載和快取大型資源。永遠保留一些可以離線做的工作。

對 LLM 輔助的工作而言，這代表：凡是你需要動手的工作，都要讓它產出有形的產物。最重要的是，如果你採納我描述的人類 coding 流程，確保你永遠有一份可工作的 todo 清單。享受把它們衝完的樂趣，等 agent 回來，再叫它做清理。

LLM 胡言亂語

LLM 產出的文字，讀起來不像人寫的。當它其實不太知道自己在講什麼時，尤其糟糕。把 LLM 胡言亂語當作可能有害你心理健康的東西。別消費太多。繼續跟人談論你的程式碼，特別是宏觀願景和有趣的面向。只在自動審查 agent 潤飾過後才閱讀 LLM 產物。

當你頭昏腦脹，就休息。是的，即使背後沒有 agent 正在跑、正在「產出價值」。你的心理健康比工作產出更重要。

你的人類同伴

程式設計大體上是社會性的事業。例如在公司或開源專案裡，我們互相寄 pull request、寫 issue 和 commit 訊息。這是一種溝通。即使專案只有你一個人：過去的你，也在替未來的你寫 issue、commit 訊息和 PR。人與人溝通，才是軟體開發的支柱。

確保你永遠先以人的姿態遇見人。不要寄一個完全生成的 PR 給別人。我不小心做過一次，對方理所當然受夠了。我會確保不再重犯。

Agent 很樂意幫你寫完整的 PR 內文，文法正確、細節俱全。這不是溝通，這是工具輸出。把這種文字當成基準測試數字或 debug 追蹤一樣處理：附加在你手寫的 PR 內文後面，可以放在 details 摺疊區裡，讓人們自己決定要不要讀。你會發現他們多半不會。

我的旅程

有了這一切，我比沒有 LLM 協助時更有產出。很難精確估計，也許快兩倍？這比很多全職 vibe coder 誇耀的少，但沒關係。我把自己想像成一個採用溫和有機肥料的園丁，而 vibe coder 比較像把工業化學品倒滿田地。我相信我的方式目前更可持續。

我熱愛寫 Haskell，靠它謀生是我的夢想工作。上個月我還擔心這個夢想已成往事。但我上面寫的一切，都是我為了讓這件事保持樂趣所學到的。看來有效。

二、論壇回應（12 則）

作者 要點
enobayram 附議「LLM 胡言亂語有害心理健康」：想同時掌控程式碼又用 LLM，很容易養成一種習慣：讀山一樣多的廢文，「在生理層面上對大腦很糟，當天做很多就會立刻痛苦，而且效果會殘留」。希望未來有神經學研究佐證，「希望我們不是在讓大腦吸石棉」。
hasufell 期望業界能雇用不同 AI 使用模式的工程師並組隊協作。他寧可讓不用 AI 的人做 code review，但需要嚴肅的政策配套（例如禁止自動生成的 commit 訊息），否則會把他們耗竭。開源方面他認為正走向分裂，「我覺得這沒什麼不好」。
Ambrose 提到有人主張公司直接下令「禁止 LLM coding」是個好的篩選機制：事業本質穩固的話不會因此受傷，還能幫你篩出好工程師。
lortabac 認為混合團隊已經很普遍，他自己就在混合團隊且運作良好，個人也會在 agentic 與手動 coding 之間交替。
tomjaguarpaw 持相反感受：標題問「如何繼續享受」，他想的是「如果失去 LLM 我還怎麼享受」——因為他現在更容易把想法化為實現，雜活都被拿走了，只剩有趣的部分。另外質疑原文「被背叛」一詞太重：他用 OpenAI 月費方案，額度與時限清楚、在 Codex 打 /status 就看得到。
turion（原作者回應） 承認有點誇張，重點是：你把工作流程建立在某方案上，對方短期內改了 token 額度，流程就斷了。他不知道 Claude Code team seat 到底有幾個 token，只能假設那是隨意變動的數字。他提出「公平市場」的三條件：獨立開源工具能量 token 消耗、有像手機合約那樣保證數量與期限的方案、uptime 保證——他認為沒有任何 provider 做得到。
lortabac（再回） 推薦 DeepSeek API 加 dsh（DeepSeek 的命令列工具）：token 成本、用量、模型的全部行為（含推理過程）都一清二楚。
Kleidukos 反問：你用 LLM 做「套件維護」這類工作的體驗如何？
hasufell 代答：在原語和怪 API（如 Windows、PowerShell）領域體驗很差，LLM 不懂 PowerShell，會收斂到常見變通法而非最佳解，而且會拿走你對決策的健康不安感。LLM 給的那種表面信心，反而可能有負面後果。
Deep 分享技巧：先寫好模組與函式介面（不寫實作），再讓 AI 實作。比解釋想要的程式碼更快，也能讓自己看清隱藏關聯、找到更好的抽象；小模型也夠用，「我保住設計聰明抽象的樂趣」。
grasshopper 感謝作者聲明「百分之百人工撰寫」，希望大家以後主動標註文章有無 AI 協助，「讀 AI 生成文字的過程常常讓我非常疲憊」。

三、Hacker News 討論整理（272 分、300 則留言）

討論核心不是原文的做法，而是原文標題引出的大分裂。大致分幾條線。

1. 最大爭論：旅程派 vs 結果派

原文引發的最大火線是一句反問——「誰喜歡打程式碼、寫樣板、熬夜讀爛文件？」（poisonborz 留言，引發 54 則回覆）

2. 技能萎縮是最常見的焦慮

– 反方 pton_xd：「現在要人花 5 小時、5 天拿紙筆想事情是不可思議的」；vconnor：「難以想像 5 小時的深度思考被當成浪費」；daemin 甚至懷疑這是注意力障礙或 LLM 過度依賴造成。

– gramie 舉日本漢字例子：打字選字久了，手寫就提筆忘字，2012 年調查有 66% 日本人認為自己正在失去漢字書寫能力。

3. 「這跟我無關」：早就討厭 coding 的人反而更愛 LLM

4. 「你也可以不用 LLM」

5. 職業層面的實務觀察

6. 對原文具體論點的回應

原文論點 HN 反應
「你才是寫程式的人」（自己規劃、自己寫） 大量呼應：nmekala35「LLM 用來壓縮想法到可運作軟體的距離，但絕不外包對系統的理解」；cautiouscat「小模型加緊握韁繩，比大模型加 agent swarm 又快又準」；dylanhouli「先自己想解法再問 AI，看有沒有吻合」。也有 dawnerd「早期 Copilot 那種聰明 autocomplete 就是我想要的，後來變成直接填滿整個檔案」。
LLM 寫的程式碼品質遠差於宣傳 兩極：cdelsolar「都 2026 年底了，Opus 5.5 我丟什麼都能蓋出來」；pydry 反駁「AI 寫出好程式碼？很明顯沒有」；parineum「20 年歷史的 .NET 4.8 混合專有 SDK 的 codebase，LLM 直接噎住，全新專案倒是很行」；freecodeio：人們看到 Tailwind 漸層儀表板就以為所有 codebase 都那麼好搞。
token 耗盡是服務中斷，不是你買太少 多數人共鳴，但也有人認為額度其實透明；lortabac 以 DeepSeek 為反例。
agent 寫的 PR 不是溝通，是工具輸出 未引發大爭議，普遍同意附在手寫 PR 後面放摺疊區的做法。
LLM 胡言亂語傷心理健康 論壇上 enobayram 附議；HN 上 jan_m_savage 描述四年來的標準循環（給多了、道歉、複雜化、再道歉、token 用光、重開、還是要自己清理），結論「我手寫會更快，但肯定更快樂」。

7. 幾則被大量按讚的收尾式發言

結語：兩邊對照

論壇那篇走的是方法路線：有系統地保留主導權，自己寫、自己規劃、加審查循環，並把 token 斷供當故障演練。HN 則把焦點扯到「你到底愛不愛 coding 本身」的身分認同戰爭，怎麼做反而不是主戰場。原作者 turion 的立場在 HN 被夾在中間：vibe coder 譏他只會在自己的編輯器裡慢慢寫，純手工派又認為他不夠徹底。

Exit mobile version