更新与发布

Jundot 的更新与发布流程服务于两个目标：让用户验证过的修改可以上传 GitHub；让足够通用的引擎能力可以整理、打包并进入后续版本。

两条流程

项目修改流程

当 AI 创建游戏、修复报错或优化性能后，用户需要先在本地验证结果。验证通过后，AI 可以帮助整理提交说明并上传 GitHub。

用户提出项目需求或错误现场
        ↓
AI 修改项目
        ↓
AI 运行检查或读取用户验证结果
        ↓
用户确认可用
        ↓
AI 整理改动说明
        ↓
AI 提交并上传 GitHub

引擎改动流程

当当前引擎能力无法满足项目需求时，AI 可以在用户确认后修改引擎。这个流程要比普通项目修改更谨慎，因为它会影响更多项目。

项目需求无法用当前引擎完成
        ↓
AI 说明为什么需要改引擎
        ↓
用户确认
        ↓
AI 修改引擎
        ↓
在当前项目中验证
        ↓
判断是否足够通用
        ↓
通用能力整理进主引擎
        ↓
Package Builder 打包
        ↓
Launcher / Releases 分发更新

Jundot Package Builder

Package Builder 是 Jundot 的图形化打包工具，用于构建和整理引擎发布产物。

• 选择平台、架构和构建配置。
• 管理版本号和发布配置。
• 生成编辑器、导出模板和发布包。
• 生成更新清单，供 Launcher 检查版本。
• 整理发布说明，让用户知道本次更新改了什么。

Jundot Launcher

Jundot Launcher 负责在启动前检查更新，并在用户确认后执行下载、校验、备份和安装。

• 检查远程 update-manifest.json。
• 比较当前版本和目标版本。
• 下载更新包并进行校验。
• 安装前备份当前版本。
• 必要时回滚到旧版本。

GitHub 上传

Jundot 的 AI 工作流可以在用户验证后帮助上传修改。推荐把上传前的检查写清楚：

1. 说明本次改了哪些文件。
2. 说明用户如何验证。
3. 确认没有把 API Key、私有路径或临时文件提交进去。
4. 生成清晰的 commit message。
5. 推送到 GitHub 分支或创建 Pull Request。

通用能力如何丰富主引擎

不是每个项目专用改动都应该进入主引擎。进入主引擎前，建议判断：

• 是否有多个项目可能需要这个能力。
• 是否能用清晰的设置项或工具入口表达。
• 是否增加过高维护成本。
• 是否有验证用例或真实项目证明它有价值。
• 是否符合 Godot/Jundot 的编辑器和引擎设计习惯。

发布说明

发布说明应该描述真实变化，而不是只列构建产物。建议包含：

• 新增功能。
• 修复的问题。
• 对 AI 工作流的改进。
• 可能影响旧项目的行为变化。
• 已知问题和回滚建议。

常见问题

Q: AI 每次都会改引擎吗？

A: 不会。能用当前引擎完成的项目需求，应优先在项目内完成。只有当前引擎能力不足时才进入引擎改动流程。

Q: 项目专用功能一定会进入主引擎吗？

A: 不一定。只有足够通用、可维护、经过验证的功能才适合整理进主引擎。

Q: AI 可以直接上传 GitHub 吗？

A: 工作流目标是用户验证通过后由 AI 帮助提交和上传。正式项目建议先检查差异、确认没有敏感信息，再让 AI 推送。