从一份文档，到一个真正能跑的项目
这次项目的起点，并不是代码，也不是某个具体的技术选型。
而是一句很朴素、但我一直没真正验证过的问题：
当 AI 不只是写 Demo，而是被放进完整工程流程中，它到底能做到什么程度？
为了回答这个问题，我刻意选了一个“边界清晰、但不简单”的项目——
一个基于 Canvas 的 H5 轻量级游戏。
它足够小，不需要庞大架构；
但也足够完整，必须经历设计、实现、运行、调试的全过程。
一切从“文档”开始，而不是从“写点代码”开始
很多人用 AI 写代码，都是从一句类似这样的话开始的：
“帮我写一个 XX 功能。”
但这一次，我刻意反过来。
我先让 Claude 做的，不是“生成代码”，
而是像一个真正参与项目的人一样，把事情想清楚。
输出的是一份偏产品、但足够工程化的文档，包括：
- 游戏核心机制与最小可玩闭环
- 状态机设计（开始、运行、失败、重置）
- 难度增长与数值上限的控制方式
- 移动端操作、屏幕尺寸与交互限制
- 哪些内容是“可配置的”，哪些是“写死的”
这一步的价值，在真正进入编码阶段后体现得非常明显：
几乎没有出现方向性返工。
进入编码阶段：让 Claude 真的“写完整项目”
在实现阶段，我没有把 Claude 当成“代码片段生成器”。
而是明确地让它承担一个角色：
主导编码，持续推进整个工程。
具体表现为：
- 按文件、按模块逐步生成代码
- 明确每个模块的职责与边界
- 在已有代码基础上继续扩展，而不是推倒重来
例如：
- Canvas 渲染循环如何组织
- 游戏引擎类如何封装更新与绘制
- 状态如何与 UI 组件解耦
- 输入事件如何映射到核心逻辑
这些并不是“写一个函数”就能完成的事情，
而是需要 长期保持上下文一致性 的工程任务。
这一点上，Claude 的表现非常接近一个“会持续记得自己写过什么”的工程成员。
Codex 的介入点：不是主导，而是“精修”
当主体结构已经完整、代码可以运行后，
Codex 才开始大量介入。
但它的角色并不是“再写一套代码”，
而是在现有基础上处理细节与问题。
主要集中在几个方面：
- 补全遗漏的边界逻辑
- 修正运行中暴露的小 Bug
- 优化某些不合理的实现方式
- 对测试中出现的问题做针对性修改
例如：
- 重启游戏时，某些状态没有被完全回收
- 不同设备上输入事件触发顺序不一致
- 某些数值增长过快，影响可玩性
这些问题非常“工程”，
也非常适合 Codex 这种 局部理解能力强、修改精确 的模型来处理。
当项目真的跑起来，AI 的“短板”开始显现
有一个很现实的阶段，绕不过去：
当项目第一次完整跑起来之后，AI 的能力边界会非常清晰地暴露出来。
比如：
- 操作“手感”是否合理
- 动画节奏是否符合直觉
- 游戏失败是否让人有继续尝试的欲望
这些东西，没有标准答案，
也无法通过纯逻辑推导得出。
这一阶段，AI 更像是一个可以随时咨询的助手，
而不是决策者。
但正是这种“边界感”，让我对它在工程中的定位更清楚了。
一个被反复验证的结论
在完整走完这条流程之后，我反而得到了一个相对克制的结论：
AI 的价值，不在于替你完成项目，而在于加速你完成项目的过程。
前提是三点：
- 你要给它清晰的结构
- 你要让它参与真实运行与反馈
- 你不能把判断权完全交出去
一旦离开这三个前提，
AI 很容易退化成“看起来很厉害”的内容生成器。
这次实践留下的真正成果
最终留下的，并不只是一个可以玩的 H5 游戏。
而是：
- 一套可复用的轻游戏工程结构
- 一条从文档到代码再到运行的实践路径
- 对 AI 在真实工程中“能做什么、不能做什么”的清晰认知
这比任何单次生成结果，都要有价值。
写在最后
这次实践让我越来越确定一件事：
未来的开发方式，一定不是“人写 or AI 写”，而是“人 + AI 一起写”。
区别只在于——
你是否愿意把 AI 放进真实工程流程中，而不是停在演示阶段。
如果你对这种
从文档 → 主导编码 → 运行打磨的 AI 工程实践感兴趣，
相关记录与延伸内容在这里：
