你把崩溃报告粘贴给 ChatGPT，它却信誓旦旦地点名一个根本不在你整合包里的模组。你要一份 KubeJS 配方，得到的却是 event.recipes.minecraft.shaped(...)——这是与当前 KubeJS 配方示例不符的旧语法。你要一段 FTB Quests 区块，它却给你 JSON 风格的逗号，而这可能破坏 1.21.1 时期任务文件所用的多行 FTB SNBT 格式。
坏掉的不是工具，而是提示词。AI 模型常常退回到更老的 Minecraft 模组开发示例，这对当前的 KubeJS 和 FTB Quests 文件相当危险。把确切的游戏版本、加载器构建号、目标文件格式，以及一段来自你自己代码的可用示例交给模型，输出就会从“自信地出错”变成“大体正确，其余自行核验”。
这才是关键：这些提示词在你已经付费的助手里就能用（ChatGPT、Claude、Copilot），无需注册崩溃分析工具，也无需额外订阅。它们也默认你已经看得懂输出。AI 生成的 KubeJS 对懂 KubeJS 的人来说是起草捷径；如果你认不出被凭空捏造的物品 ID，AI 生成的 KubeJS 反而会咬你一口。下面是五个针对具体任务、明确指定版本的提示词，每个都附有真实的返回示例，以及它会在哪里出错的说明。
TL;DR（太长不看版）
最好的 Minecraft 整合包开发 ChatGPT 提示词每次都提供三样东西：确切的 Minecraft 版本、确切的模组加载器及其版本，以及一段来自你自己代码库的可用示例。有了这些上下文，AI 才能为崩溃排查、KubeJS 配方、FTB Quests 的 SNBT、模组候选名单和提交信息给出更有用的初稿。但每一个物品 ID、每一次 API 调用、每一个十六进制任务 ID 都得由你自己核验。AI 能让一个称职的模组作者更快，却写不出一个整合包。
这些提示词做不到的事
在复制任何内容之前，先摆正预期：
- 它们不会替你做出一个整合包。 每个提示词只起草一件产物（一条配方、一段任务区块、一份诊断），由你放进本就在设计的整合包里。
- 它们不会教会你 KubeJS 或 SNBT。 如果下面的语法对你来说很陌生，那些失效模式就会从你眼皮底下溜走。先把格式学会，再用 AI 提速。
- 它们替代不了一台真正的测试服务器。 AI 只能对堆栈跟踪进行推理，却无法告诉你这个整合包在加载 150 个模组后真的能启动。
- 它们不保证输出正确。 把 AI 返回的一切都当成需要你复核的初稿，而不是最终答案。
为什么 AI 动笔之前需要正确的上下文
一个管用的提示词和泛泛的“给我做个 Minecraft 配方”之间的差别，就在于上下文。省掉版本和加载器，模型就可能给你的 1.21.1 NeoForge 整合包生成旧版 KubeJS 语法、编造不存在的物品 ID，或者把 FTB SNBT 当成普通 JSON 来排版。脚本要么毫无反应，要么带着一条埋在日志深处的错误崩掉，而那份日志你终究还是得读。
因此本文中的每个提示词都带着同样的三段式上下文，由你根据自己的整合包填空：
- 确切的 Minecraft 版本： 1.20.1、1.21.1，或者你实际在用的那个版本。
- 确切的模组加载器及版本： Forge、NeoForge、Fabric 或 Quilt，外加构建号。
- 一段来自你自己代码库的可用示例，只要你能提供就提供。一条来自你
server_scripts/的真实配方、一段有效的任务区块、一条以往的提交信息。这是提升质量最有力的一招：比起自己猜出来的 API，模型会更忠实地模仿你递给它的风格和写法。
专业提示： 版本那一行不是可有可无的点缀。面向 Minecraft 1.20.1 的 KubeJS 6.x 和面向 Minecraft 1.21.1 的 KubeJS 7.2.x 是两个不同的目标，而具体安装的构建号同样重要。一个省略了游戏、加载器和 KubeJS 确切版本的提示词，等于是在请模型猜。
提示词：崩溃日志分诊
这个提示词能把一整墙堆栈跟踪变成一份带排序的可疑模组清单和一个明确的下一步，是绕开盲目二分查找的最快方式。
You are helping me diagnose a Minecraft crash. Here is the context:
- Minecraft version: 1.21.1
- Mod loader + version: NeoForge [paste your exact build]
- What triggered it: crash on world load, ~150 mods
- (If it looks like a missing-dependency error, I'll paste the mod list too)
Here is the full crash report (or the first 100 lines plus every Caused by: block):
[paste the crash-report text or the top of latest.log]
Tell me:
1. The most likely cause, in one sentence.
2. A ranked list of the 2-3 mods most likely involved and why.
3. The single next step you'd take to confirm which one it is.
Keep it short. Don't guess at mods that aren't in the trace.一个真实的回答大致是这样：
可能原因：加载世界时发生 mixin 冲突。可能有两个模组注入了同一个类。可疑对象：(1) 栈帧 org.spongepowered.asm.mixin.transformer 指向一个未能应用成功的 mixin，拥有目标类的那个模组就是头号嫌疑。(2) 上一层栈帧出现了第二个改动实体渲染的模组。(3) 可能性较低的是崩溃前刚加载的配置类模组。下一步：把这两个嫌疑模组拿掉，启动，再一次一个地加回去。这样确认这对组合，比删掉半张清单快得多。
需要调整的地方： 如果诊断回来的是含糊其辞的说法（“某个模组有冲突”），那是你给的堆栈信息不够：把完整的崩溃报告贴上去，而不是只贴前 100 行，再附上带版本号的模组清单。要是依然含糊，那就说明日志确实点不出元凶，你只能回到二分查找。
它会在哪里出错： 即便真正的原因在堆栈里的别处，AI 也会一脸笃定地点名某个“罪魁祸首”模组。把它的回答当作带排序的假设，而不是判决。真正的确认，靠的是你动手拿掉模组再启动。
这一步正是大多数人会跳过的。AI 读得懂堆栈跟踪，却无法告诉你整合包在真实条件下能干净启动，因为有些崩溃只在多个模组于服务器上同时初始化时才出现，而不是在快速的单人启动中。这时候你需要的，是一台 用完即弃的测试服务器。Cloudzy 的应用市场也提供 一键部署的 Minecraft Forge 运行在 Ubuntu Server 24.04 LTS 上。应用市场标注的最低内存是 2 GB，但那是平台的下限，而不是大型整合包的配置目标。小型测试包用 4 GB 内存和 2 vCPU 起步比较合理；模组超过 100 个，就从大约 8 GB 和 4 vCPU 开始，再按玩家数量、世界生成和实际性能剖析来调整。开起来，在负载下确认修复有效，然后销毁掉。
借助高速 NVMe VPS 托管，运行无延迟的游戏服务器。
游戏 VPS提示词：生成 KubeJS 配方
这个提示词会用你的整合包实际使用的那套 API 来起草 KubeJS 配方，前提是你先贴上一条来自自己脚本的可用配方，让模型照着写。
Write a KubeJS recipe for me.
- Target: Minecraft 1.21.1 / NeoForge [paste exact build] / KubeJS [paste exact installed 7.2.x build]
(For the older line, use: Minecraft 1.20.1 / your exact loader build / your exact installed KubeJS 6.x build)
- Goal: a shaped recipe that crafts 3x create:andesite_alloy from
iron nuggets and andesite.
Here is one working recipe from my server_scripts/ so you match my API style:
[paste one real ServerEvents.recipes block from your pack]
Output only the recipe, inside a ServerEvents.recipes(event => {...}) block.
Use item IDs exactly as I'd find them in-game; flag any ID you're unsure exists.指定面向 Minecraft 1.21.1 的 KubeJS 7.2.x 分支并贴上示例后，你会得到当前的 event.shaped() 写法，正如 KubeJS 配方文档:
// KubeJS 7.2.x - Minecraft 1.21.1 / NeoForge
ServerEvents.recipes(event => {
event.shaped(
Item.of('create:andesite_alloy', 3),
['III', 'IAI', 'III'],
{ I: 'minecraft:iron_nugget', A: 'minecraft:andesite' }
)
})需要调整的地方： 如果是 Minecraft 1.20.1，就写明你确切的加载器构建号和实际安装的 KubeJS 6.x 构建号，好让模型对准那条分支。要移除或替换原版配方，就明确要求 event.remove({ output: '...' }) or event.replaceInput(...) ，把方法名直接说出来，它就不会自由发挥。
它会在哪里出错： 这里主要有两种失效：凭空捏造的物品 ID（create:andesite_alloy 确实存在； create:andesite_gear 则未必）；以及你忘了写目标行时输出的错误版本代码。把每个物品 ID 都对照已安装的模组核一遍，然后把脚本丢进测试包，再去读 kubejs/logs/server.log.
专业提示： 在提出任何新要求之前，先从你自己的 server_scripts/ 里贴一个已知可用的示例，胜过在提示词措辞上下的任何功夫。比起自己一知半解记住的那套抽象的“正确”API，模型会更忠实地模仿眼前这个具体例子。
提示词：编写 FTB Quests 任务书（1.21.1 上的 SNBT）
这个提示词会用 FTB 的扩展 SNBT 格式 为 Minecraft 1.21.1 起草 FTB Quests 条目。这是整组里最难的 AI 任务，因为 SNBT 看起来像 JSON，而模型偏偏一心想把它当 JSON 处理。至于 Minecraft 26.1.2 及更新版本， FTB Quests 改用 JSON5 ，因此不要在那些版本上使用这个 SNBT 提示词。
Write an FTB Quests task block in FTB SNBT for Minecraft 1.21.1 / NeoForge.
FTB SNBT is NOT JSON. Follow these rules exactly:
- Do not use commas between fields in multiline objects.
- Match the 16-character UPPERCASE hexadecimal ID format used by my existing quests
(example: 7942A6A571A4C5EB).
- Put the required amount in the task-level count field as a long (count: 8L); keep the nested item stack count at 1.
- This is a task block only; do not add chapter-level fields such as filename or quests.
Goal: an "item" task requiring 8x minecraft:diamond.
Match this known-good block's structure exactly:
[paste a valid SNBT block from your existing chapter file]
Output only the SNBT block.让输出照着一个你已知有效的区块来写：
{
id: "7942A6A571A4C5EB"
type: "item"
item: {
count: 1
id: "minecraft:diamond"
}
count: 8L
}需要调整的地方： 如果要的是整章而不是单个任务，就让它给出章节外层结构，带上 filename 和一个 quests: [...] 列表，然后要求每个任务都有一个不重复的 16 位十六进制 ID。如果它重复使用 ID 或擅自改格式，就贴上两三个已知正确的 ID，让它照着来。
它会在哪里出错： 它会往多行 FTB SNBT 里塞 JSON 逗号，把所需数量写进嵌套的物品堆里，而不是任务层级的 count 字段；也可能生成格式不对的任务 ID。这里任何一种情况都可能让整章加载不出来，或者让任务计数出错。把每个区块都对照一个你确知可用的结构验证一遍，并在它接近 config/ftbquests/.
提示词：按主题筛选模组
这个提示词把 AI 当作找灵感的捷径（一份按主题列出的、供你去核实的模组候选名单），而绝不是关于“什么模组存在”的事实来源。
Suggest mods for a modpack with this theme: [your theme, e.g. "steampunk
automation, tech-focused, no magic"].
- Minecraft version: 1.21.1
- Loader: NeoForge
For each suggestion, give me:
- The mod name and what it contributes to the theme.
- Whether you're confident it exists for 1.21.1 / NeoForge, or unsure.
Mark anything you're not certain about as UNVERIFIED. Do not assert
availability you're not sure of; I'll confirm each one on CurseForge/Modrinth.一个有用的回答会把有把握的推荐和纯粹的猜测分开：
1.21.1 / NeoForge 上已确认的例子（具体文件请自行核对）： 创建，用于自动化和机械装置； Immersive Engineering，用于多方块机器和工业科技。UNVERIFIED：[模型无法确认的小型附属模组]。在添加任何东西之前，先去看项目页面。
需要调整的地方： 把约束收得更紧：只要那些在 CurseForge 或 Modrinth 上有确认页面的模组，并要求每个模组附一行兼容性说明（依赖、已知冲突），这样你的候选名单同时就是一份调研清单。
它会在哪里出错： AI 会毫无顾忌地编造模组名称和版本支持情况。它会杜撰出一个听着挺像回事、实则并不存在的模组，或者声称某个停在 1.19 的东西有 1.21 构建。每条建议都只是一条待你去 CurseForge 或 Modrinth 核实的线索，而不是可以直接写进模组清单的条目。
提示词：起草更新日志与提交信息
这是整组里风险最低、最可靠的 AI 任务：把你自己做出来的 diff 交给它，让它总结，它确实很擅长。
Here are the changes in this modpack update (from my packwiz .pw.toml
adds/removes/updates):
[paste your git diff or a list of added/removed/updated mods]
Write two things:
1. A Conventional Commit message (type(scope): summary + a short body).
2. A short player-facing changelog entry, with a friendlier tone and no file names.
Only summarize the changes I gave you. Don't invent changes I didn't list.喂给它一份真实的 diff，它返回的东西你是真能直接用的：
feat(mods): update Create stack and remove old storage entry
- Added Create: Steam 'n' Rails and Create Crafts & Additions
- Removed Simple Storage Network
- Updated JEI to the 1.21.1 build listed in the supplied diff各位玩家：本次更新为 Create 科技树加入了火车和电力机械，移除了变更清单中列出的存储类模组，并刷新了 JEI 配方索引。
需要调整的地方： 把语气明确说出来：提交日志要简短干脆，面向玩家的说明要更亲和一些。如果是完整发布，就把整次更新的 diff 一起给它，并要求按分组输出更新日志（新增 / 变更 / 移除）。
它会在哪里出错： 几乎没有，只要你把它限定在总结你给的那份 diff 上。唯一真正的风险是它往更新日志里塞进你根本没做过的改动，所以别让它去“猜猜还改了什么”；给它真实的 diff，并让它老实待在那个范围里。
什么时候不该相信输出（失效模式一览）
如果只记住一节，就记这一节。在上面所有任务中，AI 的失败方式就那么几种，而且都可预测；每一种都有对应的补救办法，而所需的零件你已经有了：
| 故障模式 | 出现在哪里 | 如何弥补 |
|---|---|---|
| 凭空捏造的物品 ID | KubeJS 配方、任务物品 | 把每个 ID 都对照你实际安装的模组核实；把真实 ID 贴进提示词 |
| KubeJS API 版本用错 | KubeJS 配方 | 在每个提示词里都写明游戏版本、加载器构建号和确切的 KubeJS 构建号 |
| 把 SNBT 当成 JSON（加逗号） | FTB Quests | 在提示词里直接写明“同级字段之间不加逗号”；再对照一个已知正确的区块验证 |
| 无效的任务 ID（小写／长度不对） | FTB Quests | 指定 16 位大写十六进制；先给几个有效 ID 作范例 |
| 凭空捏造的模组可用性 | 模组筛选 | 每条建议都先在 CurseForge/Modrinth 上确认，再加进来 |
两个技巧就能覆盖大部分情况。第一，在每个提示词里都写上确切的游戏版本、加载器构建号、目标格式和一段可用示例。第二，走两步流程：先生成产物，再把它贴回去，让模型对照具体约束复查一遍，比如 FTB SNBT 的分隔规则或任务 ID 的格式。逼它看第二遍，它能揪出自己相当一部分错误。
这一切都替代不了你亲自去读输出。它只是让阅读花上几分钟，而不是让你从零写起耗掉的那几个小时。
结语
只有当你让 ChatGPT 在你整合包的真实约束下工作时，它对整合包开发才有用。把确切的游戏版本、加载器构建号、目标格式和一个已知可用的示例交给它；然后把每一条配方、每一段任务区块、每一份诊断都当作必须经受日志和真实测试实例检验的草稿。这样你既保住了速度优势，又没有把它并未挣得的权威交出去。
常见问题
AI 能读懂 Minecraft 的崩溃日志吗？
能。把完整的崩溃报告贴上去，或者至少贴前 100 行外加每一段 Caused by: 区块，并附上 Minecraft 版本和加载器构建号。能力过关的模型可以读懂堆栈跟踪，并给可能的元凶排个序。用它来省掉盲目的二分查找，然后在测试实例上确认这个假设。
如何用 ChatGPT 写 KubeJS 配方？
永远写明 Minecraft 版本、加载器构建号，以及实际安装的 KubeJS 构建号。KubeJS 6.x 属于 Minecraft 1.20.1 这一支，KubeJS 7.2.x 属于 Minecraft 1.21.1 这一支。从你的 server_scripts/ 里贴一条可用配方，让它匹配你的风格；然后核验每个物品 ID，并对照 KubeJS 日志确认 API。
写 FTB Quests 时哪些提示词管用？
如果是 Minecraft 1.21.1，就把 FTB 多行 SNBT 的规则一条条写清楚：字段之间不加逗号；沿用现有任务所使用的 16 位十六进制 ID 格式；源文件用了带类型的数字后缀就保留；不要把任务级字段和章节级字段混在一起，比如 filename。附上一个已知正确的区块，并在载入之前验证结果。在 Minecraft 26.1.2 及更新版本上，FTB Quests 会把这些数据存为 JSON5，所以要改用与版本相符的 JSON5 示例。
AI 能写出好的 Minecraft 模组或整合包吗？
靠它自己不行。AI 能让一个看得懂、也验证得了它输出的开发者更快，因为起草配方、任务和诊断比从零写要快。但没有人复核的话，它并不能稳定产出能用的模组或整合包。让懂这一行的人当起草工具用，是实打实的提速；把它当成能独立署名的作者，它就会把本可避免的错误一路发出去。
我该告诉 AI 哪个 Minecraft 版本和哪个加载器？
两个都要，每次都要。写明确切的 Minecraft 版本，比如 1.21.1，以及 Forge、NeoForge、Fabric 或 Quilt 的确切加载器和构建号。缺了它们，模型可能会选用过时的、或与你的加载器不兼容的语法。在把结果带进正式环境之前，先在测试包里验证一遍。
