AI 知識
速度可以交給 AI；可信任，得靠流程留下證據
AI 讓把想法變成程式的速度大幅縮短，但一段程式跑得起來，不等於它已經準備好交付。
真正容易失速的地方，往往在程式碼前後：需求是否寫清楚、限制有沒有被保留、測試是否覆蓋、審核發現有沒有留下、上線後的問題能不能回到下一輪改進。
程式不再是唯一瓶頸
公開的 AI 原生 SDLC 方法把軟體交付拆成六個互相連動的階段：Plan、Design、Build、Test、Deploy、Maintain。當 AI 壓縮了 Build 的時間，原本由人類節奏主導的規劃、測試、審核與部署，反而會成為新的等待區。
這不表示要把人從流程中拿掉。相反地，人需要把注意力放在真正需要判斷的關卡：目標有沒有被理解、限制有沒有被遵守、風險是否可接受、上線後異常該怎麼處理。
可交付的不是程式碼，而是可接手的脈絡
一個能持續運作的流程，會讓每一段工作留下下一段可讀取的成果物：
- 意圖：要解決什麼問題、為什麼做、哪些限制不能碰。
- 設計與計畫：會改哪些地方、驗證方式是什麼、可能風險在哪裡。
- 實作與測試：程式的變更與證明它能運作的測試一起出現。
- 審核紀錄：哪些地方被檢查、哪些問題被修正、哪些決定由人承擔。
- 部署與回饋：上線版本、觀測結果、事件處理與下一輪要補的需求。
這些不是額外堆疊的文書。當工作從一個人、一個工具交到下一個人、下一個工具時，它們就是避免脈絡掉落的交接面。
AI 加速後，更需要能驗證的關卡
AI 可以協助起草規格、提出計畫、產生程式和測試，也能整理審查線索。但越快產生內容，越需要明確知道哪個環節在驗證它。
一個實用原則是：不要只問「AI 有沒有把功能做出來」，還要問「下一個接手的人，能不能看懂這個功能為什麼這樣做、怎麼證明它可用、出問題時怎麼處理」。
當這些答案被留在流程裡，速度才不會把交付推向失控。
結語
AI 時代的工程能力，不只在於把程式寫得更快，而在於讓每一個快動作都能被追溯、驗證與接手。速度可以交給 AI；可信任，得靠流程自己留得住證據。
查證摘要
- Anthropic 的 AI-Native SDLC playbook 將交付拆為規劃、設計、實作、測試、部署與維護，並主張每階段產出可被下一階段讀取的版本控制成果物。
- Stripe 公開說明其內部端到端 coding agents 仍由人類審查程式合併，支持自動生成並不等於取消人類責任與品質關卡。
- 本文是對公開工程做法的知識整理，不保證任何工具、團隊或流程皆會取得相同結果。