AI 寫程式變快了，產品為什麼還是交不出去？我怎麼理解 AI 原生開發流程

讀完 Anthropic 的 〈The AI-native SDLC playbook〉，我一直在想一個問題：當 AI 可以很快寫出程式，我們到底在等什麼？

假設我正在經營一個活動報名網站，想加上「候補通知」。我請 AI 動手，它很快把寄信和確認頁面做好了。但我還沒決定：有人取消後，名額要替候補者保留多久？對方沒回覆，要不要通知下一位？已經過期的連結，又能不能繼續使用？

這時候，寫好程式距離放心推出，還有一段路。

原文由 Louis Claxton 撰寫，頁面標示發布於 2026 年 8 月 21 日。它主張，AI 加快程式產出後，瓶頸會移到需求、驗證與交付；開發流程應讓 AI 參與各階段，用可追溯的成果接續工作，同時保留人的決策責任。

我想用這篇文章整理自己對這個觀點的理解，再用一個功能從頭走到尾。下面的候補網站、人物、時間與數字都是我為了說明而設定的假想情境，提示詞與文件也是示範，沒有實際執行結果。

我先把 SDLC 想成：一個功能如何從念頭走到有人用

SDLC 是 Software Development Lifecycle，中文常稱「軟體開發生命週期」。我會把它理解成六個問題：

階段	我想先回答的問題	以候補通知為例
規劃	為什麼要做？	主辦方要一直人工聯絡候補者
設計	使用者會怎麼操作？	候補者收到通知後，在期限內確認
開發	系統要改哪些地方？	名額、通知信、確認頁面
測試	如何確認真的能用？	重複點擊、逾期確認都不會超收
部署	怎麼交到使用者手上？	先用測試活動演練，再分批啟用
維護	推出之後要看什麼？	信是否送達、名額是否正確釋出

「部署」就是把新版本放到實際提供服務的環境；「維護」則包括追查錯誤、修正問題與持續改善。小型專案裡，這六件事可能都是同一個人做，仍然值得分開想。

我對「AI 原生」的理解，是安排工作時就把 AI 能做什麼、需要哪些資訊、如何驗證成果一起考慮進去。只要下一步需要人把整段聊天重講一遍、重新整理檔案、重新追問結果，流程就還有可以改善的地方。

我會先看整段等待，而不是只看寫程式多快

我覺得餐廳出餐是個好比喻。炒菜突然變快，但點餐不清楚、食材沒備好、餐點卡在出餐口，客人仍然得等。

候補通知也一樣。AI 很快寫好寄信功能，我卻花了幾天才決定名額分配方式，或沒時間審閱它的修改，使用者就感受不到加速。

我用這張圖說明等待如何累積。方塊長度是概念示意，不代表實測工時或效能比例。

所以，我想觀察的是：一個功能從提出到能用，共花多久？中間在哪裡反覆討論？推出後是否增加客服負擔？如果程式產量增加，審閱卻塞住，下一個該改善的環節就已經很清楚。

下面，我就用候補通知示範：假如要把整段流程交代完整，我會怎麼和 AI 合作。

第一步：我先寫清楚問題，暫時不急著做功能

「有人取消，就通知候補的人」是一句直覺的需求，但離能實作還有不少空白。我會先請 AI 幫我找問題：

我想替活動報名網站加入候補通知，先不要寫程式。

目前的困擾：有人取消後，主辦方要人工查名單、逐一聯絡，
也不知道對方多久才會回覆。

請先列出你需要我決定的問題，分成：
1. 不決定就無法設計的規則。
2. 可以留到下一版的選項。
3. 必須查現有系統才能回答的問題。

不要替我補上尚未確認的商業規則。

我期待它指出「確認期限」與「排序方式」這類關鍵決定，也把「能否使用既有寄信服務」留成待查事項。它如果直接寫下「保留 24 小時」，我會要求標成假設，因為這個數字關係到主辦方多久能把名額補滿。

討論過後，我會留下這樣一份簡短的需求草稿：

# 候補通知：需求草稿

## 想解決的問題
取消報名後，主辦方需要人工聯絡候補者，容易漏掉空出的名額。

## 這一版的結果
系統依候補登記時間排序，一個空缺一次邀請一人。
收到邀請的人有 2 小時確認，逾期才通知下一位。

## 保留的限制
不變更付款流程，不提供主辦方手動插隊。
通知內容不包含其他候補者的資料。

