漸進式迭代精修技術

Iterative refinement 是一種工藝——將 Claude 勉強過關的第一版輸出，透過連續的審查與修訂循環，打磨成生產等級的交付品。Claude Certified Architect — Foundations（CCA-F）考試任務說明 3.5——「運用 iterative refinement 技術實現 progressive improvement」——隸屬於 Domain 3（Claude Code 設定與工作流程，佔比 20%），並在程式碼生成與結構化資料萃取兩個情境中被大量考測。這是其中一個安靜的領域：「懂 Claude」但從未親自設計過 refinement loop 的考生，往往把分數輸給那些真正架構過的人。

這份學習筆記涵蓋 CCA-F 考生需要在架構層級設計的完整面向：草稿-審查-修訂循環、為什麼迭代勝過一次性提示、refinement loop 的解剖結構、self-critique 提示技法、標準驅動的審查輪次、diff 式編輯對比完整改寫、收斂偵測、人工介入的 refinement、在精煉現有輸出與從頭重新生成之間做決策、迭代預算，以及在 CI/CD 中以失敗的測試作為 refinement 訊號的自動化模式。結尾的考試陷阱章節、練習錨點與六題 FAQ，將每個抽象概念連回考試情境。

Iterative Refinement 概念 — 草稿、審查、修訂循環在程式碼與內容上的應用

Iterative refinement 是一種工作流程模式：將 Claude 的初版輸出（草稿）視為起點而非最終交付品，透過一輪或多輪明確的審查-修訂輪次加以改善。每一輪應用特定的審查視角——正確性、風格、覆蓋率、結構——並產出一個吸納了回饋的新版本。這個工作流程在程式設計意義上，等同於一位永遠不會直接發佈第一稿的作家。

每位 CCA-F 考生都應內化的正典三階段循環：

1. 草稿（Draft） — Claude 根據任務提示產出初版輸出。品質目標是「夠好，可以審查」，而非「夠好，可以出貨」。
2. 審查（Review） — Claude（或人工審查者、或自動化檢查）對照明確標準評估草稿，並產出結構化回饋：哪裡有誤、哪裡缺漏、哪裡薄弱。
3. 修訂（Revise） — Claude 改寫或編輯草稿以回應回饋，產出改善後的版本。循環可重複，直到滿足收斂標準為止。

Iterative refinement 同樣適用於程式碼（草稿函式 → 對照需求審查 → 修訂）與內容（草稿文件 → 對照風格指南審查 → 修訂）。考試將兩者視為同一模式的不同實例。

Refinement 與 Prompt Chaining 及 Agentic Loop 的差異

Iterative refinement 在結構上與另外兩個 CCA-F 模式相鄰，但並不相同。

• Prompt chaining（任務 1.4、1.6）將任務分解為循序子任務，每個子任務產出不同的成品（計畫、草稿、摘要）。Chaining 沿著管線向前推進。
• Agentic loop（任務 1.1）在工具呼叫上迭代：Claude 提出行動，你的系統回傳觀察結果。Loop 透過從外界蒐集新資訊來向前推進。
• Iterative refinement（任務 3.5）在同一個成品上迭代——同一個函式、同一份萃取、同一份文件——逐步提升品質。成品不變；跨輪次改變的只有它的品質。

混淆這三種模式是常見的 Domain 3 陷阱。若系統在產出新的成品，那是 chaining。若系統在呼叫工具以蒐集新事實，那是 loop。若系統在對照品質標準反覆編輯同一份成品，那才是 refinement。

為何要迭代？初版輸出的侷限與透過 Feedback 的複合式改善

迭代有效的直覺，根植於關於大型語言模型的兩個觀察。第一，單次前向傳播只能表達模型在當下提示下的最佳猜測——它無法參照一份尚不存在的自我審查。第二，當先前的草稿已在 context window 中時，Claude 可以切換到不同的認知視角（評估者而非生成者），從而發現生成時不可見的缺陷。

複合式改善論證

