三十天前，這個系列從一個問題開始：當AI能讀規格、寫程式、補測試，開發者究竟還需要懂什麼？

一路寫下來，前提一直沒有變：規格是完整的，AI也能照著規格做出來。真正容易出事的地方，很少是某一行程式寫錯，而是判斷時少了某些程式碼以外的事實，或把某個代價當成理所當然。

做得出來，和可以放心交出去之間

程式能跑、測試通過，回答的是「照著規格做出來了沒有」。要放心交出去，還得知道這段程式放回真實系統之後會怎麼表現：它讀到的資料在業務上代表什麼，同一份資料還有誰在用，遇到等待、重複與失敗時，原本的判斷是否依然成立。

這些答案有很多不在程式碼裡，而在現有資料、部署方式與其他團隊的系統裡。AI能讀它拿到的一切，也常能從中發現我們沒注意到的線索；但要想到還有哪些事實可能存在、該去哪裡找，往往靠的是對系統的理解。真的找不到時，把它標成尚未確認，也比默默當成不存在來得踏實。

結果本身也是如此。一次通過的測試、一個說得通的解釋，都值得參考，但它們證明了什麼、還沒證明什麼，需要有人分清楚。分清楚之後，AI的分析才能放在正確的位置，團隊也知道離結論還差多少。

代價要有人選，理由要有人留下

能運作的做法通常不只一種，差別在於代價落在哪裡：回應速度、資料一致性，還是之後的維護與營運。AI能很快列出選項、比較優缺點；要承擔哪一種代價，則要回到業務用途、服務要求與團隊當下的處境。這個選擇不一定有標準答案，但可以有清楚的依據。

依據也需要被留下來。程式碼只記錄了最後的樣子，當時保護了什麼、接受了什麼、什麼情況下值得重新考慮，如果沒有寫下來，下一位接手的人，或下一次和AI的協作，都只能重新猜一次。

AI會越來越擅長追查程式、找出影響範圍、補上測試，這個系列談到的某些檢查，很可能會變成工具自動完成的步驟，需要人親自處理的事情也會跟著改變。比較不容易改變的，是對系統與業務的理解。它讓我們能交給AI更完整的背景，也能判斷交回來的方案，是否真的解決了原本的問題。

寫這個系列，也是把自己習慣的做法重新拆開檢查一次。

謝謝你陪這個系列走完三十天。
報名時立的flag沒倒，第一天說的「大家明天見」，今天總算不用再說了。
至於明天會不會有新的問題要處理，那就是另一回事了。