給 CGE 四號樣板交付一條「狀態流水線」

小小龍家最近接了一個工程：把 CGE 四號樣板的交付流程從「在群組裡喊一聲、在表格裡改狀態」升級到腳本化流水線。樣板本身不難，難的是流程裡有三個環節互相不信任：出圖的機器會超時，送審的人在填表和截圖之間來回切換，機器人要按狀態自己推播報告。

以前這三件事靠記憶串聯。出事了翻聊天記錄，翻完了發現兩邊說的狀態對不上——機器顯示「已完成」，人工手裡那張表還寫著「待審批」。

這次做的事不複雜：把每一步的產物都寫進同一個狀態檔案，機器讀完再走下一步。

狀態檔案是唯一事實來源

現在的流程：提交 → 出圖 API 回傳 URL → 寫入 state.json；機器從 state.json 取狀態發送審批；人工審批通過後寫回 `approved`；機器人看到 `approved` 自動渲染報告並推播。

每一步只讀上一步寫入的欄位，不信截圖，不信群組訊息。上週「出圖」環節 API 超時，腳本按設計重試。坑在於前一次重試把半截結果（只有外框、沒有數字的兩張圖）寫進了 state.json，報告環節拿到後照常渲染，差點發出去一張半成品。

後來加的規則：出圖環節只有當回應裡明確帶 `completed: true` 時才更新輸出欄位，超時的重試一律不碰已有記錄。

「已完成」有兩個定義

業務方嘴裡「做完了」常有兩種意思：機器口徑是圖出了、報告排版完；人工口徑是客戶簽字了。

這兩個「完成」用不同的欄位。state.json 裡現在有 `machine_done` 和 `human_approved` 兩個 key，報告推播只看後者。上週差點把一張「機器視角已完成、人工還沒簽字」的報告發出去，校驗腳本檢查 `human_approved` 為空才攔下來。

硬體設施上記住這句話：**報告檔案可以隨時重新渲染，簽字不行。**

AI 畫樣板的那次翻車

有一次 AI 產生的樣板圖把「質保三年」渲染成了「三月質保」。原始碼和文字都沒錯，是字型渲染讓「三」長得像另一個字的樣子。配圖和文字一起看，字數對，數字位置對，完全看不出來。客戶問了一句「三個月？」才發現。

這條被寫進了送檢清單：樣板裡出現的承諾性數字（質保、交期、賠付），渲染出來之後要麼人工確認圖像，要麼走 OCR 校驗文字。一個流程裡兩步都做最好，只做一步也行，但一步都不做不行。這一步不放進自動化——自動化給它添加的自動化故障風險，比它排除的風險更大。

超時重試要拉長間隔

樣板 API 週五下午高峰會超時。第一批腳本設的是「超時重發、間隔 30 秒」，卡了兩次之後手動重啟服務才通。重試的間隔重新算過：固定間隔在高峰期只是製造更多干擾。改成 90 秒起步、重試上限從 3 次加到 6 次。

第二週同個時間段跑同一批任務，沒有再手動重啟過一次。

這週帶走的東西

1. **參數校驗擋在提交前。** 客戶名、規格、交期錯一次要重跑一個週期，腳本先過一遍必填項，擋的是低價值錯誤。

2. **狀態檔案高於聊天記錄。** 兩個系統裡「做完了」定義不一致，幾乎是時間戳對不上導致的。

3. **同一份資料只出一張報表。** 兩個系統各出一張對帳表，必然有落差。

4. **AI 交付物的人工關口不能省。** 「審批認簽字」不是玄學，是工程定義。

5. **重試間隔逐次拉長。** 固定間隔在高峰時段只是雜訊。

下週的一個小工程：把參數與樣板欄位的對應規則寫成文件，讓下一位接手指明 CLI 和設定檔之間的邊界——只在檔案裡留註解，三個月後沒人記得為什麼這麼寫。