货代行业的数据分析痛点被彻底颠覆！FreightBI作为专为货代企业打造的AI智能体，从非标准数据接入到可执行经营洞察的完整闭环，解决了通用BI工具与业务系统的致命短板。本文将深度拆解如何通过规则引擎与AI的精准分工，实现从Excel碎片到老板PPT的「最后一公里」突破，附带可落地的业务场景演练与自查清单。

货代企业是典型的「数据很多、结论很少」：收入、成本、航线、客户散落在 Excel、ERP 导出表和人工台账里，老板月底要的往往不是一张透视表，而是「本月到底赚没赚钱、哪条航线在拖后腿、能不能直接拿去开经营会」的答案。通用 BI 工具不懂货代口径，通用大模型又容易「说得漂亮、算不准数」。

本文以 FreightBI——面向货代企业的 AI 数据分析智能体——为例，先回答「为什么偏偏要做智能体、货代 ERP/FMS 为什么解决不了」，再明确主要使用对象是谁，并说明为何做成个人本机 PC 客户端，拆解一套可落地的产品方法论：半自动非标准数据接入 → 规则引擎算清指标 → 人机协同确认口径 → 结论化报告与 PPT 输出 → 可追溯的市场/行业参考。文中附带核心数据示例、规则判定逻辑、完整业务场景演练与对照自查清单，便于业务负责人评估方案是否匹配本公司流程。

一、业务痛点：货代企业「有数据、没结论」

货代企业的经营分析，表面上是报表问题，本质是信任与效率问题。

数据侧的三重困境

1. 来源分散：业务流水在货代业务系统导出表，费用在财务 Excel，客户信息在销售台账，口径各说各话。
2. 格式非标：表头不在第一行、合并单元格、同义词字段、航线命名不统一——「能打开」不等于「能分析」。
3. 人工拼月报：运营或财务每周/每月花大量时间透视、核对、写 PPT，老板仍要追问「为什么毛利率掉了 3 个点」。

管理层真正关心的五个问题

1. 本月收入、毛利、TEU 到底如何？
2. 哪条航线「量涨了、利跌了」？
3. 哪个客户收入高但利润贡献低？
4. 费用结构有没有异常波动？
5. 是我们自己做差了，还是市场都这样？

现有方案的缺口

市场上的通用货代业务系统内置报表、数据咨询和聊天式 AI，往往无法同时满足：懂货代口径、能处理非标准输入、输出管理层能直接用的结论、自动生成汇报材料。这正是垂直 AI 智能体的机会窗口——但「有机会」不等于「该做智能体」。下一节专门回答这个问题。

二、为什么做这个智能体：不是 BI 不够，是任务形态不对

很多人听到「货代 + 数据分析 + AI」，第一反应是：再加一个 BI 仪表盘，或者接一个大模型聊天框，让用户自己问。FreightBI 选择做垂直智能体，是因为货代经营分析本质上不是「看图」或「问答」，而是一条有状态、多阶段、必须人机协同的任务链。只有把整条链串起来，痛点才会真正被解开。

2.1 四类相邻方案，各自卡在哪

通用 BI 工具擅长拖拽图表，但默认前提是：数据已经进仓、字段已经标准、口径已经统一。货代企业的现实是——上传的第一份文件往往表头在第 3 行、收入字段叫「应收合计」还是「海运费」都说不清。BI 解决的是「怎么展示」，解决不了「怎么理解」。

货代业务系统内置报表离业务近，但解决的是「单子怎么流转」，不是「企业赚没赚钱」。这一点需要单独展开——很多货代老板会问：「我们已经有业务系统了，为什么还要另做一个智能体？」详见下文 2.2 节。

数据咨询服务能出专业报告，但按项目收费、按次交付，无法形成「每月上传、自动复用、持续跟踪」的产品体验。对年营收 5000万–5亿的货代企业，请不起常驻分析团队，却每月都需要经营判断。

通用大模型降低了「问数据」的门槛，但货代经营分析有三个天然不擅长的点：

• 算数不能交给模型：毛利率、单 TEU 毛利、客户集中度，错一个小数点，老板就不会再信第二次。
• 口径不能靠猜：收入含税还是未税、40 尺柜算几个 TEU——模型再聪明，也不能替财务拍板。
• 结论不能只给一段话：老板要的是能开会的报告和 PPT，不是聊天窗口里一段流式输出。

四类方案各解决了一角，却没有一个能同时做到：懂货代口径、吃进非标准 Excel、算清可信指标、输出可汇报材料。

2.2 货代业务系统能记账，为什么做不了经营分析？

「我们不是已经有货代系统了吗？」——这是 FreightBI 在客户沟通里最高频的问题之一。答案是：货代系统解决的是业务运营数字化，经营分析智能体解决的是管理层决策数字化——两者相关，但不是一个问题。

第一，系统建来「管单子」，不是「看利润」。