## 尚待確認
活動開始前不到 2 小時，是否仍繼續遞補？
寄信服務中斷時，期限要從哪個時間點起算？

這裡的 2 小時只是本例的選擇。我刻意保留未決問題，因為「文件看起來完整」很容易讓人誤以為所有事情都決定了。

到這一步，我會用一個標準檢查：沒參與討論的人能否讀完後，說出這個功能要解決什麼、這一版不做什麼？如果還說不清楚，就繼續釐清。

第二步：我用具體情境，逼設計說明白

需求方向有了，我會把抽象規則換成一段使用過程。

假設上午 9 點有人取消，第一位候補者小安收到邀請，系統替他保留到 11 點。小安沒有確認，11 點後名額改保留給下一位小柏。11 點 05 分，小安才打開原本的信。

此時畫面應該怎麼辦？

我會選擇顯示「這次邀請已到期」，並阻止它動用小柏的保留名額。頁面也不能隨便承諾「你已自動回到隊伍」，除非我真的決定了重新排隊的規則。

這組時間是我設定的示例。把流程放到同一條時間線，過期連結與名額歸屬的問題就比較容易看見。

我會請 AI 對照這段情境整理設計：

請依需求草稿，畫出候補者從等待、收到邀請，到確認或逾期的流程。
先不要實作。

請逐一回答：
- 系統如何判斷這份邀請現在仍有效？
- 邀請逾期後，舊連結還能做什麼？
- 同一人連按兩次確認，會不會占用兩個名額？
- 寄信失敗時，畫面與後台各會看到什麼？

凡是需求沒有決定的地方，請標成待確認，不要自行定案。

我會特別看「前一個動作失敗時，下一步怎麼辦」。順利收到信、按下確認的流程通常很好畫，麻煩常出在寄送失敗、連結過期、使用者重複操作的時候。

這也是我希望 AI 協助的地方：把容易漏掉的分支攤開，讓我能在改程式之前決定要接受哪些行為。

第三步：我先審實作範圍，再讓 AI 改程式

設計說得通後，我會要求一份能拿來審閱的實作計畫。檔名可以簡單，但內容要讓我看見修改的邊界。

例如，這個假想專案可能需要以下工作：

修改範圍	我會要求交代的事
候補名單	如何選下一位，以及如何避免同一名額分給兩人
邀請紀錄	記下對應活動、候補者、期限與目前狀態
寄信工作	失敗怎麼重試，以及如何避免產生重複邀請
確認頁面	成功、過期與已確認時，各顯示什麼
管理介面	主辦方如何看見寄信失敗與待處理事項

這些是我用來討論的範圍，實際檔案、資料結構與修改順序，仍要讀完既有程式才能決定。我不會先替 AI 編出一串不存在的檔名，再要求它照著改。

我會這樣下指令：

請閱讀現有報名、候補與寄信流程，再提出實作計畫。

列出實際會改的檔案、每一步影響的行為、資料是否需要調整，
以及各步驟要用什麼方法驗證。
如果現有系統無法支持設計，請先說明原因與可選方案。

這一輪只讀取並整理計畫，不修改程式。

我想提前發現的，是「看似小功能，實際會碰到重要規則」的地方。例如新增邀請期限，可能需要處理既有候補資料沒有期限的情況；調整名額保留方式，也可能影響原本的正式報名。

如果開發途中才發現設計行不通，我會同步修改計畫與驗收條件。否則審閱時手上是一份舊說明，看到的卻是另一套實作。

第四步：我用驗收情境，確認 AI 做出的東西能不能用

「測試都過了」很有吸引力，但我還想知道：它究竟測了什麼？

我會先寫出重要情境，再請 AI 或工程師把能自動化的部分做成測試。以下是這個假想功能的驗收表：

情境	我期待的結果
小安在期限內確認	取得一個正式名額，邀請標成已確認
小安連按兩次，或網路重試同一請求	仍只有一筆有效報名，不重複扣名額
小安的邀請逾期，名額已改留給小柏	小安舊連結無法確認；小柏的保留仍有效
沒有剩餘候補者	空缺保留為可用名額，不寄出無對象的通知
寄信服務暫時失敗	不把失敗記成已送達，並留下可追查的狀態
活動已取消	不能用舊邀請完成報名，頁面說明原因

重複請求這件事，工程上常叫「冪等性」：同一個動作重做，結果仍然維持一次的效果。我覺得這個詞用候補確認很好理解，因為人可能真的會連按兩次，系統也可能因為網路問題重送請求。

