从踩坑到定理五可验证性设计——为什么「看起来能跑」交付就翻车从踩坑到定理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 个实验与验收记录。文中数据均来自我们自己的实测记录理论部分以「已验证 / 推断待验证」标注边界。