天空的动画，背后的工程。

这场对话的起点，是 Steven 让 Alex 回顾前一天看到的无人机 LED 灯光表演（Drone Light Show），并尝试从工程师的角度解释：数百甚至数千架无人机，究竟如何在空中同步移动、改变阵形、控制灯光，最终形成动态的图案与动画？

Alex 最初提出两个猜想：

1. 预先编程（Hardcoding）：工程师事先设定每架无人机在特定时间应该执行什么动作，表演开始后，所有无人机按照预设程序运行。
2. AI 辅助生成程序：工程师可能用自然语言向 AI 描述想要的动作，再让 AI 编写控制无人机移动的程序。

Steven 没有立即接受这两个解释，而是要求 Alex 再深入一层：不只是想象表演如何被启动，而是思考工程师如何设计、制作和部署整套系统。

Steven 随后提出自己的技术模型：

这个方向与实际的专业无人机灯光秀系统高度一致。根据 Skybrush、Verge Aero 和 Intel 的技术资料，现代无人机灯光秀确实普遍通过动画设计、自动路径规划、轨迹验证及机群控制来实现。Skybrush Open-source Drone Show Software+2

不过，这场讨论也存在一个值得澄清的概念：Alex 所说的预先编程，与 Steven 所说的软件自动生成飞行指令，其实并不互相排斥。 两者描述的是同一个系统的不同层次。

整场对话最重要的教育意义，是 Steven 希望 Alex 学会从看得见的技术效果，追问背后看不见的设计、数据、算法与执行机制。

1. Steven 提出问题：不要只看表演，要思考它怎样实现

Steven 首先请 Alex 向在场的表姐解释前一天看到的无人机 LED 空中表演。

Steven 的核心问题是：

作为一个 engineer，你觉得他们 technically 是怎样做到这件事的？

问题的重点不是描述无人机能组成什么图案，而是让 Alex 代入负责设计系统的工程师，解释背后的技术实现。

这个问题实际上包含了多个没有直接说出的子问题，例如：

• 无人机怎样知道自己应该飞到哪里？
• 不同无人机怎样配合完成动态图案？
• 无人机的移动时间和路线怎样确定？
• LED 的亮灭与颜色变化由什么控制？
• 工程师怎样把设计好的动画变成真正的空中表演？

这些是从 Steven 的问题延伸出来的工程问题，而不是 Alex 当时已经明确回答的内容。

2. Alex 第一个猜想：按照预先设定的时间执行动作

Alex 一开始承认自己不知道实际原理，但提出了一个假设：

他们有 set 时间，在 exactly 这个时间做这些 movements。

他认为工程师可能事先把无人机的动作写进程序，并设置好执行时间。

Steven 追问究竟怎样实现时，Alex 表示可能是把动作直接 hardcode 进去。

Steven 随即指出，现场看到的并不是静止图案，无人机一直在移动，因此希望 Alex 解释动态变化究竟怎样被设计出来。

这里，Alex 已经抓到一个重要的技术概念：时间同步与预设动作。

但他的回答还没有涉及动作数据从哪里来、路径怎样计算，以及每架无人机如何知道自己的位置。

3. Alex 第二个猜想：利用 AI 编写动作程序

Alex 接着提出另一个可能性：

他们 describe 那个 movement to AI，然后 AI 帮忙 hardcode 出来它的 movement。

他的想法是，工程师可能先向 AI 描述想实现的动作，再由 AI 生成对应程序。

Steven 确认他的意思：

Fix 那个时间跟 movement，然后它只是 play，它就 follow 这样。

Alex 认可这种解释，同时补充：

但是有可能有其他的方法。

这说明 Alex 没有把自己的初步解释当成唯一可能的技术实现。

不过，当 Steven 要求他进一步提出其他方法时，他暂时无法给出完整的替代模型。

4. Steven 继续追问：按下按钮并不是工程设计的答案

Alex 又提出一种可能：工作人员按下一个按钮，之后某些设备便开始执行表演。

这里提到的「box」含义尚不明确，不能确定它具体指哪一种设备。

Steven 认为这种回答只描述了第一层可观察的操作：

这个是你看到的 first level，就是你看到的东西。

Steven 要求他考虑更深入的问题：

你是那个负责这个东西的人，你是那个 engineer，你会怎样去操作？

这里，Steven 实际上在区分两个不同的问题：

Alex 最初的回答主要集中在操作层和编程层。

Steven 希望他进一步思考设计层与系统层。

当 Alex 最终表示不知道时，Steven 开始提出自己的解释。