我還會區分兩種檢查。

一種是系統內部的結果，例如名額不能被重複占用，適合自動測試；另一種是使用者能否理解畫面，例如「邀請過期」是否交代清楚，適合實際操作與截圖檢查。兩者都重要，不能互相取代。

請 AI 修錯時，我也會要求保留原本的驗收條件：

請先重現「舊邀請逾期後仍能確認」的問題，說明失敗原因，
再修改程式。完成後重新執行相關測試，附上實際輸出。

不要透過刪除測試、跳過檢查，或放寬「不能超收」的條件讓結果通過。
如果你認為驗收條件本身有矛盾，請先指出來供我判斷。

這裡我在意的是證據能否支持結論。一張綠色的檢查畫面，若沒有涵蓋舊連結與重複確認，還不足以證明候補流程正確。

第五步：我在 PR 裡看行為，也演練怎麼收回變更

PR 是 Pull Request，也就是把修改集中起來、請人審閱後再合併的請求。我希望它能讓我快速看見「改了什麼、怎麼驗證、還有哪些問題」。

我會要求這樣的摘要。以下仍是待填寫的格式，不能拿範例當成已通過的結果：

## 使用者會遇到的改變
有人取消後，第一位候補者收到邀請；逾期才輪到下一位。
已過期的舊邀請不能再取得名額。

## 驗證證據
- 自動測試：填入實際指令、結果與未涵蓋的情境。
- 操作檢查：附上有效、逾期、已確認三種畫面。
- 寄信失敗：填入演練方式與觀察結果。

## 上線與恢復
- 先對內部測試活動啟用。
- 說明如何停止新邀請，以及誰能操作。
- 說明已寄出但尚未確認的邀請會如何處理。

## 待審閱
列出尚未定案的規則與已知限制，不用「應該沒問題」帶過。

上線前，我會用模擬信箱走完整個流程。除了確認新版本可以推出，也要演練發現問題後怎麼停止。

例如，若發現邀請信內容有誤，關閉「建立新邀請」並不會收回已寄出去的信。我還得決定：已寄出的確認連結是否繼續有效？需要補寄說明嗎？主辦方如何找出受影響的人？

因此，我不會只在文件上寫「有問題就回復舊版」。如果新版本已改變名額或邀請資料，換回舊程式可能仍然留下需要處理的紀錄。對這個功能，我會先設計停止新增、保護既有名額、清點影響範圍的方法，再考慮是否回復程式版本。

第六步：我讓使用回饋回到下一輪需求

假設功能上線後，有人反映：「我收到信時，連結就快到期了。」

我不會立刻請 AI 把 2 小時改成 4 小時。那可能掩蓋真正的問題。我的第一步會是查清楚：期限從什麼時候起算？信件何時排入寄送、何時被寄信服務接受？有沒有重試或延遲？

我會請 AI 把調查拆成三部分：

我要求的分類	這次事件可能寫下的內容
已知事實	邀請建立時間、期限、寄信嘗試與重試紀錄
尚待驗證的推測	可能是寄信延遲，或畫面的時間顯示有誤
下一步	核對時區、追查寄信工作，確認期限計算規則

這裡還有一個容易誤會的地方：寄信服務接受請求，不代表使用者已經收到或看見信。調查紀錄要說清楚觀察到哪一步，才不會把推測寫成事實。

如果最後確認是「從建立邀請就開始倒數，但寄送延遲很久」，我才會把期限起算方式重新帶回需求討論。改完後，也把這種延遲情境加入驗證，避免下次同樣出錯。

這樣一來，維護得到的線索就能接回規劃，六個階段形成持續改善的循環。

我希望每次交接都留下「已決定什麼、如何確認、誰接手」。這是我自擬的候補通知案例。

我為什麼希望資訊能留在聊天以外的地方

走完這個例子，就能看出需求、設計、實作與驗證其實是一連串相互影響的決定。

如果它們只存在聊天裡，隔幾天換個人接手，就得重新拼湊：到底保留多久？寄信失敗算不算開始倒數？哪一版才是最後決定？

原文以 intent.md、spec.md、plan.md 等檔案銜接工作，並保留版本紀錄；也允許沿用既有需求系統，但要交代哪裡是權威資料來源。詳見原文。這裡的 .md 是 Markdown 文字文件，可以用一般文字編輯器閱讀。

