用 AI 随性编码打造 Minecraft Mod

{/ eslint-disable react/jsx-no-undef /}

如果你还不太了解 Minecraft 模组社区的规模，那它真的非常庞大。有些模组的制作精良程度甚至超过了众多3A大作。

最好的例子就是 创作：

{

}

所以当我时隔许久再次开始游玩时，确实有点不知所措。

目录

问题

随着我和几位朋友开始玩“Divine Journey 2”模组包， 面对数量庞大的模组化方块和物品，我感到应接不暇。

举个例子，仅来自16个模组的“发电机”就有54种：

{OpenAI Codex（命令行工具）、克劳德密码 和 光标 帮了我一把：

• TileFinder（GitHub、诅咒锻造）：可以搜索、筛选，并轻松定位所有模组中的 TileEntity（复杂方块）

• 未命名的项目管理模组：一款用于多人游戏的模组项目管理工具

在开发这个项目的过程中，我完全没有受到任何伤害，也没有编写任何Java代码。关于模型和编码体验的更多信息见下文；如果你对这些模组不感兴趣，可以折叠这部分内容。

TileFinder

{

点击展开

你可以绑定一个快捷键，打开一个界面来筛选并搜索你附近的特定方块：

当你选中某个物品时，会有一条（完全可配置的）路径指向它。

}

未命名的项目管理模组

{

点击展开

我和朋友们在这个模组包里有很多任务要做（它有一个庞大的任务系统和进度机制），而要跟踪我们需要的物品或各项子任务也变得很麻烦。

有一次，我的朋友半开玩笑地提议用类似Jira的东西来管理。这说明情况已经很糟糕了。不过说句公道话，他们当时还不知道Linear。

我原以为这款模组因为支持多人模式会更难开发，我还希望实现完全的实时同步。但结果依然没什么难度——添加支持几乎是一次性搞定的。

o3漏掉了（或者不知道需要）给一个本该只在客户端运行的函数加上@annotate注解；在重新构建后，它自己就修复了这个问题。我记得当时的错误信息并没有提示如何解决，但好在LLM知道正确的注解方式。

下面可以看到两个客户端同步的视频：

此外，你也可以使用斜杠命令，而不用通过GUI操作。

}

关于“氛围式编程”的心得

• o3是一款很棒的代理型模型。它的降价使其比Sonnet 4更便宜。

• Sonnet在我试用时的表现也不错，但我觉得它在利用工具探索代码库等方面整体表现稍逊一筹。唯一的例外是当我在Claude Code中使用时，Sonnet的表现非常出色。

• 发现常见错误时就编写规则文件。我发现所有模型都会反复遍历整个代码库，结果带回大量编译后的无用文件，这会不必要地占用上下文空间。

添加规则文件（自动注入到上下文中的文件）就能解决这些问题。

• OpenAI Codex作为命令行工具，表现尚可但不算特别出色。我没有试过他们的网页版，可能更好一些，但我不确定能否为它搭建起完整的环境，从而形成真正的代理式反馈循环。

• 我本可以用我尝试过的任何工具完整地开发出每一个模组。不过显而易见的是，对于我这样的开发者来说，Cursor与o3的组合无疑是效率最高的。

关于开发工作的几点体会

• 错误信息应当提供修复建议。 • 如果没有明确的单一修复方案，它们可以给出多种解决方案，或者用通俗的语言解释问题产生的原因。无论如何，后一种做法都应该做到。

• 需要更多围绕指定软件包版本的（AI）工具。 • Minecraft比较棘手，因为它有多个版本，且每个版本都可能引入破坏性变更，而LLM是在所有版本上进行训练的。我认为我能取得不错成果的一个原因是，我针对的是一个以模组丰富著称的较旧版本（1.12.2）。

• 在工作中我也遇到过类似的问题，比如npm包和各类库。像背景7这样的工具或MCP能在这方面提供很大帮助。

这两款模组总共花费了我约8美元的使用费用。