附加包开发工作流¶
这篇教程给出一个可持续迭代的附加包开发流程。目标不是“先做完再修”，而是把规划、实现、测试和发布串成一个闭环，让问题尽量在早期暴露。
来源说明
本页基于Microsoft Learn文档《Add-On Development Workflow》整理，并按本站术语与目录体系重写。
第一步：先规划，再动手¶
开始写文件前，先把需求写成三组清单：
- 必须完成的核心功能。
- 可以延后的增强功能。
- 目标玩家与目标平台。
接着确定包结构。资源包与行为包至少都需要manifest.json，其余目录按功能增量添加，不必一次建齐。
第二步：准备开发环境¶
建议使用以下工具组合：
- Visual Studio Code：编辑JSON、Molang、函数和脚本文件。
- Blockbench：制作模型与动画。
- Snowstorm：制作粒子特效。
- Minecraft Creator Tools：快速初始化项目结构与构建脚本。
如果项目包含脚本模块，初始化后先安装依赖：
第三步：建立“构建—测试—修复”循环¶
每次功能迭代都按同一节奏执行：
- 明确本轮只交付一个小目标。
- 编写JSON、Molang和脚本。
- 部署到开发目录并进游戏验证。
- 根据内容日志和实际表现修复问题。
- 通过后再进入下一轮。
推荐把测试世界固定为“开启作弊+创造模式”，并按功能建立可重复的验证清单，例如“实体生成”“掉落逻辑”“多人同步”“与其他包共存”。
第四步：正确使用重载¶
/reload只能覆盖一部分内容类型。实践中可按下面策略执行：
- 方块、实体、物品定义：先尝试
/reload，失败再重进世界。 - 脚本逻辑：优先
/reload，并观察是否出现重复订阅。 - 纹理、模型、音效：默认重进世界验证。
这样可以降低无效重启次数，同时避免把缓存问题误判为逻辑问题。
第五步：版本控制与发布¶
建议尽早接入Git并保持小步提交：
- 每完成一个可验证功能就提交一次。
- 提交信息写清“改了什么、为什么改”。
- 大功能用分支开发，稳定后再合并。
发布前至少完成三项检查：
- 更新
manifest.json版本号与变更记录。 - 在干净测试世界中完成一次完整回归。
- 打包为
.mcpack或.mcaddon并再次导入验证。
一份可直接复用的最小流程¶
如果你想马上落地，可以直接按这份顺序执行：
- 规划目标与目录。
- 初始化项目并安装依赖。
- 完成一个最小可运行功能。
- 用内容日志排错并修复。
- 提交版本控制。
- 打包发布并复测。
当流程固定下来后，后续做新实体、新方块或新系统时，成本会显著下降。