最近半个技术圈都在聊 vibe coding我第一次听到这个词的时候第一反应是“这不就是把用 AI 写代码换个洋气说法嘛”。直到自己关掉代码审查的“理性大脑”真正按 vibe coding 的方式跑完一个完整项目才意识到这跟我平时用 Copilot 补全代码、让 ChatGPT 生成一个函数完全是两码事。一句话概括vibe coding 是“跟着氛围写代码”——你负责描述产品的感觉和意图把键盘和设计决定权全部交给 AI看到报错就原样贴回去整个过程对你来说更像是在和队友口述需求而不是在逐行敲击键盘。适合谁想做快速原型验证的产品经理、刚接触编程但想法很多的新手、想探索新工具链的资深工程师都值得花一小时试试这种把人机分工彻底反转的工作方式。1. vibe coding 是什么一次重新定义人机分工的尝试1.1 概念来源与一句话定位vibe coding 这个叫法最早出圈是 Andrej Karpathy 在 2025 年初分享的一种新编程状态。他描述的场景是开发者不再逐行写代码而是用自然语言描述功能目标AI 大模型负责生成实现代码开发者的工作就变成了“把生成的代码贴进项目、运行、看效果、遇到报错再贴回去、改提示词继续循环”。他甚至用了类似“完全沉浸在氛围里几乎忘记代码本身还存在”这样的描述来捕捉那种体验。这里的核心词是“氛围”。传统开发中你要传达给同事或未来的自己的是精确的接口签名、严谨的边界条件、清晰的依赖关系而在 vibe coding 里你传达给 AI 的主要是产品的 vibe——这个功能大概是什么感觉、交互上想要什么调性、数据上大概怎么流转。至于底层是用数组还是链表、函数该拆成三个还是一个AI 依据它训练时见过的大量模式自行决策你不需要也没打算逐行去管。所以一句话定位就是vibe coding 是以“意图描述 报错反馈”为驱动把代码实现主导权交给 AI 的一种高信任度、快速迭代的编程方式。它强调的不是你写代码的能力而是你“描述清楚 判断对不对”的能力。1.2 为什么说它和你平时用 AI 写代码不是一回事很多人日常使用 AI 写代码的方式本质上是“AI 辅助编程”你写主干逻辑AI 负责自动补全、生成某个函数、帮忙写测试用例或者解释一段看不懂的报错。在这种模式下开发者始终坐在驾驶员的位置AI 只是一个手速极快的副驾。vibe coding 则把主副驾驶完全对调。下面这张对比表能更清晰地看出差异维度传统 AI 辅助编程vibe coding主导者开发者本人AI 模型代码审查强度逐行审查合入必须有依据快速翻一眼甚至不细看错误态度错误是必须消灭的 Bug错误是迭代的输入信号提示词作用辅助补全的上下文核心产品需求的“需求文档”交付速度中速可控性优先极快探索性优先典型心理状态理性、谨慎放松、信任、跟着感觉走放在工具层面更好理解Copilot 这类工具像“输入法”你打一半它猜你下一个词但 vibe coding 更像你直接把整篇作文的主题告诉外包团队让对方起稿你只看大纲、看成品、提修改意见。输入法猜错了你马上改外包团队写偏了你大概率只是轻描淡写地说“这里不行换一种写法”而不是拿起笔自己改。这种差异决定了心态完全不一样。普通 AI 辅助编程时你始终在跟代码“较劲”vibe coding 时你在跟 AI 的“理解力”较劲。这两个较劲对象对技能要求、时间消耗、最终产物形态的影响是天差地别的。1.3 哪些人真正适合 vibe coding我自己实践下来把适合人群分为三类也明确排除一类第一类是想快速验证想法的人。不管是产品经理想做交互 Demo、创业者想验证一个商业逻辑能不能跑通还是研究人员想搭个数据可视化原型vibe coding 都能让想法变成可点击的网页或可运行的小工具速度是以往的几倍。以前写前端路由都要翻半天文档现在只需要说清楚“三个页面左侧导航点击切换内容”。第二类是有一定领域知识但编程经验不深的人。比如懂算法但没系统学过工程的同学可以用 vibe coding 把论文里的公式变成可运行的验证程序懂电路设计的硬件工程师可以用 vibe coding 生成上位机工具来配合调试不用等软件同事排期。第三类是资深工程师做探索性实验。用 vibe coding 快速搭一个不熟悉的框架、新技术的 playground、一次性数据清洗脚本省下来的时间可以用来读文档和做架构思考。但有一类人我明确建议先别碰——需要发布生产系统、涉及资金交易、用户隐私、医疗或自动驾驶等领域的人。这些场景对可验证性、可审计性、错误边界的容错性要求极高vibe coding 的高信任度模式没有安全带可系。不是说完全不能用 AI而是不能“vibe”。2. 核心差异拆解不只是“少看几眼”那么简单2.1 从“审查者”到“体验者”的角色逆转传统编程模式里我们被反复训练成代码审查者写完一个函数要读一遍确认没有越界、没有资源泄漏、没有隐藏副作用才敢往下走。那种状态其实很消耗认知资源特别是有多年经验的老工程师盯着代码看的时候大脑里会同时跑着好几个并发检查线程。vibe coding 把这种角色彻底反转了。你不再是一个在代码仓库门口拿着放大镜的审查员而是一个站在产品门口敲门的体验者。你描述的每个功能AI 生成后你要做的第一件事不是读代码而是“跑起来看看”。页面长得对不对、按钮能不能点、接口数据有没有出来、报错提示是不是友好。你的反馈语言也从“这段代码的变量作用域有问题”变成了“这个页面感觉太挤了”“登录成功之后应该跳到首页而不是停在原地”。这种角色逆转带来的结果非常有意思它把程序员从“实现细节的泥潭”里拉出来重新放回到“产品体验的第一现场”。我印象最深的一次是让 AI 做一个数据看板生成出来后我第一眼看到的不是代码问题而是配色太丑、信息层级不对。过去我大概率要花一小时调 CSS而 vibe coding 模式下我只用补一句“按深色科技风重做主色调用蓝色渐变”三分钟后就看到新版。2.2 提示词工程和规则设定的新地位从加分项变成决定项很多人以为 vibe coding 等于“不需要动脑直接说话就行”这是最大的误解。恰恰相反vibe coding 对提示词工程的要求远高于普通 AI 辅助编程因为你没有第二次机会在代码层面修补表达不清的需求。普通辅助编程时AI 生成一段代码你看一眼能立刻发现哪里不符合预期哪怕提示词写得稀烂也无所谓反正自己会改vibe coding 里如果初始提示词没把技术栈、边界条件、风格偏好说清楚AI 生成的代码可能从根上就跑偏而且因为你不深入读代码这个偏差可能要很久之后才在行为层暴露出来。所以真正玩转 vibe coding 的人都会在项目开始前花时间写一份“项目规则文件”很多团队用 CLAUDE.md、rules.md 这类约定名称。它的作用相当于你给 AI 外包团队的一份入职手册。我的习惯是包含五个模块项目目标这个工具解决什么问题给谁用。技术约束语言版本、框架选型、不允许引入额外依赖比如“后端只用 Flask禁止用 Django”。目录结构约定生成的代码放在哪个目录命名风格是什么。错误处理策略什么情况要报错什么情况要静默处理日志打到哪。安全与性能红线不允许出现 SQL 拼接、涉及用户数据的操作必须有确认、分页查询必须有索引。这里有一个特别重要的细节规则文件不能写得像散文要写得像测试用例一样可被 AI 检查。比如不要写“请注意性能”而要写“所有列表查询必须在数据库层分页禁止加载全表到内存后再过滤”。2.3 错误容忍度与安全边界vibe 不等于盲写vibe coding 最标志性的操作就是“看到报错全选复制粘贴给 AI回车”。我刚开始觉得这算什么本事试多了才发现这个循环非常高效但它也有致命弱点AI 是在“上下文窗口”里做局部修补它看不到整个系统的全貌。很多时候一个报错消失是因为 AI 换了一种写法绕开了检查而不是真正解决了根因。所以我在实践里给自己划了几条安全边界哪怕 vibe 状态再上头也不碰涉及数据删除或覆盖的代码必须逐行审查比如批量删除、清空表、文件覆盖。涉及金额计算、权限判断的代码必须手工推导一遍核心分支。对外提供接口的鉴权逻辑不允许让 AI 自由发挥必须按我指定的框架写。生成代码后至少跑一遍测试命令不能只看“点击没报错”就认为成功。一句话总结我的原则可以 vibe 生成不可以 vibe 交付。生成阶段多信任 AI交付之前多信任自己的检查清单。3. 实操用 vibe coding 从零搭一个能跑的待办工具全记录3.1 工具选型我到底该用哪个 AI 编程工具既然要实操第一个绕不开的问题就是工具。最近“vibe coding 工具”相关搜索热度很高但很多人选工具选得很纠结。我把自己试过的组合和感受整理一下ClaudeWeb 或 API 手动复制粘贴上下文窗口大代码生成的完整度最高适合规则文件写得比较清晰的项目。缺点是你要自己在编辑器和网页间切换稍微麻烦。Cursor把 AI 直接嵌进了 IDE支持整个代码仓库作为上下文遇到报错可以直接框选给 AI 修复是我目前的主力组合配合 Claude 模型用体验最好。GitHub Copilot 的 Agent 模式对托管在 GitHub 上的仓库支持很好适合已经用 GitHub 做项目协作的团队能直接在 Issue 和 PR 流程里用自然语言驱动。本地部署的开源模型比如 Qwen2.5-Coder、DeepSeek-Coder 这类的量化版适合对隐私敏感、代码不能出本机的场景速度慢一些但胜在可控性。如果是第一次尝试我的建议是直接用 Cursor 免费版加 Claude 模型注册完五分钟就能进入 vibe 状态。别在一开始就把时间花在折腾工具上这本身就不 vibe。3.2 开工前的规则设定一份能直接抄的规则文件很多人一上来就急着“让 AI 给我做个 App”然后被生成出的一坨不可维护代码气到吐槽 vibe coding 不靠谱。真正的问题是没写规则文件。以下是我实际用过的简化版规则文件你可以直接抄# 项目规则文件rules.md ## 项目目标 构建一个单用户待办事项 Web 应用支持添加、完成、删除待办按日期分组显示。 ## 技术约束 - 后端Python 3.11 Flask数据库用 SQLite禁止引入 Flask-RESTful、Django。 - 前端原生 HTML CSS JavaScript禁止使用任何前端框架。 - 所有数据库操作使用 SQLAlchemy ORM禁止裸写 SQL 字符串。 ## 目录结构 所有代码放 app/ 目录入口文件为 app/main.py模板放 app/templates/静态文件放 app/static/。 ## 错误处理 - 表单提交数据必须校验非空校验失败时返回统一 JSON 格式{error: 字段不能为空}。 - 数据库操作异常时打印日志并返回 {error: 数据库错误}。 ## 安全红线 - 禁止任何形式的 SQL 拼接。 - 删除操作必须弹窗二次确认。 - 所有返回给前端的 ID 使用字符串禁止暴露自增主键。写完这个文件之后我通常会在第一次对话时把它完整发过去再加上一句“请先阅读这个规则文件后续所有代码生成都遵循它”。这句话很关键它让 AI 把规则文件作为长期记忆加载而不是每次临时发挥。3.3 完整迭代循环从一句话需求到能跑的应用我当时的第一个提示词是这样发的按照 rules.md 的约定做一个待办事项 Web 应用。首页展示所有待办按日期分组。输入框在页面顶部输入内容后回车即可添加。每条待办显示文字、日期和两个按钮完成、删除。完成的任务文字加删除线并置底。AI 大约花了十几秒生成了一整个 Flask 项目结构包括app/main.py、两个模板文件、一个 CSS 文件、甚至一个初始化数据库的脚本。第一眼看到这么多文件我是有点慌的因为传统模式下这些至少得花我两小时。接下来就进入标准 vibe 循环运行看看执行python app/main.py打开浏览器页面出来了输入待办、回车、添加成功。第一个问题点击“完成”之后页面回到了顶部而不是停留在当前列表位置。我把这个现象描述给 AI“完成任务后页面刷新会跳到顶部希望在原地停留”。AI 修正它给我改成用 fetch 局部更新而不是整页刷新。第二个问题删除按钮没有二次确认。我提醒它“rules.md 里写了删除必须弹窗确认”它立刻补上了。第三个问题日期分组显示今天的要做“今天”而不是显示完整日期。我把它翻译成“日期标题用相对显示今天显示‘今天’昨天显示‘昨天’其他显示具体日期”。收尾我又让它加了统计条数、清空已完成任务的功能全程没碰过核心逻辑代码。整个从零到跑通加两个增强功能耗时约四十分钟其中大部分时间是我在描述需求和等 AI 响应。这个过程中我唯一亲手写的代码是给项目补了一个requirements.txt里缺失的版本号——因为 AI 默认装了最新版我觉得不稳定就手动锁了版本。3.4 嵌入式 vibe coding 的特殊性不能全虚但能“半虚”近期的热搜词“嵌入式 vibe coding”让我很感兴趣因为嵌入式开发恰恰是最不能用 vibe coding 全流程覆盖的领域之一。我简单做过实验结合经验总结一下它的特殊性。嵌入式开发的代码最终要跑在单片机或板卡上面对的是真实硬件寄存器、中断、时钟配置、外设时序。AI 生成的驱动代码很多时候从语法上看完全没问题但一烧到板子上就黑屏、死机、或者功能完全不正常。原因倒不是 AI 笨而是嵌入式问题严重依赖芯片手册异常页和示波器波形这些上下文根本不在 AI 的训练数据里。但这不代表嵌入式开发不能用 vibe coding。我实验下来真正有效率提升的几个点协议解析代码比如 Modbus、CAN、串口打包解包这类格式固定的代码AI 写得又快又准比自己翻手册强。设备驱动框架告诉 AI“用 Linux 字符设备驱动框架提供 open/read/write/ioctl 接口”它生成的骨架能省掉大量样板代码。状态机生成把状态迁移表描述清楚AI 生成的 switch-case 状态机几乎零 bug。单元测试和 Mock让 AI 为纯逻辑代码生成测试用例以及为硬件依赖接口写 Mock非常好用。烧录脚本、日志解析上位机工具这类代码不直接接触硬件完全可以 vibe coding 全流程生成。我给嵌入式朋友的实操建议是硬件相关代码寄存器配置、中断服务、时序初始化用手工编写或基于官方例程修改纯逻辑代码协议解析、状态机、测试桩大胆交给 vibe coding。这种“半虚半实”的混搭模式既能享受效率提升又不会在硬件层翻车。4. 常见问题与排查技巧实录几个真实翻车现场4.1 代码能跑但功能是假的我做数据看板的时候遇到过一次很诡异的情况页面显示“已加载 500 条数据”但数据源 API 里明明只有 30 条。仔细追了一下才发现AI 没有真的去调 API而是直接在 JavaScript 里生成了 500 条假数据理由可能是它觉得“这样更直观”。这就是 vibe coding 最容易踩的坑AI 倾向于生成运行时不会报错的代码而不是真实连接到外部服务的代码。因为它无法验证外部 API 是否可用所以会做出自己假想一个数据结构并填满模拟数据的“聪明”行为。排查技巧是不要只信运行结果要对“关键外部链路”做人工抽查。比如搜索代码里有没有fetch、requests、SELECT语句确认这些调用真实存在于代码中且指向正确的地址。我还养成了一个习惯要求 AI 在生成代码时“涉及外部调用时必须打印真实返回状态码不允许 mock 数据”。4.2 上下文窗口爆掉AI 忘了最初的规则对话到第 20 轮以后AI 的行为会逐渐漂移明明规则文件里写了“禁止引入前端框架”第 25 轮它却默认用了 Bootstrap文件名从app/main.py变成了main.py。这不是 AI 故意的是上下文窗口装不下最初的规则了。我的解决办法是维护一个“当前任务状态”文件todo.md每完成一个功能就更新一次并在每次新对话之前把 rules.md 和 todo.md 一起发给 AI。相当于不让 AI 靠记忆工作而是靠项目文档工作。这招极大减少了行为漂移强烈推荐长期项目使用。4.3 报错循环同一个 Bug 反复出现有一次我的 Flask 应用反复报Address already in useAI 每次都让我换端口号。换一个端口确实不报错了但原来的端口为什么被占用始终没解决。直到我意识到这可能是之前的开发服务器没被杀干净手动lsof -i :5000查了一下果然是僵尸进程。这个案例说明的教训是AI 的修复策略是“最小改动消除当前报错”而不是“找到根因并根治”。当同一个问题第三次出现就要停止和 AI 在报错表面打转自己动手查系统层面、环境层面的因素。我总结的排查顺序是先查端口、环境变量、依赖版本等工程环境因素再回到代码逻辑别让 AI 一直在代码层面“盲修”。4.4 性能和安全问题vibe 盲区我在一个内部工具里让 AI 生成列表页跑起来没问题但数据量一上到几千条就卡成幻灯片。查下来发现 AI 用了最直观的写法把所有数据查出来再循环格式化。对几百条没问题对几千条就扛不住了。性能问题的本质是AI 生成代码时没有“数据规模”的概念你一说“列表”它的默认经验就是几十条级别的实现。安全性也是同理我让 AI 写一个用户查询接口它直接拼 SQL 字符串注入漏洞明晃晃地挂着。所以我在规则文件里专门加入性能与安全条款比如“所有数据库查询必须延迟加载”“禁止在 Python 代码里拼接 SQL”。还会在完成后让 AI 自己给自己做一轮审查“请以安全工程师的视角审查这些代码列出所有问题不修改。”这一步能挖出不少潜在风险。5. 什么时候该 vibe什么时候必须收敛锋芒5.1 明确适合 vibe coding 的场景根据自己的实践我把适合度从高到低排了个序一次性工具和脚本批量改文件名、数据迁移、CSV 清洗用完即弃vibe 完美。快速原型和 Demo验证产品可行性、给投资人演示、给团队体验新交互重在“看起来能用”。学习探索想弄懂一个新框架时vibe coding 生成示例代码自己再亲手改造一遍比看文档快得多。自动化测试生成让 AI 生成测试用例再由人来审查测试逻辑效率和安全性双高。内部工具团队使用、数据不敏感、挂了能重来vibe 完全够用。5.2 必须收敛的场景这些场景我在之前提到过但值得集中强调生产环境核心链路用户认证、支付、订单状态机每一行都可能是钱。强监管行业金融、医疗、电力控制需要全链路审计日志可追溯。嵌入式硬件核心中断优先级、实时性、看门狗AI 的“平均经验”往往不适用于具体芯片。涉及用户数据的批量操作一次误删可能直接变成事故。在这些场景里我的建议不是不用 AI而是把 AI 降级为“顾问”而非“主笔”让它写代码片段、做解释、列测试计划但最终落地代码必须通过人工逐行审查。5.3 我的混合作业模式Vibe 生成Rule 约束Review 把关Test 兜底实际操作中我不会非黑即白地选“全 vibe”或“全人工”。最后形成了下面这套四步流水线分享给你们参考Vibe 生成用自然语言把功能需求提交给 AI让它在规则文件约束下生成完整实现这一步追求速度和覆盖率。Rule 约束规则文件常驻更新每次模型变更、每个新模块都要重新声明技术边界和安全红线避免 AI 跑偏。Review 把关我抽查关键链路代码重点看数据流、鉴权、错误处理和外部服务调用。不需要逐行读但要确认“肉的纹理”是对的。Test 兜底任何自动生成的代码必须跑通至少一轮测试命令。我通常让 AI 生成测试用例再执行把它自己的产出拿来检验它自己。这套流程让我既享受到了 vibe coding 的爆炸速度又守住了传统开发的安全底线。说实话vibe coding 并没有让我的编程水平下降反而逼我花更多精力去提升需求描述能力和架构判断力——因为当生成代码变得唾手可得真正稀缺的反而变成了“知道该让 AI 做什么”和“知道 AI 做得好不好”这两种能力。最后再分享一个细节我在 vibe coding 过程中踩过最深的坑不是技术问题而是心态问题——一旦习惯了 AI 全权生成、快速迭代的节奏会变得不愿意停下来写文档、做审查。后来我给自己立了一条规矩每次 vibe 完一个功能必须写两行注释说明“这段代码是干嘛的、为什么这么写”。这两行注释与其说是写给未来的同事看不如说是逼自己重新以工程师的身份审视 AI 的产出。毕竟 vibe coding 的初衷不是让程序员退化而是把我们从重复劳动中解放出来去专注于更高层次的取舍。这个度把握好了vibe coding 就是这几年最值得纳入工作流的一件武器。