一、先想清楚：CI/CD 里哪些環節值得交給模型

把 Codex 接進流水線之前，先要回答一個問題：哪些環節真的適合自動化？判斷標準有三條。第一，任務的輸入是否結構化——diff、日志、測試報告這類輸入邊界清晰，適合；需要大量口頭**的架構決策，不適合。第二，輸出是否可校驗——生成摘要有沒有固定格式可檢查，預檢結論能不能分成明確的等級。第三，失敗的代價是否可控——自動評論寫錯了可以刪，自動合并錯了就是事故。

按這三條標準篩下來，最適合優先自動化的通常是四類：提交摘要生成、合并前代碼預檢、測試失敗日志解讀、發布說明草稿。它們的共同特點是輸入結構化、輸出可格式化、結果給人看而不是直接執行。而自動合并、自動發布這類"模型直接動手"的環節，至少在前半年應該保持人工確認。

• 優先自動化"輸入結構化、輸出可校驗、失敗代價低"的環節。
• 涉及寫操作的環節（合并、發布、改配置）保留人工確認。
• 一個環節自動化之前，先在交互式場景里把提示詞跑穩。

二、接入準備：流水線專用的 Key、額度與入口

CI/CD 場景的接入和本地開發有一個本質區別：它運行在無人值守的環境里，出了錯沒有人在終端前看報錯。所以接入配置要比本地更嚴格。進入 靈能API 控制臺，為流水線單獨創建一把自動化專用 Key——命名如 auto-ci-pipeline，額度按預估基線給，絕不與任何人的個人 Key 混用。官網入口可以直接記錄為 https://www.lnsns.com/，Key 的申請流程寫進團隊的 CI 維護文檔。

這把 Key 的存放方式也要符合 CI 規范：放進流水線平臺的私密變量（Secrets），配置文件中只引用變量名，任何情況下不出現在日志輸出里。同時給流水線設定明確的用量預期——比如"每次合并觸發 2 次調用、每次發布觸發 3 次調用"，有了這個預期，用量頁的異常波動才有判讀依據。

CI 接入配置清單：
- 專用 Key：auto-前綴命名，獨立額度，獨立用量統計
- 存放方式：CI 平臺 Secrets，配置文件只引用變量名
- 用量預期：寫明每個觸發點的調用次數和預估消耗
- 超時設置：單次調用超時建議 60-120 秒，必須有上限

• 流水線 Key 與個人 Key 嚴格分離，離職交接互不影響。
• Secrets 里的 Key 定期輪換，流程參考本系列密鑰管理篇。
• 用量預期寫進文檔，是后續異常檢測的基線。

三、任務通道設計：四類自動化任務各走各的軌道

四類自動化任務不應該共用同一段流水線代碼。提交摘要追求快和便宜，用默認模型、短超時、小額度；代碼預檢追求可靠，用高能力模型、允許更長超時；日志解讀輸入大，要配長上下文模型；發布說明對格式要求最高，要配最嚴格的模板。每類任務一條獨立通道，通道參數（模型、超時、重試、預算）分別配置。

通道化設計的好處體現在故障隔離上：預檢通道出問題，摘要通道照常工作；某個通道的調用量突然翻倍，看監控一眼就能定位是哪類任務。實現上不需要復雜框架，每類任務一個獨立腳本或 CI jo*，配置文件里各自**參數，就是夠用且好維護的通道化。

通道配置示例（ci_models.yaml）：

commit_sum**ry:
  model: 默認模型
  timeout: 60s
  **x_retries: 2
  *udget_tier: low

code_precheck:
  model: 高能力模型
  timeout: 180s
  **x_retries: 2
  *udget_tier: medium

log_analysis:
  model: 長上下文模型
  timeout: 180s
  **x_retries: 1
  *udget_tier: medium

release_notes:
  model: 文檔模型
  timeout: 120s
  **x_retries: 2
  *udget_tier: medium

• 通道參數顯式寫在配置里，不要散落在各腳本的硬編碼中。
• 低風險任務配短超時少重試，高價值任務允許更長等待。
• 通道獨立后，故障定位和用量歸因都會簡單一個量級。

四、合并前預檢：讓模型當守門員，但不當裁判

代碼預檢是 CI 集成里價值最高也最容易做砸的環節。做砸的典型姿勢是：把整個倉庫或幾百行 diff 直接丟給模型，輸出一大段自由文本評論，開發看兩次就不再看了。做對的關鍵是三點：輸入瘦身、輸出分級、結論不阻斷。

