尝试一下用ai开始全新的领域，完全用ai写一个游戏，自己不主动修改任意一行代码。遇到了一些问题，最终还是写出了一个小demo mvp,题材为卡牌肉鸽游戏：
一、我是怎么一步步发现问题的
我一开始以为，AI 辅助开发游戏这件事，关键只是把需求说清楚。
比如先让它写一个战斗系统，跑通；再补技能系统；再补道具和成长。每一步看起来都不复杂，而且 AI 出代码的速度确实很快。最开始那几次，我甚至有一种错觉：是不是终于可以把很多原本很慢的工程工作压缩掉了。
但真正的问题，很快就出现在第二个、第三个 Sprint。
第一次出问题是在加技能系统的时候。战斗系统刚做完时一切正常，怪物攻击、掉血、回合切换都没毛病。等到我让 AI 在它上面接技能，它发现原来的怪物结构里根本没给 buff 槽、状态计时器这些东西留位置。两条路：要么打补丁硬塞进去，代码立刻开始变乱；要么回头重构怪物数据，把 Sprint 1 的活儿再做一遍。
我当时还以为是自己一开始没说清楚需求。
第二次出问题是加技能移植——把一个怪物身上的技能抽出来移植到另一只。AI 又卡住了，因为前面写战斗时根本没区分”怪物模板”和”怪物实例”，技能也没有独立的槽位概念。这次返工范围比上一次更大，几乎把怪物相关的所有代码都翻了一遍。
到这里我开始觉得不对劲，但还在归因到”AI 没我懂这个游戏”。
第三次是加道具系统的时候。我已经做好了再返工一遍的心理准备，但这次撞上的不是数据结构问题，而是战斗系统和道具系统之间根本没有接口——AI 之前写战斗时没考虑过外部还会有别的系统进来调用它。
三次撞墙之后我才意识到，问题不是某段代码写错了，也不是 AI 不够聪明。问题在于 AI 每次只会对你眼前这一条指令给出一个局部最优解。单看当前任务，它写得通常没什么问题；但只要项目是要持续往外长的，这种局部最优解就会在后面变成系统性的返工。
后来我给这个问题找了个更准确的名字：局部性。
它不是 bug，而是 AI 协作天然的特性——它看不到你后面还要加什么，自然也不会替后面留位置。所以真正的问题不在 AI 的能力上，而在于你用什么流程，确保 AI 每次”局部写代码”时，都写在一个全局可扩展的框架里。
而做到这一点，光靠”把需求说得更清楚”是不够的，得靠文档先行。
二、我后来稳定下来的流程
既然问题不只是”写代码”，那解法也不可能只是”换个更强的模型”。我后来慢慢稳定下来的，是一套四步流程：
- 讨论想法：跟 AI 头脑风暴，把模糊想法变成具体设计
- 写 MVP 文档：把设计拆成独立、可测试的步骤，包含数据结构和系统边界的设计
- 逐步落实：每个步骤独立实现
- 每步验证：自动化确认这步做对了
四步缺一不可，但真正决定后面会不会反复返工的，其实不是”逐步落实”，也不是”每步验证”，而是第二步：在动手之前，到底有没有把 MVP 文档写清楚。
大多数做法跳过文档直接写代码，结果每步都是”补丁上打补丁”。MVP 文档的作用，是让每一步代码都建立在一个经过思考的地基上，而不是临时搭的脚手架上。
所以下面先展开讲，为什么这一步不能省。
三、为什么 MVP 文档是关键
3.1 AI 不会替你考虑”后面还要加什么”
回到我前面那三次返工。每一次都不是 AI 写错了，而是前面的步骤没有为后面的扩展留空间。而 AI 不会主动留这个空间——它只在当前需求范围内做最优解，这就是局部性。
换句话说，如果你不在前面就把”后面还要长什么”告诉它，它就只会按最简单的路径走完眼前这一步。然后你为这个”简单”付出后续返工的代价。
每次返工都在侵蚀两样东西：你对 AI 辅助开发的信心，以及代码库本身的健康。两样东西一旦被磨没了，整个项目就很难再继续往下做了。
3.2 MVP 文档真正要解决的是什么
MVP 文档的核心作用，不是写设计文档给老板看，而是在写代码之前把关键设计决策定下来。具体来说有三类：
- 数据怎么组织？ 怪物是 Resource 模板加 Instance 实例的分离设计，还是全写死在脚本里？这个决定影响后续所有系统。
- 状态怎么管理？ 全局单例、信号驱动、还是各模块自己管？这个决定了系统之间的通信方式。
- 系统边界在哪？ 战斗系统知道驯服系统吗？技能系统和道具系统怎么交互？边界不清就会出现循环依赖。
这些问题如果不在写代码前定下来，AI 就会按最简单的路径走。我前面那三次返工，本质上都是这三类决策在事后才被迫补上。
3.3 MVP 文档怎么写
要说明的是，MVP 文档不是传统意义上的游戏设计文档（GDD）。GDD 描述的是游戏的创意和体验；MVP 文档描述的是最小可玩版本的工程步骤拆解，每步包含：
- 这步要实现什么（功能目标）
- 数据结构怎么设计（为后续扩展留空间）
- 系统边界在哪（哪些交互本期不做，但接口要留）
- 怎么验证这步做对了（可测试的验收标准）
关键是：只写跟”能不能后续扩展”相关的设计决策，不写细节实现。 AI 不需要你在文档里告诉它怎么写代码，它需要你告诉它代码要在什么框架里写。
而且每个步骤必须是独立可测试的——做完这步能跑、能验证、不影响其他步骤。这样即使某一步实现有问题，影响范围也是可控的。
四、文档定方向，但执行还得靠纪律
不过，文档解决的是”方向”问题，不解决”执行”问题。
方向对了，AI 还是可能跳步、偷步、直接开写。它没有”先想后做”的本能，你说什么它就做什么；你说得不严谨，它就跳过。所以光有文档不够，还得有一套机制保证它按顺序做事。
这部分我后来是靠三件事兜住的：流程上的纪律、知识上的传承、验证上的闭环。
4.1 流程纪律：让 AI 不能跳步
和 AI 对话写代码，最常见的现象是：你说了个需求，AI 直接开始写代码。跳过了讨论，跳过了计划，跳过了测试——代码秒出，但质量堪忧。
我后来用 Skill 体系把这件事兜住了。它不是给你更多工具，而是在关键节点加检查点，阻止 AI 跳步：
- brainstorming：强制先讨论再动手。你说”我要加个技能系统”，它不会直接写代码，而是先跟你讨论技能系统的设计，确认边界和交互。
- writing-plans：强制把 MVP 拆成可执行计划再写代码。拆完计划你能看到每步做什么、依赖什么、验证什么，而不是 AI 一股脑写完一坨代码。
- test-driven-development：强制先写失败测试再写实现。这保证每一步都有验收标准，”能跑”不等于”做对了”。
- verification-before-completion：做完必须验证，不能”我觉得好了”。验证通过才算完成。
这些 Skill 的本质不是工具，是流程检查点。就好像建筑里的质检——不是每块砖都要你亲自检查，但关键节点必须有人签字确认。
4.2 知识传承：解决 AI 的”失忆”问题
但流程纪律也没法解决 AI 另一个让人头疼的特征：每次开新会话都像新员工入职。前面做的架构决策、项目约定、已完成的步骤，它一个都不知道。
这件事直接踩过我两次。一次是新会话里 AI 把之前定好的怪物数据结构重新设计了一版；另一次是它把已经完成的 Sprint 1 当成”还没做”，准备从头实现。两次都不是它写错了，是它根本不知道前面发生过什么。
Harness Engineering 是一套文档工程体系，用来兜住这件事。它包含三层：
- 入口地图：项目规则、目录结构、在哪找什么、禁止事项。相当于公司里的”新人入职手册”——不是详细的业务文档，是让你知道去哪找详细文档的地图。
- 按需加载的知识库：编码规范、架构决策、数据流、测试模板等深度文档。关键在于”按需加载”——不是每次对话都全读一遍，而是根据当前任务加载相关部分。做战斗系统时读战斗相关的文档，做 UI 时读 UI 相关的。这样既保证 AI 有足够的上下文，又不浪费 token 预算。
- 当前进度：正在做哪个 Sprint、完成了什么、下一步做什么。让 AI 知道项目走到哪了，而不是每次都从”现在项目什么状态”开始问。
没有这套东西，每次对话都是新员工从零开始。你花时间在 MVP 文档里定的设计决策，AI 根本不知道，又回到局部性写代码的老路上。
4.3 验证闭环：让 AI 自己验证自己
最后还有一件事：AI 写了代码，谁来验证？
我一开始的办法是人眼看：AI 写完代码 → 我手动在引擎里跑 → 截图给 AI 看 → AI 修 → 我再跑 → ……。这个循环慢，而且我自己是瓶颈——不可能每改一行代码都手动全面测试，结果就是很多问题拖着不验，到后面积成大问题。
后来稳定下来的是三层自动化验证：
第一层：静态验证。 写完代码立刻做语法检查和场景结构验证。零成本，零延迟，捕获低级错误——拼写错误、类型不匹配、引用缺失。这一层过滤掉 80% 的愚蠢问题。
第二层：逻辑验证。 跑一段无头脚本断言数据是否正确。比如验证怪物实例的血量是不是初始化正确、技能冷却是不是按预期递减。不需要游戏画面，只需要数据对不对。
第三层：UI 交互验证。 启动游戏 → 模拟玩家输入 → 检查界面元素 → 跑脚本确认结果。这一层验证的是玩家真实体验——玩家点了这个按钮，界面是不是真的变了？战斗扣血后血条是不是真的更新了？
三层各有分工：静态层抓低级错误，逻辑层验数据正确，UI 层验玩家真实体验。只有 UI 层能回答”玩家点击这个按钮后到底发生了什么”这个问题。
跑通这三层之后，整个循环就从”AI 写代码 → 人测试 → 告诉 AI 结果 → AI 修”变成了”AI 写代码 → AI 自己验 → AI 自己修”。人是审批者，不是测试员。
五、这套方法靠什么落地
讲到这里，整套方法的轮廓已经有了：先用文档定边界，再用流程约束执行，再用验证形成闭环，再用知识库防止失忆。
剩下的问题只有一个：这些事具体靠什么工具串起来？
下面是我实际在用的几样：
- OpenCode：支持 MCP 协议的对话式编程工具。桥接 AI 和游戏引擎，让 AI 能直接操作场景、运行游戏、查看结果，而不是靠人来回粘贴代码。
- Superpowers Skill 体系：流程纪律的载体。前面说的 brainstorming、writing-plans、TDD 都是 skill，直接挂在对话流程里执行——不是你每次手动提醒 AI “先想再写”，是流程自动触发。
- godot-mcp-runtime：游戏引擎和 AI 之间的桥梁。让 AI 能操作场景、运行游戏、模拟输入、截图查看。它是三层验证的执行手段——没有它，AI 写完代码只能等人来测试。
- Harness 文档体系：入口地图 + 按需知识库 + 当前进度。给 AI 项目上下文，防止失忆，确保每次对话都能接上之前的架构决策。
每个工具单独拿出来都不稀奇。但组合在一起，正好对应了前面那四件事——文档定方向、Skill 定流程、MCP 做验证、Harness 保记忆：
- 文档决定了写什么、怎么组织
- Skill 确保按纪律执行
- MCP 让 AI 能自己验证自己
- Harness 让 AI 不忘记之前的决策
缺了任何一环，闭环就断了——文档没人看（缺 Harness）、纪律没人守（缺 Skill）、验证靠人眼（缺 MCP）、架构决策每次重新来（缺 Harness）。
六、回头看
回头再看，AI 写游戏代码是局部性的。这件事我一开始没看明白，是被三次返工慢慢逼出来的。
局部性本身不是 bug，是特性——AI 只在当前需求范围内做最优解，这本身没问题。问题在于，如果没有全局框架约束这些局部最优解，它们就会各自为政，最终无法组合成一个可扩展的系统。
解决方案不是更好的 AI 模型，而是更好的流程：文档驱动定方向、流程纪律保执行、自动验证替人工、知识管理防失忆。
这套方法论也不限于 Godot，不限于游戏开发。任何 AI 辅助的系统性工程——Web 应用、后端服务、数据处理管线——都有同样的局部性问题，都可以用同样的思路解决：先想清楚再动手，每步可验证，知识可传承。
前期文档投入确实更大。但这个投入在第三个 Sprint 之后就会回本——因为你不用返工了。我自己就是在第三个 Sprint 才意识到这件事的，要是早一点知道，前两次返工的代价本来是可以省掉的。