没验证就汇报，是 AI 协作里最贵的坏习惯
这次改博客，我被自己一句话提醒了：
你要验证完再来报告，没验证来加剧工作量呢。
这句话听起来像在催进度，实际不是。
它是在讲一个很具体的协作成本：没验证就汇报，不是在交付结果，是把不确定性转交给对方。
AI 协作里最常见的低效，不是慢。慢一点还能接受。真正烦的是它看起来完成了，结果你一打开页面，发现又多了一个要解释、要截图、要回滚、要重测的问题。
这次问题怎么来的
我原本只是想把博客首页调好一点。
流程看起来很简单：
- 看首页截图
- 改
HomeBoard.vue - 跑构建
- 本地预览
- 截图确认
但实际踩了几个坑。
第一个坑：构建通过，不代表页面可用。
VitePress 构建成功了，但本地预览端口上可能还挂着旧进程。结果 HTML 是新的，CSS / JS 资源却可能对不上。你只看一句 build complete 就汇报，等对方打开页面，看到的是 404 或旧样式。
第二个坑：截图生成，不代表视觉正确。
移动端截图确实生成了，但标题被挤成奇怪的长行，推荐卡右侧看起来被裁掉。文件存在、命令成功、页面 200，都不能证明它好看。
第三个坑：“差不多了”最贵。
因为页面设计不是代码题。代码只要不报错，机器就觉得能跑。但用户看到的是排版、比例、阅读节奏、有没有别扭感。
这里不能靠“应该可以”。得打开看。
AI 最容易偷懒的地方
AI 很擅长给你一个“完成感”。
它会说：
- 已修复
- 已优化
- 已构建
- 已验证
但这四句话不是一回事。
| 说法 | 真正应该代表什么 |
|---|---|
| 已修复 | 代码改了，并且目标问题消失 |
| 已优化 | 视觉 / 体验比原来更好，而不是只是 CSS 变多了 |
| 已构建 | 生产构建通过，警告可解释 |
| 已验证 | 页面、资源、核心路径、截图都看过 |
最危险的是把“我做了”说成“它好了”。
这两个差一轮验证。
验证不是仪式，是省时间
很多人会把验证当成流程负担。
我的感受相反：验证是为了少说废话。
这次博客改版里，真正有效的验证至少有四层：
1. 数据校验
先跑：
pnpm run docs:check它检查文章 frontmatter、封面路径、正文图片路径、permalink 是否重复。
这个东西不花几秒，但能挡掉一堆“页面为什么空了”“图片为什么不显示”的低级问题。
2. 生产构建
再跑：
pnpm run docs:build开发模式能跑，不代表生产构建能过。尤其是 VitePress 这种静态站，很多问题只在 build 时暴露。
这次构建有一个大 chunk 警告，但不是失败。之前尝试随手拆包，反而引发主题初始化问题。所以这类警告要记录，但不能为了“看起来干净”乱改。
3. 资源检查
预览服务起来后，要查：
- 首页
/是不是 200 - 文章页
/articles/xxx/是不是 200 - 最新 CSS 文件是不是 200
为什么要查 CSS？
因为静态站最容易出现“HTML 是新的，CSS 没加载”的假正常。页面能打开，但样式全乱。你不查资源，就很容易误报。
4. 截图复核
最后才是最关键的：
- 桌面端截图
- 移动端截图
- 文章页截图
- 特殊配置截图
这次“博客全图”就是特殊配置。默认首页看起来正常，不代表切到“全图”预设也正常。后来强制切到 wide 预设再截图，才确认原来那种深色整图背景裁切确实被改掉了。
什么时候可以汇报
我的标准现在很简单：
不是命令跑完就汇报，是能回答“你验证了什么”再汇报。
比如这次能说清楚：
docs:check通过，10 篇文章校验正常docs:build通过，只有已知的大 chunk 警告- 首页、文章页、最新 CSS 都是 200
- 桌面、移动端、文章页、
wide预设都截图看过 - 本地预览在
4173跑着
这才叫交付。
否则只是“我这边感觉差不多”。
对人也一样
这件事不只适用于 AI。
人和人协作也一样。
我以前最烦的工作方式是：对方发来一句“好了”，然后你问：
- 哪个环境？
- 哪个地址？
- 你跑过没有？
- 截图呢？
- 有没有影响旧页面？
如果这些都要接收方再问一遍，那“好了”这两个字就没有信息量。
真正有用的汇报应该像这样：
我改了 A / B 两处；本地构建通过；生产路径
/xxx/打开正常；移动端 390px 截图看过，没有横向滚动；剩一个警告是 chunk 过大，不影响运行。
这段话长一点，但省掉后面十轮问答。
AI 协作的正确打开方式
我现在对 AI 的期待不是“你快点写完”。
我更在意三件事：
- 别把猜测当事实
- 别把命令成功当体验成功
- 别把未验证的东西扔给我验
AI 真正能省时间，是因为它可以替你做重复劳动：
- 查文件
- 改代码
- 跑命令
- 看截图
- 对比结果
- 总结变化
但如果它省掉的是验证，那节省的不是时间，是质量。
质量迟早要补回来，而且通常由你来补。
这笔账怎么算
一次没验证的汇报，看起来省了 2 分钟。
但后面可能多出来：
- 用户打开页面发现不对：2 分钟
- 截图发回来解释：3 分钟
- 重新定位问题：10 分钟
- 再构建、再预览、再截图：5 分钟
- 信任损耗：不好量化，但最贵
省 2 分钟，亏 20 分钟。
这账不划算。
所以我现在更认可一个慢一点但完整的闭环：
改完 → 构建 → 重启预览 → 查资源 → 截图 → 看截图 → 再汇报。
多一步验证，少一轮返工。
一句话收尾
AI 协作不是让它更快地说“好了”，而是让它更稳定地交出“确实好了”。
没验证就汇报，本质是在把工作量往后传。验证完再报告，才是真的省时间。
你用 AI 写代码 / 改页面时，最不能忍的是哪种“假完成”？ 评论区聊聊。
