人工外呼的瓶颈：不是人不够，是时间不够
海岸电台的船舶安全提醒工作有一个硬约束：船舶进港的时间是不均匀的。可能上午10点到下午3点之间大量船舶集中进港，也可能凌晨3点有船靠泊。每艘进港船舶都需要在进入管辖海域后接到电台的安全提醒电话，内容包括渔区避碰注意事项、航行安全提示，以及几项必须登记的船舶基本信息。
当这个任务的执行者是人工坐席时，矛盾就显现了：
纯体力型任务。 每通外呼电话的流程高度固定——接通后自报身份、提醒渔区避碰要点、逐项询问船舶登记信息、确认并记录。这个流程不涉及复杂判断，不需要专业知识决策，但在每天几十甚至上百通外呼的量级下，它变成了纯体力活。坐席的时间被通话本身占满，没有余力去跟踪未接通、补充登记或回溯信息差错。
语言切换消耗注意力。 进港船舶的船员可能使用中文，也可能使用英文。人工坐席需要先判断对方的语言，再切换到对应的提醒剧本和信息登记模板。中英文之间的频繁切换本身不增加知识难度，但增加了每通电话的认知负载——坐席需要在一秒之内判断语言、调取话术、进入对话节奏。连续几十通双语电话打下来，差错率自然上升。
时间窗口有限。 船舶进港的安全提醒有时效要求——必须在进入管辖海域后的有限时间内完成。如果白天的进港船舶集中爆发，即使所有坐席都在持续外呼，也可能追不上进港速度。更不用说夜间的进港船舶——海岸电台夜班人员数量更少，留给每艘船的电话时间更紧。
这不是"再多招几个坐席"能解决的问题。进港船舶数量自然波动，不可能按峰值永久配置人力。AI外呼在这个场景中的价值，不是替代人工判断，而是把"逐船拨号、自报身份、标准提醒、逐项询问、确认记录"这套固定流程自动化，让人工只处理机器人未完成或无法完成的特例。
一通AI外呼如何完成"提醒+登记"
以合力亿捷AI外呼Agent为核心的通话流程，把船舶安全提醒和信息登记从手动操作变成了一条自动链路。一通外呼的完整流程如下：
名单导入与任务生成。 船舶进港信息（船名、呼号、联系方式、进港时间等）接入系统后，由MPaaS自动生成外呼任务。任务按进港时间排序，在船舶进入管辖海域后按预设时间窗口自动触发外呼。
自动拨出与语言判断。 外呼Agent拨出电话接通后，先用简短的开场白自报身份，并根据船员的应答语言自动判断应使用中文还是英文继续通话。这一步不依赖船员主动选择语言——Agent从船员的自然应答中识别语言倾向，直接切换到对应的话术流程。
安全提醒播报。 语言确定后，Agent进入安全提醒环节。内容通常包括：当前渔区密度提醒、渔船避碰注意事项、航行安全操作建议。这些内容由悦问知识库统一管理，中英文两套话术模板独立维护，确保提醒内容的标准化和一致性。播报过程中，Agent按照自然的语音节奏完成信息传达，不像传统IVR单向播报那样机械。
船舶信息逐项采集。 安全提醒完成后，Agent进入信息登记环节。需要采集的字段一般包括船名、船舶呼号、上一港、目的港、预计靠泊时间、船员人数等。采集过程采用逐项询问的方式——问一项、确认一项、记录一项。如果船员听不清楚或需要重复，Agent可以按需重新播报当前字段的问题。如果某字段的回答格式不符合规则（如呼号格式不对），Agent会进行二次确认。
信息回传与任务完成。 所有字段采集完成后，Agent进行汇总确认——向船员播报已登记的全部信息，确认无误后结束通话。采集的船舶信息通过MPaaS Tools回传至船舶信息登记系统。
未接通与未完成的处理。 如果外呼未接通，系统标记为"待重拨"，按预设间隔再次外呼。如果接通但信息登记未完成（如船员表示不方便、信号中断、语言无法识别），任务被标记为"待人工跟进"，把已采集的部分字段和未完成的字段清单同步给人工坐席处理。
中英文切换背后的流程逻辑
海岸电台外呼场景中，中英文切换不只是"放两个版本的录音"那么简单。它涉及的是整个对话流程中的语言一致性。
合力亿捷MPaaS的Flow编排能力在这个环节中发挥了关键作用：不是把中文和英文做成两条独立的外呼流程，而是在同一个流程中包含"语言判断 → 分支"的节点。判断节点在开场白结束后触发——如果船员用中文回答，后续所有节点（安全提醒话术、信息询问话术、确认话术）都走中文模板；如果船员用英文回答，全部走英文模板。
这种设计的实际好处是：
中英文信息登记字段统一。 无论走中文分支还是英文分支，采集的字段类型和数量相同（船名、呼号、上一港、目的港等），最终进入系统的是同一个登记表。不会出现"英文电话采集了船名但漏了呼号"这种字段不一致的问题。
话术维护分离、流程编排统一。 中文和英文的话术模板由运营人员分别维护，修改英文安全提醒内容不会影响中文模板。但流程本身（语言判断→提醒→登记→确认→回传）只需编排一次。
语言识别失败有兜底。 如果船员使用中文和英文之外的语言，或者口音过重导致语言判断失败，Agent可以尝试用中英双语简短提示"请用中文或英文"，如果仍无法识别，标记为"待人工跟进"。
上线后需要验证的环节
海岸电台AI外呼系统上线后，核心不是看"打了多少通电话"，而是验证以下环节是否稳定：
接通与完成率。 第一组指标是外呼接通率和信息登记完成率。接通率受限于船只通信条件（海上信号不稳定、船员是否在岗），这是外呼场景的天然约束，不完全取决于系统。更关键的指标是"接通后信息登记完成率"——接通后有多少比例的通话完成了全部字段的采集和回传。未完成的比例中，有多少是语言问题、有多少是船员拒绝、有多少是信号中断，这些分类数据决定了下一轮优化的方向。
中英文判断准确率。 系统是否能稳定区分钟文和英文应答，是否存在中文船员被误判为英文、英文船员被误判为中文的情况。这项验证需要抽查外呼录音，用真实通话样本评估判断节点的准确性。
信息采集完整性与准确性。 船舶登记的核心字段（船名、呼号、上一港、目的港）是否有缺失，已采集的字段是否准确。这里特别要注意一个点：船员可能在通话中随口报出一个不准确的呼号格式，Agent是否能在通话中发现格式异常并进行二次确认，而不是照单全收。
未完成任务的流转效率。 被标记为"待人工跟进"的未完成任务，人工坐席收到后多久能处理？信息是否足够——已采集了哪些字段、卡在哪个字段、未完成的原因是什么——这些问题直接影响到人工兜底环节的效率。
和外呼相关的业务边界
海事通信场景有它的特殊性，方案设计中有几个边界需要提前明确：
海上通信条件决定接通率。船舶在海上可能信号不稳定，或船员在驾驶台、机舱等无法接听电话的岗位。外呼接通率低于陆地场景是正常现象，方案中应对策略是未接通自动重拨，而非承诺更高接通率。
船舶信息中的敏感字段需要提前确认登记范围。船名、呼号属于公开信息，但如果涉及船员个人信息或其他可能包含隐私的字段，登记范围需要在实施前与主管部门确认，并在流程中控制采集边界。
AI外呼的安全提醒属于"航行安全提示"范畴，不包含具有约束力的航行指令、进港许可或避碰决策。这些内容始终由主管机关通过正式通信渠道下达。
从外呼数据中能看到什么
AI外呼上线后产生的数据，不只是"拆了多少通电话"。从运营分析的角度，以下几组数据值得关注：
进港船舶的时区分布。 按进港时间统计外呼量分布，可以直观看到一天中哪些时段船舶进港最密集，从而帮助安排人工兜底坐席的值班时段。
进港船舶的国籍/语言分布。 统计中文和英文外呼的比例，可以判断中英文话术模板的维护投入是否合理，是否需要增加其他语言的模板。
未接通原因分类。 未接通是"无人接听""号码不通""接通后挂断"还是"信号中断"，不同原因对应不同的重拨策略和信息补充方式。
信息登记高频缺失字段。 如果某个字段（如"上一港"）在多次通话中频繁缺失，可能是询问话术不够清晰，或者船员习惯表达方式不同，需要优化话术。
这些数据不只是用来证明"AI外呼有用"的。它们的实际价值在于，帮助海岸电台的管理者理解进港船舶的行为模式和通信习惯，这些认知即使回到人工外呼模式下也有参考意义。
AI外呼在海岸电台场景中要解决的核心问题不是"语音机器人能不能打电话"，而是在船舶进港安全提醒这个有硬时间约束的任务里，把重复执行、高度标准化的人工动作自动化，同时把中英文切换、信息逐项采集和系统回传这些影响差错率的手动环节，纳入统一的流程编排和记录体系。对于一天需要外呼数十上百艘进港船舶的海事通信中心来说，"打没打完"不是一个效率问题，而是责任问题——而这正是AI外呼最适合接手的部分。
