★ FEATURED ARTICLE 今天把项目推上线的那一刻我确实挺开心的。这个项目从需求、原型到前后端代码绝大部分是靠VibeCoding的方式完成的——我用自然语言描述意图AI负责生成代码我来做架构、拆解和验收。这是我从“用AI搞点小脚本”真正转到“用AI交付一个能用的产品”的分水岭对我来说算是迈上了一个全新的台阶。如果你也在玩VibeCoding但总觉得做出来的东西像玩具、只敢自己跑着玩那这篇复盘应该能给你一些参考。我会把这个项目里所有关键环节——任务拆解、上下文管理、验收闭环、工具链配置、踩坑记录——完整摊开讲一遍。不是讲概念是讲我实际怎么操作的。1. 这一次真正的台阶在哪里1.1 什么才算VibeCoding“迈上台阶”很多人把VibeCoding理解成“用嘴写代码”描述一个需求AI生成一堆代码然后跑通就完了。说实话我之前的阶段就是这样。做个小爬虫、写个自动化脚本、生成一段正则表达式每次都能成功但从来不敢碰真正的产品级项目。因为只要需求一复杂AI就开始“翻车”改了一个地方另一个地方崩了加了一个功能老功能挂了甚至出现AI一本正经地编造了一个根本不存在的API。所以我认为VibeCoding真正“迈上台阶”的标志不是AI一次能生成多少代码而是你作为人类能不能把一个复杂项目稳定地、可预测地交付出来。今天这个项目我从头到尾没有写过超过十行连续的手写代码但每一步都有清晰的方向、明确的验收标准AI生成的每一块代码我都review过并且真实运行验证过。这种“AI干活、人管方向”的状态才是VibeCoding质变的地方。1.2 之前为什么一直卡在demo阶段说实话回看之前卡住的根源不是AI能力不够而是我的工作方式不对。我过去的习惯是打开对话窗口把整个项目需求一次性扔给AI让它直接生成一个完整应用。结果是什么生成的代码看起来五脏俱全但实际一跑全是坑。更麻烦的是代码量一大AI自己都搞不清自己在写什么后面对话里问它上一个文件里的逻辑它开始胡说八道。后来我意识到问题在于我把AI当成了一个“全知全能的外包团队”而实际上它更像一个“记忆力有限、执行力超强、但经常过度自信的实习生”。让它一个人干整个项目的所有事就像让一个实习生独立负责从需求到上线的所有环节不出问题才怪。Demo能跑起来是幸存者偏差真正的项目必须有流程、有分工、有验收。1.3 这次做了什么一个真实可用的全栈小项目这次我选择的项目是一个“家庭记账与预算管理”的小工具目标用户就是我家里人。需求很明确多成员账户、按分类记账、月度预算提醒、简单的统计图表。为什么选它因为它的复杂度刚好合适——不是简单到几句话就能写完但也没有复杂到需要专业团队协作。它能覆盖数据建模、后端API、前端交互、权限控制、统计聚合、部署上线这一整套链路是检验VibeCoding能力的好尺子。最后的结果是一个基于Next.js SQLite的单体应用带登录、记账、分类管理、预算进度、月度统计部署在自己的服务器上家人实测使用了两周没有出现致命bug。这个项目按之前写脚本的路子根本做不出来但用VibeCoding的方式我一天半就完成了从零到上线的过程。2. 质变的三块基石拆解、上下文、验收2.1 需求拆解把“做成一个产品”变成AI能接住的任务最容易让AI翻车的不是“帮我写个按钮”而是“帮我做一个记账软件”。因为后者包含太多隐含决策数据存哪里、字段叫什么、页面有哪些、登录怎么做、统计怎么算……AI只能猜猜错了就是坑。所以我的第一步是用自然语言把需求拆成一个个“足够小、足够明确、可单独验证”的任务。我当时的拆法是这样的数据模型先确定用户、账单、分类、预算四张表字段写清楚比如账单必须包含金额、类型、分类ID、记账人ID、备注、时间。基础能力用户注册、登录、会话保持账目增删改查分类增删改查。核心逻辑月度统计收入、支出、结余预算设置与进度计算预算超支提醒。页面交互记账页、账单列表页、统计页、设置页。收尾工程错误处理、空状态、部署。每个任务我都写清楚“输入是什么、输出是什么、成功标准是什么”然后交给AI一句一句地完成。事实证明一个明确的任务AI完成得又快又准一个模糊的需求AI就给你千奇百怪的自由发挥。拆解的过程看起来很笨但它是VibeCoding能不能上台阶的第一道分水岭。2.2 上下文资产我给AI准备的“工作台”这是这次最大的心得。以前我每个对话都是“裸聊”——AI对项目一无所知每次都要重新描述背景。后来我把项目的所有固定信息整理成一份上下文文档每次开启新会话先让它“读”一遍再开始干活。这个上下文文档我放在项目根目录的docs/context.md里内容包括项目一句话介绍和技术栈目录结构和每个目录的职责数据模型说明和关键字段定义代码风格约定比如组件用函数式、所有金额用分存储、禁止用any已经完成的功能清单和正在做的任务已知问题和解决过的坑你可能会觉得这很麻烦但实际操作下来非常值。因为你只要写一次之后每个对话、每一次让AI改代码它都能基于这份“工作台”来思考而不是凭空瞎猜。我试过不给上下文直接问AI“帮我在统计页面加一个环比”它生成的代码用了完全不同的字段名和数据结构改了三轮才跑通。给了上下文之后一次改到位。2.3 验收闭环让AI写代码我来做测试员VibeCoding最大的风险是什么不是AI写不出代码而是AI写出一堆“看起来正确”的代码。它会自信地说“这个函数没问题”但实际上没有考虑空指针它会把一个旧的删除逻辑保留下来导致新增的数据被莫名清空它甚至会因为上下文太长把上上轮已经修好的bug又改回来。所以我建立了一个不容妥协的验收闭环AI生成的每一段代码都必须经过“真实运行验证”而不是代码审查通过就算完。我的做法是三步走先跑起来看功能是否符合预期再写边界情况测试比如空账本、重复提交、非法金额最后人工看一遍diff确认没有动到不该动的地方。这三步听起来耗时但比起上线后让家里人来骂这点时间完全可以接受。3. 实操全记录从0到1的完整链路3.1 技术栈选型与初始化技术栈选型上我没有纠结太多。VibeCoding的场景下AI对主流技术栈的熟悉程度是最高的冷门框架容易让它“一本正经地胡说八道”。我选了Next.js的App Router模式、SQLite加一个ORM、Tailwind做样式部署在一个小云服务器上。这套组合的优点是数据是单文件方便我随时备份和迁移框架自带API路由和页面渲染不需要额外搭前后端项目AI对它非常熟生成代码的质量明显更高。初始化阶段我只手动做了两件事创建项目目录、安装基础依赖。其他全部交给AI。比如让它先跑一遍开发服务器确认首页能访问让它配置好SQLite连接建好数据表。这个阶段主要目的是把底子弄干净避免后面因为环境问题排查半天。这里插一句重要心得VibeCoding的每一步都要能“看得到结果”如果运行出现报错先别急着让AI继续改而是把报错信息原样喂回去通常AI能自己定位到问题。3.2 典型实现过程数据模型、后端接口、前端页面以数据模型为例我给AI的提示词是这样的我需要为记账应用设计SQLite数据库。要求如下 1. 四张表users, bills, categories, budgets。 2. users表字段id, username, password_hash, created_atusername必须唯一。 3. bills表字段id, user_id, category_id, amount_cents存储分为单位的整数, typeincome/expense, note, created_at。 4. categories表字段id, user_id, name, icon。 5. budgets表字段id, user_id, category_id, month格式YYYY-MM, limit_cents。 6. 金额一律以分为单位存储禁止使用浮点数。 请先生成建表SQL再生成对应的ORM模型定义。AI返回的SQL基本正确ORM模型也符合我的要求。重点是它理解了两个关键约束金额用分存储、用户和分类之间做关联。这个小细节在后续统计的时候避免了很多精度问题。后端接口也是一样的套路我描述清楚“从哪个表取数据、按什么条件过滤、返回什么结构”它就生成对应的API。前端页面更是纯自然语言驱动的比如“做一个记账表单包含金额输入、分类下拉框、类型切换、备注文本框提交后跳转回账单列表页”。3.3 联调与部署最后一步怎么打通联调阶段是最能体现VibeCoding威力的地方也是最需要耐心的地方。界面、接口、数据库三端不是一次就能对齐的经常出现前端发了A格式的请求后端期待的是B格式。我的办法是让AI先输出一份API文档然后所有前端请求都对照这份文档来生成避免双方各自猜。部署时我遇到了一个典型的VibeCoding陷阱。AI生成的生产环境配置里用了设置环境变量的方式指定数据库路径但我在服务器上漏配了导致应用启动后连接的数据库文件路径不对所有数据都写到了找不到的地方。排查这个问题的过程让我养成了一个新习惯凡是AI生成的“部署配置”都必须亲自检查一遍路径和权限不能只盯着业务代码。4. 工具链与工作流VibeCoding的效率来源4.1 我的工具组合与配置这次的效率提升很大程度来自工具链的组合而不是某个单一AI工具。我的实际搭配是编辑器用Cursor日常对话和代码生成走Claude的长上下文模型终端里的命令行操作用一个支持Agent模式的工具来做。这三者各管一段编辑器负责文件内联生成和修改对话窗口负责复杂逻辑设计和多文件改动方案终端Agent负责跑命令、看日志、做简单修整。为什么要分成三个工具因为VibeCoding的本质是“人和AI协作”不同任务的协作粒度不一样。小改动在编辑器里直接完成最顺手大设计要开一个对话窗口把完整上下文丢进去让AI给你方案而不是直接动手机械性操作——比如跑测试、看报错、批量重命名——让终端Agent处理最省心。我用这种方式之后返工率明显下降因为每个工具都在干自己最擅长的事情。VibeCoding对长上下文模型的要求很高。因为我时常需要把整个项目的关键文件内容一起贴进去让AI理解全貌之后再做决策。如果模型上下文窗口太小它就会“顾头不顾尾”改了一个文件忘掉另一个文件。所以我会在项目的docs目录下保留几个固定文档随时更新用来对抗“AI越聊越健忘”的问题。4.2 Prompt写得越具体返工越少很多人以为VibeCoding就是随口说“帮我写一个登录页面”但真正好用的Prompt其实和给外包团队写的需求说明差不多要包含背景、约束、结构、验证方式。我总结了一个比较实用的公式四要素齐全出错的概率至少降一半角色定位告诉AI它要扮演谁比如“你是一个熟悉Next.js和SQLite的全栈工程师”。任务描述一件事说清楚不要同时让它做十个事。约束条件包括技术栈、代码风格、禁止事项。验收标准怎么判断任务完成比如“运行npm run build无报错账单新增后可以立刻出现在列表中”。举一个实际例子。我让它做分类管理的删除功能时约束里明确写了“删除分类时如果该分类下有账单则禁止删除并返回提示”。结果AI不仅实现了这个约束还额外把前端提示信息做成了友好样式一次通过没有返工。反过来如果我不写这个约束它大概率会直接外键报错或者静默失败。4.3 git与检查点VibeCoding的安全网VibeCoding还有一个容易忽略的工程性问题AI可能会改坏你原本正常的东西。所以我把git用到了极致——每完成一个功能点就提交一次每次AI动大批代码之前先手动创建一个分支或者打个标签。这样做的好处是如果AI改出了问题我可以快速回滚到上一个可用的检查点而不是对着满屏幕报错干瞪眼。实际操作中我会在让AI动大工程之前把当前工作目录存成一个git提交并自己看一眼diff摘要。很多次AI改完加了一个新页面但顺手把样式表里的某个公共类名改了导致其他页面全部错乱。这时候如果没有检查点排查成本会高得吓人有检查点直接reset回去再让AI重做就行。这个习惯我强烈建议所有VibeCoding玩家都尽早养成。5. 我踩过的坑与排查方法5.1 常见问题速查表做这个项目的过程中我整理了一批高频问题基本都是VibeCoding特有的“病症”AI无故修改无关文件通常是因为上下文太长AI判断失误以为自己需要调整。对策是明确指定“只改哪些文件”并在评审diff时重点关注。反复修复同一个bugAI经常给出一个“看起来修好但实际没有修好”的方案因为你没有把根因告诉它。对策是把报错日志和复现步骤原样贴给它并要求它先解释原因再动手。接口路径对不上前后端分别生成后容易各自为政。对策是先让AI一次性输出一份API文档再照着文档分别生成前后端代码。生成代码里出现假方法AI会编造一个不存在的库里函数。对策是运行时报错后让它参考实际安装的版本文档有时候甚至需要你手动去查一下这个函数的真实签名。数据库迁移混乱AI做的增量改动容易和已有表结构冲突。对策是让它直接把最新版建表SQL生成出来不要用一堆零散的ALTER语句。每一项我都实际踩过尤其是第一条和第三条几乎占了我整个项目调试时间的三分之一。5.2 如何分辨AI的“自信错误”AI给出的代码里最危险的不是明显的崩坏而是看起来完全正常、但逻辑有微妙错误的“自信错误”。比如我在预算提醒功能上AI一开始判断“超支”用的是剩余金额小于0但需求是“支出进度超过预算的80%就开始提醒”。这个差异不仔细看根本发现不了因为代码能跑通页面也正常就是提醒的时机不对。我的解决办法是引入“代码走读”这个习惯。也不是说逐行精读而是把AI写的核心逻辑在脑子里过一遍问自己“如果换成是我来写是不是这个意思”看到不认识的方法名就去查看到冗余的变量就去问为什么看到异常处理的缺失就补上。这种走读不需要耗费太多时间但能过滤掉大部分逻辑层面的问题。5.3 性能与安全的底线把控最后一个必须亲力亲为的方面是性能和安全的底线。AI在生成业务代码时注意力往往在“功能实现”上不太关心查询效率和数据安全。我遇到过两个典型问题账单列表页一次查出该用户全年的所有账单然后在前端做分页数据量一大页面就卡死注册接口没有限制用户名长度甚至没有做密码强度检查。因为VibeCoding的另一面是“默认信任AI的产出”所以这些底线问题尤其要靠人来兜底。我的做法是在上下文的文档里加了一节“必须遵守的约束”明确写上所有列表查询必须分页、必须使用参数化查询避免SQL注入、用户密码必须哈希存储、所有金额字段必须在后端做范围校验。有了这些约束AI生成的质量会明显上一个档次因为它在动手之前就知道你的底线在哪里。我个人做完这个项目最大的体会是VibeCoding真正难的不是写代码而是把所有“只有人才知道的事情”整理清楚——需求边界、技术约束、验收标准、优先级。这些东西越清晰AI发挥的空间越大。你可以把AI想象成一个记忆力很好但缺乏常识判断的协作对象你要做的是给它一个足够规范的“工作环境”而不是期待它自动变成一个靠谱的全栈工程师。对我而言今天这个台阶不是AI单方面带来的是我改变工作方式之后AI才真正成了能交付产品的队友。
阅读完成 · 觉得有帮助？
