上个月接了个内部工具的活：一个报销审批系统，前端 Vue3 + Element Plus，后端 FastAPI + MySQL，前后端分离。我把需求文档丢给 AI：“帮我把这个系统做出来。”

它还真做出来了。前端十几个页面，后端二十多个接口，编译零报错，测试全绿。我满怀期待地把前后端跑起来，登录，打开第一个页面——

表格把侧边栏顶出去了。提交按钮在移动端飞到了屏幕外。审批意见的弹窗被表头盖住一半。

我点"提交报销单"，转了两秒，页面没任何反应。打开 F12 一看，接口 500，后端日志里躺着一条 KeyError: 'invoice_date'——前端传的是 invoiceDate，后端收的是 invoice_date。

AI 写代码确实快，但"写完"和"能用"之间，还隔着联调验收这道坎。

一、前后端一体工程，验收比单页应用难一个量级

让 AI 写一个单组件、一个工具函数，验收很简单：跑个测试，看一眼输出，完事。

但前后端一体的工程不一样，验收要过三道关：

头一关是样式布局。 编译通过不代表布局对。弹窗的 z-index、下拉弹层被父容器裁掉、表格列宽在小屏幕下的表现、侧边栏折叠后的内容区自适应，这些问题只有把页面真正渲染出来才能发现，代码层面看不出来。

第二关是接口联调，也是重灾区。 字段命名风格对不上（前端驼峰、后端下划线）、分页参数一个从 0 开始一个从 1 开始、时间格式一个带时区一个不带、错误码约定不一致导致前端把业务失败当网络错误处理。每一项单拎出来都是小事，凑在一起就是"页面能开但功能不对"。

第三关是看不见的雷。 页面看起来正常，但控制台里躺着未捕获的 Promise 异常；接口返回 200 但 body 里是错误信息，前端没处理；某个请求静默失败，列表显示的是上一次的缓存数据。

这三关有个共同点：问题都不在代码里，在运行时。 你盯着代码看一万遍，也看不出弹窗会被表头盖住。

二、传统做法：你自己当联调验收员

遇到这些问题，大多数人的工作流是这样的：

跑起前后端，自己点开页面，发现表格顶出去了。截图，框出问题，组织语言："表格溢出了容器，可能是 min-width 设置的问题。"发给 AI。它改一版。你再跑，再看——这次表格好了，但弹窗又出问题了。再截图，再描述……

一个下午过去，AI 写代码花了二十分钟，你给它当验收员花了三个小时。

有人会说：给 AI 配上浏览器工具不就行了？我试过，这条路比想象中累：

先得自己找工具。 社区里浏览器相关的 MCP 好几个，Playwright MCP 偏页面操作，Chrome DevTools MCP 偏网络和控制台诊断，各管一摊。你得先搞清楚自己的场景需要哪个——多数时候是两个都装，因为"点按钮"和"查接口"是两件事。

再得看适配不适配。 不同工具的配置方式不一样：有的用命令行 mcp add 注册，有的在设置界面里填 command 和 args。配完了还得确认工具名前缀——同一个"点击页面元素"，在这个工具里叫 browser_click，在那个工具里又换了别的叫法。AI 能不能正确调用，取决于你用的这个工具对这个 MCP 的支持程度。

配完了还有能力缺口。 MCP 返回给模型的大多是结构化快照——页面有哪些元素、什么层级、什么属性。这对"点击某个按钮"够用了，但对"布局歪了"无能为力。快照里没有像素。 弹窗被表头盖住、长文本没截断把卡片撑变形、两个组件重叠了 3 像素——这些纯视觉问题，结构化快照永远看不出来。最后还是得你截图发给它。

绕一圈回来，视觉验收这一环，还是断的。

三、我现在的做法：AI 自己跑服务、自己看页面、自己查接口

后来我换了个思路：验收这件事，为什么不能让 AI 自己干？

现在做前后端一体的工程，我的用法很简单：代码写完，让它自己把前端 dev server 和后端服务跑起来（常驻进程，日志随时能读），再自己开浏览器，登录，一页一页过。

