苗栗有個做工業模具的老闆，去年十二月十一號晚上，傳了一段語音給我。

他說：「老師我用 Codex 寫了一個自動報價的程式，跑起來沒問題，客戶選完規格會自動算出單價，但是裡面的程式碼我一行都看不懂。這樣算我真的學會了嗎？」

我當時剛洗完澡，坐在沙發上聽完，停了一下。

不是因為問題很難，而是這個問題裡藏著一個假設，這個假設本身才是值得拆開來看的東西。

---

「看不懂程式碼」跟「沒有學會」，是兩件事。

我問他：你知道這個程式做什麼嗎？

他說知道，幫客戶選完模具規格之後，自動算報價，然後存到試算表。

我問：你知道它算對了嗎？

他說有拿五個實際案子去核對，都吻合。

我問：你知道它在什麼情況下會壞掉嗎？

他想了一下說，目前還不知道。

好。那我們就知道問題在哪了。不是「看不懂程式碼」，是「還不知道邊界條件在哪裡」。這是不一樣的問題。

---

我教 Codex 教了大概兩年，陪過的老闆少說也有六七十位，從北到南各種產業。每次討論到「看不懂程式碼怎麼辦」，這個問題通常都包著焦慮：萬一出問題怎麼辦？萬一 Codex 寫錯了怎麼辦？我不懂程式，我要怎麼知道它寫對了？

這焦慮是真實的，我不想給什麼輕飄飄的安慰。

但焦慮的對象找錯了。

問題不是「你看不看得懂那兩百行 TypeScript」，問題是「你知不知道這個程式應該做什麼，然後你有沒有辦法驗證它做到了」。

你真正需要懂的三件事

第一件：商業邏輯。

Codex 可以幫你把邏輯轉成程式碼，但它沒辦法幫你想清楚你的商業邏輯。報價公式是你自己的，折扣規則是你自己的，哪些客戶走哪一條計算路徑，這些都要你先說清楚，Codex 才能寫。這部分你要懂，而且你本來就應該懂，因為這是你的生意。

第二件：驗證方法。

程式跑起來不等於程式寫對了。你需要知道怎麼測試它。不是什麼「單元測試」「整合測試」這些工程師語言，就是：拿你過去的真實案子去跑，看結果對不對。苗栗那個老闆拿了五個案子去核對，這個動作就對了。他其實已經在做了，只是他不知道這就叫「驗證」。

第三件：壞掉的時候你能做什麼。

這才是最關鍵的問題。程式不可能永遠不出問題，當它在客戶面前壞掉的時候，你要能說「讓我把問題描述清楚，我去問 Codex 怎麼修」，而不是「我完全不知道發生了什麼，只能等工程師」。

這三件事，一個字都不涉及「看懂程式碼」。

---

我學易經學了很多年，有一件事是我很晚才真正理解的：解卦需要懂的，是你問的問題，不是筮法的數學。

用蓍草起卦，有一套很複雜的計算過程，奇偶分組、換算爻變，涉及到組合數學的概念。但是我認識的易經老師裡，沒有一個是因為先弄懂那個數學才開始會解卦的。他們懂的是：這個問題的結構是什麼？這個人在問什麼？這個卦說的方向跟問題的情境怎麼搭？

Codex 寫程式也是一樣的道理。

你要懂的是：這個程式要解決什麼問題？解決了沒有？解決得夠好嗎？

「能不能看懂每一行程式碼」這件事，跟「有沒有學會用 Codex」沒有直接關係。

---

當然我也不是說程式碼完全不用看。

有些情況你還是得知道大概在看什麼：當 Codex 生出一段你覺得好像方向不對的程式，你要能描述哪裡不對；當程式出錯拋出了一個錯誤訊息，你要能把那個訊息貼給 Codex 說「我遇到這個，怎麼回事」；當你要改一個功能，你要能告訴 Codex 「這個地方，我想要它做的是...」。

這些不是「看懂程式碼」，這是「能夠跟 Codex 溝通」。是不同的能力。

一個是考試，一個是對話。

---

去年年底，那個苗栗老闆確認報價程式可以正確運作之後，下一步是讓業務員試用。業務員回報說有兩個規格選項算出來跟手動計算不一樣。他把那兩個案例傳給我，我們一起把問題描述清楚，貼給 Codex，Codex 修了之後再跑一次，解決了。

整個過程他沒有看懂任何一行程式碼。

但他知道問題在哪，他知道怎麼描述，他知道修完之後怎麼確認對了。

這叫學會了。

---

我有時候覺得「學會 Codex」這個說法本身有點誤導。它讓人以為存在一個學會的終點，然後你就可以像工程師一樣讀程式碼。其實不是這樣的。你要達到的狀態是：你可以用 Codex 把你的工作做得更好，你在需要的時候知道怎麼跟它溝通，它壞的時候你不會完全束手無策。

把標準改成「能看懂每一行程式碼」，是把工程師的要求套在非工程師身上。不是很公平。