18年前的夏天我在网吧里盯着一个2D魔幻世界角色站在怪物刷新点一格一格地涨经验。18年后我决定用 vibe coding 的方式把它重新做出来前后用了13天。为了避免和具体商业产品产生混淆下面的文字里我统一把它叫“华夏OL挂机版”。这13天里我的角色更像一个产品经理加测试工程师而不是传统意义上的程序员。代码量的大头来自AI生成我的工作主要是定义边界、拆解流程、验收输出、修掉那些只有运行起来才能暴露的问题。这个过程让我对 vibe coding 有了一个更清醒的判断它真正的价值不是“让你不用写代码”而是把开发的主要矛盾从“从零写代码”转移到了“如何让AI生成的代码正确为你服务”。这个判断是我愿意把这次经历完整写成文章的原因。1. 为什么我决定用 13 天重做一个“记忆里的游戏”1.1 真正想做的不是游戏是把那段时光搬回本地18年前那款游戏画面在现在看非常粗糙但它的核心机制很扎实升级、打怪、掉宝、攒装备。这些东西放在今天依然是一个游戏让人觉得“好玩”的骨架。我想做的其实不是把完整MMO搬回来而是做一个只保留核心机制的演示版玩家打开页面选择角色点击“开始挂机”后端开始模拟战斗经验、金币和掉落物一行一行滚出来。多出来的社交、组队、攻城战全部砍掉。砍到这个程度项目才可能在13天内落地。有人会问为什么不干脆去玩那个老游戏或者找个模拟器因为那个游戏已经不是我记忆里的样子了。当年一起组队的人早就不在线服务器生态也完全不同。我真正怀念的不是某个版本而是那个每天中午打开电脑、先挂两个小时再去做别的事的节奏。那个节奏是可以在单机环境里复现的。所以这个项目从一开始就不是“仿制一款游戏”而是“用代码给自己做一个记忆沙盒”。1.2 为什么选 vibe coding而不是从零手写如果是传统开发13天对这个项目来说非常紧张。从搭项目骨架、写模型、写路由、写前端页面到处理战斗逻辑、定时任务、存档中间还有最耗时间的调试环节。手写当然可以但你大概率只能在一个非常窄的范围内做完很难把“挂机循环”这个核心体验打磨出感觉。使用 vibe coding 后我做的事情变成了四步用自然语言描述一个功能包括输入、输出和边界。让 AI 生成对应代码。运行起来看日志确认行为符合预期。不符合就描述错误现象要求修正。听起来很简单但实际执行中每一步都有坑。后面我会详细展开。有一点可以先说vibe coding 并没有让“AI 替我写代码”这个描述完全成立。它更像是你带了一个效率很高的实习生这个实习生不太了解项目的整体语境但能快速产出一堆可运行代码。你要做的是给足上下文、检查输出、在它跑偏的时候把它拉回来。1.3 对“挂机版”的正确定位学习型复刻不是商业产品开始之前我给自己定了几条边界。这个项目是一个独立的本地 demo所有代码和数据都放在自己电脑上。我没有修改、反编译或接入任何商业产品也没有碰它们的服务端或用户数据。它只是借用了记忆里的玩法规则在本地重新实现一遍用于学习、怀旧和个人技术实验。它不会被上传到任何平台也不会被商业化分发。这件事在技术上稍微有一点微妙但它保证了整个开发过程是合规的也让我能够安心写下这次复盘。如果你想复刻记忆里某款游戏的玩法我建议也先做这样的定位避免滑向灰产或侵权边界。技术栈方面我选择了 Python 后端加简单 Web 前端存储用 SQLite。这个选择不是因为它最酷而是因为它足够主流AI 对这个组合的熟悉程度很高。vibe coding 时代有一个隐性规则你选的框架越大众AI 生成代码的质量越稳。冷门框架的问题不是你自己不会写而是 AI 很容易胡编一些根本不存在的 API。2. vibe coding 是什么以及它凭什么让一个挂机游戏在 13 天内走完2.1 先给 vibe coding 一个准确的自白现在提到 vibe coding很多文章会把它描述成“用 AI 托管整个项目”。这个词本身起源于一种开发体验你不再一句一句考虑语法而是把节奏和意图交给 AI让它陪着你写。“看着 AI 生成的代码像水流一样跑出来”这确实是 vibe coding 最初吸引人的地方。但真正用下来我更愿意把它定义为“面向结果的人机协作编程”。人通过自然语言描述需求AI 生成代码人负责编译、运行、验证、纠错和决策。在这个流程里你依然需要知道自己想要什么只是不需要再考虑每一行的具体写法。很多人第一次体验 vibe coding可能是在浏览器里打开某个 AI 编程平台或者在自己的开发工具里接入了 AI 助手。从 Vercel 这类 AI 前端开发平台到移动端开发工具里的 AI 补全vibe coding 的交互形式正在快速扩散。但核心逻辑没有变人给出意图AI 生成代码人负责验收。这有点像“口述写作”和“亲手写作”的区别。口述时你要比亲手写更清楚主题、结构、语气和细节边界否则听写员写出来的东西就完全跑偏。AI 不是听写员但它和听写员的处境很像记性好、速度快、但容易在缺少上下文时自作主张。2.2 为什么过去做个挂机小游戏至少一两个月现在可以以天为单位推进传统开发一个挂机小游戏真正的成本大头在两块一块是业务逻辑的开发另一块是反复调试的隐性时间。业务逻辑包含角色模型、战斗公式、掉落表、背包、任务调度、存档调试时间则分布在你确认依赖、排查报错、测试边界条件的全过程。vibe coding 把第一块成本压得极低。角色模型的增删改查AI 几十秒就能生成掉落表只需要描述清楚规则它也能给你写出一个能跑的版本前端页面更是如此你只要说清楚“左边角色面板右边日志列表下面一个开始按钮”生成的页面基本就能用。但这不意味着总时间被压缩到原来的十分之一。你会发现在 AI 生成的代码里经常会出现“编译通过但业务逻辑完全不对”的代码。这类 bug 不会在语法检查阶段报错只会在运行时的某一刻炸出来。所以vibe coding 不是把调试时间消掉了而是把调试的形态改成了“针对 AI 生成代码的验收式调试”。换句话说省下的时间被转移到了更重要的判断工作里确认系统该有什么行为、界面的输入输出边界在哪、数据如何流转、异常情况如何处理。2.3 技术栈的底线框架选择与 AI 的“舒适区”如果你要做一个 13 天周期的 vibe coding 项目我建议先想清楚一件事你的技术栈是不是 AI 的舒适区。我用 Python FastAPI 写后端接口前端用了一个极简的 React 页面数据存储先用 SQLite 起步。这三个都是非常主流的选择AI 在它们上的训练语料足够多API 也稳定生成质量通常比较高。反过来如果你选择了某个很新的框架或者某个小众数据库AI 生成的代码大概率会踩中版本或 API 不匹配的坑。另一点是控制规模。13天项目不需要微服务不需要消息队列不需要分布式任务。你需要的是一个能跑、能改、能扩的代码库。vibe coding 最容易失控的场景恰恰是项目一开始就铺得太大。后端、前端、数据库、缓存全都要AI 生成的代码堆在一起很快你就不知道哪个模块在依赖哪个模块。我的建议vibe coding 项目的前3天先不要超过“一个后端进程 一个前端页面 一个本地数据库文件”。这三样东西组合成一个最小闭环后面的功能都是往这个闭环里加。3. 13 天开发复盘从 MVP 到可玩版3.1 第 1-3 天先跑通最小闭环而不是直接做全部系统很多人做项目上来就列完整功能清单登录、角色创建、排行榜、多角色、战斗动画、背包、任务……这些都想做结果前三天都在搭架子第四天还没有一个可玩的循环。我用 vibe coding 的方式是先定义“最小可玩闭环”再让它跑起来。第一天我只让 AI 做了三件事一个后端服务监听 8080 端口。一个角色数据模型字段只有用户ID、角色名、等级、经验、金币。一个接口输入“开始经验训练”输出一条模拟战斗日志。第二天把前端页面做得非常简陋一个按钮和一个文本框。点击按钮后调用后端接口页面上出现“你击败了一只野怪获得 23 点经验”。到这一步游戏已经有一个最核心的反馈循环点击 - 请求 - 模拟战斗 - 返回结果 - 显示在页面上。第三天开始补数字细节。我给 AI 设定了战斗公式基础经验、等级差系数、随机波动。这时候你会发现一个小项目只要循环能跑所有后续工作都像往轨道上加车厢而不是重新铺铁轨。3.2 第 4-7 天战斗、挂机、掉落、背包