同一周连踩两次
第一次是早上。
我让 subagent 把一个产品的 5 页静态网站按新的设计规范重写一遍，交付完我自己跑了一遍自检：
grep -c "<img " *.html原始页里 spv.html 有 16 个 <img>，交付后的版本只有 0 个。
我心一沉，立刻发警报：「subagent 把 16 张图全丢了，老坑。」
回头一看才发现，那 16 个里没有一个是页面真正的「内容图」。全是：
- 顶栏 logo
- footer 社交图标
- GTM 像素图
- 菜单图标
这些反而是这次重设计要清掉的「全站通用 chrome 图」。真正的内容图都在 assets/images/ 路径下，0 张丢失。
是我用错了指标——<img> 标签总数完全不能反映「页面内容图是否齐全」。
第二次是下午。
我让 subagent 做一个工业大屏类的 HTML demo，需求里写了「左边树形通道控制 24 个节点 + 右边报警列表至少 8 条」。交付后我又跑 grep：
grep -c "class=\"alarm-item\"" curve-analysis.html
# → 1
grep -c "class=\"channel-item\"" curve-analysis.html
# → 0我又一次心一沉，差点发警报「subagent 把树形通道和报警列表都缩水到只剩 1 个模板」。
打开文件一看，subagent 用的是：
VEHICLES.forEach(v => {
// 渲染 24 个 tree-node
})
ALARMS.map(a => `<div class="alarm-item">...</div>`).join('')HTML 源码里 class 模板只出现 1 次，运行时会渲染 24 个 + 10 个。
我数 static class 数得到的是「模板出现次数」，不是「实际渲染数」。又是指标选错。
复盘：两次为什么都不是指标值错
我两次都没数错——
<img>真的就是 0 个class="alarm-item"真的就是 1 个
数值都对，但指标本身没有反映我想验证的事。
第一次想验证的是「内容图有没有丢」，但 <img> 总数包含了大量与内容无关的 chrome。
第二次想验证的是「实际 UI 上会显示多少元素」，但 static class 数 ≠ 运行时 DOM 数。
这是两个完全不同类型的指标错误，但根上是同一个错：
没有在跑 grep 之前先问「这个指标真的等于我想验证的事吗」。
为什么会这样
我反思了下，根因有三层。
第一层：grep 是肌肉记忆
跑 grep 是几乎零成本的动作。看到「想验证某个东西在不在」，手就敲了。
但 grep 的输出永远是「字符串匹配数」，它不知道你想验证什么。你必须自己证明「这个字符串等于那个东西」。我跳过了这一步。
第二层：subagent 自报合格让我放松了
第一次 subagent 自报「5 页全部通过自检」。 第二次 subagent 自报「8/8 项检测通过」。
这两个「合格章」让我本能地觉得「应该没事，我快速 grep 一遍走个流程」。流程心态下，我对指标本身的怀疑值就低了。
但 subagent 的自检用的是它自己想到的指标，我的复检用的是我自己想到的指标，两边都没保证「指标对不对」。
第三层：「指标值」是可视的，「指标对不对」是不可视的
跑完 grep 我能看到一个数字。这个数字看起来像「证据」。
但「这个指标是不是我想验证的事」是一个纯思考结果，没有任何工具能帮我打印出来。所以这一步特别容易被跳过。
给自己定的新规矩
跑任何验证指标之前，先回答三个问题——
1. 我真正想知道的是什么？（"内容图齐不齐" / "运行时 UI 元素多不多"）
2. 这个指标和我想知道的事是不是 100% 等价？
3. 不等价的话，缺什么、多什么？要不要换指标？
三个问题答完，再跑命令。第二步是关键。95% 的情况，指标和真问题之间有 gap。比如：
| 我想验证的事 | 看起来对的指标 | 真实 gap |
|---|---|---|
| 内容图齐不齐 | grep -c '<img ' | 多了 chrome 图、广告像素 |
| 实际渲染元素多 | grep -c 'class="x"' | JS 动态渲染时只数到模板 |
| 测试通过 | exit code = 0 | 测试本身可能跳过了 |
| 文档完整 | 字数达标 | 可能全是水分 |
| 功能 work | 编译通过 | 可能运行时崩 |
| 用户体验好 | 加载快 | 可能信息层次崩了 |
每一栏的左侧是「真问题」，中间是「易选指标」，右侧是「为什么不等价」。
中间那栏的指标都不是错的，它们都能给出可信的数值。但它们都没有 100% 等价于真问题。
兜底动作：别只信指标，亲眼看一次
光改三问还不够。指标永远会有 gap，关键场景必须加一道「真消费视角」的兜底——
- HTML / 网页 / dashboard → 浏览器打开看一眼
- API → 真发一个请求看响应
- 文档 → 从头读一遍
- 数据 → 采样几条肉眼过
这种「真消费一次」的成本通常是 10-30 秒，但它能 catch 掉所有「指标选错」的盲点。我两次 grep 翻车其实在「打开浏览器」面前都会被秒识破。
我的新执行栈是：
1. 跑 grep / 指标自检（快速大范围扫）
2. 三问验证（指标是不是真问题）
3. 真消费一次（兜底）
4. 才报「合格」前两步保证自己别把错指标当证据；第三步保证万一前两步都漏了还有一道关。
写给同样在用 AI 协作的人
如果你也在用 AI 帮你做事，会反复遇到这个问题：
- AI 自报「合格」
- 你想快速验一下
- 你想到一个指标
- 跑出来一个数值
- 看起来对/不对
别在第 5 步就下结论。在跑指标之前问一句「这指标真等于我想验证的事吗」，能避免 80% 的错判。
更狠一点的：问 AI 一句「你的自检指标是什么？为什么这个指标等价于真问题？」——逼它把指标证明给你看，比你自己想指标更稳。
我两次翻车的成本是：第一次发了错警报给老板，要回来道歉；第二次自己冷静下来才识别出来，没发到外面。
不算大事故，但同一周连踩两次，说明这不是巧合，是工作流缺一环。补上「三问 + 真消费」，下次就不会再栽。
马启航Marvis