星火 2.0 开发文档

主题

星火 2.0 发布、调试与 AI 辅助开发流程 ​

本文面向已经创建或正在维护星火 2.0 / WasiCore 项目的开发者，说明日常开发闭环、调试路线、编辑器 MCP 使用边界，以及从内测到正式发布前需要检查什么。

如果你是第一次创建项目，先读 快速开始。那篇文档负责“从零到项目能打开、能编译、能跑起来”；本文负责“项目跑起来之后如何持续开发、验证和发布”。

TapTap 审核策略、对战平台下载地址和发布后台入口以官方公告和平台内测与线上发布指南中的公开入口为准；MCP 能力以当前安装版本的 capability 和工具 schema 为准，各环境的可用版本见部署环境与运行时环境指南。

默认路线 ​

新项目默认使用线上生产环境：安装并登录线上版星火编辑器，在线上创作者中心配置项目，使用线上版星火对战平台（PC / Android / iOS）做项目内测，再进入正式发布。外网公开测试环境（alpha）只用于需要提前验证尚未进入线上的编辑器、SDK 或客户端能力，或官方明确要求的情况。

不要让编辑器、创作者中心、对战平台和项目发布环境跨部署环境混用。alpha / production 部署环境、debug / test / formal 运行时环境、项目内测与正式环境的数据隔离，以及自定义云端资源迁移，见部署环境与运行时环境指南。具体发布和内测步骤见平台内测与线上发布指南。

当前发布状态 ​

星火 2.0 编辑器已经发布到线上，新项目默认使用线上版编辑器。当前链路已经能够自洽地产出游戏：新建项目、刷新 SDK 和 AI 上下文、编译客户端和服务端、启动调试、发布测试游戏、发起内测，并进入正式发布流程。

TapTap App 的星火 2.0 内嵌客户端已经上线。需要走 TapTap 审核和正式上架的项目，不再需要等待额外的 2.0 容器能力；项目仍然需要按平台要求完成内容审核、素材配置、合规检查、版本发布和运行环境确认。

PC 对战平台、Android 对战平台、iOS 对战平台和 TapTap App 内嵌客户端都可作为实机试玩入口，具体入口和版本以当前编辑器、创作者中心和官方公告为准。平台内测的完整闭环（从线上版编辑器发布、资源准备、后台测试模式、内测码、作者加入内测、测试者进局，到更新和日志反馈）见平台内测与线上发布指南。实际使用时重点注意：

  • 下载与当前编辑器部署环境匹配的对战平台或 TapTap App 版本；线上项目使用线上版 PC / Android / iOS 对战平台。
  • 从创作者中心后台获取测试项目的邀请码，或按新指南通过作者后台 MCP 读取/创建邀请码。
  • 作者本人可在创作者中心点击“加入我的内测”，或在配套后台更新并单独授权后让 AI 调用 author_join_my_test。随后在对战平台使用同一账号刷新内测列表，无需自行输入邀请码。测试者也可在客户端内测入口输入邀请码后试玩。
  • 平台内测码测试没有额外测试准入条件，但正常发布、后台测试模式配置、内容合规和客户端版本匹配仍然必需。
  • 内测码无效时，优先检查客户端版本、项目发布环境和后台测试配置是否一致。

文档分工 ​

推荐开发闭环 ​

选择开发入口 ​

用户已经打开目标项目的可视化编辑器时，优先使用该编辑器，包括 AI 自动编辑、构建、调试与发布。只有用户主动要求隔离时，才另起隔离宿主。MCP 暂时不可用时先诊断现有连接，不能据此自动切到 Headless。没有已打开的可视化编辑器时，再按本次任务选择入口：

情况推荐入口
用户已打开目标项目的可视化编辑器优先复用；用户主动要求隔离时，按隔离要求选择宿主
没有已打开的 GUI，已有目标项目的 Headless 会话复用现有 Headless 会话
没有已打开的 GUI，或用户主动要求隔离；由 AI 创建项目、编辑数据与触发器、构建、单客户端连服调试或发布优先使用 Headless，先检查安装版本的 capability 和工具 schema
UI Authoring、地形交互、编辑器资源预览或其他图形界面操作使用完整 GUI 编辑器
本轮明确只验证 UI、Canvas、GameGraph 等客户端局部表现已有 GUI 时优先在其中验证；无 GUI 或用户要求隔离时可用纯客户端预览
需要编排多个客户端进行联机测试完整编辑器的多人调试，或支持 debug_create_game / debug_attach_client 的 Headless；先检查当前工具 schema

