竞价船舶发布系统：垂直行业交易平台的核心功能设计

摘要要点

• 船舶是非标大额资产，一套船源字段无法同时适配散货船、油船、拖轮和工程船，字段体系必须按船型分组配置，否则筛选功能会变得难以维护。
• 竞价发布与普通挂牌并不是两套系统，它们是同一套船源主数据上的两种发布形态；分两套做，后期的数据一致性代价会明显增加。
• PC、H5、小程序三端共用同一套数据模型，前端只负责呈现差异；船东和经纪人的高频操作场景多半发生在移动端。
• 决定平台能否持续迭代的关键，很少在开发阶段，更多在于后台是否把船型、字段、竞价规则的配置权交还给了运营方。

船舶交易平台不能照搬通用 B2B 商城

通用电商的商品模型是“类目 + 属性 + SKU + 价格”，一条商品对应一个明确报价，买家下单即完成。船舶交易的形态不同：同一条船在交易过程中，可能先挂牌询价，再转入竞价，最后进入线下验船与交割；买卖双方多为企业，决策周期以周甚至月计；中间还夹着经纪人、船东代表、平台运营等多重角色。

把这种交易流程放进标准商城模板里，会立刻遇到两个问题。一是商品详情页装不下船舶的参数密度：一条船的船型、载重吨、主尺度、建造年份、船级社、船旗、主机型号、航区、舱容、吊机配置等信息，任何一项缺失都可能让买方直接跳过。二是“价格”字段无法承载竞价逻辑：起拍价、加价幅度、截止时间、延时规则、保证金，都不是一个 price 字段能表达的。

所以垂直交易平台的功能设计，真正要回答的是数据模型怎么建、发布形态怎么分层、配置权交给谁这三个问题。

船型字段体系：先解决“能不能筛出来”

中国国际船舶交易网这类平台会覆盖七十多种船型。船型一旦多到这个量级，用一套统一的筛选面板必然难以使用：散货船关心的载重吨和舱容，对拖轮没有意义；工程船关注吊机和作业能力，对油船也不是重点；渔船和小型客船的字段维度又完全是另一套。

可行的做法是把字段拆成三层：

• 通用层：所有船舶都有，例如船名、船型、建造年份、船旗、船级社、当前航区、交易状态。
• 船型层：由船型决定必填与选填字段组，例如油船增加货舱涂层与泵系配置，拖轮增加系柱拖力与主机功率。
• 交易层：与船本身无关、只跟这笔交易有关的字段，例如报价方式、可看船时间、验船地点、交割条件。

前端渲染时只展示该船型所属的字段组，用户看到的筛选器数量就控制在可操作范围内。这套逻辑听起来只是后台配置，实际却直接影响平台的可扩展性：新增一个船型时，运营方能不能自己配出字段组，决定了平台是“每加一个船型就要改一次代码”，还是“配置一下就能上线”。

竞价发布与挂牌展示共用一套船源主数据

竞价页面容易被当成一个独立功能模块来做，结果是挂牌船源和竞价船源各有一套表、各有一套审核流，运营要维护两处信息，数据同步问题会持续出现。

更稳妥的分层是：船源主数据只有一份，发布形态作为挂在其上的一层视图。同一条船可以先以挂牌形式展示联系方式与概况，也可以切到竞价视图，展示起拍价、加价幅度、保证金要求、竞价开始与截止时间、延时出价规则。切换形态时，船舶本身的参数不动，交易的规则参数单独存。

这带来的好处在竞价结束后才显现：平台留下的是一份可追溯的过程记录——谁在什么时间出过价、出价被谁超越、竞价是否触发延时、最终成交价与保留价的关系。这些记录对平台方判断船源质量、对买方判断市场行情都有价值，而如果竞价做成孤立模块，这些数据往往散落在不同系统里，无法回溯。

竞价规则本身有合规边界，涉及拍卖经营、保证金监管等事项，需要由平台方法务与业务方确认后再落到产品上。这里只讨论系统如何承载规则，不涉及具体合规判断。

三端同源：PC、H5 与小程序的分工

船舶交易的移动属性很强。船东在码头、在船上、在航次间隙处理船源信息，用手机拍照上传、用微信转发船源链接给潜在买方的场景很常见。这也是为什么中国国际船舶交易网在改版中把 PC 端、H5 和小程序三端一起纳入。

三端共用一套数据模型和一套审核流，差异只在交互层面：

• PC 端承担复杂筛选、多条件组合查询、批量对比，适合买方做初步筛选。
• H5 承担外部分享，微信里点开即可看船源详情与竞价状态，不需要安装。
• 小程序承担身份与通知，登录态、出价提醒、竞价进度推送放在这里更顺。

转发链路里有个细节常被忽略：经纪人把船源转给客户时，需要让自己的联系方式跟着链接走，而不是把客户导回平台公域。这属于发布系统的“留痕”能力，不是营销功能，在系统设计阶段就要留出字段。

后台配置权，比前台功能更影响长期成本

中国国际船舶交易网的改版经历了多个版本迭代，过程中客户方深度参与了修改意见。这种参与在垂直行业平台里是常态：真正懂船型字段该怎么分、竞价规则该怎么设的，是业务方而不是开发方。

因此后台要交出去的不只是内容录入，还包括：

• 船型与字段组的增删改，包括必填项与校验规则；
• 竞价规则的模板化配置，例如加价幅度档位、延时触发条件、保证金比例；
• 审核流程节点，例如哪些字段变更需要复核、哪些可以直接生效；
• 页面模块的排序与显隐，让运营方在推广节点自行调整重点船型的展示位。

特蓝在承接该项目的多版本改版与后续平台功能增加时，处理的就是这类需求：把一次性交付的功能，逐步转成客户可自行维护的配置项。项目在 2019 年进一步扩展到 IT 整体外包，服务形态从项目制转向长期托管，这也解释了为什么平台功能可以在几年间持续增补，而不是每次调整都重新立项。

常见疑问

竞价发布和普通挂牌，需要做两套系统吗？

不需要。共用一份船源主数据，把发布形态做成可切换的一层，既避免信息不一致，也让同一条船在市场变化时可以从挂牌平滑转成竞价。

七十多种船型，筛选器会不会越做越复杂？

关键在于按船型配置字段组，只渲染相关字段，而不是把所有船型的字段堆在一个面板里。字段总量可以很大，用户单次看到的筛选条件应当保持在有限范围内。

竞价规则频繁调整，每次都找开发改吗？

规则模板化之后，加价幅度、延时条件、保证金比例这类参数应当由运营在后台调整。开发资源留给数据模型和流程变更，这才是可持续的分工。

如果要重做一版，先动哪一块？

先梳理船型字段体系和发布形态分层，再谈前端界面。字段没理清就做页面，改版通常会在第二轮推倒重来；数据模型立住了，PC、H5、小程序三端只是呈现层的不同组合。