1. Vibe Coding 的本质它真正改变的是写代码还是想方案我从去年年底开始重度使用 Vibe Coding当时团队内部对它有两种极端看法一半人觉得这就是个高级补全插件另一半人觉得它会让人失去基本功。半年多跑下来我的结论是Vibe Coding 真正改变的不是键盘敲字的速度而是把从需求到代码这条链路里最耗时的部分——方案设计、接口梳理、边界条件确认——搬到了对话里完成。很多人把 Vibe Coding 理解成用自然语言让 AI 写代码这是对的但太粗糙了。实际上它的核心价值是用对话驱动开发的节奏。传统开发是你先想清楚再写写的时候还在想Vibe Coding 是你先描述清楚AI 生成然后你以评审者的身份去检查、修正、迭代。这个角色的转变非常关键——你不再是一个逐字符的输入者而是一个有判断力的架构师。以我自己为例以前做一个内部工具的前端页面光是布局和状态管理就要磨一个下午。现在我用 Vibe Coding第一步先描述清楚页面分几个区域、每个区域的数据来源、交互是什么AI 直接生成整体骨架我再基于骨架做调整。真正省时间的不是生成那一步而是省掉了从空白文件开始的心理启动成本和基础代码的搭建过程。不过我必须给刚接触的人泼一盆冷水Vibe Coding 对需求描述能力的要求比传统开发更高。你如果说不清楚AI 写出来的东西就比你手写更糟糕——因为它会一本正经地补全你没想清楚的逻辑。所以我一向的比喻是传统写代码是施工队Vibe Coding 是设计师加施工队。你需要当那个设计师。后面所有技巧都建立在一个前提之上你肯花时间把需求讲清楚并且愿意用工程化手段管理 AI 产出的代码。如果做不到这两点任何效率技巧都是空的。2. 环境搭建为什么我把开发阵地从 VS Code 迁到了 Trae聊效率提升必须先聊工具链。我试过用 VS Code 加各种 AI 插件做 Vibe Coding也试过独立部署的开源方案最后日常主力固定在了 Trae 上。不是因为它完美而是因为它把对话式开发这件事做得最像一条完整流水线。2.1 Trae 比编辑器插件强在哪VS Code 加 Continue 或 Cline 这类方案本质是编辑器之上叠一层 AI 交互。它能用但你很快会发现几个别扭的地方AI 生成的代码和你的手动修改之间缺少清晰的版本边界多文件修改时上下文容易丢对话框和代码区来回切换非常打断心流。Trae 这类 AI 原生 IDE 解决的是这件事——AI 能力被嵌进了编辑器的底层。它的 Builder 模式可以一条指令改动多个文件而且每个文件的改动都有明确的状态标记你可以 review 每一处 diff 再决定接受还是拒绝。这个体验对我来说是质变我不再需要复制 AI 输出、粘贴到文件、再看有没有拼写错误而是直接在编辑器里完成全部操作。2.2 环境搭建里最容易踩的坑选型之后不是马上就干活环境搭建有几个细节非常影响后续使用体验第一模型配置。我在 Trae 里同时配置了不同用途的模型。日常对话和代码解释用响应更快的轻量模型复杂架构设计和跨文件重构用推理能力更强的旗舰模型。很多人只挂一个大模型走天下结果就是简单任务响应慢、复杂任务思考不够。我目前的分配是任务类型模型选择原因单文件函数编写、格式化、解释代码轻量快模型延迟低交互顺手跨文件重构、架构设计、疑难排错旗舰推理模型需要考虑上下文和后效自然语言转 SQL 或正则这类模式化任务中等模型性价比最优第二项目索引一定要打开。很多人觉得 Trae 打开项目文件夹就开始对话了其实没这么简单。它需要一个建立索引的过程最好在动手前先让编辑器完整加载一遍项目结构尤其是大型项目否则 AI 对项目文件的理解会非常残缺经常找不到文件或者用错接口。第三全局 MD 文档的加载方式。这个我下一章展开讲但在环境搭建层面我的建议是把全局 MD 文档放在项目根目录下一个固定的位置比如.vibe/目录或docs/目录并在对话中明确告诉 AI 每次修改前先读这些文件。不固定位置的话AI 每次都要在庞大的文件树里猜测哪些是你说的关键文档效果大打折扣。3. 全局 MD 文档让 AI 从聪明的新人变成了解项目的人Vibe Coding 里最容易被忽视、但效率影响最大的一个操作就是写全局 MD 文档。什么叫全局 MD 文档就是放在项目里、用来描述项目整体规则的 Markdown 文件。我在实践里把它拆成三个角色项目背景说明书、技术规范约束书、以及会话上下文复位器。3.1 把项目背景写清楚AI 才不用每次重新猜你想想你和 AI 对话的时候它其实没有记忆的。每次打开新会话它对你的项目一无所知。如果没有全局 MD 文档你每次都要重新解释我们这个项目是干什么的用了什么框架目录结构大概长什么样。这些话重复三遍之后你就会烦而且每次解释的详细程度还不一样AI 的产出质量也跟着飘忽不定。我的做法是在项目根目录维护一个PROJECT_CONTEXT.md包含以下固定结构# 项目背景 - 项目用途一句话说明 - 目标用户这个项目给谁用 - 核心业务逻辑不超过五条的要点 # 技术栈 - 前端框架名 版本 - 后端框架名 版本 - 数据库类型 版本 - 包管理器npm/pnpm/yarn 及版本 - 运行环境Node 版本等如适用 # 目录结构 - src/ 下各目录职责说明 - 新增业务代码放哪里 - 公共组件/工具函数放哪里 # 当前阶段的开发重点 - 最近在做什么模块 - 哪些部分已稳定哪些还在频繁改动别看内容少它解决的问题非常大。AI 每次读了这个文件它对新会话的热身时间基本可以缩短到零。你上来直接说帮我改一下用户注册的校验逻辑它就知道注册模块在哪、用了什么框架、校验逻辑用什么风格写。3.2 用规范约束文档给 AI 划边界第二类全局 MD 文档是规范约束我命名为CODING_RULES.md。这类文档定义的是代码该怎么写的规则。比如组件用函数式还是类样式用 CSS Modules 还是 Tailwind错误处理用什么风格API 层的封装规范是什么为什么这个文件重要因为 AI 生成代码最大的问题不是生成不了而是生成出来的代码风格跟你的项目不一致。你用手写的方法是 A 风格AI 给的是 B 风格混在一起之后项目就变成了四不像后维护成本直线上升。我的CODING_RULES.md里会写# 编码规范 - 组件使用函数式声明不写类组件 - 样式使用 CSS Modules文件名与组件名保持一致 - 接口请求统一走 src/api 下封装的方法禁止在页面中直接写 fetch - 错误处理统一使用 try-catch并调用全局错误上报 - 文件名一律使用 PascalCase组件和 camelCase普通模块 # 提交规范 - 变量命名禁止使用拼音 - 常量使用 UPPER_SNAKE_CASE - 注释只解释业务意图不解释代码语法有了这份文档AI 生成的代码基本不用做大规模风格调整。我实测对比过没有规则文档的时候AI 写出来的代码我平均要改 20% 才能并入项目有了规则文档这个比例降到 5% 左右。效率提升是立竿见影的。3.3 把 MD 文档当作会话上下文复位器还有一个很多人没意识到的用法当你换了新会话、换了模型、甚至隔了好几天再回来继续开发时全局 MD 文档可以快速让 AI回到状态。AI 对话是没有长期记忆的新会话就是失忆。但你只要让它在第一轮先读一遍PROJECT_CONTEXT.md和CODING_RULES.md它的状态就恢复得七七八八了。我甚至会在文档头部加一段对话引导# 使用说明给 AI 的提示 请先阅读本文件再回答任何问题。本文件是项目的全局说明文档。当用户提问涉及具体代码时请先查看对应目录下的文件然后结合本文件中的业务背景进行回答。这段提示的效果很神奇AI 会表现得像一个已经入职两周、看过项目文档的开发者而不是一个每次都要从零开始猜的临时工。我自己的习惯是所有项目的全局 MD 文档都放在同一个显眼位置并且定期维护。项目有重大变更比如换了接口协议、改了目录结构我会顺手更新文档。别小看这个习惯文档越新、AI 的产出越准你后面省下的纠错时间越多。4. 提示词与工作流让 AI 按照你的节奏干活而不是你被它的节奏拖着走环境搭好了文档备齐了接下来就是 Vibe Coding 效率提升的核心区——怎么写提示词、怎么设计工作流。这两个东西决定了你是一小时的对话产出三天的工作量还是三小时的对话产出两小时的工作量。4.1 指令分层别让 AI 同时做十件事最常见的低效操作是一条消息里塞七八个要求帮我写一个用户列表页面要有搜索、分页、排序、导出还要做移动端适配样式参考 antd记得处理加载状态和错误状态。AI 一次性收到这种任务的时候它的处理方式是在一个回合里全部输出然后每个功能点都只做到了能跑的程度。你检查的时候会发现搜索逻辑没防抖、分页参数不对、导出没有 loading、移动端样式根本没适配。然后你每条再开一个对话去修来回十几次。我的做法是把任务切成阶段每个阶段只让 AI 专注一件事阶段一 新建一个用户列表页面文件先完成基础表格展示。数据从 src/api/user.ts 的 getUsers 接口获取字段参考 PROJECT_CONTEXT.md 里的数据结构。先不要加搜索和分页。等这块代码合入没问题了再进入下一个阶段阶段二 在用户列表页加上分页功能。当前代码已经可以从 getUsers 接口拿数据分页参数是 page 和 pageSize接口返回里有 total 字段。请修改相关逻辑并加上分页组件。这样看起来好像多开了几次对话但实际总时间反而少。因为每一轮 AI 的任务边界清晰产出准确率高你 review 和返工的时间大幅降低。4.2 让 AI 先讲方案再写代码这是我从一位前端朋友那里学到的习惯后来发现放在 Vibe Coding 所有的场景里都好用对于超过半小时工作量的任务不要直接让 AI 写代码先让它出方案。比如你让 AI给购物车加优惠券功能它直接写的代码大概率在接口设计上跟你对不上。但如果你先让它先不要写代码。分析当前购物车的代码结构给出一个给购物车加优惠券功能的实现方案。方案里说明1. 优惠券在页面上如何展示2. 计算价格时优惠券逻辑放在哪个模块3. 涉及哪些接口字段4. API 交互方式。列出改动涉及的文件列表。AI 给你的方案往往是结构化的。你只需要检查方案合理不合理不合理就指出这里不要改接口改成前端组装字段合理了就让它按方案执行。先方案后代码的本质是把返工的成本从修改大量代码变成修改几行文字。4.3 善用内容导向的提问方式日常写提示词的时候我总结了一个高效模板称之为四要素上下文、任务、约束条件、输出格式。上下文告诉 AI 相关的文件、模块、现有逻辑。任务说清楚具体要做什么。约束条件说清楚不能做什么必须遵守什么。输出格式说清楚代码放哪里、是否可直接运行、还是只给核心片段。举个例子低效问法是帮我优化一下这段代码太慢了高效问法是参考文件 src/utils/format.ts 中的 formatPrice 函数当前场景是商品列表页循环调用它数据量在 500 条左右。任务优化该函数的执行效率。约束不能改变函数签名和返回值格式不能引入额外依赖。输出给出优化后的完整函数并说明优化点。四要素齐全之后AI 返回的内容基本就能直接用比如直接替换format.ts中的函数即可。这也是我前面说角色变成评审者的落地方式——你不需要盯着 AI 写每个字符但你需要通过约束条件来控住它。4.4 工作流的节奏感短迭代、勤提交、多验证工具链和提示词都到位了最后拼的是工作流的节奏。我在项目里跑得最顺的节奏是这样一套循环描述一个功能小块控制在 30 分钟工作量内。AI 生成代码我读 diff有问题就地修正或重新生成。本地跑通基础流程。提交一次代码并简单注释AI 生成我 review 过。进入下一个功能小块。之所以强调小块是因为 Vibe Coding 在任务大了之后出错率非线性上升。一个半小时能完成的功能拆成三个二十分钟的小块AI 在每块的表现比直接一口气做完要稳定得多。而且小块的回滚成本也低出问题只影响一个局部不至于整体推翻。5. 实测中的坑与应对上下文污染、AI 幻觉、代码回滚任何工具用久了都会踩它的坑。Vibe Coding 的坑比传统开发多但大部分坑是有规律、可提前预防的。我挑三个影响最大、实测里反复出现的展开讲。5.1 上下文污染会话越长AI 越糊涂上下文污染是 Vibe Coding 里最隐形、也最影响效率的问题。具体表现是你在一个很长的会话里聊了几十个话题之后AI 开始把前面的信息错误地带到后面的任务里。比如你前面讨论了登录模块的 token 存储后面写订单模块时它突然又去改动 token 相关代码这就是上下文污染。我的对策很粗暴一个会话只做一件事。如果某项任务超过一个会话还在反复纠缠我就开新会话然后用全局 MD 文档快速复位状态。宁可多开几个会话也不要让 AI 在一个会话里记忆过载。另外一个实用做法是在对话中定期用遗忘指令暂时忘掉上面关于登录模块的讨论。我们现在转向订单列表页的问题请只根据订单列表页相关文件和 PROJECT_CONTEXT.md 来回答。听起来很傻但实测对模型的效果很好它能把注意力重新拉回当前任务明显减少跨任务干扰。5.2 AI 幻觉它一本正经地说谎怎么办AI 生成代码时幻觉的典型场景包括编造一个并不存在的接口名、引用一个你没安装的依赖、写一个文档里没定义的字段。最麻烦的是它可能编得很像真的——函数名、参数结构、注释都齐全只有运行你才会发现报错了。我的应对分三步第一凡是 AI 提到的未知接口都要求它给出依据。它能引用项目里的具体文件路径吗如果引用不了多半是编的。第二关键逻辑让它先解释再写。比如说这个递归的退出条件是什么这个防抖的延迟时间是多少它解释的过程中如果你发现它有含糊其辞的地方立刻停下追问他细节直到答案清晰。第三测试跑得勤快点。我通常让 AI 改完一个函数立刻写个小 demo 或者临时测试来验证输入输出。别攒着最后一起验那时候出错根本定位不了是哪一部分编出来的。5.3 代码回滚靠 Git 撤销 AI 的所有动作Vibe Coding 里最让人头疼的时刻是 AI 一次性改了十几个文件你事后发现思路错了需要全部还原。如果没有版本管理兜底这基本就是灾难。我的习惯是任何 AI 大规模改动之前先手动打一个本地 Git 提交点。然后让 AI 去改改完我再逐个文件看 diff。如果思路不对直接git checkout回退干净利落。git add . git commit -m feat: 优惠券功能开发前基准基线 git checkout -- src/pages/UserList.vue另一个实操细节是我把 AI 生成的代码和手写代码用 commit message 区分。AI 生成的就标注 AI-generated手写的是我手动提交。这样后续要排查为什么这段代码风格不对或者这段逻辑谁写的时可以直接通过 Git 记录快速定位。5.4 优先级误区AI 改的东一块西一块问题还有一个概率很高的问题就是 AI 在多文件协作时容易出现局部做完、全局没跑通的情况。处理方式是要求 AI 在动手前先输出一个改动计划标明会动哪些文件、顺序怎么安排、是否会引入新的依赖包。这样你在执行前就能看到全景而不是让它闷头改完才告诉你。6. 进阶技巧用 Vibe Coding 做不只会写函数的事到了这个阶段你已经能顺畅地用 Vibe Coding 写业务代码了。但如果只拿它写函数、写页面有点浪费。我实测过几个进阶用法效率提升比无脑生成代码高得多。6.1 批量代码重构让 AI 当重复劳动的消耗机最典型的场景是把老代码迁移到新规范。比如你有一个老模块还用的是旧的 API 封装风格现在要把它的所有接口调用切换到新封装上。这种重构如果手工做是纯重复劳动但你让 AI 做注意不要让它凭理解写而是让它严格依据规则文档来改。实践流程是把新封装和旧封装的对应关系列成一张映射表。把映射表和CODING_RULES.md一起给 AI。指定一个明确的迁移范围哪个目录、哪些文件。清理 src/services 目录下的历史 API 代码。规则参考 CODING_RULES.md 第 3 条映射关系如下 旧 API: src/api/legacy.ts 的 getOrderList 新 API: src/api/order.ts 的 fetchOrderList 请遍历 src/views/order 下所有用到旧 API 的文件完成替换并修正调用参数。一次改完先给我改动清单。AI 做完之后重点不是全信它而是它做重复替换的时候出错率比人低。你只需要检查改动清单是否覆盖完整抽查几个文件是否改得对剩下的交给它。我这种切换工作以前要消耗半天现在基本一个多小时还包括了我 review 的时间。6.2 生成测试用例把你懒得写的事情交给 AI很多业务项目测试覆盖率低不是不想写是写测试太枯燥。Vibe Coding 可以帮助把最低成本的用例生成环节自动化但前提是你得给它业务语义而不是让它凭空编。参考 src/utils/order.ts 的 buildOrderPayload 函数。请为它生成 5 个单元测试用例覆盖正常数据、金额为 0、商品列表为空、单价为负数、缺少必填字段的场景。断言尽量简单不引入额外测试库使用项目现有的测试框架。它生成的测试用例不一定全部合理但它帮你把 80% 的骨架搭好了。你要做的是补充边界值、修正错误猜测而不是从零开始写一个文件。6.3 让 AI 做代码评审我经常把 AI 当免费的 code reviewer。写完一部分代码后我会把它扔给 AI假设你是这个项目的资深开发者请对以下代码做一次评审。关注可维护性、边界条件、命名规范和隐含 bug。不要客套有问题直接说。AI 提出的意见里大约有三成是废话但另外七成里经常有我没注意到的边界问题、变量覆盖问题甚至还有对业务规则的有用质疑。作为一个低成本 Code Review 工具Vibe Coding 完全够格。6.4 让 AI 生成解释文档变相提升团队效率Vibe Coding 除了写代码还能写解释文档。我在接手一个半年没人维护的老模块时会先让 AI 把模块功能梳理成一篇简短的说明文档通读 src/modules/inventory 下的代码输出一篇 500 字以内的模块说明该模块的核心职责、主要函数和用途、数据来源和流向、常见的修改入口、以及潜在的坑比如副作用、性能问题。用中文面向刚接手这个模块的开发。接手的人包括未来的我看到这篇文档等于半天热身时间直接省掉。这个用法适合任何团队几乎零成本效果却极其明显。6.5 组合拳MD 文档加全局提示词最后我再分享一个压箱底的习惯。我在 Trae 和项目级别的配置里都留了一份全局提示词——不是给 AI 的是给我自己用的。它是一段固定格式的开发指令模板。每次开始一个新会话我先呼出这段模板替换掉具体任务描述再发给 AI你是这个项目的高级开发。请先阅读 PROJECT_CONTEXT.md 和 CODING_RULES.md。当前任务是________。在回答前如果需要知道更多细节请先向我提问。实现时请遵守 CODING_RULES.md 里的规范并在输出里标注改动了哪些文件以及为什么这样改。这段人话提示词模板配合全局 MD 文档是我实测里最能稳定保证 AI 输出质量的组合。它能保证 AI 每次开局都有充足的上下文并且在动手前先提问——这一步能提前拦住很多需求理解偏差。用心维护上下文比任何技巧都重要全套技巧跑下来我最深的体会是Vibe Coding 的效率天花板不在模型强弱而在你对上下文的管理能力。环境选对了文档写清楚了提示词结构好了它就能给出高质量产出你不管上下文再强的模型也会频繁出幺蛾子。我的工作流现在很稳定动手前更新一次全局 MD 文档任务切小块每块任务开新会话AI 改完我先 review 再合入重大的改动提前打 Git 基线。这套东西跑顺之后我一个人维护三个中小型项目的效率比以前高出一截而且代码质量没有下降Review 成本也没有失控。最后给一个具体建议如果你今天就要开始尝试 Vibe Coding先别急着追求什么高级技巧从写一份PROJECT_CONTEXT.md开始。花半小时把这个文件写清楚你的第一次 Vibe Coding 体验会立刻不一样。