Vibe Coding 不是咒语：从《赤白江湖》看游戏开发里真正该被保住的东西

这两天我翻了赤白江湖项目，读了它的 GDD、工作流、架构决策、会话日志，也看了它留下来的概念图与冒烟截图。看完之后，我反而更不想把 “vibe coding” 说成一句轻飘飘的口号了。

因为真正让我有感觉的，不是 AI 把代码写得多快，而是这个项目用一连串极其具体的文档、边界和选择，证明了一件更难的事：在游戏开发里，真正珍贵的从来不是生成速度，而是你在速度里面还保住了什么。

先说结论

我越来越觉得，vibe coding 最容易被误解的地方，在于它看起来像一种“更自由”的开发方式，实际上它最需要的却是“更严格”的自我约束。

写一个工具型项目，很多时候先跑起来再说；写一个游戏，却不是这样。游戏不是一组功能的堆叠，它更像一套彼此拉扯的感受系统。气氛、数值、节奏、界面、成长、失败、视觉记忆、玩家幻想，这些东西只要有一个地方松了，整个项目都会从“作品”滑向“demo”。

而 赤白江湖里最值得写的，恰恰就是它没有把这种复杂性外包给一句“交给 AI 就好了”。

一张图是梦，一张图是手

先看它的概念层。

这张图很容易让人兴奋：赤白配色、旷野、孤身持刀、血色路径、剩余天数、五方区域，一眼就能看出它想做的不是传统意义上的 UI，而是一种带着宿命感的武侠空气。

项目文档里把这个核心说得很清楚：红白极简、文字流、1000 天寿命、五大区域、命途问答、随机武学、心法、遭遇、回合制战斗。也就是说，它不是先有代码，后找包装，而是先有审美、系统和情绪的锚点，再倒推实现。

但更打动我的是另一张图。

这是一张“没那么会骗人”的图。没有 UE5 的雾，没有山河万里，只有白底、红线、状态、方向键、日志、区域切换和功能按钮。它看起来朴素，甚至有点克制，可它更诚实。因为这张图说明，项目已经从“想做什么”迈到了“现在真的能玩什么”。

如果说第一张图是梦，那第二张图就是手。游戏开发真正困难的地方，从来不是做梦，而是让手不背叛梦。

再看移动端的落点

这张竖屏截图更能说明问题。赤白江湖不是在讲一个抽象的“AI 游戏工作流”，它明确知道自己的 MVP 要落在 375x667 的移动端基线，要处理按钮不重叠、状态面板怎么开、存档怎么导出、竖屏文字怎样呼吸。
这很重要。因为所谓 vibe，如果没有屏幕尺寸、输入方式和可用空间这些硬约束，最后就很容易变成一场只存在于描述词里的幻觉。

《赤白江湖》真正厉害的，不是 AI 多，而是顺序对

这个项目里有很多让人一眼上头的词：49 个 agents，72 个 skills，完整 studio hierarchy，hooks，rules，gate checks。单看这些，很容易把注意力全部放在“AI 团队协作”的 spectacle 上。

但如果你真的顺着文档往下读，会发现它最成熟的地方，不是阵仗大，而是顺序对。

它不是先问“怎么把功能堆出来”，而是先问：

1. 游戏概念到底是什么。
2. 系统如何拆。
3. 哪些是 MVP。
4. 哪些必须延后。
5. 架构边界在哪里。
6. 什么东西应该进组件，什么东西必须留在纯逻辑层。

于是你会看到一条非常清晰的链条：
game-concept -> systems-index -> 各系统 GDD -> MVP plan -> ADR -> runtime -> tests

这条链条的价值，在 AI 时代反而更大。因为模型最擅长补全，最不擅长拒绝。它总能顺着你往下写，问题是它不会天然替你刹车。你说想做一个江湖，它就能给你地图、城镇、任务、战斗、突破、装备、流派、事件、存档、甚至多引擎专家组。可游戏真正会死掉的原因，往往不是没人给你方案，而是方案太多，任何一个都像“顺手也能做”。

所以我很喜欢 production/project-stage-report.md 里那个判断：设计覆盖很强，代码在当时几乎是空的，先做一个 Vue 3 + Vite + Pinia 的可玩 vertical slice，再补测试、ADR、控制清单。
这不是保守，这是清醒。

Vibe coding 在游戏里最危险的诱惑，是“什么都像只差一步”

