AI 写代码三分钟，你验收一下午：该把"验收"也交给 AI 了

摘要： AI 三十秒吐两百行代码，编译零报错，但弹窗被表头盖住一半、点确认没反应、接口 500 页面毫无提示——这些问题 typecheck 查不出、build 发现不了、单测覆盖不到，最后全靠你截图描述、来回返工。瓶颈从来不在生成，在验收。这篇文章把前端验收拆成视觉、交互、网络、控制台四层，聊聊怎么让 AI 自己截屏看页面、自己点按钮、自己查请求和日志，验完才说"完成"。

描述需求，AI 三十秒吐出两百行代码，编译零报错。你把项目跑起来，点开页面——弹窗被表头盖住一半。你截图、框出问题、组织语言描述"遮罩层好像没盖住表头"，发给 AI。它道歉，改一版。你再跑，再点，再看——这次弹窗出来了，但点"确认"没反应。你又截图……

一个下午过去，需求本身 AI 只花了三分钟，剩下俩小时，全花在你给它当验收员上。

一、vibe coding 的循环，卡在最后一环

现在用 AI 写代码，流程基本都长这样：

描述需求 → AI 生成代码 → 编译通过 → 你跑起来看 → 有问题
    ↑                                              ↓
    ←──── 截图/描述问题 ← 你发现问题 ← AI 修改 ←──┘

这个循环里，AI 负责生产，你负责验收。分工听着合理，但"验收"背后是一整套活儿：

• 把项目跑起来（或者让 AI 跑起来，你再确认）
• 打开页面，肉眼过一遍布局、颜色、文案
• 实际点一遍：按钮、表单、弹窗、路由跳转
• 出了问题，截图，用文字把视觉问题描述清楚
• 等 AI 改完，再完整验一遍——它的修改可能引入新问题

AI 改代码要三十秒，你验一轮要五分钟。它改十轮轻轻松松，你验十轮，一下午就没了。

比耗时更磨人的是中断感。vibe coding 本来讲究心流，想法直接变产品。但每轮人肉验收都是一次强制中断：你要从"想需求"的状态切到"找茬"的状态，切过去再切回来。一天下来代码没写几行，截图倒发了几十张。

二、瓶颈早就不是"写"，是"验"

2026 年了，AI 的代码生成能力已经过剩。主流工具写个 CRUD 页面、加个表单校验、搞个响应式布局，代码质量都不差，编译通过更是基本操作。

但验证能力是零。

AI 出 1000 行代码要 30 秒，你验 1000 行要 30 分钟，效率差着 60 倍。AI 越快，压在你手里的"待验收品"就越多。

有人说用测试解决。单元测试确实能覆盖逻辑层，但前端有大量问题测试根本够不着：

• 弹窗被别的元素盖住一半（z-index 层叠上下文）
• 接口报错但页面没有任何提示
• 控制台一堆 undefined 但 UI 恰好还能看
• 点击后异步加载，点快了就是白屏

这些问题 typecheck 查不出、build 发现不了、单测覆盖不到，唯一的办法就是像真实用户一样打开页面看一遍、点一遍。而这活儿，现在是你干的。

三、根因：任务模型没眼睛、没手、没耳朵

为什么 AI 不自己验收？答案有点扫兴：它做不到。

日常帮你写代码的那个大模型（下文叫它任务模型）是纯文本的。它看不到渲染结果——CSS 写得对不对、布局歪没歪，只能靠代码"推理"，而层叠上下文、浮动、媒体查询这些东西，纯靠推理翻车率极高。它也点不了按钮、填不了表单，交互对不对验证不了。控制台的报错、网络请求的失败，它同样感知不到，接口 500 了它根本不知道。

所以它只能拿"编译通过"当验收标准，因为这是它手里唯一的验证手段。可编译通过 ≠ 页面对，中间差着一整个渲染层和交互层。

它缺的不是态度，是工具。

四、把验收员的活儿拆开：就四层

一个前端页面到底要验什么？拆开就四层：长得对不对（视觉）、点得动不动（交互）、数据通不通（网络）、报没报错（控制台）。

我后来换的工具把这四层全部交给了 AI 自己做。下面一层一层看。

视觉：AI 得先有眼睛

视觉验收的核心是截屏分析。但这里有个容易想当然的地方：不是"截个图丢给模型看看"就完事了。

我一开始也以为视觉模型看图很厉害，随便看看就能发现问题。实际试下来发现，泛泛地看，它只会回你"页面是深色的，有一些文字和按钮"——全是废话。真正有用的是带着问题去看。

这套流程里是两个模型配合：

任务模型（写代码那个）：根据刚改了什么，生成「重点看什么」
    ↓
截屏 → 截图 + 关注点清单 一起交给视觉模型
    ↓
视觉模型：逐条检查，结构化返回
    ↓
任务模型：拿到结果，决定修还是过

关键在第一步。任务模型知道自己刚改了什么，所以它能生成精准的关注点。比如刚改完一个弹窗组件，它给视觉模型的指令是：

重点看：
1. 弹窗是否完整显示在视口内，有没有被其他元素遮挡
2. 遮罩层是否覆盖全屏（包括导航栏）
3. 弹窗内按钮是否可辨识，文字有没有溢出
4. 关闭按钮位置是否符合项目现有弹窗的惯例

视觉模型逐条返回：

1. 弹窗完整显示 ✅
2. ⚠️ 遮罩层 z-index 低于导航栏，导航栏未被遮罩覆盖
3. 按钮可辨识 ✅
4. 关闭按钮在右上角，与项目其他弹窗一致 ✅

