说句实话，我到现在还记得 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 不靠谱"，有一大半其实是"人没把话说清"。