設單次輸出的品質為 q（正規化為 0 到 1）。一次審查輪次通常能發現剩餘缺陷面積的某個比例 d（例如 d = 0.5），產出品質為 q + d·(1 − q) 的版本。第二輪接著複合：q + d·(1 − q) + d·(1 − q − d·(1 − q))。n 輪後品質漸進趨向 1。實際的工程直覺不是要推導出一個漂亮的數學證明，而是一個經驗法則：每一輪大約能捕捉前一輪遺漏的一半缺陷，因此兩到三輪通常遠勝單輪，更多輪則出現明顯的邊際遞減。

為何不直接寫一個更好的初始提示？

有經驗的考生有時會爭辯：只要提示夠精緻，refinement 就是多餘的。這個論點有部分道理——更嚴謹的提示確實能提升 q——但它忽略了一個結構性事實：生成與評估使用不同的認知操作。提示無法完全預先定義審查視角，因為審查依賴於實際的草稿。一份自信斷言了一個聽起來合理但實際上錯誤的事實的輸出，在生成時很難防範，但在審查時卻一眼就能看穿。Refinement 不是良好提示的替代品；它是一種不同性質的工作。

何時不值得 Refinement

Refinement 不是免費的。每一輪都消耗 token、延遲，以及可能的人工審查時間。遇到以下情況時，可跳過 refinement：

• 任務是例行性的，且單次輸出品質持續高於要求門檻。
• 若在下游發現缺陷，整個輸出重新生成的成本很低。
• 延遲是緊繃的限制條件，「夠好、立刻給」勝過「更好、等十秒」。
• 下游消費者（其他 agent、結構化 schema）無論如何都會捕捉到缺陷。

Refinement Loop 的解剖結構 — 輸出、評估標準、缺口識別、針對性編輯

Refinement loop 有四個架構組成部分。缺少任何一個，都會產出一個永遠無法改善或無法終止的 loop。

1. 當前輸出

正在接受 refinement 的成品。在第 1 輪，這是根據任務提示產出的初版草稿。在第 n 輪，它是第 n-1 輪修訂步驟的輸出。Refinement loop 始終操作最新的版本，而不是原始草稿。

2. 評估標準

對照輸出進行審查的明確維度清單。程式碼的例子：需求覆蓋率、測試覆蓋率、風格指南遵循程度、錯誤處理、有無 TODO 佔位符、邊界條件的處理。萃取的例子：schema 合規性、來源文件的覆蓋率、每個欄位的信心度、對模糊段落的標記、明確的 null/unknown 標記而非憑空捏造的數值。標準必須明確——沒有具名標準的審查輪次會退化成泛泛的「這樣好嗎？」，而 Claude 對此只能給出泛泛的肯定。

3. 缺口識別

對當前輸出未能滿足之處的結構化枚舉。缺口清單應盡可能具體——「此函式未處理空輸入列表」是有用的，「錯誤處理可以更好」則無用。當 Claude 產出缺口清單時，請提示它以編號清單輸出，每個條目一個缺口，並對應到特定標準。

4. 針對性編輯

吸納缺口清單的修訂步驟。兩種執行策略適用：完整改寫（Claude 重新產出整個成品並應用修正），或 diff 式編輯（Claude 只產出變更部分，由你的系統套用到當前輸出）。Diff 式編輯對長篇成品幾乎總是更好的選擇，因為它降低 token 消耗、將變更局部化，並保留草稿中正確的部分。

Self-Critique 模式 — 提示 Claude 識別自身輸出的弱點

Self-critique 模式以 Claude 本身作為審查者。在產出草稿後，Claude 被重新提示，對照標準清單枚舉草稿的弱點，這份審查的輸出再被送入修訂輪次。

為何 Self-Critique 有效

草稿生成提示讓 Claude 傾向產出連貫、自信的成品。這個傾向使得生成者成為一個糟糕的批評者——它傾向於合理化，而非質疑。以明顯不同的角色重新提示 Claude（「你現在是一位嚴格的程式碼審查者；列出你能找到的每一個缺陷」），會激活不同的評估立場。當新的提示將批評設為首要任務時，Claude 有能力識別自身先前輸出中的缺陷。

三輪 Self-Critique 範本

1. 第 1 輪（生成）：「撰寫一個 Python 函式，功能是 <需求>。」
2. 第 2 輪（批評）：「扮演一位嚴格的程式碼審查者。以下是第 1 輪的函式和原始需求。請依嚴重程度排序，列出你能識別的每一個缺陷：正確性 bug、缺漏的邊界條件、風格違規、不清楚的命名。請具體說明，並引用行號。」
3. 第 3 輪（修訂）：「使用上述批評，修訂函式。修復列出的每一個缺陷。不要引入原始需求未指定的新行為。」

