Day 23｜稿子沒過關，AI 要改幾次？

2026 iThome 鐵人賽

DAY 23

AI 自動化

情報進來，內容發出去：30 天拆一條每天真的在跑的 AI 內容產線系列第 23 篇

18th鐵人賽

團隊會後不散場

2026-09-15 23:27:02

36 瀏覽

分享至

稿件第一次沒過檢查，最容易寫的自動化步驟是「交給 AI 再改一次」。第二次還是沒過呢？照樣再改，流程很快就會變成一個沒有出口的迴圈。

昨天寫到三份來源一起查。我的「今日候選報告」會讓腳本源、Threads 公開內容、X 與 AI 新聞三路掃描，再把情報交給後面的判斷層。Day 22 補做的合併器，會把結果分成 complete、partial、blocked，避免少了一路卻還產出一份看似完整的報告。

候選報告只負責給題目，後面的每日草稿流程才會寫第一版。但有來源，還沒到發文。第一版仍要過另一種關卡：這篇有沒有編造經驗？主文是否超過字數？來源能不能回查？文字是不是像 AI 一次吐出來的？

我的每日發文流程已經把草稿、語氣整理、發前診斷、報告與人工核准排成一條鏈。診斷只指出哪一段要改，不負責整篇重寫。這個設計符合我想要的工作方式：我仍是作者，AI 可以提出修改，但不能因為它自己說「修好了」，就替我決定文章能發。

今天想再往裡拆一層。第一版沒過時，流程到底能讓 AI 改幾次？如果它一直改不對、改完又改回去，程式要怎麼知道該停？

下面講一個有限改稿迴圈。先說清楚邊界：這是我接著 Day 22 參考合併器新做的教學控制器，尚未接進現行候選報告或正式發文流程。本文使用的稿件和修改都是固定合成資料，不是我某次真實發文的改稿紀錄。

來源缺了，先別讓 AI 改文字

進入改稿前，先讀上游狀態。

blocked 可能是必要來源沒有回來，也可能是兩份來源對同一主張互相衝突。這時就算把句子改十遍，缺的來源也不會出現，衝突也不會因為文字變順而消失。partial 可以讓某些下游工作繼續，但必須事前說明用途允不允許；這次的教學政策採保守做法，只收 complete。

if (mergeDecision.completeness !== "complete") {
  return handoffToHuman("upstream_not_approved");
}

這一行很短，卻把 Day 22 和 Day 23 接起來了。合併器負責「素材夠不夠」，改稿迴圈負責「在素材夠的前提下，這段文字能不能修」。兩個問題不能混成同一個模型評分。

哪些問題適合交給程式，哪些得留給我

發前診斷常會同時給兩種意見。

第一種是硬性條件。空稿、禁止的字面句型、主張識別碼不在可用來源清單裡，都能用程式重算。這類問題應該先由檢查器指出確切位置，而不是問 AI「你覺得有沒有問題」。

第二種是作者判斷。某句話雖然掛了來源識別碼，來源真的支持這句嗎？這個角度值得講嗎？例子是否說得太重？文章是否像我會寫的？這些不能靠一個字面掃描器自動裁決。

Day 23 的教學檢查器故意只做三件事：確認文字非空；確認至少有一個主張識別碼，而且都存在於 Day 22 的可用清單；找出三種固定禁語。它沒有驗來源語意，也沒有評文章好不好看。

這種分法和 Anthropic 對 Agent 評估的說明相近：程式檢查可重現，模型能處理較彈性的評估，人則負責需要判斷的部分。這不是說三者各管一欄就能保證正確，而是先別讓模型的自評蓋掉程式已經抓到的硬性問題。

還有一個我自己的流程細節要講清楚。全域 content-gate.sh 是工具事件 hook，掃描範圍不含這裡的 content/articles；直接把這篇文章路徑丟給它，也不會替鐵人賽正文做語意或事實查核。下文的字面檢查是另做的教學檢查器，不能說現有 hook 已經替這篇文章把關。

第一版已過，就不要為了「自動化」硬改

改稿迴圈的第一步是檢查，不是修訂。

五組合成案例裡，有一組首版就沒有命中教學禁語，也帶著合法來源識別碼。控制器直接回 passed，修改次數是 0。

