REPRODUCE · OBSERVE · VERIFY
先复现，再让 AI 修。
两个小实验，把“感觉有问题”变成可检查的证据。代码在本地运行，无真实 API、无依赖，也不会调用 AI 服务。
EXPERIMENT 01
输入没错，结果怎么倒退了？
一次点击先搜索 HTML，80 ms 后再搜索 React。前者计划等 900
ms，后者计划等 200 ms。这里用
setTimeout 模拟响应；日志显示实际经过时间，调度可能延后。
等待脚本初始化。
页面实际显示
- 当前关键词
- 尚未搜索
- 最新请求编号
- —
- 结果来源
- 尚无结果
结果标题
等待实验开始
请求时间线
- 运行实验后，这里会记录请求编号、关键词和处理决定。
要怎样证明修复有效？
故障模式结束后，当前关键词仍是 React，结果来源却是 #1 HTML。切换到修复模式再跑一次，结果应保留 #2 React，日志里能看到 #1 被丢弃。修复没有让旧请求消失，只阻止旧响应更新页面。
代码中的判断是
requestId === latestRequestId。真实项目还需要检查取消请求、卸载、错误和缓存等行为；这个实验只隔离“后发先到”这一条因果链。
EXPERIMENT 02
算得一样，页面还能响应吗？
两种模式对同一串连续整数执行相同的 32 位校验和计算。同步模式一次做完；分批模式每计算约 8
ms，就通过
setTimeout(resolve, 0) 让出主线程，再继续剩余工作。它仍然在主线程运行。
等待脚本初始化。
| 模式 | 总耗时 | 最长工作片段 | 运行期心跳 | 校验和 |
|---|---|---|---|---|
| 同步 | 尚未运行 | |||
| 分批 | 尚未运行 | |||
两种模式都运行后，检查校验和是否一致。
总耗时由
performance.now()
实测，包含分批等待时间，不含启动前留给页面绘制的等待。最长工作片段只测计算函数的执行区间。心跳计数还受浏览器调度影响；请保持标签页在前台，在同一计算量下比较。结果依赖设备、系统负载与预热情况，分批不一定更快。这些值不是
INP，也不是 Core Web Vitals。
怎样收集能交给 AI 的性能证据？
固定计算量，分别运行两种模式，记录设备、浏览器、是否启用 CPU 限速和两次实测结果。打开 DevTools 的 Performance 面板录制，再用调用栈定位计算函数。把现象、录制证据和预期写进提示词，要求 AI 先解释瓶颈，再做最小改动。
心跳在同步计算期间无法执行。分批处理给定时器和用户输入提供了执行机会，但单个片段仍可能超过目标预算，尤其在慢设备上。比较总耗时、响应性和校验和，不能只挑一个看起来更漂亮的数字。