AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤

AI 程式驗收的難點，是你可能已經看到能運作的畫面，卻還不知道它是否符合原本需求，或會不會改壞其他功能。

X 上關於人工審查與測試的討論，常把問題推向二選一。實際工作裡，它們處理的資訊不同，也需要彼此補足。

人能讀需求、理解情境與判斷範圍，測試能反覆檢查已定義的行為。兩者都有看不到的地方。

如果只問測試是否全綠，就容易忽略測試本身寫錯。若只靠人看程式，也可能漏掉只有特定輸入才會發生的問題。

我建議把驗收分成需求、差異、測試與使用者操作四段，再依改動影響決定上線方式。這樣每一段都有可以檢查的結果。

先把表單修改寫成幾個可觀察的行為，後面的審查與測試才有共同標準。

AI 程式驗收，先把需求轉成可觀察行為

第一步是寫出具體觸發條件與預期結果。以表單為例，「日期空白時顯示提示，其他欄位保留，合法日期能提交」就能直接操作確認。

「修好表單」很難驗收，因為它沒有說哪個情境出錯。代理可能重做整個介面，人也可能因為外觀變漂亮就認為問題解決。

除了正常輸入，至少列一個缺漏與一個邊界情境。邊界是規則剛好改變的地方，例如日期等於截止日，或字數剛好到上限。

若規則還不清楚，先找出會改變結果的決定。截止日當天能否提交，會影響實作，不能讓代理自己猜成既定規則。

低風險的版面細節可以由工具合理處理，再由你檢視。不需要所有小決定都中斷工作，但會影響資料與權限的選擇應寫明。

把這些條件列成驗收表，後面的程式審查與測試才有共同方向。否則每個人都可能用自己的理解判斷「正常」。

人工審查先看範圍，再看程式理由

人工審查的第一個問題，是改動是否解決使用者要求的問題，並維持在同意的範圍內。先看哪些檔案被修改，再讀代理提供的原因。

如果只處理日期提示，卻改了登入、付款或資料庫結構，就要確認這些改動是否必要。範圍增加會讓驗收成本與影響範圍一起增加。

接著看資料如何流動。原始輸入在哪裡進入、哪裡被轉換、最後存到哪裡，可以幫你找出資料被默默修正或遺失的地方。

第三個問題是錯誤處理。當資料缺少或服務無法回應時，使用者看到的是清楚提示，還是沒有反應的按鈕？

這些判斷不一定需要逐行閱讀全部程式。可以要求代理指出關鍵位置，讓人沿著具體問題檢查，而不是只讀一份漂亮摘要。

但摘要不能代替實際差異。若說明表示只改兩個檔案，實際卻改了十個，應先釐清不一致，再決定是否接受。

測試能反覆確認，但要先看它測了什麼

測試是一組可重複執行的檢查。它把預期結果寫成規則，讓程式變化之後仍能快速比較。

例如空日期應顯示錯誤，合法日期應保留輸入。這些規則寫對時，測試能幫你發現某次修改把既有行為改壞。

測試全綠表示目前執行的檢查通過，並不代表所有可能情境都正確。沒有被寫進測試的需求，仍可能出問題。

AI 也可能同時寫錯實作與預期答案。此時程式符合錯誤測試，畫面卻不符合業務規則，看起來成功仍需要被人指出。

因此先讀兩三個最關鍵測試的輸入與答案，確認它們來自需求，而不是代理臨時選的行為。

如果測試只檢查函式存在，卻不檢查結果，就很難證明問題已修好。讓測試對應一個具體失敗案例，才有實際價值。

最小必要測試怎麼選？

從這次修改影響的功能開始。日期提示至少檢查空白、合法值與截止邊界，再加上原本需要保留的其他欄位。

若改動跨到資料儲存或登入，才擴大檢查相關流程。測試範圍應跟著實際影響變化，不必為小文字修改重跑整個產品。

已有測試就優先使用，也要確認它確實覆蓋問題。沒有合適測試時，再新增一個能重現問題的檢查，避免大量建立只反映程式結構的測試。

使用者操作，檢查程式之外的交付結果

使用者操作可以發現輸入、畫面與儲存之間的落差。它特別適合表單、媒體、檔案下載與後臺內容修改。

表單案例中，先在與真實使用相近的環境開啟頁面。輸入空日期，確認提示文字、焦點與其他欄位是否保留。

再輸入合法日期完成提交，重新進入資料檢視儲存結果。按鈕顯示成功，不等於後端真的保留了正確資料。

若產品有手機使用者，也要在窄螢幕檢視。功能邏輯正確，提示仍可能被裁切，或按鈕位於看不到的位置。

這一步的證據可以是操作步驟、結果紀錄與必要畫面。證據應清楚對應被驗收的版本，避免把舊截圖當成新版本的結果。

若測試環境使用的是模擬資料，回報也應說明範圍。模擬測試通過可以支援下一步，但不能自動變成正式資料已經安全的結論。

GitHub 審查與分支保護，怎麼放進流程？

GitHub 官方審查文件 說明了留言、核准與要求修改的方式，讓合併前的意見有明確狀態。

Pull request 是把一組改動提出來，讓團隊討論與合併的入口。審查意見與檢查結果可以一起保留，方便之後追查。

分支保護則能要求合併前完成指定檢查或審查。它把團隊規則放進系統，減少單靠記憶操作的遺漏。

官方分支保護文件 也說明例外與管理權限。設定規則時，應確認誰能繞過，以及是否套用到管理者。

