Vibe Coding：真正的核心不是写代码，而是管理 AI 的记忆

[aru_91]

未来最强的开发者，不是写代码最快的人

而是最会管理 AI 记忆的人

最近很火的一个GitHub项目: https://github.com/2025Emma/vibe-coding-cn 以肉眼可见的速度在涨star,

从这面学到了很多应用到实战里的技巧, 受益匪浅, 写下这篇精简版的文章, 帮助更多人入门Vibe Coding.

[aru_47]

很多人第一次听到 Vibe Coding，会以为它的意思是：

“把需求告诉 AI，让它自动把项目做出来。”

这句话只对了一半。

如果你真的这样干，通常会发生三件事：

第一天很爽，AI 写得飞快；
第三天开始变乱，代码到处重复；
第七天你已经不敢改，因为一改就崩。

所以，真正的 Vibe Coding，从来不是“放任 AI 自由发挥”，而是：

先把上下文固定住，再让 AI 一步一步干活。

而这个“固定上下文”的核心装置，就是 Memory Bank。README 反复强调，Vibe Coding 是一种“规划驱动 + 模块化 + 上下文固定 + AI 执行”的流程，核心目的是避免 AI 把代码库写成无法维护的一团乱麻。

一、先说结论：Vibe Coding 到底是什么？

我把它翻译成一句最容易懂的话：

你不再直接管理代码，你开始管理 AI 的上下文、规则和开发节奏。

你要做的不是一句“帮我做个 App”，而是先准备好：

• 你到底要做什么

• 你不用做什么

• 技术栈是什么

• 开发顺序是什么

• 每一步怎么验收

• 项目当前进展到哪

• 现有架构长什么样

这些东西，在这个方法里都被收进了一个文件夹里，名字就叫：

README 给出的标准结构里，memory-bank 至少包含 5 个文件：
game-design-document.md、tech-stack.md、implementation-plan.md、progress.md、architecture.md。

如果你做的不是游戏，而是普通应用，那就把游戏设计文档换成 PRD，本质完全一样。README 也明确说了：应用和游戏流程基本相同，只是把 GDD 换成 PRD。

二、为什么很多人 Vibe Coding 会失败？

因为他们把 AI 当“程序员”，却没有把它当“容易失忆、容易跑偏、但执行力极强的程序员”。

AI 最大的问题不是不会写代码，而是：

• 它上下文会丢

• 它容易脑补

• 它会偷懒走捷径

• 它会越写越偏离最初目标

• 它特别容易把项目写成一个巨大的单体文件

所以这个仓库一直在强调几件事：

• 规划就是一切

• 上下文是第一性要素

• 先结构，后代码

• 文档不是事后补，而是开发的一部分

• 一次只改一个模块

• 接口先行，实现后补

这几句话看起来像原则，实际上对应的就是一整套落地动作，而这套动作最终都落在 Memory Bank 上。

三、Memory Bank 才是整个方法的发动机

很多人看 README，会把注意力放在 Claude Code、Codex CLI、模型排名这些地方。但那些只是工具层。

真正让这套方法成立的，是你把项目“喂”给 AI 的方式。

1. game-design-document.md / PRD.md

这是项目意图。

它负责回答：
你到底想做什么？
目标用户是谁？
核心功能是什么？
哪些是必须的，哪些暂时不做？

它不是为了写给老板看，而是为了让 AI 知道：
这个项目的边界在哪里。

2. tech-stack.md

这是技术边界。

它负责告诉 AI：

• 前端用什么

• 后端用什么

• 数据库用什么

• 状态管理怎么做

• 是否多人实时

• 是否需要鉴权、部署、云服务

README 里甚至特别强调，技术栈要让 AI 推荐“最简单但最健壮”的方案，而不是一上来堆复杂技术。

3. implementation-plan.md

这是最关键的执行地图。

它不是代码文件，而是一份按步骤拆好的开发计划。
README 里要求它具备三个特点：

• 每一步都要小

• 每一步都要具体

• 每一步都必须带验证测试

• 并且不要直接写代码，只写清晰指令。

这一步非常重要，因为它把“开发”从模糊的“做个功能”变成了明确的“先做第 1 步，再验证，再做第 2 步”。

换句话说：

implementation-plan 不是项目说明书，而是 AI 的施工清单。

4. progress.md

这是项目进度记忆。

它的作用不是记录情怀，而是告诉下一个会话里的 AI：

• 上一轮已经做了什么

• 哪一步已经完成

• 哪些坑踩过了

• 测试结果如何

• 接下来应该继续哪里

README 明确要求：每完成一个步骤，在验证通过后，要更新 progress.md，供后续开发者参考。

这意味着：

AI 不靠“记得你们刚刚聊过什么”来继续工作，而是靠 progress.md。

5. architecture.md

这是整个项目最被低估的文件。

README 里说得很清楚，它用来记录“每个文件的作用”，并且建议在重大功能或里程碑完成后持续更新。甚至在初始化规则时，还建议把“写代码前必须阅读 memory-bank/@architecture.md”设置成 Always 规则。

为什么它这么重要？

因为 AI 很容易写代码，却不擅长长期维护结构。
architecture.md 的作用就是持续告诉它：

• 当前项目有哪些模块

• 每个文件负责什么

• 数据流怎么走

• 哪些东西已经存在，不要重复造

• 哪些模块不能乱改

所以你会发现：

progress.md 管时间线，architecture.md 管空间结构。
一个记录“做到哪了”，一个记录“项目长什么样”。

这两个文件合起来，才构成 AI 的长期记忆。