货代业务系统的核心对象是委托单、舱单、费用录入、对账开票——设计目标是让操作、单证、财务把日常业务跑通。内置报表多数是：未收未付、单票毛利（若有）、业务量统计、客户欠款账龄。老板真正关心的「本月整体毛利率为什么掉了」「哪条航线量在涨、利在跌」「Top 客户集中度是否过高」，往往不在系统默认菜单里，要靠 IT 或顾问二次开发——周期长、一改口径就要重做。

第二，数据天然是「碎的」，系统只守住自己那一摊。

典型货代企业的数据分布是：

• 业务流水在货代业务系统导出表
• 部分费用在财务系统或独立 Excel
• 销售维护的客户分级在 CRM 或私人表格
• 月底汇总时，运营/财务再把多份表 VLOOKUP 拼成「老板版月报」

货代系统再完善，通常也只覆盖本系统内已录入的数据，无法自动吞下「财务刚改过一版的分摊表」「老板临时要的上周快报」这类系统外 Excel。FreightBI 要解决的，恰恰是系统边界之外、月报拼装过程中的那一段。

第三，收入与成本的「口径战争」，系统不会替你裁决。

同一票业务，操作看的可能是报价收入，财务看的可能是确认收入；海运费、本地费、代收代付是否计入毛利，各家公司制度不同。FMS 里录的是什么口径，不等于管理层复盘时认可的口径。经营分析必须允许企业在接入阶段明确确认「收入按未税/含税」「哪些费用类型计入成本」——这是分析层能力，不是录单系统的设计重心。

第四，操作报表 ≠ 管理层汇报材料。

货代系统可以导出明细、可以打透视，但很少能直接产出：

• 带执行摘要的经营分析报告
• 按「结论 → 依据 → 建议」结构组织的风险清单
• 可拿去股东会、集团汇报的固定模板 PPT
• 附带可追溯的市场/行业参考对比

老板要的不是「再开一个系统菜单看数字」，而是今天下班前能不能拿走一份能讲的材料。从明细到叙事，中间仍靠人——这正是智能体要自动化的部分。

第五，市场对比与异常解读，超出业务系统职责边界。

「是我们自己做差了，还是市场运价都在跌？」需要拉运价指数、港口数据、公开行业信息，并与本企业指标对照。货代业务系统不会、也不应该承担联网检索、来源校验、置信度分级——这属于分析智能体的能力范畴。

结论：不是货代系统不行，而是分工不同。

• 核心使命｜货代系统：管业务、记账、对账开票｜FreightBI：把分散数据变成经营结论与汇报材料
• 数据范围｜货代系统：本系统内已录入数据｜智能体：系统导出 + 财务 Excel + 人工台账等多源拼装
• 分析视角｜货代系统：单票、客户欠款、操作效率｜智能体：航线毛利、客户贡献、集中度风险、费用结构
• 输出形态｜货代系统：明细表、标准报表｜智能体：结论化报告、异常清单、可汇报 PPT
• 与系统关系｜智能体不替代货代业务系统，而是承接其导出数据，补上「月报最后一公里」

因此，已有货代系统的企业，恰恰是 FreightBI 的目标客户——他们不是缺系统，是缺从系统数据到老板决策之间的那一层。

2.3 为什么是「智能体」，而不是「功能模块堆叠」

FreightBI 把产品形态定为智能体，不是因为赶 AI 热点，而是因为经营分析任务具备智能体最擅长的特征：

第一，任务链长且环节之间有依赖。 上传文件 → 识别结构 → 建议映射 → 等人确认口径 → 标准化入库 → 算指标 → 跑异常规则 → 检索市场参考 → 写洞察 → 装配报告 → 生成 PPT。任何一环的结果都会影响下一环。这不是单次 API 调用能完成的，而是需要工作流编排、状态持久化、条件分支与挂起恢复——正是智能体工作流要解决的问题。

第二，中间必须停下来等人。 收入字段映射错了，后面所有结论都是错的。智能体可以在「低置信度映射」「口径未确认」「数据质量 C 级」等节点主动挂起，等人确认后再继续，而不是一路自动冲到一份看起来专业、实则不可信的报告。

第三，AI 与规则必须分工，而不是二选一。 纯规则算得准，但读不懂「工作号」「业务编号」「Job No.」可能是同一个东西；纯模型读得懂表格，却会在毛利上「幻觉」。智能体的正确分工是：规则引擎做事实，工作流做编排，模型做语义理解与语言增强——各干各的，结果才可追溯。

第四，输出是「交付物」，不是「对话轮次」。 用户要带走的是 PDF、PPT 和异常清单，不是聊天记录。智能体围绕「完成一次经营分析任务」设计，天然比聊天机器人更贴近货代月报、周报、临时汇报的真实场景。

2.4 这个智能体要解决的五个核心问题

FreightBI 要解决的不是「怎么做图表」，而是以下五个贯穿全流程的问题——每一个都指向「必须做智能体，而不是单点功能」：

