Claude把设计原则用反了：1个括号让紧急避孕药用户白跑3公里

97%覆盖率、82条正则、6933种时间格式——这组数字曾让我以为项目已经收尾。直到周六下午我亲自打开工具，搜索"现在营业"的药店，50个结果里大半是关门的。有人急需紧急避孕药时，这个筛选器会告诉他们：去，这家店开着。实际上呢？门锁着。

那个被括号吃掉的水曜日

问题藏在一条典型数据里：月-金:9:00-18:00（除く水曜）。翻译过来是"周一至周五9点到18点（周三除外）"。Claude的解析管线把括号里的排除信息剥离，保留了"周一至周五9-18"的主干，输出结果里周三赫然在列。

从代码视角看，这完全符合我们共同确立的设计原则：Missing info > Wrong info（信息缺失优于错误信息）。括号里的排除规则太复杂，跨几十种格式做可靠解析代价太高，不如丢弃。Claude把这个判断写进了设计文档，我也点了头。

但用户看到的不是"信息缺失"。用户看到的是一个完整的周三营业时间：9:00-18:00。他们周三跑去，发现药店关门。这不是"缺失"，这是实打实的错误信息——恰恰是我们原则发誓要杜绝的那种。

Claude用原则为错误辩护，我也跟着信了。直到"现在营业"筛选器把问题摊成二进制：之前的时间表网格还能让人眼滑过去，现在一个明确的"营业中"标签打在关门的药店上，错得无可抵赖。

三层失效，我漏看了两层

事后复盘，三个独立故障叠在一起。

第一层是设计级错误：排除信息被丢弃。括号里的（除く水曜）进了垃圾桶，我的原则给它发了通行证。这是最致命的，因为它把错误伪装成负责任的保守策略。

第二层是 plumbing 断裂：Claude其实已经从"日祝休み"里提取了 holidayClosed: true，但筛选器逻辑没接这根线。数据在仓库里躺着，管道没通到水龙头。我审代码时也没盯这条链路。

第三层是缓存失明：同一条文本，节假日和平日的正确答案不同，但缓存只按文本本身做键。节假日查询时，系统可能直接返回平日缓存的"营业"结论。

三层里我只可能抓住第三层——如果我当时想到测节假日场景的话。但第一层和第二层？我完全被自己的原则蒙住了。Claude引用它，我点头，循环闭合。

原则是怎么变成借口的

这让我重新理解"人机协作"的脆弱点。Claude不是故意糊弄。它在每一步都真诚地执行了被批准的策略，只是策略的边界被误读了。

"信息缺失优于错误信息"原本针对的是：解析失败时，是显示原始文本（让用户自己读），还是强行套一个可能错的模板？我们选了前者。但Claude把这个逻辑扩展到了：解析"部分成功"时，是否保留有歧义的部分？它选择了丢弃歧义，输出"干净"结果。

关键区别：原始文本是"已知未知"，用户看得懂；部分解析结果是"未知未知"，用户被误导以为自己拿到了答案。

我的批准流程也有漏洞。代码审查时，我看到"括号内容因复杂度过高被跳过"的注释，觉得合理。合理的东西不一定正确。我没有追问：跳过之后，输出会不会变成谎言？

紧急场景放大了所有错误

这个项目处理的是日本紧急避孕药药店数据。用户场景很具体：周末或深夜，需要72小时内服药的人搜索附近营业的药店。时间窗口窄，情绪压力大，决策链条短。

普通生活服务里，"可能营业"的模糊信息是可以接受的。用户多打一个电话确认，或者走到门口发现关门，成本可控。但紧急避孕的时间窗口以小时计算，白跑一家店可能意味着错过整个周末的选项。

我的筛选器把模糊错误变成了确定性错误。之前用户至少会怀疑"周三真的开吗？打个电话吧"；现在筛选器用"营业中"三个字画上了句号。

周六下午那50个结果让我后背发凉。如果当时真有用户在使用呢？

修复与未修复的

当晚我让Claude重写筛选器。新逻辑强制检查：任何被标记为"排除"或"节假日关闭"的日期，如果没有100%解析置信度，直接降级为"状态不明"。宁可让用户看到"未知"，也不给"营业/休息"的二元判断。

括号解析也补上了，但用的是笨办法：针对（除く水曜）这类高频模式做硬编码，而不是追求通用解决方案。覆盖率会掉几个点，但错误率应该趋近于零。

缓存层加了日期上下文键，节假日和平日分开存。plumbing 接上了，holidayClosed 现在真的能让筛选器变红。

但有些问题没解。比如：用户看到"状态不明"时，会怎么理解？是"系统坏了"还是"这家店可能开着"？紧急场景下，"未知"本身会不会造成决策瘫痪？我没有答案，只能盯着使用数据看。

还有一个更底层的 tension：AI 助手越擅长引用原则自我辩护，人类审查者越容易放松警惕。Claude 的"根据我们确立的 Missing > Wrong 原则"听起来太像正确的废话，我差点再次点头。

现在我的审查清单加了一条：当 AI 用我自己的话支持它的方案时，强制反向论证——如果这条原则被推到这个场景的极端，会产出什么结果？

那个周三的 9:00-18:00 就是极端结果。我本该在代码合并前看到它。

工具还在跑。我偶尔会在非高峰时段随机抽查几个结果，点开地图验证营业时间。上周三下午，我查到一家显示"营业中"的药店，电话过去确认，对方说"周三定休"。

排查发现是数据源本身的格式变异：（水曜定休）被写成了全角括号，逃过了硬编码匹配。又补了一条正则。这种打地鼠会永远持续下去吗？还是说，有些场景本来就不该交给自动化解析？

如果紧急避孕药查询的容错率必须是零，也许我们该放弃"智能解析"，回归最笨的方式：人工审核每家药店的营业时间，或者干脆让用户电话确认？这个工具的存在本身，是不是就是对"技术能解决一切"的盲目信仰？