AI Coding做游戏有多离谱？一个月复刻大巴扎写了10万行代码

项目概述：一个人用AI复刻完整卡牌游戏

一位名为白狼的开发者，用一个多月时间，借助AI Coding工具复刻了热门卡牌游戏《大巴扎》的猎人职业全部114张卡牌。期间提交代码500多次，总计约10万行代码，全部通过AI辅助编写完成。

这个项目选用了Godot引擎，开发者此前没有任何Godot使用经验，仅看了官方Quick Start就直接开干。最终实现了完整的战斗逻辑、商店系统、物品效果、UI展示以及单机游戏循环。

关于Godot引擎：Godot是一款开源、跨平台的游戏引擎，由Juan Linietsky和Ariel Manzur于2014年正式发布。与Unity或Unreal Engine不同，Godot采用节点树（Node Tree）架构和自研脚本语言GDScript，整体体积极小（完整编辑器不足100MB），无运行时版权费用。正因其"轻量"特性，引擎内置的抽象层极少，开发者几乎需要从零构建游戏系统，这在AI辅助编程时代反而成为优势——AI生成的代码不需要与复杂的内置框架协商，可以直接落地执行。

项目启动：文档先行的AI开发策略

策划文档的重要性

开发者在写第一行代码之前，花了几天时间确立了详细的策划文案，包括底层机制、局内局外循环等。他强调：对AI来说，一开始就明确知道你在做什么、想做什么，是极其重要的。

这些策划案经过与AI多轮评审，细节基本完善。开发者表示"如果上班时策划案能有这个质量，做梦都能笑醒"。每次开启Codex，让AI读一下文档就能直接开干，省去大量沟通成本。

MVP界面流转文档

对于大巴扎这种纯UI游戏，开发者提前定义了10个不同界面及其跳转关系，每个界面都有详细的信息描述。这让AI能快速生成完整的闭环骨架，后续只需在骨架上填充逻辑。

文档时效性管理

开发者特别指出一个容易被忽视的问题：文档的时效性。过期的文档反而会让AI产生错误判断。临时文档用完就删，不要留着污染AI的信息库。

这一问题在软件工程中被称为"文档漂移"（Documentation Drift）——代码已经演进，但文档仍停留在旧版本描述。在传统开发中，过期文档只会误导人类开发者；在AI辅助开发中，LLM会将文档内容与代码现状同等权重地纳入上下文推理，过期文档的"污染效应"因此被放大数倍。

AI游戏开发中的关键决策

第一天：搭建MVP骨架

第一天就实现了小型MVP流程，虽然没有细节，但已能在各流程间跳转。AI根据文档做好了基础数据定义和简单框架。开发者感叹："一天做的东西，换手搓的话一个星期都做不出来。"

为什么选Godot引擎？

因为Godot足够"简陋"。在没有AI的时代，简陋是缺点；在AI时代却是优点——AI可以随意操作，迭代速度极快。不像UE那种自带庞大框架的引擎，Godot的所有东西都需要手搓，但这反而给了AI更大的发挥空间。

Unreal Engine内置了大量高度封装的子系统（如GameplayAbilitySystem、BlueprintGraph等），AI在修改这些系统时需要理解深层的继承关系和隐式约定，极易产生难以追踪的副作用。Godot的"白板"特性让AI生成的每一行代码都处于完全可见、可控的范围内，这与AI辅助开发"可验证、可回滚"的核心需求高度契合。

避免成为"回车机器人"

开发者提出一个重要观点：如果AI给出正确决策的概率是90%，连续10次无脑追随AI的决定，最终正确率只有0.9的10次方≈35%。你需要有自己的判断力，而不是无条件信任AI的每一个决定。

这一现象在概率论中被称为"误差累积"（Error Propagation）。更值得警惕的是，LLM的错误往往不是随机分布的——当AI在某个架构假设上出现偏差时，后续所有基于该假设的决策都会系统性地偏离正确方向，实际错误率远高于独立概率模型的预测。这要求开发者在关键架构节点保持主动介入，而非将判断权完全委托给AI。

产能爆发：基于Honest Engineering的Agent流水线

从"聊天式"到"流水线式"

早期实现卡牌的方式是用聊天告诉AI要做什么，然后手动测试验证。这种方式虽然比传统编程快，但效率仍然有限。

转折点来自一篇关于Honest Engineering的文章。开发者基于这个规范实现了卡牌生产Agent，产能彻底爆发——两天内实现了超过80张卡牌，同时开6个窗口并行生产。

关于Honest Engineering：Honest Engineering是一种面向LLM协作的软件工程规范，核心理念是"让AI知道自己不知道什么"。传统Prompt Engineering倾向于让AI直接给出答案，而Honest Engineering强调在执行前插入显式的澄清、审计和计划阶段，迫使AI暴露不确定性而非用幻觉填补空白。这一规范借鉴了软件工程中"需求冻结"和"测试驱动开发"的思想，将其适配到LLM的概率性输出特征上，从而将AI的随机性约束在可控的流程节点内。

Agent的四阶段流程

第一阶段：语义澄清

• 输入卡牌原始信息（从数据库网站抓取）
• AI根据术语表理解卡面描述
• AI主动提问不理解的地方
• 人工确认后冻结理解

第二阶段：基建审计

• 审查当前框架已有能力
• 判断是否需要补充基建
• 如需补充，人工审核方案合理性

第三阶段：计划生成与实施

• 根据前两阶段信息生成实施计划
• 在主会话中直接执行代码编写

第四阶段：自动化验证

• 读取语义澄清阶段的spec文件
• 生成测试用例并执行
• 根据测试结果循环修复
• 直到所有测试通过

核心设计原则

1. 不要假设LLM是稳定的：设计稳定的生产流程，用流程约束AI的不稳定性
2. 上下文结构化：使用文档传递信息，各阶段共享Plan文档
3. Agent专业化：小Agent比大Agent更稳定，一个Agent只做一件事
4. 持久化记忆：每张卡的spec文件和测试用例是修bug的第一入口
5. 思考与执行分离：前两阶段收集信息，第三阶段专注执行，不要中途打断

"Agent专业化"原则在工程上对应"单一职责原则"（Single Responsibility Principle）的AI版本。LLM的上下文窗口是有限资源，当一个Agent同时承担需求理解、方案设计、代码生成、测试验证多个角色时，不同角色的推理目标会相互干扰，导致输出质量下降。将职责拆分到多个专用Agent，本质上是用架构设计换取每个推理步骤的专注度和准确率。

踩过的大坑：AI编程的真实教训

可视化编辑器是AI时代的伪需求

开发者花了半天时间给卡牌的Inspector面板做可视化编辑器，后来证明完全白做。一个卡牌定义面板极长，手动填写不仅需要对卡牌建模熟悉无比，还极易出错。在AI时代，这些数据定义工作全部交给AI，比人工填写快几个数量级。

这一教训揭示了一个更深层的范式转变：传统工具设计以"降低人类操作成本"为核心目标，可视化编辑器、拖拽界面、表单填写都是这一目标的产物。但在AI辅助开发中，数据录入的主体从人类变成了LLM，而LLM处理结构化文本（JSON、YAML、代码）的效率远超处理GUI交互。这意味着许多"对人友好"的工具在AI时代反而成了效率瓶颈。

高频触发导致的性能灾难

举重据实+树精的卡组组合产生了"左脚踩右脚