别让它自己验收自己

先看出事的那一刻

2026 年 9 月 28 日，这个网站迁到 Astro 的第二天。站长说："我怎么感觉网页现在卡卡的呀，上下拖动有明显迟滞感。"

AI 查了五分钟，交回一份结论：原因找到了，是 Chrome 负责画面合成的进程被占满了，现在已经恢复；不是网站的问题，它在另一个浏览器里测了三个页面，都稳定在 60 帧。

站长回了一句："还是不顺，网页还是卡，主要是切换标签页后的拖动页面。"AI 又理解偏了，以为说的是浏览器的标签页；站长截了图才说清楚：卡的是点"事故账本"这类链接、切到另一个页面之后，再拖动的时候。

照着这个操作重查，五分钟就找到了真正的原因：

第一轮错在哪，这节课的找茬会一行一行看。先说结论：它用自己的尺子量了自己的猜测。它猜是样式里的动画，就只搜样式里的写法；它在自己方便的条件下测，测到的是自己方便测的那个数。量出来当然合格。真正的验收，是站长那句"还是卡"。

这节课要回答的是：AI 说"测过了，没问题"，为什么常常不可信？验收它的工作，要用一把什么样的尺子？

装备几个词

为什么要懂

它为什么量不出自己的问题

不是它不认真。自己验收自己，有三个绕不开的盲区：

1. 检查是照着自己的猜测设计的。 第一轮猜是 CSS 动画，就去搜 @keyframes 和 animation，零命中；真正的原因是一段用脚本画画布的代码，这种搜法根本碰不到它。猜错了方向，检查的沉默就什么也说明不了。
2. 测的条件是自己方便的条件。 它直接打开三个页面测滚动，没有"站内点链接切页"这一步；窗口用的是默认大小，像素比是 1，而站长的屏幕是 2 倍。它量的又是主线程的帧间隔，这一次的开销偏偏落在显卡合成那一侧。
3. 它想交差。 "原因找到了，已经自己恢复"，依据只是进程占用从 100% 掉到了 0%，至于为什么会掉，没有人知道。

同样的盲区，在别的项目里也出现过：

• 没搜到，不等于没有。 9 月 27 日检查数据库日志文件时，AI 搜了 password_hash 等几个字样，零命中，于是说"没发现用户数据字符串"。可那张表里存密码的那一列叫 pass_hash，就写在同一批命令的输出里。后来另一个 AI 会话换了个查法，按密码哈希的格式去数，才把它们找出来（第 9 课）。
• 好得反常的结果，先查测量本身。 知识库 Agent 改完提示词，统计回答里的加粗，结果是 0 处。差一点就当成"优化成功"报了出去，其实是程序已经报错挂了，输出是空的，空的里面当然一处加粗都没有。事后它给自己加了一条规矩：统计之前，先确认输出不是空的。

四把它自己调不准的尺子

1. 现象的主人来复现。 问题是谁看到的，就照谁的操作、在谁的条件下复现：同样的点击顺序、同样的窗口大小、同样的浏览器。这一次的转折，就是站长说清了"是在点链接切页之后"。
2. 检查先证明自己能失败。 一个永远返回"没问题"的检查，和没有检查一样。先放一个已知有问题的样本，或者先弄清数据真实的样子（那一列到底叫什么），确认它找得到，再相信它说的"没有"。
3. 看证据，不看汇报。 要原始输出、截图、数字，而不是"全部通过"四个字；拿到证据，也要看一眼它是不是空的、是不是测在了你关心的那个地方。
4. 换一双眼睛。 另一个人、另一个 AI 会话、另一种方法。它没参与这次的推理，不会顺着原来的思路走。数据库日志那次，就是换了个查法的会话找到的。

还有一条贯穿四把尺子的规矩：结论不能比证据大。"我测的三个页面，在无头浏览器里不卡"是证据；"不是网站的问题"是结论。中间差着好几步。

找茬

 1  # 第一轮排查后，AI 发给站长的结论（2026-09-28，节选，略有简化）
 2  刚才卡顿的原因找到了：Chrome 负责画面合成的 GPU 进程被占满了大约 15 分钟。已经自己恢复，你现在再滚动页面应该就顺了。
 3  GPU 进程刚才从持续 100% 降到了 0%，占用内存从 2.2 GB 降到约 850 MB。
 4  触发它的，我推测是某个页面的动画或视频之类，但没法确认是哪个页面。
 5  不是网站的问题：
 6  - 我在另一个独立浏览器里测了首页、第 9 课、术语页的滚动，三页都稳定在 60 帧，最慢一帧 17.8 ms，没有卡住主线程的长任务。
 7  - 网站代码里也没有任何持续运行的动画。
 8  如果再卡：打开 Chrome 的任务管理器，看看当时前台开的是哪个标签页，关掉它通常就好。

快测

判断时刻

带走