最近圈子里讨论最多的开发方式绝对绕不开Vibe Coding。这个词刚火起来的时候我以为又是哪个博主造出来的概念噱头直到我在Trae Code里把一个内部小工具从零搭完又用同样的思路去改老项目里的历史bug才意识到它真正改变的是开发的发力方式。Vibe Coding简单说就是靠自然语言描述意图让AI动手写代码人在旁边控制方向和兜底验收。听起来很轻松实操起来差别特别大有人用它十分钟写了个脚本有人因为完全不设边界把项目拆得七零八落。我用这套方式写了半年多的代码踩坑足够多如果要总结Vibe Coding里什么最重要我会毫不犹豫选这三件事开发环境搭建、全局MD文档、人在回路。这三件事不是并列的三块砖而是一条链条环境不好AI发挥不出来文档不立AI记不住约定人不审AI给你挖坑。下面我把每一件事掰开讲清楚全是实操经验。1. 第一件事把开发环境理顺工具趁手才谈得上Vibe1.1 为什么着急写prompt前必须先收拾环境我见过太多人拿到AI IDE的第一天上来就敲一句“帮我把外卖系统写完”然后一脸期待地看着代码刷刷往外冒。结果十有八九会遇到这些情况代码风格混乱、目录结构看不懂、依赖库突然多了一堆没见过的。原因在哪不是AI不行是环境压根没梳理好。所谓Vibe Coding本质是让AI在你熟悉的技术语境里工作。它就像一个刚入职的实习生虽然能力很强但如果你没给它讲清楚项目用什么语言、遵循什么风格、目录怎么组织它就只能凭自己的“刻板印象”瞎写。环境搭建这一步就是给这个实习生一份靠谱的工位、一本员工手册和一条明确的工作流。我在团队里带过几个用AI写代码的同事最后发现人和人之间的效率差距根本不在“会不会问AI”而在于有没有把环境盘好。环境好的项目AI生成的代码能直接进diff review环境差的AI每次都要问东问西甚至偶尔反过来破坏现有功能。工具配置不到位后面所有舒适感都是空中楼阁。1.2 基于Trae Code的完整环境搭建路径Trae Code是我目前主力用的AI IDE类似Cursor的思路但它对国内开发者的入口更友好内置终端、diff审阅、AI对话这些基础能力都有。以下这套搭建流程换到任何AI IDE上也能照抄逻辑是通用的。第一步下载安装并初始化项目。官网下载对应平台的Trae Code装好后直接把已有项目文件夹导入或者新建一个空目录。不要急着写代码先检查左侧文件树确认项目的入口文件、配置文件都在。很多老项目会有奇怪的目录嵌套AI读不到关键文件后面很容易迷路。第二步配置模型服务。Trae Code里可以切换不同的模型我一般把主力模型放在Claude和GPT系列之间切换轻量补全用速度更快的模型。这里有个细节不要把对话模型和补全模型混为一谈。对话模型负责理解大段需求、跨文件改代码必须选推理能力强的补全模型只是给你接下半句选响应快的就行。第三步用规则文件给AI立“使用说明”。这一步特别关键。Trae Code支持在项目中放规则文件也能设置全局规则。我的做法是项目根目录放一份AGENTS.md也有人叫GLOBAL.md或CLAUDE.md名字看你用的IDE约定把项目的技术栈、目录约定、代码风格全都写进去。这样一来AI每次打开项目都会自动读到这份说明不用你反复在对话框里唠叨。第四步关掉自动应用代码改成手动审阅。Trae Code默认在某些场景下会直接帮你改文件我强烈建议把“自动应用”关掉改成每处变更都要你点接受或拒绝。自动应用一时爽事后review火葬场。AI一次性给十几个文件的改动时你根本分不清哪些是它自己抽风加的。第五步用一个小任务验证环境通不通。不要一上来就跑大需求。先在终端里跑通项目然后用一个很小的任务测试比如“在utils目录新增一个格式化日期函数”。看看AI能不能正确找到目录、遵循已有风格、不引入额外依赖。这一步通了再放大需求。1.3 关于IDE规则和快捷键的两个细节规则文件放在项目根目录而不是塞进三层深的子目录这个问题我在后面第二章会专门展开。习惯用快捷键做“接受/拒绝”的操作在diff面板里逐块审阅不要一键全部接收也不要一键全部丢掉。接受前看一眼拒绝时给AI说明原因它下一轮会改得更准。实测下来这个习惯比任何prompt技巧都管用。环境搭建完毕工具开始趁手了但这时候会遇到第二个大问题AI记不住你昨天和它讨论的决定。2. 第二件事全局MD文档给项目立一部“宪法”2.1 没有文档时AI为什么总是“失忆”我用AI写代码最崩溃的时刻不是它代码写得不对而是它转头就忘了我反复交代过的约定。比如说好这个项目不许引入ORM框架这周刚用十几行SQL写好的查询下周新开一个对话AI又给你塞进来一个数据库抽象层。原因很好理解。AI对话有上下文长度限制每次会话承载不了太多信息而且每次新开对话它都相当于一个“新同事”从头开始读项目。如果你不在对话里重新交代背景它就只知道文件夹里有什么文件不知道你隐藏的设计意图和禁忌。那怎么办总不能每次都把所有背景讲一遍。全局MD文档就是用来解决这个问题的。它相当于项目的长期记忆也可以叫项目宪法。所有重要约定、当前进展、常见命令、架构边界都写进这份文档让AI在每次启动时先读一遍。这和给新入职的同事准备一份扎实的README的逻辑完全一样只不过你的读者是AI。对比一下就明白有没有文档的差别没有文档时AI靠猜有文档时AI靠读。猜的行为不可控读的行为才可复现。2.2 一份能落地的全局MD文档应该写什么很多人听到“全局MD文档”以为就是把GitHub README复制一份丢到项目根目录。其实不行。README是给人看的项目简介全局MD文档是给AI看的“执行手册”二者完全不同。我写全局MD文档会分成四个区块# 项目全局说明 ## 1. 项目背景与技术栈 - 这个项目解决什么问题 - 使用的语言、框架、版本、包管理器 - 禁止引入的依赖/技术明确写清楚 ## 2. 目录结构与核心概念 - 主要目录的职责说明 - 项目里的关键名词和业务概念 - 已有模块之间的依赖关系 ## 3. 代码风格与架构约束 - 命名规范、文件组织方式 - 错误处理约定、日志规范 - 数据流向、状态管理方式 - 测试要求必须/不必须 ## 4. 当前任务与进行中事项 - 已完成事项清单 - 待办事项清单 - 最近一次修改的上下文这个结构不是死的但前三个区块要尽量稳定写好后不要频繁改动。第四个区块则要高频更新每次任务结束时把新信息回填进去。我见过很多人写完前三个区块就当甩手掌柜第四个区块长期不更新结果AI读完文档只能知道“项目大概什么样”不知道“现在干到哪一步”照样会迷路。再补一个原则文档要小而精别写成万言书。AI读文档是要消耗上下文token的文档越长留给真正代码的token越少。我给自己定的规矩是整个文档控制在300到500行以内只写“必须遵守”和“约定俗成”的东西不放废话和嵌套层数过深的说明。2.3 让AI真正“读进去”的三种挂载方式写了文档AI不一定每次都会读得用对挂载方式。我试过三种有效的办法按优先级排序如下。方式一通过IDE规则能力挂载。Trae Code以及其他主流AI IDE基本都支持在项目根目录识别AGENTS.md之类的规则文件也可以手动在设置里指定“始终读取项目文档”。如果你用的IDE支持这是最优解因为AI每一次交互都会携带这份文档你不用手动干预。首次搭建环境时务必把这步做掉。方式二新对话第一句话强制阅读。有些情况下规则文件没生效或者你用纯聊天界面和AI对话没办法自动挂载。那就在新对话的第一句写“先阅读项目根目录的AGENTS.md理解项目背景和约束后再开始。” 实测这句话能显著降低AI胡来的概率因为它先建立了一个上下文基座后面的代码生成都基于这个基座展开。方式三用符号手动引用特定文档段落。当任务特别具体只涉及某个模块时不需要让AI读全量全局MD文档。这时候用模块说明.md之类的方式单独引用对应文件或段落既精准又省token。我通常在优化老模块时用这个方式避免AI在无关目录里乱翻。上面就是把“失忆”变“记忆”的关键。但光有文档还不够因为AI就算记得背景依然可能写出逻辑正确但方向完全错误的东西。这就是第三件事要解决的问题了你必须有足够强的审查和边界意识。3. 第三件事人在回路Vibe Coding不是无人驾驶3.1 Vibe Coding的四种典型翻车现场很多人误以为Vibe Coding就是把需求一说然后躺着看AI干活。半年的实操经验告诉我如果你真这么干大概率会在这些地方翻车。依赖失控AI为了让一个排序功能好用顺手引了一个重量级第三方库项目包体积爆炸。修复式破坏你让它修A模块的bug它为了“保持风格统一”把B模块里正常逻辑也顺手改了测试跑完才发现出问题。API幻觉AI生成代码时调用了一个看起来特别合理的API实际上这个API根本不存在或者版本早就废弃了。安全裸奔AI生成拼接SQL、把密钥写死在代码里、没有对用户输入做校验这些问题在代码review时最容易漏掉。这些翻车现场的共同点是什么是AI在“局部正确”但在“全局方向”上失控。局部正确恰恰是最迷惑人的地方因为编译能过函数名也对只有你在真实业务里运行时才会发现它走偏了。这正是Vibe Coding最大的隐患它太容易让你放松警惕。3.2 我的验收清单三查三不查人要在回路里不是让你盯着AI的每一行输出那反而失去了Vibe的效率。我自己总结了一套“三查三不查”的验收方法。三查查diff重点看删改范围。AI有没有动到和需求无关的文件有没有删除看起来“多余”但实际在别处被引用的函数这些都要在diff里揪出来。查运行结果。所有AI生成的代码都必须在真实环境里跑一遍不能只看它自己贴的“输出示例”。有时候AI会很贴心地造一个假输出真实数据一进来就崩。查安全敏感项。凡是跟密钥、SQL、权限、文件路径、用户输入沾边的代码逐行看。AI不懂你的业务边界它可能在模型训练时学到了“把数据库连接放配置里”的对的常识也可能为了图方便直接把私钥写进常量。三不查简单的样板代码不需要逐行查。比如生成一个标准格式的JSON序列化函数这种东西出错概率极低逐行看是浪费时间。大规模重构时不要逐行看。你只需要看关键路径和对外接口是否保持一致内部实现细节可以在编译和测试里验证。AI自己写出来的单元测试不要完全相信。它倾向于用一个实现去验证另一个实现两边错在同一点测试照样绿。3.3 哪些需求适合Vibe哪些必须严格设计不是所有任务都适合把方向盘全交给AI。我用一张边界表来说明自己的判断标准。任务类型是否适合Vibe Coding理由写工具函数、脚本、样板页面适合边界清晰出错影响范围小AI能高效完成重构已有模块逻辑复杂半适合可以让AI提方案但核心改动必须人工确认涉及支付、权限、加密不适合全自动一行都错不得需要人对每一处逻辑做严密封装验证设计系统初始架构不适合架构是后期所有开发的底盘必须由人来主导我的常见做法是“Vibe 写细节人来定骨架”。拿到需求后我先自己规划模块划分和接口语义然后把这些交代给AI让它在既定的骨架上填肉。这样既能享受AI的高效又保住了系统最重要的上层结构。如果一开始就把架构问题甩给AI你可能会得到一份看起来很完整、但根本没有扩展余地的代码。4. 三件事如何协同一个完整实操复盘4.1 一个典型任务的完整链路前面三件事单独拆开讲完了但实际用的时候它们是一整套流程。我拿最近一个真实任务举例给内部后台工具新增一个导出Excel的功能。第一步打开项目根目录的全局MD文档把“当前任务”区块更新为“新增导出Excel功能使用已有excel库输出格式为.xlsx”。这一步对应的就是第二件事先给AI同步任务上下文。第二步在Trae Code里发起对话“请在utils/exporter目录下新增exporter.go实现ExportToExcel接收[][]string返回文件路径。使用项目中已有的xlsx库不新增依赖。导出逻辑参考当前目录已有代码的风格。” 这一步对应第一件事环境已经提前备好模型知道项目在哪、规则是什么。第三步AI生成代码后我先看diff。重点看三处是否真的没有新增依赖、是不是放在了指定目录、函数签名是否符合我描述的约定。确认OK后再跑一遍包含导出功能的测试用例。这一步对应第三件事。第四步功能验证通过后我回到全局MD文档把“已完成事项”追加一条同时把“当前任务”清掉。这一点特别重要很多人忽略。只有把任务结果回填到文档里AI下次才会记住这个模块现在已经有导出功能了而不是下次又给你写一个重复实现。整个过程看起来不复杂但没有前面环境、文档、审查任何一个环节下面就可能出幺蛾子。环境没配好AI可能找不到依赖在哪文档没更新AI不清楚项目里已有导出逻辑人没审可能直接引入了错误的库。4.2 日常踩坑记录与排查思路这套流程跑起来之后我还是遇到了不少反反复复的问题。我整理成了一张速查表方便排查。现象可能原因处理方式AI改A模块却弄坏B模块上下文太长文档与最新代码不同步精简上下文把稳定信息写进全局MD文档AI反复引入不同库不遵循技术栈全局MD文档里没写明“禁止引入XX库”或用哪个库在文档中明确指定技术选型禁止替代方案接受补全后生成大量垃圾代码打开了自动应用补全功能关掉自动应用改手动逐块审阅AI读不到项目根目录的规则说明规则文件层级不对或IDE未挂载放根目录检查IDE规则配置手动引用AI生成的代码总是忽略现有工具函数文档里没写明工具函数的位置在文档中汇总核心工具函数说明并标注路径排查思路总结起来就一句话先怀疑上下文再怀疑规则最后怀疑模型。大多数问题都不是模型笨而是它没有拿到足够的背景信息或者拿到的信息已经过期了。这时候不要把错误推给AI去检查自己的MD文档是不是太久没更新。4.3 三件事的协作关系与经验沉淀最后想系统说一下这三件事之间的关系。我把它们比喻成一棵树环境搭建是树干支撑整个系统稳定生长全局MD文档是根系持续给AI输送背景信息人在回路是阳光和修剪避免树长歪。没有树干的支撑文档写得再漂亮也无处安放没有根系的输送AI只能在每次对话里从头摸索没有阳光的修正树长得再快也只是疯长。三件事环环相扣少了任何一个Vibe Coding都会“翻车”。从团队协作的角度看这套三件事体系还有一个额外好处它把个人经验变成了项目资产。环境搭建的规则、全局MD文档里的约定、人的审查清单都可以随项目交付换一个人来开发依然能快速上手。这比单纯靠个人在聊天窗口里“调教AI”要可持续得多也是我坚持把这套流程固化成习惯的原因。结尾一点个人体会回头看我这段时间踩过的坑最想强调的还是开头那句话Vibe Coding不是甩手掌柜更像带着一个能力极强但没有项目经验的实习生干活。你越早把环境、文档、边界整理清楚AI的产出质量就越高你需要擦屁股的事情就越少。最后分享一个我雷打不动的小习惯每天下班前我会花十分钟更新全局MD文档的“已完成”和“待办”部分。这个动作看着不起眼但第二天再开对话时AI的状态衔接几乎完美不需要我复述昨天的背景。这十分钟的投入产出比是我在Vibe Coding这条路上做的最划算的一笔投资。希望这三件事对你有用也欢迎你在实际项目里调整出适合自己团队的那套打法。