輸入瘦身：只傳 diff 變更和直接相關的上下文文件，而不是整倉；超過閾值的變更集先按文件拆分再逐批送檢。輸出分級：要求模型按"嚴重 / 建議 / 需確認"**輸出，每條問題帶文件和行號，沒有問題時明確說"未發現問題"。結論不阻斷：預檢結果以評論形式呈現在合并請求里，嚴重級問題提醒人工重點看，但合并的攔截規則仍然交給測試、lint 這類確定性工具——模型的角色是讓評審更快，不是替人做決定。

預檢輸出約定：

## 預檢結果
- 嚴重：2 條（必須人工確認后才可合并）
- 建議：3 條
- 需確認：1 條（模型不確定，已標注原因）

每條格式：[級別] 文件:行號 — 問題描述 — 修改建議
無問題時輸出：未發現問題（已檢查 N 個變更文件）

• 輸入只給 diff 和相關上下文，整倉掃描既貴又淺。
• 輸出必須分級帶行號，自由文本評論的生命周期不超過一周。
• 合并攔截交給確定性工具，模型預檢只做提示層。

五、發布說明自動化：從提交記錄到可讀文檔

發布說明是另一類高價值自動化：輸入是結構化的提交記錄和合并請求標題，輸出是給人看的文檔，質量好壞一目了然。但直接"把 50 條提交記錄丟給模型寫發布說明"的效果通常很差——模型會把改錯別字和核心功能并列，把內部重構寫進用戶視角的 changelog。

可靠的做法是兩段式流水線。第一段做分類：讓模型把提交記錄按"新功能 / 修復 / 性能 / 內部變更"歸類，并過濾掉不該出現在用戶文檔里的內部項；第二段做寫作：基于分類結果，按團隊模板生成面向用戶的說明文稿。兩段用不同的提示詞模板，中間產出的分類結果可以人工抽查。這樣即使最終文稿要改，改的也是措辭而不是結構，每次發布節省的時間以小時計。

發布說明兩段式流程：

第一段（分類）：
  輸入：提交記錄   合并請求標題
  輸出：**ON 分類結果 {category, sum**ry, user_facing}

第二段（寫作）：
  輸入：分類結果（user_facing=true 的條目）
  輸出：按模板組織的發布說明 Markdown

人工節點：分類結果抽查   終稿審定

• 先分類后寫作，一步到位的提示詞幾乎必然結構混亂。
• 分類結果是人工抽查的最佳切入點，成本最低、攔截最有效。
• 發布說明模板交給提示詞工程篇的方法管理，版本化維護。

六、失敗兜底：流水線里的重試、降級與不阻塞原則

CI 環境里的模型調用失敗是常態而不是意外：額度超限、暫時性限流、輸入超限、輸出格式漂移，都會發生。流水線設計必須回答一個問題：模型這一步失敗了，整個構建要不要失敗？對絕大多數團隊，正確答案是不阻塞——預檢失敗就跳過評論并記錄原因，摘要失敗就用提交標題兜底，發布說明失敗就標記"需人工撰寫"。模型環節增強流程，但不該有能力掐斷流程。

實現上需要三個機制。重試帶熔斷：只對 429、超時、5xx 重試，指數退避，最多 2-3 次，4xx 直接失敗不重試。降級輸出：每個自動化任務都準備一個純代碼實現的兜底輸出，比如摘要任務的兜底就是提交信息原文列表。靜默告警：失敗不阻塞流水線，但必須留下痕跡——CI 日志里記錄原因，超出基線的失敗率觸發告警，否則"跳過"會慢慢變成"永遠跳過"。

失敗處理決策表：

429 / 超時 / 5xx  → 退避重試（≤2 次）→ 仍失敗則降級
400 / 401 / 403 / 404 → 不重試，記錄原因，降級輸出
輸出格式不合法    → 記錄原始輸出，降級輸出
額度耗盡          → 降級輸出   立即告警負責人

降級原則：流水線狀態 = 成功（帶降級標記），絕不因模型失敗而紅

• 模型環節失敗的默認行為是"降級 記錄"，不是"阻塞"。
• 降級輸出要用代碼生成，不能再依賴第二次模型調用。
• 失敗率超基線必須告警，否則降級會掩蓋慢性故障。

? 七、防失控：觸發條件、頻率上限與預算護欄

CI 場景的特殊風險在于觸發頻率由事件驅動：一次分支保護的誤配置，可能讓每次推送都觸發全量分析；一個 monorepo 的高頻提交，可能讓摘要任務一天跑幾百次。防失控要設三道護欄。觸發條件收窄：預檢只在合并請求打開和更新時觸發，不跟隨每次推送；發布說明只在打 tag 時觸發。頻率封頂：同一倉庫每小時的模型調用次數設硬上限，超限排隊或跳過。預算護欄：自動化 Key 的額度按基線 × 1.2 設硬頂，超了自動停，寧可漏跑不可燒穿。

