接受 AI 程式碼成果前，如何審查實際變更
在 Mono Code 檢查變更範圍、檔案差異、暫存內容、測試證據與未決問題，附審查範本和唯讀 Git 指令。
審查儲存庫裡實際存在的程式碼，不只看代理的摘要。看似有說服力的解釋，也可能伴隨不完整修正、從未執行的測試或無關變更。接受成果前，分清楚要求的行為、真正的修改及驗證證據。
Mono Code 讓你開啟專案檔案、與程式開發代理協作，並直接在編輯器中查看 Git 變更。本文介紹如何審查一個已完成的小變更；連線方法請參考遠端程式設計指南。程式碼儲存庫和指令始終留在你自己的電腦（主機）上。Mono 還沒有正式推出，你可以加入候補名單。
1. 重新寫清楚驗收條件
以虛構情境為例：任務表單允許只有空白字元的標題。修正需求是拒絕這類輸入，同時維持一般標題的送出功能。查看修補內容前，先列出必須滿足的條件：
- 空標題與只有空白字元的標題不能送出。
- 一般標題仍能成功送出。
- 使用者會看到有幫助的驗證訊息。
- 表單其他行為仍在約定範圍內。
把這份簡短清單放在差異旁邊。這樣評估依據來自需求，而不是跟著代理的說明走。若原始請求不明確，先釐清行為，再接受更廣泛的實作。
2. 確認儲存庫狀態
確認主機、專案資料夾及分支。將變更檔案清單與代理開始前記錄的狀態比較。使用者原有修改，不會因為出現在同一個檔案，就成為代理所做的變更。
在目標主機的終端機中，可用以下唯讀指令核對：
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file請替換範例路徑。一般 git diff 顯示未暫存變更；--cached 將暫存內容與提交比較。未追蹤檔案需另外檢查。Git diff 文件解釋了這些比較。工作目錄乾淨，不代表代理沒有先做過提交；若有提交，還要查看相關歷史。
3. 閱讀修改及周圍程式碼
在 Mono 編輯器中，行號旁會標出新增和修改的行，點選標記即可開啟這部分的差異。這是查看單處變更的便利方式，但不能證明你已審查所有變更。標記缺少或過時，也不代表檔案沒有變動。
回到標題範例，找出驗證條件並追蹤後續流程。是否檢查正規化後的值？錯誤是否顯示？送出流程是否停止？應查看周圍程式碼及呼叫位置，而不是只接受孤立新增的條件。
檢查新增檔案、刪除的程式碼、相依套件及無關格式調整。簡短說明不能合理化大量未解釋差異。若文字被截斷，或修改太寬無法可靠閱讀，請改到主機或較大螢幕審查。
4. 讓測試對應行為
要求提供實際執行的指令、結果，以及略過的檢查。「測試應該會過」是預測，不是已記錄的結果。即使整組測試通過，也需要與回報缺陷相關的案例。
| 案例 | 預期觀察 |
|---|---|
| 空標題 | 停止送出，並出現預期回饋 |
| 只有空白字元 | 同樣拒絕，且不建立項目 |
| 一般標題 | 仍能正常送出 |
| 與變更無關的既有行為 | 相關既有檢查仍然通過 |
畫面回饋適合手動檢查；自動迴歸測試可以保護驗證規則。選擇能證明行為的證據，不要只寫重複實作邏輯的測試。若環境阻止測試，應明確記錄限制，並決定在哪裡完成缺少的驗證。
5. 修正問題時保留其他工作
提供明確回饋，例如：「只有空白的標題被拒絕，但錯誤標籤沒有出現」，或「請解釋這次驗證修正為何改了相依套件檔」。指出行為與檔案，不要只說「再試一次」。
存在其他工作時，不要為了移除一小段不需要的變更，使用整體重設或還原。要求針對性修正，再檢查新的差異。修正後重跑受影響的檢查；先前成功的結果不能驗證後來的編輯。
核准指令和接受程式碼是兩個決定。同意執行測試，不等於同意提交、合併或部署。審查操作本身可參考權限指南。
6. 留下可審查的交接紀錄
用簡短筆記寫下結論：
要求的行為：拒絕空白任務標題。
已審查檔案：列出實際路徑。
證據：指令、結果及相關手動檢查。
未決問題：仍未驗證的事項。
下一個決定：接受變更、要求修正，或暫緩。提交與發布操作應明確決定。若要保存討論，可匯出為 Markdown，也要保留真正的專案檔案。對話紀錄保存討論；儲存庫與已確認的檢查，才建立實際變更的證據。