對我而言，先把一張工單維護好就很有價值。它至少要連到需求結論、相關 PR 與驗證結果。若把保留時間從 2 小時改成 4 小時，就同步調整驗收情境與客服說明，避免不同地方各講各的。

我也會留意文件量。只有幾行的文字修改，不需要為了湊齊檔案名稱，重複寫三份差不多的內容。能讓接手的人與 AI 找到正確資訊，比文件數量更有意義。

我會分清楚：提醒 AI，和系統真的阻止它

原文區分了 skill 與 hook：前者提供工作指引，後者可在動作發生時執行程式檢查。參考原文的 Skills 與 Hooks 說明。

我會把它想成活動現場的兩種安排：「請確認票券」是工作手冊，「驗票成功才開門」是入口設備。手冊告訴人怎麼做，設備負責檢查某個條件。

放到這個案例，我會用下面的方式分工：

需要遵守的事	我會提供的指引	我還需要的檢查或限制
不超收	說明名額與保留規則	系統更新名額時的機制，以及重複、同時操作的測試
不洩漏聯絡資料	說明哪些欄位不能進入錯誤紀錄	紀錄檢查與受限的資料存取權限
正式寄信前先確認	說明測試活動與正式活動的差別	測試帳號不能對正式名單寄信，正式操作由指定人員授權

我不會把所有限制都寄望在同一種 hook。開發工具的檢查、寄信服務的權限與報名系統本身的規則，各自保護不同的地方，也都有可能設定錯誤。

我要追問的是：如果這條規則被違反，會有人先收到提醒、動作會被阻止，還是只能等使用者回報？知道答案，才知道現在的保護夠不夠。

如果是我的個人部落格，我會怎麼縮小這套做法？

候補通知牽涉名額與聯絡資料，流程需要交代得比較完整。但我也想把同樣的思路帶回個人網站，讓它小到真的能開始。

假設我要替部落格新增「文章閱讀進度條」，我會這樣安排：

1. 先定義目的。 我想讓讀者知道文章還剩多少，而非只因為看到別人有就跟著加。
2. 把設計說清楚。 進度從正文開始算，不把導覽列與留言算進去；短文章是否顯示，也先決定。
3. 讓 AI 查現有版型。 找出正文容器與既有樣式，再提修改範圍，避免在每個頁面重複塞程式。
4. 驗證實際閱讀。 看長文、短文、手機畫面與深色模式；讀到正文底部時，進度應接近完成。
5. 附畫面再審閱。 PR 裡放桌面與手機截圖，說明如何移除這項功能。
6. 回看使用感受。 若遮住標題或讓手機畫面擁擠，就調整位置，而不是因為「程式已經完成」而勉強保留。

這個修改不需要照搬整份企業流程。我可能只用一張工單、一個小 PR 和幾張截圖，就能留下足夠的脈絡。

我會特別避免一種做法：只請 AI「幫我加個好看的進度條」，然後看到畫面能動就合併。那樣很容易漏掉文章之外的頁面、手機版與實際閱讀範圍。

我會怎麼判斷，這套流程到底有沒有幫助？

如果要開始試行，我會選一個範圍清楚、容易恢復的小修改，先記下原本的等待，再用同樣的方法觀察幾次。

我會看四件事：

• 交付時間： 從需求確認到可用，中間花多久？哪些時間用在等待？
• 返工原因： 是程式寫錯、需求沒講清楚，還是審閱時才發現設計不合適？
• 使用者問題： 上線後是否出現原本沒考慮的操作情境？
• 整體成本： AI 使用費、執行時間，以及我讀文件、審 PR、處理錯誤的時間。

若 AI 寫得更快，但我花更多時間猜它為什麼這樣改，我就會縮小每次修改，要求更清楚的摘要。若需求反覆變動，就先改善前面的問題釐清。一次順利交付也不能證明所有工作都適合相同做法，我會繼續觀察不同類型的修改。

讀完這份 playbook，我最想調整的是每次交付的完整度：我有沒有說清楚想解決的問題？AI 有沒有提供足夠的驗證？下一位接手時，是否知道哪些事已經決定、哪些事仍要判斷？

當這些問題有了具體答案，AI 寫程式的速度，才比較有機會變成我能放心交付、讀者或使用者也感受得到的改善。

延伸閱讀

• Louis Claxton，Anthropic：The AI-native SDLC playbook。原文提供六階段的詳細做法與治理建議。本文為我的閱讀心得與延伸示例，未重製原文圖表。