客户提出：“无人船再增加一个自动避障功能，最好还能远程接管。”

如果直接把这句话翻译成产品需求，似乎并不复杂：增加障碍物识别、自动避障和远程控制模块，再画出一套功能流程，交给研发团队实施。

但真正的问题是：无人船在什么情况下需要避障？发现障碍物后应该减速、绕行还是停车？自主航行与远程控制发生冲突时，谁拥有最终控制权？通信中断后，无人船应该继续执行任务，还是进入安全状态？

这些问题如果没有在设计阶段明确，新增功能不仅可能无法解决客户的问题，还可能引入新的作业风险。

本文以一艘执行港口巡逻任务的无人船为例，从需求拆解、风险分级、控制权限到上线验证，分析如何将一句模糊的功能诉求，转化为可实施、可测试、可追溯的无人船产品方案。

一、先别急着给无人船增加功能

先看客户的实际任务。

一艘无人船需要在指定水域执行巡逻任务，按照预设航线自主航行，并利用雷达、摄像头、定位设备等感知周围环境。客户希望无人船能够识别前方船只或其他障碍物，在存在碰撞风险时自主调整航向，同时允许岸基操作人员远程接管。

表面上，客户需要的是自动避障和远程控制。实际上，这里面至少包含四个需要独立分析的问题。

第一，什么情况下触发避障？

是发现目标就立即改变航向，还是只有当目标进入一定距离、碰撞风险达到设定条件时才采取行动？不同目标的尺寸、运动方向和相对速度，是否需要采用不同的判断策略？

第二，避障之后如何继续执行任务？

无人船绕开障碍物后，是自动回到原定航线，还是重新规划路径？如果绕行后进入限制水域，或者周围环境不再满足安全航行条件，系统应该如何处理？

第三，谁拥有控制权？

无人船正在自主航行时，岸基人员发出转向指令，系统应该立即执行，还是先退出自主控制模式？如果多个操作终端同时发出指令，哪个终端拥有有效控制权限？

第四，异常情况下如何保证行为可解释？

当定位信息异常、传感器数据不一致或通信链路中断时，无人船是否继续航行？如果系统触发了避障动作，事后能否还原当时的目标信息、系统判断、控制指令和执行结果？

只有回答这些问题，需求才从“增加一个功能”变成真正的产品设计任务。

再看两种作业情况。

第一种，无人船在开阔水域执行常规巡逻，航线周围没有明显障碍物，通信正常，定位与感知数据稳定。

第二种，无人船在港口狭窄水域航行，附近存在移动船只、固定设施和其他作业目标，岸基操作人员也可能随时介入控制。

如果两种情况都采用同一套避障触发条件和控制策略，系统可能在开阔水域表现正常，却无法充分应对复杂环境中的目标交汇、空间受限和控制权切换问题。

因此，客户提出的是功能需求，产品团队需要识别的则是任务条件、风险等级和系统边界。

二、把功能需求拆成风险、权限和责任

无人船与普通软件产品不同。软件中的一次错误操作可能导致数据异常或流程中断，而无人船的控制决策还可能直接影响实际航行行为。

因此，设计自动避障和远程接管功能时，不能只考虑“能不能实现”，还要明确“在什么条件下可以执行，以及出现异常时如何处理”。

首先是风险分级。

可以根据作业水域、目标类型、航行速度、感知数据质量和通信状态，将任务划分为不同风险等级。低风险状态下，无人船按照既定任务自主航行；风险上升时，系统根据经过验证的策略调整速度或航迹；当关键感知信息失效，或系统无法确认当前动作是否安全时，则应按照预先定义的安全策略处理，而不是无限制地继续执行原任务。

具体的距离阈值、速度阈值和响应时间，应依据船型、动力性能、制动与转向能力、传感器性能、环境条件及测试结果确定，不能仅凭经验设置一个通用数值。

其次是控制权限。

自动避障、航线规划、远程遥控和任务管理，看起来都属于控制系统的一部分，但它们承担的职责并不相同。

