當 AI 寫下更多程式碼，我們為什麼仍需要理解它

我用 AI 做了一個幫助人們理解程式碼的產品。

但一件有趣的事發生了：產品越來越複雜，我自己卻越來越不理解它。

我大約在 2025 年 7 月開始開發 FiboCode。當時 Vibe Coding 正在興起，所有人都在談論如何用 AI 幫助人們寫程式碼、降低軟體開發成本。一個想法自然而然地出現了：

如果 AI 能幫助人們寫程式碼，它是否也能幫助人們理解程式碼？

寫程式碼的成本不斷下降，但理解陌生專案仍然很痛苦。尤其面對存在多年、擁有複雜目錄結構、模組依賴、歷史設計決策與各種規範的程式碼庫時，往往光是找到起點就要花很長時間。

FiboCode 從這個簡單想法開始：用 AI 分析程式碼，產生對應的文件與關係圖，並讓人能在程式碼、文件與圖表之間跳轉。

那時，它只是一個程式碼分析工具。

後來，為了更容易針對程式碼提問，我加入了一個簡單的 Agent。為了改善閱讀體驗，我整合了 Monaco Editor。有了編輯器，程式碼導覽、符號引用與語言診斷似乎也變得必要，於是又加入了 LSP 支援。

既然支援閱讀，下一步自然就是編輯。

FiboCode 能修改程式碼後，我開始思考如何讓 Agent 真正理解專案，而不是只根據目前開啟的幾個檔案判斷。我逐步加入 MCP 與 Skills，希望 AI 也能取得專案的設計規範、架構背景與歷史。

之後我意識到，許多開發者早已習慣 Claude、Codex 等 Agent CLI。他們未必需要另一個內建 Agent，更需要的也許是一個專為審查 Agent 工作成果而設計的介面。

因此 FiboCode 加入終端機，並針對 Agent CLI 輸出做了特別改善，讓終端機中的檔案引用、程式碼變更與執行步驟可以連接到程式碼、文件與關係圖。

就這樣，一個簡單的程式碼分析模組，一點一點成長為日益複雜的系統。

我開始忘記自己做過的專案

AI 輔助程式設計確實很方便。

早期模型雖然沒有今天這麼強，我仍會仔細審查它們產生的程式碼，通常不只一次。我會看模組如何劃分、資料如何流動，以及架構為什麼如此設計。

開發期間，專案經歷了許多次重構。有些規模很大，但因為當時我熟悉設計細節，最終都沒有破壞專案。

接著模型變得更強，程式碼產生速度提高，程式碼庫也開始快速增長。

我逐漸發現，自己已經記不住一兩週前才審查過的程式碼設計細節。

起初，這讓我有些害怕。

這是我自己的專案。每項功能都來自我，但我已經無法記住每個模組為何如此設計，也無法記住每段邏輯如何運作。

時間久了，我意識到這或許只是必須接受的事。

它已不再是最初的小專案。在足夠複雜的系統裡，沒有人能記住所有實作細節。真正重要的，也許不是把每行程式碼放在腦中，而是知道系統核心在哪裡、模組如何協作、哪些部分可以安全交給 AI、哪些部分必須仔細理解。

我需要學會選擇。

我必須從大量程式碼中找出關鍵路徑，建立系統的大致心智圖，再給 AI 更精確的需求與限制。

從這個角度看，FiboCode 也在幫助我打造 FiboCode。

我用 AI 開發產品，產品越來越有用，反過來又幫助我更快理解與迭代它自己。這種正向循環令人振奮，也是我長期持續投入的重要原因。

但在興奮之外，我常常問自己：

在這個開發過程裡，還有什麼留給我？

當我把越來越多思考交給 AI

很長一段時間裡，我逐漸養成了一個習慣。

有需求時，先交給 AI。

有問題時，先讓 AI 調查。

它提出解法後，我負責驗證；驗證失敗，就把結果傳回去，請它再次分析並修正。

有時整整一天，我都在反覆向 AI 描述需求、解釋錯誤現況，再把測試結果回傳給它。

看起來，幾乎所有困難的思考工作都由 AI 完成，而我的角色只剩下定義需求與回傳結果。

那段時間，我真的有一種強烈感受：

好像自己已經沒有太多價值。

但繼續做下去後，我發現並不是這樣。

與 AI 一起開發時，我接觸到許多過去不會主動學習的技術，也看見各種實作方式。我開始刻意先看設計與架構，再看具體實作。

對某些任務，我能很快判斷範圍很小，可以直接交給 AI 完成。

但當任務跨越多個模組或影響專案核心結構時，我會立刻知道事情沒那麼簡單。AI 可能只看見目前需求，不理解某個歷史設計存在的原因，也不知道變更會間接影響哪些區域。

也有些程式碼，即使 AI 能寫，我仍需要幾乎完全理解，因為一旦出錯，後果可能難以控制。

我不再堅持理解所有實作細節，卻對系統的邊界、依賴、風險與變更更加敏感。

也許人的工作沒有消失，只是在改變。

過去，我們透過親手實作程式碼來理解系統。

未來，我們或許會把較少精力放在重複實作上，把更多注意力放到架構、流程、限制、驗證與長期演進。

AI 能寫，不代表我們能信任

我不知道未來 AI 是否真的能取代人類專家，完成所有程式設計工作。

這當然是技術問題，但我認為也是信任問題。

