主题
从一份需求到可运行 Demo：AI 与 DTS 的协同开发实践
做一个数字孪生 Demo，常常要跨过好几道工序：整理模型与业务数据、转换三维资源、组织工程、准备云渲染服务、查找 SDK 接口，再把界面和场景联动起来。每一步都有工具，真正耗费精力的是把它们接成一条完整的工作流。
现在，可以让具备文件处理、代码执行和 MCP 连接能力的 AI 工具，结合 DTS 已有的 Skill 与接口知识，承担其中大量重复工作。开发者描述目标、提供数据和约束，AI 按步骤准备资源、生成工程、连接 Cloud，再根据真实 API 构建业务交互，并通过实际画面检查结果。
本文以当前正式版 DTS Cloud 7.0 为主要运行环境，把已有实践整理为一套可复用的方法。我们用“园区告警与巡检演示”贯穿流程，并引用 Hub 已公开的真实工具和运行截图。园区需求是教学示例；配图分别来自既有资源，不表示本次已执行了一套新的园区项目。
先说清楚：我们要演示什么
假设手头已有一批建筑、道路、地面模型，一份设备点位表，以及一条巡检路线。演示目标是：打开园区三维场景，查看设备分布；点击告警列表时，相机定位到对应设备；切换建筑与道路图层；让巡检对象沿路线运动。
可以先把需求交给 AI：
text
请基于当前目录的数据，制作一个园区告警与巡检 Demo。
需要场景总览、设备点位、告警列表定位、建筑/道路图层开关和巡检路线演示。
先检查数据与运行环境，列出缺少的信息，给出分阶段方案。
业务告警可以使用明确标注的模拟数据，三维场景使用实际 DTS Cloud 视频流。第一轮先确定最小演示范围：要展示哪些动作、每个动作需要什么数据、哪些是真实输入、哪些是演示数据。模型用途、坐标系或设备位置不明确时，补齐这些信息，比直接生成整套页面更能推进项目。
四项 DTS 能力，把工作流接起来
| 工作阶段 | 使用的 DTS 能力 | 主要结果 |
|---|---|---|
| 原始三维数据准备 | DTS Engine 自动数据发布 | 发布计划、后台任务记录、3DT 与依赖文件 |
| 资源组织成场景 | DTS 场景整合 | DTML、同名资源目录、分类图层树 |
| 准备云渲染环境 | DTS Cloud MCP | 服务状态、工程注册与视频流/API 测试入口 |
| 实现业务交互 | DTS SDK 二次开发助手 | 基于真实 fdapi 的播放器接入和场景控制代码 |
Skill 为 AI 提供规则、知识和可复用的脚本；MCP 将 AI 连接到实际工具。二次开发助手帮助 AI 理解接口、生成代码，场景动作最终由 DigitalTwinPlayer 与 fdapi 执行。客户端需要具备相应权限和执行通道；启用一个知识型 Skill，不会自动建立 Cloud 连接。
整体顺序是：需求拆解 → 数据检查与处理 → 3DT 发布 → DTML 整合 → Cloud 服务与工程准备 → API 开发 → 真实画面验收。 已有可用 3DT 或 DTML 时，可以从相应阶段开始。
第一步：让 AI 先把数据整理明白
AI 工具可以先扫描目录、读取元信息，整理模型、纹理、矢量线、点位表和高程数据之间的关系。对业务点位和路线，可以编写脚本统一字段、检查重复 ID、空坐标和异常范围，再输出供前端使用的 JSON。
这里需要同时关注平面坐标、单位、原点和高程来源。例如，设备表是 WGS84 经纬度，园区模型采用投影坐标，不能只改一个坐标类型标记就认为完成了转换；只有明确源坐标系与目标坐标系后，才能执行对应转换。巡检路线的高度也要与道路或地形对齐。
对需要转为 3DT 的原始模型，使用 DTS Engine 自动数据发布 Skill：先识别数据类型和依赖，按质量、均衡或性能策略生成参数计划；核对计划后，再执行后台任务。
text
请检查园区模型目录，区分建筑、道路、地面和辅助数据。
使用 DTS Engine 自动数据发布，按均衡策略生成发布计划。
列出输入/输出、坐标系、关键参数、外部依赖和不确定项，先不执行。当计划已具体到数据用途、输出目录和参数后，再明确要求执行该计划。完成后检查日志、非空 3DT、依赖文件和失败记录。当前不同数据类型的验证程度不同，应以资源页中的证据说明为准，不能把“可以生成计划”直接当作“所有格式都已验证发布”。
这一步的交付物除了转换后的数据，还应包含数据清单和处理记录，让后续整合知道每份资源来自哪里、使用什么坐标、是否有遗留问题。
第二步：自动组织一个可交付的 DTS 场景
模型发布完成后，使用 DTS 场景整合 Skill，将建筑、道路、地面、水面、植被等 3DT 按分类组织成 DTML 工程。
text
使用 DTS 场景整合，将已发布的 3DT 目录生成 ParkDemo 工程。
保留分类目录，使用可移植的相对资源引用，输出到新的交付目录。
检查资源完整性、重复 ID 和失败记录，报告图层数量与校验结果。标准交付结构是：
text
ParkDemo.dtml
ParkDemo_files/
Buildings/
Roads/
Ground/
Vegetation/.dtml 与同名 _files 目录需要一起交付，资源的附属文件也要完整保留。当前场景整合 Skill 基于 EPSG:3857 兼容母版，生成图层树和资源引用；它不会把输入模型自动重投影。其他坐标系应先完成正确的数据处理和兼容性确认。
需要人工查看或合并现有工程时，也可以使用 DTML Studio 辅助检查工程结构。
结构校验通过后，仍要在目标 DTS 环境检查实际空间位置、纹理和图层显示。XML 合法、路径存在，分别解决了结构和引用问题；场景是否正确，要看加载结果。
第三步：调用 Cloud MCP，准备服务与工程
工程准备好后，让 AI 通过 DTS Cloud MCP 检查服务状态，并在明确的操作范围内启动服务、注册工程、打开测试页面。
以当前正式版 DTS Cloud 7.0 为例，管理 MCP 可以完成服务状态查询、服务启动、ACP/DTML 工程添加与移除，以及视频流和 API 测试页面打开等工作。DTS Cloud 7.0 与 7.1 的 MCP 能力一致，本文的介绍与操作示例以 7.0 为主，具体工具名称和参数以所连接 MCP 的工具列表为准。
text
请通过 DTS Cloud MCP 检查当前服务状态。
如果服务未运行，启动服务；已经运行则复用。
将已校验的 ParkDemo.dtml 加入 DTS Cloud 7.0，先检查是否存在同名工程。
使用对应工程 ID 打开视频流，检查实际画面；不要停止或重启现有服务。需要注意启动的层次：AI 客户端连接的是管理 MCP Host，MCP Host 需要与对应版本的 CloudMaster 配合运行。若主程序尚未打开，应通过客户端具备的本地启动能力或手动打开，再使用 MCP 查询和控制后台服务。
注册工程后，要确认渲染节点能访问 DTML 与资源目录，并正确选择工程和实例。已有实例若绑定了其他工程，可能影响新工程的加载，需要检查绑定状态。
DTS Cloud MCP 负责服务和工程管理；相机、标注、模型运动等场景动作由 fdapi 完成。 到这一步，应先看到对应工程的真实视频画面，再开始业务开发。
第四步：用二次开发助手，把需求变成场景交互
在 AI 客户端中启用 DTS SDK 二次开发助手，让 AI 按需求查询真实接口、参数与示例。WorkBuddy 中可搜索 fdapi，找到“飞渡DTS SDK二次开发助手”；其他客户端可按资源页说明接入相应知识与技能。
以园区 Demo 为例，可以这样分解接口与页面职责：
| 业务要求 | DTS 场景能力 | 页面需要完成的联动 |
|---|---|---|
| 展示设备位置 | Marker | 设备列表与场景对象使用一致的业务 ID |
| 点击告警定位 | Camera，配合标注 | 选中告警后定位对应坐标并展示设备信息 |
| 切换建筑、道路 | InfoTree / 对应图层接口 | 开关绑定到真实工程节点或图层 ID |
| 显示巡检路线 | Polyline | 路线选择、显隐和说明 |
| 巡检对象运动 | CustomObject 或 Vehicle | 按资源与接口能力实现运动、跟随和状态展示 |
继续给 AI 明确的实现任务：
text
使用 DTS SDK 二次开发助手，读取目标版本的真实接口与示例。
基于已验证的 ParkDemo Cloud 工程制作网页 Demo：
接入真实视频流，添加设备点位，点击告警列表定位，提供图层开关与巡检演示。
服务地址、工程/实例 ID、模型路径和坐标配置集中管理。
等待 API onReady 后再执行场景操作；模拟告警明确标注为演示数据。
只管理本 Demo 的对象 ID，重复运行时更新或重建这些对象。二次开发的关键是把界面动作接到真实场景。例如，点击告警应触发相机定位，图层开关应改变对应节点的可见性。连接失败时页面应显示原因与恢复入口；视频流正常、API 就绪之后，再加载业务对象。
AI 生成代码时，还需要核对接口是否存在、参数顺序、坐标类型、资源路径及异步调用时机。fdapi 文档工程内置的 AI 助手有真实签名与白名单约束；其他客户端应核对生成结果，不能默认继承同样的校验机制。
第五步：边运行、边修改，交付可复现的 Demo
有了第一版，下一轮需求就可以更具体：“告警点太密，调整可视范围”“巡检相机降低高度”“增加总览按钮”“列表选中时同步场景标注”。AI 修改代码与配置后，重新运行对应流程，用画面和日志检查变化。
一个已经公开的例子是 舰船多视角同步监控样例：页面常驻四路 DigitalTwinPlayer，让四个视角跟随同一舰船对象，并支持点击预览切换主画面。它展示了如何把模型、路线、相机、播放器和业务界面组合为完整演示。
不同项目可以复用相同的方法：替换数据输入、确定业务动作、选择实际 API，再围绕真实场景迭代界面。速度来自既有能力和上下文的复用；具体用时仍取决于数据质量、模型规模、运行环境与需求复杂度。
交付前，可以按四个层次核对：
| 验证层次 | 需要确认的结果 |
|---|---|
| 数据与工程 | 3DT 和依赖完整，DTML 引用有效，坐标与高程正确 |
| Cloud 运行 | 目标工程加载，视频持续播放，服务与实例状态正常 |
| 业务交互 | 点位位置正确，告警定位有效，图层开关与巡检动作符合需求 |
| 复现交付 | 源码、配置说明、处理记录与截图齐全，按说明可以重新启动 |
最终交付应包括工程与资源、处理后的业务数据、网页源码、环境配置说明和运行证据。Demo 中已经完成的交互、使用的模拟数据，以及尚未验证的接口或环境，需要写清楚。
从单次演示，积累下一次开发的起点
DTS Engine 自动数据发布负责准备三维资源，场景整合把资源组织成工程，Cloud MCP 接通运行环境，SDK 二次开发助手帮助 AI 将业务需求落实到场景接口。AI 工具则在这些环节之间读写文件、生成代码、调用工具并整理结果。
这套协同方式可以逐步积累为团队自己的模板：数据目录规范、发布参数计划、工程分类、播放器接入、告警联动、巡检动作和验收说明，都能成为下一次任务的输入。每完成一次真实演示，就多一份可复用的开发经验。