我有一套「無人值守出貨」規則。在符合條件時，agent 改完程式、通過審查與檢查後，可以自行把 PR 合併進主線，不需要再等我按一次同意。

這種做法如果沒有邊界，風險很高，所以規則裡寫了兩個主要條件：review 結果必須是 approved，或只剩不影響出貨的小意見；CI 也必須通過。

review 是另一個 agent 對這次修改做的檢查。CI 則是 GitHub 收到程式碼後，自動執行測試或檢查。兩邊都過了，才有自動合併的資格。

我原本以為這條規則已經寫得很清楚。整理鐵人賽資料時，我實際查了幾個 repo，才發現其中一個條件沒有我想像中完整。

我查了什麼

我用 gh，也就是 GitHub 的命令列工具，檢查 repo 裡有沒有 GitHub Actions 設定，再看最近的執行紀錄。

# 檢查 repo 裡有沒有自動化流程
gh api repos/<帳號>/<repo>/contents/.github/workflows

# 查看最近一百次執行結果
gh run list --repo <帳號>/<repo> --limit 100

我在 2026 年 9 月 10 日盤點時，其中一個主要 repo 有 CI 設定。查到的近期紀錄裡，九十五次成功、四次失敗。

接著我查放置共用 agent 規則的 repo。查詢 .github/workflows 時，GitHub 回傳：

404 Not Found

這不是 CI 沒通過，而是 repo 裡根本沒有 GitHub Actions workflow。

原本的規則少寫了一種情況

無人值守規則寫的是「review 通過，而且 CI 是綠的」。但它沒有繼續說明：如果一個 repo 沒有 CI，應該視為不符合條件，還是可以用其他檢查代替。

偏偏放置這條規則的 repo，就是沒有 CI 的那一個。它主要放規則文件和 shell script，目前實際的把關方式是跨 agent review，加上幾支本機檢查腳本。

這裡可能有兩種處理方式。

第一種是補上 CI，讓這個 repo 也和其他程式專案一樣，在 GitHub 上執行固定檢查。

第二種是承認不同 repo 有不同的驗證方式，重新寫清楚條件。例如，有 CI 的 repo 必須通過 CI；沒有 CI 的 repo，必須通過哪些指定的本機檢查，並把結果留下來。

我目前比較傾向第二種，因為這個 repo 的內容和一般應用程式不同。但這只是目前的判斷，我還沒有完成比較，也還沒有修改規則。

為什麼先把未完成的狀態寫出來

如果只看規則文字，我會說這套出貨流程有 review，也有 CI 把關。實際跑過查詢後，比較準確的說法是：有些 repo 兩者都有；這個規則 repo 有 review 和本機檢查，但沒有 CI，而規則沒有定義這種情況。

兩行查詢指令就讓描述差很多。

我以前常用「沒有出現錯誤」判斷一個東西有在運作。Day 01 提到的 skill 安裝就是這樣：檔案存在、安裝沒有報錯，我便當作功能已經生效。三週後真的去查，才發現讀取程式一直沒有載入它。

這次我想保留問題原本的樣子。等到後面重新跑整套流程時，再回頭確認最後選了哪一種處理方式，以及新規則能不能真的攔住這個缺口。

明天

明天開始寫需求和驗收。我會從一個進度頁面開始：它看起來能顯示工程進度，但數字其實來自 agent 自己勾選的 checkbox。