让AI 花 5 小时造了一个完整马里奥游戏 — 零架构漂移如何做到

花 5 小时造了一个完整马里奥游戏

12 个任务，0 个失败，802 个测试，架构零漂移。

这是用 OpenMatrix 自动编排完成的一个真实项目：超级马里奥兄弟 NES 版 1:1 还原。TypeScript + HTML5 Canvas + Web Audio API，从空目录到 4 个关卡完整可玩，全程 AI 自主执行，无人干预。

起点：一行命令

bash 复制代码

openmatrix start "超级马里奥兄弟 NES 版 1:1 还原"

OpenMatrix 读完设计文档，拆解为 4 个阶段、12 个任务，质量级别选了最严的 strict。然后就没有人工干预了。

执行总览

时间节点	里程碑	测试数
T+0	启动，12 任务排队	---
T+8min	Phase 1 完成：GameLoop + EventBus + InputHandler	---
T+19min	Phase 2 完成：物理引擎 + 碰撞检测 + Mario 三态	---
T+31min	Phase 1 测试全绿	91
T+1h08min	Phase 2 测试全绿，覆盖率 95.92%	167
T+1h52min	Phase 3 完成：4 关卡 + 敌人 AI + 道具系统	---
T+2h01min	Phase 4 完成：音效 + 粒子 + 性能优化	---
T+4h05min	全部单元测试通过	611
T+5h04min	集成测试 + E2E + 代码审查，结束	802

实现和测试并行推进 --- Phase 2 实现的时候，Phase 1 测试同时在跑。这就是 5 小时做完的原因。

产物数据

指标	数据
源代码	30 个文件，~3,900 行 TypeScript
测试代码	36 个文件，802 个测试（611 单元 + 160 集成 + 31 E2E）
语句覆盖率	95.92%
分支覆盖率	91.54%
可玩关卡	4 个（1-1、1-2、2-1、4-1）
外部资源	零 --- 没有图片文件，没有音频文件

数字之外，有三点真正值得说的。

干货一：架构漂移是怎么防住的

AI 编程最大的敌人不是写不出代码，而是写着写着就歪了。

典型场景：第一个功能写得很漂亮，第二个开始"将就"，到第五个功能，代码已经变成意大利面条。每个单独任务看起来都合理，但整体架构已经面目全非。

OpenMatrix 在这个项目中用了三道防线：

1. 架构写在 plan.md 里，每个 Task 都读

makefile 复制代码

GameLoop (60FPS) → [InputHandler, LogicLayer, RenderLayer]
LogicLayer: PhysicsEngine + CollisionDetector + Level
RenderLayer: PixelRenderer + TileRenderer + UIRenderer + Camera

这不是装饰性文档。每个 Task 开始前，AI 读取 plan.md 中的架构定义，知道自己产出的模块该放在哪一层、通过什么接口与其他层通信。

Phase 1 建立 EventBus 后，Phase 2/3/4 全部通过 EventBus 通信，没有出现跨层直接调用。Phase 1 定义的物理常量（gravity: 0.25、terminalVelocity: 6.0、antiTunneling: 16px），被后续所有阶段精确引用，零近似。

2. context.md 传递上下文

每个 Task 完成时，实现摘要写入 context.md。下一个 Task 先读再写。这不是简单的"记住之前做了什么"------它传递的是决策和约束：

shell 复制代码

## TASK-001 摘要: GameLoop 60FPS accumulator模式, Canvas 256x240 NES分辨率,
  constants.ts含完整物理常量
## TASK-003 摘要: PhysicsEngine半隐式欧拉积分, Mario实体(小/大/火焰状态机)

后续 Task 不需要猜"之前那个人用了什么方案"------白纸黑字写在上下文里。

3. 独立的代码审查阶段

TASK-010 是代码审查，它发现了 8 个严重问题：

问题	严重程度
SpatialHash 构建了但没有被查询，碰撞还在用 flat 遍历	严重
Mario 短跳速度 -2.0，文档要求 -4.5，与 NES 原版不符	严重
每帧大量临时对象分配（Vector2/AABB/new Set/数组展开），GC 压力大	严重
瓦片渲染器存在重复实现	警告

这些发现说明两件事：

AI 写的代码不完美 --- 这很正常
但问题被系统性地识别出来了 --- 这才是关键

没有代码审查，这些问题会一直潜伏。有了审查，每个问题都被记录、分级、可追踪。

干货二：零外部资源背后的设计决策

整个游戏没有任何外部素材文件。像素精灵用 SpriteData 调色板程序化绘制，音效用 Web Audio API 方波合成。

这不是炫技。这是约束驱动的结果：

原始需求写了"所有图形用 Canvas 绘制像素图，无外部素材文件"和"所有音效用 Web Audio API 程序化合成，无外部音频文件"。OpenMatrix 把这两条当作硬约束，不是建议。

结果是一个极其干净的项目：30 个 TypeScript 文件 + 4 个关卡 JSON，npm install && npm run dev 就能跑。没有图片 CDN，没有音频加载失败，没有跨域问题。

这验证了一个原则：好的约束产出好的架构。当你告诉 AI"不能用外部资源"，它反而会设计出更优雅的程序化方案。

干货三：TDD 不是口号，是执行顺序

看 Task 的实际执行顺序：

yaml 复制代码

TASK-001: Phase 1 实现 → TASK-003: Phase 2 实现（并行）
                                    ↓
TASK-002: Phase 1 测试 ← 结果回传 ←┘
                                    ↓
TASK-004: Phase 2 测试

实现先跑，测试紧随其后。不是"先写完所有代码再补测试"，而是每个 Phase 独立完成实现+测试闭环。

这意味着 Phase 3 开始写关卡的时候，Phase 1 的 91 个测试已经在守着基础框架了。如果 Phase 3 的代码破坏了 GameLoop 或 EventBus，那 91 个测试会立刻拦住。

最终数字：611 个单元测试（覆盖率 95%）+ 160 个集成测试（跨模块协作）+ 31 个 Playwright E2E 测试（浏览器真实运行）。三层防护网。

诚实的总结

这个项目不是完美的。代码审查发现了 SpatialHash 写了没用、短跳速度和文档不一致、GC 压力大等问题。如果这是一个商业项目，这些都需要修复。

但这个项目证明了一件事：给定结构化的执行流程，AI 可以在复杂项目中保持架构一致性，产出远超"凑合能用"的结果。

5 小时，3,900 行代码，802 个测试，4 个可玩关卡，架构零漂移。

你的下一个项目

bash 复制代码

npx openmatrix start "你的项目描述"

OpenMatrix 会自动分析需求、拆解任务、执行并验证。你只需要提供设计文档和质量要求。

马里奥项目是一个游戏，但同样的机制适用于任何复杂项目 --- API 服务、前端应用、CLI 工具。架构漂移的防护不取决于你在写什么，取决于你用什么流程。

OpenMatrix 是开源的 AI 原生任务编排框架。了解更多：GitHub | 文档 | Discord