自主航行模块负责按照任务和约束生成航行行为；感知模块负责提供目标及环境信息；远程操作人员负责在授权范围内执行人工控制；任务管理模块负责维护任务状态和执行条件。

这些模块之间必须建立清晰的控制优先级和状态切换规则。例如，远程接管生效后，自主航行模块应如何处理正在执行的指令；人工控制退出后，系统是否需要重新确认航线和周边环境，才能恢复自主航行。

控制权的交接不能只依赖界面按钮的显示状态，而应由系统状态、权限校验和执行反馈共同确认。

最后是责任追溯。

假设无人船发现前方目标并自动改变航向，几秒后岸基人员又发出转向指令，最终船只偏离预设航线。

如果系统只记录最终航迹，研发团队就很难判断问题出在目标识别、风险判断、路径规划、指令仲裁，还是操作人员的人工介入。

因此，关键事件至少应记录：

• 当时的任务状态、定位信息及可用的环境感知数据；

• 系统识别到的目标及对应的风险判断；

• 自动规划的航迹与实际执行的控制指令；

• 远程操作指令、操作权限和控制权切换过程；

• 传感器异常、通信异常、告警和系统恢复记录。

对于涉及航行安全的关键事件，还应考虑统一时间基准、数据完整性、日志保存周期和异常情况下的数据留存能力。

这些记录不是为了事后简单追责，而是为了让问题能够被复现、分析和修正。

三、从“增加避障功能”改成分级执行方案

明确问题后，需要比较不同的实现方案。

方案一：增加基础障碍物告警。

系统识别到障碍物后向操作人员发出告警，由人工判断是否调整航向。

这一方案改造相对简单，适合先建立感知和告警能力。但它不能直接解决操作人员反应时间、复杂环境判断和连续自主航行的问题，也不能将告警等同于已经具备避碰能力。

方案二：增加全自主避障。

系统根据感知信息和航行约束自主规划绕行路径，并在满足预设条件时继续执行任务。

这一方案能够减少人工干预，但对目标识别、目标运动状态估计、路径规划、控制执行和异常处理提出了更高要求。仅仅实现“检测到目标后转向”，并不意味着系统已经具备可靠的自主避障能力。

方案三：按照风险状态分级处理。

本例优先采用第三种思路。

在感知、定位、通信和系统状态满足任务要求时，无人船按照预设航线自主航行；出现可处理的障碍物风险时，系统依据经过验证的规则进行减速、绕行或重新规划；当关键数据失效、环境超出系统能力范围，或者无法确认动作安全性时，系统进入预先定义的降级或安全处置流程，并根据具体任务要求通知岸基操作人员。

需要注意，进入安全状态不应被简单定义为所有情况下立即停车。不同船型的惯性、推进方式、水流环境和作业水域不同，具体处置方式必须经过工程分析和测试验证。

远程接管则作为独立的控制机制设计。操作人员发出接管请求后，系统需要完成权限校验、控制状态切换和执行反馈确认；通信中断或接管失败时，应执行明确的异常策略，而不能默认人工指令一定已经生效。

这一方案的核心不是把更多功能叠加到无人船上，而是建立清晰的行为边界：正常状态下自主执行，风险出现时按规则处理，超出能力边界时进入可控的异常处置流程。

V1阶段还需要明确以下规则：

• 自主航行、自动避障和远程控制之间的状态关系；

• 远程操作人员的授权范围及控制权切换条件；

• 关键传感器、定位或通信异常时的处理方式；

• 航线变化、任务中断及任务恢复的判断条件；

• 关键告警、控制指令和状态切换的记录要求；

• 软件或参数更新后的回归测试要求。

第一版产品不必一次性覆盖所有水域和所有复杂目标。更合理的做法是先明确适用船型、运行环境、目标类型和测试边界，再逐步扩大验证范围。

对于产品团队而言，真正的任务不是把客户提出的功能全部写进需求清单，而是将每个功能放到具体的运行条件中，明确它的输入、判断规则、执行动作和异常边界。