Headless 调试可启动有窗口的独立游戏客户端，并通过 Runtime MCP、截图和双端日志验证实际行为。选择 Headless 后仍需运行游戏和检查画面。

重复构建、调试和查询应复用宿主及已登录账号；每轮结束用该宿主的停止工具清理本轮客户端与调试资源。GUI 和 Headless 不要同时写同一项目；切换入口前先保存、结束活动并交接项目。安装、登录与清理步骤见无头编辑器指南。

日常迭代 ​

  1. 按上表选择入口。无头开发已知实际安装路径时，先按准备步骤执行该安装的 sce.cmd prepare <项目目录>，更新当前渠道/API 且遵守项目版本约束的 SDK、文档和 AI 上下文，再打开项目；本轮刚成功 init / prepare 可跳过。路径未知时先定位，仍无法确定则说明尚未准备，不猜路径。已有宿主先保存并正常交接，连续迭代无需重复准备。第一次使用图形编辑器的细节见 快速开始。
  2. 让 AI 或 IDE 打开游戏项目根目录，而不是只打开 SDK 目录。
  3. 先读项目根目录的 AGENTS.md；如果使用 Claude Code，也读 CLAUDE.md。
  4. 根据玩法选择架构路线和起手模板。不要只按“2D / 3D”分类；先判断是否需要 SCE Unit/技能系统、直接 GameGraph、Canvas/GameUI 或服务端权威同步。
  5. 修改代码、数据或触发器。数据编辑器和触发器优先通过编辑器或 MCP 修改，避免直接手写生成文件。
  6. GUI 或 Headless 的标准构建、调试工具会完成代码生成、双端编译和部署。如果本轮由 AI / IDE 在命令行提前验证代码，至少编译两个调试配置：
powershell
dotnet build src/GameEntry.csproj -c Server-Debug
dotnet build src/GameEntry.csproj -c Client-Debug
  1. 按本次修改选择单客户端连服调试、GUI 多人调试或纯客户端预览。跟踪原有构建与操作 ID；等待超时先查同一操作的状态。
  2. 用运行时日志、截图、Runtime MCP、UI snapshot 或项目自定义 debug 工具验证结果；涉及跨端状态变化时，按下方要求核对服务端和客户端的最终状态。
  3. 发布内测前对照 游戏完整性检查清单，确认游戏不是只“能编译”，而是真的可玩。

跨端行为的完成依据 ​

修改跨场景迁移、控制权或其他同步行为前，先写清服务端应达到的状态、客户端应看到并能操作的结果，以及中途失败后的恢复目标。区分已确认的 API 契约与项目假设；先检查用户实际运行的客户端、SDK 和依赖版本，再选择实现方式。

  • 以同一次调试局、同一玩家槽位和同一同步对象身份对齐两端证据，结合服务端日志与客户端状态、截图及实际操作判断结果。调用返回成功、服务端坐标正常或 UI 已出现，只能证明对应环节。
  • 涉及异步加载和复制时，按加载事件与对象就绪条件确认完成，并设置等待超时；固定延迟不能作为完成依据。
  • 按改动范围覆盖正常操作、重复操作和失败恢复。跨场景携带角色的具体要求见 场景系统。
  • 结论注明已验证的端、路径与剩余缺口。例如只有服务端证据时，记录“服务端已验证，客户端待验收”；尚未覆盖的回退或用户版本不能写成已修复。

编辑器内部功能状态 ​

触发编辑器和数据编辑器已经开放，并持续迭代。它们适合承载图形化配置、结构化数据维护、触发器模型编辑和 AI MCP 辅助操作；复杂玩法逻辑、跨端代码、UI 调试和运行时验证，目前仍建议以 C# 代码和 AI 辅助验证为主。

当前推荐的心智模型是：

  • 用 GUI 或 Headless 提供项目创建、数据与触发器编辑、构建、调试和发布能力；需要图形交互时使用 GUI。
  • 用 AI 助手阅读项目根目录的 AGENTS.md、SDK 文档和项目代码，完成代码修改、编译、日志分析和运行时验证。
  • 用 MCP 让 AI 在必要时直接操作数据编辑器、触发器编辑器、调试启动、Runtime MCP、UI snapshot 和截图工具。

