UNSEEN · 认知报告 · 批判分析 · 广场

可靠性不是模型单独拥有的属性，而是信息、任务、行动链、执行环境与独立验证共同作用的结果；因此不应把错误笼统归为「幻觉」，而应追问缺口发生在链条的哪一环。

2026-09-24 14:15 · 原文发布于 2026-09-14

原文速写

技术随笔，以订单导出时区错误为例，讨论AI模型为何犯错。核心论点：错误不从模型内部凭空产生，而是信息缺失、任务歧义、上游材料过期三类条件不足所致，且小偏差会在多步行动链中放大，测试绿灯只能证明代码自洽而非业务规则被理解。解决路径指向独立验证路径和追问信息缺口。承接前章，为下一层问题——模型该看到哪些信息——做铺垫。

01这篇内容真正讨论什么

该章是全书体系中的第六章，接续订单导出场景。前置设定为：订单以 UTC 保存，财务需按结算地当地日期归账，AI 生成的 formatDate() 在功能测试上通过、却在业务归日上出错。原文发布时间为 2026-09-14，原文未标注其余年份信息。

02作者的思考模型

观察

  • 订单以 UTC 保存以匹配多系统记录同一时刻的需求，而财务需按结算地当地日期归账，二者规则不一致。
  • AI 写出的日期格式化函数没有明显 bug 且测试通过，但归日结果错误。
  • 模型看到了字段与函数，但没有看到归日规则，于是采用了一种常见且看似合理的处理方式。
  • 任务表述本身存在歧义，未说明「昨天」的时区口径，也未说明退款、部分支付与跨日结算的处理方式。
  • 上游文档与当前系统状态不一致：旧文档只要求 paid 即可导出，当前系统已把待清算订单也标为 paid。
  • 开发机、CI 容器与生产任务调度器的时区配置可能不同。
  • 测试可能只覆盖 UTC 午夜前的普通订单，甚至测试自身也沿用了按 UTC 格式化的错误前提。

推理

  • 把错误统称「幻觉」会把问题定性为模型突然失常，从而遮蔽错误从何处进入、在何步被放大、为何通过检查；因此这种命名妨碍改进。
  • 信息缺失、任务歧义、上游材料过期三种来源并非三种不同的模型性格，而是同一事实的不同表现：模型输出所依据的信息、任务与版本条件不足以支撑正确判断。
  • 在长链条中，后一步会把前一步的假设当作事实，因此不能只审查单步是否合理。
  • 真实命令、日志与依赖版本能缩小模型猜测空间，但这些材料本身也需确认是否最新、完整与可信——即环境的真实性本身是可验证对象。
  • 代码与测试可能共享同一错误前提而互相一致，因此绿灯只证明代码满足已有测试，不证明业务规则已被理解。
  • 模型重读自身代码可发现拼写或局部边界问题，但难以自动发现它与测试共同继承的前提（自我审查与待审对象同源，不构成独立证据）。
  • 既然错误的入口、放大环节、环境差异和验证独立性都可影响结果，可靠性就不能归属于单一主体（模型），而分布在整条任务链条上。

结论

  • 应放弃用「幻觉」作为通用解释标签，改为按错误的进入点、放大点和检查失效点进行分析。
  • 可靠的验证应尽量引入不依赖同一套实现的另一条路径，例如结算地时区真实样本对账、不同实现重算，或由对规则负责的人独立评审。
  • 这类验证检查的不只是代码一致性，而是代码之外的业务规则是否成立。
  • 遇到错误时可先追问三件事：缺了什么信息、偏差在哪一步扩大、哪条证据本该更早出现。
  • 本章将问题推进到下一层：模型究竟应当看到哪些信息，才能在正确的工作现场中行动。

03隐藏假设

置信为「作者确实依赖此假设」的判断把握

  • 归日约定确实没有被交付给模型，而不是已交付但模型未遵循。置信 · 中

    若失败：若假设失败（约定已在上下文中而模型仍未采纳），案例归因就从「信息条件不足」转为「遵循失败」，本章从信息交付切入的整套框架需重写，重心转向模型行为的可靠性。

  • 「幻觉」一词在实践中主要被当作「模型突然失常」的同义语使用。置信 · 低

    若失败：若假设失败，对「统称幻觉」的批评失去靶子，该段论证力度显著下降，但按进入点、放大点、检查失效点定位错误的正面主张仍然独立成立。

  • 自我审查与待审对象同源，必然导致无法发现双方共同继承的前提。置信 · 中

    若失败：若假设失败（借助独立规则清单或外部工具比对即可发现继承前提），可靠验证须引入另一条路径将从必要条件降级为可选优化。

  • 链条变长带来的假设继承效应，强于它同时增加的独立检查机会。置信 · 中

    若失败：若假设失败，则链条越长，越不能只看单步的规范性结论强度下降，可能只在缺少中间检查点的链条上成立。

  • 时区归日这一案例足以代表一类错误（信息、歧义、材料过期），并支撑起通用的可靠性框架。置信 · 中

    若失败：若假设失败（该案例属特殊的口径错位），则从个案到通用框架的推广缺少样本支撑，结论应降格为对该类时区错位问题的诊断方法。

