【改版】2026-09-28 新版：畫面全面改為逐格動畫，講到哪裡就標出哪裡，重點處畫面停留片刻；旁白改回原速。旁白講錯或與官方說法不符之處，畫面加上更正卡，並逐條列在下方【更正】。本片取代先前上架的舊版。 把 Claude Code 放進 CI，最常見的第一個災難：job 直接掛在那裡。 這一集用三道官方公開的範例題拆解：自動化管線裡的非互動模式、 降低 API 成本時真正該問的是延遲容忍度、批次處理的兩個硬道理， 以及審查產出時為什麼需要一雙新鮮的眼睛。 📚 正課對應 5:37 CI 管線從頭搭起 → 特講 Claude Code in Action〈無人值守：Routines 與 headless〉 https://youtu.be/-gjRXdDT7Mk?t=882 9:27 批次處理——正課沒教過，本集補足 13:21 平行化陣型 → ch8 工作流與代理架構對決〈parallelization〉 https://youtu.be/eepICjMDA3M?t=458 ；換一雙眼睛驗 → 特講 它說做完了〈第四級第二意見〉 https://youtu.be/3gc3tFRhwrA?t=723
本集章節9
本集心智圖5 組
把 Claude Code 接進自動化管線：延遲容忍度決定架構，不是成本
- 共同病灶：把給人用的東西搬到沒有人的地方
- CI＝沒有人坐在前面、有新程式碼就自動跑一輪——出事時現場沒人
- 為人設計的互動介面搬進管線，job 就掛著等輸入，永遠不會結束
- 先問一句：這裡有人在等結果，還是沒有人在等？答案不同，架構就不同
- 非互動模式：-p（--print）是整條管線的門閂
- -p／--print＝官方記載的非互動模式：處理提示、印到標準輸出、跑完就結束
- 不加旗標就照預設行為跑——而預設那一種是給人用的
- CLAUDE_HEADLESS 環境變數與 --batch 旗標都不存在——沒在文件看過的先當假的
- 把標準輸入導向空裝置治的是症狀，沒處理 Claude Code 自己的命令語法
- 搭配結構化輸出旗標，可把審查發現自動貼成 PR 的行內留言
- 批次 API：便宜一半，但時間不由你控制
- 用量以標準價五折計；處理上限二十四小時、沒有延遲保證
- 「多數一小時內完成」是通常很快，不是保證多快——不能當服務水準承諾
- 擋 merge 的預檢有人在等，維持即時；隔夜報告沒人在等，改批次
- 輪詢解決「怎麼知道好了沒」，不解決「什麼時候會好」
- 結果不保證照順序回來，但 custom_id 一一對回去，順序就不必管
- 有幾筆失敗就靠 custom_id 只重送那幾筆
- 反推送出頻率：上限二十四小時下，每四小時送一批可保證三十小時 SLA
- 批次接不住多輪工具呼叫——邊看結果邊決定下一步的工作不適用
- 大 PR 審查：注意力品質不等於脈絡長度
- 十四個檔一次全審的病灶是注意力稀釋：意見深淺不一、漏明顯 bug、自相矛盾
- 換更大脈絡窗口是被指名打掉的直覺：放得下不代表平均用力
- 正解：拆成幾輪聚焦審查——先逐檔看本地問題，再跑一輪專看跨檔資料流
- 叫開發者拆小 PR 是把負擔推給人，系統本身沒變好
- 三次審查取共識會壓抑真實 bug：細微問題本來就只被間歇性抓到
- 產生與審查要分開：不要叫寫的那一個自己審
- 同一次執行裡保留著產生程式碼時的推理脈絡，比較不會質疑自己的決定
- 不是它偷懶——那套「為什麼這樣寫」的理由會擋住它看見問題
- 另外開一次乾淨的執行去審，比自我檢查、也比想久一點更有效
- CI 天生適合：產生跟審查本來就在不同執行裡，只要不合成一次