迪威国际港口与全球Port Operations AI

港口吞吐量大并不说明每一艘船都能靠得快——这句话听起来像是常识，但在很多货主和货代的认知里，两千万TEU的年吞吐量本身就等同于"这是个高效的港口"。事实上，吞吐量衡量的是一个时间段内港口处理的货物总量，是一个存量意义上的规模指标；而对某一艘具体的船、某一票具体的货物来说，真正决定"快不快"的，是它从抵达锚地到完成装卸、重新离港所花费的时间。规模大的港口完全可能同时存在"整体吞吐量领先"和"单船在港时间偏长"两种状态，这两者并不矛盾，只是回答的问题不一样。

到达港口附近和具备开始作业条件，是航运数据里完全不同的两个状态。船舶到达港口附近的锚地，只表示它进入了这个港口的管辖水域和调度队列，并不代表泊位、装卸设备、引航资源已经为它准备就绪。当一个港口同时有几十艘船排队等候有限数量的泊位时，即便这个港口全年货量巨大、处理能力名列前茅，某一艘船仍然可能需要在锚地停留数小时甚至更久。

举一个简化的例子说明这种反差可能怎样出现——这里的数字仅用于说明两种指标可能出现的反差，不对应任何真实港口。假设枢纽港甲一年吞吐量达到两千五百万TEU，年内大部分时段泊位使用率都接近饱和，大船、超大船占比高，装卸窗口经常需要错峰排队，船舶在港时间的中位数被拉长到三天左右；支线港口乙一年吞吐量只有两百万TEU，但船型集中、装卸流程相对简单，船舶在港时间中位数稳定在一天以内。如果只看吞吐量排名，甲远远领先乙；但如果货主关心的是自己这一票货、这一艘船大概要在港口耽误多久，乙反而是更可预期的选择。

吞吐量之外，还有一把尺子——CPPI

世界银行与标普全球市场财智（S&P Global Market Intelligence）联合发布的集装箱港口绩效指数（Container Port Performance Index，CPPI），到2025版数据发布、相关分析在2026年陆续被引用时，已经是第六版，覆盖全球400多个港口。这份指数刻意没有把吞吐量作为核心排名依据，而是聚焦在"船舶在港时间"（vessel time in port）——也就是一艘船从抵达到离开所耗费的总时长，其中既包括在锚地等待的时间，也包括靠泊后装卸作业本身占用的时间。CPPI的编制方选择这个指标，用意很直接：吞吐量回答的是"这个港口一年能处理多少货"，而船舶在港时间回答的是"一艘具体的船在这个港口平均要耽误多久"，后者更贴近船公司和货主实际关心的问题。

这也是为什么一个吞吐量常年位居前列的枢纽港，可能因为船舶结构复杂、大船多、中转比例高，船舶在港时间被拉长；而一个吞吐量规模小得多的支线港口，因为船型单一、作业流程相对简单，船舶在港时间反而更短更稳定。CPPI报告本身也强调，这份指数是用来做诊断和比较的工具，不是简单地宣布"某港口天下第一"——不同港口的货种结构、航线布局、腹地条件都不一样，直接把排名当作唯一优劣标准，容易忽略掉这些实际差异。

对经常往返同一条航线的货主和货代来说，比单纯记住某个港口在CPPI榜单上的名次更有用的做法，是结合自己以往在这个港口的实际靠泊经历去判断——同一个港口对不同船型、不同货类、不同季节的表现可能并不一致，旺季集中到港时，即便是船舶在港时间常年表现不错的港口，也可能出现排队时间明显拉长的情况。吞吐量和CPPI这类公开指数提供的是一个总体参考框架，用来判断港口整体处于什么水平，而不是对某一次具体到港所需时间的精确预测，两者需要结合起来看，单独依赖任何一个都容易得出偏差较大的判断。

迪威国际在梳理港口相关的公开数据时，也倾向于把"规模类指标"和"时效类指标"分开讨论，而不是用一个笼统的"效率高低"去覆盖两件事。对经常需要评估港口选择、安排到港计划的货主和货代来说，理解吞吐量和船舶在港时间之间的区别，比记住某一个排名数字更有实际价值。