這個三輪形狀是最精簡的 self-critique loop。同樣的形狀可延伸到四輪、五輪或更多輪，但邊際遞減很快就會顯現。

Self-Critique 需要明確指令

Self-critique 不會自動發生。沒有明確的批評提示，Claude 不會自發地質疑自身的先前輸出——它會將先前的輸出視為 context 並繼續向前。認為 Claude「自然就會迭代」的考生，設計出的工作流程實際上從未真正 refine 任何東西。考試在干擾答案中充分利用了這個假設。

標準驅動的 Refinement — 在審查輪次中指定明確的品質維度

沒有明確標準的審查輪次，是一個產出模糊回饋的審查輪次。標準驅動的 refinement 預先承諾輸出對照評估的維度，確保審查輪次產出結構化、可執行的缺口清單。

寫出能產出有效審查的標準

好的標準具備三個特性。它們是具體的——「函式處理空輸入、null 輸入，以及超過一萬筆元素的輸入」，而非「函式是穩健的」。它們是可測試的——審查者無需進一步詮釋即可對每個標準回答是或否。它們是獨立的——每個標準針對品質的不同軸向，單一缺陷不會同時觸發多個標準。

常見 CCA-F 情境的標準來源

• Code-generation-with-claude-code：需求覆蓋率、測試覆蓋率（若有測試）、風格指南遵循程度、錯誤處理、型別註解、docstring 存在性、無 TODO 與佔位符、安全反模式（硬編碼密鑰、SQL injection）、與使用情境相關的效能考量。
• Structured-data-extraction：schema 合規性、所有必填欄位的存在、不確定萃取的信心度標記、對模糊來源段落的處理、明確的 null/unknown 標記而非憑空捏造的數值。
• Multi-agent-research-system：引用覆蓋率、來源多樣性、主張與來源的可追溯性、無未經支撐的斷言、對宣告受眾的可讀性。

加權標準

並非所有標準都等值。正確性 bug 的分量勝過風格違規。不符合 schema 的萃取分量勝過缺少信心度的欄位。提示審查者回報標準違規時附上嚴重程度（critical、major、minor），並提示修訂步驟優先處理 critical。平等對待所有缺口的 loop，會把輪次浪費在外觀問題上，而正確性 bug 卻持續存在。

Diff 式 Refinement — 套用最小變更而非完整改寫

當正在 refine 的成品很長（一個 300 行的檔案、一份 2000 字的文件、一份 50 個欄位的萃取），要求 Claude 在每輪產出完整修訂版會浪費 token 並帶來風險。Diff 式 refinement 模式約束 Claude 只輸出變更部分。

為何長篇成品的完整改寫有風險

完整改寫的修訂輪次可能讓草稿中正確的部分退步。Claude 不知道一個 300 行檔案中的第 147 行已經是正確的；若要求它重新產出整個檔案，它可能改寫或重構第 147 行並引入退步。Diff 式編輯透過保留未變更部分的字面原文，來避免這個失敗模式。

Claude 可以產出的 Diff 格式

• Unified diff（patch 格式）：經典的 diff -u 輸出，帶有行號和 context。可供機器套用。當目標是檔案且有 patch 套用步驟時最為理想。
• 自然語言編輯指令：「在函式 authenticate 中，將 if user.token: 那行替換為 if user.token and not user.token.expired:；在 logout 中，在第 42 行後加入 session.clear()。」需要後續的套用步驟（另一個 Claude 輪次、或人工、或 Edit 內建工具）。
• 結構化編輯區塊：一個 JSON 或 XML 結構，列出每個編輯，帶有 path、line_range、old_content、new_content。最易於程式化套用。

Claude Code 的內建 Edit 工具直接接受自然語言或結構化編輯規格；當 refinement 在 Claude Code 內進行時，diff 式模式就是原生的形狀。

何時完整改寫是可接受的

