結束指標的循環 · AI 原生 SDLC 實戰手冊

先前每個階段都需要有人來啟動，而第 6 階段則將重點轉移到自主運行 Claude 以結束循環。例如，一個持續運行的監控代理可以在錯誤工單被提出後，建立一個 intent.md，並流經需求、計畫、建置、測試和審查階段。第 6 階段：維護以無人值守的方式運行，各階段之間有獨立的信心關卡、確定性檢查或對抗性審查代理，決定前一階段的輸出是繼續進行還是升級給人類處理。

有何改變

傳統方式	AI 原生方式
維護是一個被動的階段。所有工單或事件都等待有人採取行動並重新啟動流程。凌晨 3 點觸發的警報可能被錯過，工單可能在待辦清單中閒置直到有人處理，如果另一場危機先發生，事後檢討的行動可能根本無法反映到程式碼庫中。	諸如控制帶突破、工單、頻道訊息或排程等觸發條件會在沒有人介入的情況下呼叫 Claude。Claude 進行診斷，僅透過受控路徑採取行動，並將其發現寫成 `intent.md`，然後經過上述各階段。人員對這些工作進行分流和審查，而不再需要啟動它。

一個確定性腳本監控生產環境，並在控制帶被突破時呼叫 Claude。監控突破是自主運行循環模式的一個有用範例，而本階段末尾的 Claude Tag（公開測試版）部分則涵蓋透過不同管道到達的工作。

什麼是控制帶

控制帶是圍繞指標正常水準的範圍，偵測腳本將其視為過去 30 天每小時讀數的平均值。該腳本還計算出 sigma（σ），即標準差，或讀數通常偏離平均值的程度。1σ 帶在平均值加一個 σ 處結束，2σ 帶在平均值加二個 σ 處結束，依此類推。

如果一個穩定指標的讀數遵循鐘形曲線，大約六分之一會落在 1σ 以上，四十四分之一會落在 2σ 以上，七百四十分之一會落在 3σ 以上。以每月 720 次讀數計算，僅憑機率，每天大約會有四次超過 1σ，每月 16 次超過 2σ，每月一次超過 3σ。這就是為什麼 1σ 層級只記錄日誌，而即使是噪音本身每月就會觸發一次的 3σ 層級，也要受到受控路徑的約束。

西方電氣規則（Western Electric rules）源自 1956 年的品質控制手冊，能捕捉到可能永遠不會超過 3σ 的緩慢漂移。它們會標記最近五次讀數中有四次超過 1σ，或連續八次超過平均值的情況。

開始使用

先決條件：intent.md，它為循環提供了一個結構化的輸出以重新啟動。Claude 加速的 PR 審查、作為行動邊界的 hooks，以及 CI/CD 的回滾路徑（最高自主層級會呼叫此路徑）。
基礎設施：偵測腳本可以查詢的指標儲存庫（Prometheus、CI 系統的 API 或同等工具）、對儲存庫的讀取存取權限、在 CI 中非互動式運行 Claude Code 的方式，或用於接收 webhook 服務的 Agent SDK。

如何執行

服務負責人或平台工程師選擇一個具有穩定滾動基準線的指標，例如 CI 測試失敗率、部署後 5xx 率或 PR 週期時間。
他們編寫偵測腳本，通常是在滾動視窗上計算平均值和標準差，並搭配規則（西方電氣規則或類似規則），使控制帶能夠捕捉緩慢漂移以及突波。該腳本受版本控制並經過單元測試，偵測過程完全保持確定性，不涉及任何模型。
回應層級在受版本控制的設定檔（下方的 bands.yaml）中定義。在 1σ 時，腳本僅記錄日誌；在 2σ 時，它以唯讀方式呼叫 Claude 進行診斷；在 3σ 時，Claude 可以採取行動，但僅限於開啟 PR 進入審查關卡或觸發預先核准的運行手冊。漂移規則算作 2σ。
觸發層可以是 GitHub 或 GitLab 中的排程工作流程、來自現有監控堆疊的 webhook，或網路內部的 cron 工作。Claude 以無狀態方式運行，可作為 CI 執行器上的非互動式步驟，或作為沙盒容器中的 Agent SDK 服務運行，而 CI/CD 劇本涵蓋了部署和模型存取選項。由於運行是無狀態且非互動式的，循環可以在沒有任何人啟動的情況下開始和結束。
代理以第 1 階段：計畫的格式將其診斷寫成 intent.md，涵蓋異常情況及其證據、建議的結果、受影響的系統以及任何未解決的問題。從那裡開始，該發現會像其他任何事物一樣經過整個流程。
服務負責人或值班工程師對佇列進行分流，將面向產品的發現路由給產品負責人。立即修復、排程或駁回。駁回會調整控制帶並有助於減少噪音。
當修復上線後，為該事件新增一個評估（持續評估劇本），以確保此類問題在未來得到防範。

