PROJECT P0B
开发中

FIELD NOTES

NOTE 00 · THE PIPELINE

一个人、一个仓库，和一条 AI 参与的制作管线

关于 PROJECT P0B 是怎么被造出来的：技术栈怎么定的，AI 在哪些环节真正有用，以及在哪些环节我不得不换路线。

文 / LIU YICHENG约 14 分钟

以下内容是开发者的个人记录，涉及内部里程碑、技术选择与失败过程。它描述的是当前状态，不是最终形态，也不构成任何发布承诺。

先说清楚这不是什么

这不是一篇「我用一句提示词做出了一款 MMO」的文章。

PROJECT P0B 是我一个人的项目。仓库里有 Godot 客户端、Nakama 服务端、一套确定性的资产管线、 一堆 Python 校验脚本，以及一份长到不太礼貌的审批与决策记录。AI 深度参与了其中的很多环节， 但它参与的方式，和大多数人想象的不一样。

最准确的描述大概是：我负责决定什么算完成，AI 负责把工作做到那个标准，然后由机器来证明它真的做到了。

下面是这条管线的实际样子。

一、先定边界，再让 AI 动手

在写第一行代码之前，我先冻结了几件不允许 AI 自由发挥的事：

  • 引擎版本锁死：Godot 4.7.stable.official.5b4e0cb0f，Forward+，GDScript。
  • 服务端锁死：Nakama 3.39.0 + PostgreSQL 16，服务端逻辑跑在 TypeScript 沙箱里 （没有 Node 的 fs 和 crypto 可用，这个限制后来影响了不少设计）。
  • 风格合同锁死：世界风格有一张唯一的基准图，带 SHA-256。任何「重新生成一张更好的基准图」 的提议都要走单独审批。
  • 权威边界锁死：联机权威用整数 XZ 模拟，地形语义哈希 c1e82575… 被钉死在内容包里。 一切视觉——大气、地形 v2、画质档位、语言、视觉后端——按规范都是表现层，永远不能进入联机身份。

这些边界不是为了限制 AI，而是为了让「失败」可以被定位。当你把技术栈、验收标准和版本规则都固定下来之后， 一次失败就只可能来自一个地方；否则你永远在猜。

仓库里因此长出了一套治理机制：docs/APPROVALS.md 记录我作为项目所有者的批准（A-xxx）， docs/DECISIONS.md 记录对应的决策（D-xxx）。安装新依赖、翻转一个运行时默认值、 远程部署、超预算的付费生成——这些都需要一条新的批准记录，AI 不能自己决定。

二、AI 真正擅长的那一段

在明确边界内，AI 的产出质量高得惊人。它做得最好的是这几类：

范围明确的实现工作。 给它一份写清楚的规范和一组验收条件，让它写协议序列化、写预测/回滚、 写确定性烘焙脚本——这类工作它做得又快又稳。P1-WP1 的 30 Hz 移动协议、 客户端预测与和解、内容哈希向量在 TypeScript 和 GDScript 两侧的对齐，都是这样完成的。

测试和证据整理。 这一点被严重低估了。这个项目里几乎每个模块都有配套的校验器： P0B 结构检查 332 项，P1-WP2 的生产/校验面 229/229 离线测试通过， 服务端 npm run verify 是 206 个测试里 204 通过、0 失败、2 个显式声明的历史跳过。 这些不是我一条条手写的。让 AI 写「能把自己证伪的测试」，比让它写功能代码更有价值。

把混乱的产物收敛成可追溯的记录。 每一次正式捕获都会生成一个证据目录：截图、日志、 性能采样、SHA-256 清单。整理这些东西极其枯燥，而 AI 从不嫌烦。

图像工作。 概念图、参考画面、截图再渲染、网页视觉素材。这个网站上你看到的每一张图， 都是从开发中的实机画面出发，再经过再渲染得到的。远景层也是这样做的： 游戏里森林战场和城镇原本会在地图边缘「断掉」，我用生成图做了一层纯表现的远景贴图 （战场是 1024x1024 不透明纹理，城镇是 2048x768 带透明的弧面）， 它们不含碰撞、导航、权威状态，也不影响任何玩法。生成 ID、输入哈希、输出哈希、 后处理命令全部落盘在 image2_provenance_v1.json 里。