1. 数据格式不标准，系统如何理解？ → 需要结构扫描 + 语义映射 + 人工确认的组合能力
2. 多来源口径不一致，系统如何统一？ → 需要可保存、可复用的映射档案与业务假设配置
3. 货代指标复杂，系统如何形成可信结果？ → 需要规则引擎计算 + 质量分级 + 追溯链路
4. 管理层不看明细，系统如何输出专业结论？ → 需要洞察生成 + 报告装配 + PPT 导出的一体化输出
5. 企业想知道自己所处位置，系统如何提供对比？ → 需要可检索、可校验、可降级的市场/行业参考，而非硬编码 benchmark

这五个问题串起来，就是一条完整的智能体任务链；拆开做成五个互不相干的菜单功能，用户体验是断裂的，信任也无法建立。

2.5 做智能体的时机与产品判断

2024 年以来，大模型在语义理解、摘要生成、多步推理上已经足够支撑「辅助读表、辅助写报告」；同时货代行业数字化程度提升，企业手里已经有了大量 Excel 和系统导出数据，却仍然缺「从数据到结论」的最后一公里。

此时做 FreightBI 类智能体，有三点判断：

1. 需求真实且高频：月报、周报、临时汇报是刚性场景，不是「有了更好、没有也行」
2. 技术边界清晰：算数交给代码、口径交给人、语言交给模型——分工明确，避免「全自动幻觉」
3. 壁垒可逐步积累：映射规则复用、经营指标沉淀、匿名化行业样本——用得越多，智能体越懂这家企业和这个细分行业

因此，FreightBI 不是「给 BI 加一个 ChatGPT 插件」，也不是「再造一套货代系统」，而是围绕货代经营分析任务从头设计的垂直智能体：承接货代业务系统导出数据，把口径确认留在流程里，把可信结论送出去。

2.6 主要使用对象是谁？

FreightBI 的用户不是单一的「数据分析师」，而是一组围绕经营复盘分工协作的角色。产品设计里需要区分三类人：谁动手操作、谁看结论决策、谁负责把关可信。

核心受益对象（决策层）——老板 / 总经理

这是智能体存在的根本理由。老板通常不会亲自上传 Excel、也不会配置字段映射，但他是经营分析报告和 PPT 的最终读者。他关心：

• 企业整体收入、成本、利润是否健康
• 哪些航线、客户、业务在拖累利润
• 是否存在集中度风险和经营异常
• 能不能直接拿报告去开经营会，而不是等团队再加工一遍

对老板而言，FreightBI 的价值是：10 分钟内看懂本期经营真相，而不是学会一个新系统。

核心操作对象（执行层）——运营负责人

运营负责人是智能体最高频的日常使用者。他往往负责：

• 协调业务、财务提供数据，或亲自上传 ERP/FMS 导出文件
• 完成首轮字段映射与口径确认（或指挥数据专员完成）
• 查看航线、客户、成本维度的异常清单，安排业务排查
• 在经营会前导出报告与 PPT，提交给总经理

他的成功标准是：报告能帮他优先安排排查动作，而不是多一张看不完的明细表。

可信把关对象（校验层）——财务负责人

财务负责人不一定是上传者，但往往是信任闸门。他会质疑：

• 收入、成本、毛利口径是否与财务账一致
• 费用结构波动是否有据可查
• 系统结论能否追溯到原始字段

他的成功标准是：指标口径可解释，抽样核对能对上——否则老板再想看，财务这一关也过不了。

重要协作对象（配置与复用层）——数据专员 / 分析专员

在年营收 5000万–5亿、员工 20–200 人的货代企业里，往往有专人或兼职负责「拼月报」。他们是：

• 首轮数据接入与映射配置的实际动手人
• 映射规则复用后，每月「换文件、出报告」的效率受益者

他们的成功标准是：首次配置 30–60 分钟可接受，之后同类文件上传即分析，不再重复透视 VLOOKUP。

次级使用对象

• 总经理助理：临时汇报场景下代老板取报告、调 PPT
• 商务分析 / 销售负责人：关注客户贡献度、集中度风险，辅助客户策略讨论

一张角色关系图（产品视角）

1. 数据专员 / 运营上传 ERP 导出与 Excel → 确认映射口径
2. 财务在关键口径节点参与确认或抽样核验
3. 运营查看异常、跟进业务动作
4. 老板阅读结论、拿走 PPT 上会决策

谁不是首阶段主用户？

• 一线操作、单证员：他们用货代业务系统录单即可，不是经营分析智能体的目标用户
• 极小微、无人配合整理数据的企业：缺少能完成首轮配置的人，产品价值难以释放

种子客户画像（与角色对应）

• 年营收 5000万–5亿，员工20–200人
• 已有月报习惯，运营 + 财务能配合提供数据
• 老板有经营会/复盘需求，愿意试用「报告直出」体验

三、模块边界：FreightBI 交付什么、不交付什么

FreightBI 的定位不是「又一个 BI 工具」，而是围绕货代经营分析构建的垂直智能体系统。它要同时完成四件事：

