这次数据损坏的直接原因，是我在爬虫的解析函数里偷懒，用了一个过于宽泛的正则表达式去匹配价格字段。我以为能覆盖99%的情况，结果上周对方网站改版，在价格后面偷偷加了个带HTML注释的星号，我的正则就把整段注释连同后面的产品描述都吞进去了。等发现的时候，已经污染了接近两万条商品记录，客户拿着错误报表来质问，整个交付项目差点崩盘。
不是第一次了。2017年做SEO站群的时候，就因为一个URL拼接函数没考虑中日韩字符编码，生成了一堆死链，被百度降权降得妈都不认识。2020年带团队做小程序，实习生写的提交逻辑没做前端重复点击拦截，凌晨促销时同一个订单被创建了四十多次，库存直接炸穿。每次都是“我以为不会出问题”的细节，在量级起来之后变成核弹。过去还能甩锅给别人，或者用“快速迭代”当遮羞布，现在回归超级个体，每一行代码的后果都直接砸回自己脸上，躲都没法躲。
痛定思痛，光靠人肉Review和测试用例已经不够了。尤其是现在用AI辅助生成代码，它写得快，但那种对业务上下文和边缘情况的“直觉”是缺失的，埋雷更隐蔽。我决定给我的主要数据流水线，加一层独立的、事后的自动化纠错逻辑。这套东西不参与核心业务流程，只做检查和修复。
核心是一个轻量级的校验服务。比如针对这次的价格字段，我写的规则不再是“匹配数字”，而是：1. 提取到的字符串必须能转换为浮点数。2. 数值必须在预设的合理区间内（比如0.1到100000）。3. 字符串长度不能超过15个字符（防止吞入额外文本）。任何一条不满足，这条记录就会被标记，并触发修复流程。修复不是简单丢弃，而是先尝试用更严格的XPath或CSS选择器重新提取；如果还失败，就记录原始HTML片段，存入待人工审核的队列，同时通知我。
我把这些校验规则做成了可配置的YAML文件，每个数据源对应一套。规则类型包括数据类型、范围、枚举值、字符串模式（正则）、字段依赖关系（如有了运费就必须有运费模板）。校验服务每天在数据入库后自动跑一次，用的是n8n搭的定时工作流，调用几个Python脚本。现在我的爬虫脚本可以写得稍微“激进”一点，追求覆盖率，因为我知道后面有个保险网兜着。
这听起来增加了复杂度，但实际跑下来，心理负担小太多了。昨天另一个网站的详情页突然多了一个“暂无报价”的占位图，我的主解析器漏了，但校验规则里的“主图URL必须包含常见图片后缀”这条把它逮住了。系统自动切换备用解析方案拿到了正确图片，全程我没收到任何报警。这种“静默修复”的感觉，比赚一笔快钱还爽。
慢就是快，稳就是赢。这话以前听觉得是鸡汤，现在觉得是血泪换来的物理定律。在AI时代，代码的产出速度被无限放大，但数据质量的底线一旦击穿，修复成本是指数级上升的。我的角色从一个追求“攻陷”某个技术难点的黑客，正在转变为一个设计“容错系统”的工程师。让机器去处理机器的错误，人才有可能去思考点真正的新东西。
