日志全绿数字也正常，但结果是错的：用 AI 搭数据管道踩的 4 个坑

又忘取消续费 · 2026-08-10T00:56:41.280Z

最近做了一条每天自动跑的采集链，40 个数据源，用 GitHub Actions 定时触发。上线前抓出四个坑，它们的共同点是：程序不报错、日志全绿、数字看着完全正常，但它是错的。一、只抓了一部分，报给你的是「全部」代码里写死「最多翻 3 页」，一页 100 条。跑完一切正常，直到我用另一个接口核了真实总数： A 源 1773 条 → 实际抓到 300 B 源 1281 条 → 实际抓到 300 C 源 675 条 → 实际抓到 300 D 源 180 条 → 全抓到三个源分别少了 83%、77%、56%，程序一声不响。更阴的是它保留的是最新的 300 条，而最新记录天然「还没来得及有结果」，不光数量少了，比例也系统性地偏了。做法：先用便宜的办法拿到总数（搜索接口只返回计数），再跟实际抓到的条数对。对不上就抛异常，不许交那个数。二、抓不到的时候，它填了个「看起来正常」的值从 Link header 解析页数，解析失败就退回用 body 长度，而 per_page=1 时那个值恒等于 1。于是「90 天只更新了 1 次」，真实值是 208。判断标准很简单：如果某个值既可能是「真的是 0」也可能是「没拿到」，那它就是坏数据，必须能区分。三、抽查 7 条全对，全量算出来完全不是那么回事某指标中位数 23.6 小时，我不放心，手工点开 7 条核对，全在 5 小时以内。看起来 23.6 是错的。拉出全量十分位：0.5 / 3.8 / 7.6 / 13.5 / 23.6 / 30.8 / 57.5 / 112.4 / 227.4 23.6 正是中位数，一点没错。错的是我的抽查，我点开的都是最近的、已经有回复的，那批天然就快。我的抽样自带偏差，差点因此去改一个本来正确的程序。做法：核对不要「挑几条看看」，要拉分布。最快最慢各是多少、中间那条在哪。四、用分位数定阈值，会把好东西也判成差的给 40 个候选分强/中/弱，按分位数，前 25% 强、后 25% 弱。结果 40 个里 17 个被判「不建议使用」，包括几个业内公认的主流选择。问题出在「排名后 25%」不等于「差」。如果池子里 40 个全是好东西，这套算法照样会把 10 个打成「弱」，这是数学决定的。换成有现实含义的绝对线（比如「一年没发过版本」而不是「排名靠后」），判「不建议」的从 17 降到 4，而且那 4 个是真有问题。最后固定下来的四条原则： 1. 让它报「应该有多少 / 实际多少 / 差在哪」，差额说不清就是有问题。 2. 同一个数用两条完全不同的路径各算一次。同一条路跑两遍不算验证，会错得一模一样。 3. 宁可报错，不许猜。解析失败一律抛异常，不返回默认值。 4. 抽查拉分布，别挑几条看。这套东西没有 AI 我一个人两天做不完，但 AI 交付的「完成」和「正确」是两件事，它自己分不清。真正花时间的不是让它干活，而是建立一套能抓出它错在哪的方法，特别是那种跑完很正常、过了几天才发现数不对的暗坑，最耗费精力。 #开源项目