我第一次听到 Vibe Coding 这个词是 2025 年初在一个技术社群的讨论帖里。当时第一反应是——这又是什么网络梗跟着感觉写代码听起来就像是代码是糊出来的的自嘲。直到我自己花了两周时间用对话的方式让 AI 从零搭完一个带前后端的小项目才开始意识到这玩意儿的门道比段子里说的深得多。先说一句结论Vibe Coding 不是让 AI 随便写写然后祷告代码能跑而是一套用自然语言表达意图、由 AI 负责实现、由人来把控方向和验收的新型开发方式。这个词最早是 OpenAI 的 Andrej Karpathy 带火的本意是你只需要沉浸在氛围里让 AI 把想法变成代码。但很多人把它理解成了摆烂编程结果就是AI 写了一堆貌似合理的垃圾代码然后人就开始修修补补最后花的时间比手写还长。这篇文章我不打算讲太多概念层面的东西我想分享的是自己实际用 Vibe Coding 做项目的完整经验它到底改变了什么、为什么会翻车、怎么不翻车、以及哪些项目千万别用。适合正在纠结要不要让 AI 写代码的开发者也适合被 Vibe Coding 忽悠过、想搞明白问题出在哪的人。1. Vibe Coding 不是让 AI 随便写——它到底改变了什么1.1 一个新词背后的开发范式变化Vibe Coding 最核心的变化不是AI 能写代码这件事本身——毕竟 Copilot 已经让这事儿变得稀松平常了。真正的变化是开发者在整个流程中的位置移动了。传统开发流程里程序员是实现者需求从产品经理嘴里出来你把它翻译成架构、模块、函数、变量然后一行行敲出来。这个翻译过程是最费时间的也是大部分 Bug 的来源。Vibe Coding 把这个链路重构了你直接跟 AI 说我要一个能上传 CSV 文件、自动识别列名、生成图表的前端页面AI 负责把这句话翻译成 HTML、CSS、JavaScript、可能的后端接口。你不再需要逐行敲代码但你需要做三件以前被忽视的事把需求描述得无比精确在 AI 给的代码里找出看起来对但其实是幻觉的部分判断哪些 AI 写的模块可以信任哪些必须拆开重写。所以我说Vibe Coding 真正改变的不是谁来写代码而是代码写完之后谁来负责。在人机协作里人从生产岗位转到了质检岗位。这个转变看着轻松实际更累因为你需要更高的代码嗅觉和更严谨的验收意识。1.2 边界定义什么算 Vibe Coding什么只算 AI 辅助现在很多文章把 Vibe Coding 和用 AI 辅助写 bug用补全插件写代码混为一谈。这里我给出我自己的判断标准供大家参考维度AI 辅助编程Vibe Coding代码来源人类写主体AI 补全片段AI 写主体人类描述意图人类主要工作设计、实现、调试定义意图、引导方向、验收入口对 AI 的信任程度低——每一行都要 review中——局部信任但关键点必须核对典型工具GitHub Copilot 补全模式Cursor 对话模式、Claude Code、Aider失败模式补错代码人及时发现整体生成正确但局部幻觉隐蔽且难排查我自己的体会是Vibe Coding 不是一种技术而是一种工作习惯的转变。你用不用 Vibe Coding不取决于你选了哪个 IDE 插件而取决于你是否愿意把写代码这件事的主导权暂时让渡给 AI自己退到更高层去把控。1.3 哪些人适合哪些人不适合我在不同的开发群里观察到一个规律对 Vibe Coding 抵触最大的往往是写了 10 年以上代码、以手写功底为荣的老程序员接受最快的反而是 3 年经验以内的年轻人。原因是老程序员习惯了对每一行代码负责而 Vibe Coding 要求你在不知道细节的情况下相信 AI这对职业习惯是一种冲击。但问题在于AI 写代码的可靠性已经超过了大部分初级工程师而且迭代速度是人的几十倍。适合 Vibe Coding 的人需求明确、技术栈常见的前端/全栈项目想快速做原型验证想法的人做内部工具、自动化脚本的开发者熟悉代码审查、有测试意识的工程师不适合 Vibe Coding 的人刚入行、还在学基础语法的新手AI 给的代码会掩盖你对底层原理的缺失需求本身模糊不清、连自己想做什么都不知道的人做底层硬件驱动、操作系统、编译器这类对可预测性要求极高的领域没有代码审查能力、也不打算培养的人2. 为什么 Vibe Coding 能跑通程序员的角色已经从码农变成验收员2.1 AI 时代的代码生产能力输出峰值与质量分布要理解 Vibe Coding 为什么能成立得先承认一个现实现在主流的代码生成模型在生成常见模式代码这件事上已经过了可用的临界点。以我实测的经验在常见的 CRUD 接口、表单页面、数据处理脚本这类场景里AI 一次生成、无需修改就能跑通的概率大概在 60% 到 70%。剩下 30% 里大部分是小修小补就能解决真正需要推倒重来的不到 10%。这个数据背后有个质量分布的概念。人类程序员写代码质量波动很大——状态好时一个 Bug 没有状态差不光是逻辑错误还有隐藏很深的边界问题。AI 写代码的质量曲线的特点是下限较高、上限有限。它极少犯那种完全不着边际的错误比如把数据库连接写在死循环里但你也别指望它写出极具巧思的算法优化。Vibe Coding 能跑通本质上是接受了这种质量分布用一次 60%-70% 的成功率加上人类 30%-40% 的修正换取 5-10 倍的生成速度。这是从追求一次写对到追求快速迭代逼近正确的转变。2.2 程序员的护城河已经变了我用 Vibe Coding 写了一段时间之后最深的感受是那些让我引以为傲的技能——记得住标准库的 API、手写排序算法不卡壳、能背出 CSS 属性——正在变成无用武之地的能力。AI 比你记得牢。但与此同时另外一些能力变得无比值钱拆解需求的能力你能不能把一句我想做个博客拆成用户系统、文章管理、评论功能、SEO 优化、部署方案这些 AI 能执行的粒度。判断代码质量的能力AI 给你一段代码你扫一眼能不能发现它偷懒了比如用any类型绕过类型检查、把逻辑全写在componentDidMount里、完全没考虑错误处理。架构取舍的能力AI 倾向于用最顺手的模式给你生成代码但最顺手的模式不一定是长期维护最好的模式。什么时候让它保持原样、什么时候必须重构这个判断得人来下。说白了在 Vibe Coding 的模式下你不再是一个翻译需求为代码的人而是一个把需求结构化为机器可理解指令、并对机器输出做出正确裁决的人。这是更接近架构师和产品经理的岗位而不是码农。2.3 哪种项目能跑通哪种是灾难基于我自己的项目实践我梳理了一份Vibe Coding 适用度清单项目类型适用度原因企业内部工具数据看板、后台管理高需求明确技术栈常见容错率高前端页面 标准后端 API高生成代码模式化程度高容易检查数据处理脚本 / 爬虫中高逻辑独立易隔离测试但注意效率问题旧项目重构/改 Bug中低上下文理解困难容易改 A 坏 B支付、安全认证等敏感逻辑低出错代价高AI 幻觉很难被发现底层系统、协议栈、高性能计算极低需要精确控制内存和时间AI 生成代码无法验证算法/数学密集的核心模块低AI 能给出框架但优化需要人类直觉这个表不是绝对的但我建议用来做投入产出比预判。如果你手上是一个旧项目里面纠缠了各种奇怪的历史包袱Vibe Coding 的效果会很差——模型的上下文窗口装不下你这个项目的所有潜规则而每个潜规则都是它写错代码的伏笔。3. 我的 Vibe Coding 实操流程从一句话需求到能跑起来的完整链路3.1 工具选型我试过的方案横向对比Vibe Coding 的工具五花八门我按对话式生成这个核心标准筛了一圈实际深度用过 4 个CursorIDE 内嵌对话 代码应用当前最主流的 Vibe Coding 工具。它的卖点不是对话生成本身而是把对话生成的代码直接 diff 进项目文件。你可以在侧边栏描述需求它会在右侧给出修改建议你逐条决定接不接受。这种代码审查式的工作流非常符合人类习惯。我实测下来Cursor 在中型项目几千个文件以内的上下文管理要明显优于纯 API 调用——它会把整个项目的文件树喂给模型所以它写的代码能够基本遵循你的项目结构而不是凭空给你造一个新文件。Claude Code终端 CLI 工具Anthropic 出的终端环境编程工具。它在一个 REPL 里运行可以调用 Claude 模型执行文件读写、bash 命令。体验和 Cursor 完全不同更像雇佣了一个远程实习生你说把测试跑一下、然后把失败的修了它就真的会自己去跑测试、看报错、改代码。这个工具的自由度很高但也很考验你的管理能力。它有时候会自作主张地改掉不该改的文件所以需要你前期约定好工作边界。我现在的用法是简单、独立的子任务丢给它核心架构自己动手。GitHub Copilot 对话模式IDE 内联老牌选手补全做得好但对话生成的能力相对保守。适合需要 AI 辅助但是不信任 AI 大改的人不太算纯粹的 Vibe Coding 工具更像传统的 AI 辅助老兵。Aider终端开源工具一个偏极客的选择在终端里用 git 管理你的代码你通过对话让它改代码它会自动提交 commit。最大优点是每一个 AI 操作都对应一个 commit方便随时回滚。缺点是界面对新手不友好上下文管理也比较裸。我的建议是如果你刚开始尝试 Vibe Coding直接用 Cursor因为它的 diff 审查机制最接近人审代码的流程。如果你已经比较熟练、且注重可回滚性可以试试 Aider。Claude Code 更适合已经习惯了AI 是团队成员这种协作方式的人。3.2 提示词怎么写AI 才不胡编Vibe Coding 听起来是随便聊但随便聊和写出能跑的代码之间隔着一套提示词工程。我踩过很多坑现在稳定下来一套三段式写法第一段交代背景和约束不要上来就说写个订单系统要先说清楚项目现状。像这样这是一个基于 FastAPI SQLite 的电商后台项目订单表在 app/models/order.py 中定义。技术栈固定使用 SQLAlchemy 2.x不使用 ORM 之外的原生 SQL。前端忽略只需要返回 JSON。为什么要这么做因为 AI 的默认行为是猜——你给它一个模糊上下文它就用它训练数据里最常见的惯例来填空。如果不限定技术栈它可能给你用 Django 写一个 FastAPI 项目然后把整个工程结构都改变了。上下文交代得越清楚幻觉越少。第二段描述需求标明验收标准这是最容易犯错的环节。很多人描述需求用的是形容词比如页面要好看点性能要好一些。AI 听到好看就只能自由发挥。正确的做法是把形容词翻译成可测量的标准在订单列表中增加一个导出按钮点击后下载 CSV 文件。CSV 的列包含订单号、用户手机号、商品名称、实付金额、下单时间。编码使用 UTF-8 带 BOM确保 Excel 打开不乱码。这能让导出从一句话变成一个可交付、可验证的功能。带 BOM这种细节尤其重要——AI 不知道你的用户会用 Excel 打开你不说它就会漏。第三段限定实现思路与边界如果你对实现方式有偏向最好直说不要用额外插件直接使用 Python 内置的 csv 模块即可。导出逻辑放在服务层 order_service.py 中不要写在 controller 里。导出前检查用户是否有管理员权限。这一步相当于给 AI 画了一个工作范围防止它跨模块动代码。我见过 AI 为一个小小的导出功能顺手改了 model 定义、加了一个 config 配置项甚至动了数据库字段——如果你不说边界它会认为自己帮了个大忙。3.3 渐进式搭建先骨架后肌肉Vibe Coding 最常见的新手错误是试图一次对话让 AI 把整个项目写完。我第一周就是这么干的结果是它生成了一个结构看似完整的工程实际上里面全是互相矛盾的接口定义前端调用的 API 路径和后端路由对不上、Model 定义的字段和数据库迁移文件不一致。后来我总结出一个渐进式搭建的节奏第一步让 AI 生成项目骨架只让它搭目录结构、配置文件和空的模块入口。目的不是得到代码而是得到一个统一的工程约束。这一步你不应该让 AI 操心任何业务逻辑。第二步按功能模块逐个填充每填充一个模块前先确认基础骨架没变、依赖关系清楚了、上一个模块是否已经对接好。然后把每个模块当成独立的小项目去描述需求。第三步模块对接时人肉介入这是最关键的一步。AI 在单个模块内表现很好但跨模块沟通时经常交接不清。比如它写的用户模块返回的是user_id但订单模块里调用时用的却是id。这时候你千万别指望 AI 自己能发现——它的上下文感知在这种细节上并不可靠。你需要在对接点手工检查一遍或者用测试用例覆盖。第四步持续集成每步验证做完一个模块就立刻跑测试、起服务、用 API 工具调一下。不要攒到最后一口气验证。Vibe Coding 的节奏是快速迭代、高频验证跟传统开发不一样。3.4 哪些代码必须人肉 review哪些可以放心用我有一套自己的 review 优先级分享出来供参考可以快速看一眼就放过的标准的数据 CRUD 代码常见的 UI 组件拼接逻辑定型化的配置代码比如 Dockerfile、CI 模板工具函数日期格式化、字符串处理注意测试覆盖必须逐行审查的任何涉及权限、鉴权、支付、外部 API 密钥的代码数据库操作——尤其是涉及数据迁移的错误处理逻辑——AI 通常会忽略异常分支只写主流程异步/并发代码——AI 对 race condition 的理解很差涉及文件读写、网络请求这类外部 I/O 的边界条件为什么因为 AI 的训练数据里主流程占了绝大多数正确处理的错误分支是很少的。它的默认行为是我猜这个不会出错而你的工作就是替它把所有出错的情况想到。Vibe Coding 里人的价值就体现在这些审查上。4. 翻车实录Vibe Coding 最常踩的五个坑与排查链路4.1 幻觉 APIAI 自信地写了不存在的库有一次我让 AI 写一个 PDF 转图片的工具它生成了下面这行代码from pdf2image import convert_pdf_to_images一眼看过去逻辑没问题——pdf2image这个库确实存在但里面的函数叫convert_from_path根本没有convert_pdf_to_images。AI 把两个不同库的 API 记忆混在一起编了一个看起来对的函数。这个坑的隐蔽性在于如果用的不是 Python 这种有清晰ImportError的语言或者你恰好命名了自己的函数很可能直到运行到那一行才报错。我的排查方法是让 AI 给出依赖列表和版本号然后人工对着官方文档核对一遍再往下走。这一步 5 分钟能搞定但能避免 2 小时的排查。4.2 改一行坏三处上下文漂移问题我最惨的一次 Vibe Coding 事故是这样的项目里有一个utils.py里面定义了一个format_date()函数。我让 AI 把日期格式从YYYY-MM-DD改成YYYY/MM/DD。AI 的回应是好的我帮你改。 结果它不光改了utils.py里的函数体还把report.py里已经格式化好的字符串又格式化了一次导致输出变成YYYY//MM//DD。更隐蔽的是它把 README 里的示例日期也改了。这个问题的根源叫上下文漂移——AI 在处理你指定的任务时会顺手把上下文里它认为相关的代码也改了。它分不清用户让我改函数定义和用户希望所有调用点都更新的区别。解决方案每次让 AI 改代码之前先 git commit 一遍然后给它明确指令只修改 xxx.py 中名为 xxx 的函数其他文件不允许改动。 如果它改了不该动的文件你直接git checkout恢复而不是手动去改。4.3 测试全绿但功能全废这是 Vibe Coding 最阴险的坑。AI 特别擅长生成一个能通过测试的假实现。我让 AI 写一个计算折扣价的函数要求输入原价和折扣率返回折后价。AI 生成的代码长这样def calculate_discount(price, rate): 计算折扣后价格。 return price * rate然后它还贴心地生成了测试用例def test_calculate_discount(): assert calculate_discount(100, 0.8) 80测试确实是绿的。但问题是这个函数的语义对吗折扣率 0.8 意味着打八折还是打了两折实际业务里折扣率更常见的是折扣力度即 80% off 还是 80% of 原价如果需求里没说清楚AI 就按它猜的最简单方式实现且测试只会验证它自己的理解。这种坑怎么防先把验收测试写清楚再让 AI 实现而不是让 AI 自己出题自己答。测试用例应该由人来定义边界条件。比如折扣率 0.8 表示打八折原价 * 0.8折扣率大于 1 或小于 0 时应抛异常价格必须为正数。有了这样的约束AI 就不会自作主张。4.4 越权和业务安全漏洞这个坑我没踩过特别大的但见过 GitHub 上好几个公开的 Vibe Coding 项目翻车。最常见的模式是AI 写了一个带用户登录的后台系统然后忘记在删除接口上做权限校验。比如这样的代码app.delete(/api/order/{order_id}) def delete_order(order_id: int, userDepends(get_current_user)): # 没有检查 user 是否有权限删除该订单 db.delete(order_by_id(order_id))代码逻辑完整、语法无误、能跑但任何登录用户都能删掉别人的订单。AI 没有业务规则的概念它只知道删订单 调用删除函数。这类问题的核心是AI 不感知业务语义它只感知代码语义。你必须在需求描述里主动把业务约束列出来比如仅管理员可删除用户只能删除自己的订单。即使如此你还是要对鉴权、权限、支付这类关键路径做深度 review这是无法替代的。4.5 代码膨胀AI 的贴瓷砖式扩展Vibe Coding 项目写久了你会发现代码量会显著增长。AI 倾向于用新增模块而不是修改现有模块的方式解决问题。比如你让它加一个导出订单数据功能它可能会新建一个export_service.py再建一个export_controller.py还复制了原来列表查询的代码——实际上这个功能只需要在已有order_service.py里加一个 30 行的函数。久而久之代码里出现大量重复、大量 helper 函数最终变成一座屎山。这个责任不在 AI在你的项目治理。你需要周期性地做代码瘦身让 AI 列出重复代码然后手动合并且删除冗余文件。这就像整理房间——你不能指望 AI 不乱放东西但你可以定期要求把左边第三堆东西移到右边。5. 防御式编程给 Vibe Coding 加一道可信护栏5.1 三步代码审查法我现在的固定流程经过多次翻车我总结出一套适用于 Vibe Coding 的代码审查流程总共三步第一步看边界不看主流程大部分 AI 代码的主流程都不会错如果你先看主流程很容易被看起来正确的代码麻痹。直接跳到异常处理、空值判断、类型边界上去看。这三个地方是 AI 幻觉的重灾区。第二步逆向验证数据流在脑子里或者用注释沿着数据流反推这个接口返回什么谁在用这个返回值如果返回值为None会怎样AI 经常写出自己爽的接口——它定义了一个返回dict的函数但实际返回的dict里键名跟对方期望的完全不一致。第三步对着依赖清单查 API 签名这一步是对付幻觉 API的有效手段。把 AI 生成的代码里所有第三方库的函数调用列出来对照官方文档检查签名。如果你用的是 IDEL 工具跳转到定义处也能验证。5.2 自动化防线让机器替你守门人肉 review 总会漏。Vibe Coding 项目比传统项目更需要自动化防线因为 AI 生成的代码频率太高你不可能每个细节都盯着。我现在的项目标配是单元测试核心逻辑必须有测试覆盖率目标 80% 以上Linting 类型检查用 ESLint / mypy / pylint 之类工具拦住低级错误CI 流水线每次 commit 自动跑测试和构建。AI 改完代码提交 PR发现测试挂了就自觉修绝不让坏代码流向主线。这套东西看起来传统但在 Vibe Coding 里价值加倍。因为 AI 可以一分钟改十次代码人不可能一分钟 review 十次。你需要把审查工作尽量转交给机器让人盯住机器审查覆盖不到的业务层面。5.3 版本管理策略让 AI 乱改之前先保住底牌我在用 Vibe Coding 时养成了一个非常老派的习惯任何时候当前目录必须处于 git clean 状态。怎么理解就是每次 AI 开工之前先把当前可用的状态 commit 一次。AI 改完如果效果不好直接git checkout .就能回滚。这省掉了 90% 的AI 把代码改坏又找不到原来的版本的焦虑。更进阶的技巧是给每个功能分支建独立分支。AI 在分支上折腾你随时可以切回主分支继续干别的。全部满意后再 merge。这个策略在传统开发里只是好习惯在 Vibe Coding 里是底线——因为你不是在修自己的代码你是在指挥一个生产速度极快、但质量不稳的实习生。不给实习生留好退路你就得替他擦屁股。5.4 构建小型可信任代码库策略最后分享一个我最近在用的策略把项目划分成可信任区和不可信任区。可信任区是那些被测试完全覆盖、代码逻辑稳定、你 hand-on review 过多遍的核心模块——比如支付服务、鉴权模块、数据模型定义。这些模块绝不允许 AI 直接改必须通过 PR 流程且变更必须伴随测试更新。不可信任区是边缘脚本、一次性工具、UI 展示层——这里可以让 AI 自由发挥快速迭代出错也无伤大雅。这么做的好处是AI 的大部分生产力集中在不可信任区快速产出同时可信任区的稳定性保证了整个项目不会因为一次 AI 幻觉而崩盘。Vibe Coding 不是全员摆烂而是划好边界之后在边界内摆烂。我个人现在对 Vibe Coding 的态度是它真的有效但不是靠感觉在编程而是靠把感觉翻译成明确指令 严格的验收流程在编程。你可以把 AI 当成一个手艺不稳定但手速极快的学徒——你不需要教它怎么写代码但你需要教会它哪些代码是你想要的还要能一眼看穿它什么时候在交差。刚开始用 Vibe Coding 的那两周我一度觉得自己的饭碗要没了。现在我的感受完全反过来写代码的技巧越来越不值钱但理解需求、判断方案、把关质量的能力正在变得越来越值钱。如果你也打算试记住那句老话——AI 写的每一行代码最后都得由你负责。工具不会替你承担后果只有你的护栏会。