1. 理解并接入复杂、非标准的业务数据
2. 将数据标准化并沉淀为可信经营指标
3. 基于规则引擎和 AI 生成可执行的经营洞察
4. 输出适合老板、运营和财务负责人的报告与汇报 PPT

首阶段明确不做的事

• 不承诺任意格式文件零配置全自动分析
• 不承诺首版就具备高精度同行经营分位值
• 不替代 ERP/FMS，不做复杂预测与定价优化
• 不追求企业级多组织权限体系

北极星目标

让货代企业管理层（以老板/总经理为核心读者）在 10 分钟内看清本期经营真实情况，并基于系统生成的报告或 PPT 做出经营判断。

首阶段用户边界

• 主操作人：运营负责人、数据专员
• 主决策人：老板 / 总经理
• 主校验人：财务负责人
• 详见上文 §2.6 主要使用对象

种子客户画像

• 年营收 5000万–5亿，员工20–200人
• 已有月报习惯但依赖 Excel 人工整理
• 愿意配合首轮数据接入配置

四、系统底盘：规则算事实，智能体做语言，人机协同保可信

FreightBI 的底层原则可以概括为一句话：规则引擎做计算，工作流做编排，模型做语言增强。

三层架构逻辑

1. 接入层：Excel/CSV 上传 → 结构扫描 → Sheet 分类 → 表头识别 → 字段映射候选 → 用户确认口径 → 标准化入库
2. 分析层：指标聚合（收入、成本、毛利、TEU、航线/客户/费用维度）→ 规则异常检测 → 历史对比 → 市场/行业参考检索
3. 输出层：在线经营分析报告 → PDF → 固定模板 PPT → 风险清单与行动建议

AI 智能体的真实角色

智能体不是聊天入口，而是围绕「经营分析任务」运转的工作流助手：

• 辅助判断 Sheet 类型与字段语义
• 用易懂语言提示用户确认关键口径
• 基于已算好的指标生成洞察摘要与 PPT 文案

智能体绝不独揽的事

• 核心数值计算（收入、毛利、TEU 等必须由代码完成）
• 财务口径的最终决定（收入含税/未税、成本完整性）
• 无公开来源支撑的行业 benchmark 结论

可信设计的四条铁律

1. 规则做计算，AI 做解释
2. 所有结论必须可追溯
3. 不确定的数据必须允许人工确认
4. 优先输出可信结果，再追求自动化程度

4.1 交付形态：为什么做成个人本机 PC 客户端？

FreightBI 以 Electron 桌面安装包交付（Windows / macOS / Linux），安装在使用者自己的电脑上，由一个人完成上传、映射确认、分析与导出。产品定位是个人本机上的经营分析助手：在本机导入 Excel，在本地算清指标、生成报告和 PPT，再通过文件交给老板、财务或经营会使用。

这样设计，与货代月报的真实制作方式高度一致：通常是运营负责人或数据专员在自己工位上拼数据、出材料，而不是全公司登录同一个网址协同编辑。

当前实现形态可以概括为：

• 渲染层：React + Ant Design，负责上传、映射确认、报告查看、导出任务
• 主进程：承载数据接入、指标计算、智能体工作流、PDF/PPT 导出——通过 IPC 与界面通信，无独立后端服务
• 本地存储：SQLite 保存映射规则、报告快照、工作流状态；上传文件与导出物落在本机用户目录
• 外部依赖：仅 LLM（DeepSeek）、行业联网检索（智谱等）走 HTTPS API，由使用者在设置中自行配置 Key

选择个人本机 PC 客户端的主要优点

• 经营数据不出本机｜收入、成本、客户明细在本地解析、入库、计算，不上传业务明细到任何厂商服务器。对个人使用者而言，没有「数据上云」的心理负担，也省去公司 IT 审批一套后端服务的流程。
• 安装即用，零运维｜不需要 Docker、Redis、PostgreSQL，也不需要公司搭服务器。下载安装包、配置自己的 API Key，即可在工位上开始首轮映射。
• 与 Excel 工作流天然贴合｜货代月报的真实入口是「从 ERP 导出 → 本地 Excel」。桌面端直接调文件选择器、读写本地路径、一键打开导出的 PDF/PPT，比浏览器来回上传下载更顺手。
• 重任务在本机可控执行｜大文件解析、规则计算、PPT 离屏渲染截图、行业检索循环，在主进程异步跑完，通过进度条反馈即可，不受浏览器标签页限制。
• 映射规则越用越省事｜字段映射、业务假设存在本机 SQLite，下月换一份新 Excel，规则自动复用——个人生产力工具的典型体验。
• API Key 本地加密保存｜模型与检索费用由使用者自行申请、自行承担，密钥加密存在本机。
• 「操作一个人，服务一群人」｜软件只装在使用者电脑上；老板、财务不装客户端，通过导出的报告 PDF、汇报 PPT 看结论。这符合多数货代企业「专人做表、管理层看结果」的分工，无需建设账号体系与权限后台。

需要接受的边界（对个人本机工具而言是合理取舍）