三、AI 做不好的那一段

让大模型直接给我一个能进游戏的 3D 角色，这条路没有走通。

我最初的想法很朴素：我已经有角色设定图了，那么让模型直接从设定图推导出可用的三维模型， 应该是最短路径。结果很快暴露出问题——结构不成立、手部不可读、武器轮廓糊成一团、 正视图和顶视图根本不是同一个物体的两个投影。

问题不在于「生成得不够好看」，而在于它生成的东西无法被验证。 我没有办法对着一个语义模糊的网格说「这里错了」，因为我说不清「这里」是哪里。

所以我换了路线，把一个大任务拆成一串更窄、每一步都能单独判定通过或失败的环节：

  1. 先用设定图和生产图把视觉意图固定下来，包括正/侧/背/顶的一致性；
  2. 由 Meshy 处理基础几何（image-to-3D / multi-image-to-3D）；
  3. 本地工具做网格与结构修复、比例修正、拆件；
  4. 刚性部件绑定与动画适配；
  5. 导入 Godot，实机验证；
  6. 我本人做视觉审批。

关键在第 6 步：机器合同全部通过，仍然可能被我否掉。这两件事是分开的。

这条路线的细节我写在了 角色那一篇 里，包括第一版被我打回来的具体原因。

四、把踩过的坑写成规则

Goblin 和 ordinary Minotaur 的保真度恢复做了 Phase A、Phase B Wave-1，以及 Wave2 的 v2 到 v6。这个过程很不体面，但它产出了这个项目里我最满意的一份文档：一张「踩坑 → 浪费 → 以后固定规则」的表。

摘几条：

  • 无纹理的 Meshy GLB 不要指望它带着概念颜色。 should_texture=false 只负责几何， 颜色权威必须单独绑定设定图色板和语义区。
  • 一个候选只回答一个假设。 禁止用多次随机重掷同时试颜色、拓扑、姿势和武器—— 这样你永远不知道是哪条规则改变了结果。
  • 最便宜的失败必须最先发生。 输入投影一致性、朝向探针、组件存在性检查， 全部要在昂贵的正式捕获之前完成。有一次朝向 yaw 错了，一直到完整派生之后才发现， Goblin 的双耳探针为零，整条候选链作废。
  • 沉没成本不改变门。 「反正已经付费了」是这个流程里最贵的一句话。 质量不合格的候选不进候选集。
  • 武器不走付费几何路径。 有独立武器板时，武器始终走本地确定性构建； Meshy 不用于修武器轮廓或握点姿态。

这些规则现在是强制的伴随合同，和主工作流文档一起生效。

五、分工

写到这里，各方的职责其实已经很清楚了：

| 角色 | 负责 | | --- | --- | | 我 | 技术栈、设计边界、验收标准、版本规则、视觉审批、什么算完成 | | LLM | 范围明确的实现、测试、脚本、证据整理、文档 | | Meshy | 基础几何——只在明确的几何缺陷上，一次一个假设 | | 图像生成 | 概念图、参考画面、再渲染、表现层贴图、网页素材 | | 自动化脚本 | 确定性烘焙、校验、封存、拒绝覆盖已有证据 |

有一条我想强调：AI 是制作管线的一部分，不是美术判断和技术判断的替代品。

它可以把一件事做到我定义的标准，但它不能替我定义标准。它可以生成二十个候选， 但它不能告诉我哪一个是对的。它可以写出通过所有测试的代码， 而「所有测试」本身是不是问对了问题，仍然是我的责任。

六、现在的状态

  • Phase 0 已经关闭；本地的完整纵切片（Hub → 远征 → 结算 → Hub）跑通并通过了手动验收。
  • Phase 1 是联机部分。P1-WP1（权威移动实验室）已封存并获批；P1-WP2（在线单人/协力战斗） 已授权，但必须停在 P1-B 决策点；P1-WP3（社交城镇）机器层面完成，等待人工决策。
  • 天气是表现层能力，默认仍是 warm_day。
  • Metal GPU 的 Phase 1 目标 <16.67 ms 仍然没有达成——它被推迟了，不是被通过了， 也不是被豁免了。我在文档里把这一条单独标了出来，因为这正是最容易被含糊过去的那种事。

游戏还在开发中。这篇记录写的是现在，不是终点。