任务模型拿到第 2 条，直接定位到 z-index 的问题去修，修完再截屏确认。"带着问题看"和"随便看看"的差距，就是能不能定位到具体问题。

还有个点，多数人想不到：这份关注点清单，让任务模型来写，比你自己写更准。

倒不是人不够聪明，是信息不对等。你描述问题时，只能凭肉眼看到的现象去猜原因——"弹窗好像被挡住了"。而任务模型手里握着完整的上下文：它刚改了哪几行、动了哪个组件、这次改动可能牵连什么。让它来生成检查清单，等于让最了解病情的人开化验单，每一项都冲着这次改动的风险点去，不漏项、也不浪费。你写 prompt，写的是"我看到了什么"；它写 prompt，写的是"这次改动可能影响什么"。后者才是验收真正该查的东西。

所以整个环节里你要做的只有一件事：提需求。剩下的——生成检查清单、看图、比对、定位——两个模型自己接力完成。

交互：页面长得对，不代表点得动

光看静态画面不够。我踩过一个很典型的坑：一个列表页，渲染出来完全正常，数据也在，但点"删除"按钮没反应。

后来发现是按钮上盖了一层透明的绝对定位元素，视觉上完全看不出来，只有实际点击才会暴露。这种问题，截一百张屏也发现不了，必须真的去点。

所以交互层靠浏览器自动化：AI 控制 Chrome，像真实用户一样操作页面——

打开页面 → 获取元素 → 点击 → 输入 → 等待结果 → 确认状态

比如验证一个删除流程：

1. 打开列表页
2. 找到第一行的「删除」按钮，点击
3. 等待确认弹窗出现（最多 5 秒）
4. 点击「确认」
5. 等待列表刷新（等"删除成功"提示出现）
6. 确认第一行数据已消失

这里有个细节值得单独说：等待是条件式的，不是死等几秒。现在前端全是 SPA，点击后内容异步加载，如果点完立刻检查，大概率截到一张白屏或者中间态，然后 AI 误判"功能坏了"。条件等待是等某个元素出现、等某段文案出现，等到了才继续——验的是最终状态，不是中间态。

网络：页面"正常"，可能只是没报错

还有一种更隐蔽的情况：页面看起来一切正常，其实接口早就 500 了。

我遇到过一次：表单提交后页面没有任何反应，但也没有报错提示。肉眼看是"点了没反应"，查了网络请求才发现——接口返回 500，而前端代码压根没写错误处理，失败得悄无声息。

这种问题用户描述不出根因，AI 如果只看页面也发现不了。所以网络层要直接查请求：

• 筛出失败的请求（网络层失败或状态码 ≥ 400）
• 看具体某个请求的响应体，确认接口到底返回了什么

AI 拿到"POST /api/submit 返回 500，响应体是 {"msg": "字段缺失"}"，就能直接定位是前端没传字段还是后端校验问题。不用你再当人肉传话筒，把截图和报错来回搬运。

控制台：UI 能看，不代表没埋雷

最后一层是控制台。有些 bug 的特征是：UI 恰好还能看，控制台已经炸了。

比如一个数据面板，某个字段 undefined，页面上显示空白——用户觉得"这个卡片没数据"，凑合能接受。但控制台里每次渲染都在抛 Cannot read properties of undefined，哪天上游数据结构一变，整个面板直接白屏。

这种雷不炸的时候没人管，炸的时候就是线上事故。所以验收的最后一环是拉一遍控制台日志，按级别过滤，error 和未捕获异常一个不留。UI 能看只是及格线，控制台干净才算交付。

五、两种循环放一起看

人肉验收循环（你当验收员）：

描述需求 → AI 生成 → 编译通过 → "已完成"
    ↓
你跑起来 → 肉眼看 → 手动点 → 发现问题
    ↓
截图 → 组织语言描述 → 发给 AI → 等修改
    ↑                              ↓
    ←────── 再完整验一遍 ←───────┘

AI 自验收循环（AI 当验收员）：

描述需求 → AI 生成 → 编译通过
    → 启动 dev server → 截屏分析（视觉层）
    → 浏览器操作验证交互（交互层）
    → 查网络请求（网络层）
    → 查控制台日志（控制台层）
    → 有问题？修 → 回到编译验证
    → 全部通过 → 才说"完成"

区别一目了然：人肉循环里，发现问题的是你，描述问题的是你，复验的还是你。AI 自验收循环里，这三件事都发生在 AI 内部，你只在需求入口和最终交付两个点出现。

六、算笔账：一个下午 vs 三分钟

拿一个真实需求算：给现有管理后台加一个「批量导出」功能，含弹窗、进度条、完成提示。

注意最后两行。省时间只是表面收益，心流不中断才是 vibe coding 该有的样子——你的注意力始终在需求上，不在验收上。

七、最后说两句

Vibe coding 最大的错觉是"AI 都能写代码了，我只要提需求"。但真用起来你会发现，你并没有从开发里解放出来，只是从"写代码"换岗到了"验收代码"——而且这个新岗位没有下班时间。

瓶颈从来不在生成，在验收。AI 什么时候能自己看页面、自己点按钮、自己查报错，什么时候你才算真正从循环里出来。

我目前主力是 Codex 和 UseIO，两家都在往这个方向走：Codex 内置 Goal 契约，写完会自己跑测试自查；UseIO 把四层验收做成了开箱即用的闭环，不用装 skill、不用写 prompt，改完代码它自己截屏、自己点页面、自己查请求和日志，全过一遍才交付。感兴趣可以去 GitHub 搜 UseIO 试试。如果你有更高效的验收工作流，或者踩过别的坑，评论区聊。