AI Agent / DevOps / Production

AI 說「部署完成」時，我只問：證據在哪裡？

process 已啟動、port 在 listen、CI 是綠的、git push 成功、網址回 200——這些都可能是真的，但使用者仍然拿不到正確功能。這份 Production Definition of Done（正式環境完成定義）把每一層證據、未知狀態與 rollback（回復）寫成可重複執行的 gate。

2026 年 8 月 13 日 · 約 9 分鐘 · 免費 Markdown 範本

開啟免費上線檢查表產生器下載 Markdown 範本先在瀏覽器查看

最小判定：production 完成不是某一個工具顯示綠燈，而是「這次要交付的使用者結果」在正確環境有直接證據。沒有權限或量測時，狀態是 NOT_MEASURED，不是靠推理補成 PASS。

五種最常見的假綠燈

看到的綠燈	它真正證明的事	還缺什麼
`process started`	建立程序的命令沒有立刻報錯	程序持續存活、沒有 crash loop、確實完成初始化
`port listening`	某個 process 擁有 socket	擁有者正確、依賴可用、已準備接真實流量
`HTTP 200`	這次 HTTP request 成功取得 response	Content-Type、body marker、版本、權限與使用流程正確
`CI green`	該 workflow 的檢查通過	執行 SHA 正確、部署 revision 更新、正式環境仍正常
`git push succeeded`	remote 接受 commit	部署系統採用該 commit，公開環境已切到新版本

這不是語意挑剔。Google SRE 的監控章節把「回 200 但內容錯誤」直接列為 implicit error（隱性錯誤），並指出這種問題可能只有 end-to-end test（端到端測試）抓得到。本站也真的遇過 sitemap 回 200，正文卻只是 React 首頁的案例。

真正的完成證據有八層

Artifact identity（成品身分）：local commit、remote SHA、部署 revision／image digest 與實際 artifact 能互相對上。
Control plane（控制面）：CI、雲端部署、環境設定、scheduler 與 queue 指向本次版本，不是只看其中一張綠燈。
Runtime readiness（執行期就緒）：程序存活、預期 listener 的擁有者正確，readiness 還要驗依賴與接流量能力。
Public HTTP／network：從外部網路檢查 DNS、TLS、status、Content-Type、唯一 body marker 與 redirect。
User journey／UI：真實瀏覽器完成核心流程，手機沒有阻擋性跑版，console／network 沒有本次造成的錯誤。
Data and side effects（資料與副作用）：migration、retry、webhook、queue 與對外訊息不會重複或消失。
Observability（可觀測性）：有部署前 baseline，能看 latency、traffic、errors、saturation，觀察窗涵蓋有意義的工作週期。
Rollback and recovery：知道退回哪個 artifact、什麼條件觸發、資料是否相容，而且 rollback 後重新跑驗證。

liveness 不等於 readiness

Kubernetes 官方把三種 probe（探針）分開：startup 確認應用完成啟動，liveness 判斷是否需要重啟，readiness 判斷是否準備好接收流量。readiness 失敗時，Pod 會停止從相符 Service 接流量，但 container 可以繼續運行。

即使不用 Kubernetes，這個模型仍然好用：活著、啟動完、能服務是三個問題。若 App 必須連資料庫才能工作，單純 TCP port 開著不能證明 readiness。

狀態必須容納未知，不然 AI 會替你腦補

PASS本次直接驗證通過。

FAIL已執行，確定失敗。

WAITING外部系統正常處理中。

NOT_MEASURED缺少權限、工具或資料。

NOT_APPLICABLE有理由證明不適用。

WAITING 與 NOT_MEASURED 特別重要。Search Console 還在處理 sitemap，不等於失敗；沒有 Analytics 權限，也不能把流量寫成 0 或「看起來有成長」。模板要求最後摘要把未量測範圍說清楚。

範本怎麼使用

下載後，把檔案放進 repo 的 docs／ops 目錄，或直接貼給執行任務的 Agent。先填 release contract（發布契約），再要求它逐項留下 command、URL、SHA、時間窗或 readback（回讀）證據。

請依這份 Production Definition of Done 驗收本次 release。

規則：
- 不得以 process、port、HTTP 200、CI 或 push 單一訊號判定完成。
- 每個 PASS 都要附本次執行的 evidence。
- 缺權限就填 NOT_MEASURED，不得推論。
- 任何外部 mutation 必須在 authorized mutations 內。
- 最後只輸出 PASS / FAIL / PARTIAL / WAITING 與剩餘風險。

完整版本已包含 release identity、control plane、runtime、HTTP、UI、資料副作用、監控、rollback 與 final verdict。可以先用AI Agent 上線檢查表產生器建立判決報告，或直接下載 Markdown；兩者都不需要留下 email。

三種產品，完成證據不一樣

靜態網站或 SPA

remote SHA 與部署 revision 一致；公開 URL 的 Content-Type、body marker、canonical、robots、sitemap 都正確；桌機與手機真的渲染，而且不是 SPA fallback 冒充內容頁。可參考本站的 Cloudflare React SPA SEO 修復。

API 或長駐服務

程序持續存活、listener 屬於預期 process、readiness 會檢查必要依賴；核心 API 有正向與負向測試，auth／付款／資料路徑 fail closed。不能只在本機 curl localhost。

排程、AI Agent 或媒體產線

scheduler enabled 只證明排程開著；還要看最新一次 run、log、output artifact、hash，以及目標端是否真的收到。若工作單位是 20 分鐘影片，觀察窗至少要涵蓋一個實際工作週期，不能跑 30 秒就宣稱穩定。

監控不是「有 dashboard」就好

Google SRE 建議優先關注 latency、traffic、errors、saturation 四個 golden signals（黃金訊號）。若用 canary（小流量版本），還要把 canary 與 control 的訊號分開；只看全站平均，少量高錯誤率可能被總體數字稀釋。

模板沒有強迫每個小網站建一套 SRE 平台。低風險靜態頁可以用公開 HTTP、瀏覽器、console 與簡單流量基準；付款、個資、migration 或大量 background jobs（背景工作）則需要更嚴格的觀察與 rollback。

哪些事情不能讓 Agent 自己擴權

付費、退款、實刷與新增計費資源。
刪除 production 資料、bucket、資料庫或不可逆 migration。
IAM、OAuth scope、帳號角色與公開存取權限。
對外發布貼文、寄信、送出表單、提交 sitemap 或 request indexing。

「production 完成定義」的目的不是給 Agent 無限權限，而是讓它在已授權範圍內做到可驗證，遇到需要新 authority（授權）的步驟就明確停下。角色分工可搭配 Claude Code 與 Codex 決策矩陣。

想把 AI 產出的「完成」變成可驗收交付？

不油膩數位工作室做 Web、App、AI Agent 與自動化，也會把測試、部署、監控、權限邊界與正式環境證據一起交付。

下載免費 Markdown 範本，或聯絡工作室。