Git Hook 中 AI 归因过滤器的精准度陷阱从「锚定了但还是错」到上下文感知正则核心观点原文记录了一个真实 bug 的两次演化作者为 git hook 写了一个过滤器用来从 AI 生成的 commit message 中剥除这是 AI 写的之类的归因声明第一版用裸字符串匹配过于宽泛false positive修复为\b锚定正则后自认为精准了但文章的核心发现是——锚定正则解决了一类误判却没有解决语义层面的误判\bclaude code\b这一条依然会把所有合法的技术性提交fix: handle claude code MCP timeout当成 AI 归因声明一起抹掉而且因为系统提示保证只生成单行抹掉单行等于整条 commit 消失静默失败症状与之前两个完全不同原因的 bug 完全相同。技术现状与参照系这不是什么范式突破而是一个非常经典的正则过滤器精度问题在 AI 工具链语境下的具体复现。把它放到更长的历史脉络里垃圾邮件过滤、敏感词屏蔽领域早已反复经历这个教训裸关键词 → 词边界锚定 → 上下文感知是一条反复被走过的演化路径。「llm这个词被裸匹配误删」和「claude code这个短语作为工具名被误删」两次 bug 的形态完全不同前者是子串匹配太宽llm出现在任何地方都算后者是模式设计缺乏语义约束即使加了\b词边界只管边界不管短语前后的上下文是归因场景还是技术描述场景。最核心的那个机制真正巧妙也是真正值得记住的点在于\b锚定修复的是是否命中这个词但过滤规则真正需要问的是这个词出现在归因语境里吗。两个问题在大多数场景下高度相关提交里写claude code大概率是在提 AI 归因但在「这个仓库本身就是封装 Claude Code 的工具集」时两个问题的答案完全脱钩——claude code在这里就是一个普通技术名词频繁出现在任何正常提交里。作者给出的修复方案本质上是要求归因介词存在r\b(with|by|using|via)\s*\[?\s*claude code\]?这把匹配条件从「短语出现」升级为「短语出现在归因动词之后」同时还处理了现实中 Claude Code 官方 footer 的 Markdown 链接格式[Claude Code](url)——这个细节之前的 patterngenerated (with|by)\sclaude因为没考虑方括号插入而完全漏掉了真实的 footer 格式所以那条\bclaude code\b并非冗余而是在偷偷兜底一个更微妙的问题。与历史方案的对比牺牲了什么版本策略问题v1裸子串匹配简单覆盖广严重 false positive合法 commit 被误杀v2\b锚定正则词级精准语义 false positive工具名被当归因语v3介词上下文约束语义感知需要穷举归因介词新介词漏网如powered byv3 没有穷尽所有攻击面但它把误判的成本大幅降低了——这是现实工程里「够用的精度」。静默失败为何特别危险这里有一个被作者深入挖掘、值得单独强调的放大机制msg \n.join(l for l in raw.splitlines() if not _STRIP_RE.search(l)).strip()这行代码在多行输出时是安全的只删单行但系统提示保证 AI只输出一行。结果是任何 false positive 都会导致msg变为空字符串然后hooks/prepare-commit-msg因为[ -n $MSG ]检查失败静默退出——没有报错没有警告表现跟hook 没装或AI 调用失败完全一样。这是三个不同根因收敛到同一症状的案例调试难度指数级上升。交叉验证信源一pii-guard 项目文档intellirim.github.io2026-02这篇文档研究 LLM Pipeline 中的 PII 检测明确指出「正则命中 5-token 上下文窗口分析」比「纯正则」减少 60% 的 false positive。核心逻辑与原文完全一致123-45-6789在「version X.Y.Z released」语境下不应被标为 SSN就如同claude code在「fix: handle claude code MCP timeout」语境下不应被标为 AI 归因。两篇文章独立地从不同领域PII 过滤 vs. git commit 过滤得出了相同的工程结论纯词边界匹配不够必须考虑语义上下文。pii-guard 的解法更重量级50 pattern 置信度打分原文的解法是轻量但务实的介词约束——方向一致复杂度的取舍不同。信源二regular-expressions.info 关于\b词边界的文档该文档系统说明了\b的局限性它只处理「词字符/非词字符」的边界对连字符、括号、Markdown 语法等完全无感知。这从技术规范层面印证了原文发现的那个坑[Claude Code](url)中方括号打断了generated.*claude的匹配路径——这不是偶发 bug而是\b本身机制决定的。两个信源均认同原文的核心判断没有反驳但都指向同一个补充原文修复仍是「启发式」的更完备的方案需要引入语义评分机制而非仅靠枚举介词。个人启发具体可操作的建议而非泛泛而谈写任何内容过滤器的测试用例必须包含两个方向true positive目标 pattern 是否还能被捕获和 false positive合法内容是否会被误杀。原文作者只测了第一个方向就上线了这是这个 bug 的直接成因。我们的项目本身就在讨论这个工具是最容易被忽略的边界条件。如果你的项目是关于 Python 的你的代码质量过滤器里就不能有裸匹配python如果你在维护一个 Docker 相关仓库裸匹配container会炸掉一半提交。这类冲突需要在设计阶段就问自己「这个词在本项目里是普通技术名词吗」单行输出 逐行过滤 极端脆弱的组合应当在系统设计时就对齐。如果 AI 只能输出单行过滤器要么改为返回原始内容并发警告要么改为「检测到归因 → 尝试摘除归因片段而非整行」。静默将整条 commit 丢弃是错误处理的反模式。双文件复制同一逻辑是已知漂移风险但作者每次修复都能记住检查两处——这点值得学习。更彻底的方案是把_STRIP_PATTERNS提取到单一可 import 的模块从根本上消除漂移风险。延伸思考上下文窗口 vs. 语法约束原文用介词约束来表达「归因语境」但如果 Claude Code 未来的 footer 格式改成「built on Claude Code」或「Claude Code-assisted」这个修复又会漏网。更鲁棒的做法是用正则捕获组保存匹配上下文再用白名单判断——这和 pii-guard 的置信度打分思路殊途同归。问题是对一个 git hook引入这个复杂度是否值得AI 生成 commit 人工维护过滤规则是一种结构性张力AI 工具的输出格式随版本迭代会变比如 Markdown footer 格式而过滤规则是手写的静态正则两者的演化速度不对齐。长期来看更可靠的架构可能是在 AI 生成侧就禁止输出归因信息系统提示里明确约束而不是在输出侧做事后过滤——把问题解决在源头。同一症状、多个根因是自动化工具链中调试最难的模式原文三次 bug 都表现为commit 消失但根因分别是 hook 未安装、AI 调用失败、正则 false positive。对于这类收敛症状正确的工程响应是在每一个可能的失败节点打一条可区分的日志而不是只在最终结果上判断是否非空。这是日志设计哲学的一个具体反例教材。 参考来源My AI-Attribution Filter Stopped Over-Matching Ordinary Words. It Still Wipes Any Commit Thats Legitimately About Claude Code. - DEV Community
