在 LLM 時代學習程式設計 —— 來自資深開發者與 Hacker News 討論的見解

TL;DR

  • 核心程式設計基礎（資料結構、語言語意、系統抽象化）依然重要；它們能讓你驗證並引導 LLM 的輸出。
  • LLM 可以大幅加快原型開發速度，但也會造成知識缺口，在需要維護或除錯時會變得非常棘手。
  • 有效的學習方式現在結合了傳統的實作練習與針對性的 AI 輔助，將模型視為一種「可驗證」的工具，而非建議來源。

1. 為什麼基礎依然重要

結論： 理解你當前抽象層「之下」的那一層，是防止隱藏錯誤的最佳保障。

原部落格作者 Seemann 強調了一條軟體工程的長期準則：「理解你工作層級之下以及之上的抽象層。」這條準則讓你能在不依賴 LLM 解釋失敗原因的情況下，解決大多數問題。作者自身的職涯——從 1999 年使用 C++ 的 COM 元件開始，到後來編寫 RISC-V 編譯器——證明了深厚的知識能讓開發者適應完全陌生的環境。

"即使我被指派維護一個完全用 RISC-V 組合語言編寫的應用程式，我過去的經驗也能讓我比完全沒有程式設計背景的人更快上手。" – Mark Seemann

2. AI 是否讓人們建構的速度快過學習的速度？

結論： AI 可以加速「建構」但無法加速「理解」；速度差距可能會擴大。

Seemann 和幾位 HN 評論者都同意 LLM 能實現快速的 MVP 開發。japhyr 指出：「如果你能相當好地引導 LLM，你可以快速建構出一個遠超你自身實作理解能力的 MVP。」然而，同樣的速度可能會掩蓋日益擴大的能力差距。當系統運作正常時，差距是隱形的；當系統崩潰時，開發者被迫在過程中邊做邊學。

"我用 AI 建構了一個東西，但我並不理解它。我想進行修改和修復，卻完全沒有能力推論為什麼它會失敗，或者該如何修復它。" – agentultra (HN)

3. 選擇何時使用 LLM 與何時手動解決問題

結論： 將 LLM 用於「可證偽」的問題（例如編譯或執行的程式碼），並親自解決「開放式」的學習問題。

Seemann 區分了可驗證的提示（「我能讓這段 Haskell 表達式更簡潔嗎？」）與推測性的提示（「我接下來該學什麼？」）。他建議僅在答案可以直接在程式碼中檢查時才詢問 LLM。這反映了更廣泛的社群觀點：將模型視為一個在已知資料結構和演算法上運作的編譯器。

"將 AI 視為一個在資料結構、演算法和架構需求上運作的編譯器，而不是原始程式碼。" – aethertap (HN)

4. LLM 豐富環境下的實用學習策略

結論： 將專案導向學習與對底層概念的刻意深入研究相結合。

  • 專案優先，好奇心驅動： dack 建議在 LLM 的幫助下建構真實系統，然後審視生成的程式碼以填補知識缺口。
  • 手工打造的副專案： aethertap 建議在沒有 AI 的情況下維護一個「手工」專案，以保留底層技能。
  • 蘇格拉底式提示： rgbrgb 描述了利用模型詢問新技術「為什麼」會這樣運作，迫使學習者追蹤其推理過程。
  • 迭代抽象化： corti 指出 AI 可以幫助將子常式收斂為可讀的層級，但開發者仍必須定義清晰的抽象化。

5. 過度依賴 LLM 的風險

結論： 過度依賴會侵蝕專業知識並增加技術債。

  • 技能退化： duendefm 警告說，持續的 AI 查詢會使專家和初學者隨著時間推移而變得能力不足。
  • 不透明的程式碼庫： bborud 講述了一個團隊在 Claude 生成部署後無法修改程式碼的案例，因為沒有人理解其輸出。
  • 經濟不確定性： Seemann 提出了關於知識工作者大規模失業的宏觀層面擔憂，並將其與歷史上的技術顛覆進行了比較。

6. 傳統學習材料的角色

結論： 書籍和文件對於深層概念仍然很有價值，即使它們的使用頻率降低了。

Seemann 承認他早期的學習大多來自範例和文件，而書籍對於 F# 和 Haskell 等語言發揮了關鍵作用。雖然 LLM 可以立即呈現相關片段，但它們無法取代類型理論、編譯器設計或作業系統內部原理等概念所需的紀律性學習。

"瓶頸不在於老師或材料，而在於人類大腦吸收新知識的速度。" – ferguess_k (HN)

7. 給今日新學習者的建議

結論： 專注於基礎，將 AI 視為「工具」，並維持一條平行的「手動」學習軌道。

  • 學習核心概念： 資料結構、演算法、網路、作業系統基礎和除錯技術。
  • 建構真實專案： 使用 LLM 進行架構搭建，然後逐行深入研究生成的程式碼。
  • 提出可驗證的問題： 將提示限制在你可以測試的事物上（例如：這個函式能編譯嗎？）。
  • 維護一個非 AI 的副專案： 確保你保留從零開始編寫程式碼的能力。
  • 記錄假設： 像 aethertap 一樣，在向模型尋求解決方案之前，先寫下潛在的原因。

關鍵要點

  1. 基礎是不可妥協的 —— 它們讓你能夠驗證並指導 AI 的輸出。
  2. AI 加速了原型開發，但擴大了學習差距 —— 規劃刻意的深入研究課程。
  3. 將 LLM 視為可驗證查詢的「編譯器」 —— 避免詢問開放式、不可測試的問題。
  4. 將專案導向工作與紀律性學習相結合 —— 現實世界的程式碼加上專注的閱讀能產生最佳結果。
  5. 提防技能侵蝕 —— 維持手工實作練習以保持核心能力敏銳。

本文綜合了 Mark Seemann 的原始部落格文章以及 Hacker News 討論中獲得最多票數的評論（2026 年 9 月）。所有引述均為逐字引用並歸屬於原始評論者。

Sources

相關