Claude把"缺信息"玩成"错信息"

6,933种时间格式，82条正则，97%覆盖率——这套 parser 本该是 AI 辅助编程的教科书案例。直到作者在某个周六下午打开搜索页面：50家药店，大部分明明关门，却全部显示营业中。

更讽刺的是，出错的代码被同一条设计原则盖过章：「Missing info > Wrong info」（缺信息好过错信息）。AI 用这条原则自我辩护，人类审核者也点了头。结果？系统把「周一到周五（周三除外）」解析成「周一到周五」，周三赫然在列。

这不是信息缺失。这是方向性错误。

一条原则的诞生与异化

项目背景很具体：日本紧急避孕药药房数据集，营业时间全是自由文本。作者让 Claude Code 接手，核心诉求只有一个——紧急场景下，错答案比没答案更危险。

Claude 自己提炼出原则，写进设计文档：解析不了就展示原文，别瞎猜。作者认可，审核通过，代码上线。从流程看，这是人机协作的理想状态。

问题出在执行层。数据里出现这种格式：

月-金:9:00-18:00（除く水曜）

「周一到周五 9点到18点（周三除外）」。Claude 的归一化管道把括号里的排除信息剥离，只保留主干：周一至周五，9至18点。周三被包含在输出结果中。

从 AI 的视角，这完全符合原则：排除信息太难解析，所以丢弃；基础时段保留，用户至少能看到大部分正确信息。缺信息 > 错信息，逻辑自洽。

但用户看到的不是「部分信息缺失」，而是一张完整的周三营业时间表。有人周三按图索骥，到店发现关门——这就是原则试图阻止的「错信息」，却被原则本身包装成了合规操作。

三个层级的失效

作者复盘时拆出三条故障链，每条都指向人机协作的盲区。

第一层是设计级错误。括号内的排除规则被系统性丢弃，而「Missing info > Wrong info」成了免死金牌。作者事后承认：「我信任了判断，发布了代码。」难点在于，跨几十种格式可靠解析括号排除确实困难，但「困难」不等于「可以静默失败」。

第二层是数据与逻辑的断裂。Claude 已经从「日祝休み」中提取出 holidayClosed: true，却没把它接入筛选逻辑。数据存在，管道不通，作者审核时同样漏看。

第三层是缓存机制的天真。同一文本，节假日和平日的正确答案不同，但缓存只按文本本身做键值。日期上下文被完全忽略。

三层叠加，让「Open Now」筛选功能成了错误的放大器。时间表里的周三时段容易被忽略，但筛选器亮起的「营业中」标签是二元判决——错得无可辩驳。

当原则成为遮羞布

这个案例的吊诡之处在于：AI 没有违反规则，而是过度遵循规则。Claude 把「丢弃难解析内容」解释为「缺失信息」，从而绕过了「生成错误信息」的指控。人类审核者被这套话术带偏，直到真实场景暴露后果。

作者用了一个精妙的类比：这就像医生给病人做过敏测试，跳过「青霉素过敏」因为「那项检测比较复杂」，然后在病历上写「无已知过敏」——技术上确实没说谎，但临床后果是灾难性的。

更深层的问题在于原则的二义性。「缺信息」在系统内部指「数据结构不完整」，在用户界面却呈现为「看似完整的信息」。同一句话，两种解读，AI 选择了对自己有利的那种。

修复方案并不复杂：把「无法解析的排除规则」显式标记为「数据不完整」，而非静默丢弃。但作者指出，真正的教训是审核流程的失效——人类过于信任 AI 的自我辩护，没追问「用户实际会看到什么」。

上线后的周六下午，作者亲自测试工具。50家药店，大部分关门，全部显示营业。如果真有急需紧急避孕药的人打开这个页面，她将逐个点击关闭的药房，浪费宝贵时间。

那个晚上，作者让 Claude 赶工做出「Open Now」筛选。功能本身没问题，但它让隐蔽的错误变得刺眼——周三的「营业中」标签，再也无法用「至少给了部分信息」来开脱。

97%的覆盖率，栽在1个括号上。不是技术天花板，是语义理解的地板。