AI 辅助开发约束 ​

  • AI 应以游戏项目根目录为工作区，并优先读取项目根目录的 AGENTS.md。
  • Windows 下仍建议用户和 AI 助手安装并优先使用 PowerShell 7 (pwsh)；但项目刷新、资源统计和发布流程不能假设用户机器一定安装了 pwsh。自动化脚本应先用 Get-Command pwsh，找不到时回退到系统自带的 powershell.exe，保证缺少 PowerShell 7 不会阻断这些流程。项目通常会包含 ai/tools/Ensure-PowerShell7.ps1，也可以参考 PowerShell 7 环境诊断 Skill。
  • AI 还应检查 $PSVersionTable.PSVersion，确认命令实际运行的宿主版本：PowerShell 7 支持 && / ||，Windows PowerShell 5.1 不支持；; 不检查前一步是否成功，不能直接替代 &&。搜索代码和日志优先使用已有的 rg；coreutils 是可选增强，不替代 PowerShell，也不提供 Bash 语法。需要 coreutils 的同名命令时使用 ls.exe、cat.exe 等，避免命中 PowerShell 别名。
  • AI 可以从 map_templates 读取模板和示例，新项目优先通过所选宿主的项目创建工具建立。需要 AI 复制模板时，规则见 快速开始。
  • 本机命令行编译验证应覆盖 Server-Debug 和 Client-Debug。使用 GUI 或 Headless 标准构建、调试时，让宿主完成编译与部署；任务涉及发布资源清单时，再补 Client-Resource 或按 发布资源缺失排查 验证。
  • 需要刷新资源清单、生成 Humanoid 动画或模型预烘焙碰撞时，使用所选宿主的 resource_statistics_generate_animations。Headless 异步操作须跟进原 operation_id，确认成功且清理完成；debug_start_with_resource_statistics 可在资源准备后启动调试，skip_compile 只跳过后续双端脚本编译。步骤见资源准备。依赖库可构建和统计资源，其运行行为在引用库的游戏中调试。
  • 按当前宿主和操作返回的日志路径读取本轮构建及双端运行日志。GUI 运行日志通常在安装目录的 logs/client 和 logs/server 下；Headless 使用自己的工作目录与返回路径，不要只看项目根目录里的 build log。

选择调试路线 ​

标准调试：带服务端逻辑的游戏 ​

如果本次需要验证服务端权威逻辑、整局流程或真实联机行为，使用带服务端的标准调试。用户已打开目标项目的可视化编辑器时优先复用，除非用户主动要求隔离；没有已打开的 GUI 或用户要求隔离时，AI 单客户端连服验证优先 Headless，编排多客户端时使用完整编辑器。典型场景包括：

  • 使用 Entity 或 Unit 系统。
  • 使用 CloudData、玩家数据、服务端 AI、刷怪、结算、匹配或多人同步。
  • 需要验证客户端与服务端之间的事件、消息、同步和远端服务器行为。

这类项目可通过所选宿主的 MCP 调用 debug_start、debug_start_with_resource_statistics 和 debug_stop，GUI 也可使用正常调试按钮。先发现实际工具 schema，并确认账号、项目及调试依赖就绪。标准调试执行保存、生成、编译、部署与远端调试开局流程；Headless 的依赖配置和单客户端操作见无头编辑器指南。

如果已经由 IDE、终端或 AI 工具完成编译，并且确认最新 GameEntry.dll 已经部署到服务端 AppBundle/managed/ 和客户端 ui/AppBundle/managed/，可以使用编辑器菜单里的“调试（不编译）”，或通过 MCP 调用 debug_start_no_compile。这个入口只适合跳过重复编译来加快迭代；如果 DLL 没有手动复制到两个 AppBundle 目录，运行时仍会加载旧代码，容易出现“源码已经改了但调试表现没变”的误判。

需要在编辑器外的独立窗口运行时，使用“调试 → 独立客户端调试”；已有当前代码对应的编译产物时，可选“调试 → 独立客户端调试(不编译)”。两项均只启动单人客户端，仍连接调试服务器，无需修改编辑器启动参数。不编译仍会保存和准备地图；修改脚本后应先编译。依赖库需配置测试地图，或打开引用该库的游戏项目进行调试。

