AI工程管理怎麼做？Change Budget、CI、Review Queue、Release Gate與Incident

AI 工程管理的核心：把生成速度接到交付證據

當 Coding Agent 能在幾分鐘內修改很多檔案，團隊的限制通常不再是「能不能產生程式碼」，而是能不能理解、測試、審查、發布和監控這些變更。沒有驗收的 Generated 只是活動量；經過人類理解的 Reviewed、通過測試的 Tested、符合安全與風險條件的 Verified，以及已經上線並持續觀察的 Deployed，代表不同責任狀態，不能在報表中混成一個完成數字。

工程吞吐應該計算已接受、已驗證的變更除以完整經過時間，而不是計算 Agent 產生了多少行、多少 Commit 或多少 Prompt。大型 Diff 可能讓模型看似高產，卻把 Context Reconstruction、Review、CI、返工和 Rollback 成本推給下游。AI 導入後第一個管理動作，不是無限制增加 Agent，而是量出 Review Capacity、CI 吞吐、Integration 容量和事故恢復能力。

本篇把 Change Budget、Small PR、AI Change Manifest、CI、Code Owner、Release Gate、Canary、Observability 與 Incident 串成一條可驗證的工程流程。安全與供應鏈背景可對照 NIST AI Risk Management Framework、GitHub Protected Branches與 SLSA Build Levels。這些框架不能取代產品自己的驗收，但能幫助團隊把責任、證據與閘門分層。

Change Budget：限制同一時間可承受的變更風險

Change Budget 是團隊在一段時間內能同時承受的修改量與風險，可以用 Active PR 數、修改檔案數、Service 數、Migration 數、Review Hour、CI 分鐘或風險分數表示。它不是禁止開發，而是避免新變更超過下游理解和驗證能力。當 Review Queue 超過門檻，就暫停新生成，先清空待審工作；發生 Production Incident 時，凍結非必要變更；高風險期間則降低 Agent 權限與可觸碰範圍。

不同變更類型應有不同預算。文件和測試資料可以允許較多小 PR；一般功能按 Domain 限制同時進行的 Active PR；Authentication、Payment、Privacy 和 Infrastructure 可能一次只允許一個高風險變更；Database Migration 則把 Schema、Backfill、切換與清理拆開，讓每一步都能觀察和回退。若同一個 Change 同時包含 Refactor、Feature、Migration 和 Workflow 修改，應先拆分，而不是用更長的 Review 清單掩蓋範圍。

Change Budget 也要有明確的消耗與恢復規則。例如一次高風險變更消耗較多預算，通過 Canary、監控窗口和回退演練後才釋放；事故或未解決的 Defect Escape 會暫時降低可用預算。這讓「慢一點」有可量化原因，也能防止管理者只用 Agent 產量要求團隊加速。

Small PR：降低 Context Reconstruction 和回退成本

Small PR 不只是限制行數，而是限制認知範圍。一個 PR 應該有一個主要 Task、明確的 Acceptance Criteria、可讀的影響範圍、失敗測試、修改理由和 Rollback 方法。Refactor 與新功能分開；自動格式化、Generated File 與行為修改分開；資料庫變更和應用程式切換分開。Reviewer 才能回答「這次改動解決了什麼、可能破壞什麼、如何證明、如何回復」。

AI 參與的 PR 也應清楚列出模型或 Agent 類型、使用的 Instructions 版本、工具範圍、是否讀取外部來源、已知風險與人類 Owner。這不是為了追蹤誰該被責怪，而是事故時能還原變更路徑。若團隊不記錄 Context 和工具，發生缺陷時只能猜測模型看過什麼、做過什麼，無法改善下一輪規則。

小 PR 仍然需要一致的分支與提交規則。不要讓 Agent 為了「保持綠燈」而刪除測試、放寬 Required Check 或修改 Branch Protection；一旦發現變更碰到不在 Write Scope 的 Workflow、權限或部署設定，應先標記為需要專門 Review。

AI Change Manifest：把一次生成變成可追蹤事件

一份可用的 Manifest 至少包含 Task ID、目標 Scope、模型與版本、Instructions 或規則版本、可用工具、修改檔案、測試命令、已知風險、人類 Owner、需要的 Approval 和 Rollback。若包含外部資料，還要記錄來源時間、輸入識別碼與資料政策。這份紀錄應與 PR 或 Artifact 綁定，而不是只留在不可查找的對話視窗。

Manifest 的功能是支援審查和回放。Reviewer 可以知道 Agent 的輸入和權限是否足夠；事故處理者可以知道是哪個版本、哪次工具呼叫、哪一項核准導致變更；管理者可以比較不同模型與流程的 Defect Escape、Rework 和 Cost。敏感值仍必須遮罩，Token、Cookie、客戶資料和秘密不能放進 Commit、Issue、Log 或截圖。