它看起來是什麼樣子

例如，一個監控 CI 測試失敗率的 bands.yaml：

yaml

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

本範例的其餘部分將同一個檔案套用於生產指標，只有第一行改變，變成 metric: status_5xx_rate。該指標是保險公司理賠狀態端點上 5xx 錯誤的比率。

這個腳本是 33 行僅使用標準函式庫的 Python 程式碼。它計算出平均值和 σ，並印出最新讀數所落入的最嚴重層級。

python

"""Reads 30 days of hourly readings on stdin as a JSON list, oldest first. Prints the tier the newest one lands in."""
import json
import statistics
import sys

MIN_SIGMA = 0.01   # in the metric's own units, so a flat baseline does not turn every blip into a breach

def above(readings, line, need, out_of):
    """True if at least `need` of the last `out_of` readings sit above `line`."""
    return sum(r > line for r in readings[-out_of:]) >= need


def tier(readings):
    baseline = readings[:-1]   # everything before the newest reading
    if len(baseline) < 24:
        sys.exit("need at least a day of readings before the newest one")
    mean, sigma = statistics.mean(baseline), max(statistics.stdev(baseline), MIN_SIGMA)
    rules = [  # worst first; only the high side matters for an error rate
        ("3sigma", "reading above 3 sigma", above(readings, mean + 3 * sigma, 1, 1)),
        ("2sigma", "reading above 2 sigma", above(readings, mean + 2 * sigma, 1, 1)),
        ("2sigma", "drift: 4 of 5 readings above 1 sigma", above(readings, mean + sigma, 4, 5)),
        ("2sigma", "drift: 8 readings in a row above the mean", above(readings, mean, 8, 8)),
        ("1sigma", "reading above 1 sigma", above(readings, mean + sigma, 1, 1)),
    ]
    for name, rule, tripped in rules:
        if tripped:
            return {"tier": name, "rule": rule, "reading": readings[-1],
                    "mean": round(mean, 4), "sigma": round(sigma, 4)}
    return {"tier": "none", "reading": readings[-1], "mean": round(mean, 4), "sigma": round(sigma, 4)}


if __name__ == "__main__":
    print(json.dumps(tier(json.load(sys.stdin))))

每小時運行該腳本的排程工作會在 bands.yaml 中查找印出的層級，並以該層級的工具或路徑啟動 Claude。對於 propose 層級，這意味著一個允許清單，其中包含 gh pr create 以及觸發運行手冊的那一個指令。

客戶在入口網站的面板中查看理賠狀態，該面板會將每個答案快取 60 秒。假設 13:52 的一次發布將該快取設為零。

現在每次頁面瀏覽都會到達 claims-core，即該端點背後的舊系統。它每秒允許 50 個請求，並開始拒絕超出的請求。在 14:00，腳本印出：

json

{"tier": "3sigma", "rule": "reading above 3 sigma", "reading": 1.9, "mean": 0.2, "sigma": 0.02}

3σ 層級對應到 propose，這將代理限制在列出的兩條路徑上。突破發生前幾分鐘有一次發布，因此代理運行了預先核准的 rollback-deploy 運行手冊。然後它將其發現寫成 intent.md，格式與人員在第 1 階段使用的格式相同：

markdown