即使有一天 AI 能獨立產生高度複雜的系統，也不表示我們願意毫無保留地信任它。

當系統出現意外行為時，我們知道原因嗎？

我們能定位錯誤嗎？

我們能驗證修正嗎？

其他人能接手嗎？

如果系統造成嚴重傷害，誰該負責？

這些問題無法只靠把模型準確率從 99% 提高到 99.9% 就完全解決。

對低風險且容易替換的應用，我們當然能容忍更多黑箱。只要功能可用、開發夠快，也許不必在意每個實作細節。

但對作業系統、資料庫等基礎軟體，或金融、電力等對社會影響重大的系統，很難接受一個無法理解、稽核或接手的黑箱。

這些系統仍需要人來維護。

那些人不一定要親手寫每一行，但必須有人大致知道系統如何運作、關鍵風險在哪裡，以及出問題時從哪裡開始調查。

因此我越來越相信，程式碼理解不會隨著 AI 程式設計興起而消失。

它只會換一種形式。

過去，我們為了寫程式碼而理解程式碼。

未來，我們也許要為了驗證、維護、接手並持續演進 AI 建立的系統而理解程式碼。

正在消失的入門工作

程式碼理解還有另一層意義。

AI 正在減少一些以重複實作與基礎任務為主的入門職位。即使職位本身沒有消失，過去交給新人的許多工作也正先被 AI 自動化。

這對新人並不友善。

工程師傳統的成長路徑通常從簡單任務開始：修一個 bug、讀一小段程式碼、完成一個小功能，再逐步參與更複雜的模組與系統設計。

新人正是透過這些看似不重要的任務，一點一點建立對真實專案的理解。

但現在，AI 可能直接完成這些基礎任務。

當培養新人的入口越來越少，未來的資深工程師要從哪裡來？

這也是我建立 FiboCode 的另一個原因。

我在這個職業裡也是新人。第一次面對複雜的舊程式碼庫時，我常常完全不知所措。

檔案和目錄太多，服務互相呼叫，型別、介面與設定散落各處。你知道答案一定在程式碼某處，卻不知道從哪裡開始、哪些部分重要、哪些只是實作細節。

真正的困難通常不是理解某一行程式碼，而是缺少一張完整地圖。

我一直想要一個工具，能先分析整個專案結構，告訴我核心模組在哪裡、程式碼如何連接，以及某個變更可能影響哪些區域。

這樣新人就不必完全依賴別人一步步帶領，也不必一再在陌生程式碼庫中摸索。

這樣的工具不能取代成長過程，但能降低進入複雜系統的門檻。

當 AI 逐漸切斷舊的成長路徑時，我希望 FiboCode 能重新接上一條路。

它不一定是跳過所有基礎的捷徑，而更像地圖、導航系統，以及幫助新人更快建立系統心智模型的一條路。

程式碼只記錄現在

開發過程中，我還發現另一個問題。

直接把任務交給 AI，讓它自行探索儲存庫，有時會導致思考不完整。

AI 能看見目前的程式碼，卻未必知道某個模組為何如此設計，也可能不知道程式碼與看似無關的其他檔案有間接連結。

程式碼通常能告訴我們系統現在長什麼樣子，卻很難解釋它為什麼變成這樣。

一開始，我考慮把所有資訊都放進程式碼註解。

後來，我認為這並不合適。

大量設計背景、歷史推理與變更說明會讓程式碼檔越來越臃腫，也可能讓 AI 取得許多與目前任務無關的上下文。註解適合解釋局部邏輯，卻不容易承載專案的完整演進。

因此我設計了一系列 Fibo Skills。

它們記錄專案規範、設計、實作過程與 diff 說明，為每次程式碼變更留下更完整的軌跡。

我希望未來 AI 修改程式碼時，不只看見專案現況，也能理解過去發生了什麼，以及某些設計為何被保留。

當專案演進歷史可以追溯，AI 就能更完整地理解專案。

這也成為 FiboCode 逐漸發展的一個方向：

它最初是為了幫助人理解程式碼，後來也開始幫助 AI 更好地理解程式碼。

FiboCode 如何成長為今天的樣子

回頭看，FiboCode 並不是從一開始就被設計成今天的樣子。

它從簡單的程式碼分析模組開始，後來加入文件與關係圖、Agent、編輯器與語言服務，再逐漸擁有程式碼編輯、終端機、MCP 與 Skills。

我希望它能給 Agent CLI 類似 Cursor 的程式碼審查體驗，同時把程式碼分析產生的文件與關係資訊變成 AI 真正能使用的上下文。

它從簡單模組演變成複雜系統，這個持續成長的過程，悄悄呼應了 Fibonacci 數列擴展的方式。

FiboCode 的名字與蝸牛圖像，也由此而來。

蝸牛殼承載著黃金螺旋的數學之美。

它移動得不快，卻持續向前成長。

FiboCode 並不是要讓人重新親手寫每一行程式碼，也不是要把 AI 拒於門外。

恰恰相反。它接受 AI 將寫下越來越多程式碼，並在這個前提下，希望幫助人們繼續理解、驗證、維護與接手自己的系統。

在每個人都追求更快生成的時代，我仍希望我們偶爾能慢下來。

去理解程式碼為什麼這樣執行，也理解系統為什麼成為今天的樣子。

並重新找回最初吸引我們走進程式設計的樂趣。