别急着 Vibe Coding：AI 三小时写完需求后，我为什么宁愿多花一天

发布日期：2026-08-03

标签：前端 / AI 编程 / Cursor / Vibe Coding / 工程实践 / 职业成长

去年底开始，技术群里流行一个词：Vibe Coding。

大意是：别写详细方案了，把感觉丢给 Agent，看它往哪冲；不对就再聊两句，对了就合并。三小时出一个需求，下午还能摸鱼------听起来像前端的新春。

我试过。真的很快。也真的翻过车。

有一次活动页，Agent 一个下午交卷：组件齐、样式过得去、交互也能点。我很得意地提了 MR。Review 当晚被打回四处；修到第三天，我把 AI 生成的 将近一半文件删掉重写。不是它写得「不会跑」，是它写得「会跑，但谁都不敢碰」。

这篇文章不是反 AI，也不是教你关掉 Cursor。我想诚实地聊一件事：

速度到手之后，真正稀缺的变成了：敢不敢慢下来，把代码变成别人接得住的资产。

如果你正处在「AI 让我飞起来」的兴奋期，希望这篇能帮你少交一次学费。

一、Vibe Coding 为什么会上瘾？

因为它精准击中了前端工作里最耗情绪的三段：

空白页恐惧 ------ 从 0 到第一屏，Agent 比人更不怕丢人。
重复劳动 ------ 表单、列表、弹窗、权限按钮，模式高度相似。
上下文切换 ------ 文档、设计稿、接口、本地报错，Agent 能一口气串起来。

所以它不是「智商税」。在正确场景里，它就是杠杆。

问题出在：我们把「能跑」误当成了「能交付」。

感觉上很快	实际上可能发生了什么
文件一下子冒出来很多	抽象层多了三层，没人需要
类型都过了	业务边界用 `any` 糊过去了，或者类型很完整但和真实接口对不上
UI 看起来像设计稿	空态、错误态、权限态全是快乐路径
自己测一遍 OK	只有你那条路径 OK，移动端 / 弱网 / 老数据没摸过

Vibe Coding 的快感来自 连续正向反馈 ；工程价值来自 可维护的负向约束。这两件事，经常打架。

二、我踩过的四个坑（都是「当时觉得挺爽」）

坑 1：需求还没对齐，代码先写了 800 行

Agent 最擅长「把模糊话补成完整实现」。你说「做一个筛选面板」，它能给你状态管理、URL 同步、埋点、骨架屏。

结果产品第二天改口：只要三个下拉，不要 URL 同步。

你删代码的时间，往往比手写三个下拉更长------因为你要先读懂 AI 的「完整宇宙」。

教训：模糊需求先 Ask / Plan，再 Agent。一句「先别写代码，列出你理解的范围和不确定点」能省一天。

坑 2：每个文件都「很规范」，合在一起却很陌生

命名整齐、Hooks 拆得干净、注释像教科书。但仓库里突然多了 useXxxOrchestrator、XxxProviderFactory、createFeatureContext------团队从来没用过这套词。

AI 写的是「通用最佳实践」；你们仓库要的是「本地方言」。

教训：没有 Rules / 示例文件约束时，Agent 会把互联网平均水平灌进你的项目。规范进仓库，比事后吐槽「风格不对」有效一百倍。

坑 3：Bug 用「再生成一次」解决

报错贴进去，Agent 改一版；又报错，再改一版。三轮之后，逻辑像缠绕的耳机线------每处都能解释，整体没人讲得清。

教训：修 Bug 时，先逼自己用一句话说清根因，再让 Agent 改。说不清就先 Debug / 读栈，不要开「盲盒循环」。

坑 4：个人飞起来了，协作变慢了

自己用 Agent，一天三个 MR；同事 Review 不过来，开始害怕点开你的 diff。效率从个人指标上看涨了，从团队吞吐上看------可能掉了。

教训：AI 提效必须以「别人能快速 Review」为边界。否则你只是把瓶颈从「写代码」挪到了「审代码」。

三、我现在的默认节奏：快，但留三道闸

