AI 應先治理 SDLC，再去寫程式碼
AI 最有價值的地方不是先產生程式碼，而是先審核需求與評審流程，提早攔下錯誤決策。
AI 最有價值的地方不是先產生程式碼，而是先審核需求與評審流程，提早攔下錯誤決策。
我站在這一邊：AI 應先治理 SDLC，再去寫程式碼。因為軟體團隊最大的損失，往往不是少寫了幾行碼，而是把錯誤需求、模糊假設與低品質評審一路傳到實作階段，最後用更多人力補洞。Uber 把 AI 放在 PRD 驗證，DoorDash 把它放進高訊號 code review，Cloudflare 則用專門代理做分工審查，這些案例指向同一件事：AI 最適合先當治理層，不是先當產碼機。
第一個論點
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
AI 在需求階段的價值，遠高於在產碼階段的炫技。Uber 的 PRD 驗證流程就是典型例子，系統先檢查清晰度、完整性與執行風險，再讓工程師動手。這不是形式主義，而是在最便宜的時點抓出最昂貴的錯誤，因為一份有缺陷的需求文件，後面通常會變成設計改一次、實作改一次、驗收再改一次。
實務上，模糊需求會把成本層層放大。產品寫得不清楚，設計會補自己的理解，工程會補自己的假設，最後 code review 變成「這到底原本想做什麼」的辯論。AI 若能先標出缺失依賴、衝突條件與未定義邊界，就等於在工作流最前端截斷 rework。這種節省不一定會出現在漂亮的儀表板上，但它直接影響團隊吞吐量。
第二個論點
在 review 階段，AI 的核心不是產生更多評論，而是產生更可信的評論。DoorDash 的內部 reviewer 之所以值得參考，不在於它留言多，而在於它刻意追求高訊號、低噪音。這很重要，因為 code review 最怕的不是漏掉一兩個問題，而是工具丟出一堆泛泛警告，最後工程師把它當背景噪音。
好的 AI reviewer 應該像成熟的同事，而不是急著表現的實習生。它要能指出具體問題、嵌入既有流程、並且尊重人工決策權。DoorDash 的做法說明一個很現實的標準：如果工具真的改變了上線前的行為，它就有價值；如果它只是增加 comment 數量，那只是把噪音包裝成生產力。
反方可能怎麼說
反方會說，AI 最該先進入的地方是 code generation，因為那裡有最直接的產出；把它放到 PRD 和 review，反而像是多加一層機器關卡。很多團隊本來就已經被流程拖慢，再多一個 AI 審核，會不會只是把開發節奏變得更官僚、更難啟動？
這個疑慮不是空穴來風。模型會看漏上下文、誤判內部術語，也可能用很像樣的語氣講錯誤的建議。若團隊把 AI 輸出當成權威，就會出現 approval theater：看起來很嚴謹，實際上只是把薄弱需求和粗糙 review 重新包裝。
但這個批評只能限制 AI 的角色，不能推翻它應該前移的結論。AI 不該成為額外的批准者，而該是第一道過濾器，先攔下明顯缺陷，再把人的注意力留給真正需要判斷的地方。人仍然要負責決策，AI 則負責把最浪費時間的錯誤提早暴露出來。
你能做什麼
如果你是工程師、PM 或創辦人，別先問 AI 能不能多寫 code，先問它能在哪裡減少返工。把它放進 PRD、設計說明與 review 流程，觀察它是否真的降低歧義、縮短審查時間、提升決策品質。真正值得押注的不是產碼速度，而是治理能力：先用 AI 把需求和審查變乾淨，再讓工程師把時間花在真正的實作上。