別讓模型給自己打分：5 步設計 AI 深度任務的外部驗證

作者注：從驗收標準、數據隔離到獨立複覈，用 5 個步驟設計 AI 深度任務的外部驗證，避免模型自評造成的虛假完成。

模型回覆“任務已完成，結果準確”，卻經不起復現，這是許多 AI 使用者在處理深度任務時遇到的難題。本文將介紹一套可獨立運行的外部驗證設計方法，幫助你把“模型說做好了”變成“證據表明做好了”。

Claude 開發者 Felix Rieseberg 在 2026 年 10 月發表的實踐指南中明確建議：不要讓模型自己給自己打分，並堅持使用外部驗證。他認爲，最理想的形式是模型能夠自行運行、並立即獲得反饋的工具。InfoQ 於 2026 年 11 月 4 日發佈了這篇文章的中文譯文。

這不是一篇勸你“多檢查一遍”的提醒。原文給出了方向，本文在此基礎上進一步整理出可落地的設計步驟，涵蓋驗證手段的選擇、常見失效模式和多模型複覈方式。

核心價值：讀完本文，你將能爲自己的 AI 深度任務寫出一份驗證契約，讓模型在可判定的反饋中迭代，而不是在自我評價中結束。

AI 深度任務外部驗證核心要點

外部驗證的關鍵，不是增加一個檢查環節，而是讓判斷依據獨立於模型自身的推理過程。

要點	說明	價值
先定標準	開工前寫清通過條件，並儘量做到可判定	避免模型事後重新解釋目標
數據隔離	用模型沒有見過的數據或場景檢驗結論	區分真實發現與事後擬合
工具優先	優先使用能運行、能立即反饋的驗證器	讓模型自主迭代，減少人工盯守
證據留存	保存運行結果、日誌和復現步驟	讓人能夠審查結論，而不只是相信結論
獨立複覈	用不同方法和不同立場挑戰結果	發現單一驗證器遺漏的問題

爲什麼 AI 深度任務需要外部驗證

Rieseberg 所說的“深度”，是指採用領域頂尖專家使用的工具、技術和知識，深入底層數據，而不是停留在任務表面。任務越深入，人越難憑直覺判斷結果是否正確。一份措辭專業的流失分析，讀起來可能很有說服力，但這並不能證明其中的因果判斷成立。

他還提到一個常見現象：要求模型表現得像專家時，它往往只是換了一套詞彙，工作方法並沒有真正改變。自我評估很難發現這類問題，因爲評價者和生產者共享同一套假設。如果推理一開始就有偏差，模型的打分也可能沿着相同的偏差展開。

大膽的目標會讓驗證變得更加重要。原文建議設定看似不合理的目標，比如把網站加載時間從 10 秒壓縮到 200 毫秒，並要求模型繼續嘗試。這類目標之所以可用，是因爲 200 毫秒可以被測量。如果目標既激進又無法驗證，得到的很可能只是一份更自信的報告。

AI 深度任務外部驗證快速上手：5 步設計法

下面的方法不依賴特定模型或框架，你可以先選一個正在進行的任務來套用。如果暫時無法全部實現，建議優先完成前三步。

第 1 步：把任務目標改寫爲外部驗證標準

“分析得全面”“代碼質量高”都無法直接判定，需要改寫成可以通過或失敗的條件。比如，把“修好崩潰”改寫爲“按原始復現步驟運行不再崩潰，並且相關測試全部通過”。標準必須在模型開工前寫好，否則模型可能在完成後才調整成功的定義。

你可以先把下面這份驗證契約寫好，再交給模型執行：

字段	需要寫清什麼	示例
最終目標	真正想要的業務或工程結果	應用保持穩定，不再出現同類崩潰
原始材料	模型應直接使用的一手數據	崩潰報告、版本與 Git 提交的對應關係
驗證器	由什麼工具或數據判定結果	復現腳本、自動化測試、留出數據
通過條件	明確的閾值或判定規則	三個目標系統上均無法再復現崩潰
禁止事項	模型不得改動的內容	不得刪除測試，不得修改留出數據
提交證據	需要附帶的運行結果	命令、日誌、失敗記錄和最終結果
停止條件	何時結束或交給人處理	達到迭代上限後提交阻塞原因

第 2 步：切斷結論與驗證數據的聯繫

模型用同一份數據提出假設並證明假設，這並不是外部驗證。原文的用戶流失示例提供了很好的做法：讓模型從日誌中尋找最早的流失信號，再用它沒見過的數據證明該信號確實具有預測能力。實踐中可以把數據按時間切分，早期數據用於探索，後期數據用於檢驗。

留出數據最好由獨立腳本或人員保管，模型只能獲得運行結果，而不能直接讀取明細。若一次次根據結果調整方案，留出數據也會逐漸被“學會”。因此，重要結論最好再留一份只在最終驗收時使用的數據。

