2026年4月13日 · 阅读 —
什么是 Vibe Coding 和 Vibe Testing：把“氛围”变成可交付的工程
什么是 Vibe Coding 和 Vibe Testing：把“氛围”变成可交付的工程
==Vibe Coding==
翻译成“氛围编程”有点怪，但意思很直白：写代码时不再从语法和文件结构起步，而是先说“我想要什么感觉/意图”，让 AI 先把实现铺出来，再通过对话迭代到可用。
同一套思路也开始渗到测试里，变成 Vibe Testing：不先写死一堆脚本，而是先定义“用户体验应该是什么 vibe（快、顺、丝滑、稳）”，让 AI 去探索、去找“不对劲”的地方。
这篇文章基于 Anushree Chatterjee 的文章《What are Vibe Coding and Vibe Testing?》重新思考：概念、实践流程、底层引擎、反馈回路，以及 vibe testing 的实操方法。
01. Vibe Coding：先定意图，再写约束（别把氛围当需求）
Vibe Coding 更像“跟 AI 结对编程”：
- 你用自然语言描述目标与体验
- AI 生成代码
- 你审一眼/跑一下
- 再用 prompt 迭代细节
它厉害的地方是把“从 0 到能跑”压得很短。
但天花板也很明显：性能、安全、可维护性、可观测性这些东西，不能靠“感觉”交付。
所以正确姿势是：
vibe 用来定方向，DoD（验收标准）用来锁结果。
02. Vibe Coding 的完整实践流程（从 Big Picture 到 Debug）
按工程视角把 vibe coding 整理成 5 步：
Step 1：Start with the Big Picture
不要一上来就写 <html> 或 public static void main。
先用人话描述目标：
“我想要一个简单网页：有一个联系表单；顶部标题写 ‘My Awesome Project’；点按钮后显示成功提示。”
Step 2：Prompt Your Intelligent Assistant
把目标喂给 AI coding assistant。它要做的是理解意图并生成可运行代码，不是“去搜答案”。
Step 3：Review and Refine
AI 吐出一份代码后，你要审：
- 结构对不对？
- 行为是不是你想要的？
- 有没有明显工程缺口（错误处理/类型/边界条件）？
很多人 vibe coding 翻车，不是 AI 写不出来，是人不审。
Step 4：Iterate and Direct the Vibe
你用体验语言下指令，让 AI 做细节改动：
- “按钮太土 → 做成现代、干净、柔和蓝色渐变”
- “成功提示太慢 → 立刻出现，2 秒后淡出”
Step 5：AI-Assisted Debugging（Testing vs Debugging）
你可以问：
- “为什么表单不提交？”
- “按钮没按预期工作，哪里不对？”
但要加上证据锚点（日志/文件范围/最小 diff），否则 AI 会猜。
Debugging 解决“为什么坏了”；Testing 解决“会不会再坏、边界有没有漏”。
03. 反馈回路（Feedback Loops）：Vibe Coding 的威力在“循环”
Vibe coding 的核心循环是：
- Prompt → Generate → Review → Refine
直到 vibe 对齐。
工程上建议把它写成 SOP：
- Prompt（意图 + 约束 + DoD）
- Generate（出能跑的骨架）
- Review（最短路径验收：预览/关键路径/跑一条验证命令）
- Refine（一次只改一个维度：UI/行为/结构分轮次）
一次只改一个维度很关键：否则 AI 会同时改 UI/逻辑/结构，你根本不知道 bug 从哪来的。
04. The Engine Behind Vibe Coding：它靠什么跑起来？（四层结构）
vibe coding 不是“聊天框魔法”，更像四层系统叠起来：
4.1 LLM：理解意图、生成代码、维护上下文
- 理解意图：它理解“contact form”这个概念，而不是逐词匹配
- 生成代码：基于训练中学到的大量代码模式，一次性生成 HTML/CSS/JS
- 上下文感知：同一对话里能记住你前面的指令（比如“把刚才那个提交按钮改绿”）
工程提醒：上下文窗口有限，越长对话越要把关键约束写回到文档/注释/测试里。
4.2 工具层（Code Generation Tools）：把 LLM 变成可用的编程界面
- IDE 插件（例如 VS Code 扩展）：在工作区内生成函数/文件、理解项目结构
- 专用平台：能 scaffold 项目，把 vibe + 约束变成目录结构与代码骨架
4.3 交互式开发环境（Interactive Dev Environment）：实时反馈 + 集成工具
- 实时错误提示（语法/类型/潜在问题）
- git / debugger / test runner 集成
- 有时有可视化预览（网页开发尤其重要）
4.4 Feedback Loops：持续对话迭代，而不是一次性生成
没有反馈回路，你得到的是“生成一段代码”。
有反馈回路，你得到的是“可控迭代”。
05. Examples：Vibe Coding 更适合的三类典型场景
- 快速原型：先把能点能动的意图跑出来
- 新手/非开发者：AI 出骨架，人负责创意与迭代
- 样板代码：server scaffold、CRUD 骨架、重复配置交给 AI
06. 什么是 Vibe Testing：从“检查功能”转向“验证体验是否对齐”
Vibe testing 更像一种 QA 组织方式：
- 先定义体验标准（vibe）
- AI 生成并执行探索式测试（不是跑死脚本）
- AI 标记体验偏差（vibe deviations）
- 人类做最终判断与校准
07. Vibe Testing 怎么跑：定义 vibe → AI 探索 → 标记偏差 → 人类校准
7.1 定义 vibe（把抽象词翻译成检查点）
“快、顺、稳、丝滑、专业、安全感”必须落成 checklist：
- 专业：hover/active 一致、字号间距统一、错误提示一致
- 快：首屏 < 1.5s、交互响应 < 100ms、loading 动画不掉帧
- 安全感：关键操作二次确认、失败信息明确、可撤销提示
7.2 AI 生成并执行测试（探索式）
- 生成多样场景：扩展路径与边界
- 模拟真实用户行为：点/填/滑/乱序操作/快速连点
- 尝试破坏系统：找脆弱点
7.3 AI 标记“vibe deviations”
比如：
- 轻微延迟导致“显得卡”
- 字体/间距不一致导致“不专业”
- 动画掉帧导致“不丝滑”
- 某路径崩溃导致“不可靠”
最好能同时输出：复现路径、日志/截图、可能原因。
7.4 人类监督与校准
- 验证关键问题（避免误报）
- 校准阈值与规则（把“可接受”教给 AI）
08. Vibe Testing 的 4 个典型案例
- UI/UX 一致性：全站按钮 hover/click feedback/响应时间一致
- 感知性能：不仅看 2s 数字，还看动画是否顺、是否渐进呈现、是否 layout shift
- 细微 bug：特定快速操作序列才出现的 glitch（AI 更擅长跑出来）
- 自动化 UAT：验证用户旅程“是否让人有信心/不慌/不迷路”
09. 边界再强调一次：vibe ≠ 免责
Vibe coding / vibe testing 不是让工程变轻松，而是让“表达意图”和“探索空间”更大。
如果不补工程门禁（测试/CI/评审/约束），你只是更快地产生更多不稳定代码。
10. Vibe Coding 的方法论：它不是写代码的新姿势，是“表达与约束”的新秩序
你可以把 Vibe Coding 当成一种“思维方式”而不是工具：它把开发从“写行”改成“控熵”。
10.1 意图优先（Intent-first）：先把要达到的体验说清楚
传统开发常见起手式是“从实现推需求”：先写框架、先搭目录、先补胶水。
vibe coding 的起手式反过来：
- 用户要完成什么任务？
- 过程中什么体验最关键（快/顺/安心/专业）？
- 哪些是绝对不能变的约束（权限、数据、边界）？
它的价值不是省敲键盘，而是避免你和团队在“实现细节”上提前内耗。
10.2 约束即规格（Constraints as spec）：把“不能做什么”写得比“想做什么”更清楚
vibe coding 最容易跑偏的原因只有一个：
你给了它自由，但没给它边界。
所以方法论里最关键的不是“更会写 prompt”，而是把约束写成一组机器能遵守的规则：
- 允许改哪些文件/目录
- 不允许动哪些模块（支付/权限/核心链路）
- 必须通过哪些命令（
npm test、npm run build） - 输出格式/日志/错误处理的规范
10.3 小步迭代（Small diffs）：每轮只改一个维度，留证据链
vibe coding 的理想节奏是“导演式迭代”：
- UI 一轮
- 行为一轮
- 结构一轮
每轮都能解释：
- 改了什么
- 为什么这么改
- 如何验证
这让你在需要回滚时不会绝望。
10.4 证据优先（Evidence over vibes）：用日志、截图、测试把“感觉”钉成事实
一个成熟的 vibe coding 团队，会把“感觉”翻译成证据：
- 视觉：截图/录像/视觉回归
- 行为：关键路径 E2E
- 性能：Web Vitals / 指标阈值
- 稳定：错误码与重试策略
最终目标是：
vibe 是方向盘，但证据链才是刹车。
10.5 常见反模式（踩中一个就会变成玄学）
- 反模式 1：只讲 vibe，不讲 DoD
- 反模式 2：让 AI 同时改 UI/逻辑/结构
- 反模式 3：没有一键验证命令，靠“看起来没问题”合并
- 反模式 4：把 AI 当外包，自己不审（最后一定会在生产环境审）
11. Vibe Testing 的方法论：把“体验”升级为一等公民的质量模型
==Vibe Testing 不是“用 AI 写更多测试”。它更像把测试从“功能正确性”扩展到“体验一致性”。==
11.1 先定义体验契约（Experience Contract）
Vibe Testing 的第一步不是写用例，是写“体验契约”：
- 目标用户是谁
- 关键旅程是什么（登录、下单、发布、付款…）
- 体验底线是什么（不迷路、不慌、可撤销、错误提示清晰）
这份契约要能被任何人理解，也要能被机器部分验证。
11.2 把 vibe 拆成四类质量属性（更容易落地）
把“顺/快/稳/专业”拆成可落地的质量属性：
- 一致性（Consistency）：样式、交互反馈、文案、错误提示
- 可感知性能（Perceived Performance）：不是只看 2s，而是看加载动画、渐进呈现、抖动
- 可恢复性（Recoverability）：失败是否可理解、可重试、可回退
- 信任感（Trust）：敏感操作是否明确、是否有确认、是否有解释
11.3 实践方向：从“探索”开始，但要有“可复现”收尾
AI 探索式测试能跑出很多“人想不到的路径”，但如果只停留在“我觉得不对劲”，团队会烦。
落地上必须做到：
- 每个偏差都能输出最小复现路径（操作序列）
- 能带截图/日志/trace
- 能定位到组件/页面（至少到路由级）
这才会变成“可修复的缺陷”，而不是“体验吐槽”。
11.4 把 Vibe Testing 接进 CI 的最小落地方式
别一上来就想做“全自动 vibe judge”。先从最硬的几项开始：
- Lighthouse/Web Vitals 阈值（LCP/CLS/INP）
- 视觉回归（关键页面截图 diff）
- E2E 关键旅程（Playwright/Cypress）
- a11y 基线（axe）
这些先跑稳，再谈 AI 去探索更多路径。
11.5 人类的角色：不是执行者，而是“校准器”
Vibe Testing 里人类最重要的工作不是点按钮，而是：
- 定义阈值与体验底线
- 决定“哪些偏差算问题、优先级多高”
- 不断校准 AI 的判断标准
一句话：
让 AI 负责覆盖空间，让人负责价值判断。
AI 时代的编程与测试：靠 vibe 起步，靠 DoD 交付
#VibeCoding #VibeTesting #软件测试 #AI编程 #LLM #质量工程 #自动化测试 #E2E #CI