Digital Twin Project Takeover
已有Unity或UE数字孪生工程，继续开发前怎么评估
企业已经有园区、工厂或设备三维系统，下一步可能是增加点位、接入新数据、调整操作流程，或者让原来的展示程序进入日常使用。换团队之前，先确认现有材料能支持哪些修改：能运行原来的程序、能在编辑器里打开场景、能修改后重新构建，是三种不同的证据。把这些条件查清，才能判断哪些成果可以继续使用，哪些依赖需要补齐。
阅读目录7 个章节
先把“接下来要改什么”落到一个具体动作
例如，新增一台设备后，能否在场景中找到它、显示对应数据，并从告警列表定位过去？这个动作同时涉及模型对象、业务身份、接口和界面交互，比只看一段演示视频更能说明后续开发需要动到哪里。如果目标是把展示机程序改为浏览器访问，还要单独评估部署路线；原程序能运行，不能直接说明 Web 版本已经具备。
评估前先保存原工程副本、当前可运行版本和已知问题，记录使用的引擎版本及启动方式。首次复现优先沿用已有环境；需要升级引擎或替换插件时，把这部分工作另列出来。Epic 的迁移文档也建议在副本上升级，并说明较新版本保存的资源存在向旧版本打开的限制。参考 Epic 工程迁移说明。
收到的文件，能证明到哪一步
左右滚动表格，查看完整对照内容。
| 现有材料 | 先验证什么 | 还不能据此认定什么 |
|---|---|---|
| 演示视频、截图、可执行程序或访问地址 | 现有功能、交互流程和运行环境是否有可核对的基线。 | 不能仅据此认定已经取得可编辑、可重新构建的工程。 |
| Unity 或 UE 编辑工程 | 能否用记录的引擎版本打开代表性场景，资源与脚本/蓝图引用是否正常。 | 打开编辑器不代表目标平台打包、插件依赖和真实接口都已验证。 |
| 建模原文件、导出模型、贴图与材质 | 能否完成约定修改，导入后保持所需坐标、单位、层级和业务对象标识。 | 有一个可显示的模型，不代表保留了全部建模过程或工程中的业务逻辑。 |
| 构建说明、依赖清单、接口资料和部署配置 | 能否在约定环境重新生成运行版本，并走通代表性操作。 | 文件齐全仍需实测；私有包、服务权限或第三方组件可能尚未取得。 |
UE 的发布流程会编译代码，并把资源处理为目标平台运行格式，因此安装包和编辑工程承担不同用途。拿到 EXE 或发布资源，应继续确认对应工程在哪里，不能直接承诺从发布包恢复原工程。参考 Epic 打包流程说明。
Unity 工程重点检查资源引用与包依赖
Unity 资源旁的 .meta 文件保存资源标识和导入设置。模型或脚本文件还在，相关 .meta 丢失后，场景中的材质、脚本等引用仍可能出现问题。因此接手时要连同资源及其元数据一起核对，不能只抽取模型和代码文件就认定工程完整。参考 Unity 资源元数据说明。
同时检查项目设置、Packages/manifest.json、packages-lock.json 和实际使用的插件。包清单说明需要哪些包，锁文件保留依赖解析结果；本地包、私有源或外部仓库依赖能否取得，还要单独确认。接手测试应保留原有依赖记录，先复现已有环境，再决定是否更新。Unity 项目包清单、Unity 锁文件说明。
UE 工程重点检查蓝图、代码与插件是否能一起构建
从 .uproject 对应工程核对 Content、Config、实际使用的插件，以及项目所需的源码和构建文件。UE 项目可以使用蓝图，也可以包含 C++，不能只因没有 C++ Source 目录就判定“没有源码”。需要确认的是后续要修改的那部分逻辑在哪里，能否编辑，并随项目一起构建。参考 Epic 工程目录说明。
插件还需区分可修改源码与仅提供二进制的组件，并记录它们依赖的引擎版本、其他插件和目标平台。只有二进制不一定影响原环境运行，但不能据此保证换版本或换平台后仍能使用。是否能继续维护，应由对应环境的加载与构建结果说明；第三方部分的可修改范围也应单独列明。参考 Epic 插件说明。
用一次小改动，验证是否真的能继续开发
选择一个代表性楼层或设备，做一次与后续需求相近的改动，例如增加点位、调整设备状态显示，或修改一处查询联动。在副本中完成编辑、保存、重新构建，再到约定终端执行相同操作。记录改了哪些文件、使用什么版本、如何生成运行包，以及原有功能是否仍正常。
这一步输出的是继续开发所需的条件：模型对象能否定位，业务 ID 是否稳定，逻辑是否可改，依赖是否取得，以及新版本能否生成。若还需改动原始 CAD/BIM 或建模文件，应同时验证导出和重新导入。Datasmith 的官方兼容表按来源应用、版本与导入/导出流程区分，说明“文件扩展名支持”不能替代具体样例测试。参考 Datasmith 文件与软件兼容说明。
数据连接与浏览器部署，要沿实际链路走一遍
让一条可控测试数据从接口到达场景，核对对象、数值、时间和状态，再测试超时或断开后的提示。演示数据能变化，不能证明业务系统已经接入。具体字段、权限、网络区和点位映射可使用数字孪生资产与协议兼容矩阵记录。
如果准备发布 Unity Web，核对原有插件、接口和输入方式能否适配浏览器。Unity Web 的网络请求受浏览器跨域与网络能力限制，原客户端的原始套接字连接方式不能直接照搬。参考 Unity Web 网络说明。
如果已有 UE 系统通过 Pixel Streaming 提供浏览器访问，除 UE 工程外，还要接收对应的串流前端、信令服务、部署配置和启动说明。远端计算机负责运行与渲染，用户通过浏览器观看并操作；多人共同观看一个场景与各自独立操作，需要分别确认会话资源和网络条件。Pixel Streaming 架构说明、网络与部署说明。路线尚未确定时，可先阅读Web 三维与引擎选型文章。
评估结果应说明哪些成果保留、哪些条件待补
左右滚动表格，查看完整对照内容。
| 评估结果 | 应有的依据 | 下一步 |
|---|---|---|
| 可以沿原工程继续开发 | 原版本已复现，代表性改动可构建，关键依赖和数据链路可用。 | 保留现有成果，按新增功能确定范围和回归要求。 |
| 补齐依赖或完成适配后再继续 | 缺项明确，例如某个插件、私有包、模型原文件、接口权限或部署配置。 | 列明补充责任、验证方式和受影响功能，再安排开发。 |
| 部分内容需要替换或重建 | 具体模块缺少可维护输入，或在目标环境验证后仍不满足需求。 | 区分能复用的模型、数据与逻辑，说明替换边界，避免把局部问题扩大成全量重做。 |
工程接手评估用于确定后续开发条件。最终交付时，仍需按照约定核对完整功能、性能、部署和资料；可以继续使用数字孪生项目验收清单与源码、部署与账号交接清单。
已有工程准备继续开发时，可以先整理当前运行方式、工程目录、引擎版本、已知问题和下一步最想完成的操作，再安排小范围复现与修改验证。沟通现有工程与继续开发范围。
泓珊科技团队具备Unity与Unreal Engine相关开发能力。智慧工厂仓储数字孪生案例公开说明了项目原文件、代码与三维模型的交付范围；该范围不能用于推定其他项目的引擎、文件完整性或维护条件。团队介绍见泓珊科技团队。