第 3 步：優先選擇模型能自行運行的外部驗證工具

驗證器越接近真實結果，反饋越快，模型就越能獨立迭代。下表按照常見任務整理了幾種外部驗證手段，選擇時不必追求單一的“最強方案”，而應按風險組合使用。

驗證手段	能證明什麼	反饋速度	主要侷限
自動化測試與復現腳本	指定行爲符合預期	快	只覆蓋已寫明的場景
性能測量工具	指標是否達到閾值	快	環境差異可能影響結果
留出數據回測	結論是否具有預測能力	中	歷史規律不一定持續
紅隊式方法審查	假設和證據鏈是否薄弱	中	判斷質量依賴審查方法
影子運行	方案在真實流程中是否有效	慢	週期長，組織成本較高
領域專家抽檢	結果是否符合專業判斷	慢	難以大規模覆蓋

第 4 步：把外部驗證接入模型的工作循環

驗證工具只有放進模型的工作環境，才能產生持續迭代的效果。原文的崩潰修復案例很有代表性：作者先讓 Claude 能方便地獲取崩潰報告，知道每個版本對應哪次 Git 提交，還能使用 Windows、macOS 和 Linux 電腦。具備這些條件後，模型才能獨立復現問題並驗證修復。

這也說明，外部驗證常常需要調整工作流程，而不只是修改提示詞。你需要開放必要的數據和工具，比如通過 MCP 連接器接入數據源，同時把權限控制在任務範圍內。循環設計至少要包含三項內容：

失敗反饋：返回具體的錯誤日誌和未通過項，而不是隻有“失敗”兩個字。
迭代上限：限定重試次數和總預算，防止模型陷入無效循環。
受保護對象：將測試、驗證腳本和留出數據設爲只讀，防止模型通過修改標準來“通過”。

第 5 步：用獨立複覈與並行運行完成外部驗證

單一驗證器通過，並不代表結論可靠。原文提到可以引入專門挑錯的“紅隊”，比如做空投資者和法務會計師，但重點不是模仿他們的口吻，而是使用他們真正的研究方法。例如，要求模型追溯每個關鍵數字的原始出處，或者主動尋找能夠推翻結論的數據。

對於流程類改動，還可以採用並行運行的方式。原文建議先用歷史數據證明新的覆盤機制本可以更早發現問題，再讓它與現有流程並行運行一個季度。這樣既能檢驗真實效果，也不必一開始就承擔完全替換舊流程的風險。

接入建議：如果需要讓不同模型分別承擔執行和複覈工作，可以通過 API易統一調用。API易提供本文涉及模型的 API 調用，兼容 OpenAI 與 Anthropic 接口格式，接入時一般只需按文檔配置 base_url、api_key 和 model。文檔地址：https://docs.apiyi.com

AI 深度任務外部驗證的常見失效模式

外部驗證也可能流於形式。下面這些問題在設計階段就應當考慮，否則驗證結果只會帶來一種虛假的安全感。

失效模式	典型表現	應對方法
修改標準	刪除失敗用例或放寬斷言	驗證器只讀，並審查相關改動
驗證集過擬合	指標持續上升，新數據上卻失效	保留一份最終驗收數據
循環論證	用模型生成的數據驗證模型的結論	回到原始日誌和一手材料
只驗形式	格式正確，但內容錯誤	增加業務規則和抽樣覈對
角色扮演	對話很像專家，成果卻沒有改善	要求執行具體方法並提交證據

其中，“第二個模型複覈”需要特別說明。它比自評更好，因爲可以暴露一部分盲點，但仍然屬於基於判斷的複覈，不能代替測試或真實數據。複覈時最好只提供任務標準、原始材料和最終產出，不提供前序對話，以減少原有推理對判斷的影響。

不同 AI 深度任務的外部驗證設計示例

以下示例可以作爲設計起點，具體閾值需要根據業務情況確定。

任務	只靠自評的做法	外部驗證設計
修復應用崩潰	模型解釋修復原理後宣佈完成	跨系統復現，確認修復後不再出現
尋找流失信號	模型給出一份合理的歸因報告	用未參與探索的數據檢驗預測能力
檢驗流失原因	模型沿用“新用戶引導有問題”的判斷	從原始數據尋找支持和反對的證據
優化加載速度	模型列出優化項並估算收益	在固定環境中測量，與目標閾值比較
重構業務覆盤	模型論證新方案更加先進	歷史回測後，與現有流程並行一個季度

判斷任務是否值得這樣設計，可以參考一個簡單的標準：錯誤的代價是否高於驗證的成本。如果只是改寫一封郵件，讀一遍可能就足夠了。但如果結果會影響線上系統或資源配置，就應當設計外部驗證。

常見問題 FAQ

Q1：什麼是 AI 深度任務的外部驗證？

