我已經能沿著系統思考，卻還不能沿著程式碼追問題

上一篇寫到，我現在有些工程概念，已經不只是聽得懂。

新的需求出現時，我會主動拿它們來判斷風險、責任和影響範圍。

但這又帶出另一個問題：

我現在理解的，到底是系統怎麼組成，還是程式本身怎麼寫？

目前我比較確定，主要是前者。

我現在腦中已經有一張系統地圖

這個委託專案有前端、後端、文件處理服務和資料庫。

對我來說，它們現在已經不只是幾個技術名稱。

我大致知道：

前端負責使用者操作。

後端負責案件流程、權限和主要業務規則。

文件處理服務負責 Excel、Word、PDF、OCR 等工作。

資料最後會被保存到資料庫。

我也可以自己大致畫出一個功能怎麼在這些部分之間流動。

例如使用者上傳一份 PDF。

資料會先從前端送到後端。

後端先處理權限、案件狀態和其他規則。

如果需要解析文件，再呼叫文件處理服務。

處理結果最後再一路回到前端。

這種理解會直接影響我怎麼看問題。

我已經可以先把問題拆到不同系統部分

假設今天使用者上傳 PDF 之後，畫面顯示處理失敗。

我不一定知道真正的 bug 在哪裡，但我會先想到幾個可能方向。

可能是前端送資料出了問題。

可能是後端沒有正確往下處理。

也可能是文件處理服務失敗。

還有可能每一部分單獨看都正常，問題卻出在彼此交換資料的地方。

我可以先沿著這張系統地圖，把「功能壞了」拆成幾個可能的系統區域。

這和 Day 1 很不一樣。

當時結果不對，我幾乎只知道：

「它壞了。」

現在至少可以先問：

它可能壞在哪一層？

新的需求出現時也是一樣。

我會想到：

這次修改可能碰到哪些部分？

哪些責任需要一起維持？

前後端交換的資料會不會改？

是不是還牽涉另一個服務？

這些判斷不需要我先熟悉底下每一段程式碼。

它們來自我對整套系統責任和資料流的理解。

但這張地圖一進到程式碼裡，就會斷掉

這也是我目前最明顯的能力邊界。

我不是完全看不懂程式碼。

如果 Codex 已經指出一小段直接的條件判斷、function 或資料轉換，我通常可以大致理解它現在在做什麼。

但只要要從一個功能一路往下追，我很快就會失去方向。

還是以前面的 PDF 上傳為例。

我知道它大致會經過：

前端 → 後端 → 文件處理服務。

但如果現在真的打開後端 repo，要我自己找到 request 從哪裡進來、經過哪些 module 或 service、在哪裡呼叫文件處理服務，我目前追不下去。

我不知道應該從哪一個檔案開始。

也不知道 framework 裡這一層接下來通常會連到哪裡。

更沒有辦法單靠閱讀現有程式，把一個完整功能的實作路徑拼回來。

所以我現在可以沿著系統看問題。

但還不能沿著程式碼看問題。

看得懂一小段程式，不等於看得懂一個功能怎麼被做出來

這個差別以前我沒有特別分開。

因為單獨看到一小段熟悉的 JavaScript 或 TypeScript，我可能會覺得：

「這個我大概看得懂。」

但現在一個使用者看到的操作，背後可能跨過：

• 前端
• 後端
• 資料庫
• 另一個服務

所以就算看得懂其中一個 function，也不代表知道整個功能最後怎麼成立。

「我看得懂這十幾行在做什麼」，和「我知道這個功能是怎麼被整套程式一起做出來」，中間還有很大的距離。

我現在缺少的，不只是更多語法。

更大的缺口是：

我還沒有形成一種可以沿著 codebase 追出完整實作路徑的能力。

這讓 Day 1 的「改不動」多了一層新的比較

Day 1 時，整套網站對我來說幾乎都是黑盒。

我不知道有哪些主要部分。

也不知道一個問題可能落在哪裡。

現在底下的程式實作對我仍然很大程度是黑盒。

但黑盒外面，已經多了一張系統地圖。

我知道：

有哪些主要部分。

各自負責什麼。

資料和工作大致怎麼流動。

某些責任為什麼不能只放在其中一層。

新的需求可能影響哪些地方。

所以 Day 1 到現在的差別，不是：

以前不會改程式，現在會了。

而更接近：

以前既不知道程式怎麼寫，也看不見系統怎麼組；現在我還不能沿著程式碼理解完整實作，但已經能沿著系統理解它為什麼這樣組成。

目前我能確定的是：

我已經有一部分系統層級的理解，但程式層級的理解還很薄。

而這就留下下一個很直接的問題。

如果我還不能自己沿著程式碼確認完整實作，那 Codex 說「做完了」之後：

我到底憑什麼相信它真的做對了？