• 换机需带走本机数据｜映射规则、历史报告在 userData 目录，换电脑需备份迁移或重新配置——个人工具的常见特征，不是缺陷，但要提前知晓。
• 版本升级靠安装包｜修 bug、加能力需下载新版本安装，不如网页刷新即更新。
• 分析和操作绑在本机｜出差在外无法在自己笔记本上打开家里的那份映射库；但导出的 PDF/PPT 可以随身带走。
• 算力取决于本机配置｜超大 Excel、长周期历史分析，速度跟 CPU、内存、磁盘有关。
• 外联能力需联网｜本地计算可离线完成大部分环节，但 AI 洞察与行业检索仍需访问 DeepSeek、智谱等 API。

与 Web 形态对比：为什么本产品不优先做浏览器版

FreightBI 选择个人本机，不是因为「暂时做不了 Web」，而是使用场景决定了形态：

1. 使用者就是一个人——上传、认字段、出报告，不需要多人同时在线改同一份配置
2. 结论靠文件流转——老板要的是 PDF/PPT，不是登录系统看仪表盘
3. 数据敏感且来自本地文件——从本机读 Excel、在本机落库，路径最短、信任成本最低
4. 研发聚焦智能体能力——把精力放在接入、规则、洞察、导出，而不是账号、租户、云端存储

若未来有「多人共用映射库、总部统一看板」的需求，可以再单独做团队版或 Web 版；当前版本清晰定位于个人本机生产力工具，不混入协作能力，产品边界反而更干净。

当前产品以 Electron 桌面单体落地：一个人在本机完成从 Excel 到报告/PPT 的全流程，主进程承载接入、分析、智能体与导出，数据与规则默认留在使用者电脑上。

五、关键能力拆解

5.1 非标准 Excel 的半自动理解

真实货代 Excel 的常见乱象：多 Sheet 混排、表头在第 4 行、合并单元格、字段名「应收」「海运费」「Ocean Freight」并存。系统采用「结构扫描 + 规则初判 + 语义候选 + 人工确认」的组合策略，而非追求首版 100% 自动。

接入流程七个阶段：文件接收 → 结构扫描 → Sheet 分类 → 表头识别 → 字段映射候选 → 用户确认口径 → 标准化与规则保存。

一次确认、多次复用是留存关键：按租户、文件类型、Sheet 类型保存映射规则，下次上传同类文件时自动加载，仅对低置信度字段再次确认。

5.2 标准数据模型与经营指标

非标准数据最终沉淀为三类核心对象：

• 业务流水（ShipmentRecord）：单号、日期、客户、航线、TEU、收入
• 费用明细（CostRecord）：关联单号、费用类型、金额
• 客户信息（CustomerRecord）：客户名称、销售负责人、等级（可选）

核心指标口径：

• 收入 = 标准化 revenue 汇总（含税/未税须在接入阶段确认）
• 成本 = 关联单号的 cost_amount 汇总
• 毛利 = 收入 − 成本
• 毛利率 = 毛利 / 收入
• 单 TEU 毛利 = 总毛利 / 总 TEU（货代经营效率的核心标尺）

5.3 规则驱动的异常识别

异常检测以规则引擎为主，避免 LLM「凭感觉报风险」。首阶段覆盖概览、航线、客户、成本、数据质量五类异常。

5.4 分层行业对比

行业对比拆成两层，避免误导：

• 市场对比（首阶段可做）：运价指数、港口吞吐量、贸易统计等公开数据，回答「市场是否在波动」
• 经营对比（逐步增强）：毛利率、单 TEU 毛利、客户集中度等相对同行的水平，需有样本或可追溯公开来源

行业参考通过 Loop Agent 从公开网络检索：Observe 本企业指标 → Plan 检索词 → Act 搜索 → Extract 抽取 → Verify 校验来源与置信度 → 最多 5 次检索、3 轮循环。检索失败时仅展示本企业计算值，明确标注「行业参考不可用」，禁止编造 benchmark。

5.5 结论化报告与 PPT

输出不是图表堆砌，而是先结论、后依据：

• 报告首页：KPI + 核心发现 + 风险提示 + 行动建议
• 每条结论附带依据指标，可追溯到原始字段与映射规则
• PPT 采用固定模板，智能体生成标题与摘要文案，图表数据由规则计算结果绑定

六、衡量指标与产品成功标准

北极星过程指标

• 首次导入配置后，同类文件二次导入成功率 ≥ 80%
• 单次报告生成时间 ≤ 5 分钟
• 至少 70% 种子用户认为报告结果可信

业务价值指标

• 至少 3 家种子客户完成真实数据跑通
• 至少 2 家客户认可报告「比人工月报更有价值」
• 报告中至少 1 条异常或建议被客户用于后续跟进

过程漏斗指标

上传转化率 → 字段映射确认完成率 → 数据校验通过率 → 报告查看率 → PDF/PPT 导出率 → 异常项点击查看率

质量红线

• 核心指标人工抽样校验准确率
• AI 结论可追溯率
• LLM 输出失败时的规则降级成功率

七、核心数据示例