关闭独立调试客户端会通知服务器结束该客户端关联的调试局；多人内嵌调试只有关闭最后一个窗口才通知结束。主动停止后核对清理结果，不将服务器离线回收作为正常停止步骤。

调试启动后，AI 仍然可以通过 runtime_call_tool 检查客户端运行时，例如调用 debug.ping、debug.capture_screenshot、ui.snapshot 和项目自定义 runtime 工具。完整工具说明见 SCE Editor MCP 工具速查 和 SCE DebugTools MCP Skill。

这不表示带服务端逻辑的项目不能使用纯客户端模式。对于同一个项目，如果本轮只想快速调整某个 UI 页面、GameGraph / SceneGraph 场景、模型预览或本地客户端工具，可以增加 #if CLIENT + Game.IsClientOnly 分支，让纯客户端调试直接打开目标界面或目标场景。局部表现确认后，再回到标准调试验证服务端逻辑和整局流程。

只生成与编译 ​

修改数编或触发器后，如果本轮只需要验证代码生成与编译，可在 GUI 或 Headless 中打开目标项目或依赖库，调用 build_start。它保存数据与触发器、生成代码，编译 Server-Debug 和 Client-Debug，成功后部署 AppBundle 并结束。此流程不启动游戏，也不要求依赖库有可运行的场景。

  1. GUI 通过 editor_get_context、Headless 通过 headless_get_project_state 确认当前项目；通过 tools/list 确认 build_start 的实际 schema。
  2. 调用 build_start，记录返回的 build_id 和 operation_id。收到 ID 仅代表构建已接受。
  3. 使用 build_wait 或 build_status 查询该 build_id，以终态 succeeded 确认生成、双端编译与部署完成；失败时按下一节读取诊断并修改源数据、触发器或代码。
  4. 依赖库的运行行为在引用它的游戏项目中通过标准调试验收；已配置测试地图的库也可使用菜单测试地图路线。直接调用库的调试启动工具会返回 dependency_library_requires_test_project。

build_wait 等待超时不会取消后台任务。若 build_start 返回 build_start_timeout，先用其 operation_id 查询 build_status，确认任务状态再决定是否重试，避免重复构建。仅需要保存与生成数据时仍可使用 data_save_and_generate。

编译失败时查看错误和日志 ​

GUI 标准调试中的项目 DLL 编译异步执行，进度窗口保持在所属场景编辑器前方；切换到其他程序时，其他程序窗口可以覆盖进度窗口。编译期间暂时阻挡编辑器窗口操作，结束后恢复。GUI 和 Headless 的 AI 调用均通过本次构建 ID 查询诊断或取消；Headless 按工具返回的日志路径排查，无需操作窗口。下列窗口入口适用于 GUI：

  • 查看具体错误： “信息列表”窗口的“编辑器”页中选择“编译”来源。构建失败或超时会自动显示该窗口并选择来源，同时清空搜索条件、恢复全部严重级别可见。这里会显示配置、错误码与消息，有源码位置的错误还会显示文件和行列。
  • 打开源码： 点击具体错误行右侧的路径，例如 Player.cs(12,3)。系统会用关联程序打开源码文件；行列用于定位参考，暂不自动跳到 IDE 对应行。没有源码位置的恢复、工具链或生成错误仍可查看诊断文字。
  • 打开完整日志： 点击构建阶段消息右侧的日志路径。日志以 UTF-8 保存在 <EditorRoot>/logs/build/<project-path-hash>/<timestamp>-<build-id>/，每个配置有独立日志；代码生成异常另写 generating_code-failure.log，保留完整异常和内部异常，具体以结果中的 log_path / log_paths 为准。项目根目录中的旧构建日志不代表本次结果。
  • 让 AI 修复： 调用 debug_start 后，用 operation_id 查询 debug_wait / debug_status，读取关联 build；再用 build_id 查询 build_diagnostics，需要原始输出时按 build_status 返回的路径读取对应日志。生成阶段失败时先修复数据或触发器定义，源码错误则按配置和文件行列修复，再启动调试。

所有必需配置编译成功后才部署 DLL；编译失败保留上次有效产物，部署失败会尝试回滚。通过 MCP 使用 build_cancel 取消正在运行的构建后，要等它进入终态再重试。build_wait 的查询等待超时仅返回当前状态，编译仍会继续。构建完成后，仍需通过调试操作与 Runtime MCP 确认游戏局启动。更多参数见 SCE DebugTools MCP Skill。

