最近一段时间我在持续实践 Harness engineering（把规则、流程、护栏、脚手架先搭好，再让 AI 在框架里跑），体感开发效率确实提高了不少。
但效率上来以后，新的问题也更刺眼：真正拖慢 vibe coding 飞轮的，不再是“写代码”，而是“把代码验证成可交付的软件”。
非 AI 的总结
- 结论一：测试是 vibe coding 的瓶颈。
- 结论二：GUI 老兵不死——CLI 再火，也不可能取代 GUI。
- 结论三：未来更现实的形态是：GUI + CLI 并行，AI 做 AI 擅长的，人类做人类擅长的。
下面展开这周两个最有价值的经验。
一、测试是 vibe coding 的瓶颈
AI 把“产出代码”这件事的边际成本打到很低：
- 改一处功能很快
- 重构一层也很快
- 加一个模块更快
但代价是：代码量膨胀速度远超测试能力增长速度。当代码规模上去，你会发现测试需求不是线性增长，而是接近指数增长：
- 功能越多，组合越多
- 分支越多，回归越多
- 依赖越多，牵一发而动全身
更致命的是：很多产品的核心体验都在 GUI 上，而 GUI 测试天然难：
- 面向人类的交互路径多、状态多
- 视觉反馈难以结构化
- UI 自动化一旦碰到弹窗、遮罩、引导层、验证码、异步加载……就容易崩
于是 vibe coding 的飞轮变成：
开发（快）→ 测试（慢）→ 修复（快）→ 再测试（更慢）
最后“最慢的一环”决定整体吞吐。
我目前的解决方案：三段式测试流水线
1）用脚本做开发环境的单元测试，形成开发-测试-修复闭环
把能单测的尽量单测：
- 业务逻辑
- 数据结构 / schema
- 配置解析
- 接口契约
目的不是追求“100% 覆盖率”，而是让 AI 的高频迭代有一个可重复、可自动化的安全网。
2）在单测护城河上，用 AI 根据 commit 信息生成“功能测试清单”
这一步很关键：
- 人类很难在高频 commit 下保持“测试清单同步更新”
- AI 反而擅长从 diff/commit message 里总结“我改了什么，可能影响什么”
产出的不是测试用例代码，而是一份“本次改动应该检查哪些路径”的 checklist。
3）发布前人工收尾 GUI 测试
很现实：现阶段 GUI 的端到端测试仍然是最难彻底自动化的部分。
人工收尾不是退步，而是把人力用在最值钱的地方：
- 体验是否连贯
- 关键路径是否通顺
- 视觉/交互是否符合预期
下一步：我想做一个 vision-based AI Test
测试完备性一直是软件工程的老大难，而 GUI 又是最难的那块。
我接下来想尝试搭一个基于视觉的 AI 测试（vision-based AI Test）：
- 像“人”一样看屏幕
- 像“人”一样点按钮
- 用视觉结果判断状态
目标不是一开始就做通用 E2E，而是从最朴素的场景开始：
- 启动是否成功
- 关键按钮是否可用
- 页面是否进入到预期状态
- 弹窗/教程浮层是否出现并可关闭
如果这条路能跑通，vibe coding 的“最后一公里”就能再省掉一大块人工。
二、GUI 老兵不死
最近一段时间 CLI 风头很大，甚至有人高喊“GUI 已死”。
但我这段时间更深的体感是：指望完全通过对话来完成任务，既低效也不现实。
1）GUI 是新用户的引导系统
没有 GUI 的产品，很多时候等于没有“路标”。
对一个新用户来说：
- 面对聊天框，他不知道有哪些功能
- 不知道应该怎么问
- 更不知道“问错了”会发生什么
GUI 把“可用性”摊开给用户看：
- 我能做什么
- 我现在在哪
- 下一步怎么走
这是一种非常强的“认知减负”。
2）多媒体交互的信息密度，天然高于文字
文字聊天的优点是灵活，但它的信息密度并不高：
- 你需要把信息线性读完
- 你需要在脑子里构建结构
- 你需要自己记住上下文
而 GUI（尤其是图表、表格、预览、拖拽、可视化状态）天然具备并行信息：
- 一眼看到全局
- 直接操作对象
- 用空间组织复杂度
这不是审美偏好，是信息论层面的效率差异。
结语：GUI + CLI 并行，AI 和人各归其位
我越来越相信一个更现实的未来形态：
- GUI 负责“可见、可探索、可控”的交互
- CLI/对话负责“表达意图、生成内容、自动化执行”的部分
让 AI 做它擅长的：
- 总结
- 生成
- 批处理
- 重复劳动
让人类做自己擅长的：
- 判断
- 取舍
- 体验审美
- 最终验收
Harness engineering 的意义，也许就在这里：
不是让 AI 更聪明，而是让 AI 在正确的轨道上更稳定地跑。