先說結論
引入 AI 後，實作速度確實會提升。
但在團隊開發中，真正成為問題的不是寫程式碼的速度，而是理解程式碼並共享判斷的速度。
從這次閱讀的兩篇文章中，我的總結有三點：
- 規格書不是「永遠維護的正本」，而是「用來對齊認知的起點」
- AI 時代的審查，會從「細節指摘」轉為確認「為何要這樣實作」
- 要把 AI 寫的程式碼變成團隊的資產，就必須打造「能說明的狀態」
對於有「用 AI 實作變快了，但審查和設計反而更辛苦」感受的人，這些內容應該會很有共鳴。
參考的文章
為何引入 AI 後的開發，反而覺得更困難
使用 AI 可以很快產出大量定型程式碼。
CRUD、資料庫遷移、輔助處理等，比以前能在更短時間內推進很多。
但在團隊開發中會出現另一個問題。
那就是，程式碼生成的速度超過了人類理解的速度。
結果容易發生的是：
- PR 變大，審查負擔增加
- 規格書未被更新，很快就過時
- 程式碼能運作，但設計判斷的依據薄弱
- 實作者自己也難以說明「為何要這樣做」
換句話說，AI 增加的不只是程式碼量，也帶來了「理解上的負債」。
學習1：規格書不是「長期維護的東西」，而是「正確啟動的工具」
第一篇文章讓我印象深刻的是，把需求規格或實作計畫交給 AI，能減少實作偏差這點。
需求規格、QA 項目、API 規格、事件規格、參考資訊——
把這些資訊整理好後，AI 與人都比較容易共享前提。
特別是把現有實作當參考一起給 AI，能提高精準度，這點相當有說服力。
不過，這種作法如果一直延續，也會帶來其他問題。
每次規格變更都要更新文件，就會產生與程式碼的雙重管理。
此外，規格書中的程式碼範例也可能成為搜尋上的雜訊。
因此文章重新定義了規格書的用途：不要把它當作「永遠正確的正本」，
而是把它當成「在開發前用來對齊認知的起點」。
我認為這非常關鍵。
AI 時代的規格書重要的不是完美保留內容，而是要做到「讓 AI 與人能以相同前提啟動開發」。
學習2：AI 時代審查重要的不是「正確性」，而是「可解釋性」
第二篇文章中，「理解負債」這個詞讓我印象很深。
AI 能寫出看起來很合理的程式碼。
但那段程式碼是否被團隊真正理解，是另一回事。
文章裡舉例：在跨越點數消耗與獎勵發放的流程中，AI 生成了包含補償交易（compensating transaction）看似合理的實作，
但「若只有其中一方成功時要如何處理」這類設計判斷的依據仍然模糊不清。
另外，有個案例是團隊不自覺採用了 FIFO 隊列，直到審查時被問「真的需要保證順序嗎？」才重新考量。
從這些案例可以看出，AI 時代的程式碼審查真正應該關注的是：
- 為什麼採用這個設計
- 基於哪些優先順序做出這個判斷
- 在故障時系統會如何表現
- 與替代方案比較後，為何選擇這個做法
也就是說，應著重於「判斷的根據」。
命名、規範、明顯的遺漏等一次性檢查可以大量交給 AI 做。
人類審查者反而應該偏向確認：「這個實作是否能被說明清楚」。
從兩篇文章得到的、現在就能做的 action
1. 在設計書中寫下「程式碼不容易自動還原的部分」
比起類圖或偽代碼，對 AI 有最大價值的設計資訊是下面這類內容：
- 錯誤時的處理方式
- rollback 的優先順序
- 重試策略
- 是否需要順序保證
- 運維與監控要觀察的重點
- 作為參考的既有實作
這類資訊從程式碼自動復原比較困難，
正因如此，才更有必要寫在設計書中。
2. 把規格書當成「會被用完」來考量
如果試圖把所有規格維持成長壽命的文件，會非常吃力。
不如把它當作用來對齊認知的產物，必要時再把細節分散到 Issue 或 PR 說明中，會更實際。
比起「留下很完美的文檔」，更重要的是做到「能持續更新的運作模式」。
3. 讓 AI 小範圍輸出，而非一次做很大
使用 AI 時，PR 容易一發不可收拾地變大。
因此應把 PR 切到「一句話就能說明」的粒度。
小的 PR 容易審查、
容易被打回修改、
也容易對 AI 下追加指示。
結果是，團隊整體的理解成本會下降。
4. 區分審查的角色
我認為應把 AI 能處理的事項與人類需要看的人為分開。
可以交給 AI 的有：規範、命名、遺漏檢查、定型檢查。
人類要看的則是：設計意圖、故障時的行為、技術選型的合理性。
不做這個切分，AI 時代的審查會變得越來越沉重。
5. 合併前確認「能否用自己的話說明」
就我個人而言，這是最重要的一點。
不論是 AI 寫的程式碼還是自己寫的程式碼，若最終要合併進主線，實作者應能說明：
- 為何選擇這種方式
- 想定了哪些失敗情境
- 優先考量了什麼、捨棄了什麼
若無法說明，那段程式碼還不算是真正「成為團隊的程式碼」。
總結
AI 可讓實作變快。
但在團隊開發中真正決勝負的是接下來的那些事：
- 規格書怎麼做
- 要維護到什麼程度
- PR 要以何種粒度提出
- 審查要看什麼
- 實作者要承擔到什麼程度的說明責任
如果不檢視這些面向，AI 可能反而會增加現場的痛點，而非減輕。
讀完這兩篇文章後，我最大的體會是：
AI 時代應該守護的不是程式碼量，而是「讓理解能流通的狀態」。
若你有相同的違和感，建議也去讀一下原文，會讓觀察的解析度提升不少。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
