跳至主要內容
    新知與拆解· BriefingsBuilding & ShippingFIELD NOTES / 007

    Plan、Build、Verify、Ship 是什麼？AI 寫程式變快後，進度要怎麼算？（2026 完整懶人包）

    寫程式變便宜之後，進度看的是通過了幾道關卡

    sunny 桑尼· · 12 MIN READ · 237 次瀏覽

    Plan、Build、Verify、Ship 是什麼？AI 寫程式變快後，進度要怎麼算？（2026 完整懶人包）
    本文目錄
    1. 階段關卡概念已有數十年：當 AI 讓寫程式幾乎免費，前後的驗證反而成了最大成本
    2. Plan、Build、Verify、Ship 四道關卡：每一階段都要有明確通過條件，未過關就退回前段
    3. 會員中心實戰：程式碼兩天合併完成，卻在 Ship 踩了 4 個只有真實環境才看得到的坑
    4. 依出錯代價決定關卡嚴格度：一句話講得完的改動可跳過，涉及金錢與資料四道關缺一不可
    5. 結論：週會改問「這週過了幾道關」，未通過驗證的產出進度就是零
    6. 常見問題
    7. 什麼是 Plan → Build → Verify → Ship 方法論？
    8. 為什麼用產出量（行數、PR 數）衡量 AI 開發進度會害了專案？
    9. Verify（驗證）環節如果全部交給 AI 自己檢查會發生什麼事？
    10. 小團隊或個人開發者該如何落地這四步？
    11. 延伸閱讀
    12. 參考資料

    AI 讓你一週合併的 PR 翻倍，週會上卻還是說不清楚進度到哪了？這篇帶你用四道關卡重新算進度，開工前就把每一關的通過條件寫好！

    週會上，主管問：「這週做了什麼？」

    以前這個問題很好用。寫程式是整個專案最貴的一段，寫了多少，大致就等於做了多少。程式寫完，剩下的測試和上線雖然也要時間，但量跟著寫的量走，估得出來。

    AI 把最貴的那一段變便宜了。軟體工程分析公司 Faros AI 在 2025 年分析了一萬多名開發者的工作紀錄，AI 用得多的團隊，合併的 PR 多了將近一倍。

    AI 讓團隊合併的 PR 增加近一倍，PR 審查時間同步暴增 91%，但真正完成的任務僅增加 21%（資料來源：Faros AI 2025 年軟體工程報告，n>10,000）。

    這張圖裡最該看的是中間那條：審查時間也多了 91%。產出變多了，但每一份產出要人看、要驗證、要上線的成本，沒有跟著變便宜。工作沒有消失，它往下游堆。

    其他地方也看得到同一件事。Google 的 DORA 團隊在 2025 年的報告說，AI 用得越多，交付量越高，但交付的穩定度越低。CircleCI 統計 2025 年九月的兩千八百多萬次自動化建置，主分支的成功率掉到 70.8%，是五年來最低。日本一份針對 322 名負責 code review 的工程師的調查，86% 說審查負擔變重了，最常見的抱怨是「寫的人自己說明不了程式碼」。

    所以週會的問題要換一個。寫完不算數，過關才算。進度要用「通過了幾道關」來算，每一道關的通過條件，要在開工前寫好。

    快速回答 AI 讓 Build（寫程式）幾乎免費，進度就不能再用「產出了多少行程式碼」來算。進度看的是「過了幾道關」：Plan（寫下通過條件）→ Build（AI 產出實作）→ Verify（客觀驗證與測試）→ Ship（小規模交付與監控）。每一段的通過條件必須在開工前寫好，Ship 學到的事要回寫到下一次的 Plan。

    階段關卡概念已有數十年：當 AI 讓寫程式幾乎免費，前後的驗證反而成了最大成本

    把工作切成幾段、每段要過關才往下走，在工程管理裡有很長的歷史。品管學者 Shewhart 在 1939 年提出循環式的改善流程，後來 Deming 帶到日本，1951 年被日本品管界整理成大家熟悉的 PDCA。1990 年，Robert Cooper 提出 Stage-Gate，把新產品開發切成幾個階段，每個階段後面放一道關卡。Scrum 的 Definition of Done 則把「做完」寫成一份正式的品質標準，沒達到就不算完成。

    這些方法在 AI 之前就存在，但當時有個默契：寫程式很貴，所以前後的關卡相對便宜。現在倒過來了。寫程式幾乎免費，關卡反而成了人花最多時間的地方。

    AI 工具自己也在往這個方向長。Claude Code 在 2025 年 6 月加入 plan mode，讓 AI 先提計畫、你同意了才動手；OpenAI 的 Codex 在 2026 年 2 月把 plan mode 改成預設開啟。GitHub 在 2025 年 9 月開源了 Spec Kit，把開發切成規格、計畫、任務、實作四段，文件寫明「目前這一段沒驗證過，就不要往下走」，還有一句我很喜歡的話：AI 產出這些文件，你負責確認它們是對的。Anthropic 給 Claude Code 使用者的建議更直接：如果你沒辦法驗證，就不要上線。

    Plan、Build、Verify、Ship 四道關卡：每一階段都要有明確通過條件，未過關就退回前段

    我把 AI 做產品的流程切成四段：Plan、Build、Verify、Ship。每一段只問一個問題，答得出來才往下走。

    Plan、Build、Verify、Ship 各階段皆有明確通過條件，未過關即退回前段修正，上線經驗則回饋至下一次 Plan（Sunny DataScience 整理）。

    階段通過條件：要能回答的問題留下來的東西

    Plan
    通過條件：要能回答的問題
    這次要解決誰的什麼問題？做到什麼程度算完成？
    留下來的東西
    一頁範圍與驗收條件
    Build
    通過條件：要能回答的問題
    能不能從頭到尾示範一次真實流程？
    留下來的東西
    可以跑的版本、改了什麼
    Verify
    通過條件：要能回答的問題
    每一條驗收條件，有沒有對應的證據？
    留下來的東西
    測試結果、檢查紀錄
    Ship
    通過條件：要能回答的問題
    要用的人，在他自己的環境裡做完了他要做的事嗎？
    留下來的東西
    上線紀錄、使用者回饋

    這張表裡最容易被跳過的是 Verify 那一格。AI 會告訴你「已完成，測試都通過了」，但它說的通過，是它自己寫的測試通過。Verify 要對照的，是 Plan 寫下的驗收條件；AI 自己定的標準不算。這也是為什麼 Plan 一定要先寫：沒有驗收條件，Verify 就沒有東西可以對。

    圖的下半部同樣重要。驗收沒過，退回 Build；做到一半發現需求本身錯了，退回 Plan。退回能讓問題停在出錯的那一段，不會一路帶到上線。最後一條是虛線：上線之後才學到的事，要寫回下一次的 Plan。

    會員中心實戰：程式碼兩天合併完成，卻在 Ship 踩了 4 個只有真實環境才看得到的坑

    我最近替這個網站做了會員中心，讓學員可以看到自己買過的課、整理自己的作品。整個功能用 Claude Code 開發，分三期，兩天內做完。這個例子剛好說明了「寫完」和「做完」差多遠。

    Plan。開工前我先寫了一份規格。裡面有已經確認的決定，例如登入方式、作品要不要公開由誰決定、見證有哪些必填欄位；也有一份現況盤點，查完才發現，舊系統的購課資料其實只有 3 筆，全部是我自己的測試帳號。這個發現讓「舊資料轉移」從一件大事變成一件小事。規格最後把功能分成四期，每一期都列出上線步驟。

    Build。第一期在當天晚上就合併了：學員中心頁、個人資料、購課紀錄、後台的匯入功能。第二、三期在隔天內完成。用 AI 寫這些程式，速度確實很快。

    Verify。資料庫的變更腳本，先在本機一個用完就丟的資料庫上跑過，確認可以重複執行、資料合併和帳號認領的行為都對。第三期串接外部課程平台的部分，寫了自動測試。

    Ship。問題是在上線之後才出現的：

    • 有一個後台功能根本沒有部署，後台的作品分頁是空的。
    • 學員作品的圖片破圖。原因是存放圖片的儲存空間被設成不公開，而且用資料庫腳本改不了，網站平台的資料庫遷移不能建立或修改儲存空間，最後要到平台的管理介面手動處理。
    • 管理員用 Email 登入後上傳檔案，送出的驗證資訊不對，當晚修正。
    • 第三期在管理介面設定的檔案類型限制沒有作用，改用資料庫的權限規則限制副檔名，之後測過，.exe 檔會被拒絕。

    這幾個問題有一個共同點：程式碼都寫完了，也合併了，在 Build 和 Verify 那兩關看起來都沒事。它們卡在 Ship 那一關，因為只有在真實環境、由真的使用者操作，才看得到。

    我做的修正，是圖上那條虛線。從第二期開始，規格裡的上線步驟直接寫明：「如果建立儲存空間那段失敗，改到平台介面手動建立。」第一期在 Ship 學到的事，變成了第二期 Plan 的一部分。

    依出錯代價決定關卡嚴格度：一句話講得完的改動可跳過，涉及金錢與資料四道關缺一不可

    關卡太多會變成官僚。Anthropic 給 Claude Code 使用者的建議裡有一句很實用的話：如果這次的改動一句話就講得完，可以跳過計畫。改一個錯字、調一個顏色，不需要寫規格。只給自己用的一次性腳本、還在摸索方向的原型，也不需要。

    我的判斷標準是：出錯的代價越高，關卡越要嚴。會碰到別人的資料、會收錢、會被很多人用到的功能，四道關一道都不能少；自己的實驗，Plan 和 Verify 可以縮成幾行字。關卡要多嚴，和要不要讓 AI 自己跑多久是同一個問題，可以接著讀〈Claude Code 權限要怎麼設？一直按「允許」真的安全嗎？（2026 完整懶人包）〉。

    另一個邊界是：關卡擋得住的，只有你寫下來的條件。會員中心的圖片破圖，在第一期的規格裡沒有寫到，所以 Verify 沒有攔下來。這就是為什麼最後那條虛線重要。你沒辦法在第一次就寫出完美的通過條件，但每上線一次，條件就該更完整一點。

    結論：週會改問「這週過了幾道關」，未通過驗證的產出進度就是零

    下一次週會，把「這週做了什麼」換成「這週過了幾道關」。

    寫了五個功能、一個都還沒過 Verify，進度是零。寫了一個、它已經在使用者手上順利跑了一週，進度才是一。這個算法剛開始會讓數字很難看，但它算的是真的進度。

    AI 讓寫程式變得很便宜，便宜到「寫完」已經不值得拿出來報告。寫完不算數，過關才算。

    Plan 這一段要寫到多清楚，可以接著讀〈AI Coding 還需要寫 PRD 嗎？需求越模糊，Agent 替你決定的越多（2026 完整指南）〉。

    常見問題

    什麼是 Plan → Build → Verify → Ship 方法論？

    這是專為 AI 協作開發設計的四階段交付循環。Plan 階段先定義通過門檻；Build 階段讓 AI 高速生成實作；Verify 階段使用自動化測試或明確檢查清單進行客觀驗收；Ship 階段小步上線並收集真實使用者回饋，將學到的盲點回饋至下一個 Plan。

    為什麼用產出量（行數、PR 數）衡量 AI 開發進度會害了專案？

    AI 生成程式碼的成本趨近於零，十秒鐘就能生出上百行。若以程式碼行數或功能數量當作進度指標，會誘使團隊產生大量未經驗證的半成品，把隱藏的技術債與相容性問題全部拖到上線前夕才爆發。

    Verify（驗證）環節如果全部交給 AI 自己檢查會發生什麼事？

    AI 具有「自圓其說」的強大傾向。如果讓同一個 Agent 既寫程式又負責驗證，它寫出來的測試往往會刻意避開自己的盲點，甚至在功能根本沒跑通時讓測試通過。驗證必須依靠獨立的測試腳本、外部 Reviewer 或真實環境的客觀回饋。

    小團隊或個人開發者該如何落地這四步？

    從小步快跑開始：Plan 只寫三條驗收條件；Build 讓 AI 生成程式碼；Verify 跑一次真實指令（如 pytest 或部署至預覽環境）；Ship 交給第一個測試使用者使用。只要維持每一輪都有具體關卡被跨越，交付節奏就不會亂。

    延伸閱讀

    參考資料

    數據與調查

    方法的來歷

    AI 工具的做法

    #AI Builder Method#Plan Build Verify Ship#Spec-Driven Development#Definition of Done#AI 專案
    ShareTwitterFacebookLinkedInLine
    Previous

    AI Coding 還需要寫 PRD 嗎？需求越模糊，Agent 替你決定的越多（2026 完整指南）

    Next

    Claude Code 權限要怎麼設？一直按「允許」真的安全嗎？（2026 完整懶人包）

    留言0

    登入後就能留言。

    登入
    sunny 桑尼
    sunny 桑尼

    AI 資料科學 · 產品經理 · 蒙奇 D 桑尼

    專注於 AI 工具應用與資料科學教育，致力於讓每個人都能用 AI 提升工作效率。曾任職於科技業，現為全職教育創作者。

    讀更多文章 →想自己動手試？領免費 Starter Kit →