短篇成品（sub-500-token 的草稿）、需要無法以少數編輯表達的深度結構性重組的成品，或 Claude 已識別出「草稿大部分是錯的」的成品——這些情況都有正當理由選擇重新生成而非 diff。這個決策是情境相關的，考試會測試你是否能正確選擇。

收斂偵測 — 判斷何時進一步迭代的邊際效益遞減

一個永遠不終止的 refinement loop，跟一個沒有迭代上限的 agentic loop 一樣，都會耗盡預算。收斂偵測是 loop 決定已榨取出最大改善、應當停止的機制。

四個收斂訊號

1. 空缺口清單 — 審查輪次回報沒有標準違規。這是最乾淨的終止訊號，也是大多數 refinement loop 應優先鎖定的目標。
2. 微小缺口清單 — 審查者只回傳低於門檻的 minor 嚴重程度缺口。在不要求完美、時間有限時適用。
3. 重複缺口清單 — 連續兩次審查輪次產出相同的缺口清單，表示修訂步驟沒有帶來進展。視為強制停止並升級（人工審查、重新生成，或接受當前結果）。
4. 邊際差異縮小 — 連續兩版之間的語意距離低於門檻。在實務中較難衡量，但當成品是結構化的（JSON、程式碼）且 diff 大小可作為代理指標時有用。

為何收斂偵測重要

沒有終止測試，你的 loop 要嘛跑到迭代預算用完（若收斂實際上更早就發生了，那是浪費），要嘛跑到審查者偶爾回傳空缺口清單（不可靠；Claude 有時過早回傳空缺口清單，有時則永遠不回傳）。明確的收斂測試讓終止變得具有確定性。

複合終止條件

生產環境的 refinement loop 通常將收斂訊號與硬性迭代上限結合使用。Loop 在最先觸發者停止：審查者表示「不再有缺口」、缺口清單在兩輪間停止變化，或迭代預算達到上限。這種雙重保障避免了過早終止與失控消耗兩種極端。

人工介入的 Refinement — 在迭代之間納入審查者回饋

並非每一個 refinement 輪次都需要自動化。人工介入的 refinement 在輪次之間插入人工審查者，以人工判斷取代 Claude 的 self-critique，適用於任務需要這樣做的情境。

人工審查勝過 Self-Critique 的時機

• 新穎或模糊的需求，「正確」沒有在提示中完整定義，Claude 無法對照不存在的標準進行測試。
• 法律、醫療或安全關鍵輸出，漏掉一個缺陷的成本超過人工時間的成本。
• 主觀品質維度——語調、品牌聲音、美學判斷——人工偏好才是最終依據。
• 對抗性設定，Claude 可能對特定答案存在可預測的偏見，需要外部校正。

架構形狀

Loop 形狀與 self-critique 相同，但將 Claude 擔任審查者的輪次替換為人工擔任審查者的步驟。人工產出缺口清單（通常是自由文字，有時透過結構化表單），Claude 在修訂輪次中消化這份清單。Claude Code 的 Plan mode 是這個模式的原生實例：Claude 產出計畫，人工核准或修改，Claude 再執行或重新規劃。

成本與延遲的取捨

人工介入的 refinement 可能讓延遲從秒級拉長到小時級，取決於審查者的可用性。對高吞吐量工作流程而言，這是致命的成本；對高風險工作流程而言，這是划算的投資。架構應只在風險能夠合理化人工輪次的情況下選擇人工審查，其餘自動化。

Refinement 對比重新生成 — 何時精煉現有輸出、何時從頭開始

Refinement 並非總是正確的選擇。有時，對一份有缺陷的草稿做出的正確回應，是將其丟棄並以更好的提示從頭重新生成。

草稿可精煉的跡象

• 草稿大部分滿足標準；缺口是局部的、可識別的。
• 失敗在特定位置（一個錯誤的分支、一個缺漏的邊界條件、一個錯字），而非在整體方法上。
• 提示與草稿合在一起仍然舒適地在 context 預算內。
• 審查者能夠將缺口表達為具體的編輯。

草稿應當重新生成的跡象

• 整體方法是錯的。對一個根本有缺陷的方法進行 refinement，只會產出一個打磨精美的錯誤答案。
• 缺口清單被「改寫這個段落」或「整個函式形狀不對」這類條目主導。
• 草稿已歷經多輪 refinement 而未收斂。沉沒成本偏誤常常讓架構師持續 refine，而此時重新生成才能更快完成。
• 提示本身才是問題所在。一個更好的提示，可能一輪就產出比五輪 refinement 更好的草稿。

