當 AI 說「完成了」，團隊要拿什麼確認？我寫《AI 驅動開發》想回答的問題

我是 Ci，軟體工程師。這是我在就享知的第一篇。

先交代這個頻道之後會寫什麼：AI 進到開發團隊之後，工程流程要怎麼調整，才不會變成「產出變快，出事也變快」。第一篇想先講我 9 月剛出版的書，因為接下來的文章，大多會從這本書延伸出來。

這本書在講什麼

《AI 驅動開發》書封

書名是《AI 驅動開發——從 Prompt 到 Loop，建立可控、可驗、可恢復的工程系統》，深智出版，2026 年 9 月 19 日上市。

整本書從一個很實際的問題開始：

當 AI 說「完成」，人要拿什麼重新確認？

為什麼這不只是工程師的問題

團隊說「做完了」之後，真正的問題才開始

現在讓 AI 寫一段程式、產一份文件，已經不難。難的是後面：它改了哪些東西？改得對不對？出事了能不能退回去？

我自己一開始也是丟幾句 prompt 給 AI，期待它自己搞定。順的時候很快，跑歪的時候完全不知道從哪裡收。改一次、壞一次，再改一次，又壞在別的地方。後來才發現，問題不在 prompt 寫得好不好，是我沒有一套讓「跑歪了收得回來」的機制。

一個人用 AI，出錯了自己收拾。一個團隊用 AI，出錯的成本會落在交付時程、客戶信任，還有接手的那個人身上。所以這件事走到最後，會變成管理問題。

三個關鍵詞：可控、可驗、可恢復

可控、可驗、可恢復：換了模型也用得上的三個判斷

• 可控：AI 動手之前，要改什麼、能動哪些東西，有沒有先講清楚。改動越小，越好檢查。
• 可驗：做完之後，有沒有證據證明它做對了，而不是「看起來對」。一份測試結果或驗收紀錄，比一句「好了」可靠。
• 可恢復：真的出問題，能不能回到改動前，或換一個人接手繼續做。

這三件事跟用哪個模型、哪家工具沒有關係。工具每幾個月就換一輪，我在書裡想留下的，是換了模型也還用得上的工程判斷。

我的觀點：AI 版的開發流程，重點是每一步留下什麼

Anthropic 把 AI 版的開發流程拆成六段，每一段都留下一份紀錄

Anthropic 在 8 月 21 日發了一篇〈The AI-Native SDLC Playbook〉，講 AI 進到團隊之後，軟體開發流程會變成什麼樣子。

它的出發點是：寫程式已經不是瓶頸。開發這一段變快之後，瓶頸就移到前後，也就是規劃、審查與測試、部署，這些還是照人的速度在跑。

所以它把流程拆成六段（規劃、設計、開發、測試、部署、維運），每一段都要留下一份進版控的東西：需求意圖、規格、計畫，接著是 PR、測試和部署紀錄。文章說，這一串紀錄本身就是稽核軌跡：誰要了什麼、AI 做了什麼、誰核准的。工程師的工作也跟著變成帶領幾個 AI 工作階段，並且審查它們的產出。文章建議一開始先開兩到三個就好，上限是一個人審得過來的數量。

文章裡有兩句話，跟我書裡的主張最接近：

「設計審查發生在任何程式碼產生之前，這時候要改方向，只是改一份文件。」

「寫程式的 agent 沒辦法核准自己的程式碼」，所以職責分離還在。

放回書裡的三個關鍵詞，其實是同一件事：

• 動手之前先有規格和計畫，是可控。
• AI 先自己檢查一輪再交給人，而且寫的人不能自己核准，是可驗。
• 每一步都留在版控裡，出事能追、能退，也能換人接手，是可恢復。

對管理者來說，我覺得要調整的不是買哪一套工具，而是每個階段要交出什麼，還有誰來簽核。這篇文章也寫明了：需要判斷的決定，責任仍然在人身上。這也是我在書的結語想講的事：判斷仍然是人的工作。

原文：The AI-Native SDLC Playbook

不寫程式的人怎麼讀

書中的閱讀路線，主管和不寫程式的讀者可以先看標色的兩列

書裡有一條閱讀路線是給 PM、Designer、QA 的：序、第 1、5、7、10、13、14 章。不需要先會操作 Git，重點是從需求到驗收的共同語言。

如果正在想怎麼把 AI 帶進團隊，第 13 章〈從個人 Harness 到團隊 AI 治理〉講的是角色責任、權限、交接和治理。這一章是我覺得最適合管理者先翻的。

一個今天就能做的小動作

下次聽到「AI 做完了」，先問這一句

下次團隊回報「AI 已經做完了」，可以多問一句：

「你是怎麼確認它做對的？」

如果答案是「我看過了，應該沒問題」，那就是最該補的地方。要補的不是更強的 AI，是一個可以驗證的機制。這本書，就是從我自己補這一塊開始寫的。

接下來這個頻道

之後我會把書裡的觀念，拆成比較適合管理者讀的主題：導入 AI 的風險怎麼控、團隊怎麼分工、怎麼判斷一件事「真的做完」。技術細節會收斂，想深入的可以再看書。

紙本書在博客來、天瓏、momo 都買得到，電子書有讀墨、BookWalker、HyRead 等通路。

購書連結：博客來、天瓏書局