5. Steven 的主要解释：从 3D 动画设计到无人机控制

这是整场讨论中技术内容最丰富的一段。

Steven 指出现有的 3D 绘图及动画软件能够在虚拟环境中设计物体的移动。他举出 Unity、Unreal Engine 一类软件作为例子。

Steven 的假设可以整理为六个步骤。

第一步：设计空中图案

工程师先准备希望无人机在天空中呈现的图形或画面。

例如文字、图案或其他动态图像。

第二步：转换图形数据

Steven 推测可能将这些图像转换成某种数据格式，并在解释时提到 ASCII。

他的意思是：画面必须转换为计算机软件能够读取和处理的数据。

这里的 ASCII 是 Steven 当时提出的格式猜想，并非已经确认的灯光秀行业标准。

第三步：导入 3D 动画软件

Steven 设想利用 Unity、Unreal Engine 或类似工具，将图像转换成虚拟空间中的点或对象。

这些对象可以对应真实世界中的无人机。

第四步：设计动画与阵形转换

在 3D 软件中，工程师安排每个点如何移动、不同画面之间如何连接，以及动画序列应该怎样变化。

Steven 特别提到，不同 animation sequences 之间需要有相应的移动安排，而不是只有静止图像。

第五步：导出移动及位置数据

当动画设计完成后，软件可以输出每个点在各个时间的目标位置，以及从一个画面转移到下一个画面的运动资料。

这些结果再交给专用的无人机程序。

第六步：控制真实无人机和 LED

无人机根据导入的数据移动到指定位置，并执行对应的灯光变化。

Steven 认为，工程师不一定需要手工编写每架无人机所有的移动指令，而是利用已经设计好的软件，将动画转换为无人机能够执行的数据。

这个观点最关键的地方，是把复杂的工程问题转变为：

6. Steven 强调：AI 不是实现无人机灯光秀的必要条件

Steven 最后指出，这项技术在 ChatGPT 等生成式 AI 普及之前就已经存在。

另一位家庭成员补充，中国此前就已经有类似表演。

Steven 进一步解释：

这个东西是可以被 program 出来的，它不一定需要 AI。

他的观点是：

• 无人机灯光秀本质上是一项可以通过传统软件工程实现的技术。
• AI 可以帮助工程师编写软件、生成动画或提高开发效率。
• 但是不能因此认为，复杂的无人机表演一定依赖 AI。
• 即使没有生成式 AI，工程师也可以设计这样的系统。

Alex 在 Steven 解释期间，多次以「嗯」「哦」回应。

听过解释并作出回应，还不能说明已经能够独立解释或实现其中的技术机制。

有了初步的工程模型，还需要通过软件操作、程序编写、实验验证与独立复述来检验理解。

理解原理只是起点，能够独立设计和验证，才说明知识开始转化为能力。

Intel+3

其中有三个概念特别值得进一步澄清。

1. Hardcoding 与预先编排不是同一回事

这是整场对话最重要的概念差别。

严格来说，Hardcoding 通常指把特定数值或规则直接写死在程序源码中。

但灯光秀不一定这样做。它可以先用通用软件生成表演数据，再由通用的飞行控制程序读取这些数据。

所以：

• Alex 认为动作事先被设定，是正确的。
• Steven 认为不需要逐项手写所有动作，也是正确的。
• 两人的观点可以组合起来，而不必互相否定。

此外，Steven 以「它会移动，不是静止的」追问 hardcoding，这个问题能够引导 Alex 思考动态轨迹，但严格而言，动态移动本身并不能排除 hardcoding，因为程序同样可以包含随时间变化的坐标。

2. ASCII 不是 Steven 所寻找的关键技术概念

Steven 当时似乎在寻找一种把视觉内容转换成可处理数据的方式。

实际上，不同环节可能用到不同格式：

• SVG：表示二维矢量图形。
• 3D 模型或动画文件：表示空间对象与动画。
• CSV：储存时间、坐标及颜色等结构化数据。
• .skyc：Skybrush 使用的编译表演格式。

ASCII 本身只是文本字符编码，并不规定图形、位置或运动的数据结构。

Steven 的数据转换思路是正确方向，但实际关键在于图形表示、几何采样、编队生成与轨迹数据格式。

3. Alex 的 AI 假设并非没有技术依据

2026 年已有研究探索从文本提示和生成式视觉内容出发，自动生成无人机灯光秀轨迹，并结合安全规划来形成可执行编队。arXiv

因此，应作更精确的区分：

Steven 最后提出的观点，在这个意义上是正确的。