帶著教訓重新生成的模式

一條中間路線：丟棄草稿，但保留審查輪次產出的缺口清單。用這份缺口清單來強化重新生成輪次的提示。這保留了從失敗嘗試中萃取出的資訊，同時避免了繼續編輯一份破碎草稿的沉沒成本陷阱。

考試何時測試這個選擇

CCA-F 的情境題有時描述一個架構師已對一份輸出 refine 了很多輪卻未見改善，並詢問下一步該做什麼。正確答案通常是「以 refinement 輪次所揭示的資訊強化提示，並重新生成」。干擾答案會提供「再加一輪 refinement」或「提高 temperature」——兩者都是錯的。

迭代預算 — 設定最大輪次上限以防止無限 Refinement Loop

就像 agentic loop 需要迭代上限，refinement loop 也需要。沒有上限的話，一個收斂測試永遠不觸發的 loop，將跑到 token 預算或 API 預算耗盡為止。

典型的迭代預算

• 短篇程式碼生成：2 到 3 輪。每輪通常能捕捉剩餘缺陷面積的一半；三輪後邊際遞減已相當明顯。
• 長篇文件 refinement：3 到 5 輪，通常按標準組分拆（第一輪覆蓋正確性，第二輪覆蓋風格，第三輪覆蓋流暢度）。
• 結構化萃取驗證：驗證失敗後 1 到 2 輪重試，然後升級處理。撐過兩輪重試仍存在的萃取錯誤，通常是進一步 refinement 無法解決的問題。

為何預算獨立於收斂之外

收斂測試在改善發生且趨於平緩時停止 loop。預算在改善完全拒絕發生時停止 loop。兩者都需要：僅靠收斂測試，會錯過病理性的不終止 loop；僅靠預算，會在 loop 早已收斂的情況下浪費輪次。

業務層級預算

在生產環境中，迭代預算應與業務成本信封掛鉤，而非工程預設值。一個每天 refine 一萬份文件的內容生成 pipeline，負擔不起每份五輪。一個每週只產出一份合約的法律文件 refinement loop，可以負擔十五輪。架構師從部署經濟學中選擇預算。

CI/CD 中的 Refinement — 以自動化測試失敗作為 Refinement 訊號

CCA-F 的 CI/CD 情境將 refinement 模式翻轉過來：不再由人工或 Claude 審查者產出缺口清單，而是由自動化測試套件產出。失敗的測試成為驅動修訂輪次的結構化批評。

模式流程

1. Claude Code 產出一個程式碼變更（草稿）。
2. 測試執行器執行並產出帶有具名失敗和診斷輸出的通過/失敗報告。
3. 若所有測試通過，loop 終止。若測試失敗，失敗輸出以結構化批評的形式回饋給 Claude。
4. Claude 產出一個針對失敗測試的修訂變更。
5. 測試執行器再次執行。Loop 持續直到所有測試通過或迭代預算耗盡。

這在架構上與 self-critique 模式完全相同，只是審查者被替換成 npm test 或 pytest。優點是顯著的：測試是客觀的、快速的，且跨多次執行產出相同的缺口清單。缺點是測試只能覆蓋它們實際測試的範圍——一個通過測試但在測試覆蓋範圍之外引入退步的變更，會過早收斂。

非互動模式是必要的

CI/CD 以非互動方式執行 Claude Code，這意味著必須使用 -p 旗標（非互動 / print 模式）。Plan mode 和互動式提示與自動化 pipeline 不相容——pipeline 沒有人工可以回應核准提示。提出 CI/CD refinement loop 卻未使用 -p 旗標的考生，設計出的是無法執行的系統。

CI 中的權限範圍

CI 環境需要嚴格限縮的工具權限。在 CI 中執行的 refinement loop，只應擁有它所需工具的存取權限（Read、Edit、Bash 加上受限的指令允許清單），且永遠不應擁有超出工作區範圍的網路或檔案系統存取權。這是與 refinement 架構交叉的一般 CI/CD 安全原則。

