本文同步刊載於個人連載網站
上一篇最後，我留下一個問題：
「我聽懂了」，到底代表什麼？
現在很多工程概念，都是我在跟 Codex 討論需求、設計或 Debug 的過程中理解的。
但能不能聽懂解釋，和下一次遇到新問題時，會不會自己拿這個概念來做判斷，對我來說是不同層次。
我現在更在意的是後者。
最近做 QA 測試帳號時，我很明顯感覺到這種差別。
原本的需求很簡單：
希望同一個 QA 帳號可以切換不同業務情境。
這樣測試不同資料和操作時，不需要一直準備不同帳號。
但我在討論實作以前，就已經會先想到幾個不能被破壞的條件。
QA 本身還是 QA，不能因為切換情境，就真的變成另一個正式使用者。
切換之後，工作台、案件列表和統計也要站在同一個情境裡，不能每個地方各自理解目前正在測什麼。
如果某一筆案件不屬於目前的業務範圍，也不能只是從列表上藏起來，直接輸入網址時仍然必須被擋住。
真正的權限限制，也不能只靠前端畫面維持。
這些不是 Codex 問一條，我才補一條。
而是我自己在看這個需求時，就已經會先想到：
這個功能會不會把原本的身分與權限邊界弄壞？
對我來說，這就是一個很明顯的變化。
以前「權限」是一個我知道大概意思的工程概念。
現在它開始變成我看到新需求時，會主動拿來檢查的條件。
系統分工也有類似的變化。
Day 17 寫過，最早做到文件處理時，是 AI 先提出另外拆一個 Python 服務，我才追問：
既然已經有後端，為什麼還要再拆？
當時我是在理解一個具體案例。
後來如果又出現一種和主要後端工作性質明顯不同的事情，我已經比較容易自己先想到：
這是不是另一種責任？
有沒有必要另外拆開？
拆出去之後，會增加哪些溝通、部署或維護成本？
我不一定會立刻知道答案。
但這個問題已經會自己出現。
原本只在「文件處理服務」這個案例裡理解的分工概念，開始能被我帶到其他情境。
這時候，我對一個概念的掌握就不只是：
我知道這是什麼。
而是：
我開始知道什麼時候應該拿它出來想。
這種變化也出現在 multi-repo。
一開始我只是知道，這個專案被拆成前端、後端、文件處理服務和 Coordination 等不同 repo。
後來真正理解這些部分各自負責什麼之後，新的需求出現時，我會開始自己想：
這次可能碰到哪些 repo？
前後端交換的資料格式會不會跟著改？
是不是還會牽涉文件處理服務？
如果只完成其中一邊，整個功能是不是還沒真的完成？
這時候，multi-repo 對我來說已經不只是「專案被分成好幾個 repo」。
而是一張我會拿來判斷修改影響範圍的系統地圖。
決策紀錄也是一個例子。
最開始，是 mentor 提醒我：
重要的工程決策不能只留下最後選了什麼，也要把「為什麼這樣決定」記下來。
這個觀念不是我自己發明的。
但真的拿進專案使用之後，我又看到另一個問題。
有一份決策文件，並不代表程式已經完成。
程式已經做了，也不代表目前已經有足夠的測試或驗收證據。
所以後來我自己又把：
分開管理。
這讓我更清楚感覺到：
一個觀念不是非得從零由我自己想出來，才會變成自己的判斷。
mentor 可以先提醒我。
AI 也可以先解釋一個原本不知道的工程概念。
但真的用進專案之後，如果我開始看見原本做法沒有處理到的新問題，並能自己決定接下來應該怎麼調整，那個觀念就不再只是我記住的一句話。
我現在理解的工程概念，掌握程度並不一樣。
資料存取層和 ORM 對我來說，就是很明顯的例子。
我知道，後端裡負責業務規則的程式，和真正去資料庫讀寫資料的程式，可以分開。
我也知道 ORM 可以幫忙處理很多資料庫操作，不需要每一件事情都直接自己寫 SQL。
如果 Codex 或工程師跟我解釋，我大致可以跟上，也知道它們想解決什麼問題。
但如果現在換一個新的專案，要我自己判斷：
什麼情況值得拆出資料存取層？
什麼情況適合使用 ORM？
哪些代價值得接受？
我還沒有穩定的判準。
所以這不是單純的「懂」或「不懂」。
更接近的是：
我知道它是什麼，也理解部分價值，但還沒有形成自己的適用條件。
對我來說，一個工程概念開始形成自己的判斷，不是因為我已經能背出完整定義。
也不一定代表我已經能不靠 AI 把底下的程式實作出來。
更接近的是：
下一個問題出現時，我會主動拿它來做決定。
我會想到：
這裡是不是有權限問題？
這是不是不同性質的責任？
這次修改會影響哪些系統部分？
原本的決策還適用嗎？
我不一定會立刻知道答案。
但至少我已經知道這裡有一個需要判斷的問題，而不是等 Codex 提醒之後才第一次看到它。
這些理解目前大多還停留在系統責任、權限、資料流、影響範圍和工程取捨這一層。
它們已經開始進入我理解系統的方式。
但這又留下下一個問題：
我現在形成的這些判斷，究竟是在理解系統怎麼組成，還是在理解程式本身怎麼寫？
iThome鐵人賽
看影片追技術