让 Claude 开塞斯纳：一场没飞成的 AI 试航，反而暴露了智能体最真实的短板
当大模型坐进驾驶舱，故事就突然变得具体了
“AI 会不会取代人类驾驶员”这种问题，平时听起来总有点空，像饭桌上的科幻聊天。但这次实验很不一样。博主把 Claude 接入飞行模拟器 X-Plane 12，让它自行查阅 API、自己写 Python 控制脚本，然后尝试驾驶一架 Cessna 172，从海口美兰机场飞去琼海博鳌附近。
结果既像喜剧，也像工程事故复盘会。Claude 记录了自己的“飞行日志”：15:54 在海口美兰机场 09 号跑道对正，计划以 55 节抬轮、75 节爬升；15:57 成功离地；15:59 因控制器把 861 英尺/分钟的爬升视为“过猛”，直接给了过大的低头指令，飞机一度翻到 60 度左倾；16:00 首次坠毁。之后它重写控制逻辑，第三次起飞终于稳定得多，能完成爬升、平飞和左转航线，甚至像个认真但手生的学员飞行员那样，一边飞一边修自动驾驶代码。可到了进近阶段，因为基准航线没算好，加上控制器竟然有约 20 秒“空窗期”，飞机一路缓慢下沉，最终在距跑道 1.7 海里处撞地。
如果你只看结果，这当然不是“Claude 学会开飞机”了。可如果你盯着过程看，会发现它已经不是一个简单的聊天机器人在胡说八道，而是一个能读文档、写代码、观察状态、修补控制器并继续尝试的执行体。它离“真会飞”还有距离，但也已经离“只是会聊天”很远了。
最有意思的，不是坠机，而是它像个工程师一样犯错
这场实验最迷人的地方，是 Claude 的失败非常“人类工程师化”。它并不是随机乱来，而是在非常典型的控制系统问题里栽了跟头：增益太高、缺乏阻尼、状态切换不平滑、对延迟估计不足、没有给低空场景设计足够保守的保护逻辑。
比如第一次严重失稳，本质上就是一个非常教科书式的控制问题。飞机刚离地，系统把爬升率 861 英尺/分钟判断为“偏离目标 700 英尺/分钟太多”，于是电梯指令过猛向前推，导致机头猛压，速度冲到 125 节，航向也被带偏。这一段看得人甚至有点哭笑不得：Claude 的问题不是“不懂飞行术语”，恰恰相反，它已经能写出“目标俯仰角—姿态 P 控制—限制爬升率”这样的结构，只是调参和边界条件处理还太嫩。
后续它也确实像一个会复盘的工程师那样改进了算法。它把控制器改成了更保守的纯比例控制，取消了一部分积分项，加入了更平滑的切换逻辑，避免在远低于目标高度时还允许系统主动压低机头。第三次尝试里，飞机成功稳定巡航，保持在 82 节左右，航向控制也相当像样，左转三个 90 度都做出来了。
但真正击垮它的，不再是飞行原理，而是系统工程。进近时它需要一边截图、一边读取 API 状态、一边计算下一步动作，还要顺手记飞行日志。飞行器控制却是一个对时延极其敏感的任务，20 秒没有闭环控制，在天上已经不是“反应慢一点”，而是“足够掉下去了”。这几乎是今天所有智能体项目都会撞上的同一堵墙：会推理，不等于能稳定执行；会执行，不等于能在实时世界里活下来。
这件事为什么重要：AI 正从“答题”走向“控物”
过去两年，我们看了太多大模型考试、编程、写报告、做客服，甚至帮人点外卖、订机票的演示。很多人已经有点审美疲劳了，因为这些任务大多发生在数字界面里，哪怕做错了，最多是页面报错、脚本失败、输出一段离谱文字。
但飞行模拟不是这样。它虽然仍是虚拟环境，却已经具备“物理世界代理”的典型特征：状态连续变化、系统存在惯性、每个动作都有代价、错误会累积、反馈有延迟。你不能像聊天那样停顿半分钟再想想，也不能把上一步做错了靠“重新生成”糊过去。在这样的环境里，智能体的能力会被迅速拉回现实。
这也是为什么我认为，这场“Claude 开飞机”的实验比许多漂亮的 AI Demo 更有价值。它不在于证明某家模型更聪明，而在于提醒所有人：从“会说”到“会做”，中间隔着一整套控制论、系统安全、实时架构和异常处理。今天很多 AI 产品在办公软件里看起来很能干，是因为容错空间巨大；可一旦进入机器人、无人车、工业设备、医疗器械、飞控系统这种领域，模型本身往往只占总难度的一小部分。
这让我想起自动驾驶行业这十年的经验。外界总以为自动驾驶的核心是“识别得准不准”，后来大家才慢慢明白，真正难的是感知、规划、控制、冗余、安全和人机接管机制如何组成一个稳定闭环。大模型智能体眼下也处在类似阶段：大家惊叹它“懂很多”，但真正决定它能否进入现实世界的，常常不是知识量，而是系统是否足够稳。
Claude 没飞成，不代表这条路走不通
当然，也不能因为这次坠了两次，就得出“AI 根本不可能驾驶飞行器”的结论。恰恰相反，这个实验已经证明了一件颇有分量的事：通用大模型在没有被专门训练成飞控软件的前提下，仅靠读文档、写脚本和在线修补，就已经能把一架模拟塞斯纳从起飞带到稳定巡航阶段。这事放在几年前，听起来仍像段子。
更重要的是，Claude 暴露出来的问题，其实都不是不可解的。截图和 API 状态更新太慢，可以换成更高频的数据通道；控制器调用存在空档，可以用常驻进程替代一次次脚本执行；进近几何算不好，可以加专门的航迹规划模块；姿态控制脆弱，也完全可以交给传统 autopilot，只让模型做高层决策。这实际上已经指向一个业内越来越清晰的方向：大模型不必亲自“拧每一个舵面”，它更适合做任务规划、异常解释、策略切换和人机协作，而把毫秒级控制交给传统系统。
换句话说，最现实的未来不是“让 Claude 直接当机长”，而是“让 Claude 成为机长旁边那个永远不困、会查手册、会写程序、会辅助决策的副驾驶”。在航空之外，这个思路也适用于机器人、工业自动化、仓储调度甚至家庭智能设备。大模型像一个脑子很快但手还不稳的实习生，真正靠谱的产品设计，是别让它独自握住方向盘，而是把它放在最适合它的位置上。
比起好不好笑，我们更该问：谁来为 AI 的动作负责
这类实验还有一个绕不过去的问题：当 AI 不再只是输出文本，而是开始输出动作，责任边界该怎么划？在模拟器里，坠机只是重置到跑道；在现实世界里，任何“20 秒没控制”的空窗都可能是事故调查报告里的核心段落。
所以我看这篇实验记录，最大的感受并不是“Claude 真笨”或者“Claude 已经很强”，而是我们终于有机会更认真地讨论一个现实议题：当大模型接入真实设备，它到底应该拥有多大权限？是只能建议，还是可以执行？执行到哪一层？遇到不确定状态时，是继续尝试还是立刻交还控制？这些问题，比模型排行榜上的一两分差距重要得多。
说到底，飞行是一件很诚实的事。你可以用漂亮的话解释一切，但升力、俯仰、速度和地面不会跟你客气。也正因为如此，飞行模拟器成了检验 AI 智能体的一面好镜子：模型有没有真正理解环境，系统是不是闭环，产品有没有把“安全”放在“惊艳”前面，几圈下来几乎都会见分晓。
Claude 这次没把飞机飞到目的地，却把一个行业的真问题飞出来了。这比一次完美降落，可能还更有新闻价值。