假设一艘船原计划再航行48小时抵达某港口锚地，而它此时的航速足以按原计划准点到达。按照传统的操作习惯，船长往往会选择维持较高航速甚至提前赶到——早到总比晚到更保险。但如果港口这边的调度系统已经知道，这艘船要用的那个泊位要在船舶原计划抵达时间之后的第六个小时才能空出来，全速赶到港口带来的唯一结果，就是提前在锚地开始等待，燃油照烧、船照样闲置，只是把等待的地点从海上换成了锚地。

Just-in-Time Arrival解决的是"匹配"问题，不是"减速"问题

很多人第一次听到Just-in-Time Arrival（准时到港，简称JIT Arrival）时，容易把它理解成"让船开慢一点"，但这个理解并不准确。JIT Arrival真正调整的是"到达时间"与"泊位可用时间"之间的匹配关系：如果能提前获知泊位、装卸资源或引航安排的可用窗口，船舶就可以据此调整航速，让抵达时间落在这个窗口附近，而不是始终按照较高航速航行、再在锚地被动等待。核心是"按需匹配"，而不是单方面、统一地要求所有船在所有航段都开得更慢。

泊位预计可用时间这个数字本身，通常不是单一系统凭空给出的结果，而是把码头的泊位作业计划、装卸设备和人力排班、以及前一艘船实际作业进度这几类信息拼合之后得到的动态估计。前一艘船如果因为货量、天气或设备故障导致作业延后，后一个泊位空出的时间点也会跟着顺延，这也是为什么泊位可用时间预测通常需要滚动更新，而不是船舶离开上一港口时拿到的一个固定数字就能一直沿用到抵达当天。

下面用一个示意场景说明两种做法的差别——这里的数字仅用于说明原理，不代表任何真实船舶、真实港口或真实航次的实际数据。假设某船从上一港口出发，原计划匀速航行48小时抵达目的港锚地，而目的港泊位预计要到抵达时间之后的第6小时才能空出。

方案一是维持原定航速的全速航行：船舶按计划48小时后抵达锚地，随后在锚地等待6小时，再进港靠泊，锚地等待期间同样需要消耗燃油维持船舶各项系统的正常运转。方案二是速度优化到港：船舶根据提前获知的泊位可用时间信息，把航速降低到能在大约54小时后、也就是泊位实际空出的时间点抵达锚地附近，基本省去了锚地等待环节，总燃油消耗和相应排放通常低于方案一，而且抵达"可以开始作业"的时间点并没有变晚。

1. 方案一・全速航行48小时抵达锚地，随后开始等待锚地等待约6小时，等待期间发动机仍需运转维持船舶状态（示意数据，非真实航次）
2. 方案二・速度优化到港约54小时抵达锚地，几乎无需等待全程以更低负荷航行，抵达可作业时间点相近，但省去锚地空转（示意数据，非真实航次）

这种做法带来的好处，不只是船公司省下的燃油成本。锚地是一个物理空间，同一时间能容纳的船舶数量有限，如果每艘船都习惯性全速到达、再排队等待，锚地本身也会变得拥挤，甚至压缩其他船舶的安全操作空间。这正是JIT Arrival这些年被反复提及的原因——它要求港口和船舶之间共享更准确的时间信息：泊位什么时候空、装卸设备什么时候能用、引航员什么时候能派出，这些信息越早、越准确地传递给船舶，船舶就越有条件把航速安排得更合理。

需要指出的是，JIT Arrival能不能真正发挥作用，很大程度上取决于港口一侧能不能提供足够可靠的泊位预计可用时间——如果这个预测本身经常变化或者不够准确，船舶按照它调整航速反而可能面临新的不确定性。这也是为什么行业里更多把JIT Arrival看作是船港双方共同协作才能落地的操作理念，而不是船公司单方面调整航速就能解决的技术动作。

从商业合同的角度看，JIT Arrival要普遍落地还有另一层需要协调的障碍。不少租船合同仍然沿用传统的条款设计：船舶只要在约定时间到达装卸港并递交解到通知书（Notice of Readiness），无论港口当时是否具备立即作业的条件，都可以据此起算装卸时间甚至产生滞期费。在这样的合同框架下，全速赶到、尽早递交解到通知书反而更符合船东的直接利益，即便这意味着接下来要在锚地等待。JIT Arrival要从个别船公司的自愿实践变成行业普遍做法，往往还需要租船合同条款本身作出相应调整，而不只是船舶操作层面愿不愿意减速的问题。