白話說明

抽象的 refinement 機制，一旦錨定在具體情境上，就會變得直觀。以下三個類比涵蓋了 iterative refinement 的完整面貌。

類比一：珠寶師的拋光台 — 標準驅動的審查

想像一位珠寶師正在拋光一枚戒指。師傅從粗坯開始（Claude 的草稿——形狀大致對了，但表面粗糙）。他拿出一張品檢清單：對稱性、刻面角度、表面無瑕疵、尺寸吻合。每次拋光過後，他拿著放大鏡對照清單逐項檢查（缺口識別），然後只針對不符合規格的地方再次動手（針對性編輯）。第二輪、第三輪後，被圈出的問題越來越少——戒指已趨於收斂。若師傅在戒指已經完美的情況下繼續打磨，反而會磨掉太多金屬，讓戒指變小（過度 refinement 的退步）。若師傅沒有品檢清單，他只能憑感覺說「好像還不錯？」，永遠不知道何時真正完成（沒有明確標準的 refinement）。這正是標準驅動 refinement 的形狀：品檢清單是評估標準，圈出的問題是缺口清單，下一輪拋光是修訂步驟。

類比二：陶藝拉坯 — 漸進成形與收斂

拉坯師傅在轉盤前永遠不會一個動作就做出最終的茶碗。他從一個粗糙的土塊開始（草稿——結構大致是對的，但粗獷），然後透過連續的動作逐步成形：拉高器壁、收窄瓶口、修整口緣、撫平表面。每個動作都去除了一點多餘，讓茶碗更接近完成的形狀。師傅靠手感判斷何時繼續塑形反而有害——泥土已「收斂」，再一個動作就會讓器壁過薄或破壞對稱（邊際遞減）。若初始的土塊沒有對準中心，再怎麼塑形也救不回來；師傅會把它摔掉重來（重新生成）。師傅尊重迭代預算，因為泥土在工作過程中會風乾——有一個硬性的時間限制，無論師傅是否滿意，都會強制終止。這正是帶有收斂偵測與迭代預算的 refinement loop 的形狀。

類比三：水電師傅的試水壓 — 重複對照規格量測

水電師傅完成管路配件後，會用水壓測試儀逐段測試。規格很明確：每個接頭必須在一定壓力下不滲漏五分鐘。他加壓、觀察儀表（缺口識別）、鎖緊有問題的接頭（針對性編輯）、再加壓確認。當所有接頭在規定壓力下都撐過五分鐘，作業就收斂了。若師傅在已經合格的接頭上繼續鎖，反而會鎖過頭、損壞墊圈（過度 refinement 的退步）。若師傅沒有測試儀，他只能憑眼睛看，永遠無法確認是否真的不滲漏（沒有明確標準的 refinement）。沒有評估標準的 refinement 答案，就是沒有測試儀的水電師傅：他知道自己在迭代，但沒有辦法知道何時真正完成。評估標準是測試儀，缺口清單是量測到的差距，收斂是所有數值都落在規格內的那一刻。

考試當天選用哪個類比

• 關於標準驅動審查的題目 → 珠寶師拋光台類比。
• 關於收斂與邊際遞減的題目 → 陶藝拉坯類比。
• 關於評估標準必要性的題目 → 水電師傅試水壓類比。

常見考試陷阱

CCA-F Domain 3 持續利用五種與 iterative refinement 相關的反覆出現陷阱模式。全部五種都有社群通過報告記錄在案，並以合理的干擾選項形式出現。

陷阱一：將 Refinement 與提高 Temperature 混淆

部分干擾答案提出「提高 temperature 以產出更多樣且精煉的輸出」。這是錯的。Temperature 控制的是採樣隨機性，而非輸出品質——更高的 temperature 產出更多樣的第一版草稿，而非更精煉的輸出。事實上，高 temperature 常常讓 refinement 更難，因為每輪產出略為不同的草稿，使得跨輪次追蹤缺口清單更加困難。Iterative refinement 需要的是明確的審查和修訂重新提示，而非參數調整。

陷阱二：假設 Self-Critique 自動發生

