AI 花幾分鐘改完數個檔案，測試畫面也全數通過，這時最容易出現的誤判，是把「已經有一版可以看」當成「工作快結束了」。畫面上的變更很完整，團隊卻可能還不知道它為何這樣改、出了問題要從哪裡查，也沒有人答應半年後繼續照顧它。
本文所說的 coding agent，是能讀取既有程式、修改多個檔案並執行部分檢查的 AI 助手。它交出的 patch，也就是一組等待審查的程式變更，應先視為候選版本，而不是可以直接合併、發布的正式成果。
GitHub 最近把第一版 patch 比作一次「price check」：團隊先以相對低的成本取得一個可能解法，藉此看見修改範圍與潛在代價。這次試價能告訴我們候選版本多快出現，卻沒有包含人工理解與驗證所需的時間，更沒有回答日後由誰維護。
所以，判斷標準不該只是 AI 有沒有把程式寫出來。團隊真正要確認的是：眼前是否已有足夠證據，讓人能安全接手這次變更。
第一版的價值，在於提早看見代價
程式可以執行，不表示審查者已經理解它。人仍要核對需求是否讀對、修改有沒有超出約定範圍、測試是否涵蓋重要的失敗情境，以及異常發生時能不能回到上一個可用版本。
如果這些答案只能從 AI 的對話紀錄裡拼湊，理解成本就沒有消失。它只是被留到正式環境出問題、原作者不在場或需要緊急修復時才一次浮現。
另一筆容易漏算的是後續維護責任。這裡的 ownership，不是一個抽象標籤，而是有人願意在未來解釋這段程式、處理異常、更新相依套件，並在成員更替時把必要知識交給下一位維護者。
EASE 2026 / arXiv 的實證研究分析了 100 個程式碼儲存庫（repository）、超過 1,000 個檔案及約 3,200 次變更。研究發現，由 agent 產生的程式，之後大多仍由人類維護。DORA 的研究則指出，AI 比較像組織能力的放大器：測試、交付流程和責任邊界原本清楚，速度才容易變成成果；基礎若是一團混亂，增加產出只會讓混亂擴大得更快。
因此，受限試作的用途不是提早替上線背書，而是用一個範圍有限、可以撤回的候選版本，提早查清楚團隊若要接手，究竟得付出多少代價。
三筆成本要分開查證
候選 patch 產生得快，不代表總成本低。審查時可把代價拆成三部分，避免其中一項的漂亮數字遮住另外兩項。
| 要查的成本 | 審查時要確認什麼 | 判斷依據 |
|---|---|---|
| 產生成本 | 為了得到這個版本，補了多少背景、來回修正幾次？ | 任務範圍清楚，而且再次執行仍會得到相近做法，表示成本較可控。若每次都導向不同設計，還得持續補充只存在於口頭的背景，應先縮小問題。 |
| 審查成本 | 人能否說明修改目的、資料流向和可能的失敗方式？ | 修改集中、測試能對應需求，而且審查者知道風險所在，才適合繼續評估。若多處程式彼此牽連、測試只涵蓋正常情況，或沒有人敢移除任何一段，就不能直接接受。 |
| Ownership 成本 | 半年後誰負責維護？異常發生時能否定位、復原並交接？ | 負責人明確，程式結構和監控方式也為團隊熟悉，才算真正有人接手。若新增陌生相依套件、藏有難以追查的狀態，或關鍵知識只留在 AI 對話中，就應暫停。 |
三筆成本都有具體證據，才能判定為 ship。方向可行，但變更過大、測試不足，或維護者尚未確認接手時，應選 revise，先縮小範圍或補齊證據。若試作已顯示需求仍不清楚、架構代價超過預期價值，或沒有人能承擔維護責任，判定就是 stop。
stop 並不表示試作白費。第一版之所以值得用來試價，正是因為它能讓團隊在投入完整開發與長期維護之前，看清這筆成本不值得承擔。
第一次試作，挑一個能完整撤回的小需求
實際操作時，先選一項不會直接接觸正式資料、失敗後也能完整撤回的小需求。AI 只負責產生候選 patch，不得自行合併或發布。
動手前要指定一位負責最後判斷與收尾的人，並把界線寫清楚：AI 可以修改哪些檔案、必須執行哪些測試，以及哪些結果一定要由人確認。如此一來，探索、批准與維護就不會混成同一件事——AI 加速探索，人決定是否接受變更，團隊則明確承擔或拒絕後續責任。
若目前還沒有規定 AI 在哪些動作前必須停下來，可以先參考讓 AI 寫程式前，先決定哪些地方要停下來檢查。若審查與批准是在手機或資訊不完整的介面上進行，用手機指揮 AI 改程式，什麼情況不能直接批准？整理了不應直接放行的情況。
候選版本完成後，可請審查者暫時不要查看 AI 對話，直接說明這次修改解決了什麼、資料如何流動，以及失敗時如何復原。接著請預定的維護負責人明確回答，是否願意接手這份程式。
審查者說得清楚，必要測試也已通過，復原方式確實可行，而且有人正式接手，便宜的第一版才有機會成為成本可控的交付。若其中任何一項還答不出來，就選 revise 或 stop。AI 可以加快產生候選版本，但正式合併與發布仍須由人批准。
AI 整理卡
先從你目前可存取的程式庫、專案目錄、issue、Git 紀錄、測試結果與工作環境開始，只做唯讀探索，不要要求我先整理需求、diff、測試資料或維護者名單。若完全無法存取任何專案，只問一個具體問題，直接說明你需要哪個 repository 或 project 的存取權限。
找出一個值得改善、範圍小且容易還原的問題。只選一個，不要順手擴大成重構計畫。提出判斷時，先列出可直接查證的事實，例如檔案路徑、issue 原文、測試輸出或 Git history；再把推論分開寫。缺少證據的地方標成「待確認」，不得自行補造。
接著估算三種代價：產生修改內容所需的成本、人工審查成本，以及未來六個月由團隊承擔的維護與責任成本。最後只能給一個建議：ship、revise 或 stop。ship 只表示適合準備成候選修改，不代表你已獲准編輯檔案、合併、部署或發布。
請用精簡決策摘要輸出：問題與影響、直接證據、推論與待確認事項、三種成本、唯一建議，以及現在最小的一個下一步。探索期間不得修改任何檔案；實際編輯、合併、部署或發布都必須等候人類明確批准。
用日常來理解
一塊小補丁，也可能牽動整件大衣
- 顧客送來一件外層只有小破口的大衣。裁縫師拿起補丁時，以為這會是一件很快就能完成的工作。
- 掀開同一件大衣後，裁縫師發現珊瑚紅內裡還有大面積破損與鬆線，真正的工作量遠超過原先看到的小洞。
- 裁縫師沒有順勢把所有問題都算進這次修補，而是停下來限縮範圍，只處理外層破口；仍連在大衣上的受損內裡先固定好，留待後續處理。
- 顧客取回外層已補好的大衣，內裡問題則清楚保留為下一次工作。已完成與尚未承擔的部分沒有混在一起。
參考來源
- GitHub Blog：The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/（2026-07-17）
- DORA：State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/（2026-07-19）
- EASE 2026 / arXiv：To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/html/2605.06464v1（2026-05-07）