一艘船靠泊前，需要向港口所在国的相关部门提交船舶信息、货物清单、船员名单、卫生申报、保安信息等多项材料。在Maritime Single Window（海事单一窗口，简称MSW）成为强制要求之前，这些材料往往需要分别提交给海关、边检、卫生检疫、港口当局等不同部门，格式、渠道、提交时间要求都不完全一样，同一份数据可能要在不同系统里重复填写好几次。

MSW已经是强制要求两年多，但不是"一个全球统一的网站"

根据IMO《便利国际海上运输公约》（FAL公约）的规定，Maritime Single Window从2024年1月1日起已经是IMO成员国的强制性要求——这项规则已经生效两年多，并不是2026年才出现的新变化。它要求的是，船舶、货物、船员、卫生、保安等相关信息通过统一的数字化平台一次性提交给港口所在国，而不是分头报送给多个部门、多套系统。但需要说清楚的是，这里的"单一窗口"是按国家、按港口分别建设和实施的机制：各国、各港口有各自的MSW系统，而不是全球只有一个统一的网站或平台。不同国家、不同港口的实施进度和成熟度也存在明显差异。

这个问题在跨多个国家挂靠的航次里会被进一步放大。一艘船如果这一趟航程要挂靠三个不同国家的港口，理论上每个国家的Maritime Single Window都已经是强制要求，船公司也确实按规定分别向三个平台提交了信息，但这三个平台之间彼此并不互通，也没有共享同一套字段定义。结果是，船公司实际上要把大致相同的一批数据——船舶信息、货物清单、船员名单——按三套不同的格式、三套不同的字段口径分别整理三次、分别提交。单一窗口在这里解决的只是"某一个港口内部不用重复报送给多个部门"，并没有解决"同一艘船跨港口、跨国家不用重复整理数据"这个更大的问题。

但系统对接完成之后，数据能不能被正确理解，是另一个问题。举例来说，"到港时间"这个字段，不同系统之间的定义可能并不一致——有的系统记录的是船舶抵达锚地的时间，有的记录的是船舶靠泊完成、开始作业的时间，还有的记录的是引航员登轮的时间。这三个时间点在物理上可能相差数小时，但如果两个系统都只标注"到港时间"这一个字段名称，数据交换的时候很容易被默认当成同一件事直接对接，结果产生偏差。

举一个简化的例子说明这种偏差可能造成的实际影响——这里的场景仅用于说明问题，具体的时间差和流程安排在真实操作中会因港口、航线而不同。假设港口系统按照"引航员登轮时间"记录到港时间，而船公司内部系统按照"抵达锚地时间"记录到港时间，两者之间相差三四个小时；一旦某项后续流程——比如某类查验安排或者装卸计划——是按照到港时间往后推算，双方基于不同定义算出来的时间点就会对不上，需要人工介入核对才能确定到底该以哪一个时间作为基准，这类核对工作看似琐碎，累积到一个繁忙港口的日常运营里，仍然会消耗不少协调成本。

这背后其实是两类不同性质的问题。系统能不能连通、数据包能不能被对方平台接收，属于技术对接层面的问题，随着各国MSW陆续建成，这一层已经基本解决。但同一个字段名称背后，双方系统对它的定义是否完全一致，属于语义层面的问题，需要的不是把接口打通，而是双方先就"这个字段到底指什么"达成一致，这个协调过程往往比技术对接本身更慢，也更容易被忽略——毕竟系统对接完成之后，表面上数据已经能够流转，字段定义是否真正一致这个问题不会立刻暴露出来。

这也是为什么"已经建成单一窗口"和"数据真正可以互通"之间，还有一段距离要走。行业里目前也在推进和MSW配套的治理工作——例如IMO便利化委员会（FAL）第50次会议已经批准了与海事单一窗口相关的网络安全方面修正案，计划在2027年前后正式通过、2029年前后生效。这类安排本身也说明，MSW相关的治理和技术细节仍在持续完善，并不是2024年强制生效之后就一次性定型、不再变化了。

对货主和船公司来说，理解这一点有实际意义——不能简单假设"港口已经上线单一窗口"就等于"我的系统数据可以直接对接、无需校验"。在字段定义、更新频率、数据颗粒度真正统一之前，跨系统的数据核对和转换工作，仍然是航运数字化里绕不开的一环。