四、真正的 Vibe Coding 流程，应该怎么做？

如果我把 README 的核心抽成一套适合普通人上手的版本，完整流程应该是这样的。

第一步：先别写代码，先写项目意图

不要一上来让 AI 开始生成页面。

先让它帮你整理一份项目文档，比如：

这一步的目标不是完美，而是把你的脑子里的模糊想法，变成 AI 能反复读取的固定文档。

第二步：让 AI 推荐最简单但健壮的技术栈

接着继续：

然后保存成 tech-stack.md。

第三步：让 AI 生成实施计划，而不是直接生成代码

这一点特别关键。

你要让 AI 输出一份 implementation-plan.md，格式像这样：

• Step 1：初始化项目结构

• Step 2：搭建首页基础布局

• Step 3：接入登录

• Step 4：接入数据模型

• Step 5：写最小测试

每一步都要附带：

• 本步目标

• 要修改哪些文件

• 验收标准

• 测试方式

README 明确提倡这种“小步、具体、可验证”的开发计划。

第四步：建立 memory-bank

在项目根目录创建：

memory-bank/
PRD.md
tech-stack.md
implementation-plan.md
progress.md
architecture.md

如果你做游戏，就把 PRD.md 换成 game-design-document.md。README 原始版本也是这么组织的。

第五步：初始化 AI 规则，让它先读 Memory Bank 再干活

这一步是很多人忽略的，也是最核心的一步。

README 建议在 CLAUDE.md / Agents.md 或初始化规则里，加入类似这种 Always 级别的约束：

写任何代码前，必须完整阅读 memory-bank/architecture.md
写任何代码前，必须完整阅读 memory-bank/game-design-document.md
每完成一个重大功能或里程碑后，必须更新 architecture.md

这类规则的本质不是“形式主义”，而是：

强迫 AI 先看地图，再动手施工。

否则它很容易一兴奋，直接跳进去改一堆文件，最后你根本不知道项目结构为什么变成这样。README 对这件事说得非常重。

第六步：一次只执行实施计划中的一步

真正开始开发时，不要说：

帮我把整个项目做完

而要说：

请先阅读 memory-bank 中所有文件。
然后只执行 implementation-plan.md 的第 1 步。
在我验证测试通过前，不要开始第 2 步。
完成后，请更新 progress.md 与 architecture.md。

这几乎就是 README 给出的标准提示词思路。

这一步的好处非常大：

• AI 不会一次改太多

• 你更容易排查问题

• 每一步都能独立验收

• 项目不会失控

第七步：你负责验收，AI 负责修改

README 明确有个思想很实用：

测试可以交给 AI，但断言要人审。

意思就是：

AI 可以帮你写测试、跑思路、解释错误；
但“这个结果是不是我要的”，最终必须你来拍板。

你的职责不是自己把代码都敲出来，而是像产品经理 + 代码审稿人一样判断：

• 功能对不对

• 结构乱不乱

• 是否符合原始目标

• 这一步能不能通过

第八步：每完成一步，都回写 Memory Bank

这是整个闭环最重要的一环。

每做完一步，你都要让 AI 回写两件事：

更新 progress.md

记录：

• 这一步完成了什么

• 测试如何

• 当前状态

• 下一步是什么

更新 architecture.md

记录：

• 新增了哪些文件

• 每个文件负责什么

• 数据流或依赖关系有没有变化

README 里几乎把这件事当成必须动作。因为如果你不回写，AI 下一轮就会重新“猜”项目状态，而不是“知道”项目状态。

五、这套方法最妙的地方：它把“聊天开发”变成了“流水线开发”

很多人以为自己在和 AI 协作，其实只是“连续聊天”。

而这个仓库的方法，真正厉害的地方在于，它把开发变成了下面这条链路：

需求文档 → 技术栈 → 实施计划 → Memory Bank → 单步执行 → 测试验收 → 更新进度 → 更新架构 → 新会话继续

README 自己也把它概括成一条闭环交付路径：
需求 → 上下文文档 → 实施计划 → 分步实现 → 自测 → 进度记录，并强调这样做的结果是可复盘、可移交。

这意味着哪怕你中途换模型、换会话、换时间继续做，只要 memory-bank 还在，AI 就可以重新接上节奏。

所以，真正的 Vibe Coding 不是“会聊天”，而是：

会把项目整理成 AI 随时能接手的上下文系统。

六、给普通应用开发者的一套最简上手版

如果你不做游戏，只做网站、App、管理后台、小程序，可以直接照这个模版开工。

项目目录建议

your-project/
src/
memory-bank/
PRD.md
tech-stack.md
implementation-plan.md
progress.md
architecture.md

第一次给 AI 的话

开发时的固定提示词

每次新会话继续时

这就是 README 背后的真正打法，只不过我把它翻译成了普通开发者能直接用的版本。

七、最后总结：Vibe Coding 的本质，不是写得快，而是不失控

如果只用一句话概括这个仓库最核心的思想，那就是：

不要让 AI 凭感觉开发，要让 AI 在固定上下文里按计划施工。

所以它的真正核心不是“Claude Code 很强”或者“Codex CLI 很快”，而是这 4 个东西：

• implementation-plan.md：让开发有顺序

• memory-bank/：让上下文不丢失

• progress.md：让进度可续接

• architecture.md：让结构不失控

工具只是执行器，

Memory Bank 才是方向盘。

这也是为什么 README 一直强调：
Vibe Coding 不是让 AI 自由发挥，而是要通过规划、模块化、上下文管理和持续回写，构建一条可维护的开发流水线。