惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Martin Fowler
Martin Fowler
Jina AI
Jina AI
J
Java Code Geeks
Microsoft Security Blog
Microsoft Security Blog
Recent Announcements
Recent Announcements
I
InfoQ
L
LangChain Blog
The Cloudflare Blog
IT之家
IT之家
博客园 - 叶小钗
Apple Machine Learning Research
Apple Machine Learning Research
B
Blog
A
About on SuperTechFans
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Last Week in AI
Last Week in AI
Blog — PlanetScale
Blog — PlanetScale
罗磊的独立博客
云风的 BLOG
云风的 BLOG
Microsoft Azure Blog
Microsoft Azure Blog
Engineering at Meta
Engineering at Meta
F
Fortinet All Blogs
博客园 - 聂微东
美团技术团队
博客园_首页

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
3D集装箱装箱算法可视化:从产品设计到技术实现的复盘
天涯轩 · 2025-12-22 · via 人人都是产品经理

在物流供应链领域,"装箱率"是直接影响成本的核心指标。传统的装箱依赖经验丰富的老工人,但经验难以传承且不够稳定。本文复盘了一个基于 Web 3D 技术的智能装箱系统的设计与实现过程,分享如何通过可视化和算法解决这一B端痛点。

一、 为什么要做装箱可视化?

在物流结算中心或仓储管理系统(WMS)中,我们经常面临这样的场景:

  1. 空间浪费:由于货物尺寸不一,装箱时容易出现大缝隙,导致集装箱空间利用率低。
  2. 成本不可控:因为预估不准,可能多订了集装箱,或者订了不合适的柜型(如普柜无法装下超高货物)。
  3. 沟通成本高:现场装箱人员看不懂二维的装箱单,经常装错了才发现装不下,需要重新倒柜。

针对这些痛点,我们设计了一款 “智能装箱优化与可视化系统”。核心目标是:算得准、看得清、省得下

二、 真实业务场景:从“凭感觉”到“靠数据”

为了更好地理解系统的价值,让我们看两个真实的业务痛点:

场景 A:外贸家具出口的“爆仓”危机

某外贸家具企业每批次出口的货物规格极为复杂,一批订单可能包含床架(长条形)、床头柜(正方体)、床垫(扁平且不可折叠)等20多种规格的纸箱。

  • 过去:订舱员拿着计算器加加减减,预估需要2个 40HQ(高柜)。结果装车当天,最后剩下3个立方的货物死活塞不进去。只能临时加订一个 20GP(小柜),不仅运费多出几千美元,还因为临时订舱导致船期延误。
  • 现在:通过系统模拟,算法自动尝试了上万种组合,发现只要将其中几件床架“竖着放”并填补在床头柜上方的空隙,就能完美塞进2个 40HQ。一次计算,直接省下一个集装箱的运费。

场景 B:大型设备海运的“特种柜”难题

一家工程机械公司需要运输一批超大型设备部件。

  • 过去:业务员如果不熟悉柜型,可能直接订了普通集装箱,结果货物高度超标,卡在柜门口进不去,造成严重的退关损失。
  • 现在:系统在导入货物数据时,算法(GreedyAlgorithm)会自动识别出“超高货物”,并自动匹配开顶柜(Open Top Container)或框架箱(Flat Rack)。3D 视图中清晰地展示了货物超出集装箱顶部的部分,帮助业务员直观判断是否符合航运公司的限高要求。

三、 产品核心功能设计

1. 智能算法引擎(The Brain)

产品背后的核心是装箱算法。我们在设计中采用了**贪心算法(Greedy Algorithm)**作为基础策略,并结合了启发式规则。

从代码实现逻辑(GreedyAlgorithm.ts)来看,我们采取了以下策略:

  • 容器筛选:系统内置了 20GP, 40GP, 40HQ 等标准柜型,以及开顶柜(Frame Container)等特种柜。
  • 货物分流:根据货物高度自动分流。标准货物优先匹配标准箱,超高货物自动匹配框架箱。
  • 多维评分:算法不仅仅看体积利用率,还引入了 costEfficiency(成本效率)和 loadingEfficiency(装载效率)的多维评分体系。

2. 交互式3D可视化(The Eye)

B端产品最忌讳”黑盒”。即便算法算出了结果,用户如果看不到具体怎么摆,信任度就会大打折扣。

因此,我们利用 Three.js 和 React Three Fiber 打造了全视角的 3D 交互场景(Scene3D.tsx):

  • 所见即所得:真实还原集装箱尺寸和货物摆放位置。
  • 多箱展示:支持一次计算多个集装箱的方案,并在 3D 空间中自动排列展示。
  • 交互细节:支持旋转、缩放、透视,甚至可以点击查看单个货物的详细信息。还加入了“混凝土地面”、“安全警示线”等环境元素,提升临场感。

3. 决策辅助报告(The Report)

计算完成后,产品经理需要关注的是”结果交付”。我们设计了详细的 PackingSolutionReport:

  • 关键指标:直接展示空间利用率(Utilization Rate)、预估总成本。
  • 可视化图表:通过图表展示不同柜型的对比。
  • 打印支持:生成的方案可以直接导出打印,作为现场装箱工人的指导手册。

四、 技术架构选型与实现

作为一款现代化的 SaaS 工具,我们在技术选型上追求性能与体验的平衡:

  • 前端框架:React 18 + TypeScript。利用 TS 的强类型系统(如 PackingConfig, Cargo, ContainerType 等类型定义)保证业务逻辑的严谨性。
  • 3D 引擎:@react-three/fiber。它允许我们用声明式组件的方式编写 3D 场景(如 <Container3D />),极大地降低了 3D 开发的复杂度,让前端开发像写 HTML 一样写 3D。
  • 状态管理:使用了 React Hooks (usePackingCalculation, useCargoManagement) 进行逻辑复用,将算法计算、货物管理与 UI 展示解耦。

五、 核心难点与解决方案

难点1:如何处理特种货物?

场景:有些货物超高,普通集装箱装不下。

方案:我们在 ContainerType 中增加了 isFrameContainer 标记。算法在预处理阶段(separateCargosByHeight)会将货物分为”标准货物”和”超高货物”,分别匹配不同的柜型策略,确保”特货特装”。

难点2:如何让计算过程不卡顿?

场景:当货物数量成百上千时,3D 渲染和算法计算可能导致页面卡死。

方案

  1. 按需渲染:在 Scene3D 中,我们引入了可见性控制(visibleContainers),用户可以选择只查看特定的集装箱,减少 GPU 渲染压力。
  2. 算法缓存:通过 PackingSolutionCache 对计算结果进行缓存,避免重复计算带来的性能损耗。

六、 产品价值总结

通过这套系统,我们实现了从”经验装箱”到”数字化装箱”的转变:

  1. 降本:通过算法优化,平均提升集装箱空间利用率 10%-15%,直接节省运费。
  2. 提效:3D 可视化指导,减少了现场沟通成本和装错率。
  3. 决策:多方案对比评分,帮助业务人员快速选择最优(成本最低或装载最快)的订柜方案。

本文由 @天涯轩 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议