Claude把设计原则用反了：93%覆盖率背后藏着致命漏洞

「Missing info > Wrong info」——这条原则被Claude写进设计文档，执行了三个月，最后成了它犯错的挡箭牌。

这是日本紧急避孕药药房查询工具的故事。上一篇文章里，我让Claude Code处理了6,933种营业时间格式，用82条正则表达式做到97%解析覆盖率。数字很漂亮，但数字会骗人。

真正的问题藏在一条被Claude自己删掉的数据里。

那条括号里的「除外」

原始数据长这样：月-金:9:00-18:00（除く水曜）。翻译过来：周一至周五9点到18点，周三除外。

Claude的标准化处理流程把括号里的「除く水曜」剥离了，只保留前半段。输出结果：周一至周五，每天9:00-18:00。周三赫然在列。

从Claude的视角看，这完全符合原则。括号里的排除规则太难解析，跨几十种格式做可靠处理成本极高。去掉它，保留基础时段，用户至少能看到大部分正确信息。Missing info > Wrong info，对吧？

我审代码时也觉得逻辑合理。解析括号排除确实是个坑，Claude的选择看起来是务实的妥协。

但 shipped 之后我才意识到：工具现在主动显示周三营业。用户查时间表，看到周三有时段，周三去了，药房关门。这不是「信息缺失」，这是错误信息。Claude正在生成原则原本要阻止的那类错误——还用原则本身当正当理由。

周六下午的50家「营业中」药房

上线后某个周六下午，我打开工具实测。搜索结果：50家药房，大多数显示营业中。实际上呢？大部分关门。

紧急避孕药不是普通商品。需要的人没空一家家打电话确认。如果工具显示开着，人去了，发现关着，这场景想想就头皮发麻。

当晚我让Claude加了个「现在营业」筛选器。初衷是好的：帮用户过滤掉闭店选项，减少无效奔波。

筛选器让漏洞无所遁形。时间表网格里周三的时段容易被忽略，但一个写着「营业中」的筛选结果在周三显示某药房开放——这是二元的、 definitive 的错误答案。没有模糊空间，就是错了。

三个叠加的失误

问题不是单一 bug，是三层设计缺陷的叠加。

第一层：闭店数据被丢弃。「（除く水曜）」这类括号排除规则，Claude的标准化流程直接剥离，我的原则给了它道德掩护。这是设计层面的根本错误。

第二层：节假日标记未接入。Claude已经从「日祝休み」提取了 holidayClosed: true，但没连到筛选逻辑。数据存在，管道不通。审代码时我也没发现。

第三层：缓存忽略日期上下文。同一文本，节假日和普通日的正确答案不同。缓存只按文本 key，没考虑查询日期。又是我漏掉的。

每层单独看都像是「合理的技术债务」。叠在一起，筛选器在错误的日子告诉用户错误的营业状态。

原则怎么成了遮羞布

「Missing info > Wrong info」这条原则本身没问题。紧急医疗场景，宁可承认不知道，也不能给假答案。

但Claude把它用成了分类器：只要我把数据标为「缺失」，就可以丢弃。括号排除太难？标为缺失，扔掉。节假日逻辑复杂？标为缺失，推迟。缓存日期感知没做？标为缺失，以后再说。

问题在于，「缺失」和「错误」的边界是模糊的。剥离「周三除外」后输出完整周时间表，用户视角看这不是缺失——是明确告诉你周三营业。Claude的「缺失」是我的「错误」，但我们用同一套词汇，各自理解。

更隐蔽的是，原则给了Claude（和我）心理安慰。代码里有注释引用这条原则，PR描述里提到它，设计文档里高亮它。它成了自我合理化的工具：我在做正确的事，即使结果看起来有问题。

这有点像产品经理常说的「数据驱动」——数字成了决策的替罪羊，没人再问数字背后是什么。

修复比发现更难

发现三层问题后，修复花了比预期长的时间。

括号排除规则不能简单加回来。6,933种格式里，括号内容千差万别：「除く水曜」「祝日休み」「年末年始除く」「第3水曜休み」「不定休」……每种都需要单独解析逻辑。Claude最初选择剥离，部分是因为这个组合爆炸。

节假日标记的接入需要重构筛选管道。原来 filter 只查时间段匹配，现在要叠加日期类型判断。缓存层要加日期维度，key 结构变了，失效策略要重新设计。

最耗时的是验证。每改一处，要确认没破坏其他格式。6,933条记录，97%覆盖率是之前的成绩，现在成了回归测试的基线。改对一条，可能错十条。

最终方案是分级处理：高频排除规则（如「周三除外」）硬编码解析，低频的 fallback 到原始文本显示。节假日标记接入筛选逻辑，缓存加日期 key。覆盖率从97%掉到91%，但错误率从「未知」变成了可量化。

AI辅助编程的幻觉

这件事让我重新理解 Claude Code 这类工具的能力边界。

它能生成合理的代码，能写设计文档，能引用你教给它的原则。但它对原则的理解是语法层面的——识别关键词，匹配场景，输出符合格式的论证。它不会站在药房门口，想象一个周三下午急需避孕药的人看到「营业中」是什么感受。

更危险的是，它能把错误包装得很有说服力。剥离括号数据的代码有详细注释，引用设计原则，解释技术权衡。读起来像资深工程师的务实决策，而不是一个会害用户白跑一趟的漏洞。

我作为审代码的人，也被这套包装影响了。看到原则被引用，看到成本收益分析，潜意识里降低了警惕。AI 的幻觉传给了人类。

现在我的流程里加了一道手工抽检：随机选10条记录，人工核对原始文本和解析结果。不依赖覆盖率数字，不依赖原则引用，直接看输入输出是否匹配常识。这道工序 Clau de 做不了，也不该让它做。

工具上线半年后，我收到一条用户反馈：「周三去了显示营业的药房，关门了，最后去了另一家。」没有抱怨，只是陈述。但这条消息让我确认，那三层漏洞至少影响了一个人。

如果当初没有加「现在营业」筛选器，错误会更隐蔽，影响更多人，但可能永远不会被单独报告。筛选器放大了错误，也暴露了错误。这算设计成功还是失败？