这篇是「如何制作一款开放世界游戏」系列的玩家载具驾驶序章，承接此前的人口、车辆和交通运行时篇。车辆篇讨论一辆车内部的所有权、座位关系、驾驶权与执行栈；交通篇讨论多辆车如何共享路网、路口和事件系统。本篇继续追问：当驾驶者变成玩家时，玩家如何进入这套运行时，又如何在离开时把它交还给世界？
相关材料来自成熟商业开放世界引擎与客户端代码的长期源码级阅读，覆盖车辆智能、汽车驾驶任务、GPS 路线、局部避让、驾驶策略、载具战斗、碰撞物理、网络控制和回放。公开文章延续匿名化处理，并区分原版机制、UE5 迁移判断与原型实现状态。
本子系列分为 12 篇方案篇和 12 篇落地篇。完整索引放在文末，正文先处理一个问题：玩家驾驶为什么会成为车辆运行时中最复杂的一次控制权变化。
赛车游戏首先解决的是“车辆如何响应输入”，而开放世界首先解决的是“玩家如何进入一辆已经存在的车辆运行”。
引言：玩家坐进驾驶席之后，发生了什么
玩家走向一辆车。
系统需要先确认目标车辆、可用座位和当前任务状态。座位可能已经被预约，角色可能没有进入权限，车辆也可能正在由 AI 驾驶。车门打开并不代表驾驶权已经建立；角色进入、座位确认、驾驶者身份写入、旧控制源释放、摄像机切换完成之后，玩家输入才真正有了对象。
随后，玩家在地图上设置一个目的地。GPS 生成路线，任务系统可能增加检查点或时间限制，交通系统处理路口和其他车辆，局部避让系统观察眼前的障碍。玩家转动方向，车辆却同时处理着输入、任务、路线、交通、物理和表现。
车辆撞上路障之后，速度和姿态交给物理系统，损伤状态发生变化，任务系统判断是否继续，车内角色可能切换武器，警察车辆可能进入追逐。玩家离开驾驶席后，车辆也不一定离开世界：它可能继续由 AI 驾驶，进入远景表示，成为网络实体，或者在特定回放模式下由记录状态继续驱动。
玩家只执行了几个动作，车辆运行时却完成了多次控制权交接。
一段普通的驾驶过程
为了看清这些交接，可以把镜头放回玩家接近车辆的那一刻。
阶段一：车辆还不属于玩家
这辆车可能正在由一名 AI 驾驶。它有当前路线，有任务阶段，有驾驶者，也可能已经被某个事件系统登记为响应资源。玩家按下进入键时，系统并不是简单地执行：
Driver = Player
它需要先判断旧驾驶者是否可以释放，玩家要进入的座位是否仍然可用，车辆是否允许当前任务接管，以及玩家角色是否已经满足进入条件。若进入动作在中途被打断，旧的驾驶者关系不能被提前清掉；若玩家成功进入，原有 AI 任务也不能在没有处理的情况下留在车辆上继续写入控制。
完整接管需要按顺序结算这条状态链，不能简化为一次变量赋值。
玩家看到的是角色坐进驾驶席，系统完成的却是一组关系和权限变化。驾驶权不是一个变量，而是一系列状态变化的结算结果。
阶段二：玩家正在驾驶
玩家设置导航目的地，车辆开始沿道路前进。对玩家而言，这意味着驾驶已经交到自己手中。
从运行时角度看，至少有几条链路正在同时工作：GPS 维护路线，任务系统维护目标和阶段，交通系统提供道路约束，局部避让系统检查前方风险，摄像机反馈速度和方向，物理系统推进车辆状态。玩家只提交了当前驾驶意图，其他系统围绕这份意图提供目标、约束和反馈。
如果路线即将失效，GPS 可以重新规划；如果前方出现障碍，避让系统可以提出减速或绕行建议；如果车辆发生碰撞，物理和损伤状态会改变车辆的可控性。它们都可能影响驾驶结果，但并不意味着它们都可以直接夺取方向盘。
阶段三：玩家离开车辆
玩家按下离车键，控制权再次发生迁移。车辆是否停止，是否继续执行任务，是否交给 AI，取决于当前车辆状态。停在路边的普通车辆、仍在追逐中的车辆、任务要求保持运行的车辆和已经受损的车辆，不能使用完全相同的离车策略。
玩家离开之后，车辆仍然可能留在世界中。它可能由 AI 接回路线，可能降低更新频率进入远景，可能由网络系统交给另一端，也可能在特定回放模式下由记录状态继续驱动。
玩家没有创造这辆车的运行，也没有在离开时销毁它。玩家只是进入了一段已经存在的运行时，又在另一个时间点退出。
本文的判断是：
开放世界里的玩家驾驶，首先是一个控制权迁移问题，其次才是输入映射问题。
玩家进入驾驶席后，成为车辆当前有效的主要驾驶命令来源。AI、脚本和回放仍保留接管入口，任务和路线继续提供目标与约束，网络系统决定哪一端有权提交最终状态。玩家并非从零开始建立车辆控制，而是暂时进入一辆已经拥有身份、任务和运行循环的车辆。
“接管”不是瞬时动作。系统至少要完成三个阶段：确认玩家可以成为驾驶者，确认车辆接受玩家提交的命令，以及确认执行结果能够返回玩家侧。任一阶段缺失，都会出现具体的状态错误：角色已经入座但没有控制权；输入已经提交但车辆没有反应；车辆开始运动后，摄像机、任务与物理状态彼此不一致。
在实现上，玩家接管车辆属于状态迁移，不是一次函数调用。旧 AI 任务不能直接删除，当前路线不能无条件丢弃，摄像机也不能只切换到另一个位置。系统必须明确哪些状态由玩家继承，哪些由任务继续维护，哪些需要清空，以及哪些状态在玩家离开后交还给 AI。
为什么开放世界驾驶不同于赛车游戏
赛车游戏的驾驶问题通常可以沿着一条相对集中的路径理解：玩家输入经过车辆控制和物理反馈，最终服务于比赛结果。车辆可能有复杂的动力学、轮胎模型和悬挂，但它的世界关系相对稳定。玩家拥有车辆，比赛提供目标，赛道提供空间边界，碰撞通常服务于比赛结果。驾驶系统的主要问题是：车辆如何在输入下表现得像一辆可信的车。
开放世界中的车辆还要面对另一组问题。玩家进入之前，车辆可能已经由 AI 驾驶；玩家离开之后，车辆仍然要在世界中存在；任务可以随时改变目标，交通系统会改变道路环境，网络和回放会改变状态的提交者。此时驾驶不再是一条从输入直达比赛结果的单线流程，而是控制权、目标、交通、执行和世界持续运行共同参与的运行时链。
赛车关注“车怎么开得像车”，开放世界还要关注“车怎么一直属于这个世界”。前者可以把车辆看成比赛中的运动对象，后者必须把车辆看成具有身份、任务、关系和生命周期的运行实体。
开放世界仍然需要车辆物理，但物理不是全部问题。物理负责车辆运动，运行时负责保证车辆在玩家输入、AI 接管、任务变化、碰撞、远景和网络切换之后仍保持同一身份。
一、三个系列，三种问题
| 系列 | 核心问题 |
|---|---|
| 车辆运行时篇 | 一辆车内部的状态归谁，驾驶权和执行如何保持一致 |
| 城市交通篇 | 多辆车如何共享道路、路口、信号和事件资源 |
| 玩家驾驶篇 | 控制权如何在玩家、AI、脚本、网络与回放之间转移 |
前两个系列解决“车辆如何存在”，本系列解决“谁可以暂时改变它”。
玩家驾驶篇不重复车辆篇和交通篇的内容。车辆篇回答“车辆如何拥有自己的运行时”，交通篇回答“车辆如何进入更大的世界协同”；本篇增加一个观察角度：玩家作为控制命令来源，如何进入、使用并离开这套结构。
玩家驾驶与车辆 AI 的关系也需要重新理解。玩家输入和 AI 任务来自不同的上层，但最终都要驱动同一辆车。玩家提供方向、速度和接管意图，AI 提供巡航、跟随、追逐或逃逸任务；任务脚本提供阶段和约束，回放系统提供已经记录的控制数据。它们的区别，不在于是否进入车辆执行层，而在于谁有资格在当前状态下提交驾驶命令。
二、四种状态不能混在一张图里
玩家驾驶系统中经常被混在一起的，其实是四类不同问题。
第一类是驾驶命令来源：玩家输入、车辆 AI、脚本强制控制和回放数据。它们可能竞争同一辆车的控制权。
第二类是目标与约束来源：任务目标、GPS 路线、交通规则和局部风险。它们通常不直接输出方向盘控制，而是决定车辆应该去哪里、能以什么方式前进。
第三类是网络权威位置：本机、远端或当前网络所有者。网络迁移不是一种驾驶命令，它改变的是哪一端有权提交和复制实体状态。
第四类是失效与恢复状态：物理失控、车辆损伤、执行器不可用和安全恢复。它们不是普通控制源，而是对当前驾驶链的反馈和兜底。
控制源不存在适用于所有场景的固定优先级。玩家接管时，AI 需要释放或保存当前状态；任务强制控制时，玩家输入可能暂时失效；回放开始时，玩家输入退出当前控制窗口；网络迁移时，控制命令的提交权随权威位置变化。
控制源的变化本身就是车辆状态的一部分。
同一辆车上同时存在几种时间
玩家输入通常以控制帧为单位变化，物理以更高频率推进，路线可能在几秒后才重新规划，任务阶段则可能持续数分钟。四种时间不会同步结束，因此车辆不能只保存一个“当前状态”。
玩家松开油门，输入可以立即变成零；车辆的速度却不会立即归零，物理仍然需要继续结算。前方道路被封闭，路线系统可能需要等待异步搜索；在搜索结果返回之前，局部避让仍然要处理眼前障碍。任务进入下一阶段，也不代表旧的物理接触已经结束。
如果所有系统都在自己的时间尺度上直接写入车辆，状态就会发生竞争：路线已经更新，执行器仍在消费旧路径；玩家已经接管，AI 仍提交上一帧命令；任务已经失败，物理恢复却把车辆拉回可控状态。驾驶运行时应明确每类状态的有效期、提交者和结算顺序。
玩家看不到这些时间戳和版本号，只能感知结果：车辆是否平滑减速，路线是否在合适的时机改变，碰撞后是否还能继续驾驶。所谓“自然”，往往来自不同时间尺度之间没有互相覆盖。
三、三个核心问题
谁能控制这辆车
驾驶权不是一个表示“玩家正在开车”的开关。角色可能还没有完成进入流程，玩家可能坐在乘客座位，AI 可能暂时控制车辆，任务可能要求车辆执行特殊动作，远端机器可能仍然拥有网络权威，车辆也可能已经进入物理失效状态。
一次可靠的接管需要完成旧控制源释放、当前车辆状态接收、新控制源确认和输入清理。玩家成为驾驶者之后，系统还必须知道控制何时失效，以及失效后由谁接回车辆。
为什么驾驶权不是一个 bool
最容易写出的版本可能只有一个标志：
bIsPlayerDriving = true;
但这个标志无法回答几个立即出现的问题：谁负责把它清回 false，旧的 AI 任务是否仍然存在，玩家离车后由谁重新接管，网络上的另一端是否同意这次变化，任务是否允许玩家在当前阶段驾驶，以及座位关系是否已经完成确认。
第二种常见做法，是让玩家输入直接覆盖 AI。这样可以很快得到“玩家能开车”的结果，但会留下另一组冲突：追逐任务是否仍然需要 AI 维护目标，脚本强制控制如何插入，路线是否继续更新，玩家松开输入时车辆回到什么状态。输入覆盖并没有解决控制权，只是让最后写入车辆的系统暂时获胜。
第三种做法，是让物理成为唯一最终权威。物理确实决定车辆这一帧的运动结果，但它不知道车辆为什么要去某个地点，也不知道碰撞之后任务是否失败、AI 是否应该恢复或玩家是否仍然拥有接管权限。把物理结果直接当成完整运行时状态，同样会丢失任务和所有权信息。
更完整的驾驶权状态至少需要分别表达：
这四项可能在同一时刻指向不同对象。玩家可以是当前控制命令来源，网络远端可能仍然拥有实体权威；任务可以提供目标，AI 可以提供辅助执行；物理可以反馈车辆失控，但并不因此自动成为任务所有者。
驾驶权的价值不在于告诉系统“玩家正在开车”，而在于让系统能够解释玩家为什么可以开、当前命令是否有效，以及下一次控制权应该交给谁。
三种看起来能运行、实际上会失控的设计
第一种设计，是让玩家输入直接写入车辆：
Vehicle->SetThrottle(Input);
这种写法适合验证最小控制链，却无法承担开放世界的车辆关系。AI 仍然可能在另一条路径上提交控制，任务可能要求车辆前往新的目标，回放可能需要重建车辆状态。多个系统都直接写入车辆时，最后一次写入只代表更新顺序，不代表真正的控制权。
第二种设计，是让玩家和 AI 各自拥有一套车辆控制器。玩家驾驶时使用一套物理和状态，AI 接管时切换到另一套物理和状态，表面上能够分别运行，交接时却会出现速度、姿态、路线和损伤无法对齐的问题。控制器可以有多个，车辆状态不应该因此分裂成多份。
第三种设计，是让任务直接控制车辆。任务脚本为了完成一段剧情，可以直接指定目标位置、速度甚至车辆姿态；但任务结束之后，谁负责恢复玩家输入，谁清理强制控制，谁处理车辆已经发生的碰撞，通常没有明确答案。任务应该提供目标和阶段，车辆执行层负责把目标变成运动，二者之间需要一个可追踪的命令边界。
更可靠的结构，是让输入来源经过命令仲裁，生成统一的 Driver Command，再由车辆执行器交给物理层处理，而不是让多个系统直接争夺物理对象。
玩家、AI、脚本和回放都可以成为输入来源，但它们不直接争夺物理对象。仲裁层确认当前有效来源，命令对象携带来源和有效期，执行器把命令转换为车辆控制量，物理反馈再返回车辆运行时。这样，控制权可以迁移，车辆状态却不必被反复重建。
车辆要完成什么
任务系统决定目标和阶段，GPS 提供路线，交通规则和局部风险提供约束，驾驶策略决定速度、让行和风险偏好。它们共同构成驾驶意图，但不应该各自直接修改物理对象。
任务目标、路线目标和控制目标必须分开。任务要求抵达某个地点，路线系统决定沿哪条道路前进，执行层才决定当前这一帧使用多少转向、油门和制动。
意图如何变成运动
执行器把玩家输入、路线、策略和 AI 命令转换为车辆控制量，物理系统根据控制量推进车辆状态，并把速度、姿态、碰撞和失效结果反馈回来。
物理是执行结果，不是驾驶决策来源。它不理解任务目标，任务系统也不负责计算轮胎接触。两者之间的接口决定了玩家控制、AI 驾驶、运动学预览、网络同步和真实物理能否共享同一条链。
四、第一阶段：成为驾驶者
第一阶段从进入车辆开始，而不是从方向键开始。座位预约、进入确认、换座、离车和被拽出，决定了角色与车辆之间的关系是否成立；输入和摄像机随后才有明确的控制对象。
玩家输入需要经过采样、来源确认和状态过滤，摄像机则把速度、方向、倒车、碰撞和接管状态反馈给玩家。玩家按下按键并不意味着车辆必然转向，系统首先要判断玩家当前是否拥有驾驶命令的提交权。
任务系统接着为驾驶提供目的地、阶段、检查点和时间约束。车辆 AI 则负责在玩家没有接管、玩家暂时离开或任务重新要求自动驾驶时继续维护车辆运行。玩家和 AI 的控制来源不同，但它们必须在同一套车辆关系和执行接口上交接。
这一阶段的终点不是车辆开始移动，而是车辆能够明确回答：当前控制者是谁、控制依据是什么、控制何时失效。
玩家与 AI 的三种交接
第一种是玩家接管 AI。比如一辆出租车原本由 AI 驾驶，车辆已经拥有路线和当前驾驶任务；玩家进入驾驶席之后，AI 不需要被销毁，车辆也不需要从零生成一套新状态。AI 保存或释放当前任务，玩家获得驾驶命令提交权，路线和车辆身份继续保留。
第二种是玩家离开之后的 AI 恢复。玩家退出驾驶席，车辆可能停在原地，也可能仍处于任务阶段。系统需要决定是让 AI 继续路线、等待新的驾驶者，还是将车辆转入低成本世界行为。关键不是“AI 是否重新生成”，而是车辆之前的目标、路线和状态是否能够被正确接回。
第三种是任务强制控制。某些剧情阶段中，玩家仍然是车辆中的驾驶者，但任务会限制目标、路径或控制范围；另一些阶段则可能暂时让脚本或 AI 驱动车辆。这里必须区分控制命令来源和目标约束来源：任务可以改变车辆必须完成的目标，却不一定直接产生每一帧方向；玩家可以继续控制方向，却不能违反任务要求的阶段条件。
这三种交接说明，AI 与玩家并不构成两套互斥的车辆系统。AI 可以在玩家进入前拥有车辆，在玩家离开后恢复车辆，也可以在任务要求下提供目标和辅助。仲裁层需要确定当前哪一个来源可以提交驾驶命令，以及其他来源如何保存、等待或退出。
控制权迁移也不是一次事件，而是一条有生命周期的状态链。其关键阶段包括 AI 驾驶、接管请求、座位确认、玩家持有、释放请求和 AI 恢复。
每个阶段拥有的东西并不完全相同。座位确认阶段主要处理关系，玩家持有阶段主要处理输入和摄像机，AI 恢复阶段主要处理任务和路线，网络迁移则贯穿这些阶段，决定哪一端能够提交最终状态。把这些阶段压缩成一个 IsPlayerDriving 标志，正是许多接管问题无法被解释的原因。
五、第二阶段：车辆如何完成驾驶
第二阶段讨论车辆如何从玩家或 AI 的意图走向真实运动，以及如何在变化的道路环境中完成目标。
路线系统解决的不是一次性寻路，而是在世界变化时保持一条可用的路。玩家改变目的地，AI 遇到路障，任务进入新阶段，目标区域尚未流式加载，都会导致路线重新生成或失效。玩家 GPS 和 AI 路线可以共享道路图和路径搜索能力，却不能共享全部生命周期。
路线确定之后，还要经过驾驶策略。速度、跟车距离、让行倾向、风险容忍度和车道偏好，使不同车辆沿同一条道路呈现出不同的行为。玩家辅助系统可以提供路线提示、稳定、限幅和风险反馈；AI 则可以把策略结果交给执行器，但二者不能混淆控制权。
长距离路线也无法处理车辆眼前的每个障碍。局部避让需要预测碰撞、评估切线、选择减速或绕行，并在障碍消失后恢复原路线。路障、临时封闭、近失、鸣笛和交通参与者反馈，都属于这一层。
这一阶段可以压缩为以下关系：
路线决定往哪里走，策略决定倾向于怎样走，局部避让决定此刻能不能这样走。
六、第三阶段：车辆如何继续存在
第三阶段把前面的目标和约束交给执行层，并继续处理碰撞、战斗、追逐、网络、回放和多载具状态。
驾驶执行栈负责把路线、策略、玩家输入和 AI 指令转换为转向、油门、制动和档位等控制量。零输入、路线清空、控制权切换和执行器失效，都必须产生可解释的结果。运动学预览可以为远景车辆或低成本车辆提供行为表现，但它需要在明确的状态边界上与真实物理切换。
物理系统随后处理速度、姿态、接触和损伤。碰撞、翻车、爆胎、发动机失效和爆炸不只是画面表现，它们会改变车辆是否仍然可控，是否触发任务失败，是否需要强制下车或交给 AI 接管。
车内战斗会同时占用驾驶、座位、瞄准、摄像机和武器权限；追逐和逃逸会重新安排路线、风险、局部避让和支援资源。更远处，LOD、网络、录制、回放以及船、飞机和铁路载具会继续挑战状态连续性。
玩家离开车辆之后，车辆仍然可能继续运行。回放也不是简单地重新播放画面；在特定模式下，它会成为车辆状态的驱动来源。不同载具不必共用同一套控制律，但都要能够回答：当前谁拥有它，它正在执行什么，下一层能否可靠地消费它的状态。
七、后续文章如何展开
后续落地篇不再重复解释所有机制，而是把三阶段分别转成工程问题。
第一组落地内容处理控制入口：座位账本、进入与接管、输入采样、摄像机、驾驶权和任务意图。目标是让系统能够记录输入何时生效、何时被拒绝，以及旧控制源如何退出。
第二组落地内容处理目标与策略：路网、GPS、异步路线、驾驶个性、交通辅助和局部避让。重点是路线结果的身份、版本和有效期，避免迟到结果覆盖新状态；同时让玩家辅助和 AI 策略共享评估逻辑，但不共享最终控制权。
第三组落地内容处理执行与复杂状态：Driver Command、运动学预览、物理适配、碰撞损伤、车内战斗、追逐、LOD、网络和回放。汽车、船和飞机可以使用不同执行器，但控制命令、状态快照、错误报告和权威迁移需要保持可验证。
这也是 AI 在本系列中的位置。玩家驾驶的问题不是代码量本身，而是隐藏状态过多。AI 可以帮助整理跨越任务、座位、路线、车辆智能和物理的关系，生成可核对的规格和检查表；哪些关系真正成立，哪些内容可以进入原型，仍然由人决定。
具体来说，AI 最适合协助追问四个问题：谁拥有这份状态，谁可以修改它，谁负责在失败后恢复它，以及下一层需要消费哪一种结果。把一份源码阅读记录、测试输出和原型接口放在一起时，AI 可以帮助发现它们之间缺失的连接：某个任务是否真的有取消路径，某个座位预约是否存在超时清理，某个控制命令是否记录了来源，某个物理失效是否有重新接管入口。
这些工作不会替代车辆系统设计。它们把“车辆会自己运行”拆成一组可验证的状态关系。关系是否成立，仍由源码证据、原型测试和工程判断决定。AI 可以压缩复杂材料，但哪些关系需要保留，必须由人决定。
八、这套系列真正要解释的“驾驶感”
驾驶感当然来自车辆质量、轮胎摩擦、转向响应和悬挂参数。但这些参数只说明车辆如何运动，不能说明玩家为什么相信这辆车仍然属于自己。
这种信任来自一组连续的结果：进入车辆后，驾驶权确实落在玩家手中；设置路线后，导航、任务和车辆不会各自维护不同目标；发生碰撞后，速度、姿态、损伤和任务状态能够互相解释；玩家进行车内战斗时，控制权不会无原因丢失；玩家离车之后，车辆仍然能够作为世界中的实体继续存在。
玩家为什么觉得这辆车属于自己
第一是状态连续。车辆撞上墙体之后，速度、姿态和损伤发生变化，但车辆不会无缘无故跳回碰撞前的位置；如果物理系统暂时失效，也应该有明确的恢复过程，而不是下一帧突然替换成另一种状态。
第二是权限连续。玩家换座、下车、重新上车或把车辆交给任务控制时，驾驶权需要沿着座位、角色和车辆关系正确迁移。玩家不一定永远拥有控制权，但控制权的变化必须有原因，并且能够被车辆运行时确认。
第三是世界连续。玩家离开车辆后，车辆仍然是世界中的同一实体。它可能停止、继续执行任务、由 AI 接管或进入远景，但路线、身份和必要状态不能因为玩家离开摄像机范围就全部丢失。
第四是时间连续。网络迁移和回放会把车辆带入不同的时间与权威环境。回放不是简单地重新播放一段画面；在特定模式下，它需要根据记录状态驱动车辆，同时避免把旧状态错误地写回当前运行时。
这些连续性共同形成了“驾驶感”的底层。加速度、摩擦和转向响应决定车辆运动得像不像一辆车；控制权、任务和状态连续性则决定玩家是否相信这辆车仍然属于当前世界。
玩家感受到的不是某一个“驾驶组件”，而是多个系统能否在同一时刻保持一致。
玩家驾驶可以看作一连串控制权迁移：玩家进入，车辆让出；玩家驾驶，任务与路线提供约束；玩家离开，AI、网络或回放重新接管。每次交接都需要保留车辆身份、目标和状态。任何一项丢失，车辆都会显得像换成了另一个实体。
九、12+12 总索引
方案篇
- P1 进入车辆、座位关系与驾驶接管：玩家什么时候真正拥有这辆车。
- P2 输入、驾驶权与载具摄像机：玩家输入什么时候真正属于车辆。
- P3 玩家输入如何汇入 Driver Command：按键如何变成车辆可以消费的命令。
- P4 AI 如何让出方向盘并重新接管：玩家驾驶和 AI 驾驶如何共存。
- P5 玩家目标如何变成导航：车辆如何知道应该去哪里。
- P6 玩家辅助与 AI 驾驶的风险模型：为什么不同驾驶者表现不同。
- P7 局部避让与即时风险：眼前障碍如何处理，以及何时不能夺权。
- P8 执行器、运动学与物理接缝：意图如何变成真实运动。
- P9 碰撞、损伤与失控恢复：车辆失效之后如何回到可解释状态。
- P10 驾驶、瞄准与车内战斗：驾驶和其他交互如何共存。
- P11 追逐、逃逸与动态控制权：事件如何改变驾驶规则。
- P12 网络、回放、LOD 与多载具延续：玩家离开后，车辆如何继续属于世界。
落地篇
- L1 玩家输入、驾驶权与载具摄像机落地：输入采样、控制权仲裁和摄像机状态。
- L2 座位账本、进入流程与驾驶接管落地：预约、确认、释放、回滚和接管协议。
- L3 驾驶任务与意图接口落地：任务对象、阶段、目标、取消与抢占。
- L4 持久车辆智能与 AI 驾驶入口落地：车辆智能、驾驶者桥接和任务收养。
- L5 GPS、路网与异步路线运行时落地：路线槽、异步搜索、重规划和路径消费。
- L6 驾驶策略与交通辅助落地：策略函数、风险参数、速度调制和辅助控制。
- L7 局部避让与道路事件执行落地：障碍预测、切线评分、路障和恢复。
- L8 Driver Command 与车辆执行器落地：控制契约、执行器、预览和多车型接口。
- L9 物理适配、碰撞与损伤状态落地：物理适配器、碰撞、损伤和失效恢复。
- L10 车内战斗与载具武器接口落地：座位武器、瞄准、Drive-by 和并行控制。
- L11 追逐、逃逸与特殊驾驶任务落地：任务重规划、警察车辆和事件执行。
- L12 LOD、网络、回放与多车型执行器落地：远景、控制迁移、回放以及船机车。
如果说车辆篇回答的是“一辆车内部的状态归谁”，交通篇回答的是“许多车辆如何共同运行”，那么这组文章要回答的是：
当玩家只转动一次方向时，开放世界里究竟有多少个系统正在共同保证这辆车仍然属于他、仍然能够被控制，并且仍然可信。
下一篇从最容易被忽略的一步开始：玩家还没有按下任何方向键之前，系统已经必须决定一件事——这辆车是否真的属于他。
*本序章只建立玩家载具驾驶子系列的问题、主线和阅读地图；后续文章再逐篇进入源码证据、UE5 迁移取舍、原型状态和验证细节。*