如果制度允許某些人直接略過檢查，就要清楚瞭解這個例外。畫面上有保護規則，不等於每條合併路徑都受相同限制。

第一次可以只要求一項最相關檢查與一位合適審查者。先讓規則真的能執行，再依團隊規模與風險調整。

不同檢查抓不同錯誤，交付前一起看

下面的表格可以用來安排驗收。它說明各方法的主要用途，也提醒你保留其他方法補足缺口。

不要因為某一列通過，就省略另一列。是否需要每種方法，應由改動影響決定，而不是用「AI 寫的」一概加重所有流程。

小範圍可逆修改可以採簡短檢查，大範圍資料或權限變化則需要更完整證據。控制範圍，本身就能降低驗收難度。

逐步上線，先定義停止與回復條件

逐步上線是先讓一部分使用情境採用新版本，再觀察是否擴大。它能限制某些問題的影響，仍不能代替上線前檢查。

開始前寫清楚要看什麼。表單案例可以觀察提交成功率、日期錯誤與客服反映，避免只有「看起來還好」的印象。

再定義何時停止。例如出現已確認的資料遺失，就先暫停擴大範圍。不要等到所有指標都惡化才處理。

回復也要有可用版本與操作方式。若改動涉及資料結構，單純換回程式可能不夠，應在上線前確認資料相容性。

負責觀察的人與負責回復的人應明確。若出現異常時沒有人知道下一步，逐步上線的保護效果就會降低。

對於一次性本機工具，可能不需要複雜上線系統。保留原檔案副本與可恢復版本，就能建立合適的完成邊界。

範例：日期修正的驗收證據怎麼留？

先記錄修改前，空日期會直接提交的問題。這份紀錄應包含重現步驟與輸入，讓其他人確認同樣問題。

修改後對照三個結果：空白顯示提示、合法值可提交、其他欄位保持。每個結果都應有對應操作與版本。

再讀回儲存資料，確認沒有自動插入今天日期。這個檢查能抓到畫面看似正常、後端卻默默補值的問題。

如果只在測試環境確認，就將結果標為測試環境通過。正式上線與真實資料檢查應另外記錄，避免報告混淆不同完成點。

最後儲存改動差異與剩餘限制。例如尚未處理跨時區日期，就寫清楚範圍，讓下一項任務能從這裡接續。

這份紀錄不必很長，但應讓另一個人能重現。可重現的證據，比「代理已反覆檢查」更容易支援交付決定。

新增測試之前，先確認舊錯誤真的能被抓到

假設修正前輸入空日期仍能提交，測試卻一直通過。先讓測試針對這個行為失敗，才能確認它真的覆蓋原問題。

如果修改前後都通過，就檢查測試是否呼叫了正確路徑。它可能只測了一個未被實際頁面使用的函式，或用到不相關的模擬資料。

再檢查預期結果是不是來自需求。若測試寫成「空日期自動補今天」，它可能驗證了未經授權的行為，需要先修正規則。

當測試能在舊版發現問題、在新版確認修正，就有更明確的證據。仍要補使用者操作，檢查畫面與儲存結果是否接上同一條路徑。

這類測試不需要很多，重要的是能抓到具體失誤。把輸入、預期與失敗原因寫清楚，之後才容易維護。

若程式碼無法直接重現舊版，也應說明驗證限制。不要為了報告漂亮，把沒有檢查的步驟寫成已經通過。

交付報告如何避免讀者誤解？

先寫實際完成的結果，再寫檢查範圍。例如「日期提示已修正，測試環境三項操作通過，尚未執行正式釋出」。

如果只做程式碼審查，就寫審查結果與發現，不把它擴大為真實使用者已經使用成功。不同證據支援的結論範圍應保持一致。

剩餘問題也寫成具體情境。比如「未驗證跨時區日期」，比「可能有風險」更容易讓下一位決定是否需要擴大檢查。

最後提供可回看的版本與結果位置。報告不需要包含全部終端機輸出，但應讓接手者找到關鍵證據並復現檢查。

AI 程式驗收常見問題

非工程師能參與驗收嗎？

可以從需求、操作與儲存結果開始。程式細節可請工程師協助，但你仍能確認業務規則、畫面與實際資料是否符合目的。

測試全綠，為什麼還不能說完全安全？

測試只覆蓋已定義與已執行的條件。遺漏情境、錯誤預期與環境差異仍可能存在，因此結論應說明實際檢查的範圍。

人工審查一定比 AI 審查可靠嗎？

不能只由身分決定可靠程度。重點是能否指出具體問題與證據，AI 可以幫助找線索，人則負責判斷需求與交付範圍。

讓驗收結果對應實際交付

AI 程式驗收的價值，是把漂亮成品與可接受的行為連結起來。每次檢查都應能說明看了哪一版、哪個情境，以及看見什麼結果。

先挑目前一項修改，把需求、差異、測試與操作各留一份最小證據。確認儲存結果後，再依實際影響決定是否上線與擴大觀察。

延伸閱讀：GitHub ReviewBench 發布：AI 程式審查怎麼比，才能找到問題又不淹沒工程師？

延伸閱讀：Bun 1.4.3 加入 bun check：AI 寫完程式，先檢查型別再執行

資料來源

產品資訊依 第一手來源 與 官方補充文件 整理，功能與條款查核日期為 2026 年 10 月 12 日。

討論線索來自 X 原始貼文。本文操作案例是供讀者採用的練習流程，未宣稱已替讀者完成產品實測。