关于 · About — 天工引擎

天工引擎是一个 AI 原生的个人游戏工作室。我们相信：做游戏的门槛，正在被 AI 重新定义。

我们的愿景很直接 —— 让更小的团队，借助 AI，做出过去需要更大团队才能完成的游戏。不是取代创作者，而是把"把想法变成可玩游戏"中间那一大段繁重的工程与制作，交给 AI 去扛。

我们走在哪一步

当前阶段是 用 AI 把想法做成可玩游戏：已经能在工作室里做出 FPS、ARPG、生存、射击等多款可玩 demo，引擎覆盖了 PBR 渲染、物理、骨骼动画等能力。这一阶段会持续打磨，把"AI 写出能出货的游戏"推进到更高的完成度。

开源

天工引擎的工具层采用 Apache License 2.0 —— 任何人都可以自由 fork、使用、商用与二次发布。我们希望它成为一个开放、可被社区共建的项目。详见版权说明。

让更小的团队，做出更大的游戏。

你在工作室里向一个叫 Forge 的 AI 主创描述你想要的游戏 —— 可以用对话，也可以在可视化编辑器里直接动手，未来还会支持图片、视频等更多输入。它会规划、必要时叫上各司其职的子 Agent（玩法、设计、美术……），然后自己编写引擎代码，结果实时热重载到浏览器预览里。

这背后有两块自研的底座：一个为 AI 视角重新设计的天工引擎（让 AI 读得懂、写得动、错得明白），和一套引导 AI 持续收敛到正确结果的开发流程（需求进、可玩产物出，中间每一步可观测、可回溯）。

七步闭环

在引擎内部，每个功能都经过同一条流水线 —— 需求进、可用产物出，中间每一步都留下可读的记录：

需求 —— 把要做什么写清楚，带验收标准。
研究 —— 查历史、约束与可选方案。
计划 —— 定策略，拆成可执行任务。
实现 —— 写代码 + 测试。
验证 —— 多方独立检查，任一不过就拦下。
验收 —— 人来把最后一关。
合入 —— 通过后并进主干。

编排者 + 子 Agent

一个"编排者"推进这条状态机，决定每一步派哪个子 Agent、并检查它的产物；子 Agent 各有角色、各自独立上下文。人类只在两个出入点注入判断：提需求和做验收。

不让"看起来过了"溜过去

验证步里有两道 AI 关卡：一个以 AI 用户视角静态扫文档与 API，抓"承诺了却没实现"；另一个在隔离沙箱里真跑 demo、截图，再回头核对画面对不对 —— 防止"测试假绿、画面却是黑的"。

越跑越稳

每个功能跑完，过程里遇到的痛点会沉淀成反馈，反过来升级流水线本身。下一个功能自动用上更新后的版本 —— 流水线吃自己的产物，越跑越懂。

结果是：AI 写出来的不是"demo 级"代码，而是经过验证、可重放、能被人接手的功能。

四块东西协同工作：

天工引擎 —— TypeScript 写的 ECS 引擎，双 RHI 渲染（WebGPU + 一套 wasm 后端）、PBR/IBL/SSAO 渲染、2D/3D 物理、glTF/FBX 资产与骨骼动画。它的 API、错误与状态都为 AI 读写而设计。
自进化开发闭环（ForgeAX closed loop） —— 七步闭环（需求 → 研究 → 计划 → 实现 → 验证 → 验收 → 合入），由编排者驱动一组角色化子 Agent，内置 AI 评审与"真跑 + 截图"的沙箱验证；它吃自己的反馈持续进化，越跑越稳。
AI 原生玩法 —— 不止用 AI 做游戏，还支持把 AI 做进玩法本身：智能 NPC、生成式内容、可交互的 AI 体验。
工作室与编辑器 —— 对话区紧挨实时预览，可视化场景编辑器的改动直接回流到运行中的游戏；网页或桌面应用皆可。
Agent 团队与创作工具 —— 制作、玩法、设计、叙事、美术、编码各有命名 Agent；还有一整套扩展页面插件，生成角色、动画、3D 模型、特效、UI、音乐等。

大多数游戏引擎的 API 是给人写的。当写代码的主力变成 AI，引擎就该换一种长法。

ForgeAX 的核心是：用户描述游戏，AI 来写引擎代码。这听起来只是"换个人写代码"，但真正做下去会发现，现成引擎对 AI 并不友好 —— 它们假设的读者是一个能看文档、能猜、能脑补上下文的人类。

我们的取舍很简单：AI 是引擎的第一用户。当"对 AI 友好"和"对人友好"冲突时，优先 AI。 下面是几个具体的做法。

一、单一可信源，其余派生

同一个事实只有一处定义，其他地方都从它派生。比如组件的字段定义内联在 schema 里，inspector、调试器、工具链直接读 schema，而不是去 grep 源码瞎猜。AI 不需要"记住"散落各处的约定，因为约定只有一处。

二、错误要让 AI 看得懂、能恢复

错误不是 throw 一句人话就完事。我们用闭包的错误码，每个错误自带"这是什么、为什么、怎么恢复"的结构化信息。AI 拿到错误，能直接知道下一步该改哪里，而不是把异常文本当成玄学。

三、用结构化数据代替"看显示器"

渲染 bug 最难的地方在于"它在屏幕上看起来不对"。人可以盯着显示器调，AI 不行。所以引擎支持把一帧的渲染调用录下来 —— draw call、绑定、渲染目标、管线状态都能离线读取、重放、定位到第 N 次绘制时的完整状态。视觉问题被转成了 AI 能 Read 的数据。

四、双实现互相验证

渲染层有两套后端实现（WebGPU 与一套 wasm 实现），走同一套接口。它们同时出图：一旦 AI 把引擎 API 用错了，另一套后端会立刻表现出不一致，问题随即暴露。这比"等人来 review"快得多。

这些设计有一个共同的衡量标准：读者（无论人还是 AI）要装进脑子里的概念越少越好。 API 越自洽、越能就地索引，AI 写对的概率就越高，人来接手时也越省心。

AI 原生不是一句口号，而是一连串"为 AI 视角重做一遍"的具体决定。我们会在文档和后续更新里，把这些逐步展开。

在 GitHub 关注我们

关于天工引擎