一個常見的陷阱將 refinement 框架為「隨著對話繼續，Claude 自然就會批評自己的輸出」。這是錯的。沒有將 Claude 置於具有具名標準的評估者角色的明確提示，Claude 會將先前輸出視為 context 並繼續向前——它不會自發地質疑自己。Self-critique 需要一個專用的批評提示輪次。

陷阱三：Refinement Loop 沒有迭代預算

描述 refinement loop 只在「Claude 認為輸出已夠好時」終止的答案是不完整的。Claude 對自身收斂的判斷並不可靠；沒有迭代預算的 refinement loop 在病理性輸入上可以無限執行。每個生產環境的 refinement loop 除了任何收斂測試之外，都需要硬性迭代上限。

陷阱四：對長篇成品進行完整改寫的 Refinement

當成品是一個 300 行的檔案或一份 2000 字的文件時，完整改寫的 refinement 浪費 token 且有讓正確部分退步的風險。Diff 式或針對性編輯的 refinement 才是正確形狀。提出「每次 refinement 輪次重新生成整個檔案」的干擾答案，對長篇成品而言是錯的。

陷阱五：在 CI/CD 中套用 Refinement 而未使用 -p 旗標

CI/CD 是非互動式的。由失敗測試驅動的 refinement loop，在沒有人工可以回應提示的自動化 pipeline 中執行。-p（print / 非互動）旗標是必要的。描述 CI/CD refinement pipeline 卻沒有 -p 旗標的答案，在架構上是破損的——pipeline 會在等待互動輸入時掛起或報錯。

陷阱六：將 Plan Mode 當成萬用的安全機制

Plan mode 是人工介入 refinement 的一個特定實例，適合有風險或模糊不清的任務。它不是萬用的預設值。對每個任務套用 plan mode 會增加延遲並讓非互動式 pipeline 故障。考試會對不加區分地使用 plan mode 的設計扣分。

練習錨點

Iterative refinement 的概念在六個 CCA-F 情境中的兩個最集中出現。將以下內容視為此任務領域的情境叢集題的架構骨幹。

Code-Generation-With-Claude-Code 情境

在這個情境中，Claude Code 根據需求產出一個程式碼變更。Refinement 工作流程是：Claude 生成草稿，一個審查輪次（self-critique 或測試驅動）發現缺陷，Claude 修訂。預期會有題目測試你是否正確地對長篇檔案套用 diff 式編輯、在測試存在時是否使用失敗測試作為 refinement 訊號、是否納入迭代預算，以及是否區分了 refinement（編輯同一個檔案）與 chaining（產出一個獨立的測試檔案再實作）。當情境沒有自動化測試驅動 loop 時，self-critique 範本——生成、以具名標準批評、修訂——是預設的答案形狀。

Structured-Data-Extraction 情境

在這個情境中，Claude 從非結構化文件中將欄位萃取到結構化 schema。Refinement 工作流程是：Claude 產出初版萃取，一個驗證步驟（schema 檢查，加上對照來源的審查）識別出缺漏、錯誤或低信心度的欄位，Claude 修訂。預期會有題目測試你是否使用結構化批評（逐欄位的缺口清單）而非自由文字審查、在修訂輪次中是否將來源文件保留在 context 中、是否在一到兩輪後停止重試並升級，以及是否區分了 refinement 與驗證重試 loop（任務 4.4）。一個常見的陷阱：萃取的 refinement loop 在來源確實缺少某個欄位時拒絕終止。正確答案：將欄位標記為 unknown/null，而非繼續 refine 以捏造答案。

Claude-Code-For-Continuous-Integration 情境

雖然主要的分量在任務 3.6，這個情境與 refinement 直接交叉：對每個 pull request 執行 Claude Code 的 CI pipeline，通常實作一個以失敗測試作為缺口清單的自動化 refinement loop。預期會有測試 -p 旗標、迭代預算、權限範圍，以及對 Claude 無法修復的測試失敗（基礎設施錯誤、環境差異）的正確處理——這些應該被標示為人工介入訊號，而非繼續燒迭代次數試圖 refine 過去。

FAQ — Iterative Refinement 前六大問題

在 Claude 的語境下，iterative refinement 究竟是什麼？

