迪威国际App全球航运与船舶数据AI助手

迪威国际App里，一条船期提醒最先跳出来的往往就是一句话：预计到港时间较原计划推迟两天。这句话本身没有说错什么，但它只完成了信息传递的一半——用户知道"结果"，却不知道"起点"。如果一个产品在这里就停下，用户接下来要做的事情，通常是打开另一个页面查历史挂靠记录，或者直接联系船公司问一句"到底哪一站出的问题"，这恰恰是一个船期类产品本该替用户省下的动作。

"晚两天"是结果，不是原因

同样是"到港时间推迟两天"，背后可能对应完全不同的情况：可能是船舶在上一港因为泊位紧张多等了将近两天才靠泊；可能是船舶提前到港但因为港口作业效率下降，装卸时间被拉长，导致离港延误；也可能是更早的一港就已经出现延误，只是这个变化沿着航线上的每一站不断累积，到了用户所在的这一港才被明显感知到。这三种情况对用户的意义完全不同，如果App只显示"晚两天"这一个数字，这三种情况在界面上是没有区别的，用户没有办法据此做出不同的判断。

把延误的起点标出来，用户能多做出什么判断

如果迪威国际App在"预计到港时间推迟两天"这行字下面，继续标出"变化最早出现在某港离港环节"，用户至少可以多做三件事：第一，核对自己的货物是在这一港之前还是之后装船，从而判断自己是否真的会受影响；第二，回看这一港口近期是否反复出现类似的延误提示，用来判断这是不是一次性事件；第三，结合航线整体的历史准班表现，估计后续挂靠港是否也会出现连锁的时间下修。这三件事都不需要用户跳出App去查资料、打电话问客服。

举一个示意性的例子：如果提醒显示"变化最早出现在某枢纽港，该港离港时间较原计划推迟约36小时"，一位货物尚未在该港装船的用户，可以初步判断自己受到直接影响的概率较低；而一位货物恰好在该港转运的用户，则可以提前预留缓冲时间，通知下游收货方，而不是等到货物真正抵达自己所在港口时才发现整个计划已经被打乱。

与航线可靠性数据打通，而不是孤立展示一个数字

这也是为什么"船期"和"航线"在迪威国际App里被设计成互相引用的两个板块，而不是各自独立的两张表。单独一条船期变化提示，价值有限；但如果用户点进去之后，能看到这条航线过去一段时间的准班率区间、到港时间的常见波动范围，一条"晚两天"的提醒就有了参照系。

如果延误起点本身需要修正，界面应该怎么处理

标注延误起点还带来一个容易被忽略的问题：这个起点判断本身也可能是阶段性的，随着后续数据回传而调整。比如最初的提示写着"变化最早出现在A港离港环节"，但过了一段时间，更完整的数据显示，真正的延误其实是从更早的B港就已经开始累积，只是当时的信息还不完整。如果App在这种情况下悄悄把起点从A港换成B港，用户之前基于A港做出的判断——比如已经通知下游收货方"预计延误约两天"——就可能变成一个过时的结论，而用户自己并不知道判断的依据已经变了。比较负责任的做法，是在起点判断发生修正时明确提示"延误起点已更新"，而不是直接覆盖旧信息，让用户清楚知道自己看到的是第几次修正后的结论。

这也解释了为什么船期提醒不能只是"发一次就结束"的静态通知，而需要和港口板块的运营状态保持联动：某一港口如果本身正处于拥堵或作业效率下降的阶段，这一港后续挂靠的其他船舶大概率也会出现类似的延误起点，用户如果习惯性地在App里同时关注这个港口的状态，看到新一轮"变化最早出现在该港"的提示时，也就不会感到意外，甚至可以提前预判。目前这一整套关联展示是迪威国际App的产品设计方向，界面与数据均为规划示意，具体呈现方式以正式版本上线后为准，App本身不提供运输时效承诺。

在迪威国际App里查一个集装箱的动态，最常见的一条事件记录是"已装船"。这三个字告诉用户的信息其实很有限：箱子被装上了某一艘船，仅此而已。它没有说是哪一艘船、这是第几个航次、船接下来要开往哪一港。如果App到这里就结束了这条记录的展示，用户手里的信息量，和收到一条"你的包裹已发出"的短信没有本质区别——知道"动了"，但判断不了"接下来会怎样"。

集装箱事件和船舶事件，是两条不同的信息线

集装箱追踪系统记录的是箱子本身的事件节点：进场、装船、离港、转运、卸船、出场，这条线关心的是"箱子在哪个环节"。而船舶动态系统记录的是船舶本身的状态：船名、航次号、当前位置、预计到港时间，这条线关心的是"承运这个箱子的船，现在处于什么状态"。这两条线在物理世界里当然是绑在一起的，但在很多传统的箱况查询页面里，这两条线在界面上是分开的，用户看到"已装船"之后，还要自己再去船期页面重新查一遍。

