一位VibeCoding开发者的浅薄经验自述

今天跟大家分享一下我这一年多来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 一次性输出整个项目而是要求它分四轮生成数据 schemaAPI 路由与服务层页面组件与交互测试与运行说明对应的 prompt 也会写得很明确或者把prompt直接写成一个文件喂给AI例如请先实现 TodoList 项目的 Prisma schema 和基础 API要求仅支持新增、查询、更新、删除、完成状态切换。使用 TypeScript。必须补充输入校验。关键动作加日志。不要擅自添加认证系统。输出完成后附上运行命令和文件结构说明。这种分段式生成有两个优势每一段都能独立 review 和修正问题被局部化不会牵一发动全身这也是 VibeCoding 和“让 AI 直接生成一个大项目”的本质差异之一。### 第四步先写测试清单再进入实现验证TodoList 虽然小但测试仍然不能省。在这个项目里最先写出来的不是页面而是一份测试清单。功能测试新增任务成功编辑任务成功删除任务成功标记完成成功状态筛选正确优先级显示正确边界测试任务标题为空时不能保存超长标题时有提示非法日期被拒绝已删除任务不会再次出现在列表中体验测试删除前需要确认空列表有引导提示操作成功后有即时反馈测试清单的作用不是为了形式完整而是为了让后面的每一次代码生成都有落点。没有这份清单所谓“做完”往往只是“看起来差不多”。### 第五步强制补日志别等 bug 出现了再加这个项目虽然不大但在生成代码时仍然要求 AI 补齐关键日志例如createTodo startcreateTodo validation_failedcreateTodo successupdateTodo startdeleteTodo successlistTodos 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 才是在帮开发者放大效率而不是放大混乱。