當寫程式變成「審代碼」：資深開發者的 AI 協作倖存指南

剛看完Youtube 上的影片 https://www.youtube.com/watch?v=v4F1gFy-hqg

也有一陣子沒在公司親手敲代碼、更多是在對AI下決策，我發現自己正在經歷一場角色轉變：我不再是那個在戰壕裡揮汗的步兵，我變成了審核代碼的「大腦」。但問題來了，當 AI 產出的垃圾代碼像雪球一樣越滾越大，三個月後，我還能認得這堆東西嗎？

針對這個困境，我實踐了五個軟體工程的核心對策，這是我從 Andrej Karpathy 的影片中提煉的心得。

1. 拒絕盲目信任，啟動「拷問模式」¶

很多人用 AI 是「我說，你做」。這太危險了。
我現在的作法是：我先不告訴你我要怎麼做，你先來拷問我。 在我腦中藍圖固化到連一個新進工程師都能聽懂前，我不准 AI 動工。這不是浪費時間，這是在建立「設計共識」。如果 AI 不問你問題，它就在猜你的心思，而 AI 猜測的代價通常是後期的打掉重練。

2. 為了三個月後的自己：寫給「人」看的筆記¶

你可能會問：「AI 寫代碼那麼快，內部邏輯亂成一團怎麼辦？」
我的答案是：戰略性放棄微觀，但嚴格掌控宏觀。 我會要求 AI 在 Open Spec 中記錄學習筆記，這份筆記不是給機器讀的，是給「三個月後的我」讀的。當我未來需要維修時，我不需要讀懂每一行代碼，我只需要讀懂這份筆記，並要求 AI 基於這份筆記跟我對話。這種「對話式維護」是我放過 AI 冗餘代碼的臨界點。

3. TDD：別讓 AI 跑得比大燈快¶

AI 最大的問題是它「跑得太快了」，快到連燈光都跟不上。
應該要強制讓它慢下來。先寫測試案例，定義好「什麼是成功」，再讓它去填充內容。這就像是給瘋馬套上韁繩，只要測試沒過，管你代碼寫得再漂亮都得重來。

4. 深層模組：把髒活藏在接口後¶

我認同軟體設計中的「深層模組」概念。我可以容忍 AI 在內部實作時用一堆代碼堆疊，只要它給我的接口（Interface）像 Type-C 一樣簡單。我負責設計那個出口，AI 負責處理內部的複雜邏輯。只要邊界清晰，內部的混亂就不會蔓延成全域的災難。

5. 角色轉變：從工匠到指揮官¶

從「寫程式的人」變成「審核代碼的人」，我最大的感覺不是輕鬆，而是責任的位移。
現在的我更像是一位資深工程師，在指揮一群高速運作的實習生。我的價值不再於我打字有多快，而是在於：我能不能看穿 AI 華麗外表下的邏輯缺陷？我能不能在系統崩潰前，做出正確的戰略投資？