举一个示意性的场景：同一个提单号在两周之内先后出现两条"已装船"记录。如果两条记录都只写着"已装船"，用户很容易误以为是系统重复推送了同一条通知；但如果这两条记录分别标注了不同的船名、不同的航次号、不同的下一港，用户立刻能看出，这其实是货物在中途枢纽港完成了换船转运，继续驶向最终目的港。

为什么这三项要跟在"已装船"后面，而不是放在另一个页面

把Vessel（船名）、Voyage（航次号）和下一港这三项直接接在"已装船"这条事件后面显示，本质上是把两条本该关联的信息线在用户看得到的第一屏就拼在一起。具体来说，这三项分别解决三个问题：船名让用户可以确认承运船舶的身份；航次号让用户可以准确核对这一次装运对应的是哪一个航次；下一港则直接告诉用户，这个箱子接下来的下一个动态节点大概率会在哪里出现。

一个更完整的记录长什么样

比较起来，一条只写"已装船"的记录和一条写着"已装船 · 船名XX轮 · 航次2609E · 下一港：XX港"的记录，信息密度是不一样的。这种把集装箱事件和船舶身份信息合并呈现的方式，也是"集装箱"板块和"全球船舶"板块在迪威国际App里被设计为互相引用的原因——集装箱页面里出现的船名和航次号，理论上应该可以直接点进去，跳转到对应船舶在"全球船舶"板块里的当前动态。

如果船名或航次号本身发生变化，记录要怎么显示

实际运输过程中，"已装船"后面绑定的船名和航次号并不是永远固定不变的。比如箱子原计划由甲船承运，但因为舱位调配或班期调整，实际改由乙船装运，也就是常说的"换船"；又或者同一艘船的这一航次编号本身发生了更正。如果App在这种情况下只是悄悄把船名和航次号换成新的，而不留任何痕迹，用户很可能会以为自己记错了，或者怀疑是系统出错，反而降低对整条记录的信任。比较合理的处理方式，是在事件记录上明确标注"船舶信息已更新"，并保留修正前的版本可供查看，让用户清楚知道这是承运安排发生了变化，而不是页面本身出了问题。

这一点同样适用于下一港信息：如果船舶的挂靠计划临时调整，原本标注的下一港也需要相应更新，这时候如果App能借助迪威国际助手用一句话解释"下一港已从A港调整为B港，原因与该航次挂靠计划变更有关"，用户看到变化时就有据可依，而不是只看到一个陌生的港口名称却不知道为什么变了。需要说明的是，以上事件字段与联动方式是迪威国际App当前的产品设计方向，实际集装箱动态以真实提单信息为准，App本身不提供订舱服务、在线支付或运输时效承诺。

"海运运价下降"这五个字，如果不说清楚说的是哪种运价，几乎可以套用在任何时候——因为即期市场和长期合同市场几乎从不同步变化，甚至经常朝相反方向移动。迪威国际App如果在运价板块只推送一句"某航线运价下降"，却不注明这到底是即期运价（Spot Rate）还是长期合同价格区间，用户很容易把一次短期的即期市场波动，误读成整体运价趋势的转向。

即期市场和合同市场，回答的是不同的问题

即期运价反映的是当下、单次订舱在公开市场上大致可以拿到的价格水平，波动频繁，往往一两周内就能看到明显起落。长期合同价格则是承运人与货主基于一段时间事先约定的价格区间，变化频率低得多。同样一条航线，即期市场可能因为短期舱位过剩而快速下滑，但长期合同价格往往要等到下一轮谈判周期才会调整，两者在同一个时间点上完全可能呈现出相反的方向。

一条负责任的运价提醒应该包含什么

比较完整的呈现方式，至少应该标明四件事：市场类型（即期还是合同）、具体航线、统计口径对应的日期或周期，以及变化幅度所对应的参照基准是环比上一期还是同比去年同期。

一个容易被混淆的示意场景

假设某条航线的即期运价在一周内下降了约一成，而同期这条航线的长期合同价格并没有变化。如果App只推送一句"该航线运价下降一成"，一个刚刚签订新一季合同的货主，很可能立刻怀疑自己是不是错过了更优惠的价格；而一个正在比较即期报价、准备现货订舱的用户，如果没有意识到这条提醒说的只是即期市场的一周波动，也可能因此做出偏离实际情况的判断。反过来，如果同一条提醒明确写着"即期运价（周度）较上周下降约一成，长期合同价格未发生变化"，两类用户各自真正需要的信息都被准确传达。

为什么这件事必须在界面设计层面解决，而不是指望用户自己分辨

把市场类型标注清楚，不是一个"锦上添花"的细节，而是运价类信息能不能被正确使用的前提。这也是为什么迪威国际App计划把市场类型、航线区间和统计周期作为运价提醒里不可省略的固定字段。

即期与合同两个市场同时发出信号时，提醒该怎么呈现