四、上线前后，如何验证无人船真的具备这项能力？

无人船功能验证不能只看控制界面是否增加了按钮，也不能只在理想环境下完成一次演示。

上线前，需要建立覆盖正常场景、边界场景和异常场景的测试集。

在正常场景中，验证无人船能否按照任务航线稳定航行，能否识别测试范围内的目标，以及系统是否能够在规定条件下触发预期动作。

在边界场景中，验证目标相对运动、航道空间受限、多个目标同时出现等情况下，系统是否能够按照既定规则处理风险。具体测试工况应由产品需求、风险分析和适用的技术规范共同确定。

在异常场景中，则要验证定位信息失效、感知数据中断、通信链路丢失、远程接管失败以及控制模块异常等情况下，系统是否进入预期状态，并留下足够的诊断信息。

测试过程还需要关注自主航行与人工接管之间的交互。例如，自动避障正在执行时发出远程控制指令，系统是否能正确处理控制权；人工操作结束后，无人船是否需要重新确认航线和环境状态，才能恢复自主航行。

如果这些情况没有被测试，即使无人船能够在常规演示中完成避障，也不能据此证明其在所有实际环境中都能安全运行。

上线后，应建立与需求目标相对应的观察指标。

**第一，感知与避障表现。**观察测试目标识别表现、风险事件触发情况、避障动作执行结果，以及不必要告警的发生情况。不同目标和不同环境应分别统计，不能只用一个总体识别率代表整套避障能力。

**第二，自主任务执行表现。**观察任务完成率、航线偏离情况、任务中断次数和人工接管频率。若人工接管频繁发生，需要进一步判断是环境超出设计范围、感知能力不足，还是自主策略过于保守。

**第三，系统可靠性。**记录关键传感器异常、定位或通信中断、控制权切换失败和异常恢复情况，分析问题发生的条件与原因。

**第四，运营效率。**在相同或可比的任务条件下，观察单次任务的人工干预时间、任务执行时长和运维工作量。效率指标必须与安全约束一起评估，不能为了减少人工接管而忽视异常风险。

这些指标是建议建立的验证体系，并不代表某款无人船已经取得了特定测试结果。具体目标值需要根据产品能力、任务环境和测试基线确定。

如果上线后的数据不理想，下一步也不一定是继续增加传感器或升级算法。问题可能出在目标数据质量、风险触发条件、航线约束、控制权管理或测试覆盖不足。只有将运行记录与原始需求对应起来，才能确定真正需要改进的环节。

五、从增加一个功能，到建立一套可靠的无人船系统

回到最初的需求：“无人船增加自动避障，最好还能远程接管。”

如果只按照字面理解，项目的交付结果可能是一套新增功能；如果从任务和风险出发，最终交付的则应包括感知与决策逻辑、控制权限规则、异常处置策略、日志记录机制，以及能够证明这些能力满足要求的测试结果。

这也是无人船产品研发与普通功能开发之间的重要区别。

无人船并不是把一艘船装上控制器，再增加几个智能模块就能完成无人化。真正的无人化能力，需要硬件、感知、算法、控制、通信和任务管理相互配合，并在明确的运行边界内持续验证。

对无人船企业而言，产品竞争力也不应只体现在航速、续航和传感器数量上，还应体现在复杂任务中的稳定性、异常情况下的可控性，以及系统行为是否能够被记录、解释和持续改进。

青岛能征智能装备有限公司围绕无人船与智能控制系统开展研发，面向港口巡逻、智慧渔业、水域清洁和海洋作业等场景，推动自主航行、环境感知、路径规划与远程控制能力的协同应用。

从一项具体功能出发，逐步建立可验证的系统能力，才能让无人船从“能够执行任务”，进一步走向“能够在明确边界内稳定执行任务”。

产品经理的价值，在于将客户的功能诉求转化为清晰的业务目标、可执行的系统规则和可验证的工程指标。对于无人船而言，这不仅决定了功能能否落地，也决定了产品能否真正进入复杂的实际作业场景。