今天跟大家分享一下我这一年多来VibeCoding的浅薄经验和拙见，以及一些实际使用AI Agent时的具体细节。
首先，在VibeCoding时代纠结技术栈是没有意义的，前后端你都要会，这是前提。其次，后端至少精通一门大众化的编程语言，这对于你了解其它陌生语言很有帮助。还需要有敏捷的学习能力，对于其它的编程语言和特性，你要有迅速过一遍w3c、菜鸟教程这种基础知识后就能修改、编写代码的能力，遇到不会的点再通过AI补齐。如果没有上述这些要求就能难保证AgentCoding后的代码质量，虽然在模式领域你未必有AI强。
其实我觉得很多人都误解了VibeCoding这个词，有人把它理解成“想到什么就让 AI 生成什么”，有人把它理解成“少写代码、全靠模型”，也有人把它当成一种带点戏谑意味的开发方式：先有感觉，再看结果，能跑就行。
这里放一张很有意思的图：
哈哈哈哈哈哈……其实我个人更倾向于第二到第四种，深度的依赖AI但是不做“AI人柱力”，一些需求、debug和review的工作确实需要人工来把控，但是用过GPT5.4和ClaudeOpus4.6的都知道它们的能力有多强，可以预见未来可能真的会发展成第五种，这时候我觉得我们不该考虑未来会不会被替代，而是现在怎么去使用它们。
扯远了，那么VibeCoding在我这里的定义是什么，我的定义是：利用并约束大模型数十倍的提升软件工程项目的一种实施方式。
但真正进入项目现场之后，很快就会发现，事情远没有那么轻松。AI 确实能极大提高开发速度，尤其是在原型设计、代码生成、测试补全、文档整理和重构 review 这些环节里，它已经不是“辅助工具”那么简单了。但与此同时，AI 也会放大另一类问题：需求不清、边界不明、上下文混乱、测试缺失、日志不足、评测缺位。一旦这些基础工作没做好，AI 产出的速度越快，返工也只会越快。
所以，VibeCoding 真正有价值的地方，不在于“随手一问就把项目做出来”，而在于把 AI 纳入一套可控、可验、可复盘的工程流程里，让它负责加速，而不是负责拍脑袋。
这篇文章不讨论“AI 会不会替代程序员”这种大话题，只谈一件更实际的事：在真实开发里，怎样把 VibeCoding 变成一套靠谱的方法；以及，为什么它不应该只是“让 AI 帮忙写代码”，而应当是一整套从需求澄清到项目交付的工作方式。
## 先把整套流程放在前面：我现在使用的 VibeCoding 流程
在展开细节之前，先把完整流程列出来。相比最初那种“需求一说，马上开写”的做法，这套流程更强调边界、验证和可追踪性：
确认需求，同时确认非目标与验收标准
做一轮风险预审：数据来源、权限、依赖、复杂度、上线风险
让 AI 拆分需求、设计信息架构，并快速生成原型
基于原型再次确认需求，收敛歧义
利用AI编写并补充 Prompt 约束：目标、上下文、输出格式、约束边界、错误处理
先写测试用例与验收清单，要求整个过程面向输出结果，必要时补 AI 评测集
让 AI 分阶段生成代码，而不是一次性生成整个项目
强制补齐日志、错误处理、类型约束、配置说明
AI 先做一轮代码 review，再由人工做一轮 review
部署测试环境，跑自动化测试与流程化回归测试
进行人工测试，验证真实使用路径与边界场景
根据测试结果迭代修正，补文档、补监控、补回滚方案后交付
ps：除非是功能确定的小需求，其它时候请务必开启/Plan模式
这套流程看上去比“直接让 AI 开干”更慢，但真实体验恰恰相反：
前面多花一点时间约束问题，后面会少花很多时间来返修。
## 一、VibeCoding 到底是什么？
如果把它说得尽量朴素一点，VibeCoding 可以理解为：
用 AI 参与需求拆解、方案设计、代码实现、测试和 review，但由人来定义目标、边界和最终判断。
这里有两个关键词。
一个是“参与”。
AI 不是外挂，也不是装饰。它确实应该深度参与开发流程，尤其是在重复劳动、结构化输出、初稿生成和批量补全这些环节上，它的效率优势已经非常明显。
另一个是“判断”。
AI 再强，也并不真正理解项目为什么这样做、为什么不能那样做、为什么某个交互虽然“能实现”但不适合上线。
这类判断，仍然是工程经验、产品理解和业务上下文共同作用的结果。
所以，VibeCoding 的核心从来不是“少写代码”，而是重新分配开发流程中“谁更适合做什么”：
AI 更适合做高速度的生成、归纳、重写、补全、检查
人更适合做目标定义、边界设定、质量判断、优先级决策
一旦这个分工关系搞反，VibeCoding 就会从效率工具变成返工工具。
## 二、为什么很多人一上来用 VibeCoding，结果却并不好？
原因其实并不复杂。
### 1. 把“生成能力”误当成“交付能力”
AI 很擅长生成一段代码、一页页面、一个接口、一个 README，甚至一套看上去完整的项目结构。但“生成”不等于“可交付”。
真正的交付至少还包括：
需求边界清楚
代码可维护
日志可追踪
错误可处理
测试可回归
部署可复现
文档可移交
很多项目的问题不是“AI 写错了几行代码”，而是从一开始就没有按交付思路在做。
### 2. 需求没有收敛，就开始让 AI 放大误解
传统开发里，需求不清会导致返工；VibeCoding 里，需求不清会导致更快地返工。
因为 AI 会把模糊描述扩展成看似完整的实现，而这类“看似完整”特别有迷惑性：页面做出来了、接口也有了、数据库也建了，但做出来的并不是要的东西。
### 3. 过度相信“一步到位”
很多人习惯这样下指令：
帮我把一个 XX 系统完整做出来，技术栈用 XX，要求美观、好用、可扩展。
这种提示词的最大问题不是“太短”，而是它默认 AI 会自动理解那些根本没有写出来的东西：用户角色、业务流程、异常处理、权限边界、部署方式、数据约束、验收标准。
现实里，AI 会补全，但它补的是“它认为合理的版本”，不是“项目真正需要的版本”。
所以，VibeCoding 的第一原则其实很简单：
不要一次性让 AI 生成一个项目，而要让它逐层生成一个项目。
## 三、VibeCoding 里最重要的，不是代码生成，而是需求收敛
很多人提到 VibeCoding，第一反应还是“怎么写 prompt 让 AI 写得更好”。
这当然重要，但更关键的问题在于：在开始写 prompt 之前，需求是不是已经被收敛到了可实现、可验证、可交付的程度。
我现在更愿意把需求阶段拆成三件事：
### 1. 确认要做什么
这是最基本的一层：系统要解决什么问题，核心功能是什么，用户是谁，使用路径是什么。
### 2. 确认不做什么
这是 VibeCoding 特别需要的一层。
因为 AI 非常乐于“顺手帮你做更多”，比如默认加登录、默认加分页、默认做权限、默认做搜索、默认加复杂配置。
如果没有明确写出非目标，项目会在不知不觉中膨胀。
### 3. 确认怎么算做完
也就是验收标准。
没有验收标准，最后只能靠“感觉差不多了”；而一旦有了标准，AI 才有可能围绕标准生成，测试也才有锚点。
一个简单的经验是：
只要一句需求描述里同时缺少目标、边界和验收，那它就还不能直接进入编码阶段。
## 四、原型不是装饰，它是 VibeCoding 里最便宜的纠错工具
在传统项目里，很多开发者对原型的耐心不高，尤其是小项目，总觉得“页面我脑子里有数，直接做就行”。
但在 VibeCoding 里，原型的重要性反而更高了，因为它承担的不是“设计展示”功能，而是“快速对齐认知”功能。
让 AI 先输出原型、信息架构、页面流和组件拆分，有几个非常现实的好处：
可以尽早暴露理解偏差
可以快速发现字段设计不合理
可以讨论交互，而不是等代码写完再推倒
可以在低成本阶段调整范围
原型阶段最值得确认的，通常不是颜色、间距和阴影，而是：
用户第一步看到什么
主要操作路径是什么
哪些数据字段必须出现
哪些功能入口应该合并
哪些流程存在歧义
说得直白一点，原型在这里不是为了“更精美”，而是为了“少返工”。
## 五、Prompt 在 VibeCoding 里不是聊天记录，而是开发契约
很多人用 AI 编码时，仍然习惯以聊天方式提需求，这样当然也能工作，但一旦项目稍微复杂一些，聊天式 prompt 很快就会失控。
因为聊天记录会不断叠加临时指令、口头约定和隐含前提，最后连人自己都说不清当前上下文里到底有哪些约束。
更可靠的做法，是把 prompt 当成一份契约文档来写。
一份适合开发阶段使用的 Prompt 契约，至少应该包含这些内容：
项目目标
当前任务范围
输入与输出
技术栈约束
目录与模块约束
类型与错误处理要求
日志要求
不允许擅自添加的内容
测试要求
交付格式要求
例如，与其说：
帮我把待办列表做出来。
不如说：
请实现 TodoList 项目的任务管理模块，仅包含新增、编辑、删除、完成状态切换四个功能。前端使用 Next.js + TypeScript，后端使用 Prisma + SQLite。要求：
不加入登录注册；
组件职责清晰；
必须有表单校验；
关键动作必须加日志；
生成对应测试；
不允许擅自增加复杂状态管理库；
输出顺序为 schema、API、页面组件、测试、运行说明。
两者的差别不在于“更长”，而在于后者把项目边界从模糊意图变成了可执行规格。
## 六、真正拉开差距的，是测试先行而不是代码先行
这是 VibeCoding 最容易被忽略，但又最值得坚持的一点。
因为 AI 写代码很快，所以人会天然倾向于把“先生成再说”当作默认路径。
但长期看，更稳的方法其实是：先写测试用例，再让 AI 生成实现。
原因很简单。
如果没有测试锚点，AI 每一轮修改都有可能把旧功能悄悄带坏；而有了测试锚点之后，系统每次变化都至少能被基本验证。
对一个普通项目来说，测试通常至少应分成三层：
### 1. 功能测试
例如新增、删除、编辑、状态切换、筛选是否正确。
### 2. 边界测试
例如空值、超长输入、非法格式、重复提交、异常返回。
### 3. 体验测试
例如空状态展示、按钮反馈、二次确认、错误提示是否清晰。
如果是 AI 应用，还需要再加一层评测：
提示词输出是否符合 schema
检索结果是否相关
工具调用是否稳定
典型场景下的回答是否准确
从工程角度看，VibeCoding 最大的收益并不是“少写代码”，而是能用 AI 很快地补齐测试与回归资产。
如果这一点不用起来，其实等于只用到了 AI 最表层的能力。
## 七、日志和可观测性，应该从第一版就开始加
AI 生成代码时有一个很常见的问题：
它会优先把“功能主干”写出来，但对日志、监控、追踪、异常信息这些“上线后才会救命”的部分，经常处理得不够认真。
而现实项目里，最难排查的问题恰恰不是“页面打不开”这种显性错误，而是：
某个接口偶发失败
某条数据写入异常
某个筛选逻辑在特定条件下失效
某个 AI 输出在特定输入下格式错乱
某次调用慢得异常，但无法复现
这类问题如果没有日志，基本只能靠猜。
所以现在做项目时，我会把“日志要求”写进 prompt，而不是上线前临时补。
至少在这些位置必须有日志：
页面初始化
API 入口
数据写入前后
校验失败分支
异常捕获分支
外部调用分支
AI 生成或工具调用节点
日志不用写得像审计系统那么重，但一定要足够描述上下文，否则 debug 时只会看到一句“操作失败”。
## 八、AI review 很有用，但它代替不了工程 review
这一点很值得单独说。
AI 做 review 的能力已经相当实用，尤其擅长发现：
重复逻辑
未处理异常
类型风险
可读性差的实现
明显的边界漏判
测试缺口
与需求不一致的地方
它非常适合做第一轮筛查，而且速度极快。
但 AI review 的上限仍然受限于它看到的上下文和它对项目真实目标的理解程度。它可以指出“代码里有问题”，却未必能准确判断“这个设计本身就不该这样做”。
所以，在实际流程里，AI review 更适合承担的是“技术层初筛”，而人工 review 负责的是“工程层定夺”。
一个简单的分工方式是：
AI review：找 bug、找重复、找风险、找未覆盖
人工 review：看需求是否满足、实现是否过度、结构是否可维护、交互是否合理
两轮都做，质量通常比单做任意一轮都稳。
## 九、一个完整案例：从 0 开始 VibeCoding 一个 TodoList 项目
为了把上面的流程说得更具体，这里用一个非常经典、但足够完整的小项目来演示：从零开始做一个 TodoList。
之所以选这个例子，不是因为它复杂，而是因为它恰好能覆盖 VibeCoding 中最关键的几个步骤：需求收敛、原型确认、分阶段生成、测试先行、日志补齐和迭代交付。
### 第一步：先把需求写成“项目边界”，而不是一句愿望
最初的目标很简单：做一个单用户可用的待办事项管理工具。
但如果只写成“做一个 TodoList”，AI 会默认补出很多并不一定需要的内容。所以更实际的做法，是把需求先写成项目边界。
项目目标
用户可以创建待办事项
可以编辑、删除、标记完成
可以按状态筛选
可以设置优先级和截止日期
数据刷新后不丢失
非目标
不做登录注册
不做多人协作
不做消息推送
不做复杂权限
不做 AI 自动规划
技术约束
前端：Next.js + TypeScript + Tailwind
数据层：Prisma + SQLite
测试：Vitest + Playwright
部署：支持 Docker 本地运行
验收标准
核心增删改查完整可用
刷新页面后数据仍保留
筛选逻辑正确
错误输入有明确提示
测试可以本地通过
项目一条命令可以启动
到这一步为止，项目才算真正进入“可开发状态”。
### 第二步：先让 AI 做拆解和原型，而不是直接写代码
接着，不让 AI 一口气生成整个系统，而是先让它输出这几项内容：
页面结构
组件拆分
数据模型
API 设计
目录结构
低保真原型说明
这样做的好处非常明显。
如果原型阶段就发现“优先级字段不该做成五档”“截止日期不需要精确到时间”“删除应该有二次确认”“列表页需要空状态提示”，这些问题可以在几分钟内调整，而不是等代码成型后推翻。
在这个项目里，原型确认后最终收敛出的页面结构大致是：
顶部输入区：标题、优先级、截止日期、添加按钮
中部列表区：展示任务、支持编辑/删除/完成
筛选区：全部 / 未完成 / 已完成
空状态区：无任务时展示提示信息
这个阶段的目标不是“做得像成品”，而是“确保理解一致”。
### 第三步：编写 Prompt 契约，按模块逐步生成
到这里，才开始真正进入编码。
我通常不会让 AI 一次性输出整个项目，而是要求它分四轮生成：
数据 schema
API 路由与服务层
页面组件与交互
测试与运行说明
对应的 prompt 也会写得很明确，或者把prompt直接写成一个文件喂给AI，例如：
请先实现 TodoList 项目的 Prisma schema 和基础 API，要求仅支持新增、查询、更新、删除、完成状态切换。
使用 TypeScript。
必须补充输入校验。
关键动作加日志。
不要擅自添加认证系统。
输出完成后附上运行命令和文件结构说明。
这种分段式生成有两个优势：
每一段都能独立 review 和修正
问题被局部化，不会牵一发动全身
这也是 VibeCoding 和“让 AI 直接生成一个大项目”的本质差异之一。
### 第四步：先写测试清单，再进入实现验证
TodoList 虽然小，但测试仍然不能省。
在这个项目里，最先写出来的不是页面，而是一份测试清单。
功能测试
新增任务成功
编辑任务成功
删除任务成功
标记完成成功
状态筛选正确
优先级显示正确
边界测试
任务标题为空时不能保存
超长标题时有提示
非法日期被拒绝
已删除任务不会再次出现在列表中
体验测试
删除前需要确认
空列表有引导提示
操作成功后有即时反馈
测试清单的作用不是为了形式完整，而是为了让后面的每一次代码生成都有落点。
没有这份清单，所谓“做完”往往只是“看起来差不多”。
### 第五步：强制补日志，别等 bug 出现了再加
这个项目虽然不大，但在生成代码时仍然要求 AI 补齐关键日志，例如：
createTodo start
createTodo validation_failed
createTodo success
updateTodo start
deleteTodo success
listTodos fetch_failed
这些日志平时看起来像是“多写了几行”，但在后面调试 API 和页面状态不一致的问题时，会立刻体现价值。
尤其是 AI 生成代码之后，经常会出现“功能能跑，但某个分支判断不稳定”的情况，没有日志很难看出问题到底出在前端、接口还是数据层。
### 第六步：AI review 一遍，人工 review 一遍
代码生成完成后，先让 AI 站在审查者视角重新看一遍：
是否存在重复逻辑
是否有未处理异常
是否有不必要的状态复杂度
是否存在类型不一致
是否有测试遗漏
这一轮通常能发现不少显性问题，比如：
表单校验前后逻辑不一致
删除接口没有处理资源不存在的情况
组件里重复维护同一份状态
更新后列表刷新逻辑缺失
接着再做人工 review，重点看的是：
交互是否符合最初预期
代码是否过度设计
代码内是否有潜在的问题
模块结构是否适合后续扩展
是否真的满足非目标约束
例如，在这个 TodoList 项目里，就很容易遇到一个典型问题：
AI 为了“更完整”，会倾向于引入额外的状态管理或抽象层。但对一个 MVP 来说，这种完整并不一定带来收益，反而会抬高维护成本。这个判断就必须由人来做。
### 第七步：部署测试环境，跑回归，再做人工体验测试
代码通过本地验证后，接下来进入测试环境部署。
这一步会重点验证几件事：
环境变量是否配置正确
Prisma 初始化是否正常
API 与前端交互是否一致
页面刷新后数据是否持久化
Docker 启动是否稳定
自动化测试跑完之后，还会再走一次人工体验测试。
例如用真实使用路径去检查：
连续新增 10 条任务后列表是否仍然正常
完成和未完成切换是否有延迟或错位
编辑过程中刷新页面会不会丢状态
删除后的提示是否足够清楚
移动端显示是否可接受
这一步往往能发现很多“自动测试没报错，但用户会觉得别扭”的问题。
### 第八步：补文档后再交付，而不是把代码仓库直接甩出去
一个小项目做到最后，最容易被省略的就是交付资料。
但真正意义上的“交付”，并不只是把代码 push 到仓库。
至少要补这些内容：
README
项目启动方式
环境变量说明
数据库初始化方法
测试命令
已知限制
下一步可扩展建议
这不是形式主义，而是为了让项目在离开当前上下文之后，仍然有人能接得住。
## 十、从这个案例里，能看到 VibeCoding 最核心的价值
TodoList 这个例子并不复杂，但它已经足够说明一个事实：
VibeCoding 真正缩短的，不只是写代码的时间，而是从模糊想法到可交付结果之间的距离。
它的价值主要体现在三个方面。
### 1. 更快地收敛问题
借助 AI 去拆需求、做原型、列测试、查缺补漏，很多原本要靠口头沟通和多轮试错解决的问题，可以更快落到具体对象上。
### 2. 更快地形成初稿
不管是代码、测试、文档、review 清单还是部署说明，AI 都能显著减少“从零起草”的成本。
这一点在小步快跑、频繁验证的开发模式里尤其明显。
### 3. 更容易把工程流程补完整
很多个人项目和小团队项目最缺的，其实不是代码能力，而是流程资产：测试、日志、文档、校验、review。
这些事情过去常常因为“太花时间”而被省略，而 AI 的出现，让它们第一次具备了低成本补齐的可能性。
## 十一、关于 VibeCoding，我现在最在意的不是“快”，而是“稳”
如果只把 VibeCoding 当成提速手段，那么最终最容易追求的是“更快出结果”。
但做久了会发现，真正决定体验的不是快，而是稳。
所谓稳，至少包括这些含义：
需求稳：不被 AI 带跑偏
结构稳：不是一次生成一团糟
质量稳：每次修改都有回归依据
排错稳：出了问题能快速定位
交付稳：项目离开作者也能继续维护
所以现在回头看，VibeCoding 最应该摆脱的，其实是它名字里那个容易让人误会的“vibe”。
它当然可以保留灵感驱动、快速试错、低门槛起步这些优点，但一旦进入真实开发，就必须补上另一面：边界、验证、评测、review 和工程 discipline。
只有这样，AI 才是在帮开发者放大效率，而不是放大混乱。