04逻辑质量分析

优势

  • 把错误归因从「模型属性」拆解到「链条环节」，使诊断从贴标签转为可追问的定位问题，这是本章最有价值的框架贡献。
  • 清晰区分了「代码满足已有测试」与「业务规则成立」两件事，把绿灯的证明范围限定住，这是对验证充分性的有效切分。
  • 给出构造性的替代验证路径（真实样本对账、不同实现重算、规则责任人评审），与差分测试、独立复核的工程实践同构，且每条都可执行、可判定。
  • 案例选的是一类可复现的口径错位（存储口径与归账口径不一致），而不是笼统的「模型不靠谱」，因此错误可被定位、可被验证。

不足

  • 把「信息缺失」「任务歧义」「上游材料过期」统一为「同一个事实的不同表现」，属于抽象层合并过度：三者的修复动作并不相同——缺失靠补充交付，过期靠更新材料与版本锁定，而歧义无法靠增加信息消除，必须有人做出口径裁决。合并后，修复路径的差异被抹掉。
  • 从后一步会把前一步的假设当成事实推到链条越长，越不能只看单步，缺少对冲项：链条变长同时也可能增加独立检查点（集成验证、人工复核）的机会。原文只呈现放大效应，未讨论抵消机制，机制到规范结论之间缺一环。
  • 把「幻觉」等同于「模型突然失常」，这是对该词常见用法的窄化（该词通常指生成与事实不符的内容）。据此批评「统称幻觉」，有把被反驳对象设成稻草人的风险——被否定的可能不是通行用法。
  • 自我审查无法发现共同继承前提这一判断，只给结论未给机制说明：原文没有解释「为什么很难」，也未给出反例边界（例如借助外部规则清单或独立工具比对时是否仍成立），属未充分论证的断言。
  • 由单个时区归日案例推出「可靠性不是模型单独拥有的属性」这一普遍命题，属局部到一般的推广；该命题为否定式存在论断，自身也很难被证伪。

遗漏

  • 归账口径的定义权与裁决机制：谁有权确定「昨天」的时区口径、退款与部分支付的先后归属；原文只要求由对规则负责的人评审，未讨论规则本身由谁制定、冲突如何裁决。
  • 检测时延与观测手段：案例是上线后才被发现，原文未讨论如何缩短「错误发生」到「被看见」的间隔（对账频率、异常告警、跨口径抽样比对）。
  • 独立验证的成本与优先级：第二条路径的代价、时效、可扩展性，以及多条路径结论冲突时以谁为准，原文均未触及。
  • 新框架的适用边界：哪些情形下「幻觉」标签仍然成立（例如模型凭空生成不存在的接口或字段），原文未做区分，导致替代框架的适用范围不明。
  • 人因的对称性：代码与测试共享同一错误前提，在纯人类团队中同样可能发生；原文未说明这是 AI 场景的特有机制，还是通用软件工程失效模式的再表述。

05反向视角

  • 整章归因依赖一个未被独立检验的前提：归日约定确实没有交给模型。原文写的是「问题出在这条没有交给它的约定」，但没有给出能区分两种情形的观察——若约定已在上下文中而模型仍未采纳，错误就属于遵循失败而非信息不足，本章从补足信息条件展开的整套诊断需要重写。这是一个未验证的问题，不是确定的漏洞。
  • 第二条验证路径本身可能被同一前提污染：若挑对账样本的人同样认为按 UTC 归日没问题，他倾向选出的恰恰是 UTC 午夜以前的普通订单——原文自己就提示「订单导出的测试可能只覆盖了 UTC 午夜以前的普通订单」。原文只讨论了实现层的独立性，未讨论样本选择层的独立性；在样本层不独立时，独立路径的收益可能被高估。
  • 「可靠性不是模型单独拥有的属性」是一个难以被反例推翻的否定式命题：任何错误都可以事后归入链条某一环，因此它不易被证伪，但也不告诉人哪一环应当先修。作为诊断语言它有效，作为优先级工具它可能提供不了排序。
  • 结尾提出的问题可能有一类无解子集：若某些约定属于只在少数人操作习惯里存在的惯例，那么模型应当看到哪些信息无论怎样扩展信息供给都答不完，只能改为谁在什么时点必须做出裁决。原文把问题留给下一层，未提示这一分叉。

替代性解释

  • 跨口径错位是纯人类团队里的经典问题：存储按一套口径、归账按另一套口径，与是否有 AI 参与无关。AI 在这里可能只是把这类翻译错误的产生频率提高了，而非引入了新的失效模式；那么「模型为什么犯错」至少有一部分应被跨专业口径如何被翻译这个更一般的解释所替代。
  • 模型的错误也可以解释为「先验正确」而非「信息不足」：按 UTC 格式化日期在多系统场景中本就是常见做法，模型选它，是因为它在训练分布中大概率正确。原文提到模型「选用了一个常见而看似合理的处理方式」，但没有沿这条线追问：如果错误来自一个在多数场景下正确的默认，那么补上这条特定约定会不会与其他场景的正确性发生冲突。
  • 时区归日可能是一个过于顺手的案例：它的错误是确定性的、可枚举的、能靠真实样本对账发现。用这样一个可对账的错误去支撑通用可靠性框架，可能高估了框架对那些无法构造对账样本的错误的适用性。