用了大半年，我把个人流程收成一句口诀：

先对齐，再生成；先读懂，再合并；先护栏，再加速。

闸门 1：生成前 ------ 用 10 分钟买保险

动手前强迫自己写清四行（可以打在对话里）：

text 复制代码

目标：用户完成后能做什么？
范围：这次明确不做哪些？
验收：哪 3 个操作必须手测通过？
约束：必须遵循仓库里哪几个现有模式/文件？

写得出来，就让 Agent 干；写不出来，说明还在 Vibe，不在 Coding。

闸门 2：生成后 ------ 先当 Reviewer，再当作者

Agent 停手后，我不再立刻 git commit，而是换个身份扫一遍：

删：没有调用方的工具函数、过度抽象、重复封装
问：这段为什么存在？换成团队已有写法会不会更短？
验：空列表、失败接口、无权限、慢网络，至少各点一次

一个粗暴标准：

如果我不敢在站会里用两分钟讲清「改了什么、为什么这样改」，就还不能合并。

闸门 3：合并前 ------ 让机器先骂一顿

本地至少过三关再提 MR：

类型检查 / Lint
相关单测或关键路径手测
自己把 diff 当陌生人读一遍（是的，读自己的 AI diff）

团队若已有 CI，别在红灯时说「先合后补」------AI 时代最容易养成这个坏习惯，因为「再让它修一下」永远有下一轮。

四、一张表：什么适合 Vibe，什么必须慢

场景	可以更 Vibe	必须更慢
内部工具、原型、Spike	✅
标准 CRUD、明显照着现有页抄	✅
活动页视觉 Demo、一次性脚本	✅
权限、钱、隐私、订单状态		✅
多人长期维护的核心模块		✅
性能敏感、复杂状态机、并发		✅
「我自己都说不清需求」		✅ 先澄清

判断口诀：

错了可以今晚回滚 → 允许快
错了会悄无伤用户或同事 → 必须慢

五、慢一天，通常在慢什么？

很多人以为「慢」等于「不用 AI」。不是。

我多花的那一天，通常花在这些更值钱的地方：

把需求从形容词变成验收句 ------ 「好看一点」变成「首屏 3 张图可左右切换，失败展示重试」。
对齐仓库方言 ------ 指定参考文件，让 Agent 抄本地模式，而不是抄博客。
砍掉多余抽象 ------ 生成 10 个文件后，合并回 3 个也常见。
补齐不快乐路径 ------ 空、错、权限、加载，这四态比主路径更能决定线上质量。
写给下一个同事看的说明 ------ MR 描述里写清意图；三个月后你就是那个同事。

这些事，AI 能辅助，但不能替你做最终判断。而判断，正是 AI 时代前端不可替代的竞争力里最贵的那一块。

六、给你一份可直接抄的对话模板

下次想 Vibe 一把之前，可以把这段贴进 Agent：

text 复制代码

先不要改代码。

请基于仓库现有实现，回答：
1. 你理解的目标与范围（含「不做清单」）
2. 你会改哪些文件，为什么
3. 最大的 3 个不确定点
4. 建议的手测验收步骤

等我确认后，再按确认范围最小改动实现。
不要引入仓库里不存在的新架构模式。

确认后再说：

text 复制代码

按刚才确认的范围实现。
改完后列出：新增/修改文件、你主动砍掉的过度设计、我需要手测的路径。

两段话，常常比「帮我把这个需求做了」便宜一个周末。

结语：飞起来之后，记得留降落跑道

Vibe Coding 会留下来。它降低了「从 0 到能跑」的门槛，这是好事。

但它不会自动给你：

和产品对齐的能力
对线上风险的直觉
让同事敢合并你代码的信任

所以我现在的态度很简单：

能快则快；快完必须过闸。宁肯多花一天把资产做干净，也不要三小时堆一栋别人不敢住的楼。

如果你也有一段「AI 写完 → 自己连夜拆」的经历，评论区欢迎聊聊------你后来给自己加的第一条护栏是什么？

别急着 Vibe Coding：AI 三小时写完需求后，我为什么宁愿多花一天