以下示例为贴近货代业务的虚构样例，用于说明单据关联与业务关注点。

7.1 上传与结构识别

上传编号：UPL-2025-1103-001

文件名：华东货代_10月经营明细.xlsx

Sheet 扫描结果：

• Sheet「业务明细」｜类型候选：业务流水｜表头行：第 3 行｜置信度：0.92
• Sheet「费用分摊」｜类型候选：费用明细｜表头行：第 2 行｜置信度：0.88
• Sheet「说明」｜类型候选：无关表｜建议跳过

业务关注点：多 Sheet 文件中，系统须先分类再映射，避免把汇总表当明细分析。

7.2 字段映射确认

映射档案：MAP-华东货代-业务明细-v1

关键映射：

• 原始字段「工作号」→ 标准字段 shipment_id（业务单号）
• 原始字段「应收合计」→ 标准字段 revenue（收入，用户确认：未税）
• 原始字段「航线」→ 标准字段 route_name
• 原始字段「箱量TEU」→ 标准字段 teu

口径确认：收入按未税口径；40HC 按 2 TEU 折算

业务关注点：收入含税/未税、箱型折算方式必须在接入阶段由用户确认，不能由模型猜测。

7.3 标准化业务流水（节选）

• SH-2025-10001｜2025-10-05｜宁波某进出口｜东南亚线｜2 TEU｜收入 18,600 元
• SH-2025-10002｜2025-10-08｜上海某贸易｜欧地线｜4 TEU｜收入 42,800 元
• SH-2025-10003｜2025-10-12｜宁波某进出口｜东南亚线｜1 TEU｜收入 8,200 元

7.4 关联费用明细（节选）

• SH-2025-10001｜海运费｜12,400 元
• SH-2025-10001｜港杂费｜1,850 元
• SH-2025-10002｜海运费｜31,200 元
• SH-2025-10002｜拖车费｜2,600 元

关联关系：费用明细通过 shipment_id 与业务流水关联；毛利 = 流水收入 − 关联费用汇总。

7.5 10 月经营指标快照

• 总收入：1,286 万元
• 总成本：1,052 万元
• 总毛利：234 万元
• 毛利率：18.2%
• 总 TEU：6,840
• 单 TEU 毛利：342 元

7.6 数据质量评级

• 质量等级：B（有少量警告，允许继续分析）
• 警告项：3.2% 业务单号在费用表中无匹配记录；东南亚线部分记录缺少箱型字段，已按默认规则折算 TEU

业务验证点：费用与业务单关联不完整时，系统应降级提示而非静默忽略，否则毛利会被高估。

八、规则与判定逻辑

8.1 规则如何匹配

异常规则在指标计算完成后触发，输入为标准化后的 ShipmentRecord、CostRecord 及历史对比结果。每条规则输出：异常名称、目标对象、当前值、对比值或阈值、风险等级、建议动作、依据指标。

8.2 首阶段核心规则与默认阈值

• GP_MOM_DROP（毛利率异常下降）｜逻辑：毛利率环比下降超过阈值｜默认阈值：20%｜优先级：高
• TEU_COST_UP（单 TEU 成本异常上升）｜逻辑：单 TEU 成本环比上涨超过阈值｜默认阈值：15%｜优先级：高
• NEG_ROUTE_PROFIT（航线负毛利）｜逻辑：某航线毛利为负且收入占比超阈值｜默认阈值：收入占比 10%｜优先级：高
• TOP3_CONC_RISK（客户集中度偏高）｜逻辑：Top 3 客户收入占比超阈值｜默认阈值：40%｜优先级：中
• COST_TYPE_SPIKE（费用类型异常波动）｜逻辑：某费用类型环比上涨超阈值｜默认阈值：25%｜优先级：中

8.3 数据质量分级与后续动作

• A 级（可直接分析）｜结构完整、口径已确认 → 正常生成报告
• B 级（有少量警告）｜允许继续分析，报告中标注质量说明
• C 级（勉强可分析）｜需用户确认是否继续，结论须降级表达
• D 级（不可分析）｜阻断正式报告，仅输出扫描结果与修正建议

8.4 行业参考的 Verify 逻辑

行业 benchmark 须通过校验才可进入报告：

• 必须有 source_url 与原文摘录
• confidence ≥ 0.5
• LLM 抽取 found: false 或 Verifier 拒绝 → 不写入市场值
• 5 次检索后仍不足 → benchmark_status = partial，detailNote 说明实际检索次数

三类结果含义

• 通过：指标进入报告正文，附来源链接
• 警告（partial）：部分指标有参考，其余仅展示本企业值
• 阻断（unavailable）：不展示虚构行业值，避免误导管理层

九、场景演练

场景 A：月度经营复盘（正常闭环）

背景：10 月底，运营负责人张敏上传《华东货代_10月经营明细.xlsx》，准备周五经营会材料。

步骤

