飞驼网络

产品与系统

一套自研系统矩阵,
四个域

下面每一个系统都在飞驼自己的业务里天天运转——先自用,被真实单量磨过,磨到自己愿意用,再谈对外输出。一套没有被真实业务磨过的系统,演示时有多好看,上线后就有多难用:它没见过现场的一百种例外,而现场只由例外构成。

看解决方案 聊聊输出与合作

履约域

把货按时按质送出去

支撑日均十万量级订单的主战场,也是所有系统里被磨得最狠的一组。它们不是六套各自为政的软件,而是同一条数据流上的六段。

  • Warehouse Management

    云仓 WMS

    多仓统一管理,按仓切片的作业模型。仓内是「库区—库位—载体」三层结构,库位精确到排层格深度,带承重与温湿度约束。出库以波次为单位,标准波次、同构批量、摘果播种、B 端批量四种模式并存,对接 Geek+ 货到人机器人拣选并做库存镜像对账。出库前称重复核,一票记订单理论重、实际称重、计费重三个口径。

  • Order Management

    OMS 订单中台

    平台店铺授权、开放接口、标准协议三条来源进来,出去只有一种规整的作业单。订单进来先判结构(单件/单品多件/多品)并计算同构标识——商品构成完全相同的订单被自动聚成一批,这是爆款能批量作业的前提。拆合单、地址异常、缺货、超区拦截全部前置在进仓之前。

  • Transportation Management

    TMS 运输管理

    承运商路由是一张按平台、店铺、省市、重量区间、金额区间、优先级配出来的规则表,输出首选加备选、可自动降级。全程路由跟踪识别滞留、虚假签收与退回。计费核对逐票比对我方称重、承运商账单重量与账单费用——全量,不是抽查。

  • Cloud Waybill Printing

    云端面单打印

    把散在各终端的十多个平台打单组件集中到云端统一调度,面单提前生成并落库,终端凭运单号取件出单。终端只剩一个轻量程序,老机器也能出单;平台组件抖动卡不住出货现场;「漏打」从黑盒变成一条有状态、可查可补的记录。

  • Reporting

    报表系统

    从仓内作业到履约时效的全链路报表,口径统一维护,货主、仓库、管理层看到的是同一套数字。新的报表需求配一张查询就能发布到货主端,不用改代码发版——「客户报表需求永远做不完」这个老问题,解法是把配置权拿在自己手里。

  • Ticketing

    智能工单

    履约链路上的问题在同一张单据上收敛。工单挂在具体单据上自动带出上下文,处理结果从受类型约束的结论集里选,赔付责任由「类型加结果」自动推定。下面单独一节展开。

客户域

把客户侧的信息收进同一套结构

  • Call Center & CRM

    呼叫中心与 CRM

    自建呼叫中心,浏览器即软电话,坐席打开网页就能外呼接听,通话记录与录音自动沉淀到客户档案。线索分配采用「预模拟加人工可改加超时自动落实」——引擎给建议,人始终能接管,总开关一关就回到人工认领。成交归属在转化那刻定死改派不变,认人一律用工号,提成只认已完成结款的账单。

  • Omni-channel Messaging

    多平台消息接入

    把多个渠道的客户消息接进统一的处理结构:一套业务代码对接多渠道,换渠道只换适配层,业务逻辑和坐席工作台零改动。客户从哪个渠道来不重要,接待流程、归属规则和数据沉淀是同一套;新增一个渠道不需要重做一遍客服系统。

  • Ads Management

    广告投放管理

    建计划、建广告、调预算出价、启停、管素材、盯盘全在自己的后台完成,素材改动有改前改后对比并自动读回核对。投放接口没有沙盒,调用即真花钱,所以写操作默认不发出去。四道闸:账户白名单、单次与单日金额闸、上调倍数限制、意图台账防重复扣钱,新建广告一律落成暂停态。花了多少钱、来了多少线索、成了几单,一条链路对得上。

经营域

让经营结果和现场动作对得上账

  • Billing & Settlement

    应收应付与开票

    应收、应付、预付账款加开票与采购报销一体化。两条不可协商的机制。一是财务单据永不删除,只能冲销、调整、作废,审计不可关闭。二是业务型账款不允许人工创建,一律走统一入账管道:每条账款带「来源系统、来源单号、来源版本」的幂等标识,上游重推同一单时,未核销的自动冲销重建、已部分核销的生成调整单。金额一律定点数全系统禁用浮点;多法人主体强制归属,付款只能选该主体名下的账户。

  • Data Dictionary

    数据字典

    把「这个字段到底是什么意思」从口口相传变成会自己更新的活文档。仓储侧分三层:设计说明书快照、数据库实况结构、人工沉淀的业务口径笔记,官方文档一有变更就自动同步并产出可比对的变更报告。客户侧由代码里的结构注释自动生成,每一列写清含义、谁写的、取值枚举,以及这一列在什么情况下会骗你。

  • Recruiting

    招聘工作台

    AI 辅助的简历初筛与业务方轻量评审,与招聘系统并存分工。几条硬规则,体现的是我们对「AI 进入业务流程」的一贯态度:AI 推荐、人决策,评分永远不直接触发状态变更;评审必须写理由,接口层和数据库层双重强制;意见与决策分表;评分表单版本化,后来改权重不会悄悄改写已经下过的判断。

决策域

Flyto Agent 决策引擎

上面三个域解决「记录与执行」,这个域解决「判断」。它是飞驼智能的内核,全部工程设计围绕同一个问题展开——错了怎么办。值得单独一整页。

  • 场景建模

    业务场景描述成引擎能理解的结构:要做的判断、输入与口径边界、什么输出绝对不允许、多久之后才知道对错。场景变了改描述不改代码,新场景以模块叠加接入。

  • 执行边界

    AI 负责决策,业务系统的接口负责执行,AI 不直接写业务数据库。库存不能为负、金额精度不能丢、状态机不能跳步——这些不变量该由业务系统自己守。

  • 三层防御

    指令层约束方向,参数层限制能力边界,兜底层接住前两层漏掉的一切。永远不假设模型会百分之百遵守指令。

  • 暂存与双层校验

    每个决策先落成一条可审计的记录,通过技术层与业务层校验才进入执行。「不校验」必须是一个明写的、出现在日志里的选择。

  • 留痕与反向论证

    决策带输入、依据和上下文,出问题能回放;代价高、不可逆的动作还要先产出结构化的反面论证。

  • 影子、灰度与熔断

    推演在与生产同构的影子环境里进行,新逻辑先影子运行再灰度放量,质量异常自动熔断回退。上线不是一次赌博。

需要其中某一块?

这些系统先服务飞驼自己的业务,也对外输出。我们不承诺「什么都能做」——能对外讲的都是我们自己每天在用的,正在建的、只画在设计文档里的,我们不会说成已经有的。无论你要的是完整的仓配履约,还是某个单独的能力,都可以聊。

留下联系方式 读长文