CI 與 Risk-based Review：讓檢查強度跟風險走

每個 PR 至少要有 Build、Type Check、Lint、Formatting 和必要 Unit Test；跨模組變更再加入 Integration、Contract 或選定的 E2E。依賴、License、Secret、SAST、Container 和生成 Artifact 也應按風險納入。Authentication、Payment、Privacy、Infrastructure、Migration 和 CI Workflow 的變更，應由相應 Code Owner 或安全 Reviewer 參與，而不是把所有責任丟給一般 Reviewer。

Required Checks 應由分支保護與發布系統強制執行。Agent 不得透過改 Workflow、降低門檻、跳過測試或自動批准自己的 PR 繞過 Gate。若 CI 失敗是環境問題，應明確標記為 Blocked 並處理環境；不能把「重跑終於變綠」當成程式碼已被證明正確。測試結果要保存 Artifact、版本、輸入和時間，讓後續 Review 能重現。

風險式審查比每個 PR 都套一樣的流程更有效。低風險文件可以快速通過；核心邏輯、資料處理和權限變更需要更完整的測試與 Owner 審查；不可逆資料動作則應有 Dry Run、備份、雙人核准和清楚的回復方式。Agent 可以產生候選 Patch，但不能依風險等級自行授予自己更高權限。

Release Gate：發布前要同時證明可用與可回復

Release Gate 的條件可以包括 Required Review、CI Required Checks、Security Gate、Migration 測試、Rollback Ready 和 Observability Ready。Feature Flag、Canary、小比例流量、SLO、Error Budget、Kill Switch 和 Manual Runbook 應在發布前準備，而不是事故後才尋找。對應用程式和資料庫，還要確認向前與向後相容，避免只回退程式碼卻留下不能讀取的資料格式。

Canary 的重點不是把一小部分使用者當成實驗品，而是限制影響範圍並定義停止條件。發布前寫清楚錯誤率、延遲、資源使用、關鍵業務指標和資料完整性的可接受範圍；超過門檻就停止擴大或回退。Observability 至少要能把版本、變更 ID、請求、錯誤和重要業務事件連起來，否則看到數字變差時仍不知道是哪個變更造成。

供應鏈也要納入 Release Gate。建置來源、依賴、Artifact 和部署結果要能互相對應；高風險系統應保存 provenance、簽章或可驗證的建置紀錄。SLSA 文件提供不同建置與 provenance 保護層級的概念，但實際選擇仍要依團隊的威脅模型、部署方式和合規要求決定。

Incident：錯誤發生後先控制影響，再追查生成路徑

Incident 的第一步是停止擴散：暫停新流量、關閉 Feature Flag、切回舊流程或啟動 Kill Switch；第二步是保存事件鏈，包括版本、Commit、Agent、Model、Tools、Approval、測試、部署和監控；第三步確認資料、客戶、安全和供應鏈影響；第四步在修復後以 Canary 重新上線。Rollback 是技術動作，Postmortem 則要回答為什麼原本的 Change、Review 或 Gate 沒有攔住問題。

Postmortem 不應只寫「模型寫錯」。需要分類是需求不清、Context 缺失、工具權限過大、測試覆蓋不足、Reviewer 無法重建狀態、CI 失效、監控缺失，還是 Release Gate 被繞過。修復可能包括更新 Instructions、增加負面測試、收緊 Tool Scope、改變 Change Budget、補 Code Owner、調整 Canary 門檻或停用某種自動化路徑。

用正確指標管理 AI 工程

Lead Time、Change Failure Rate、恢復時間、Review Latency、Rework Rate、Defect Escape、WIP、Integration Failure 和 Cost per Accepted Change，比 Generated Lines、Prompt 數、Commit 數和 Agent 完成數更接近真實交付。管理者應同時看速度、品質、風險和恢復能力；如果產量提高但 Review Queue、事故和人工返工一起上升，系統並沒有變快。

建議建立一個小型對照基準：固定一批真實任務，記錄單一 Agent、受限 Agent 和人工流程的 Cycle Time、Acceptance、CI 成本、Review 時間與事故結果。模型或 Harness 更新後重跑同一批，確認收益來自穩定流程而不是一次漂亮 Demo。對高風險任務，也要保留人工接管率與未測試範圍，避免平均值掩蓋尾端風險。

把風險管理放進日常交付，而不是只做年度文件

NIST AI RMF 可以當作管理 AI 變更的思考框架：先治理責任與政策，再辨識使用情境、資料、使用者與可能傷害，接著衡量品質、安全、隱私、可靠性與可解釋性，最後管理剩餘風險與持續監控。對工程團隊來說，這些概念可以落在 Change Manifest、Code Owner、測試、發布閘門和 Incident 記錄中，而不是另外建立一套沒有人閱讀的報告。