這不是小細節。如果流程永遠固定叫 AI 再寫一版，原本已經符合條件的文章也會被改，作者聲音可能就在這個多餘的步驟裡消失。對我而言，能停在第一版也是自動化的一種結果。

不過 passed 的意思要講準：只是本文那三類硬性檢查通過，還不是「Ci 已經看過並批准」，更不是已經發布。

修改單要指出一段，不要一句「重寫得更好」

假設合成首版是這樣：

總而言之，兩份來源對同一項主張一致。

檢查器指出「總而言之，」這個片段。修改者只需要提議把它刪掉，留下：

兩份來源對同一項主張一致。

比起「請讓文章更自然」這種模糊命令，局部修改至少能說清楚三件事：改哪個位置、為什麼改、改後還保留哪些東西。

這次的參考執行器更保守。補丁必須精確對應一個已命中的片段；找不到唯一位置、修改範圍跑出問題段落，或順手插入新的來源結論，都以 invalid_patch 停下來。這不是完整的 AI 編輯器，而是為了測停止條件，把修改權收窄到固定字面問題。

const patch = { find: "總而言之，", replace: "" };
const nextDraft = applyLocalPatch(draft, patch, findings);
const nextCheck = checkDraft(nextDraft, usableClaims);

第二次 checkDraft 必須重驗整份稿，不是只確認剛剛那個詞不見了。刪掉一句禁語卻引入另一句，不能算成功；來源識別碼若變了，也得重新檢查。

Anthropic 的 evaluator-optimizer 模式正是「產生 → 評估與回饋 → 修訂」的基本形狀。它適合評估標準明確、修訂有可量價值的工作。這篇借的是形狀，不是替 AI 訂一個神奇的最佳修改次數。

我會讓迴圈在三種情況停下來

文章修改很容易變成「再試一次」。但多呼叫一次模型，不一定多得到一版有用的稿。

第一種停止是 no_progress。提議的修改執行後，文字跟上一版完全相同。這代表本輪消耗了一次修改額度，卻沒有新版本。不能把同一個請求無限重送。

第二種是 oscillating。稿件從 A 變 B，再從 B 回 A。只比較相鄰兩版，A→B 和 B→A 都看得到變化，還會以為有進展；把每版文字摘要存進 seen，第三版就能辨識它回到了第一版。

第三種是 max_rounds。改到事前約定的上限，硬性檢查仍沒過，就交人處理。此次合成政策設「最多兩次修改」，只是方便把出口測出來，不是我的正式發文設定，也不是研究建議「文章只能改兩次」。

程式主幹可以縮成這樣：

const seen = new Set([digest(draft)]);

for (let attempt = 0; attempt <= maxRevisions; attempt += 1) {
  const check = checkDraft(draft, usableClaims);
  if (check.passed) return reviewCandidate(draft);
  if (attempt === maxRevisions) return handoffToHuman("max_rounds");

  const next = applyLocalPatch(draft, proposePatch(check), check.findings);
  const before = digest(draft);
  const after = digest(next);

  if (after === before) return handoffToHuman("no_progress");
  if (seen.has(after)) return handoffToHuman("oscillating");

  seen.add(after);
  draft = next;
}

摘要在這裡只是用來比較版本。它不是簽章，也不能證明文字真實。若修改者回「這版已經過了」，但 checkDraft 仍抓到問題，控制器仍照檢查結果走，不靠修改者自己替自己評分。

還要分清另一種常被混用的上限。AWS Step Functions 的 MaxAttempts限制的是指定錯誤的重試；本文限制的是稿件修改嘗試。一次修訂即使沒有產生新文字，也算一次嘗試。模型呼叫輪數、執行圖步數和文章版本數，同樣不能直接畫等號。

五組合成稿，把每個出口都跑一次

為了避免只測「修一次就好」，這次用五組固定合成稿和腳本化局部替換，覆蓋四種不同出口：

稿件變化	修改嘗試	出口
首版符合教學條件	0	`passed`
一個禁語，局部刪除後過關	1	`passed`
補丁前後同稿	1	`no_progress`
A→B→A，回到歷史稿	2	`oscillating`
兩次修改仍有禁語	2	`max_rounds`