1. 张敏上传文件 → 系统扫描识别 2 个有效 Sheet，跳过「说明」页
2. 系统加载历史映射 → 自动匹配 92% 字段，仅「杂费合计」需人工确认映射为 cost_type=杂费
3. 张敏确认口径 → 收入未税、40HC=2TEU，质量评级 B，允许分析
4. 系统计算指标 → 收入 1,286 万、毛利率 18.2%、TEU 6,840
5. 规则引擎触发 → 东南亚线 NEG_ROUTE_PROFIT（该航线毛利 −12 万，占收入 11%）；GP_MOM_DROP（毛利率环比上月下降 22%）
6. 行业参考检索 → 公开来源显示东南亚运价指数环比上涨 8%，本企业该航线毛利率下降更多，倾向内部成本问题
7. 生成报告与 PPT → 首页摘要 3 条发现、2 条风险、3 条行动建议；张敏导出 PPT 提交总经理

业务验证点：老板能否在 10 分钟内抓住「整体尚可、东南亚线需专项排查」的结论？PPT 是否可直接上会？

场景 B：周度异常排查（毛利率突降）

背景：11 月第 2 周，财务负责人李磊发现周报毛利率从 18.2% 降至 14.1%。

步骤

1. 李磊上传 11 月前两周数据 → 映射规则复用，无需重新配置
2. GP_MOM_DROP 触发 → 毛利率环比下降超过 20% 阈值
3. 下钻航线维度 → 欧地线单 TEU 成本环比上涨 18%（TEU_COST_UP 触发）
4. 下钻费用维度 → COST_TYPE_SPIKE：海运费环比上涨 32%
5. 市场对比 → 公开运价指数同期上涨约 10%，企业内部海运费涨幅显著高于市场
6. 系统建议 → 核查欧地线近期合约价、附加费录入是否完整；与采购核对 11 月初加价是否同步体现在报价

业务验证点：异常能否定位到「航线 + 费用类型」而非空泛的「成本上升」？建议是否可执行？

场景 C：数据质量不足（阻断分析）

背景：新客户首次上传，仅有汇总透视表，无业务单号明细。

步骤

1. 系统扫描 → Sheet 类型候选为 summary_report，置信度 0.95
2. 字段映射 → 有月份、航线、收入合计，无 shipment_id，无费用明细
3. 质量评级 D → 缺少主键与成本字段，不满足正式报告最低条件
4. 系统动作 → 阻断正式报告，输出结构扫描结果与修正建议：「请提供含业务单号的流水明细及费用分摊表」
5. 智能体降级 → 不生成盈利结论，不输出行业 benchmark 对比

业务验证点：系统在数据不足时是否「敢说不知道」，而非硬凑一份看起来专业的报告？

场景 D：老板临时要汇报（价值瞬间）

背景：周三下午，总经理要求当天 18:00 前提交股东会经营简报。

步骤

1. 运营上传已配置过的 9 月数据 → 映射全自动复用
2. 5 分钟内完成分析 → 报告 + PPT 一键导出
3. PPT 结构 → 封面、执行摘要、KPI 总览、航线分析、客户集中度、风险与建议、附录
4. 总经理直接使用 → 无需运营重写文案或重做图表

业务验证点：这是 FreightBI 的核心 Aha Moment——用户敢把系统产出直接拿去汇报。

十、对照自查清单

帮助读者快速判断 FreightBI 类方案是否匹配自身企业制度与数据现状：

• 数据形态｜要问：我们的月报数据主要在 Excel、ERP 导出还是系统直连？｜系统需支持：非标准 Excel 半自动理解 + 映射规则复用
• 收入口径｜要问：报表收入含税还是未税？是否含杂费？｜系统需支持：接入阶段强制口径确认，不可由 AI 猜测
• 成本完整性｜要问：成本是单票分摊还是月度汇总？缺成本时能否接受「仅收入分析」？｜系统需支持：缺成本时阻断盈利结论或降级表达
• 主键关联｜要问：业务与费用能否通过单号关联？｜系统需支持：主外键关联成功率检查与质量分级
• 异常规则｜要问：我司关注哪些经营红线（毛利率、集中度、负毛利航线）？｜系统需支持：可配置阈值 + 可追溯依据
• 行业对比预期｜要问：老板要的是「市场运价」还是「同行毛利率排名」？｜系统需支持：市场对比与经营对比分层表达，禁止虚构 benchmark
• 汇报场景｜要问：月报读者是谁？是否需要 PPT？｜系统需支持：结论化报告 + 模板化 PPT 导出
• 首次配置成本｜要问：谁来做首轮字段映射？能否接受 30–60 分钟配置？｜系统需支持：一次确认、多次复用，二次导入成功率 ≥ 80%
• 可信追溯｜要问：财务质疑数字时，能否追到原始字段？｜系统需支持：结论 → 指标 → 标准字段 → 原始列 的全链路追溯
• AI 边界｜要问：能否接受「模型只写文案、不算数」？｜系统需支持：LLM 失败时规则报告降级，不输出虚构结论
• 交付形态｜要问：谁在本机操作、结论如何传给管理层？｜个人本机客户端：一人上传分析，报告/PPT 导出后流转；不要求多人登录同一系统

