★ FEATURED ARTICLE 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 并没有替代程序员它替代的是程序员身上“打字员”的那部分放大的是“架构师”和“审计员”的那部分。如果你能接受这个角色转换它会是这些年里最值得投入的学习方向如果你只想躺着等奇迹那你大概率只能得到一把破破烂烂的代码和一地鸡毛的排查时光。
阅读完成 · 觉得有帮助？
