Vibe Coding 这个词，一年前我第一次看到的时候，第一反应是“这不就是偷懒写代码吗”，后来自己被朋友拖着试了两周，直接上头。到现在一年半过去，我经手了大小项目十来个，从最初只会拿 AI 写点胶水脚本，到后来敢让它独立重构模块、写测试、做性能优化，整个过程踩过的坑比我想象中多太多。
这篇不想写什么宏大叙事，就是纯粹把我这一年半的实操经验抖出来：我用什么工具、怎么搭工作流、提示词怎么组织、哪些场景容易翻车、什么项目适合什么项目不适合。不管你是刚听说这个热词的新手，还是已经用了一段时间但总觉得不对劲的老手，下面这些内容应该都能让你少走点弯路。
1. 先说说我理解的 Vibe Coding，以及这一年半我经历了什么
很多人一听到 Vibe Coding，脑子里浮现的画面就是“躺在椅子上对 AI 喊一句给我做个 App”，然后代码自己长出来。这种印象不能说全错，但它忽略了一个关键事实：任何靠谱的 Vibe Coding 项目，开发者的工作量并没有消失，只是从“用手写代码”转移到了“用嘴定方向、用眼抓偏差、用脑做决策”。
1.1 它不是什么：破除“躺着把代码写完”的幻想
我第一周用 AI 写代码的时候，确实爽。让它生成一个 Python 脚本，几秒钟就出结果，复制粘贴就能跑。但第二周我就发现，凡是“复制粘贴就能跑”的项目，基本都不需要你写，网上一搜一大堆。真正需要你动手的项目，比如一个带用户系统的 Web 服务、一个和外部 API 交互的数据处理管道、一个跨端同步的客户端工具，AI 生成的第一版永远只是骨架，甚至骨架都是歪的。
所以我对 Vibe Coding 的第一个定义是：它不是“不写代码”，而是“不手动敲每一行代码”。你把精力从打字里解放出来，去干那些 AI 不擅长的事情：拆需求、写验收标准、判断方案是否可行、识别错误方向。这个认知如果不在第一天建立，后边迟早要栽跟头。
1.2 它是什么：人机协作的编程节奏
我现在的理解是，Vibe Coding 的本质是一种高频率反馈循环。你给 AI 一个目标，它给出代码，你运行、看结果、发现问题、修正指令，然后再给它。这个循环的单位不是小时，是分钟。你不需要等 40 分钟编译一次，也不需要把整个系统的每个细节都装进脑子才开始动手，你可以通过 AI 的输出来“边做边想”。
这种节奏最大的好处是，它极大降低了“从空白文件开始”的抗拒感。以前启动一个新模块，最难的部分是那个空白的 IDE 窗口，你会对着光标发呆。现在你丢一段需求描述进去，让 AI 先生成第一版，然后你以“审查者”的身份介入。哪怕它的第一版只有 30% 能直接用，你也有了可以讨论的对象。
1.3 我从入门到熟练的三个阶段
回头看这一年半，我的水平大致分三个阶段。第一个阶段是“玩具期”，大概头两个月，我用 AI 写脚本、写一次性工具，项目都非常小，坏了也不心疼。第二个阶段是“项目期”，从第三个月开始，我尝试把它用在一个真实的中型项目上，开始接触上下文管理、提示词迭代、代码回滚这些概念。第三个阶段是“系统期”，也就是最近半年，我开始把一整套 Vibe Coding 工作流固定下来：每项任务必须有任务卡、每次生成必须过测试、每个大改动必须留回滚点。
这三个阶段对应的最大认知升级分别是：明白了 Vibe Coding 不是万能许愿机；明白了上下文比模型更重要；明白了可靠性不靠模型靠流程。
2. 工具链选型：我最终留下的组合与理由
一年半下来，市面上的 AI 编程工具我基本都用过一圈。有些换来换去，有些用完就删，最终稳定下来的是一个组合，而不是某个单一工具。这背后其实是一个很现实的原因：Vibe Coding 的体验天花板，不在单次回答的质量，而在“工具能不能接住你的工作流”。
2.1 以“代理式”为核心的模型接入方式
市面上的工具大体分两类。一类是“补全式”，比如 IDE 里的行内补全插件，你写一半它帮你续写，适合手速快、思路清楚但想省打字的人。另一类是“代理式”，也就是所谓 Agent 模式，你给它一个任务，它能自己去读文件、多轮修改、运行命令。我一年半的经验是：一旦进入真实项目，代理式的效率碾压补全式。
为什么？因为真实项目的问题从来都不只是“怎么写这个函数”，而是“这个函数应该放在哪个文件、它依赖什么函数、改了它会影响哪些测试”。这些事靠行内补全解决不了，必须让工具拥有对项目的整体感知能力。我现在的主力方案是终端里的代理式工具搭配一个支持长上下文的 IDE 插件，两者配合使用而不是互相替代。
2.2 被我用明白的两类工具
先说 IDE 插件型。这类工具适合我“边看边改”的场景：代码在那里，我通过对话让它改某个函数、补充某个注释、增加某个类型的字段。它的优势是改动范围可控，我可以清楚地看到 diff。缺点是它的主动探索能力弱，你让它“去查一下为什么测试挂了”，它通常只会盯着当前文件猜。
再说终端代理型。这类工具适合我“给它一个目标，让它自己跑”的场景：比如“把这个模块的调用方全部从 v1 接口迁移到 v2 接口”。它能自己列出所有引用位置，逐个修改，然后跑测试给我看结果。它的优势是自动化程度高，缺点是一旦任务描述得不够精确，它会在错误的方向上走很远，消耗大量时间和 token。
我最后的用法很朴素：全局性的重构和脚手架生成用代理型，局部性的修改和细节调整用 IDE 插件。两个都剩下，没有谁替代谁。
2.3 必须留的“安全网”：版本控制与我关注的检查点
无论用哪个工具，我都强烈建议把所有 AI 生成的改动都纳进版本控制，并且每次 AI 动手前先看一眼当前工作区是否干净。这一条我在前半年吃过亏：有一次 AI 自动跑了格式化工具，把整个项目的换行符全改了，我完全没察觉，等到提交时 diff 变得巨大无比，排查花了一个多小时。
所以我现在给自己立了几条规矩：AI 每次改动前，本地分支必须干净；每完成一个可运行的小目标，立即提交一次；回滚操作只回滚到最近一次我能确认“它是好的”的提交。这三条规矩听起来简单，但它们是我能放心让 AI 大胆试错的基础。
3. 可复用的工作流：从需求到上线的完整闭环
工具只是起点，真正让 Vibe Coding 从“好玩”变成“能用”的，是一套稳定的工作流。我这一年半不断迭代，现在用下来最顺手的流程分三步：开工前拆任务、生成中小步快跑、审查中靠测试兜底。
3.1 开工前 10 分钟：把需求拆成“AI 能执行”的任务卡
很多人在 Vibe Coding 里翻车，不是因为 AI 笨，而是因为给的指示本身是一团浆糊。比如你说“帮我优化一下登录模块”，AI 根本不知道你想优化什么，它只能随机挑一个方向猜，猜到你满意为止。这样既烧钱又耗时。
我的解法是花十分钟把需求拆成任务卡。一张任务卡包含：要达成的结果、输入输出的定义、涉及的关键文件、验收条件、禁止事项。例如：
任务：给订单模块增加一个“取消订单”接口。 结果：POST /api/orders/{id}/cancel，返回更新后的订单对象。 输入：订单 id，用户角色。 输出：订单状态改为 cancelled，记录 cancelled_at 时间。 关键文件：controllers/orders.py, services/order_service.py 验收：测试 cover 以下两个 case——订单存在且未发货，取消成功；订单已发货，返回 409。 禁止：不要修改支付回调逻辑。别看这短短几行，它帮我把一次对话从“碰运气”变成了“按图施工”。尤其是验收条件和禁止事项两栏，基本杜绝了 AI 跑偏的两种常见情况：一种是它觉得自己在完成任务，其实把周边代码改得面目全非；另一种是它自作主张引入你根本不想用的第三方库。
3.2 生成阶段：小步快跑与“代际锁定”
任务卡准备好之后，我会一条条丢给 AI，而不是一次性全部灌进去。这一步很关键，因为虽然现在很多模型支持很长的上下文，但你一次给太多任务，它会把注意力均匀摊开，导致每个任务都只完成一半，或者某个任务做得很精细但另一个完全被忽略。
我采用的策略是每次只给它一张任务卡，完成之后立刻运行并检查。确认没问题后，就进入下一个任务。这里有个细节叫“代际锁定”：当一个任务卡被验证通过之后，我坚决不会在同一轮对话里让 AI 去优化它。我宁可把这个优化需求放进新的任务卡，再开一轮对话。原因很简单：同一次对话里，上下文和刚才的修改纠缠在一起，AI 很容易把自己刚写好的代码改出新的 bug，旧的又回不去，非常被动。
3.3 审查阶段：手写测试作为唯一保险
很多 Vibe Coding 的教程会强调“审查 AI 生成的代码”，但我觉得“看代码”这件事天然不可靠。人的注意力有限，而 AI 生成的代码很多时候不是“逻辑错误”，而是“边界条件缺失”，这种东西肉眼几乎不可能看到。
所以我的审查策略非常直接：不追求看每一行，而是确保每个关键行为都有对应测试，然后跑测试。我写过一个小项目，让 AI 自己写了一个 Web 服务的主体代码，我没有逐行读它的路由实现，但要求它把核心逻辑的测试全部补上，并且必须跑通。那一次项目上线之后，最早暴露出来的问题全部来自那些我没有加测试的部分，而不是我加过测试的部分。对我来说，这已经足够说明问题。
4. 提示词与上下文资产：vibe coding 的核心手艺
工具确定之后，决定项目成败的几乎就是两件事：提示词怎么写、上下文怎么管。这一部分我花了很多时间琢磨，因为一个模型好不好用，很大程度上取决于你怎么指挥它。
4.1 提示词模板的三层结构
我写提示词的习惯，总结下来是一个三层结构：角色背景、动作指令、约束条件。
第一层是角色背景。不要只写“你是资深 Python 开发”，那太泛了。我会写“你是一个负责订单模块的 Python 后端工程师，你非常熟悉 FastAPI 的项目结构，了解我使用了 pydantic v2 而不是 v1”。这段话看着啰嗦，但实测好处很大：它让 AI 从最开始就在正确的项目语境里思考，避免用错了库版本或者写出和现有风格完全不一致的代码。
第二层是动作指令。这里我要么给任务卡，要么给很具体的动作词，比如“创建”“重构”“修复”“补充测试”。我尽量避免“帮我看看”“帮我处理一下”这种模糊指令，因为模糊意味着 AI 需要自己补全目标，而它补全的目标几乎永远和你想的不一样。
第三层是约束条件。我最常写的是：“只修改 src/ 目录下的文件，不允许改动测试代码”“不要引入新的依赖包”“不要用 eval 或动态生成代码”。这些约束是给 AI 划安全边界，越具体越好。
4.2 上下文资产的四种形态
所谓上下文资产，就是你把项目的关键信息整理好，让 AI 每次都能读到的东西。我用下来最有效的是四种：README 风格的项目说明、项目规范文件、任务卡仓库、以及一个持续更新的“会话履历摘要”。
项目说明和规范文件不用多解释；任务卡仓库就是我把每次任务的结果和心得记下来，供后续参考；会话履历摘要则是我最倚重的一个技巧。因为 AI 对话有上下文窗口上限，当我做一个大型模块时，做到第三天，第一天的上下文基本已经被挤出去了。我会在每天开工前，花五分钟把昨天做了什么、今天继续做什么、有哪些坑踩过，浓缩成几行话放进新对话的开头。效果立竿见影，AI 的“记忆”立刻被拉回正轨。
4.3 控制“遗忘”与“偏题”的方法
Vibe Coding 最常见的两个心智问题，一是 AI 忘记了你前面提过的需求，二是它在某个细节上越做越多，偏向了别的方向。我的应对方法有几个：一个是每条任务卡都强制要求最后给出“改动摘要和影响的文件列表”，这样我可以快速判断它有没有碰不该碰的；另一个是当它开始加戏的时候，我会明确喊停：“以上需求全部作废，请只完成任务卡里列出的第一条。”
这里还有一个很反直觉的技巧：定期更换“对 AI 的称呼和语气”。我发现同一个项目对话时间太长之后，AI 会开始变得敷衍，回答越来越短、越来越模板化。这时候我会故意换一种方式重新描述需求，比如从“修复 bug”改成“请你从用户角度描述这次问题的现象，并给出修复思路”。这种切换往往能重新激活它，让它开始真正思考而不是机械应答。
5. 一年半踩过的坑与排查实录
这部分是干货中的干货。我把自己踩过的、以及身边朋友都遇到的典型问题整理出来，每个都配有排查思路。这些问题几乎没有人会在教程里告诉你，但他们才是 Vibe Coding 真正的“使用成本”。
5.1 幻觉 API 让我翻了两次车
第一次比较惨烈。我在做一个第三方数据同步服务，AI 给我生成了一段调用某个文件处理库的代码，它引用了一个看起来非常合理的方法名。我跑测试，发现那个方法根本不存在，AI 自己编了一个。我一开始以为是我代码写错了，反复排查了半小时才发现问题出在 AI 的幻觉。
后来我学乖了，凡是 AI 生成的不常见的 API 调用，我必须先快速验证一遍：要么去查官方文档，要么在环境里跑一段最小用例。第二次遇到幻觉 API 的时候，我因为已经有了这个习惯，三分钟就定位了问题。归根结底，AI 的语言模型它学习的对象是“代码的形态”，而不是“代码的真实行为”，所以任何看起来逻辑自洽但你没验证过的调用，都必须默认它有可能是假的。
5.2 无限“修 bug”循环的止损策略
这是 Vibe Coding 最典型的翻车场景：你反馈一个问题，AI 修了，但引入另一个问题；你再修，又引发第三个问题；往复 5 轮以上，代码像滚雪球一样越来越烂。这种循环的本质原因，是 AI 在缺乏验证手段的前提下，每次都是在原有修改上打补丁，但原始设计里的根本问题一直没被发现。
我现在的止损策略是三步：第一，明确告诉它“停止修改代码，只解释你认为当前 root cause 是什么”；第二，如果它的 root cause 分析和我预期不符，我会把整个相关函数重写，而不是继续打补丁；第三，我规定同一个问题最多让它修三轮，三轮没解决就手动接管。
5.3 上下文膨胀导致的行为漂移
我有个项目前期很顺利，后来发现同一个模块，上午生成的代码风格正常，下午再让 AI 改，它居然开始用完全陌生的编码习惯。我一度以为是模型本身不稳定，后来才想明白：上下文窗口里塞的东西太多了，其中包含了很多早期的探索性对话和无效信息，AI 被这些历史信息干扰了决策。
解决方法是建立“每轮对话单线程”的习惯：一个对话只围绕一个任务，失败了就开新对话重新导入项目说明，不要在一个对话里救了东边再救西边。我后来甚至会在任务卡仓库里留下一个“当前项目快照”，每次新对话都以这份快照开头。这样一来，行为漂移的问题基本没有再出现过。
5.4 依赖与运行环境的不一致问题
AI 对依赖库版本的“感觉”是很不准确的，它经常会基于某个库的最新版本的语法生成代码，而你的环境还停留在两年前。还有一种情况是，它自己认为某些库是必须的，于是擅自往 requirements 里塞了一堆你根本不需要的包，这些包又和现有依赖冲突。
现在我维护一个固定的“技术栈清单”，放在项目的 docs 目录里，明确写清楚 Python 版本、框架版本、包管理方式、以及哪些库是禁止使用的。AI 是不粘锅性格，你给它的约束越硬，它就越老实。
5.5 一张避坑速查表
| 常见问题 | 典型信号 | 我的应对 |
|---|---|---|
| 幻觉 API | 调用了不存在的方法或参数 | 涉及陌生 API 先查官方文档 |
| 无限修 bug 循环 | 修复一个又冒出两个 | 三轮不解决就重写整个函数 |
| 上下文漂移 | 风格突变、开始乱加功能 | 强制单线程对话，定时开新对话 |
| 依赖污染 | 擅自加包、版本不符 | 技术栈硬约束 + 禁止项清单 |
| 大改毁全局 | 改 A 导致 B 崩了 | 每次提交前必须跑全量测试 |
6. 什么项目适合 Vibe Coding，什么不适合
这篇的最后一章，我想认真给一个诚实的判断。因为 Vibe Coding 真的不是所有场景都适用，盲目用会让你从“效率起飞”跌到“事故现场”。
6.1 适合的场景
我这一年半里体验最好的一类项目，是“边界清晰、反馈快速”的中小型工程。比如内部管理系统的后端 API、数据处理与格式转换脚本、带明确输入的 CLI 工具、以及自动化测试本身。这些项目共同的特点是：需求可以写得很具体，每个功能都有明确的输入输出，而且问题可以在几秒内被验证。AI 在这样的环境里，几乎就是一台高效的代码生成器，配合我的任务卡和测试检查，质量非常稳定。
6.2 不适合的场景
不适合的场景也很多。第一是那种牵一发动全身的遗留系统改造，AI 没有足够上下文去理解二十年业务规则，强行让它改代码，它很容易在你看不见的地方弄出隐性破坏。第二是性能敏感型模块，AI 生成的代码往往“能跑”但“跑不快”，你不深入做性能分析很难发现问题。第三是安全合规要求极高的场景，比如支付、权限校验核心链路。这倒不是说 AI 一定会写错，而是说它的错误模式太不可预测，在这种容错率极低的地方，风险收益完全不成比例。
6.3 我的项目选择清单
现在我接一个新的想法，会先对照这份清单决定要不要用 Vibe Coding：需求是否能在两段话以内描述清楚？反馈周期是否在 10 分钟以内？是否有足够的测试覆盖来兜底？失败代价是否可控？这四个问题里只要有两个是“否”，我就会把它当作传统开发项目对待，或者干脆先拆小再进 AI 流程。
我个人这一年半最大的体会是：Vibe Coding 并没有替代程序员，它替代的是程序员身上“打字员”的那部分，放大的是“架构师”和“审计员”的那部分。如果你能接受这个角色转换，它会是这些年里最值得投入的学习方向；如果你只想躺着等奇迹，那你大概率只能得到一把破破烂烂的代码和一地鸡毛的排查时光。