十一、结语：从「自动画图」到「经营判断基础设施」

FreightBI 的真正价值，不在于做一份好看的 PPT，而在于把货代企业最头疼的「数据整理」变成可复用的数据资产，把「人工拼月报」变成「10 分钟看清经营真相」。

对产品经理和解决方案设计者而言，这个品类有六个值得复制的经验：

1. 先回答「为什么做智能体」——货代经营分析是长任务链；ERP/FMS 管单子不等于能出经营结论，智能体补的是「月报最后一公里」。
2. 分清使用对象——老板看结论、运营做上传与排查、财务把关口径；产品必须按角色设计，而不是只服务「会 Excel 的人」。
3. 垂直场景胜过通用平台——货代口径、非标 Excel、管理层表达习惯，决定了必须做深而非做宽。
4. 人机协同是信任的前提——在财务口径未确认前，自动化越高，信任崩塌越快。
5. 行业对比要分层售卖、分层实现——市场对比先上，经营 benchmark 靠样本积累，绝不硬编码「行业平均值」。
6. 形态服从使用方式——个人本机工具，一个人操作、文件带走结论；不必为多人协作叠加账号与云端复杂度。

首阶段的正确方向，不是「模板化报表工具」，而是半自动数据接入 + 可信分析引擎 + 结论化输出的货代 AI 智能体。当种子客户愿意把系统报告直接带进经营会，这条产品路径就被验证了。

十二、定制开发：每家公司的专业要求不一样

FreightBI 标准版面向货代行业共性最强的经营分析链路：非标准 Excel 接入、口径确认、指标计算、报告与 PPT 输出。但实际落地时，几乎每一家公司都会提出只属于自己的专业要求——这不是「加个字段」那么简单，往往涉及业务规则、分析视角、汇报习惯乃至与现有系统的衔接方式。

常见定制方向

• 专属智能体能力｜按贵司分析习惯调整工作流阶段、人机协同节点、异常阻断规则与降级策略（例如：必须关联成本才出盈利结论、特定航线命名体系的自动归一）
• 指标与规则引擎｜在标准 KPI 之外，增加公司自用的经营指标、预警阈值、客户/航线分级逻辑，并保证可追溯、可复算，不把算数交给大模型
• 字段映射与口径模板｜针对贵司货代系统导出格式、财务分摊表结构，预置映射方案与业务假设模板，缩短首轮配置时间，提高二次导入成功率
• 报告与 PPT 表达｜按股东会、经营会、部门周会等不同读者，定制章节结构、图表组合、摘要话术风格与品牌视觉规范
• 指定 API 接入｜对接贵司指定的外部或内部 API——如货代业务系统开放接口、运价/舱位数据服务、财务中台、CRM、自建数据中台等；由智能体按约定协议拉数、增量同步或触发分析，API 密钥与访问策略由客户侧配置，不写入安装包
• 指定行业数据接入｜接入贵司认可的行业数据源（运价指数、口岸统计、船公司公告、协会/研究机构公开数据、采购的第三方行业库等），限定检索范围、更新频率与引用格式；分析结论中明确标注「行业数据来自何处」，与本公司经营数据分层呈现，避免混为一谈
• 行业对比与外部检索｜限定检索来源、对比维度与引用格式，避免「泛泛的行业平均数」，贴合贵司对市场运价与经营 benchmark 的分层要求
• 系统对接（可选）｜在标准「本机文件导入」之外，按需对接 ERP/FMS 导出接口、定时拉数或内部数据服务——仍建议保留口径确认环节，避免「自动进来、自动算错」

为什么建议定制，而不是硬改标准版

• 专业要求写在流程里，而不是写在 Prompt 里——货代企业的差异多在口径、规则和汇报结构；定制应落在可维护的规则与模板层，而非依赖模型「临场发挥」。
• 标准版保证底座可信，定制版保证贴合组织——算数、追溯、质量分级等底座能力复用；差异部分单独交付、单独验收，降低长期维护成本。
• 一次定制，多次复用——与标准版一样，定制成果应沉淀为映射模板、规则配置与报告模板，而不是每次月报都靠人工重做。

适合启动定制评估的信号

• 自查清单（第十节）里有多项「系统需支持」与贵司制度明显不一致
• 老板固定要看 3–5 个非标准 KPI，且口径每年由财务书面确认
• 已有稳定的 ERP 导出格式，希望「上传即分析」但仍要可审计
• 汇报材料有明确的品牌规范、章节顺序或监管/股东披露要求

若贵司存在上述情况，可在标准 FreightBI 底座之上进行智能体与输出链路的定制开发：先对齐业务场景与可信边界，再分阶段交付映射模板、规则扩展、指定 API / 行业数据接入方案与报告/PPT 规范，避免「一上来全定制、最后不可维护」。标准版适合验证价值与流程匹配度；定制版适合把已验证的方法论，固化成只属于贵司、接得上指定数据源的经营分析智能体。

系统相关截图