週三下午，產品經理提了一個小需求：匯出報表時多一個欄位。工程師把它交給 coding agent，也就是能自己讀程式、改程式的 AI 工具，十分鐘後拿到一組修改：五個檔案，測試全部通過。看起來工作已經結束了。
但這時團隊其實還不知道幾件事：這五個檔案為什麼都要改？如果明天匯出出錯，該從哪裡查起？半年後這段程式需要更新時，誰會記得它是怎麼運作的？
GitHub 在 2026 年 7 月的一篇工程部落格文章裡，把 AI 交出的第一版修改形容為一次「試價」：它很便宜，讓團隊用很低的成本看見一個可能的解法和它的範圍。但便宜的只有「寫出來」這一段。審查它、維護它的成本並沒有因為 AI 而降低。所以，第一版不該被當成完工；它的用途是讓團隊看清楚，要接受這次修改得付多少代價。
寫出來變便宜了，其他兩筆帳沒有
一次程式修改的總成本，大致可以分成三筆。
產生的成本：花多少時間、補多少背景說明，才得到這個版本。這一筆 AI 確實大幅降低了。
審查的成本：人要花多少力氣，才能確定這次修改是對的。GitHub 那篇文章說得很直接：只有在人能有把握地驗證時，一次修改才算便宜；一個沒辦法審查的修改，只是把成本往後延。
維護的成本：半年後，有沒有人願意為這段程式的行為負責。文章作者用的檢驗問題是：六個月後，你願意擔下這個行為嗎？
後兩筆帳由誰來付？2026 年 5 月一篇被軟體工程研討會 EASE 2026 接受的研究，分析了 100 個熱門開源專案裡、由 AI 產生的一千多個檔案和約 3,200 次後續修改，發現這些 AI 寫的程式，後續絕大部分的維護工作是由人類開發者完成的。AI 交出程式之後就離開了，留下來的是團隊。
用第一版查清楚三件事
既然第一版是試價，拿到它之後該做的，是用它查清楚三件事。
修改有沒有超出範圍。 一個「多一個欄位」的需求，改了五個檔案，是合理還是 AI 順手做了別的事？GitHub 那篇文章建議看的訊號包括：修改是否擴散到好幾個模組、是否很難測試、是否需要一個新的產品決定。這些都代表這次修改比看起來貴。
審查的人能不能自己說明它。 請審查的人暫時不看 AI 的對話紀錄，直接說明：這次修改解決了什麼問題、資料怎麼流動、出錯時怎麼退回上一版。說得出來，審查成本才算真的付過了；說不出來，關鍵知識就只存在於一段對話紀錄裡。
有沒有人答應接手。 指定一位負責這段程式的人，請他明確回答：半年後這裡出問題，你願意處理嗎？這個問題比測試有沒有過更難回答，也更重要。
三件事都有答案，這次修改就可以合併。方向對但範圍太大、測試不足，就請 AI 縮小範圍重做。如果試價的結果顯示需求本身還不清楚，或沒有人願意接手，就停下來。停下來不代表試作白費：第一版的價值，正是讓團隊在投入完整開發之前，就看清這筆帳不划算。
小修改不必走這一套
這套檢查會讓小修改變慢。對一行文字修正、版本號更新這類改動，逐項確認誰來維護顯然太重了。值得這樣檢查的，是會改到資料流向、新增相依套件，或碰到計費、隱私、權限的修改；GitHub 那篇文章也特別提到，牽涉支援負擔、隱私、計費或法規的修改，不管程式碼多短，都仍然昂貴。
團隊本身的基礎，也決定了這套檢查有沒有用。長期研究軟體交付效能的 DORA 研究計畫，在 2025 年的報告裡說，AI 的主要角色是放大器，會放大組織原本的優點和缺點。測試、交付流程和責任分工原本就清楚的團隊，比較容易把 AI 的速度變成成果；這些基礎薄弱的團隊，多出來的產出只會讓混亂擴大得更快。
下一次 AI 交出第一版時，在合併之前問兩個問題：審查的人能不能不看對話紀錄說明它？有沒有人答應半年後接手？兩個答案都是「能」，再合併。如果還沒決定 AI 寫程式時哪些地方要停下來，參考〈一張 issue 能不能交給 coding agent，看你寫不寫得出第一個 diff〉。審查若是在手機這類資訊不完整的介面上進行，參考〈用手機合併 AI 改的程式之前，讓儲存庫的規則替你把關〉。
AI 整理卡
AI 剛交出一組程式修改，我想在合併前判斷它是否值得接受。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/ai-code-change-ownership-price-check/
文章的看法是：AI 讓寫出第一版變得很便宜，但審查和維護的成本沒有降低。第一版是試價，合併前要查清楚三件事：修改有沒有超出範圍、審查的人能不能不看 AI 的對話紀錄說明它、有沒有人答應半年後接手維護。
請先問我 3 個問題：
1. 原本的需求是什麼，AI 改了哪些檔案、新增了哪些相依套件；
2. 審查的人能否說明這次修改解決了什麼、資料怎麼流動、出錯時怎麼退回；
3. 這段程式有沒有指定的維護人，他是否同意接手。
根據我的回答，請輸出：
- 修改範圍是否超出需求，以及哪些部分可能是 AI 順手做的；
- 產生、審查、維護三筆成本各自的狀況，以及目前缺少的證據；
- 唯一建議：合併／縮小範圍重做／停下來，並附上理由；
- 現在可以做的一個最小下一步。
不要修改任何檔案；缺少證據的地方標成「待確認」，不要自己補。合併與否由負責這個專案的人決定。
參考來源
- GitHub Blog：The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/（2026-07-17）
- arXiv（EASE 2026）：To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/abs/2605.06464（2026-05-07）
- DORA：State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/ [accessed: 2026-10-11]
