一年半前我接了一个只有两周交付期的小项目。放在以前这种项目至少要经历框架搭建、接口设计、数据库建表、前端页面联调几个固定步骤一周能在电脑前坐掉大半。但那次我给自己定了一条新规矩只要是网上能找到答案的常规代码全部交给 AI我只负责设计需求和验收结果。那是我第一次完整跑完 Vibe Coding 的流程也是从那以后我彻底换了一种写代码的方式。Vibe Coding 这个概念最近被讨论得很多相关热搜里也总能看到“vibe coding 工具”“嵌入式 vibe coding”这些词。按我的理解它不是在说“随便乱写、靠氛围感糊弄”而是把开发者从逐行敲代码的身份里拉出来变成一个更偏向架构、验收、纠偏的角色。你描述场景AI 动手写你负责审片。只要你还会看方向、会读报错、会验收行为Vibe Coding 就一点都不危险反而效率高得惊人。这篇文章不聊抽象概念就聊我这一年半真实跑过的项目、踩过的坑、以及我从工具到流程上的具体做法。不管你是刚听说这个词的新手还是已经在用 AI 辅助写代码的开发者应该都能在里面找到几段可以直接抄作业的笔记。1. Vibe Coding 的真相不是偷懒是编码分工变了很多人第一次看到 Vibe Coding 这个词第一反应是“这人不写代码了全靠 AI 混日子”。我一开始也这么想过但真正实践之后才明白它只是把工作量从“手写实现”转移到了“定义、指挥、审阅、兜底”这四个环节上并没有让思考消失。1.1 从“打字员”到“产品”的角色迁移传统开发流程里一个需求从口头描述到代码成型中间需要经过肉体的键盘敲击。你会花大量时间在语法、括号、变量名、导入路径这些细节上。Vibe Coding 最大的变化是这些动作交给了 AI而你需要花更多时间在更早的阶段把需求讲清楚把边界条件列出来把技术约束塞进 prompt然后在 AI 交出代码之后打开 diff逐一追问“这里为什么这么处理”“那里是不是漏了空值判断”。举个例子我以前写一个后端接口会先建 model再写 service再写 router再补异常处理前前后后可能半小时。现在我会先用三分钟把接口契约写清楚比如数据模型是否需要唯一约束。创建和更新接口返回什么结构。参数校验失败时是返回 400 还是 422。是否允许部分字段为空。然后把这几个限定写进提示词让 AI 按这个契约生成代码。生成之后我重点审核的不再是每一行语法而是它有没有遵守我提的这几条边界。这其实就是一次角色迁移从“打字员”变成更像“产品经理 架构师 测试负责人”的混合体。1.2 一年半里我为什么没换回旧模式答案很现实省时间尤其省在重复劳动上。对于一个团队内部的数据看板、日常运维脚本、临时爬虫、内部管理系统Vibe Coding 的提速效果非常明显。同样的功能过去可能要写一个完整的下午现在如果需求拆得清楚两三个小时就能出可运行的版本剩下时间都花在测试和边界修正上。探索类项目更夸张。比如想试试某个新的开源库能不能满足需求以前我得先读它的 README再看示例代码再写最小 demo。现在直接把目标、限制、数据格式喂给 AI它先给出一版我跑一跑不行就让 AI 调整。这种探索速度直接改变了我的试错成本。当然不是说没遇到烂摊子。AI 生成的代码质量像初级开发三个月的水平有明显套路也会在边界上翻车。但只要我还保留着一双会看 diff 的眼睛它就是我工位上最勤快的初级开发而不是我的替代者。2. 工具选择与上下文管理Vibe Coding 的地基Vibe Coding 能不能成事工具只占三成剩下七成在你给它的上下文里。我在这一年半里把主流方案基本都试了一遍最后沉淀下来的是一套“多工具混合”的组合而不是迷信某个单一产品。2.1 主流工具怎么选编辑器插件 vs 独立 IDE现在能聊 AI 编程的工具非常多我自己的使用习惯是这样的工具类型代表方案我用来做什么注意点聊天式 IDECursor、Windsurf 等多文件重构、跨模块改动、整个项目的代码生成对大型仓库的上下文理解更强但会话太长会“失忆”编辑器 AI 插件GitHub Copilot、Continue 等日常补全、单文件修改、写测试、生成注释补全很快但主动纠正需求的意识较弱终端 AgentClaude Code、Codex 等命令行下的自动化修改、跑测试、分析日志适合处理脚本化任务但危险操作需要人工盯住本地模型方案ollama Continue 等敏感代码、不能出本机的内网项目离线可用但模型能力通常弱于云端模型我不建议只押注一个工具。实际项目里我用 Copilot 做“Tab 补全”用 Cursor 做“跨文件大改动”用本地模型处理完全不能出内网的项目。三者配合比单个 AI 工具信到底更稳。如果你是从零开始先别急着装一堆插件。选一个聊天式 IDE把一个真实小项目丢进去跑一遍感受“AI 读代码—写代码—你验收”的循环比什么教程都管用。安全第一的话记得从官方插件市场或官网下载不要碰来路不明的压缩包。2.2 上下文就是提示词的命很多 Vibe Coding 翻车不是 AI 能力不够而是你喂给它的上下文太稀薄。直接一句“帮我写个用户管理接口”它只能给你一个教科书式的模板完全不匹配你的项目结构、依赖版本和业务逻辑。真正好用的 prompt 更像一份简短的开发单。我常用的提示词骨架是背景这是一个 FastAPI 项目使用 SQLAlchemy已有 models.py。 任务新增一个 POST /api/orders 接口。 文件清单routers/orders.py、schemas/order.py、services/order_service.py。 约束不新增第三方依赖订单状态通过枚举透传失败时返回 400 和 code 字段。 请先输出文件级改动方案等我确认后再写完整实现。这看起来多花了几分钟但实际省回来的时间远不止几十分钟。AI 在信息充足的时候生成的代码就像照着需求文档写出来的信息不足的时候它就给你编一个看起来合理但完全不是你要的东西。除了 prompt项目里最好维护一个持久的“项目记忆文件”比如.cursorrules或AGENTS.md。我会把技术栈、代码风格、哪些目录不能随意改、测试命令等都写进去让每次新会话都能带上这批背景知识。这个文件每周更新一次是我自己踩了无数次“上下文丢失”的坑之后总结出的最优解。2.3 “Vibe Coding 下载”的误会热搜里总出现“vibe coding 下载”我猜很多人把它当成一个能安装的软件或插件。其实它不是一个独立的安装包而是一整套工作流。你需要下载的是具体的 AI 编程工具比如 Cursor、JetBrains 的 AI 插件、GitHub Copilot然后在你熟悉的 IDE 里启用它。所以别再搜“Vibe Coding 下载”了。先把一个 AI 编程插件装好再找一个不超过一千行的小项目尝试让它读代码、改代码、跑测试这就算正式开始。Vibe Coding 的门槛从来不是安装某个神秘工具而是你愿不愿意换一种和代码对话的方式。3. 我的 Vibe Coding 产品级工作流从第一个实验项目跑通之后我开始把 Vibe Coding 用到正式项目里。这个过程不是“一句话需求 AI 哗哗生成代码”那么简单我慢慢沉淀出一套四步工作流每一步都要人肉介入。3.1 需求拆解和种子文件先给 AI 搭舞台如果直接把一段模糊需求丢给 AI它大概率给你一个能编译但跟你预期完全不同的东西。我现在会先做需求拆解产出一个叫“种子文件”的东西。所谓种子文件就是一个精简的上下文锚点里面包含当前项目目录结构。本次任务涉及到的文件路径。技术栈和版本约束。接口、数据结构或关键算法的定义。验收标准也就是“做到什么程度算完成”。一个典型的任务描述可能是这样目标给现有订单系统增加定时取消超时未支付订单的任务。 涉及文件scheduler.py、models/order.py、config.py。 现有约束订单超时时间配置在 config.py 的 ORDER_TIMEOUT 字段使用 APScheduler 不得修改 models/order.py 的表结构。 验收标准任务每次扫描过期订单取消并把状态置为 CANCELLED并写入日志。有了这个文件AI 的注意力会被锚定在正确范围代码跑偏的概率会大幅下降。这个步骤很像给外包写需求说明书只不过这份说明书的读者是 AI。3.2 生成、运行、报错回喂的闭环Vibe Coding 的核心循环可以精简成四个动作生成、运行、报错、回喂。我严格遵循的顺序如下让 AI 先给出“最小可运行版本”不做任何额外优化。我在本地运行测试或启动服务。一旦报错把完整报错信息连同相关文件路径复制给 AI。要求 AI 先解释“报错根因”再给出修复方案。修复后重新跑测试绿灯再进入下一块功能。这个循环里最反直觉的一点是不要一次让 AI 生成一个上百行的完整模块。模块越大AI 越容易在内部埋下自相矛盾的逻辑。我会让它先把接口、数据结构、文件清单列出来确认之后再生成实现。一次只推进一个可控步骤报错了也知道该找谁。3.3 测试与重构用测试锁住 AI 的行为AI 生成代码最让我不放心的地方就是它重构时可能把我辛苦调通的边界行为弄丢。所以我的做法很朴素先让 AI 写测试再让 AI 重构人在中间守门。具体来说如果我要用 AI 重构一个老模块我不会直接说“帮我优化一下”。我会先把模块现有行为整理成一组测试用例让 AI 基于这些用例生成 pytest 或 JUnit 测试确保现有功能是绿的。然后再给它一个约束极其明确的重构指令“在测试不变的前提下改造内部实现保持所有公共接口签名一致。”测试就是这套工作流里的围栏。Vibe 可以浪但浪的边界必须是测试划出来的。没有测试保护的重构等于让 AI 在自己画的墙上随便拆砖拆完你都不知道哪块是承重墙。4. 嵌入式 Vibe Coding必须降低预期“嵌入式 vibe coding”这个搜索词我很早就见过因为我本身就是从嵌入式开发切到全栈的手头也一直有硬件相关项目。很多人以为 AI 能写 Web 代码就一定能写驱动、寄存器配置和 MCU 控制逻辑。实际感受下来它能帮上忙但你必须把预期调到“高级助手”而不是“方案提供者”。4.1 嵌入式开发为什么不能彻底“Vibe”嵌入式开发和 Web 开发最大的区别在于代码的运行环境不在你眼前也没有那么廉价的调试回路。你写完一个 Python 接口本地跑一下就知道行不行但写一个 ARM MCU 的串口驱动你至少需要交叉编译、烧录、逻辑分析仪、示波器甚至还要考虑目标板上电时序。AI 看不到这些硬件它只能根据大量相似代码的统计规律来生成。这就意味着几件事第一AI 对寄存器地址、位宽、掩码、时钟频率这些内容非常容易产生幻觉它会很自信地给出一个看起来合理但和你的芯片完全无关的数值。第二它生成的中断服务程序和 DMA 配置几乎不能直接信任。第三硬件上很多“约定俗成”的坑比如 volatile 关键字、字节对齐、电平转换延时AI 不会替你想到。所以嵌入式领域的 Vibe Coding我给的定位是“生成骨架 辅助分析”而不是“生成即交付”。它可以帮你把数据手册里的寄存器表转换成结构体定义可以帮你生成驱动的基础读写接口但最终的硬件验证必须人来完成。4.2 AI 在嵌入式项目里真正好用的几个位置这一年半里我在嵌入式项目里最舒服的几个 AI 使用场景是驱动骨架生成给定芯片型号、总线接口、外设寄存器基地址让 AI 生成 init、read、write 的代码框架再由我把寄存器地址和位域定义逐项替换为数据手册上的真实值。数据手册翻译把 PDF 或文本片段丢给 AI让它整理成结构体、枚举和掩码定义。这个环节虽然要人工核对但能省下大量零碎的键盘功夫。调试日志分析当设备输出异常状态时把日志片段贴给 AI让它根据代码定位可疑分支。我遇到过几次 GPS 模块冷启动失败的问题AI 帮我从串口日志里发现了一个配置校验分支的边界 bug。测试桩生成为上位机调试工具生成模拟数据发生器、CRC 校验脚本和压力测试脚本。这些代码运行在 PC 上容错空间大用 AI 非常划算。一个实际例子我帮一个 STM32 项目生成温湿度传感器驱动时AI 给的 I2C 读写骨架基本可用但它把传感器芯片地址写成了数据手册里的默认值没考虑硬件引脚上拉后的实测地址。最后我根据原理图改掉那一个宏定义驱动转了几百次读都很稳定。这个过程不是“AI 替代我”而是“AI 把骨架搭好我负责硬件关键细节”。4.3 嵌入式项目的“红线”什么必须人工确认下面这几类东西我给自己立了红名单AI 再强也不让它最终拍板中断服务函数里的操作顺序和临界区保护。启动代码、时钟树初始化、Flash 写保护配置。电机控制、电源管理、安全相关的输出逻辑。所有跟时序、电平、总线协议有关的参数。AI 可以参与草稿生成但必须有人把每一行和芯片手册对照过。我有一次让 AI 生成 UART 波特率分频配置它用了通用公式没有考虑这个芯片内部外设时钟源和标准库时钟树之间的差异结果串口输出全是乱码。排查了半小时才发现是分频值差了 4 倍。这种坑在普通应用开发里不常见但在嵌入式环境里一次误配置轻则功能异常重则可能影响硬件寿命。所以做嵌入式 Vibe Coding守住“不信任、必验证”这条底线比代码速度重要得多。5. 一年半里踩过的坑和排查实录Vibe Coding 没有想象中那么神话它更像一个效率放大器你方向对了它帮你放大产出你上下文没给够它帮你把 Bug 放大到整个项目。下面这四类坑是我遇到频率最高的每一类都花过真金白银的时间。5.1 上下文遗忘AI 改了 A 文件弄坏了 B 文件AI 在单次会话里记住的东西有限会话越长越容易把早期给的约束忘掉。最典型的翻车场景是让它修复一个登录模块的小 bug结果它沿着依赖关系顺手“优化”了 session 存储逻辑把另一处日志里依赖的老字段删了导致线上异常率升高。后来我给所有工具都配了项目记忆文件并把关键约束写进 prompt 的前三行。更重要的是我会在让 AI 改动前显式声明“不要改动与本任务无关的文件”。命令式地写进约束里AI 的扩散倾向会小很多。如果任务确实涉及多文件我会要求它在动手前先列出文件清单和改动范围我确认后再执行。这个“先评审后动手”的顺序帮我挡掉了至少一半的连带破坏。5.2 幻觉依赖AI 喜欢生造 API 和第三方库AI 还有一个很坑的习惯它会在代码里引用一个非常贴合问题描述、但其实根本不存在或者不常用的库。比如让它处理特殊 JSON 时它给我引入了json_tricks实际上项目原本用标准库就能搞定。又比如让它调用某个开源 SDK 的新版接口时它生成的参数名和真实发布版对不上一运行就抛TypeError。我的处理办法是两条第一在 prompt 里默认写上“禁止引入新依赖优先使用标准库或项目已有依赖”第二真需要新库时先人工确认库是否存在、版本是否兼容再让 AI 编写调用代码。幻觉依赖不像 bug 一样靠堆测试能兜住它更需要人在依赖声明和 import 位置把好关。5.3 团队协作里怎么 review“AI 原生代码”当 Vibe Coding 进入团队真正麻烦的不是代码跑不过而是代码风格和审查标准变形。AI 生成的代码经常夹带大段注释、模板块复制、以及一些它自己 invent 出来的“伪优化”。我带了两个小团队之后定了一套 review 纪律只要 AI 产生的改动git diff必须在 PR 里完整可见禁止用“AI 生成的不用看”糊弄。审查重点从“逐行读代码”变成“查数据流和边界”尤其关注 AI 擅自改动的地方。凡是 AI 生成的代码里出现了新增依赖、删除既有兼容逻辑、重命名公共接口review 一律打回。这套纪律执行下来团队对 AI 代码的信任度反而高了。因为大家知道AI 可以参与生产但要有人为它画一条清晰的围栏。5.4 我需要紧急回滚的典型时刻最狼狈的一次是我让 AI 重构一个订单服务的内部实现。它把一段我很久以前写的“老客户补数据”的兼容逻辑当成了废弃代码直接删掉。我当时以为 AI 已经通过全部测试就上线了结果老客户的历史订单页开始报空指针灰度数据异常率冲到 8%我紧急回滚才恢复。从那以后我每次让 AI 重构前都会在 prompt 末尾加一句话“项目中可能存在非显然用途的兼容逻辑如果不是你本次任务的明确目标请保留并注释说明。”同时我把所有不能被删的兼容逻辑写进了项目记忆文件。AI 不知道这段代码是“保护伞”还是“废代码”只有人知道。6. 新手入门路线与我的红名单如果你看完前面的内容想开始自己的 Vibe Coding 之旅我建议你先按下面的路线走一遍而不是上来就把它用在核心业务系统里。6.1 适合用 Vibe Coding 的四个典型项目类型项目类型适合程度原因内部工具、管理后台非常适合需求清晰、可快速迭代、出错影响可控探索性原型、概念验证非常适合重点在快速验证Vibe Coding 能大幅缩短试错周期常规 CRUD 业务系统适合要有测试和 code review 兜底直接跑生产有风险底层库、算法、硬件驱动低AI 幻觉率高需要大量人工核对只适合辅助生成骨架我把“底层库、算法、硬件驱动”放在低分区不是说不能用而是说它对你的验收能力要求极高。新手如果一上来就用 Vibe Coding 写编译器和加密算法大概率会被 AI 的迷之自信带到沟里。6.2 我建议的学习路径从小脚本到小系统第一步从一个个人小脚本开始比如用 Python 写一个日志分析脚本让 AI 生成代码你负责跑通。第二步找一个你熟悉的开源小项目在本地跑起来然后让 AI 帮你加一个小功能比如增加一个导出按钮、一个新接口。第三步尝试让 AI 做一次限定的重构同时用测试锁住行为。第四步再把核心业务逻辑交给它。每走一步都要练习一个核心能力追问和质疑。看到 AI 生成的代码别急着夸它跑通了先问“这个循环的退出条件是什么”“这个接口非法输入会怎样”“这个重构删了什么”。能问出这类问题说明你已经开始驾驭 Vibe Coding而不是被它带着跑。6.3 我的个人红名单哪些代码永远不让 AI 单独写即使是我最信赖 AI 的时候下面这些内容也不会让它“一手包办”支付、计费、权限与认证相关逻辑。涉及资金、库存、客户隐私的数据一致性代码。并发事务和分布式锁相关复杂逻辑。硬件安全保护、中断优先级、电源管理配置。团队公共基础设施代码比如 CI/CD、数据库迁移脚本。这些地方允许 AI 出草稿但必须有资深开发逐行 review甚至完全人工重写。为什么因为这类代码一旦出错成本不是“改个 bug”能覆盖的而是资金损失、安全事故、或者线上数据不可逆。Vibe Coding 的副产物是效率但最终代价清单上永远写着两个字责任。7. 一年半之后我发生的变化回头看看这一年半我最大的变化不是“写得少了”而是“想得更多了”。以前我会为一个愚蠢的NullPointerException查半天现在 AI 三秒就能定位但我会花更多时间在需求边界上反复确认“这个状态到底允不允许为空”“历史数据迁移过来会不会触发异常”。Vibe Coding 把时间从键盘前挪到了思考和判断里这在我看来是好事因为后者才决定一个项目的上限。如果非要给新人一句忠告我想说不要神话它也不要诋毁它。Vibe Coding 适合所有愿意对 AI 输出负责的人。你越是能给它清晰的边界它会回报你越高的效率你越是把它当成“甩锅对象”它就会用一堆看起来很对、跑起来很错的代码教你怎么做人。最后再分享一个小习惯我每天下班前会把当天所有让 AI 生成的代码在脑子里过一遍挑出一个我没看懂的片段第二天早上第一件事就是把它彻底搞懂。Vibe Coding 能帮你写代码但真正让你成长的永远是那些你愿意停下来追问的瞬间。