最近在技术社区和开发者群里vibcoding 这个词出现的频率越来越高。有人把它翻译成“氛围编程”有人叫它“感觉流开发”。说实话我第一次看到这个词的时候也愣了一下但仔细想想这其实就是我们正在经历的一种编程方式变化开发者用自然语言描述需求、思路、甚至是一种模糊的“感觉”AI 负责把这种意图变成代码而人把精力集中在方向判断、代码审查和纠偏上面。我连续几个项目都在用这种方式推进踩过不少坑也沉淀了一些自己的方法。这篇文章不打算讲什么玄学就是把 vibcoding 到底是怎么一回事、它适合做什么、实操中怎么用、会遇到哪些问题完整地梳理一遍。如果你正在用 AI 编程工具但又觉得效率没有想象中高或者想尝试这种新的工作流但不知道从哪里下手这篇文章应该能给你一份可以直接参考的答案。1. vibcoding 到底在说什么1.1 从“氛围编程”这个翻译说起vibcoding 是 vibe 和 coding 的合成词。vibe 在年轻人的语境里是“氛围、感觉、气场”所以 vibcoding 直译过来就是“跟着感觉编程”。听起来很玄实际操作起来其实很朴素你不太需要一字一句地敲代码而是用对话的方式告诉 AI“我想要一个什么样的功能”“这个页面大概是什么感觉”“这里的数据流转应该怎么样”AI 会基于你的描述生成版本你再根据结果调整方向。这种模式和我们熟悉的面向搜索引擎编程完全不同。以前遇到问题我们会先搜索关键词、翻文档、找 Stack Overflow 上的答案然后把代码片段拼到自己的项目里。vibcoding 的逻辑是把“知道怎么做”的一部分工作外包给 AI人保留的是“知道要什么”和“知道好不好用”这两件事。我用一个生活化的例子来解释。传统编程像是你自己下厨每道菜的切配、火候、调味全部亲力亲为。vibcoding 更像是你请了一个技术很好的帮厨你告诉他“今天想吃酸辣口、要有点焦香味、不要太油”他帮你把菜做出来端到你面前你再尝一口说“辣度不够再酸一点”。整个过程里你不需要自己握刀铲但你对味道的判断决定了这盘菜能不能上桌。1.2 不是不写代码而是换个方式写代码很多人对 vibcoding 有一个误解觉得它意味着开发者不再需要懂编程、不再需要看代码只要会说话就行。从我实际使用的情况来看这个理解是有偏差的。vibcoding 不等于不写代码你的角色从“代码生产者”变成了“代码协作者”和“方向决策者”。AI 生成代码的时候你依然需要阅读它、理解它、审查它。你不会写代码就没法判断 AI 给出来的方案是不是合理也没法在它跑偏的时候把它拉回来。更关键的是AI 经常会一本正经地生成看起来合理但实际有问题的代码如果连最基础的语法和逻辑都看不懂这些问题就会直接流到生产环境里。vibcoding 真正改变的是开发的节奏。以前写完一个功能模块可能要花不少时间在重复性编码工作上比如写样板代码、调样式、处理边界条件。现在这些工作可以交给 AI 快速完成人只需要在关键节点做审查和决策。我自己的体感是vibcoding 模式下的编码速度会快很多但思考密度反而更大了因为每一步你都需要想清楚“这个方向对不对”“这个实现有没有隐患”。所以我把 vibcoding 理解为一种更进阶的编程协作方式AI 当执行者人当架构师和验收人。它不是编程的终结而是编程范式的一种演进。1.3 适合什么项目、什么团队vibcoding 不是万能的它有自己的适用边界。我实践下来比较适合的场景有以下几类原型验证和 Demo 开发。快速把想法变成可点击的页面、可调用的接口验证业务逻辑是否走通。内部工具和脚本。一次性或低频率使用的工具比如数据清洗脚本、日志分析工具、自动化运维脚本。前后端框架代码生成。基于成熟框架创建项目骨架、生成 CRUD 接口、搭好页面结构。技术栈切换时期的探索。团队要学一个新的框架或语言让 AI 生成示例代码作为学习参考比自己查文档效率高很多。不太适合的场景也很明显对性能和安全性有极致要求的核心模块、涉及复杂并发和数据一致性的系统、需要长期维护且对代码风格有严格要求的大型项目。不是说这些场景完全不能用 vibcoding而是需要人投入更多的审查精力如果团队没有足够资深的开发者把关风险会比较大。团队层面vibcoding 更适合小团队和独立开发者。人少、事多、变化快的时候这种模式能大幅提升产出效率。如果是在大团队里需要多人协作开发同一个代码库那么必须提前约定好 AI 生成代码的规范和审查流程否则很容易出现风格混乱、代码质量参差不齐的情况。2. vibcoding 的核心工作流与关键环节2.1 需求拆解把“感觉”变成 AI 能理解的输入vibcoding 的起点不是写代码而是把脑子里模糊的想法变成一个 AI 能理解的清晰描述。这一步很多人都忽略了结果是 AI 生成出来的东西和自己的预期差了十万八千里然后反过来抱怨工具不好用。我自己的经验是描述需求要遵循三个层次第一层是功能目标。这个功能要解决什么问题用户拿到它之后能做什么。比如“做一个待办清单页面”就比“帮我做个页面”清晰得多。需要把基本功能点列出来能不能增删改查、要不要分类、需不需要排序。第二层是技术约束。项目用什么框架、什么语言、有没有已有的组件库和样式规范。AI 不知道你的技术栈如果不告诉它它可能会给你一套完全兼容不了的方案。我见过很多人让 AI 生成代码结果 AI 基于一个完全不同的版本生成接进项目里全是报错。第三层是体验细节。页面大概什么风格、交互上有没有特殊要求、这些看起来“软性”的信息会直接影响生成结果的质量。比如同样是列表页你要卡片风格还是表格风格空状态要展示什么都是可以描述的。值得注意的一点是vibcoding 强调“跟着感觉走”但不代表需求可以完全没有结构。恰恰相反把感觉结构化是 vibcoding 能不能成的分水岭。会拆解需求的人能让 AI 一次生成就能用不会拆解的人会在反复对话里消耗大量时间。2.2 上下文构建与提示词维护AI 编程工具和搜索引擎不同它没有“记忆”每一次对话的上下文都是有限的。如果是临时问一个小问题无所谓上下文但如果是一个完整的功能模块上下文构建就非常重要。我通常在项目里维护一个上下文文件里面放的是 AI 需要反复参考的信息主要包括项目的技术栈和版本号。项目的目录结构。代码风格约定。设计规范比如主题色、组件库。常见踩坑记录哪些写法在这个项目里不能使用。这样做的效果很明显。AI 每次生成代码之前我先让它读一遍这个上下文文件生成的代码就能自动符合项目约定不会出现风格漂移的问题。这就像团队里来了一个新人你第一时间先给他一本操作手册他上手的速度会快很多。提示词本身也需要维护。不要每次都重新写一大段把常用的需求描述整理成模板需要的时候填充关键词就行。我常用的一个模板大致是这样的请基于以下需求在 [目录] 下实现 [功能名称] - 功能描述[说清楚用户故事] - 技术栈[框架/语言/关键依赖] - 交互细节[页面流转/状态变化/异常处理] - 数据格式[接口字段说明或数据结构示例] - 风格要求[参考组件库/设计规范] 请生成可直接运行的代码并说明使用方式。模板的价值在于它能把描述需求的时间压缩到一两分钟而且保证每次给 AI 的信息是完整的不会因为我忘了说自己想要动画效果就导致生成结果缺失。2.3 生成-审查-修正循环vibcoding 的典型开发过程是一个循环描述需求、AI 生成代码、人审查代码、反馈修改意见、AI 调整直到满意为止。这个循环里最关键的环节是审查。AI 生成代码不是任务终点而是中间产物。你自己不审查就放进项目里是对自己也对团队不负责任。审查的时候我通常会重点关注几个地方逻辑正确性。代码能不能实现预期功能条件判断和异常处理是否合理。安全隐患。有没有 SQL 注入风险、有没有敏感信息泄露、有没有明显的认证绕过问题。风格一致性。命名是否规范、结构是否和项目其他部分保持一致。性能隐患。有没有明显的循环嵌套、有没有不必要的渲染刷新、有没有过度查询数据库。如果发现有问题不要直接自己去改尽量把问题描述给 AI让它自己修正。这也是一种训练过程对话轮次越多AI 对你的项目理解就越深后面生成的代码会越来越贴近你的预期。这个循环会让开发过程看起来像是“一直在聊天”但实际操作的时候节奏很快。一个普通的 CRUD 接口从描述需求到测试通过可能在十几分钟里就能完成。同样的工作量在传统模式下可能需要半天甚至一天。2.4 代码审查与信任边界vibcoding 模式下代码审查的重要性被放大了很多倍。平时我们会把审查看作一个质量保障步骤但在 vibcoding 的场景下它更像是一道安全防线因为 AI 生成代码的出错率是远高于人类开发者的。关于这个问题我想单独强调一下AI 生成的代码看起来越是“理所当然”越要提高警惕。AI 特别擅长生成风格良好、命名规范、注释全面的代码但它在逻辑边界上的错误也同样频繁。比如字段名拼错、把 写成 、数据格式判断遗漏兼容性这些都是我真实遇到过的。所以在我的项目里设置了一条原则AI 生成的代码必须由人审查通过后才能进入主线分支不允许直接 AI 生成然后直接合入。这条原则看起来保守但它能避免绝大多数低级问题。信任边界可以这样理解AI 在当前阶段更像是一个能力很强但不太稳定的实习生你需要给它足够的支持明确交代背景也要在关键节点把关。不要因为它看起来专业就无条件信任也不要因为一两次出错就完全放弃使用。3. 工具选型与实践配置3.1 主流 AI 编程工具对比vibcoding 离不开好用的工具。目前市面上主流的 AI 编程工具各有侧重点我挑几个自己用过且觉得有代表性的来说。GitHub Copilot 是很多人最早接触的 AI 编程工具它更像是一个“智能输入法”在你敲代码的时候提供补全建议。它的优势是侵入性低不需要改变原有工作流适合在传统编程模式里提效。但它的会话能力和全局理解偏弱不太适合做大规模的功能生成。Cursor 和 Claude Code 这类会话式编程工具更适合 vibcoding 的玩法。它们能在一个上下文里理解整个项目的结构支持连续多轮对话可以根据需求描述生成完整文件或模块。Cursor 对开发者的日常操作更友好图形界面完整适合前端和后端混合开发。Claude Code 在长对话和大文件处理上表现更好适合做重度重构和代码审查。国内也有不少好的选择比如通义灵码、CodeGeeX 等它们对中文场景的适配做得更多如果你习惯用中文描述需求体验会更好一些。我个人的建议是不要迷信某一个工具不同任务用不同工具。简单补全用 Copilot复杂模块生成用 Cursor做代码审查和重构可以尝试 Claude Code。关键是要让工具为你的工作流服务而不是为了用工具而用工具。3.2 我的项目配置参考这节我用一个实际项目的配置来做示范。假设我们要用 Vue 3 TypeScript 开发一个后台管理系统团队成员很少目标是三周内完成第一个可用版本。第一步是搭好项目骨架。你不用自己搭让 AI 来做。给它的需求描述是基于 Vue 3 TypeScript Vite 创建后台管理项目包含路由配置、Pinia 状态管理、Axios 封装和常用布局组件。第二步是准备上下文文件。我建议在项目根目录放一个 AI_CONTEXT.md内容写清楚项目技术栈、目录结构、代码规范、接口约定。每次让 AI 做事情之前先让它读这个文件。这样 AI 生成代码的准确率会有质的提升。第三步是给 AI 划分工作边界。比如我们可以约定前端页面由 AI 生成但涉及鉴权和权限控制的逻辑必须由人来写或者由人严格审查。这是基于安全的考量Auth 相关的代码出问题后果往往很严重。下面是一份简化版的上下文文件示例你可以参考# AI 上下文说明 ## 技术栈 - 前端框架Vue 3.4 TypeScript 5.4 - 构建工具Vite 5 - 状态管理Pinia - UI 组件库Element Plus - HTTP 请求Axios ## 目录结构 - src/api接口请求 - src/views页面组件 - src/components公共组件 - src/router路由配置 - src/store状态管理 - src/utils工具函数 ## 代码规范 - 组件使用 script setup 语法 - 变量命名使用 camelCase组件命名使用 PascalCase - 样式使用 scoped类名使用 BEM 风格 - 所有接口请求必须经过 src/api 目录统一封装 ## 接口约定 - 基础路径/api/v1 - 响应格式{ code: number, data: T, message: string } - code 0 表示成功非 0 表示失败有了这份上下文再配合清晰的指令AI 生成出来的代码基本可以直接用在项目里不用大改。3.3 提示词模板与工程化沉淀vibcoding 用多了以后很多人会发现一个特点你反复在做同类的事情时实际上是在做重复劳动。写一个列表页要描述一遍写另一个列表页还要描述一遍。这时候就需要做提示词的工程化沉淀。我的做法是建立一个提示词库按场景分类维护。比如列表页生成模板包含搜索条件、表格展示、分页操作、新增编辑弹窗。Go 接口生成模板包含参数校验、业务逻辑、数据库操作、返回统一格式。代码排查模板包含问题现象、相关代码片段、期望行为、已尝试方案。每个模板都经过多次迭代打磨已经验证能在当前技术栈下稳定产生可用结果。团队里其他成员也可以直接复用这套模板大家的产出风格会更统一。这个思路和软件开发里“抽取公共组件”的思想是一样的。提示词本身就是一种资产花时间打磨它们是值得的。我见过很多团队每个人都有自己的 AI 使用习惯但缺乏统一沉淀结果就是代码风格五花八门维护成本很高。建立提示词库之后这个问题的改善非常明显。4. 实操过程与踩坑实录4.1 一次完整的功能开发过程用一个真实的小功能来完整展示 vibcoding 流程在一个管理后台里做一个“用户反馈列表”页面支持筛选、分页和查看详情。我的第一条指令是让 AI 读取上下文文件请阅读项目根目录下的 AI_CONTEXT.md了解项目技术栈和规范。确认 AI 读取完成之后我再给出功能需求请在 src/views 下实现用户反馈列表页 feedback.vue - 功能描述展示用户反馈列表支持按类型筛选和状态筛选分页展示点击查看按钮可以打开抽屉显示反馈详情。 - 技术栈使用 Element Plus 组件库TypeScriptsetup 语法。 - 接口约定API 路径是 GET /api/v1/feedbacks请求参数为 page、pageSize、type、status响应数据格式按照项目约定。 - 交互细节筛选条件变化时重置页码加载数据时显示 loading 状态抽屉中显示完整反馈内容和用户联系方式。AI 生成的代码质量还不错基本功能都有。但审查的时候我发现两个问题一是筛选条件变化时没有重置页码这会导致当前页码超出总数范围二是详情抽屉里的用户联系方式字段名拼错了和接口实际返回的字段对不上。我把这两个问题反馈给 AI筛选条件变化时应该重置页码为 1。 抽屉中用户联系电话字段名有问题实际接口返回的字段是 mobile不是 phone。 请修正以上两个问题。AI 很快给出了修正版本我再次测试通过后合入分支。整个过程耗时大概十五分钟其中我自己的主要工作是审查代码和做边界测试真正从零写的代码几乎为零。4.2 常见问题速查表我在 vibcoding 实践中收集了一些高频问题的排查思路整理成表格方便查阅。问题现象可能原因解决方式AI 生成代码与项目风格差异大没有提供上下文信息在指令前先让 AI 读取上下文文件明确项目规范AI 反复修改仍不符合预期需求描述太模糊把需求拆成功能点、技术约束、体验细节三个层次生成代码可以运行但逻辑有坑边界条件未描述清楚审查时特别关注条件判断、空值处理、并发场景对话太长之后 AI 忘掉早期需求上下文窗口有限定期总结对话进展在关键节点新建会话承接AI 生成接口字段与定义不一致接口文档缺失或信息过时把接口定义直接贴进对话让 AI 基于原始定义生成生成代码有安全隐患安全约束未在提示词中强调在指令中明确要求处理输入校验和权限判断这张表本身也在持续更新。每次踩到新的坑我都会把现象、原因和解决方式补充进去下次再遇到类似问题就能快速定位。4.3 我在 v ibcoding 里踩过的坑第一个坑是“用 vibe 代替了思考”。刚开始接触这种模式的时候会特别兴奋一个 AI 生成功能模块的速度让人上头所以那段时间我几乎不审视需求本身想到了什么就扔给 AI 去做。折腾了两三天之后发现做出来的东西看起来很多但有一大半不是用户真正要的。从那以后我给自己定了规矩动笔描述需求之前先花五分钟想清楚这个功能到底为什么存在、用户会怎么用它、成功的标准是什么。第二个坑是“代码审查流于形式”。AI 生成代码太流畅行文又很像老手写的人会产生一种错觉质量应该没什么问题吧我第一次基于这个心态跳过深度审查之后一个统计口径算错的 bug 直接跑到了联调阶段后端同事来找我核对的时候场面非常尴尬。AI 生成的代码必须像审查新同事的代码一样去审查不能带滤镜。第三个坑是“上下文文件形同虚设”。我一开始放在项目里的上下文文件内容很少只有技术栈和目录结构。结果 AI 生成代码的时候还是会写出和项目现有代码风格不一致的内容。后来我花了一个晚上把代码规范、接口约定、常见反模式都写进去又让 AI 多读了几次节省下来的修改时间远远超过了写这个文件的时间。4.4 团队协作里的规则怎么定vibcoding 模式如果用在团队里一定要提前定好规则不然整个代码库很快就会变成无人能维护的状态。我建议至少明确以下几点第一AI 生成代码的分支管理策略。所有 AI 生成的代码不能直接推送到主分支必须走分支加 MR 的方式由其他成员审查通过后再合并。第二约定 AI 的使用边界。哪些模块是 AI 可以自由生成的哪些模块必须人工编写。比如权限控制、支付逻辑、核心算法这类高风险模块我倾向于人工编写或至少人工逐行审查。第三统一提示词和上下文文件。让团队成员共用同一套上下文文件可以减少风格漂移也方便大家理解彼此的代码。第四记录 AI 的常见错误模式。每个成员把自己遇到的 AI 典型错误记录下来形成一个团队级别的踩坑文档。这样其他人看到类似情况时能快速识别风险。5. 写在最后的一点个人体会如果你问我 vibcoding 到底靠谱不靠谱我的答案是它已经是我日常工作流里不可缺少的一部分但它并没有取代编程这件事本身。它改变了我和代码打交道的方式让我能把更多精力放在设计、体验和架构这些更难被自动化的事情上。我自己现在的开发节奏是先用自然语言把想法铺开让 AI 把骨架搭出来然后花时间做审查、修正和收尾。这个过程中我会用到上下文文件、提示词模板和问题速查表它们才是保证 vibcoding 效率的隐藏关键。单独会用一两个 AI 工具的人很多但能把整个工作流打磨顺的人还不多这恰恰是机会所在。最后再分享一个小技巧遇到 AI 生成结果不理想的时候不要急着在里面一点点抠细节而是把问题定位到“对话上下文”上。很多生成质量差的根本原因是你给它的背景信息不够不是它的能力不行。上下文给足、交互闭环跑通vibcoding 带来的效率提升往往超出预期。