例如新增一個會讀取客戶資料的 Agent 工具時，治理問題是誰批准與誰負責；辨識問題是它會讀到哪些資料、能否被提示注入影響、錯誤會造成什麼傷害；衡量問題是要用什麼測試、抽樣和監控判斷安全；管理問題則是最小權限、遮罩、Kill Switch、Audit Log 和回退。只要這些問題沒有答案，就不應把變更標成 Verified。

風險也會隨環境變化。模型更新、工具新增、資料來源改變、使用者族群改變或流量擴大，都可能讓原先的測試不再代表真實情境。因此 Release Gate 通過不代表永久安全；應設定重新評估觸發條件，保存失敗樣本與異常事件，並在重大更新後重新跑 Evals。管理流程的成熟度，表現在能否把監控結果回寫到規則與測試，而不是能否提出一份漂亮的架構圖。

每個發布證據包可以固定保存變更 ID、Base Commit、模型與規則版本、修改檔案、測試與掃描結果、Review 身分、Artifact 雜湊、Feature Flag、Canary 指標、監控時間窗和 Rollback 決定。事故後再把實際影響、修復版本、回復時間與新增測試連回同一個變更 ID。這樣團隊能從一個變更追到一個部署，再追到一個結果，不必依賴記憶或零散聊天紀錄。

也不要把綠色 CI、PR 數量或模型自評當成完整成功。CI 可能沒有覆蓋真實資料，PR 可能只是拆得更碎，模型也可能忽略沒有寫進提示的風險。只有外部驗收、監控窗口、人工責任與可回復證據一起成立，才可以把變更從 Verified 推進到 Deployed。

回退測試也要實際演練，確認舊版本仍能啟動、資料格式可讀、旗標能關閉、監控能辨識回退，以及值班人員知道何時停止擴大流量。沒有演練過的 Rollback 只能算計畫，不能算證據，不能算正式完成與安全長期交付，也是可靠工程底線與穩定承諾。

把自動化邊界寫成核准矩陣

不同變更需要不同核准人與證據。文件、測試和低風險重複修正，可以由一般 Reviewer 加上自動測試處理；商業邏輯、資料處理和公共 API，需要熟悉 Domain 的 Owner 確認行為與相容性；Authentication、Payment、Privacy、Infrastructure 和 Migration，則需要專責 Reviewer、明確的測試資料、備份、Dry Run 與 Rollback 演練。Agent 可以準備差異與風險摘要，但不能把「測試通過」解讀成「所有責任已被批准」。

核准矩陣還要定義自動化能做的事與必須停下來的事。自動化可以建立分支、執行本機測試、產生報表和提出 Patch；涉及秘密、正式資料、公開發布、權限提升、刪除、付款、不可逆 Migration 或修改保護規則時，必須轉入人工核准。若輸入含有外部指令、權限狀態改變或測試結果互相矛盾，也要暫停並保留事件證據。這些邊界讓速度與責任同時存在。

核准不是最後一個按鈕，而是一次可驗證的決策。核准後仍要重新讀取實際 Diff、測試結果、部署版本和監控狀態，確認沒有新的變更或環境漂移；若 read-back 與核准內容不一致，就回到 Review，不得以先前的批准覆蓋新風險。

最小可落地流程

第一步建立 Change Manifest 和風險分類；第二步按照 Change Budget 拆成 Small PR；第三步用最小權限讓 Agent 產生 Patch；第四步跑 Required CI、Security Scan 和對應 Owner Review；第五步以 Feature Flag 或 Canary 發布；第六步檢查 Observability 與 Error Budget；第七步在超過門檻時停止或 Rollback；第八步把結果、事故和人工修正回寫到測試、Policy 與 Agent 規則。每一步都要有具名 Owner 和可讀證據。

這個流程的價值不在於增加表格，而在於讓團隊知道目前變更處於 Generated、Reviewed、Tested、Verified 還是 Deployed，知道下一個 Gate 是什麼，也知道失敗時能退回哪一個穩定版本。AI 工程的速度只有在這些狀態清楚時，才會轉成可持續的交付能力。

結論：管理變更流，而不是追逐生成量

AI 工程管理要控制的是變更流與風險邊界，不是壓低模型使用。Change Budget 限制同時承受的工作，Small PR 降低理解和回退成本，Manifest 保留生成路徑，CI 與 Code Owner 提供外部驗收，Release Gate 把 Canary、Observability 和 Rollback 接起來，Incident 與 Postmortem 則把失敗轉成流程改進。當 Generated 不再被誤稱為 Deployed，Agent 的速度才有機會真正提升工程吞吐。