表格把侧边栏顶出去了？它截屏看到，自己改样式，改完再截屏对比，确认恢复了才继续下一个页面。

点"提交报销单"没反应？它自己查网络请求，看到接口 500，再看响应体和后端日志，定位到前端传 invoiceDate、后端收 invoice_date——字段名对不上。改完再点一次，看到 200 和正确的返回，这一环才算过。

页面看着正常？它还会查一遍控制台日志，把未捕获的异常和静默失败的请求翻出来。我管这个叫"像开发者开 F12 一样诊断"：不是等用户报障，而是交付前自己把雷排掉。

整个过程我不碰浏览器、不开 F12、不截图。它交付给我的，是它自己看过、点过、查过的页面。

四、双模型协同：任务模型再强，也得有双眼睛

这套流程能跑通，有个前提：任务模型和视觉模型是分开的，各干各擅长的活。

任务模型负责写代码、拆任务、决定怎么修，这是它的强项。但布局歪没歪、弹窗有没有被遮挡、图标和文字是不是没对齐，这些是像素层面的事，得靠视觉模型看截图来判断。

两边的结论还能对得上：视觉模型说"表格溢出了容器"，任务模型去查样式代码，找到 min-width 的问题，改完再截屏给视觉模型复核。一个负责看，一个负责修，来回几轮，问题就清了。

这就是前面说的 MCP 快照做不到的事——快照里有结构没像素。而纯靠任务模型硬看 DOM 代码猜布局，猜十次错八次。

五、算笔账

同一个报销系统，两种验收方式的差距大概是这样：

	我自己当验收员	AI 自己验收
发现问题的方式	我点开页面逐个看	AI 截屏+交互+查日志
反馈成本	截图+描述，每轮 3-5 分钟	0（它自己内部转）
接口联调定位	我开 F12 查请求，复制报错给它	AI 直接看失败请求的响应体
返工轮次	5-8 轮	1-2 轮
总耗时	一个下午	半小时左右（我只看最终结果）

省时间是明面上的。更舒服的是心流回来了：前者你的注意力全耗在验收上，需求本身反而没时间想；后者你只管提需求，验收是它的事。

六、总结

目前 AI 写代码这事没什么稀奇的，前后端一体的工程也能一口气写出来，编译零报错。

但"写完"和"能用"之间，隔着联调验收这道坎：样式布局要看渲染，接口联调要看请求，看不见的雷要查控制台。这些问题没一个在代码里，全在运行时。

谁能把验收闭环做进工具里，谁交付的就是"能用"，而不是"写完了"。

我现在开发主要靠两个工具：Codex 和 UseIO。先说 Codex，最近半年微软突飞猛进，在开发自检上下了非常多的功夫：应用内置了浏览器，写完前端会自己打开页面点 UI、抓视觉错误、跑 UI 测试；配上 /goal 工作流，能自己规划、跑单元和集成测试、调试，浏览器里确认没问题再才算完成，全程不用人盯。Chrome 扩展还能带着真实登录态并行开子代理，跑完自动汇总报告。单说"写完自己查一遍"这件事，它已经做得很扎实了。

再说 UseIO ，同样是看页面，可以配置任务模型和视觉模型，当两个模型都配置时，agent开发就是一个改代码，一个专门看屏幕、分析截图、管布局像素层面的事，两个模型互相印证，任务模型不用靠代码推测布局、颜色、层级等等，返工轮次比很多AI工具少太多了（PS：这里必须点赞：api调用次数、token随之也变少了）。查问题的手段也更多：除了操作浏览器之外，控制台console日志、network网络请求、失败接口的响应、前后端常驻进程的日志都能一起看。前端传参、接口响应、后端日志，都可以快速定位，跟我手动开 F12 排查完全一个路数。最关键的是这些能力都是开箱即用的，不用我自己到处找 Skill、配 MCP，找完还得自己验证合适不合适，感觉不要太好。 入坑过AI前后端一起开发的童鞋都不妨用来试试！