一个模型能在视频里控制无人机跟着人走，不等于工程团队已经知道它哪里可靠、哪里会失败。端到端演示把建图、定位、路径规划、目标识别和飞行控制压在同一条链上，只要最后撞墙，记录里往往只剩一句"任务失败"。下一版模型偶然飞通后，又很难判断究竟是哪一段变好了。
Anthropic 与 Andon Labs 在 Project Pilot 中采取了更适合复测的办法：先保留真实无人机演示，再把室内寻找并跟随指定人员的任务拆成五个可以在软件中重复运行的子任务。Drone-Bench 由 Andon Labs 建立并执行，Anthropic 参与咨询但没有拿到评测集。这种分工也提醒开发者，基准的设计方、运行方和被测方要在记录里分开写。
五段任务不是五个互不相干的分数
Reconstruct 接收办公室视频，生成三维重建，并提供切成二维障碍地图的函数。Localize 用带已知位姿的视频帧，把无人机当前画面匹配到地图位置。Navigate 根据地图规划跨房间路线，飞行中还要反复调用定位，修正控制噪声。Detect 根据目标人员的参考照片，在视频帧里返回边界框。Follow 再用边界框调整方向和距离，让目标尽量保持在画面中心。
接口契约至少要记录输入、输出、误差单位和失败状态。下面是一份可以实际落到评测仓库的简表，它是依据任务依赖关系整理的工程方案，不是官方规定的字段格式。
text
阶段：reconstruct / localize / navigate / detect / follow
输入资产：视频、参考图、地图、当前帧、飞行状态
输出对象：mesh、2D map、pose、path、bbox、control command
坐标系与单位：world / camera / map，米 / 像素 / 角度
允许误差：位置、朝向、检测框、跟随距离
失败状态：无地图、位姿丢失、路径不可达、目标丢失、控制超限
上游版本：数据集、模型、算法提交、随机种子这里最容易漏掉的是坐标系。重建给出的门洞位置偏了一点，定位仍可能在错误地图里显得很稳定；导航模块也会忠实地规划一条"穿墙路线"。若只检查每个函数是否返回结果，链路错误要到真机撞上障碍才暴露。验收时应同时保存真值坐标、预测坐标和转换参数，不能只保存最终航迹视频。
基线应是可重建的系统，不是一个模糊的人类分数
Andon Labs 让人类研究人员与编码智能体共同开发各子任务算法，并把组合后的端到端系统作为现实基线。模型某个子任务达到或超过这套基线，才算完成该项。官方特别说明，这既不是无辅助人类能力的下限，也不是人机协作的上限；它描述的是熟悉 AI、但并非全职机器人专家的团队，使用现代工具能做到什么。
复现时应把基线也当作有版本的软件交付物。至少保存基线提交哈希、依赖、硬件、输入视频、运行次数和评分脚本。否则，某模型"超过基线"可能只是比较了不同地图、不同检测器或不同容错阈值。若基线后来修复了重建算法，历史模型成绩也不能直接与新成绩横向排列。
还有一层常被忽略：一次最好成绩和稳定表现不是同一个指标。官方对每项运行十次时，模型在五项中的四项至少有一次达到人机团队基线；但表现最好的 Fable 5，按平均结果只有三项达到基线。报告还估计，模型当前稳定表现大约落后其最好单次表现六个月。工程看板因此至少应并列显示 best-of-n、平均值、成功次数和最差结果，不该只拿最高分做发布门。
用错误注入检查上游偏差怎样向后传
这类链式系统不能只跑干净样本。可以人为让地图门洞平移、给定位加入逐步漂移、短暂遮挡目标、让目标走出画面，再看下游是否识别到输入已经失效。测试重点不是"还能不能勉强飞"，而是错误有没有被显式标记，系统会不会在不确定时继续输出高置信动作。
一组实用的故障矩阵可以这样安排：
| 注入位置 | 注入方式 | 应观察的结果 |
|---|---|---|
| 重建 | 删除门框或移动墙面 | 定位残差是否升高，导航是否拒绝穿越 |
| 定位 | 累积航向偏差 | 重定位频率、路径修正量、停止条件 |
| 导航 | 禁用一条通道 | 是否重新规划，还是重复撞向同一区域 |
| 检测 | 遮挡或相似人物 | 目标身份是否切换，丢失后是否停飞 |
| 跟随 | 目标突然转向 | 距离超限、 reacquire 次数、控制振荡 |
Fable 5 的真机结果正好说明为什么要做这一步。它在检测和跟随上明显优于参考算法，却因为重建错误影响定位与导航，把墙判断成门，无法自主跨房间。单看后两项会得到"跟随能力已经很好"的判断；把依赖链连起来，结论变成"上游空间模型仍足以让整套系统失效"。
仿真晋级真机之前要过三道门
软件复测的价值是速度和重复性，真机的价值是暴露传感器噪声、控制延迟与环境偏差。两者不能互相替代。建议把晋级条件分为三道：单项在多随机种子下达到预设成功率；相邻阶段联调时没有未捕获的坐标或置信度错误；端到端仿真在最差条件下能进入安全停止，而不是只看平均航迹。
进入真机后再限制速度、区域、人员和退出方式。Project Pilot 本身使用的是室内单层办公室、有限人数和慢速无人机，也没有测试户外大规模人群。这样的结果适合说明能力方向和失败结构，不足以替代真实部署环境的可靠性证明。
仿真与真机还要使用能够对应的事件编号。比如仿真把"目标离开画面 2 秒"判为丢失，真机日志就不能只写"视觉异常"；两边应记录相同的丢失时刻、最后可信位姿和控制输出。若传感器频率不同，则把条件换成时间而非帧数。这样才能判断仿真中修复的重捕获逻辑，到了真实摄像头和网络延迟下是否仍然成立。
评测也应保留负例，而不是只保存成功视频。将撞墙、错过门洞、跟错人和悬停超时分别建成固定回归样本，每次更新重建模型或导航策略后重放。若新版总体平均分提高，却在某个已知危险样本上退步，发布门不应被均值掩盖。
一次可评审的运行记录应回答这些问题：哪个版本生成了地图；定位误差怎样传播；何时丢失目标；哪条规则触发停止；失败能否用同一输入复现。视频可以帮助人理解过程，但只有结构化运行记录能支持回归测试。把演示拆开不是为了多做五张排行榜，而是为了在端到端能力突然看似"跃升"之前，看见每个必要条件正在怎样变化。
官方来源：Anthropic 与 Andon Labs，《Project Pilot: Can AI control a drone?》，2026 年 7 月 24 日。