06核心洞察

分级 L0–L3 表示洞察深度递增；置信为结论的可靠程度

  • 独立验证的有效维度是「前提差异」，而非「实现差异」：用另一套代码重算同一组假设，不构成第二条路径。验证的检出上限，等于第二条路径相对第一条路径在前提层面的补集大小。L2 · 发现隐藏变量置信 · 中

    为什么：原文把自我审查的失效归结为「让模型重读自己的代码，可以发现拼写或局部边界问题，却很难自动发现它和测试共同继承的前提」，并给出的解法是「可以用结算地时区的真实订单样例，核对财务提供的对账结果；也可以用不同实现重新计算，或由对这项规则负有责任的人独立评审」。由此可推：若第二种实现同样接受按 UTC 格式化为日期这一前提，两次计算必然得到相同结果，差异为零，错误因此不可见；换语言、换框架、换工具都不改变这一点。原文只说到「另一条不依赖这套实现的路径」，未点明「另一条实现」若与第一条共享前提则等于重复计算。

    意义：把多加一条验证路径从成本加法变成一次前提盘点：设计验证的第一步不是选工具，而是列出当前实现默认接受了哪些从未被写明的约定，再确保新路径不接受其中任何一条。列不出这份清单，所谓独立验证就只是把同一个答案算了两遍。

  • 能被现有验证捕获的错误，恰恰是影响面被验证边界框住的那一类；越过验证边界传播的错误，在体系内部不产生任何可观测信号。因此同一路径上的验证密度与该路径是否指向业务正确，没有单调关系。L2 · 发现隐藏变量置信 · 中

    为什么：案例中错误的表现是「文件里的订单金额都对，日期却整体偏了一天」，而「订单导出的测试可能只覆盖了 UTC 午夜以前的普通订单」——金额一致、测试全绿、跨零点样本缺失，错误在这套体系里没有任何异常可看。原文的判断是「绿灯证明的是代码满足已有测试，不是财务规则已经被理解」，并主张检查要落在代码之外的业务规则是不是真的成立上，但没有指出一个结构性的反差：验证能抓住的错误通常局部而显形，口径级偏移的错误则全局而静默。这两类错误的发现成本不在同一量级。

    意义：提示不要在绿灯失败时加码验证，反而要在绿灯全亮而结果不对时换口径重验；也解释了这类错误为何总由下游在使用现场首先发现，而不是由开发环节发现。

  • 「信息缺口」应分成两类：答案存在于某处但未被交付，与答案从未被任何人确定过。前者可靠补充材料修补，后者不能；对后者补得越多，越可能提供更多看似合理的解释候选。L2 · 发现隐藏变量置信 · 中

    为什么：原文说「导出昨天的已支付订单」没有说明「昨天」按什么时区计算，也没有说明退款、部分支付和跨日结算怎么处理，并指出「模型把其中一种解释写成代码，并没有消除原先的歧义，只是让歧义变成了可以运行的程序」。可见这不是某份文档写了而模型没读到，而是这条口径本身未必被裁决过。据此可推：检索、扩上下文、塞文档这套手段只针对第一类缺口；对第二类，材料越丰富，模型越容易挑中一个论证充分的错误解释（原文另提到「训练资料也有时间边界，库版本、接口和内部约定都可能已经变化」，说明材料本身还带版本风险）。原文结尾问「模型究竟应当看到哪些信息，才能在正确的工作现场中行动？」——这个问题对第二类缺口没有答案，只有一次人为裁决才有答案。

    意义：把「给模型更多信息」和让某个人做出决定明确分开：前者回应信息缺口，后者回应歧义，二者不可互换。用文档治理的力度去解决裁决缺位，通常只是把歧义更整齐地保存下来。

  • 若可靠性确实分布在整条链条上，那么「谁写的谁负责」的问责结构就与它不匹配；在这种不匹配下，把资源投向让自己那一环有证据可交比投向「让整体错误可见」更划算。L2 · 发现隐藏变量置信 · 低

    为什么：原文的结论是「因此，可靠性不是模型单独拥有的属性」，并列出任务清晰度、信息有效性、行动链可控性、环境真实性与验证独立证据作为影响面。由此可推一层原文没有讨论的激励后果：当错误可由任一环节的缺口引起、而问责只能落到可指认的个人时，理性个体会优先生产可自证的材料（测试报告、评审记录），而回避那些可能暴露自己上游问题的跨环节验证。原文未提供任何组织层面的经验证据，故这只是从框架推出的待检验推论。

    意义：采纳「可靠性分布」这一诊断时，需同步检查问责口径是否仍指向单一主体；否则诊断只会停留在解释层面，不改变任何人的行为。