土拨鼠日志：位图算错一位，皮肤集体消失又找回

今天有两件小事，看着不起眼，背后都是同一类坑：「你以为算对了，其实差一位」，和「抽样指标没分清对象就下结论」。挑出来讲，因为我们自己就差点被它们带沟里两回。

一、改位图前，先把 bit 和 col 的公式摆桌上

事情很小：玩家挖宝拿到的皮肤在衣橱里是空白卡片，已激活 0/450。查下来是真凶很典型——皮肤图档号不在客户端索引里，客户端解析不到就渲染成空卡。

真正值得讲的教训不是这个 bug 本身，而是修复过程中我们自己翻了两次同样的错：

• 要把某一位清零，得先算 bit = (skin - 1) % 32、col = (skin - 1) / 32 + 1。
• 头两次我们把 16、17 号皮肤直接当成了第 16、17 位，而不是先减一、再对 32 取模定位。

位对不上，清零就清错了格。之所以最后能兜住，靠的是一条土办法：改完不是「看着对就收工」，而是把整张表重新读回来、逐条解码核对一遍——这一步一跑，错的位立刻现形。

二、判断「皮肤能不能显示」，别用错口径

这里还埋着一个更隐蔽的坑：同一个团队 9 月份就做过一次奖池收窄，当时的判据是「图片数据存不存在」，结果漏掉了 53 个空皮。

正确口径是看客户端索引里有没有这个图档号——数据文件里有、索引里没有，照样显不出来。9 月那次就是拿「数据存在」当「能显示」用，才让这 53 个一直藏在奖池里。

教训一句话：「资源存在」和「资源能被查得到」是两件事，做判定必须用最终能被消费到的那一层去验证，不能停在上游。

三、抽样指标要分开数：文字页归文字页，图片页归图片页

下午的另一件事看着完全不相干，内核是同一个病。做网站内容体检时，脚本随机抽 20 页算字数中位数，得出「47% 页面内容偏浅、要文字化 700 页」的结论。

真去翻数据库才发现是测量误判：站里有大量宠物图鉴页，正文 0 字、本质是「纯图 + 名字」的图片载体页，sitemap 里占约一半；随机抽样抽到 9 个这种页，把中位数狠狠拉低了。

按页面类型分组再看：攻略页中位数 1868 字、问答 677、Top10 1185，没有一类是真的浅。把文字内容页和图片载体页混在一起测字数，必得假结论。

修法也简单：深度指标只对文字页统计，图片载体页单独标注占比、不计入。改完中位数立刻回到了达标线上。

四、这套东西在土拨鼠里长什么样

说点能直接感觉到的：

• 改数据前有闸门：先查错题、查领域坑、查同类作业，把「验收标准 / 回滚点 / 改动范围」定清楚再动手，避免上手就改错对象。
• 改完有回读审计：不是看自己写的代码觉得自己对，而是把结果读回来核对一遍，像今天那张位图表一样让错位自己现形。
• 长活有进度卡，你随时看得到它在第几步、卡在哪，不用一直问「好了没」。

想先看看它怎么帮你把这些纪律落到日常，可以从 功能页 看长任务与工作区的部分；要算一笔账，定价页 有按量与实际的对照；想直接上手，就 下载 装一个，拿一件真事跑一遍比看十篇介绍有用。

五、一个 30 秒自查

下次你（或你的 AI 助手）「明明查过了还是错」，按顺序问三句：

• 位、索引、ID 这类从 0 还是从 1 开始，公式摆出来核过吗？
• 判定用的是什么口径——「存在」还是「能被查到、能被用上」？
• 抽样的样本里，是不是混进了根本不该一起比的那类对象？

三个问题里中一个，多半就解释了「为什么看起来查过、结果还是不对」。数据修错的代价，永远比多写一行核对贵的多。