從踩坑到定理五可驗證性設計——為什么「看起來能跑」交付就翻車從踩坑到定理Dify 應用工程的通用理論 · 5/7基于 Dify 1.16.x 69 個實戰實驗實測2026-08 摘要LLM 應用必須設計可觀測性、可審計性、可重復驗證路徑否則無法被獨立驗收。本文給出三層用例功能點/節點/路徑 三分歸因應用/用例/環境的完整驗證體系——可靠是設計出來的不是驗收時發現的。本文要解決的核心痛點驗收時「看起來能跑」交付后邊界場景連炸客戶問「你怎么證明可靠」你只有「我點過幾遍」驗收 FAIL 了到底是應用錯、用例錯還是環境錯本文講可驗證性設計可觀測、可審計、可復現——可靠是設計出來的不是驗收時發現的。前四篇都在講「怎么設計」這一篇講「怎么證明」。這是整個系列的落點前面所有定理最后都要回答一個問題——你怎么證明它真的可靠大多數 LLM 應用團隊的做法是開發完手工點幾遍「看起來能跑」就交付了。然后用戶發現問題團隊說「這是模型的問題」。這條路線我們走過翻過車后來徹底換了方法。場景交付一個 RAG 問答應用驗收階段。第一版我們的驗收方式是把典型問題在界面上點一遍「回答得還行」出驗收報告。結果被客戶當場打臉人家問了三個邊界問題——「手冊里沒寫的你怎么回答」「兩個相似故障你答錯了一個。」「換個問法你給的依據變了。」我們無從辯駁因為我們根本沒有證據證明它可靠只有「我點過幾遍沒問題」的印象。那次之后我們立了一條鐵律驗收不是流程是設計的一部分。可驗證性必須在設計期就造進應用里。結論定理 6可驗證性設計LLM 應用必須設計可觀測性中間狀態可查、可審計性輸入輸出可回溯、可重復驗證路徑同樣的輸入可復現驗證否則無法被獨立驗收。推導來源LLM 是黑盒 概率性 → 黑盒不可驗證 → 驗證能力必須在設計期造進去而不是驗收時才想。這條定理是四個約束維度理論的應用層它不增加新的維度而是要求前四個維度的每條設計都「可被證明」。推導鏈為什么「看起來能跑」不算數一個應用要能被獨立驗收必須同時滿足三個條件可觀測運行的中間狀態要能查。LLM 節點的輸入輸出、檢索節點實際檢索了什么、改寫節點把問題改成了什么——這些中間值必須有記錄可查。沒有可觀測性出了問題只能猜。可審計輸入輸出要能回溯。一次回答依據了哪幾個文檔段落、結論和依據對不對得上——要能回放。不能回放就無法判斷「這次答錯了」是模型問題還是檢索問題。可重復驗證同樣的輸入要能復現驗證路徑。不是「點一次看看」是「同配置、同輸入、可重復執行用例」——驗收的每個結論都要有可重復的執行記錄支撐。這三個條件的反面就是「看起來能跑」中間值看不到、回答依據說不清、驗證結論無法復現。三個條件全部不滿足這個應用就是不可驗收的——無論它實際質量多高。正例實證一套完整的驗證體系長什么樣我們最終形成了一套完整的驗證方法論核心是測試分層 驗收基線化第一層節點級驗證斷言形狀不斷言措辭。每個確定性節點驗證輸入輸出契約LLM 節點驗證輸出形狀字段存在、類型正確、值合法不驗證措辭——因為措辭是采樣結果逐字斷言是錯誤預期。這一層回答「節點壞了沒有」。第二層鏈路級驗證按路徑枚舉端到端用例。按業務拓撲枚舉路徑主路徑、分支路徑、失敗路徑、邊界路徑每條路徑一個端到端用例。這一層回答「鏈路斷了沒有」。兩層合起來覆蓋了「節點失效局部」和「鏈路失效全局」兩類問題——對應定理 5。第三層驗收基線化斷言事實不斷言措辭。驗收用例先全部輸出 → 用戶確認基線化 → 執行時嚴格按基線跑中途不因應用特殊性改用例。同一個問題采樣多次看結論是否一致——一致性斷言的是「事實」不是「表述」。結論一致、表述不同 正常波動結論都變了 工程缺陷。這一層回答「它穩定嗎」。EDD 保證這套三層驗證落地的核心不是「要求做驗證」而是驗證結果不可繞過——六道結構性保障 一、三層驗證 ? EDD 對應 - 節點級驗證斷言形狀不斷言措辭→ EDD 硬斷言層字段名與 TR2 一致性/禁區觸發/工具調用順序機器可執行 TR2 字段表Mock Schema——形狀契約的真相源 - 鏈路級驗證路徑枚舉端到端→ TR3 用例三來源成功標準→端到端用例主路徑、邊界禁區→負向用例失敗/邊界路徑 - 驗收基線化斷言事實不斷言措辭→ 用例集基線化 硬/軟斷言分層——「結論一致表述不同正常波動結論變了工程缺陷」正是軟斷言的判定語義 二、EDD 的六道落地保障為什么它不會停留在文檔里 1. 門禁強制TR3/TR4 是收尾正式關卡不參與循環——驗證是必經之門不是可選動作 2. 收斂前提MRT 目標達成 應用形態穩定 錯誤清單飽和 才進 TR3——驗證在正確時機跑不早跑不亂跑 3. 基線紀律用例集基線化后嚴格執行——「嚴格按用例執行」執行器與用例逐字一致AST 校驗中途不因應用特殊性改用例這是 dify-app-testing 的 E 系列執行紀律 4. 自斷后路鐵律交付期不手工改輸出只改系統——錯了改工作流/提示詞/加斷言直到自動跑通——驗證結果不可繞過手工改繞過循環錯誤不進清單資產不沉淀 5. 歸因三分FAIL 必須歸因應用缺陷/用例缺陷/執行器缺陷基線后缺陷只標識不改——鍋不混修復有路徑 6. 裁判權分離TR4 裁判是「硬標準」不是人不會失真 獨立驗收正交只報告不修改——運動員兼裁判問題的解法 三、加一層資產化 黃金集帶 Source 標注復用前回歸100% 通過才交付——驗證基線不只是本次交付的門禁是跨項目復用的資產下一單直接繼承基線 一句話EDD 讓驗證落地靠的是「繞不過去」——門禁強制 自斷后路 基線紀律 歸因 裁判分離驗證是體系的一等公民。三層合起來的執行鏈路三層用例是否功能點級端到端鏈路節點級輸入輸出斷言路徑級按拓撲枚舉執行FAIL?三分歸因應用缺陷修應用用例缺陷改用例環境問題重跑基線化驗收報告獨立驗收只報告不修改。交付側和驗收側分開驗收方只做驗證和報告不改應用。為什么因為「改完再測」和「測完再改」混在一起永遠說不清質量是誰的。獨立驗收讓「缺陷歸因」干凈——應用問題歸應用用例問題歸用例環境問題歸環境三分法明確責任。這套體系跑下來交付的每個應用都有完整的驗證證據鏈節點級斷言記錄、鏈路級用例執行記錄、基線化驗收報告。客戶再問「你怎么證明可靠」我們給出的是可回放的執行記錄不是「我點過幾遍」。反例實證驗收翻車的三種姿勢反例 1手點驗收。現象驗收「看起來能跑」交付后邊界場景連炸。根因手點無法覆蓋路徑、無法復現、無法留痕——「點過幾遍沒問題」是印象不是證據。修復路徑枚舉用例 執行記錄留痕。反例 2驗收時改應用。現象測試發現一個問題當場改應用改完「重測一下」報告里分不清哪些是原樣測的、哪些是改后測的。根因驗證與修改混在一起基線被污染。修復基線化 獨立驗收——先按基線跑完拿結果再統一歸因再修應用。反例 3斷言措辭。現象驗收用例斷言「回答必須一字不差」模型措辭一變就報 FAIL。根因把采樣結果當確定性斷言——這是 LLM 應用驗收最常見的自欺把用例缺陷當應用缺陷。修復斷言事實不斷言措辭同一問題多輪采樣看結論一致性。這條經驗后來獨立成方法論——「如何區分 AI 幻覺與用例缺陷」FAIL 先分清「誰錯了」再動手修。三個反例的共性都是驗證方法本身有缺陷不是應用有缺陷。這就是為什么說「可驗證性是設計出來的」——驗證方法設計錯了再好的應用也驗不出來。擴展驗證體系的落地形態——三層用例 三分歸因這套方法論具體落到項目上是三層用例設計 三分歸因的固定組合這里把細節展開三層用例功能點級、節點級、路徑級。功能點級端到端鏈路回答「這個功能能用嗎」——典型輸入走完整鏈路看最終輸出。節點級逐節點輸入輸出斷言回答「這個節點對嗎」——確定性節點嚴格斷言LLM 節點形狀斷言。路徑級按拓撲枚舉業務路徑回答「這條鏈路斷了嗎」——主路徑、分支路徑、失敗路徑、邊界路徑全覆蓋。三層合起來把「驗證」從一次性的「我點過幾遍」變成了可執行的用例集。每一層都有明確的判定標準執行結果可記錄、可回放。三分歸因應用缺陷 / 用例缺陷 / 環境問題。驗收中遇到 FAIL第一件事不是修是歸因應用缺陷應用行為不符合預期——修應用。用例缺陷用例本身設計錯了斷言措辭、預期錯誤、輸入不真實——改用例不修應用。環境問題依賴不可用、限流、網絡——記錄環境重跑。三分歸因的價值在于防止一個最常見的自欺把用例缺陷當應用缺陷修——應用本來是對的因為用例斷言錯了報 FAIL然后團隊去「修應用」越修越錯。先歸因再動手是驗收的第一紀律。這套組合跑下來每個交付項目都有一份完整的驗證證據鏈三層用例集 執行記錄 歸因記錄 基線化驗收報告。這就是「可驗證性設計」在項目里的最終形態——不是一篇方法論是一套每次交付都會執行的固定動作。實踐動作設計時應用設計里強制包含可觀測性——LLM 節點輸出留痕、檢索節點記錄實際檢索詞與命中段、關鍵中間值可查。不可觀測的節點設計打回。評審時用「三個條件」過一遍——中間狀態能查嗎輸入輸出能回溯嗎驗證路徑可重復嗎任一不滿足補設計。驗收時先基線化用例先確認再執行→ 分層執行節點級 鏈路級→ 統一歸因應用/用例/環境三分→ 結論基線化斷言事實。排障時回答不一致先看節點執行記錄取證再按歸因法分類崩潰/漂移/生成禁止猜。邊界與版本版本無關定理 6 是 LLM 應用的普遍規律——任何平臺、任何框架下黑盒概率系統的可驗證性都只能靠設計期造入。版本相關的只是取證手段節點執行記錄的 API、日志格式隨平臺版本變化。邊界說明本系列的驗證方法論基于文本型 RAG 應用與工作流應用實測多模態應用的驗證維度圖像輸出如何斷言未在本系列實測范圍內推斷待驗證。收尾可驗證性設計是四個約束維度理論的匯合點平臺約束決定你能觀測什么節點執行記錄、LLM 行為決定你該斷言什么形狀與事實不是措辭、架構決策決定你該怎么分層節點級 鏈路級、數據/記憶決定你該審計什么檢索命中段與依據。四個維度合起來才構成「可證明的可靠」。下一篇從踩坑到定理六盲區與開放問題——這套理論有什么不能信的地方我們誠實地面對這套理論的邊界性能/成本這些我們實測還不充分的地方、平臺版本演進帶來的不確定性、以及理論本身的自我檢驗方法。討論區你驗收過 LLM 應用嗎有沒有經歷過「看起來能跑、交付就翻車」驗收 FAIL 時你分得清是應用錯還是用例錯嗎評論區聊聊你的驗收方法論。如果覺得有收獲歡迎點贊 收藏 關注這是激勵我更新這個硬核系列的最大動力。本文基于真實項目交付經驗撰寫Dify 1.16.x 環境、69 個實驗與驗收記錄。文中數據均來自我們自己的實測記錄理論部分以「已驗證 / 推斷待驗證」標注邊界。 從踩坑到定理（五）：可驗證性設計——為什么「看起來能跑」交付就翻車？
從踩坑到定理五可驗證性設計——為什么「看起來能跑」交付就翻車從踩坑到定理Dify 應用工程的通用理論 · 5/7基于 Dify 1.16.x 69 個實戰實驗實測2026-08 摘要LLM 應用必須設計可觀測性、可審計性、可重復驗證路徑否則無法被獨立驗收。本文給出三層用例功能點/節點/路徑 三分歸因應用/用例/環境的完整驗證體系——可靠是設計出來的不是驗收時發現的。本文要解決的核心痛點驗收時「看起來能跑」交付后邊界場景連炸客戶問「你怎么證明可靠」你只有「我點過幾遍」驗收 FAIL 了到底是應用錯、用例錯還是環境錯本文講可驗證性設計可觀測、可審計、可復現——可靠是設計出來的不是驗收時發現的。前四篇都在講「怎么設計」這一篇講「怎么證明」。這是整個系列的落點前面所有定理最后都要回答一個問題——你怎么證明它真的可靠大多數 LLM 應用團隊的做法是開發完手工點幾遍「看起來能跑」就交付了。然后用戶發現問題團隊說「這是模型的問題」。這條路線我們走過翻過車后來徹底換了方法。場景交付一個 RAG 問答應用驗收階段。第一版我們的驗收方式是把典型問題在界面上點一遍「回答得還行」出驗收報告。結果被客戶當場打臉人家問了三個邊界問題——「手冊里沒寫的你怎么回答」「兩個相似故障你答錯了一個。」「換個問法你給的依據變了。」我們無從辯駁因為我們根本沒有證據證明它可靠只有「我點過幾遍沒問題」的印象。那次之后我們立了一條鐵律驗收不是流程是設計的一部分。可驗證性必須在設計期就造進應用里。結論定理 6可驗證性設計LLM 應用必須設計可觀測性中間狀態可查、可審計性輸入輸出可回溯、可重復驗證路徑同樣的輸入可復現驗證否則無法被獨立驗收。推導來源LLM 是黑盒 概率性 → 黑盒不可驗證 → 驗證能力必須在設計期造進去而不是驗收時才想。這條定理是四個約束維度理論的應用層它不增加新的維度而是要求前四個維度的每條設計都「可被證明」。推導鏈為什么「看起來能跑」不算數一個應用要能被獨立驗收必須同時滿足三個條件可觀測運行的中間狀態要能查。LLM 節點的輸入輸出、檢索節點實際檢索了什么、改寫節點把問題改成了什么——這些中間值必須有記錄可查。沒有可觀測性出了問題只能猜。可審計輸入輸出要能回溯。一次回答依據了哪幾個文檔段落、結論和依據對不對得上——要能回放。不能回放就無法判斷「這次答錯了」是模型問題還是檢索問題。可重復驗證同樣的輸入要能復現驗證路徑。不是「點一次看看」是「同配置、同輸入、可重復執行用例」——驗收的每個結論都要有可重復的執行記錄支撐。這三個條件的反面就是「看起來能跑」中間值看不到、回答依據說不清、驗證結論無法復現。三個條件全部不滿足這個應用就是不可驗收的——無論它實際質量多高。正例實證一套完整的驗證體系長什么樣我們最終形成了一套完整的驗證方法論核心是測試分層 驗收基線化第一層節點級驗證斷言形狀不斷言措辭。每個確定性節點驗證輸入輸出契約LLM 節點驗證輸出形狀字段存在、類型正確、值合法不驗證措辭——因為措辭是采樣結果逐字斷言是錯誤預期。這一層回答「節點壞了沒有」。第二層鏈路級驗證按路徑枚舉端到端用例。按業務拓撲枚舉路徑主路徑、分支路徑、失敗路徑、邊界路徑每條路徑一個端到端用例。這一層回答「鏈路斷了沒有」。兩層合起來覆蓋了「節點失效局部」和「鏈路失效全局」兩類問題——對應定理 5。第三層驗收基線化斷言事實不斷言措辭。驗收用例先全部輸出 → 用戶確認基線化 → 執行時嚴格按基線跑中途不因應用特殊性改用例。同一個問題采樣多次看結論是否一致——一致性斷言的是「事實」不是「表述」。結論一致、表述不同 正常波動結論都變了 工程缺陷。這一層回答「它穩定嗎」。EDD 保證這套三層驗證落地的核心不是「要求做驗證」而是驗證結果不可繞過——六道結構性保障 一、三層驗證 ? EDD 對應 - 節點級驗證斷言形狀不斷言措辭→ EDD 硬斷言層字段名與 TR2 一致性/禁區觸發/工具調用順序機器可執行 TR2 字段表Mock Schema——形狀契約的真相源 - 鏈路級驗證路徑枚舉端到端→ TR3 用例三來源成功標準→端到端用例主路徑、邊界禁區→負向用例失敗/邊界路徑 - 驗收基線化斷言事實不斷言措辭→ 用例集基線化 硬/軟斷言分層——「結論一致表述不同正常波動結論變了工程缺陷」正是軟斷言的判定語義 二、EDD 的六道落地保障為什么它不會停留在文檔里 1. 門禁強制TR3/TR4 是收尾正式關卡不參與循環——驗證是必經之門不是可選動作 2. 收斂前提MRT 目標達成 應用形態穩定 錯誤清單飽和 才進 TR3——驗證在正確時機跑不早跑不亂跑 3. 基線紀律用例集基線化后嚴格執行——「嚴格按用例執行」執行器與用例逐字一致AST 校驗中途不因應用特殊性改用例這是 dify-app-testing 的 E 系列執行紀律 4. 自斷后路鐵律交付期不手工改輸出只改系統——錯了改工作流/提示詞/加斷言直到自動跑通——驗證結果不可繞過手工改繞過循環錯誤不進清單資產不沉淀 5. 歸因三分FAIL 必須歸因應用缺陷/用例缺陷/執行器缺陷基線后缺陷只標識不改——鍋不混修復有路徑 6. 裁判權分離TR4 裁判是「硬標準」不是人不會失真 獨立驗收正交只報告不修改——運動員兼裁判問題的解法 三、加一層資產化 黃金集帶 Source 標注復用前回歸100% 通過才交付——驗證基線不只是本次交付的門禁是跨項目復用的資產下一單直接繼承基線 一句話EDD 讓驗證落地靠的是「繞不過去」——門禁強制 自斷后路 基線紀律 歸因 裁判分離驗證是體系的一等公民。三層合起來的執行鏈路三層用例是否功能點級端到端鏈路節點級輸入輸出斷言路徑級按拓撲枚舉執行FAIL?三分歸因應用缺陷修應用用例缺陷改用例環境問題重跑基線化驗收報告獨立驗收只報告不修改。交付側和驗收側分開驗收方只做驗證和報告不改應用。為什么因為「改完再測」和「測完再改」混在一起永遠說不清質量是誰的。獨立驗收讓「缺陷歸因」干凈——應用問題歸應用用例問題歸用例環境問題歸環境三分法明確責任。這套體系跑下來交付的每個應用都有完整的驗證證據鏈節點級斷言記錄、鏈路級用例執行記錄、基線化驗收報告。客戶再問「你怎么證明可靠」我們給出的是可回放的執行記錄不是「我點過幾遍」。反例實證驗收翻車的三種姿勢反例 1手點驗收。現象驗收「看起來能跑」交付后邊界場景連炸。根因手點無法覆蓋路徑、無法復現、無法留痕——「點過幾遍沒問題」是印象不是證據。修復路徑枚舉用例 執行記錄留痕。反例 2驗收時改應用。現象測試發現一個問題當場改應用改完「重測一下」報告里分不清哪些是原樣測的、哪些是改后測的。根因驗證與修改混在一起基線被污染。修復基線化 獨立驗收——先按基線跑完拿結果再統一歸因再修應用。反例 3斷言措辭。現象驗收用例斷言「回答必須一字不差」模型措辭一變就報 FAIL。根因把采樣結果當確定性斷言——這是 LLM 應用驗收最常見的自欺把用例缺陷當應用缺陷。修復斷言事實不斷言措辭同一問題多輪采樣看結論一致性。這條經驗后來獨立成方法論——「如何區分 AI 幻覺與用例缺陷」FAIL 先分清「誰錯了」再動手修。三個反例的共性都是驗證方法本身有缺陷不是應用有缺陷。這就是為什么說「可驗證性是設計出來的」——驗證方法設計錯了再好的應用也驗不出來。擴展驗證體系的落地形態——三層用例 三分歸因這套方法論具體落到項目上是三層用例設計 三分歸因的固定組合這里把細節展開三層用例功能點級、節點級、路徑級。功能點級端到端鏈路回答「這個功能能用嗎」——典型輸入走完整鏈路看最終輸出。節點級逐節點輸入輸出斷言回答「這個節點對嗎」——確定性節點嚴格斷言LLM 節點形狀斷言。路徑級按拓撲枚舉業務路徑回答「這條鏈路斷了嗎」——主路徑、分支路徑、失敗路徑、邊界路徑全覆蓋。三層合起來把「驗證」從一次性的「我點過幾遍」變成了可執行的用例集。每一層都有明確的判定標準執行結果可記錄、可回放。三分歸因應用缺陷 / 用例缺陷 / 環境問題。驗收中遇到 FAIL第一件事不是修是歸因應用缺陷應用行為不符合預期——修應用。用例缺陷用例本身設計錯了斷言措辭、預期錯誤、輸入不真實——改用例不修應用。環境問題依賴不可用、限流、網絡——記錄環境重跑。三分歸因的價值在于防止一個最常見的自欺把用例缺陷當應用缺陷修——應用本來是對的因為用例斷言錯了報 FAIL然后團隊去「修應用」越修越錯。先歸因再動手是驗收的第一紀律。這套組合跑下來每個交付項目都有一份完整的驗證證據鏈三層用例集 執行記錄 歸因記錄 基線化驗收報告。這就是「可驗證性設計」在項目里的最終形態——不是一篇方法論是一套每次交付都會執行的固定動作。實踐動作設計時應用設計里強制包含可觀測性——LLM 節點輸出留痕、檢索節點記錄實際檢索詞與命中段、關鍵中間值可查。不可觀測的節點設計打回。評審時用「三個條件」過一遍——中間狀態能查嗎輸入輸出能回溯嗎驗證路徑可重復嗎任一不滿足補設計。驗收時先基線化用例先確認再執行→ 分層執行節點級 鏈路級→ 統一歸因應用/用例/環境三分→ 結論基線化斷言事實。排障時回答不一致先看節點執行記錄取證再按歸因法分類崩潰/漂移/生成禁止猜。邊界與版本版本無關定理 6 是 LLM 應用的普遍規律——任何平臺、任何框架下黑盒概率系統的可驗證性都只能靠設計期造入。版本相關的只是取證手段節點執行記錄的 API、日志格式隨平臺版本變化。邊界說明本系列的驗證方法論基于文本型 RAG 應用與工作流應用實測多模態應用的驗證維度圖像輸出如何斷言未在本系列實測范圍內推斷待驗證。收尾可驗證性設計是四個約束維度理論的匯合點平臺約束決定你能觀測什么節點執行記錄、LLM 行為決定你該斷言什么形狀與事實不是措辭、架構決策決定你該怎么分層節點級 鏈路級、數據/記憶決定你該審計什么檢索命中段與依據。四個維度合起來才構成「可證明的可靠」。下一篇從踩坑到定理六盲區與開放問題——這套理論有什么不能信的地方我們誠實地面對這套理論的邊界性能/成本這些我們實測還不充分的地方、平臺版本演進帶來的不確定性、以及理論本身的自我檢驗方法。討論區你驗收過 LLM 應用嗎有沒有經歷過「看起來能跑、交付就翻車」驗收 FAIL 時你分得清是應用錯還是用例錯嗎評論區聊聊你的驗收方法論。如果覺得有收獲歡迎點贊 收藏 關注這是激勵我更新這個硬核系列的最大動力。本文基于真實項目交付經驗撰寫Dify 1.16.x 環境、69 個實驗與驗收記錄。文中數據均來自我們自己的實測記錄理論部分以「已驗證 / 推斷待驗證」標注邊界。