AI 判完了。
誰負責按下發布？
這一頁不是在講模型有多準。
這一頁在講：當它判錯的時候，那筆東西會撞上什麼。
AMAX 人審閘門 ｜ HUMAN GATE
AI 產出結果
要不要人審？
直接發布
進人審佇列
有人回應嗎？
通過 / 退回 / 改
逾時策略生效
發布後才發現錯？
大部分的失敗不在「AI 判錯」，在「沒人回應」那一格。所以我們把它做成全頁最長的一段。
節點 1 ／ 這一筆要不要人審？
全部都送人審，人會被淹死，然後開始亂按通過 —— 這比不審更糟，因為它製造了「有人審過」的紀錄。
所以第一個分岔是「哪些不必審」。這條規則由你定，不由模型定。
AI 產出結果
- 命中「必審」規則進人審佇列
- 命中「必擋」規則直接退回，不進佇列
- 兩者都沒命中直接發布
三種規則怎麼寫
| 規則類型 | 依據 | 例子（示意，非實際客戶規則） |
|---|---|---|
| 規則類型必審 | 依據內容類型、金額級距、對象、發布通路 | 例子（示意，非實際客戶規則）對外發布的文字一律必審；內部草稿不必審 |
| 規則類型必擋 | 依據出現特定字詞、觸及特定主題、缺少必要欄位 | 例子（示意，非實際客戶規則）缺少免責聲明時直接退回，連人審都不用排 |
| 規則類型其餘 | 依據落在前兩者之外 | 例子（示意，非實際客戶規則）自動發布 |
這三條規則是關鍵字與欄位比對，不是模型判斷。
我們刻意不用模型來決定「這筆要不要人審」—— 因為那等於用一個會出錯的東西，來決定要不要檢查另一個會出錯的東西。
規則比對的結果是可解釋的：命中哪一條、為什麼命中，都寫在紀錄裡。
已實作的一個具體形式
我們有一支自動分類器就是這樣寫的：純記憶體的關鍵字字典比對，多條規則同時命中時取優先序最高的那條並標記為「有歧義」交人判斷，零命中時落入「未分類」而不編造一個分類。
「不知道就說不知道」是這整頁的設計原則，第一個分岔就開始用。
節點 2 ／ 通知誰？通知到哪？
一筆東西進了佇列，如果沒有人被戳一下，它就會躺在那裡。「有一個待審列表」不是通知，是一個沒人會主動打開的頁面。
進人審佇列
- 誰依規則指定的審核者（角色、或指定人）
- 哪通知管道
- Discord（已實作，正在跑）
- Email（已實作，其他產品線）
- Slack（同一介面換 adapter，尚無上線實作）
- LINE（同上）
上面四條的成熟度不一樣，我直接標出來：
- Discord 私訊 —— 已實作，而且正在跑。 產出後直接私訊管理員，訊息裡帶內容全文與兩顆按鈕。超過長度上限時自動分段，優先在換行處切開，附件只掛最後一段。
- Email —— 已實作，但在另一條產品線上。 寄送與通知的機制是現成的，接到閘門上是整合工作。
- Slack / LINE —— 沒有已上線的實作。 通知這一層是介面化的，換一個 adapter 即可，但「可以做」跟「做過了」是兩件事，我們分開講。
如果你需要的是 LINE，請把它當成一項要排的工作，不是一個開關。
責任歸屬
通知要送給一個具體的人或角色，不是一個群組。送到群組的結果是所有人都以為別人會處理。
系統記錄的是「這一筆的審核者是誰」，逾時策略也是綁在這個人身上。
[待審] 一筆內容等你確認
內容：{摘要}
若在 {timeout} 內沒有回應，將依設定{自動發布 / 自動丟棄}。
[ 通過 ] [ 退回 ] [ 中止 ]節點 3 ／ 他回應了。三條出口。
審核者有回應
- 通過發布，紀錄「誰在什麼時候通過」
- 退回自動抓下一個候選重跑（人不需要重新發起任務）
- 修改後通過內容以人的版本為準，紀錄同時保留「AI 原版」與「人改後」
「退回」不是終點，是換一條
這是我們在實作裡踩出來的一條規則：按下退回之後，系統自動抓下一個候選重跑，人不需要回到起點重新發起任務。
為什麼重要 —— 如果「退回」的代價是「整件事重來」，審核者就會傾向於按通過。一個讓人不想按的按鈕，等於一個不存在的按鈕。
「中止」要單獨存在
除了通過與退回，還要有一個「這整件事現在不要做了」的出口。缺這一顆按鈕時，審核者唯一的中止方式是不回應 —— 於是逾時策略會被誤用成中止鍵，而那兩件事的語意完全不同。
修改後通過，兩個版本都要留
人改過的版本才是發布出去的那一份，但 AI 原版必須留著。少了原版，你就永遠不知道模型到底錯在哪、也無法判斷換一版模型是變好還變壞。
已知限制
我們既有的狀態機實作有一個已知行為：把一個已核准的東西退回時，它的狀態會由「已核准」直接改成「已退回」 —— 也就是「它曾經被核准過」這件事只剩稽核紀錄記得，狀態欄位上看不出來。
這在多數場景可以接受，在需要證明「核准歷程」的場景不行。如果你的用途屬於後者，這是一項要修改的工作，不是現況。
節點 4 ／ 他沒有回應。
這是這一頁真正的主題。
前面三個節點都有人在動，這一格沒有。而實務上，大部分的閘門是死在這一格，不是死在判斷錯誤。
沒有回應
- 策略 A：逾時自動發布東西出去了，但沒有人真的看過
- 策略 B：逾時自動丟棄東西沒出去，這一輪白做
- 策略 C：什麼都不做卡住。而且沒有人知道它卡住。
策略 A：逾時自動發布
| 項目 | 內容 |
|---|---|
| 項目行為 | 內容到時間沒回應 → 視為通過 → 發布 |
| 項目適合 | 內容內容風險低、更新頻率高、「漏發」的損失大於「發錯」的損失。例如：內部情報摘要、社群日更、非對外的整理型內容 |
| 項目不適合 | 內容任何對外的、有法律或醫療後果的、金額相關的內容 |
| 項目已實作的實例 | 內容我們有一條在跑的產線就是這個策略：10 分鐘未回應自動發布。這是一個明確的產品決策，不是漏寫 |
| 項目代價 | 內容你必須接受「有些東西是沒有人看過就出去的」。如果你不能接受這句話，就不要選 A |
策略 B：逾時自動丟棄
| 項目 | 內容 |
|---|---|
| 項目行為 | 內容到時間沒回應 → 視為不通過 → 丟棄，並記錄丟棄原因為「逾時」 |
| 項目適合 | 內容對外文宣、法遵文件、醫療衛教、金融與保險話術、廣告素材。也就是發錯的代價遠大於沒發 |
| 項目不適合 | 內容高頻產出的內容 —— 丟棄率會高到讓整條產線失去意義，那時候該修的是通知機制不是策略 |
| 項目代價 | 內容這一輪的產出白做（如果有 API 成本，錢也白花）。所以選 B 的人要同時盯著「逾時丟棄率」這個數字 |
| 項目補充 | 內容B 的變體是「逾時降級為草稿」：不丟棄，但也不發布，退回草稿區等人有空。適合產出成本高的場景 |
策略 C：什麼都不做 —— 這是最糟的選項。
「沒設定超時」聽起來像是最安全的：沒有人批准，所以什麼都不會發生。實際上它會產生下面這四件事，而且是依序發生的：
- 它安靜地卡住。 沒有錯誤、沒有警報、沒有失敗紀錄。監控看起來一切正常，因為技術上確實沒有任何東西壞掉。
- 佇列越積越長。 兩週後有人打開待審列表，看到 300 筆。
- 有人開始繞過去。 因為 300 筆審不完，而業務要出去。於是出現一條沒有經過閘門的路徑 —— 這正是閘門原本要防的事。
- 它在稽核時最難解釋。「為什麼這批東西停在這裡三個月」比「為什麼這筆被自動發布」難回答得多，因為前者沒有任何決策紀錄可以指。
選 A 或選 B，都是一個你可以對主管機關解釋的決定。
選 C 不是一個決定，是一個還沒被發現的問題。
不管選 A 還是 B，這三件事都要有
逾時策略生效
- 1. 事前預告通知訊息裡就要寫明「逾時會怎麼處理」
- 2. 升級路徑逾時前先提醒一次，或轉給第二順位審核者
- 3. 逾時紀錄這一筆是「人批准的」還是「逾時放行的」，必須是兩種不同的紀錄，不可混為一談
第 3 點是最容易被省略、也最不能省的一點。
如果「逾時自動發布」在紀錄裡看起來跟「有人按了通過」一模一樣，那你的稽核紀錄就是假的 —— 它會讓你相信有人看過，而其實沒有。
節點 5 ／ 已經發出去了，然後發現錯了。
閘門會漏。逾時會放行。人也會按錯。所以最後一個節點不是「怎麼不出錯」，是「出錯之後怎麼辦」。
發布後發現錯
- 通路支援撤回撤回 + 記錄「撤回原因、誰撤的、幾點撤的」
- 通路不支援撤回發更正 + 把原件標記為「已更正」
- 這一段本來就該重做單段返工：只退回出錯的那一段，不是整件事重來
單段返工
「已完成」不該是死路。我們的狀態機補過三條返工轉換，讓已經走到終點的東西可以退回到特定的中間狀態重做 —— 只重做那一段，而不是整件事重來。
這三條轉換在程式碼註解裡標明了各自是為哪一條驗收條件補的，這樣下一個接手的人知道它為什麼存在。
稽核紀錄是這一格的地基
沒有紀錄，這一格就沒有東西可以做。要能回答的問題是：
- 這一筆是誰批准的？幾點？
- 它是人批准的，還是逾時放行的？
- AI 原版長什麼樣？人改了哪裡？
- 撤回是誰做的？原因寫了什麼？
我們既有的稽核紀錄實作是結構化日誌 + 後台查詢介面，並且寫入權限被單獨收緊過 —— 稽核紀錄如果誰都能寫，它就不是稽核紀錄。
可重現，才可重放
出事後要重建現場，前提是同一份輸入能得到同一份輸出。我們的任務包組裝器是全純函式，檔案內明令「任何隨機值都不准出現」 —— 同樣的輸入永遠得到同一份指令與同一份任務描述檔。
如果你的產線每次跑都不一樣，出事時你連「當時到底發生什麼」都重建不出來。
附錄 A ／ 超時要設多久
下表是設計建議的起始值，不是實測出來的最佳值。我們手上唯一有實作先例的數字是「10 分鐘」（低風險、高頻的內部情報產線）。
其餘各列是依風險等級推導的建議，你必須依你團隊的實際回應速率調整。任何人給你一張「業界標準超時時間表」，都應該被追問資料來源。
| 風險等級 | 內容類型（示意） | 建議策略 | 建議超時 | 逾時前提醒 | 說明 |
|---|---|---|---|---|---|
| 風險等級低 | 內容類型（示意）內部情報摘要、內部草稿、非對外整理 | 建議策略A 自動發布 | 建議超時10 分鐘 | 逾時前提醒不需要 | 說明此列有實作先例：現行產線即為 10 分鐘自動發布 |
| 風險等級中低 | 內容類型（示意）社群貼文、部落格草稿、內部通知 | 建議策略A 自動發布 | 建議超時1–2 小時 | 逾時前提醒逾時前 15 分鐘 | 說明漏發的損失大於發錯 |
| 風險等級中 | 內容類型（示意）對外文案、產品說明、客服回覆範本 | 建議策略B 降級為草稿 | 建議超時4–8 小時 | 逾時前提醒逾時前 1 小時 | 說明不丟棄也不發布，退回草稿 |
| 風險等級中高 | 內容類型（示意）廣告素材、報價與金額相關內容 | 建議策略B 自動丟棄 | 建議超時1 個工作天 | 逾時前提醒逾時前 2 小時 + 轉第二順位 | 說明需要第二順位審核者 |
| 風險等級高 | 內容類型（示意）醫療衛教、金融文宣、保險話術、法遵文件 | 建議策略B 自動丟棄 | 建議超時1 個工作天，且必須有第二順位 | 逾時前提醒逾時前 2 小時，且提醒同時發給主管 | 說明此級別不建議使用自動發布，任何情況下都不建議 |
- 超時長度要跟你的人真的多久會看一次通知對齊，不是跟內容的重要性對齊。設一個沒有人做得到的超時，等於選了策略 C。
- 上線後第一個月要看的數字只有一個：逾時率。逾時率高，先修通知管道，不要先改超時長度。
- 高風險等級如果逾時率高，那不是設定問題，是這條產線的人力配置問題。
這套東西適合誰、不適合誰
適合
- 你已經有一條會產出東西的 AI 產線，而且產出量大到人不可能全部從頭做。
- 你能指出具體的某一個人或某一個角色該對這批東西負責。
- 你可以接受「慢一點但擋得住」，勝過「快但偶爾出包」。
- 你需要在事後回答「這一筆是誰批准的」。
- 你的內容是可以被一個人在幾分鐘內看完並判斷的（一段文字、一張圖、一份清單）。
不適合
- 你想要的是全自動。 那你要的不是這個產品 —— 這一頁從頭到尾都在說「留一個人在迴路裡」。
- 你想要 AI 來判斷該不該放行。 我們刻意不做這件事，理由寫在節點 1。
- 你的產出需要專業判讀才能審（例如要看完 30 頁報告才知道對不對）。閘門解決的是「有沒有人看」，不是「這個人有沒有能力看懂」。
- 你沒有人可以當審核者。 沒有人的閘門就是一個延遲器。
- 你要的是內容品質提升。 閘門不會讓 AI 寫得更好，它只決定寫壞的那些出不出得去。
這個產品不會讓你的 AI 變準。
它讓你在 AI 不準的那一天，還有東西可以拿出來解釋。
把你的產線畫成一張圖，我們幫你標出閘門要放在哪裡
給我們你現在的流程（一段文字說明就可以），我們會回你三件事：哪幾個點該設閘門、每個閘門建議用哪一種逾時策略、以及你的稽核紀錄目前缺哪些欄位。
這一頁沒有淡入、沒有位移、沒有 hover 動效，只有流程線是畫出來的。這是刻意的：這個產品在講謹慎，視覺上就不該浮誇。
本頁描述的閘門機制不含任何模型呼叫。被閘門審核的內容可能由模型產生，那是兩件事。