Iterative refinement 是一種工作流程模式：Claude 產出初版輸出（草稿），對照明確標準評估以產出缺口清單，並修訂輸出以修補缺口——重複審查-修訂循環直到收斂訊號觸發或迭代預算耗盡。此模式適用於程式碼、結構化萃取與長篇內容。它在架構上有別於 agentic loop（在工具呼叫上迭代以蒐集新資訊）與 prompt chaining（跨循序步驟產出不同成品）。Iterative refinement 持續操作同一份成品；跨輪次改變的只有品質。

Iterative refinement 與單純提高 Temperature 或重跑同一個提示有何不同？

Temperature 控制採樣隨機性；它不產出 refinement。更高的 temperature 讓第一版輸出更多樣，而非更精煉。沒有中間批評輪次的情況下重跑同一個提示兩次，產出的是兩份獨立草稿，而非一份精煉過的。真正的 iterative refinement 需要一個明確的審查步驟——一個將 Claude 置於具有具名標準的評估者角色的專用提示，加上一個消化缺口清單的修訂提示。沒有這兩個額外的輪次，你沒有 refine 任何東西；你只是生成了兩份草稿。

何時應精煉現有輸出，何時應從頭重新生成？

當草稿大體上是正確的、缺陷是局部的（缺漏的邊界條件、錯誤的分支、錯字），且整體方法是健全的，選擇精煉。當方法本身是錯的、缺口清單被「改寫這個段落」的條目主導、多輪 refinement 未能收斂，或提示本身可以用失敗草稿的教訓加強時，選擇重新生成。一條有用的中間路線：丟棄草稿但保留缺口清單，並用它來強化重新生成的提示。沉沒成本偏誤常常推動架構師持續 refine 一份根本破損的草稿，而此時以更好的提示重新生成才能更快完成。

通常需要多少輪 refinement 才夠？

對短篇程式碼生成，兩到三輪是典型值——每輪大約能捕捉剩餘缺陷面積的一半，因此第三輪通常已進入明顯的邊際遞減。對長篇文件 refinement，按標準組分拆的三到五輪效果良好（正確性輪、風格輪、流暢度輪）。對結構化萃取驗證，驗證失敗後重試一到兩輪，然後升級——撐過兩輪重試的萃取錯誤，通常是來源資訊缺失的症狀，而非 refinement 能修復的 bug。每個生產環境的 refinement loop 都應將明確的收斂測試（空缺口清單或微小缺口清單）與硬性迭代預算結合使用。

如何在 CI/CD pipeline 中實作 refinement？

以 -p（非互動 / print）旗標執行 Claude Code，讓 pipeline 不會在互動提示上掛起。以失敗的測試輸出作為結構化批評——每個失敗測試是一個帶有具名診斷細節的缺口。設定緊湊的迭代預算（通常兩到四輪）以防止 CI 作業失控，並嚴格限縮工具權限範圍（Read、Edit、Bash 加上指令允許清單；除非必要否則不開放網路存取）。對 Claude 無法修補的測試失敗（基礎設施差異、環境問題），應標示為人工介入訊號，而非燒迭代次數試圖 refine 過去。Plan mode 與非互動式 CI 不相容，不得在此使用。

為何 self-critique 有效，即使作者和審查者是同一個模型？

Self-critique 有效，是因為生成與評估即使在同一個模型中也會激活不同的認知立場。草稿生成提示讓 Claude 傾向產出連貫、自信的輸出——這個傾向主動壓制了批評。以明顯不同的角色重新提示 Claude（「扮演嚴格的審查者；對照這些具名標準列出每一個缺陷」）會激活一個能夠發現生成立場所產出缺陷的評估立場。這不是 Claude「即時注意到自己的錯誤」——而是 Claude 在另一輪針對不同問題給出答案。關鍵的實作細節在於批評提示必須明確且標準驅動。模糊的「這樣好嗎？」產出泛泛的肯定；具體的「列出標準 X、Y、Z 的每一個違規」產出可執行的缺口清單。

延伸閱讀

• Plan mode and iterative refinement — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Handle tool calls — validation and retry loops: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Integrate Claude Code into CI/CD pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• Prompt engineering overview — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

Related ExamHub topics: Plan Mode vs Direct Execution, Validation, Retry, and Feedback Loops for Extraction, Multi-Step Workflows with Enforcement and Handoff, Agentic Loops for Autonomous Task Execution.