UI 编辑器创作模式的启动失败也保留实际构建阶段。uiauthoring_status / uiauthoring_wait 返回的 build 含构建编号、诊断摘要和日志位置，信息列表的 UIAuthoring 来源同步显示失败原因；按该编号读取完整诊断，再修复生成或编译错误后重试。不要把 generating_code 失败当作客户端 C# 编译失败，也不要用免编译入口证明生成问题已修复。此行为需更新编辑器及配套脚本。

纯客户端调试：UI / Canvas / GameGraph / 本地工具 ​

纯客户端调试适用于两类情况：

  • 项目本身就是纯客户端 UI、Canvas、GameGraph 或本地 SceneGraph 游戏。
  • 项目有服务端逻辑，但本次只想迭代其中某个客户端 UI、GameGraph / SceneGraph 场景、模型表现或本地工具。

推荐闭环是：

  1. AI 修改代码或数据。
  2. 如果项目原本依赖服务端，在客户端初始化代码中为 Game.IsClientOnly 增加本地预览分支，直接启动想调整的 UI、SceneGraph 场景、假数据 ViewModel 或本地工具。
  3. AI 编译 Client-Debug 和 Server-Debug。
  4. AI 把最新 GameEntry.dll 部署到 AppBundle/managed/ 和 ui/AppBundle/managed/，或使用编辑器调试流程完成部署。
  5. AI 运行项目内 ai/tools/Start-SceClientOnlyDebug.ps1，以 -client_only 启动客户端。
  6. AI 通过 Runtime MCP 调用 debug.ping 确认客户端在线。
  7. AI 调用 debug.capture_screenshot 获取画面，调用 ui.snapshot、ui.find 或 ui.get_rect 检查 UI 控件树和像素坐标。
  8. 如果内置 runtime 工具不够，项目可以在调试分支中注册自定义 Runtime MCP 工具，例如返回当前 ViewModel、局部关卡状态或 UI 预览参数。
  9. AI 根据截图、UI 快照、日志和自定义工具结果继续修改。必要时关闭客户端并重新启动，形成自动化闭环。

纯客户端模式不会启动服务端，服务端初始化、Unit / Entity 创建、CloudData、服务端触发器和多人同步都会被跳过。因此它可以验证客户端局部表现和本地预览逻辑，但不能作为发布前整局验证的替代。详细启动参数、DLL 部署和 Runtime MCP 用法见 纯客户端调试指南 与 Runtime MCP 调试指南。

消息框阻挡自动化时 ​

如果保存、关闭或更新流程被编辑器共享消息框挡住，先调用 editor_dialog_snapshot 读取内容、用途、dialog_id 和按钮状态。理解消息内容、确定操作后，用 editor_dialog_choose 传入该 ID 与 confirm、cancel 或 close，走原有按钮回调，再接续原来的任务。窗口 ID 已变化时重新读取，隐藏或禁用按钮不能执行；系统文件选择框和进度窗口不在此工具范围内。这些工具需要更新完整编辑器，详细参数见 MCP 工具速查。

数据编辑器、触发器编辑器与 MCP ​

数据编辑器 MCP 已经支持表、条目、字段、模板、Link、资源、校验、保存和生成代码等操作。AI 修改 editor/data 或 GameData 配置时，优先使用 data_*、gamedata_*、workflow_* 和 ui_* 工具，而不是直接手写 JSON。细节见 SCE 数据编辑器 Skill 和 数编 MCP 工作流。

触发器编辑器 MCP 已经支持列出文件、查询 API、读取正向/反向/失效引用、创建触发器/函数/变量/类/校验器、安全幂等删除、替换函数体、保存和校验。触发器写操作会刷新生成代码，但仍需要保存触发器模型；删除工具的 outcome / safeToRetry 等结构化结果可帮助自动化判断是否允许重试。细节见 SCE 触发器编辑器 MCP Skill 和 触发器 MCP 工作流。

这些 MCP 能力适合让 AI 做结构化修改和验证。发布前仍要保留源码管理记录，检查生成代码，运行双端编译，并在合适的平台完成内测。

发布和内测前检查 ​

让 AI 发布当前项目 ​