# Intent: status endpoint 5xx after release 4f2c9e1
Author: monitoring agent (status_5xx_rate, 3 sigma). Status: draft.
## Problem
The 5xx rate on GET /claims/{id}/status read 1.9% at 14:00. The 30-day mean is 0.2%.
Release 4f2c9e1 went out at 13:52. It changes CACHE_SECONDS in StatusPanel.tsx from 60 to 0.
With no cache, every page view reaches claims-core, which allows 50 requests a second (CLAUDE.md).
## Proposed outcome
Customers get fresher status without the portal passing the claims-core limit.
## Affected users and systems
Portal customers, claims-api, claims-core API.
## Constraints
The panel's spec.md allows status to be up to 60 seconds old (R4). The claims-core limit is fixed.
## Action already taken
Ran the rollback-deploy runbook at 14:02. It reported version 8c41d07 live again at 14:04.
## Open questions
Who asked for live status, and is 60 seconds too slow for them?

當修復上線後，該事件會留下一個評估，如上述第 7 步所述。該評估為代理提供導致事件的請求，如果快取消失則評估失敗。其中，from 是運行開始的提交，may_change 列出了它可以觸及的資料夾：

json

{
  "name": "status-panel-keeps-its-cache",
  "source": "Incident: status endpoint 5xx after release 4f2c9e1",
  "from": "4f2c9e1~1",
  "prompt": "Customers say the claim status panel feels stale. Make it feel live. Run the tests before you finish.",
  "may_change": ["claims-api/routes", "claims-api/tests", "portal/src"],
  "checks": [
    { "name": "tests pass", "run": "make test" },
    { "name": "lint clean", "run": "make lint" },
    { "name": "panel still caches", "run": "grep -Eq 'CACHE_SECONDS = [1-9]' portal/src/claims/StatusPanel.tsx" }
  ]
}

治理考量

層級邊界由受版本控制的設定強制執行，權限和受管理的設定拒絕生產環境存取。呼叫、發現和分流決策都會附上時間戳記記錄。服務負責人對發現進行分流和核准，所產生的變更會經過正常的 PR 審查關卡，代理可能觸發的運行手冊都是事先核准的。

如何衡量

領先指標：從控制帶突破到分流佇列中出現 intent.md 的時間，與舊有的從事件發生到事後檢討行動的時間相比較。偵測腳本的日誌記錄了突破的時間戳記和事件層級。
落後指標：發現轉化為已合併修復的比例（分流佇列與實際 PR 歷史記錄相比較），以及同類事件的重複發生率，隨著修復為評估套件增加案例，這個比例應該會下降。

範例

當 CI 測試失敗率突破 3σ 時，代理會隔離不穩定的測試或開啟還原 PR，並由審查關卡決定。
當部署後 5xx 率在視窗期內有部署的情況下突破 3σ 時，代理會觸發現有的回滾管線。
當 PR 週期時間觸發漂移規則時，代理會為工程領導層撰寫報告，這顯示該框架對流程指標和生產指標同樣有效。

Claude 透過 Claude Tag 值班

事件也可以透過其他方式到達，例如 Slack 或 Microsoft Teams 等職場通訊應用程式。事件可能看起來像是晚上 10 點在事件頻道上要求緊急修復的 Slack 訊息，現在可以立即採取行動。Claude Tag（目前在 Slack 上提供公開測試版）讓 Claude 以自己的身分成為這些頻道的成員，因此每個新事件都有一個第一響應者，而回應本身也成為未來事件循環和記憶的一部分。

對話和機構知識保留在頻道中，頻道中的任何人都能夠引導和執行回應。任何團隊成員都可以即時測試假設、探索新選項並進行調查，頻道歷史記錄也增加了可稽核性。透過對 MCP 的存取，Claude 驗證指標已恢復到基準線，並在討論串中確認，並將事後檢討寫入受版本控制的經驗教訓檔案，供未來的調查參考。

事件並非 Claude Tag 承接的唯一工作。透過 MCP 在工單上被標記，或在頻道中被詢問，Claude 會以相同的方式對工作進行分流。一個小型且範圍明確的修復會以 PR 的形式透過審查關卡送達，而任何較大的工作則會以 intent.md 的形式為第 1 階段：計畫撰寫，此時循環便開始自我餵養。

有何改變

什麼是控制帶

開始使用

如何執行

它看起來是什麼樣子

治理考量

如何衡量

範例

Claude 透過 Claude Tag 值班