護欄配置要和團隊規模同步校準。十人團隊的頻率上限和百人團隊完全不同；monorepo 和多倉庫策略的觸發設計也不同。建議每季度對照用量基線重新評估一次護欄參數，這部分可以復用本系列成本篇的基線數據。

護欄配置示例：

triggers:
  precheck: [pr_opened, pr_up**ted]      # 不跟隨 push
  release_notes: [tag_created]
  commit_sum**ry: [merge_to_**in]

rate_limits:
  per_repo_per_hour: 30
  per_pipeline_run: 5

*udget:
  monthly_cap: 基線 × 1.2
  on_exceeded: stop_and_alert

• 觸發條件寧窄勿寬，漏觸發可以手動補，誤觸發燒的是錢。
• 頻率上限和預算護欄是硬約束，寫進配置而不是靠自覺。
• 護欄參數隨團隊規模季度性校準，不要設一次管一年。

八、可觀測性：流水線里的模型調用要看得見

無人值守環境里，可觀測性就是全部。每一次 CI 里的模型調用，都應該能在事后回答五個問題：哪個任務調的、輸入多大、用了哪個模型、成功還是失敗、花了多少。這不需要自建系統——流水線日志規范輸出 控制臺用量頁對賬，就是夠用的觀測體系。

日志規范是關鍵動作：每次調用前后各打一行結構化日志，包含任務名、模型 ID、輸入規模、耗時、狀態碼或錯誤類型。月底把 CI 日志里的調用記錄和 靈能API 用量頁的數據對一次賬，兩邊的數應該對得上——對不上就說明有日志遺漏或計劃外調用，這本身就是最重要的監控信號。

結構化日志示例：

[AI-CALL] task=code_precheck model=xxx input_tokens=3421
[AI-DONE] task=code_precheck status=ok latency=8.2s output_grade=pass
[AI-FAIL] task=commit_sum**ry status=429 retries=2 fall*ack=used

月度對賬：CI 日志調用次數 ≈ 控制臺用量頁該 Key 的調用數

• 結構化日志五要素：任務、模型、輸入規模、耗時、結果。
• 每月用 CI 日志和控制臺用量對賬，差異即信號。
• 觀測數據存留至少一個季度，趨勢問題需要時間跨度才能看見。

九、效果評估：自動化到底替團隊省了什么

CI 集成跑起來一兩個月后，需要回答"值不值"。評估看四個維度。時間節省：合并前評審的平均耗時有沒有下降，發布說明的撰寫時間從幾小時降到幾分鐘沒有。質量變化：預檢發現的問題里，有多少是真問題被采納修復的——采納率低于三成的預檢規則應該回爐。穩定性代價：因模型環節導致的流水線波動次數，降級機制兜住了多少。成本賬目：自動化層的實際消耗是否在預算護欄內。

評估的結論要落到動作上：采納率高的預檢規則加強，采納率低的下線；降級頻繁的任務檢查是不是輸入設計有問題；成本超預期的通道重新估算額度。自動化不是一次性的項目，而是持續調優的運營工作。

季度評估四問：

1. 時間：評審耗時、發布說明撰寫時間的變化
2. 質量：預檢建議的人工采納率（目標 > 30%）
3. 穩定：模型環節失敗次數與降級兜底成功率
4. 成本：自動化 Key 消耗 vs 預算護欄

產出：每個維度至少一個下季度的調整動作

• 采納率是預檢質量的核心指標，比"發現了多少問題"重要得多。
• 評估必須產出調整動作，否則就是在例行看數。
• 把評估結果同步給使用這些自動化的一線開發，他們的體感是最準的校準。

? 十、結語：好的 CI 集成是"感受不到存在"的集成

回顧整個 CI/CD 集成路徑：先篩出值得自動化的環節，用專用 Key 和通道化配置打底，預檢和發布說明兩大場景按"輸入瘦身、輸出分級、兩段式流水線"落地，失敗兜底守住不阻塞原則，三道護欄防失控，可觀測性兜底，最后用季度評估持續調優。

判斷一套 CI 集成是否成功的標準，其實很樸素：開發不再注意到它的存在。摘要自然出現在合并記錄里，預檢評論恰到好處地提醒風險，發布說明在發版前靜靜躺在草稿箱——沒有人被誤報打擾，沒有流水線因為模型環節變紅，月底賬單沒有驚喜。做到這一步，Codex 通過 API中轉站 就不再是一個"接入的工具"，而是團隊工程體系里一段安靜可靠的管道。