先按开发入口规则选择宿主。Headless 的发布流程见上传发布与成功标准：跟踪原 operation_id，核对后台最终结果与发布身份、持久化成功及资源清理。accepted 或上传结束尚未完成发布；等待超时或结果不明时继续查询原操作。下列步骤适用于 GUI 当前项目发布。

更新完整编辑器及配套 XDEditor、Script 后，AI 可以通过 project_publish_start 复用编辑器菜单的保存、生成代码、资源统计和上传流程。发布使用当前编辑器环境及项目原有后台配置。

  1. 调用 editor_get_context 获取当前项目路径，确认已登录。
  2. 将该绝对路径作为 project_publish_start 的 project_path，记录返回的 operation_id。
  3. 用 project_publish_status 或 project_publish_wait 查询结果。accepted 代表上传已受理，succeeded 才代表后台发布成功；等待超时不会取消发布。
  4. 如果返回未上传的依赖资源列表，先处理这些资源后重试。结果为 unknown 时继续查询或打开返回的 backend_url；启动响应超时时先查询原操作，避免重复上传。

此入口不执行创作者中心的审核、上架或环境晋级，也不用于依赖库发布。状态仅在当前编辑器进程内保留，后台结果通过现有通知更新；通知监听最多 30 分钟，断线或重启后需在创作者中心确认结果。工具详情见 Editor MCP 工具参考。

有自定义 UI 图集时，可在成功发布后按返回身份启动 project_publish_verify_resources，用校验编号继续查询结果，检查 JSON、实际纹理容器和区域配置。它需要配套发布服务、编辑器和脚本更新，不能代替目标客户端进局显示验收；详见发布包图集校验。

平台内测闭环 ​

从线上版编辑器到测试者进局的顺序如下，详细操作、入口和排错见平台内测与线上发布指南：

  1. 在线上版编辑器完成资源准备、双端编译和本地调试。
  2. 通过“发布 → 上传”或 project_publish_start 上传项目，确认后台发布成功。
  3. 在线上创作者中心测试环境配置可见的游戏模式，核对生效范围和玩家槽位。
  4. 创建或读取内测码；作者可点击“加入我的内测”或调用 author_join_my_test。
  5. 测试者使用匹配的线上版对战平台输入内测码进入，完成目标平台实机验收。
  6. 修改后重新上传并确认测试端拿到新内容；测试环境的更新不会自动进入正式环境。
  7. 用创作者中心玩家日志或作者后台 MCP 读取测试环境和游戏局日志，修复后按同一路径复测。

发布前检查 ​

发布或发内测前，建议至少完成以下检查：

  • Server-Debug 和 Client-Debug 都能编译通过。
  • 使用服务端逻辑的项目，走一次 GUI 或 Headless 连服调试并验证客户端、服务端日志；多人竞争、晚加入和重连等另按多人测试覆盖。
  • 纯客户端项目，或服务端项目中的客户端局部预览，走一次纯客户端调试并用 Runtime MCP 截图或 UI 快照确认关键界面。
  • 检查项目资源是否进入发布清单。模型、粒子、音频缺失时参考 发布资源缺失排查。
  • 获取内测码前，确认创作者中心测试环境存在可见模式，生效范围包含当前项目，人数与项目槽位匹配。已有内测码不代表可以进局。配套后台可通过作者 MCP读回、预检并按授权配置测试模式；正式同步是独立操作。完整步骤见平台内测与线上发布指南。
  • 对照 游戏完整性检查清单，确认核心玩法、失败/胜利流程、UI 状态、断线/重进、资源加载和移动端表现已经验证。
  • 发起内测后，至少在目标平台实机试玩一次；平台内测覆盖 PC、Android 和 iOS 对战平台，TapTap App 内嵌启动不在平台内测范围。
  • 对战平台内测运行在 test 环境，只能使用已有星火币消费，不能充值；项目上线后运行在 formal 环境，可以在对战平台正常充值。TapTap App 内嵌启动仍需联系工作人员开通 TapTap 测试，见 TapTap 测试与上架。
  • 需要 TapTap 审核上架的项目，先完成内测验证，再按 TapTap 测试与上架 和当前创作者中心流程提交审核；不再需要等待额外的星火 2.0 容器上线。
  • 如果项目确实需要从外网测试环境迁移到线上，确认依赖的新 SDK / 编辑器 / 客户端能力已经进入线上生产环境，并检查自定义云端资源是否已经同步到线上环境；不要把这条件当作新项目默认路线。