[AI 實踐] 在 Skill 流程加入人為檢查點

[AI 實踐] 在 Skill 流程加入人為檢查點

摘要：在高價值節點讓人及早審核，能減少誤差累積，提升 Skill 的穩定性。

內容:

設計 Skill 時，很容易把「完全自動化」當成目標：把 SOP 交給 Agent 後，從開始到產出結果都不再介入，也不必查看中間過程。但在反覆打磨 Skill 後，我發現這種想法反而可能是失敗的原因。若想提升 Skill 的魯棒性與穩定性，不能一味把人從流程中抽離，而應在適當位置加入人為檢查點（checkpoint）。

我在製作問卷生成 Skill 時遇過這個問題。經過多個版本的迭代，產出的問卷仍不符合預期。我能感覺到設計有問題、某些地方需要調整，卻很難把這種綜合判斷整理成固定而明確的規則，寫進 Skill。當時流程往往有十幾個步驟，執行一次可能要等十多分鐘；等到最終結果出來才發現不對，再要求重跑，又得耗費一輪時間。

後來我改變了設計方式：不再要求 Agent 一口氣做完，而是把人的經驗判斷放進流程中最有價值的節點。現在，這個 Skill 會先分析客戶背景、提取關鍵資訊，再讀取既有的通用問卷模板，思考如何針對該客戶調整。接著，它不會立刻生成完整問卷，而是先提出一份簡短的調整方向，停下來請我確認。這就是第一道人為檢查點。

把檢查點放在早期很重要。假設流程共有十步，第三步的方向已經偏了，卻等到第七步甚至最後才檢查，後續工作可能已經建立在錯誤的基礎上。Agent 也不是一開始就完整想好每一步，而是在執行過程中根據前一步結果繼續推進；早期的小誤差，可能隨著步驟增加而放大。因此，越早在關鍵處校正方向，越能避免浪費後續的時間與 token。

檢查點的中間產物必須方便人閱讀，因為它的服務對象是人，不只是 Agent。如果要求人審核，卻產出一份冗長的 Markdown 文件，就失去了快速判斷的意義。在我的流程中，Agent 會把問卷的調整方向整理成簡潔的 HTML。我可以迅速看出它提出了哪些改進點，告訴它哪些方向可以保留、哪些需要修改；有需要的話，HTML 也可以設計成可勾選確認的互動形式，但不必為了互動而讓流程過度複雜。

收到我的意見後，Agent 會修正方案，再生成問卷初版。初版同時有 Markdown 與 HTML 兩種形式：Markdown 供 Agent 後續處理，HTML 則供人預覽。這時進入第二道檢查點，我會在最終產出前檢視問卷。如果整體符合預期，只有個別題目需要微調，就直接提出意見，讓 Agent 在目前流程中修改，不必從頭重跑，也不一定需要再安排第三次審核。確認後，它才呼叫後續工具生成最終問卷，並把連結交給我分享。

這與「全部做完後，在流程外要求重做」不同。檢查點是 Skill 內部預先設計好的環節，讓人能在尚可低成本調整時介入，而不是等到所有步驟完成才回頭修正。

這種設計也承認了 Skill 的限制：即使指示寫得清楚，Agent 的執行仍可能有變動；有些人類能察覺的問題，也很難事先寫成可穩定遵循的規則。與其無止境地修改指示、期待流程永遠自行產出理想結果，不如設計一套讓人與 Agent 各自發揮所長的協作方式。

實作時，我會掌握三個原則：盡量及早設置檢查點；選在需要高價值判斷的節點介入；讓中間產物簡短、易讀，足以支持人的審核。 經過多次使用後，人於檢查點提出的意見和修改紀錄，也可以再沉澱成改進 Skill 的素材。

人為檢查點不是放棄自動化，而是避免過度相信全自動化。當流程走到能看出雛形、也最需要判斷的地方，讓人及時介入，通常比等到最後才檢查，更能得到穩定且符合預期的結果。