说句实话我到现在还记得 Vibe Coding 这个词刚火起来的那阵子。2025年初AI 编程从帮你补全函数直接跳到了你用大白话描述需求它当场给你把整个功能写完。前一阵圈子里铺天盖地都是我不用手写代码了需求丢进去产品直接能跑了。可真等这股热潮烧了几个月情况开始不对劲AI 生成的代码越堆越多能跑通的功能越来越少一改需求就到处崩没人敢说自己完全看懂那几千行是 AI 写的还是自己写的。于是有人开始喊Vibe Coding 已经死了。这句话有点标题党但确实戳中了一个真实的拐点。Vibe Coding 的原始模式——随缘描述、随缘出码、随缘提交——在小型原型项目上非常爽一旦进入需要维护、需要协作、需要稳定交付的真实项目就撑不住了。它的问题不是 AI 不行而是人的参与方式不对。我在 Cursor、Copilot、Trae Code 这些工具里折腾了大半年最终形成了一套和以前完全不同的工作习惯不再让 AI 当自动写码机而是让它当一个有完整上下文、有验收标准、有执行边界的工程师我也不再随缘写提示词而是先维护好一份全局的 MD 文档把它变成项目组的共同记忆。这篇文章就把这套打法完整拆给你看包括它为什么有效、全局 MD 文档怎么写、在 Trae Code 里怎么落地、以及我踩过的一堆坑。1. 先聊清楚Vibe Coding 到底是怎么死的1.1 它火起来的原因Vibe Coding 这个词火起来靠的是它第一次真正消解了编程语言这个门槛。以前你要做一个网页、一个小工具必须懂 JavaScript、懂框架、懂部署现在你只要会描述我想做一个待办清单左边是任务列表右边是详情数据存在本地方便一点。AI 几秒钟就给你铺好页面、写好交互、连上存储。这种体验的冲击力太大了它让很多非程序员第一次觉得我也能写软件。在我自己体验下来Vibe Coding 用来做原型验证是真的快。我以前搭一个带后端、带数据库的演示项目最快也得一个周末。用 Vibe Coding 的状态一个晚上能出两版还能顺便换了三种 UI 风格。那种想法到屏幕几乎零延迟的感觉确实会让人上瘾。它解决的问题是真实的对于探索阶段的代码效率和试错成本比条理性重要得多。1.2 翻车的三个典型场景但爽撑不起工程。我在三个月内连续摔进了三个一模一样的坑相信很多人也经历过。第一个坑是修不完的 Bug 螺旋。AI 给功能加了个新参数结果另一个地方的调用没改报错以后你把错误贴回去它又改了一个地方结果引出两个新错误。来回拉锯十几轮最终你发现改动已经面目全非AI 自己也忘了它改过什么。这种状态下整个项目变成了一堆没有逻辑链条的代码碎片。第二个坑是没人能接手的遗产代码。AI 生成的代码在你自己的上下文里好像还能解释可一旦你隔一周再打开或者交给同事代码为什么要这样写、哪个函数是被 AI 补出来的、哪些逻辑是硬编码的全是黑盒。一个不能被人理解的代码库本质上和丢失源码没有区别。第三个坑是上下文过期。Vibe Coding 起步阶段你很少写文档所有上下文都靠聊天记录。可聊天记录不会随代码更新昨天说好的技术方案今天改了三次需求AI 每次回答都基于过期的记忆。到后面你会发现它每次在你指出的错误边上编一个新方案越编越离谱。这三个问题本质上是同一个问题Vibe Coding 把写代码变成了廉价动作却把想清楚代码该满足什么这个核心工作扔在了一边。你可以让 AI 帮你打字但你没有让 AI 帮你思考——因为你自己也没思考。所以它死掉的不是工具而是这种不设边界的协作方式。2. 替代方案不是不用 AI而是换了工作模式2.1 从随缘出码转向规格驱动我现在用的这套模式没找到特别统一的名词你可以叫它规格驱动开发也可以叫文档驱动开发。核心思路特别简单让 AI 写代码之前先把代码要满足什么这件事用文字固定下来而且是写在项目里的正式文档不是写在聊天框里。所谓规格落到实操就是三样东西需求描述、验收标准、技术约束。需求描述说明要做什么验收标准说明做成什么样算完技术约束说明不许用什么、必须用什么。以前这三样东西都藏在开发者脑子里写代码的时候随机释放。现在我把它们显式地写进全局上下文AI 每做一件事都要先对着这个上下文来回答。举个例子我让 AI 加一个用户上传头像功能。Vibe Coding 的写法是帮我加头像上传功能图片剪一下存到服务器。结果它可能用了 base64 塞进数据库也可能原地起了一个本地存储服务反正能跑但架构上完全是灾难。规格驱动的写法是在需求文档里先写清楚——用户上传头像后前端需压缩到 200KB 以下后端接收 multipart 格式图片存储在对象存储的 avatars 目录保存后返回 CDN 地址原图不落库。然后让 AI 按这份文档执行。同样是让 AI 干活后者基本不会跑偏。这套模式适应的项目不只是大型企业系统。哪怕一个个人项目只要你还打算维护它超过一星期就值得写规格。因为那个一星期后再打开代码的人就是没有你的记忆的另一个平行宇宙的你规格文档就是传递记忆的唯一通道。2.2 AI 的角色重新定位从神谕到实习工程师另一个关键转变是我对 AI 身份的看法。Vibe Coding 心态下很多人把 AI 当神谕——描述需求之后期待它一次性给出完美答案。一旦出现错误就陷入不断的贴报错—生成补丁—报新错循环像一个在赌场反复下注的赌徒。问题在于神谕不需要上下文但 AI 不是神谕它是一个对项目一无所知、但学习能力极强的实习工程师。你想想你会怎么带一个实习生你不会上来就让他独立重构整个模块而是先给他一份 README、一次项目导览、一条明确的验收标准然后让他从一个小任务做起做完你 review发现理解偏差就纠正同时把纠正后的认知写回文档形成下一次工作的基础。这套流程放在 AI 身上完全成立甚至效果更好。把 AI 当实习工程师之后我的行为模式发生了三个具体变化第一每次让它做事之前我会先想清楚这次任务的边界而不是甩一句话过去第二它给出的代码我必看但看的目的不是逐行审查而是校验它有没有偏离规格第三它每次做完一个阶段性任务我会要求它把关键决策写进项目文档。这三个变化让我从运维一个自动生成器变成了管理一个团队。3. 全局 MD 文档让 AI 和你的记忆同步3.1 为什么需要全局上下文文档用过 AI 编程工具的人一定都体验过上下文丢失的挫败感昨天明明跟它敲定了方案今天新开一个对话它就什么都不记得了甚至在同一个对话里聊到第 40 轮以后它开始逐渐忘记刚才自己说过什么。AI 的对话窗口是有限的但你项目的复杂度是无限的。用聊天记录的规模去对抗项目的复杂性注定输。全局 MD 文档解决的就是这个记忆问题。我把它理解为项目的外置大脑一个放在仓库里、所有 AI 工具都能读取的 Markdown 文件相当于给 AI 注入了一管疫苗让它不需要靠猜或者靠聊天记录来理解项目而是直接读取一份结构化、常更新的全局说明。它同时解决三个问题跨会话记忆、跨工具记忆、以及跨人协作时的信息同步。第一次感受到这套方法论的价值是我用一个周末让 AI 帮我重构一个老项目。以前这种重构我根本不敢交给 AI因为旧代码里的业务分支太多AI 会在第五步突然把某个接口的返回结构改了然后全链路崩溃。那次我把项目背景、模块划分、依赖关系、哪些模块绝对不能动全部写进全局文档然后在文档约定下让 AI 一小步一小步地改。结果非常意外两天的重构仅有的三次报错都集中在文档里没写清楚的部分。从那以后全局 MD 文档就成了我所有 AI 项目的标配。3.2 一份可落地的文档模板全局文档我建议按固定结构维护不要想到什么写什么。下面是我现在常用的模板你可以直接抄走按项目情况增删。# 项目全局上下文 ## 1. 项目一句话目标 一句话说明这个项目要解决什么问题。 ## 2. 技术栈与版本 列出核心依赖、版本号、运行环境要求。 禁止引入未列出的框架。 ## 3. 架构与目录说明 - 根目录下每个文件夹的职责 - 核心模块的调用关系 - 数据流向说明 ## 4. 核心业务规则 把最容易让 AI 犯错、或者重构时最容易破坏的功能细节写死。 例如订单状态机的流转不允许跳级、所有对外接口必须做参数校验。 ## 5. 编码规范 - 命名规范 - 代码风格 - 必须使用的工具链 - 不允许使用的反模式 ## 6. 已知的大坑 记录已经踩过、AI 下次可能还会再犯的错误。 ## 7. 变更记录 每次重大决策、任务完成后回写旧的决策保留但标记失效。有几个位置非常重要但容易被忽视。一是禁止事项必须单独列段AI 对允许的指令执行得非常好但对默许但不提倡的理解经常跑偏你写明白禁止用 any 绕过类型报错它就真的不会用。二是核心业务规则要有场景感和上下文别只写订单状态不能乱跳而要写清楚为什么——因为财务对账依赖这个顺序。AI 一旦理解原因遇到边界场景时它的决策准确率会高很多。三是文件目录说明一定要写清楚每个文件夹负责什么AI 才能正确判断新代码应该放哪而不是每次都新建一个乱七八糟的目录。3.3 什么时候更新文档文档最怕的是写完就长眠。但我也不想给你一个负担过重的更新仪式那样坚持不下来。我的经验是三个时机必须更新完成一个阶段性功能时。让 AI 把关键实现决策回写到文档否则下周它自己都不认识自己的代码。踩了一个大坑并修复后。写进已知的大坑等于把这个教训复制给了未来所有会话。架构级决策变化时。这是最高优先级因为架构变了而文档没变等于让 AI 拿着旧地图开新车。我自己会刻意要求 AI 在完成每个任务后如果涉及上述内容就在文档里追加一段更新说明并提交。这让文档保持和代码同步演化而不是一个僵硬的快照。4. 在 Trae Code 里搭建可复用的开发环境4.1 项目规则文件与全局上下文配置Trae Code字节跳动出的 AI IDE最近热度很高我也是从它早期的状态一路用过来的。它对全局上下文的落地方案值得单独说一下。它的机制是项目级规则文件和全局规则文件规则文件会被 AI 作为每次对话的默认上下文加载。我目前的配置是.trae/rules/ ├── global_rules.md # 所有项目通用语言、代码风格、提交规范 └── project_rules.md # 当前项目专属技术栈、业务规则、大坑清单global_rules 我放的是跨项目不变的约定比如默认使用中文交流函数必须写 JSDoc 注释禁止使用 any 类型提交信息遵循 Conventional Commits。project_rules 则放当前项目的核心上下文对应我上面说的全局 MD 模板中的第 2 到第 6 段。有一个配置细节容易踩坑Trae 的规则文件不一定自动加载到长对话的后续轮次里尤其是当对话特别长的时候AI 会默认沿用最近几轮的语境老规则文件信息被丢在后面。解决办法是在关键任务开始时直接点名要求请先重新阅读 .trae/rules/project_rules.md再开始你的工作。别嫌这句话啰嗦实测非常管用。4.2 工作流设计从任务卡片到验收有了规则文件下一步是搭一个可复用的任务工作流。我现在每个 AI 功能开发都走五步流程第一步写任务卡片。在项目下建一个 tasks 目录每个任务一个 MD 文件内容包括任务目标、验收标准、关联文件列表、禁止改动范围。哪怕只有五行的任务也写清楚。第二步让 AI 读任务卡片并输出执行计划。注意这里不要让它直接改代码而是让它先说明准备改哪些文件、影响哪些模块、怎么验证结果。这一步看它计划对不对不对就先纠偏成本最低。第三步AI 按计划实现。在这个阶段我会把模型切到带工具调用的 Agent 模式让它能自己跑测试、查日志、修复小问题。第四步代码审查。我用 AI 审自己的代码也审它的代码。最粗暴但有效的做法是让它生成完代码后自己再读一遍列出它认为最可能出问题的两个点。它往往能指出刚才自己写错的地方。第五步回写文档。按照更新时机把变更记录、新坑、决策追加到全局 MD。这套流程看起来比 Vibe Coding 多了很多环节但你真正跑起来会发现总时间反而更短因为省去了大量的错误循环与返工时间。4.3 模型选择与上下文管理的实战细节Trae Code 这类工具通常都支持多模型切换。我个人的经验是规划阶段用好推理模型执行阶段用更快的模型复杂重构用上下文窗口更大的模型。不要指望一个模型所有场景通吃。上下文管理是我认为最影响成败的细节。两个建议。一是回合数控制同一个任务对话超过 40 轮如果还没收敛不要继续贴错误硬刚干脆让 AI 把当前改动提交到一个临时分支开一个新对话加载全局文档描述清楚现状和待解决问题重新开始。二是代码库索引Trae 有代码索引机制但索引可能过期。改了目录结构或新增模块后如果 AI 开始胡猜文件路径先刷新索引再对话。5. 常见问题与排查实录5.1 高频问题速查表我把自己和周围朋友从 Vibe Coding 转到文档驱动模式后遇到的高频问题整理成了一张表按症状—原因—对策的格式写症状常见原因对策AI 改了 A 模块导致 B 模块报错上下文没覆盖模块间依赖关系在全局文档目录说明里补充依赖关系并在任务卡片中标注禁止改动范围同一个功能每次生成的代码风格完全不同缺少编码规范或规范未加载把编码规范放到全局规则文件并确认规则被实际引用AI 反复用同一个错误方案上下文被旧聊天记录污染开新对话重新加载全局文档只贴当前报错新需求导致老功能行为变化没有回写业务规则每次完成后把最终行为更新到核心业务规则文档写了 AI 仍不遵守文档太长关键信息被稀释把禁止事项放在文档前部并在任务卡片里再次显式引用这张表的共同底层逻辑是AI 的表现直接反映你提供给它的上下文质量。上下文质量高它的稳定性和准确度就能到工程可用的水平上下文质量低它就退回随机生成器的状态。5.2 一个真实翻车案例分享一个我印象很深的翻车案例。有次我做一个数据看板项目AI 连续帮我实现了三个图表组件都挺顺利。然后我让它加了导出 Excel功能对话里只顺手提了一句顺便把图表标题改成固定格式。结果它把三个图表组件的标题逻辑全改了还改坏了两个接口。当时的项目全局文档里有技术栈但没有写图表标题由后端配置返回这条业务规则。AI 以为它是前端写死的那自然就顺手改了。这件事给我最大的教训是不要相信 AI 会顺便理解那些你没写出来的约定。在一个好的协作模式下业务规则要么落到文档里要么在任务开始前明确声明两者都没有那就别怪 AI 自由发挥。那次之后我要求每一次对话里任务卡片必须写着不得修改以下文件或逻辑效果立竿见影。6. 最后分享几条值得直接抄走的经验先说心态层面的。Vibe Coding 没有真正消失它只是退回到了它该在的位置适合做原型验证、学习探索、一次性脚本。而作为替代品出现的这套规格驱动 全局文档的协作方式并不神奇它的本质是把你过去依赖经验和记忆的管理动作显式化为 AI 可读取、可执行、可校验的文档。如果你现在正准备开始一个新项目我给三条具体建议。第一条动手写代码前哪怕只花十分钟先写一个够用的全局 MD 文档包含技术栈、目录规划、三条禁止事项然后让 AI 永远以它为起点。第二条每完成一个任务强迫自己花两分钟让 AI 回写变更记录这个习惯会在两周后体现出巨大价值。第三条如果你的项目已经积累了大量Vibe Coding 式遗产代码不要一次性交给 AI 重构先写文档、再圈定范围、小步提交你会发现那些代码里藏着的坑在文档里记得越清楚重构就越安全。我个人最大的体会是AI 编程工具这一波进化真正改变的不是写代码这个动作而是表达需求这件事。凡是能把自己的需求、约束、边界讲清楚的人AI 就是十倍效率的放大器凡是讲不清楚的AI 只会把混乱也放得更大。所以别问Vibe Coding 死了之后用什么要问我有没有真的把要什么想清楚。想清楚之后配上全局 MD 文档和一套老老实实的工作流你会发现过去的AI 不靠谱有一大半其实是人没把话说清。