實驗室已驗證

告別「差不多」:建構 LLM 任務的【驗收清單 (Acceptance Checklist)】工作流程

告別「差不多」:建構 LLM 任務的【驗收清單 (Acceptance Checklist)】工作流程 在與大型語言模型(LLM)協作時,最令人沮喪的時刻不是它一次性給出了錯誤答案,而是它給出了一個「看起來很正確,但細節處有致命缺陷」的答案。 這種現象被稱為「幻覺的偽裝」。當你要求模型寫一段程式碼、一份合約草案或…

告別「差不多」:建構 LLM 任務的【驗收清單 (Acceptance Checklist)】工作流程

驗證報告

告別「差不多」:建構 LLM 任務的【驗收清單 (Acceptance Checklist)】工作流程

在與大型語言模型(LLM)協作時,最令人沮喪的時刻不是它一次性給出了錯誤答案,而是它給出了一個「看起來很正確,但細節處有致命缺陷」的答案。

這種現象被稱為「幻覺的偽裝」。當你要求模型寫一段程式碼、一份合約草案或一個技術方案時,模型傾向於生成符合機率分佈的「流暢文本」,而非經過邏輯驗證的「正確結果」。如果你習慣於直接複製貼上,那麼你實際上是在把品質控制(QC)的壓力全部壓在自己的最後一次閱讀上。

要解決這個問題,你需要將 LLM 從一個「執行者」轉變為一個「執行者 + 自檢員」,而核心工具就是:驗收清單 (Acceptance Checklist)。

什麼是驗收清單工作流程?

驗收清單工作流程是指在 Prompt 中明確定義一套可量化的、二進位(是/否)的檢查標準,並強制模型在輸出最終結果之前,必須對照該清單進行逐項自檢,並將自檢過程公開展示。

這就像軟體工程中的單元測試或飛行員起飛前的檢查單——不依賴於「感覺」,而依賴於「核對」。

實踐指南:如何建構你的驗收清單

1. 定義「絕對禁區」與「必須項」

不要使用「盡可能準確」、「盡量簡潔」這種模糊詞彙。將要求轉化為具體的檢查點。

❌ 模糊要求: 「請確保程式碼沒有 Bug 且符合規範。」 ✅ 清单项:

  • 是否處理了 None 或空字串的邊界情況?
  • 是否所有變數命名都遵循 PEP8 規範?
  • 是否包含必要的錯誤處理 try-except 區塊?
  • 是否刪除了所有除錯用的 print 陳述式?

2. 建構 Prompt 的結構化指令

將驗收清單嵌入到 Prompt 的末尾,並規定輸出格式。

推薦指令模板:

「在給出最終答案之前,請先建立一個【驗收清單】表格。列出本任務的所有關鍵約束條件,並針對每一項標註 [PASS] 或 [FAIL]。如果某項為 [FAIL],請重新修改內容直到其變為 [PASS]。最後才輸出正式結果。」

3. 強制執行「反思循環」 (Reflection Loop)

如果任務極其複雜,可以採用兩步法:

  • Step 1: 生成初稿 $\rightarrow$ 根據清單自檢 $\rightarrow$ 列出缺陷。
  • Step 2: 根據 Step 1 的缺陷列表 $\rightarrow$ 生成終稿 $\rightarrow$ 二次核對。

實戰案例:撰寫技術 API 文件

假設你需要 LLM 為一個新介面寫文件。

糟糕的 Prompt: 「幫我寫這個介面的文件,要專業且詳細。」 $\rightarrow$ 結果:格式漂亮,但可能漏掉了某個必填參數。

驗收清單 Prompt:

「請為以下介面編寫技術文件。在輸出文件前,請對照以下【驗收清單】進行自檢:

  1. 參數完整性:是否涵蓋了所有 Request Body 中的必填欄位? (Yes/No)
  2. 類型準確性:每個欄位的類型(String, Integer, Boolean)是否與程式碼一致? (Yes/No)
  3. 錯誤碼覆蓋:是否列出了所有可能的 HTTP 狀態碼及其含義? (Yes/No)
  4. 範例可運行:提供的 JSON 請求範例是否語法正確且邏輯閉環? (Yes/No)

請先展示自檢表格,確認全部為 Yes 後再輸出文件。」

何時使用 vs 何時跳過

✅ 使用場景(高風險/高精度需求):

  • 程式碼生成:涉及生產環境部署、安全敏感邏輯、複雜演算法實現。
  • 法律/財務文案:涉及條款約束、數字計算、合規性要求。
  • 結構化資料提取:從長文中提取 JSON/CSV,要求欄位絕對對齊。
  • 多步驟指令執行:需要嚴格遵守 A $\rightarrow$ B $\rightarrow$ C 的順序且不能遺漏任何一步。

❌ 跳過場景(低風險/創意需求):

  • 腦力激盪:需要發散思維而非收斂精度時。
  • 文學創作/潤飾:追求的是語感和氛圍而非邏輯對齊時。
  • 簡單事實查詢:問題答案唯一且簡短時(如「法國首都是哪裡?」)。

Gotchas & 注意事項

  1. 防止「敷衍式勾選」:有些模型會直接輸出一排 [PASS] 但內容依然有錯。解決方法是要求它在 [PASS] 後面附帶一句理由(例如:「[PASS] - 已在第3行添加了 null check」)。
  2. 清單過長會導致注意力分散:單次任務的清單項目建議控制在 $5 \sim 8$ 項以內。過多會導致模型在關注 checklist 時忽略了內容的深度。
  3. 動態更新清單:當你發現模型在某個點反覆出錯時,不要只在對話中提醒它,而應將這個錯誤點永久加入到該類任務的【驗收清單】模板中。

本週行動建議 (Checklist for You)

  • 回顧過去一週 LLM 出錯最多的一個場景。
  • 為該場景拆解出 $3 \sim 5$ 個具體的二進位檢查點。
  • 將其轉化為一個 Prompt 模板並嘗試運行一次對比實驗(有無清單的區別)。

怎麼用

先在隔離環境中按記錄步驟重現,再決定是否採用這項技能。

實測效果

實驗室只記錄可重現結果,不把未經驗證的說法寫成結論。

踩坑

套用前核對權限、輸入、回復步驟和證據是否完整。

適用場景

適合環境條件與本報告證據範圍一致的任務。

不適用場景

缺少必要證據、隔離條件或回復控制時不要使用。