更复杂的情况是，即期运价和长期合同价格有时会在同一时间窗口内同时发生变化，而且方向未必一致。比如某条航线的即期运价短期内明显下降，与此同时新一轮合同谈判也刚好落地，长期合同价格出现小幅上调。如果App把这两条变化拆成两条独立提醒分别推送，用户很容易只看到其中一条就形成整体判断；但如果把两者合并在同一条提醒里呈现，并且分别标注各自的市场类型、变化方向和统计口径，用户才有机会看到运价市场当下实际存在的这种结构性分歧，而不是被单一数字带偏。

这类运价信号也不是孤立存在的，理想情况下应该能和"全球贸易流"板块里的货量与运力信号相互印证：如果即期运价短期下降，同时对应航线的运力部署又在同步收紧，这条运价变化背后大概率对应的是短期舱位供需的季节性波动，而不是需求端出现根本性转弱。用户如果对这类背景判断没有把握，也可以直接在迪威国际助手里追问"这一轮即期运价下降和合同价格有什么关系"，得到一个附带数据依据的结构化解释，而不是只看到一句孤立的"运价下降"。需要特别说明的是，App内展示的运价及其走势为航运科技教育示意内容，用于帮助用户理解运价市场的结构性差异，不构成实际订舱报价，也不构成任何形式的投资建议。

在迪威国际助手里输入"全球贸易是不是在增长"这样一个问题，最偷懒的回答方式，是去数一下当前在航的船舶数量，如果比上个月多，就回答"在增长"。这个逻辑听起来直观，但经不起推敲——船舶数量的变化，受运力交付周期、船东调度策略、季节性调仓等因素影响，跟"贸易本身有没有在增长"之间，并不是一一对应的关系。

为什么"在航船舶数量"是一个不可靠的代理指标

船舶数量本身混合了太多与贸易增长无关的因素。比如，一段时间内新船集中交付，会让在航船舶数量上升，但这只是运力供给端的变化，不代表货量在增长；反过来，船东出于成本考虑选择闲置部分运力，也会让某个时间点的在航船舶数量下降，但实际货量未必同步减少。此外，一艘一万标箱的船和一艘两千标箱的船，在"数船"的逻辑里权重是一样的，但它们代表的运力和潜在货量差异巨大。

一个更靠谱的回答会参考什么

更审慎的回答，至少需要交叉参考几类信号：一是运力部署数据，包括船舶总运力在各主要航线上的分布变化；二是港口层面的实际吞吐量数据，这是相对更接近"货量"本身的指标；三是行业机构和海关口径下的官方贸易统计，这类数据权威但通常有一定的发布滞后；四是基于前几类高频数据做出的"即时预估"（nowcast），用来在官方统计发布之前给出一个方向性的、但明确标注了不确定性的判断。这四类信号各有局限，不能被当成最终答案。

举一个示意性的例子：如果某个月运力部署数据显示主要航线运力环比上升，但同期几个核心港口的实际吞吐量数据只是持平、甚至略有下降，一个只看运力数据的回答会得出"贸易在扩张"这样干脆的结论；而结合了吞吐量数据之后，更谨慎的说法应该是"运力供给端出现扩张，但目前尚未看到货量同步扩张的信号，需要等待下一期官方贸易统计或港口吞吐量数据进一步确认"。

当几类信号互相矛盾的时候，答案应该怎么给

比数据本身更难处理的，是这几类信号经常互相矛盾。运力部署数据显示某几条主干航线在扩张，港口吞吐量数据却在同一时间段内基本持平，而官方贸易统计因为发布滞后，还停留在更早一期、看不出明显趋势。如果迪威国际助手在这种情况下依然只给出一个"增长"或"放缓"的单一结论，等于是替用户抹掉了信号之间真实存在的分歧，而这种分歧本身往往才是最值得用户注意的信息——它可能意味着市场正处在转折点附近，不同指标的反应速度不一样，而不是简单的"数据出错"。比较负责任的做法，是把几类信号各自的方向和更新时间都摆出来，明确指出哪些指向增长、哪些指向持平或放缓、哪些还没有更新，让用户自己判断该更看重哪一类信号，而不是把这个判断过程隐藏在一句结论背后。

这也是为什么"全球贸易流"板块和"全球港口"板块在迪威国际App里需要保持数据联动：港口层面的实际吞吐量变化，往往比单纯的运力部署数据更接近货量本身的真实情况，如果用户在追问全球贸易趋势时，能顺带看到几个核心港口最近的吞吐量走势，就多了一层交叉验证的依据，而不是只能被动接受迪威国际助手给出的文字判断。

迪威国际助手在这类问题上的设计原则

正因为没有哪一个单一指标能够独立、及时、准确地回答"全球贸易是不是在增长"这样的问题，迪威国际助手在处理这类问题时，被设计为优先说明它引用了哪几类数据、这些数据各自的时效性和局限是什么，而不是直接给出一个斩钉截铁的"是"或"否"。以上内容为迪威国际助手的产品设计方向说明，具体问答能力以正式版本上线后的实际表现为准。