2026年9月vibe coding这个词已经火了一年半。作为一个从2025年春天就开始用AI写代码的人我完整经历了“一段代码激动半天”到“AI写的代码我改到崩溃”再到“终于摸清怎么用才算顺”三个阶段。这篇文章不是AI功能介绍也不做工具PK而是把我这一年多实际用vibe coding写业务、做个人项目的经验沉淀下来重点聊聊现在的主力环境Trae Code的搭建思路以及一个大部分人都没用好、但真正决定vibe coding体验的东西——全局MD文档。如果你已经受够了“AI生成的代码能跑但不能改”或者正准备把vibe coding从玩具项目搬到正经工作流里下面的内容应该能帮你少走不少弯路。1. Vibe Coding一年半从玄学编程到氛围工程1.1 我记忆里的两种vibe coding这个词刚火起来的时候主流定义非常浪漫沉浸在自己的节奏里顺着感觉给AI下指令让它把代码写完你只需要享受那股“它懂我”的氛围。第一批尝鲜的人大多带着赌一把的心态对着终端一顿输出AI噼里啪啦生成几百行跑通了就欢呼跑不通就换个prompt再来一次。我也有过那段完全凭感觉的时期写小脚本确实爽但一旦放进正经项目里问题立刻暴露没有类型定义、没有错误处理、没有注释连变量命名都像抽盲盒。后来我又滑向另一个极端——什么代码都丢给AI然后我全程跟在后面修它犯的错。一个表结构它能改出五种风格一个API错误处理它有时候抛异常有时候返回null改到后半夜我盯着屏幕只想把网线拔了。这两种状态其实都不算健康的vibe coding前者是真正的“玄学编程”后者更惨属于“AI挖坑我来填”。1.2 现在的正确姿势约束内的快速生成到了2026年AI IDE和模型能力已经比两年前成熟太多大多数人的问题不再是“AI写不出来”而是“AI写的代码能不能被维护”。这一年半我最大的认知变化是vibe coding的重心不再是“让AI自由发挥”而是“在一个清晰约束框架里让AI高速输出”。约束来自三样东西项目上下文、验收标准、代码风格规范。这三样东西如果只在对话窗口里反复口述是没法稳定生效的。因为每个新会话AI都会失忆你上轮说的业务背景、技术约定、踩坑记录它下轮一个字都不记得。这也是为什么我后来把所有上下文都固化成了文件——文件不会忘文件会被每次新会话自动读进去。说白了vibe coding的“氛围”是设计出来的不是碰运气碰出来的。2. Trae Code开发环境搭建我在2026年的标配2.1 我的本机基础环境清单先说硬件。我的机器是16GB内存加SSD这个配置在2026年属于AI IDE的入门偏上水平主要是因为同时要跑IDE、本地代码索引、偶尔还要挂一个小规模本地模型做补全内存低于16GB会明显卡顿。如果只是纯云端模型对话8GB也能跑但体验会差不少。软件层面我目前主力是Trae Code。选择它核心是三点一是规则文件支持比较灵活项目上下文能自动加载二是对话面板和编辑器融合得很好AI生成代码可以直接逐段接受或拒绝三是内置的终端和Git操作流程比较顺手符合我“让AI改完必须过diff”的习惯。项目统一用Git做版本管理所有AI产生的变更都先进分支review通过再合入主分支这是我给自己定的硬规矩。2.2 模型选择主模型和备份模型干活分工很多人喜欢在一个工具里接七八个模型我的建议是别这么干。模型多了以后最大的麻烦不是选哪个而是不同模型对项目的理解方式和代码风格完全不一样。同一个需求上午A模型给你写一套实现下午B模型接手之后说“这代码冗余我给你重写”结果整得你每次会话都要重新解释上下文。我的方案是固定一主一备。简单补全、短函数生成用本地小模型响应快、不烧云端额度隐私也相对可控复杂架构设计、跨文件重构、整个模块生成用云端大模型上下文窗口长能一次把GLOBAL.md完整读进去。我会同时开两个对话面板左边那个当“架构顾问”聊方案右边那个当“代码打字员”落实现。主模型挂了或者网络限流才切到备用模型避免工作流中断。2.3 项目级配置规则文件、斜杠命令、Git集成Trae Code这类AI IDE现在已经普遍支持项目根目录放规则文件比如AGENTS.md或者在.trae/rules目录里放一套规则。我会在项目里放一个精简版项目说明让AI每次进入项目都自动载入。配置里固定几件事技术栈、目录约定、编码风格、禁止事项、测试要求。比如我习惯在规则文件里写“所有函数必须有类型注解”“禁止循环内查数据库”“错误信息必须包含上下文”这些硬约束比在对话里反复提醒有效得多。斜杠命令我配了三个最常用的/review让AI自己审查当前改动并列出问题/test让AI补测试并运行/fix专门给它自己上次搞砸的问题用的。这些命令本质上就是把固定流程沉淀成模板减少每次打的字。Git集成我设了“提交前必须跑测试”“AI每次改动自动生成diff摘要”两条这样我做code review的时候不用自己去翻Git log猜它干了什么。这里有第一个值得注意的坑不要一开始就追求大而全的配置。我见过同事把规则文件写了几百行结果AI每次读规则就占了大半上下文反而没精力写代码。规则文件应该像电梯演讲短、准、有力后续再根据项目情况慢慢增补。3. 全局MD文档让AI在每个会话里保持人设3.1 为什么必须搞一个全局MD文档刚开始用vibe coding的人最容易忽略的就是上下文记忆。你以为上次和AI聊了四十轮它应该对整个项目了如指掌结果第二天你一打开新会话它连你项目是做什么的都要问一遍。这本质上是会话记忆的局限性它记得住你上一轮聊什么但记不住你上个月的所有决定。全局MD文档就是从这里切入的。你可以把它理解成给AI准备的“入职手册”每次新会话开始它先读一遍相当于AI第一天上班就有人把公司历史、业务流程、代码规范、已知雷区全部交代清楚。这样做最大的好处是把记忆从模型内部抽离出来放进一个你能控制、能审查、能版本管理的文件里。模型会更新、会话会丢但GLOBAL.md一直在。3.2 一份可以直接抄的全局MD模板下面是我在实际项目里用过很多次的模板结构你可以按需裁剪# 项目全局说明 ## 一句话简介 用一句话说明这个项目做什么限定受众是第一次接触的新人。 ## 核心业务场景 - 谁在用这个系统 - 解决什么问题 - 核心业务规则有哪些 ## 技术栈 - 后端Python 3.12 FastAPI - 前端原生HTML JavaScript无框架 - 数据库SQLite使用连接池 - 部署Docker Compose ## 目录结构 - src/主代码 - src/models/数据模型 - src/routes/API路由 - tests/测试目录 ## 编码风格 - 所有函数必须有类型注解 - 注释用中文说明意图而不是复述代码 - 禁止循环内查询数据库 - 错误信息必须包含上下文参数 ## API契约 - 统一返回格式{code: 0, data: ..., message: } - 鉴权方式所有接口需要在Header带X-Token ## 已知坑 - SQLite并发写入会报database is locked必须走连接池 - 前端删除按钮必须用事件委托绑定不能直接绑动态子元素 ## 当前任务 - 进行中的需求需求看板的状态流转优化 - 进行中的分支feature/kanban-transition ## 禁止事项 - 不要引入未讨论过的新依赖 - 不要改变既有接口的返回结构 - 不要在生成代码后直接提交必须经过人工review ## 变更记录 - 2026-09-01增加状态流转的事务控制 - 2026-08-28移除了旧版的权限中间件3.3 全局MD文档的迭代经验我的习惯是拆成两个文件GLOBAL.md放高频信息每次会话都要读DECISIONS.md放低频旧闻记录那些已经不影响当前开发的历史决策。这样GLOBAL.md始终保持精简AI读起来不费劲也不会被成堆的历史淹没。每次AI犯错以后我都会立刻把错误类型写进“已知坑”。比如最开始AI反复在SQLite并发写入上翻车我把“必须走连接池”写进去之后后面所有会话都不再犯这个错。这其实就是把AI当成一个会成长但需要你提示的组员你每验收一次它就更懂这个项目一点。维护频率上我要求自己“今天AI产生新决定今天就必须更新”拖到明天基本就忘了。项目开发到中期GLOBAL.md大概会稳定在150到300行之间超过500行就该考虑把“API契约”之类的大块内容拆到独立文档里只留链接。4. 从“生成”到“交付”我是怎么验收AI写的代码4.1 先让AI交方案再让它写实现我发现很多人让AI写代码是一句话就让它冲“帮我实现一个下单功能。”这种prompt出来的东西大概率是AI按照自己想象中的需求写和你真正想要的差着十万八千里。我现在的习惯是增加一次“方案确认”环节先让AI输出三样东西第一是实现思路第二是风险点第三是验收清单。确认没问题了再让它动手写。所谓的验收清单就是让AI自己定义“什么状态算做完”。比如我让它做一个状态流转接口它给出的清单可能是创建需求成功的响应码、状态非法时返回的错误、并发流转时是否覆盖旧状态。这些清单看起来简单但能逼着AI在写代码前就把边界想清楚而不是边写边编。一个我实际用过的prompt是请先不要写代码。阅读项目根目录的GLOBAL.md然后告诉我 1. 你打算怎么实现需求看板的状态流转功能 2. 你预计会遇到哪些边界情况和风险点 3. 你会用什么测试手段来验证这个功能 注意在确认之前请不要生成任何代码文件。这一步把主动权从AI手里拿回来了。方案不对顶多是文档讨论不用改代码。4.2 三层检查能跑、能改、能埋对我review AI代码时不会逐行盯那样效率太低。我按三个层次过第一层是“能跑”测试能不能过手动点一圈有没有明显崩第二层是“能改”代码结构是否清晰依赖方向是否是单向的变量命名是否表意第三层是“能埋对”错误处理是否在正确的边界层性能是否符合预期会不会留下坑给后面接手的自己。这层检查行为用表格整理就是检查层核心问题我常用的方法能跑功能是否符合预期测试是否通过运行单元测试 手动走一遍核心流程能改代码是否好维护依赖是否清晰检查函数是否过大、全局变量是否泛滥、模块划分是否合理能埋对是否在正确位置处理异常是否留下性能隐患重点看外部I/O逻辑、循环内查询、异常吞掉的地方大部分AI生成代码的问题卡在第三层。它特别擅长“把异常吞掉然后返回null”看起来程序不崩实际上一出问题就是莫名其妙的白屏。我现在的规则文件里明确写了“禁止空catch块”“错误信息必须带上下文”就是从这些实际review里沉淀出来的。4.3 把AI代码人味化重构不是洁癖AI写出来的代码有个通病逻辑全挤在一个大函数里一口气写300行中间没有抽象、没有分层能跑但没法看。这种情况下我不会让它一直生成新版本因为在错误的抽象层级上修修补补只会越修越乱。我的做法是先让项目稳定跑起来再集中做一次重构。重构也会用AI但会明确告诉它目标。比如“把handleCreateOrder这个函数拆成校验、价格计算、落库三个小函数保持现有接口行为不变不要改任何返回结构。”这类prompt比“帮我重构一下这个代码”有效得多因为它限制了AI的创造范围不会顺手把命名风格也改了更不会把好端端能跑的代码改出回归bug。重构完成之后必须跑一遍完整测试。AI对“保持行为不变”的理解不够稳定偶尔会自作主张优化掉它觉得“没用”的逻辑而这部分逻辑可能正好是某个业务要求的。5. 实战复盘用Vibe Coding做一个内部需求看板5.1 需求范围与选型为了写这篇心得我特意在9月初把一个真实的内部工具项目整个用vibe coding重新做了一遍验证现在的流程是否还经得住考验。项目是一个五人小团队的需求看板功能包括创建需求、状态流转、备注、按标签筛选、简单统计。技术栈选的是FastAPI SQLite 原生JavaScript没有上任何重前端框架。选这个组合是有意的。FastAPI的自动文档和类型提示对AI很友好SQLite适合小团队并发不高的场景原生JS则能考验AI处理DOM细节的能力。整个项目代码量不算大但覆盖面很全适合用来复盘典型流程。5.2 完整prompt链我按什么顺序让AI干活整个项目我拆成了四个阶段每个阶段都基于上一阶段的产出继续推进。第一阶段是读全局文档和建表结构。我开的第一个会话prompt是请先阅读项目根目录GLOBAL.md。这是一个需求看板项目请根据业务场景设计数据库表结构包括字段、索引、状态枚举。先输出建表DDL不要写业务代码等确认后再继续。第二阶段是创建数据模型和API。这里我会把建表DDL和接口清单一次性发给AI要求它按GLOBAL.md里的API契约来写。第三阶段是前端页面prompt里明确要求“用原生JS实现列表渲染和状态流转按钮避免使用框架注意事件绑定方式”。第四阶段是联调和修复我作为“验收员”逐项核对功能发现问题直接丢给AI修。5.3 三个典型的翻车点以及我怎么解决的第一个翻车点是状态流转的并发问题。AI最开始实现“将需求从未开始改为进行中”时直接用一条update语句更新状态没有校验当前状态。两个人同时操作时后写覆盖前写完全丢失了中间状态。我让AI修复时特意要求加乐观锁控制同时把“状态流转必须走事务”写进了GLOBAL.md的已知坑。第二个翻车点是SQLite并发连接。项目上线给团队试用后几个人同时提需求立刻出现了database is locked错误。AI第一次给出的修复是加大timeout参数治标不治本。我让它排查连接池配置后才真正解决。这个坑很有意思AI在单用户环境下怎么测都测不出来只有真实多人并发才会暴露属于典型的需要人工介入判断的场景。第三个翻车点在前端。动态渲染出来的删除按钮直接绑定的click在第一次渲染后失效。AI连着修了好几次始终在事件重复绑定和绑定失效之间来回跳。后来我提示它用事件委托一次就解决了。这个问题的本质是AI对DOM生命周期理解不够细单看局部代码没问题但放到整个页面的渲染时序里就成了bug。5.4 最终数据和感受整个项目AI生成了约3000行代码我人工补充和修改的部分大约200行主要是边界情况的错误处理、几个性能优化点、以及一些样式细节。从零到可演示版本用了一个下午到验收通过总共花了两天其中大部分时间用在我review和调边界上。如果完全手写这个项目我估计要三天到四天。提速是实打实的但没有网上吹的“十倍数”那么玄乎。更重要的收获是那个看板到现在还在团队里正常用着没有出现需要推翻重来的技术债。这和我把上下文固化进GLOBAL.md有很大关系——每次开新会话AI都知道前端用了事件委托都知道SQLite要走连接池都知道状态流转要加乐观锁它就不再重复犯错。6. 我会主动关闭vibe coding的场景6.1 高风险代码权限、支付、加密不走全自动vibe coding再好用我也给自己画了一条明确的线权限校验、支付流程、加密逻辑、审计日志这类代码AI可以出参考实现但最终版本必须经过严格人工review。原因很简单这些场景的错误代价太高一个AI自信满满的“看起来没问题”逻辑可能在某个极端情况下绕过鉴权或者把敏感数据打出来。这类代码的问题不是AI写不出来而是AI的幻觉很隐蔽。它可能调了一个不存在的方法甚至引用了一个根本不存在但名字很合理的第三方库单测全绿灰度一跑就炸。所以在这些领域我宁可慢一点也不让vibe coding全流程接管。6.2 性能敏感路径AI的复杂度意识很差AI生成代码时对性能的直觉非常差。它倾向于写出最简单直白的逻辑比如循环内查数据库、反复创建对象、全表扫描之后在内存里过滤。小数据量还好一旦数据量上来就是灾难。我遇到过一个典型问题AI实现了一个排行榜聚合逻辑数据量只有几千条的时候响应时间70毫秒完全看不出来问题。等团队把历史数据全部导入后接口直接超时。原因是它在一个循环里对每个用户单独查了一次统计数据N1查询几千条数据就变成几千次查询。后来我人工介入改成一次分组聚合查询响应降到几十毫秒。这个案例后来也被我写进了规则文件禁止循环内查询数据库。6.3 存量复杂系统的重建要谨慎如果一个老项目有大量的历史包袱比如十年前的PHP改成了今天的Python中间经历了好几任开发之手我基本不会让AI去做大面积的“重构建议”。因为这类系统的很多代码之所以长那样是为了兼容某些埋得很深的历史约束AI只看到局部代码根本不知道背后有多少隐藏依赖。它给出的“优化方案”往往局部合理、整体翻车。在这些系统上我倾向于让vibe coding做增量需求而不是动存量。比如加一个导出功能、加一个日志查询接口这类独立边界清晰的需求AI能做得很好但“把这个老模块彻底重构一遍”模型能力再强我也不放心。6.4 幻觉最常见的那几副面孔把这一年多遇到的AI幻觉整理成了一张表供你对照排查幻觉类型表现应对方式假API调用了不存在的库函数运行时报错锁定依赖版本开启类型检查假依赖引入不存在的三方包在规则里写“禁止引入未经确认的新依赖”假测试断言了并不存在的逻辑强制跑单测抽查关键断言的正确性假注释注释写得很合理但代码没做那件事review时对照注释检查重点代码路径过度设计为了“灵活”加了一堆用不上的抽象层方案阶段就要求AI说明每一层抽象的理由7. 给2026年还在犹豫要不要用vibe coding的人几句实话如果你现在还是完全不用AI写代码我觉得没必要再坚持了但如果你还在用“让它自由发挥”的老方式我会建议尽快换到我现在这套流程上来。三个新手最值得养成的习惯第一先做小项目脚本或工具把规则文件、验收流程玩明白再上正式项目第二一切上下文以文件为准不要依赖对话记忆第三永远开着Git分支让AI随便造反正可以回滚。我在实际操作中还有一个很小的习惯每天收工前花十分钟更新GLOBAL.md。不管今天AI做了什么关键决定还是我发现了什么坑通通记进去。第二天新会话一开AI自动读到这些内容我就省了重新解释的时间而它犯错的概率也明显低了一截。vibe coding变得靠谱从来不是因为模型变多强而是因为人学会了怎么管理模型的上下文和产出。这大概就是“氛围编程”真正成熟的样子。