它是指用獨立於模型自身判斷的依據來檢驗結果，比如自動化測試、性能測量、留出數據回測和專家審查。核心要求是，判斷標準不能由產出結果的模型臨時決定。

Q2：外部驗證和模型自檢有什麼區別？

模型自檢可以快速發現明顯的遺漏，但生產者和評價者共享相同的假設。外部驗證引入了獨立的證據來源，更適合判斷結果是否真實有效。兩者可以配合使用，但自檢不能作爲最終驗收依據。

Q3：模型越來越強，外部驗證還有必要嗎？

Rieseberg 認爲，隨着模型變聰明，這個問題最終可能得到解決，但他明確建議，至少在 2026 年 10 月仍應堅持外部驗證。這是階段性的實踐判斷。在模型自評的可靠性得到驗證之前，高風險任務仍應保留獨立檢驗。

Q4：哪些場景最需要外部驗證？

主要包括以下幾類任務：

– **工程修復**：崩潰修復、性能優化和數據遷移。
– **數據研究**：流失分析、因果判斷和預測信號發現。
– **長期運行的智能體流程**：需要模型在較少人工介入的情況下持續工作的任務。

Q5：如何通過 API 搭建多模型交叉複覈？

可以通過 API易統一接入，其接口兼容 OpenAI 與 Anthropic 格式：

1. 按照 API易文檔 https://docs.apiyi.com 配置接口地址和 API Key。
2. 在價格頁 https://docs.apiyi.com/models 覈對可用模型及其費用。
3. 爲執行和複覈分別配置不同的 `model`，複覈請求不攜帶執行階段的對話。
4. 將複覈意見與測試結果分開記錄，以測試和數據證據作爲優先依據。

Q6：外部驗證循環的成本如何估算？

總成本通常取決於迭代次數、上下文長度、輸出長度和複覈模型的數量。建議先在小樣本上跑幾輪，記錄每輪實際用量，再結合迭代上限估算預算。本文不列具體單價，模型價格、計費口徑、輸入輸出單價和緩存價格均以 API易價格頁 https://docs.apiyi.com/models 的實際數據爲準。

Q7：外部驗證有哪些限制？

測試只能覆蓋已定義的場景，回測無法保證歷史規律繼續成立，影子運行的週期也比較長。驗證通過只能說明結果在限定條件下得到了支持，並不等於絕對正確。涉及法律、財務和重大業務決策時，最終判斷仍應由相關責任人完成。

AI 深度任務外部驗證核心要點 Key Takeaways

核心原則：不要把模型自評當作驗收依據，判斷必須來自獨立證據。
標準前置：開工前寫好通過條件，防止事後重新定義成功。
數據隔離：用模型沒見過的數據檢驗其發現，避免循環論證。
工具優先：能運行、能立即反饋的驗證器最有利於自主迭代。
環境配套：模型需要獲得數據、工具和運行環境，才能完成自我修正。
複覈分層：第二模型用於發現盲點，不能替代測試和真實數據。
靈活接入：可通過 API易統一調用多個模型，降低交叉複覈的接入成本。

總結

設計 AI 深度任務的外部驗證時，可以記住以下三點：

先把目標變成可判定的標準：沒有通過條件，就無法判斷任務是否真正完成。
讓證據獨立於模型的推理：隔離數據、保護驗證器，並保留完整的運行記錄。
按風險組合驗證手段：工具提供快速反饋，複覈發現盲點，並行運行檢驗真實效果。

下一步可以挑選一個手頭的深度任務，先寫一份驗證契約，再讓模型開始工作。這樣做不只能減少錯誤，也讓你敢於提出更有挑戰性的目標，因爲無論目標多大膽，結果都有辦法接受檢驗。

如需搭建多模型執行與複覈流程，可以通過 API易進行調用測試，接入方式見 https://docs.apiyi.com，模型價格和計費口徑以 https://docs.apiyi.com/models 的實際數據爲準。

📚 參考資料

如何把目標定得更大膽：寫給 AI 使用者的實踐指南：InfoQ 中文譯文
鏈接： infoq.cn/article/F1ms7x7KI1p7UfocCywh
說明：包含高度、深度、廣度三個方向的實踐方法
How to be more ambitious: A tutorial for humans with models：Felix Rieseberg 原文
鏈接： felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models
說明：外部驗證建議及崩潰修復、用戶流失等案例的原始出處
API易文檔中心：接口接入說明
鏈接： docs.apiyi.com
說明：用於查詢 OpenAI 與 Anthropic 兼容格式的接入配置
API易模型與價格頁：模型及計費信息
鏈接： docs.apiyi.com/models
說明：模型價格、計費口徑和緩存價格均以此頁面爲準

作者：API易技術團隊
技術交流：歡迎在 API易網站首頁聯繫我們，更多資料可訪問 docs.apiyi.com 文檔中心

別讓模型給自己打分：5 步設計 AI 深度任務的外部驗證