游戏项目最容易让人失控的地方，是每个系统都能说出充分的理由。

要不要做城镇？当然要。
要不要做任务板？当然要。
要不要做更完整的装备经济？当然要。
要不要把概念图里的那种 AAA 气氛落进正式版本？当然想。

问题在于，AI 会让“当然要”变得更加廉价。过去你还会因为写起来麻烦而犹豫，现在模型几秒钟就能给你一套看似完整的方案。于是范围失控不再以“做不到”的形式出现，而是以“这也很合理”的形式出现。

我觉得这正是 vibe coding 在游戏开发里的第一课：
AI 降低的不是复杂度本身，而是你误判复杂度的门槛。

赤白江湖最有启发的地方，就是它没有沉迷于“既然能写，那就都写”。它把城镇经济、全装备体系、多敌人战斗、Canvas 渲染等内容明确标成 deferred systems，把第一圈玩法钉死在：新人生、五题命途、区域移动、时间消耗、随机遭遇、回合战斗、掉落成长、状态查看、存档导入导出。

这不是缩小 ambition，而是在保护 ambition。因为对独立开发也好，对 AI 协作也好，真正把项目带到下一阶段的，从来不是“加东西”，而是“舍得不加”。

真正的作者，不再只是敲代码的人，而是守边界的人

如果只看代码栈，赤白江湖很朴素：Vue 3、TypeScript、Pinia、纯逻辑模块、Base64 存档、seed-based RNG。
但朴素恰好说明另一件事：这个项目在有意压低技术炫技，把作者的精力留给更关键的判断。

比如它在 ADR 里明确要求：

• Vue 组件负责渲染与交互；
• Pinia store 持有持久状态；
• 纯 TypeScript 模块承接 RNG、属性、战斗、时间、存档；
• 公式不能埋进组件；
• 数据要尽量放进 src/data/。

你会发现，所谓 AI 协作开发，最后真正决定项目气质的，并不是模型写了多少行，而是谁在替项目持续回答这些问题：

• 这段逻辑该放哪？
• 这个系统是不是现在就该做？
• 这个视觉是 promise 还是 debt？
• 这个功能是在服务玩家体验，还是在服务作者的兴奋？

我越来越相信，AI 时代的作者身份并没有消失，只是从“执行者”向“裁判者”移动了。
模型负责把可能性铺开，人负责决定什么值得留下。

游戏开发不是反对 vibe，而是反对只有 vibe

说到底，我并不反对 vibe coding。恰恰相反，我觉得它对游戏这种重 imagination 的媒介很重要。没有那一点先被画面、气质、世界观击中的瞬间，你甚至不会开始。

但如果一个项目只有 vibe，它就会变成精致的许愿单。
真正能往前走的项目，必须让 vibe 穿过以下几道门：

1. 穿过文档

把模糊感受翻译成可讨论、可删减、可验证的系统描述。

2. 穿过架构

让激情不直接淹没工程，让每个系统有自己的边界。

3. 穿过范围控制

承认不是每一个好想法都配得上今天的版本。

4. 穿过可玩原型

让玩家真的点下去、走一步、打一回合、存一个档。

5. 穿过时间

看它在第二天、第三天、下一次重构时，是不是还站得住。

赤白江湖给我的最大感受就是，它不是在证明“AI 能一键做游戏”，而是在证明另一件更值得尊敬的事：
AI 可以把一个人的开发冲动，整理成一个像样的项目秩序。

最后想说的一句

我们今天谈 vibe coding，很容易把重点放在“快”。
可游戏开发真正稀缺的，往往不是快，而是那种在高速里仍然不失真的能力。

《赤白江湖》也许还远没到最终形态。它现在留下的，是概念图，是 GDD，是工作流，是一套能玩的竖屏原型，是若干还没来得及兑现的雄心。可正因为如此，它才有代表性。它像一个很好的提醒：

未来的游戏开发，未必是“一个人埋头苦写代码”，也未必是“把一切都交给 AI”。更可能的现实，是你带着一群不会疲惫的模型，一边冲锋，一边不断把自己拽回来。

因为真正让作品成形的，不是那股最先升起来的兴奋，而是你有没有本事在兴奋之后，仍然一页一页地把它写实，一块一块地把它落地。

vibe 很重要。
但能把 vibe 变成结构，才是项目真正开始活过来的那一刻。