一、需求分析
业务背景
物流的运价已经被压到极限。油钱、路费、司机工资这些轮子上的成本,同行之间早就抠不出花来了。真正还能省出真金白银的,是办公室里至今纯手工的那几件事:查单、录单、对账、催款。
先看两组来自行业一线的数字,感受一下量级:
七万不多,但它是纯利——因为它没有多雇人、没有多加车,只是把两道手工工序交了出去。这说明物流这一轮的 AI 机会,未必在"调度算法"那种大题目上,而在办公室里这些又碎又高频的工序上。
四类痛点
| 环节 | 现状 | 量级 |
|---|---|---|
| 查单 | 客户微信发个单号、电话打进来问"货到哪了"。客服复制单号 → 打开系统或平台查轨迹 → 复制结果回复。一票货 2–3 分钟 | 一人 120 通/天 |
| 询价 | 客户报过来的信息五花八门:有的写"10 吨货济南到西安",有的只发一张货物照片,有的连起点终点都说不清。业务员得先问清品名/重量/体积/起运地/目的地,再翻线路价格表,再手动填报价模板 | 整理信息的时间,可能比核价还多 |
| 对账 | 运单、回单、代收货款三头都得对;各家的月结对账单还要逐家核,对不上就互相打电话确认 | 月底对四天的账 |
| 催款 | 出账单慢、对账拖三五天;催款还没凭证,口头去催客户赖账时拿不出记录;90 天账期垫资,月底得借钱发工资 | 流程理顺后回款周期可缩短 ≥30% |
| 台账 | 哪票货的回单没回来、哪家客户月结超期、哪张运单代收货款没结清——全靠翻微信群和 Excel | 没有一本随手能翻的账本 |
需求的层次
问老板"你要什么",得到的通常是第一层:
"客户问货,你帮我答得快一点就行。"
但复盘一下这几件事,真正的痛点在第二层:这不是"做一个更快的客服",而是把办公室的四道工序产品化。 每一道工序,拆开看都是同一个骨架:
结构化输入(表格 / 单据)
→ 按规则比对(价目表 / 结算单 / 状态表)
→ 生成草稿或差异清单
→ 人工复核(这是硬门,不能省)四道工序是同一个骨架的四个实例。这个观察直接决定了系统形态:不是做四个单点工具,而是做一套可复用的智能体,再按客户下发。
为什么不是"把提示词丢给大模型"
因为物流的这几件事,有三个硬约束:
1. 口径必须来自真实表格,不能靠模型记忆。 运价随时在变,今天的成本和昨天不一样。让模型"估一个数",等于拿亏损赌客户。
2. 错了要赔钱。 报价报错是亏本或违约,对账对错是跟客户扯皮。所以模型只出草稿、只列差异,人工复核是硬门——这一步不能自动化掉。
3. 催款消息发出去就是凭证。 措辞有红线:不承诺减免、不写威胁性内容。真走到诉讼那一步,靠的是完整的运单和签收证据链,不是谁说话更狠。
二、技术方案
前置判断:三类能力必须分开
和所有企业落地一样,动工前先把"智能体要会的东西"拆成三类——因为它们的实现路径不同,失败代价更不同:
| 能力 | 在物流里是什么 | 技术路径 | 失败代价 |
|---|---|---|---|
| 知道 | 时效口径、运价规则、账期政策 | 检索 + 生成 | 说错话,客户换一家 |
| 记得 | 这票货到哪了、这个客户欠款到哪一级 | 结构化查询 + 会话状态 | 客户重复描述,体验崩 |
| 动手 | 查轨迹、写台账、生成催款草稿 | 工具调用 + 权限分层 | 做错事,要赔钱 |
**能说的和能做的,不能用同一套约束管。** 说错话可以道歉,做错事要赔钱。
交付形态:为什么是"分发平台",而不是"本地装个工具"
这是本案例最值得说的一个判断。
物流公司家家不同(线路不同、价目表不同、查询系统不同),但"查单/报价/对账/催款"这四件事的骨架完全一样。如果给每家公司各做一个本地工具,就是四份代码复制 N 遍——改一处,其余全不同步。正确的形态是一个智能体分发平台:
这正是我们自己智能体分发平台(coolseek.net 数字助理分发)的形态:**多租户、渠道接入、按客户分发、带配额与审计**。本案例的技术方案即以此为参考实现。
系统架构
分发平台层(多租户 · 渠道接入 · 配额 · 审计)
├─ 渠道适配:微信 / 飞书 / Telegram / WhatsApp …
└─ 每客户独立实例 + 独立数据目录(不是共享一张表)
│
会话与身份层
├─ 身份归并:办公室人员 / 司机 / 客户 → 企业内部角色
└─ 会话状态(当前意图 / 已收集信息 / 待兑现动作)
│
智能体编排层(四场景路由)
├─ 查单客服:状态表 + 只读查询 → 回复草稿
├─ 询价报价:结构化 + 价目表比对 → 报价草稿
├─ 对账催款:三表逐条核对 → 差异表;催款分级话术
└─ 台账:录入 / 查询 / 到期提醒(响应式 Web)
│
执行与合规层
├─ 权限分层(L1 只读自动执行 / L2 写入需人工确认)
├─ 幂等键(运单 + 动作类型)
├─ 审计日志(谁触发 / 依据 / 系统返回)
└─ 兜底转人工(查不到、无价目、连续失败、异常件)
│
企业系统(TMS / 查询平台 / Excel / 台账库)技术栈
推理 多模型路由(按任务复杂度与成本分配)
检索 结构化表格优先(运单表 / 价目表 / 结算单),非向量检索优先
工具 只读查询工具(轨迹 / 状态)+ 台账写入工具(幂等)
接入 智能体分发平台(多租户 / 渠道适配 / 配额 / 审计)
数据 每客户独立数据目录 + 审计日志
前端 响应式台账 Web(手机 / 电脑同开)三、实现细节
1. 查单客服:状态表 + 只读查询 + 「查不到不编」
每天把运单状态整理成一张表(单号、起点终点、当前状态、预计到达),智能体按表回答客户问询,生成回复草稿:
人工的动作只剩"扫一眼草稿 → 复制发给客户"。发不发、措辞怎么改,永远是人说了算。
如果客户的查询系统有可对接的网页版接口,可以让智能体直接调它拿轨迹,自动填表;如果只有本地客户端软件、没有可对接的口,那就退化成"人工填表 + 智能体生成草稿"。**这不是能力缺陷,是接口差异——方案里要显式写明哪一条走不通。**
2. 询价报价:结构化 + 价目表比对 + 「没有的线路标人工核价」
把零散的询价信息整理成标准字段(品名、重量体积、起运地、目的地、时效要求),信息不全的列出来告诉你该问客户哪几句;再对照本地价目表生成报价草稿:
一条底线写进提示词:运价随时在变,AI 生成的报价发给客户前,必须核对当天的实际成本(油费、装卸费、返程能不能带货)。亏本报价 AI 不知道;口头答应客户的时效,兑现不了就是违约。
3. 对账与催款:三类表逐条核对 → 差异表;催款分三级 + 留证
对账:把运单记录、回单签收记录、客户结算单三类表放同一目录,让智能体按单号逐条核对——运费金额对不上的、回单没签回的、代收货款有出入的,分别列成一张差异表,每条写清差在哪;对上的不列。
人工拿到差异表**逐条人工复核,别让 AI 替你判断谁对谁错**。几百上千条流水,人只需要看异常的那几条。
催款:按客户欠款时长和信用分三级写话术——半个月内(友善、顺带提醒)、一个月以上(明确结算时间和金额、请对方给付款安排)、两个月以上或答应过又没兑现(语气严肃、说明会暂停月结改现结、保留对账凭证)。
两条红线:每条都带具体金额和单据期间;不承诺减免、不写威胁内容。发出去就是凭证。
4. 台账小系统:把「没有一本随手能翻的账本」变成手机可开的小应用
前三件事背后其实是同一个根因:小型物流公司没有一本能随手翻的账本。 那就直接做一个:
5. 平台侧的三条硬约束
这是"分发平台"相对于"本地工具"的价值所在,也是不能省的:
1. 权限分层:只读动作(查轨迹、查状态)自动执行;写入动作(改台账、发消息)需要人工确认。能说的放开,能做的收紧。
2. 幂等:同一票货的同一动作重复提交,只生效一次——物流单据重复是最容易出的事故。
3. 兜底转人工:查不到、无价目、连续失败、异常件(破损/丢失/严重延误)——一律转人工,且在转交时把"缺什么"讲清楚。
四、项目成果
业务指标
以下数据来自公开的行业一线案例(来源见文末),非我们的自有交付:
| 指标 | 变化 |
|---|---|
| 对账耗时 | 4 天 → 1 天 |
| 年度增量纯利 | 约 +7 万元(同一批人、同一批车) |
| 查货电话处理 | 一人 120 通/天 → 人工只做"扫一眼草稿" |
| 运单录入量 | 一人 1400 张/月(工序结构化后 AI 接管整理) |
| 回款周期 | 流程理顺后 缩短 ≥30% |
一个结构性变化:从「靠人的记忆」到「可复核的清单」
这四件事的共同产出,都不是"一个答案",而是一张可复核的清单:回复草稿清单、报价草稿清单、对账差异表、催款分级话术、台账提醒列表。
这个变化的意义在于:把工序从"人的记忆和微信群"搬到了"可复核、可交接、可审计的清单上"。 人不再是"记住一切的那一个",而是"看异常的那一个"。这才是它为什么值钱——省的不只是时间,是对人的依赖。
关于获客
这类方案的获客路径很直接:它不是卖给"想尝鲜 AI"的人,是卖给已经在亏损里精打细算的人。 当运价压到极限,"一年多七万纯利、少对三天账"这种账,老板一听就懂。
五、可复用的经验
1. 别只做"更快的客服",要把工序产品化。 查单、报价、对账、催款是同一个骨架的四个实例——识别出骨架,才能一次开发、多客户下发。
2. "知道"放开,"动手"收紧。 说错话可以道歉,做错事要赔钱。权限分层不是可选项。
3. 口径一律来自真实表格,不来自模型记忆。 价目表、结算单、状态表——模型只做比对与生成,不做"估算"。
4. 人工复核是硬门,不是兜底。 报价、对账、催款,模型出草稿,人签字。谁把这一步自动化掉,谁就制造事故。
5. 交付形态是分发平台,不是本地工具。 多租户、渠道复用、每客户数据隔离、配额与审计——否则就是四份代码复制 N 遍。
写在最后
物流这个行业很特别:它把成本精算做到了极致,却在自己的办公室里留了一大块纯手工。这不是技术难题,是没人把这四道工序当作产品来设计。
四个智能体、一张可复核的清单、一次"人只看异常"的重心迁移——它不炫,但它是纯利。
如果你也在物流或类似的传统行业,手里有一堆"高频、重复、靠人记"的办公室工序,欢迎来聊聊怎么把它们变成可下发的智能体。
作者:Coolseek AI Lab | 深度案例与 AI 落地方法 → [coolseek.ai](https://coolseek.ai) | 智能体产品预约与演示 → [www.coolseek.net](https://www.coolseek.net)(内测中 · 可预约)
数据与场景援引自公开行业案例(作者:马佳彬,发布于「人人都是产品经理」,2026-10)。本案例中的系统架构与平台形态为我们的参考实现,与原文所涉第三方产品无关。正文数据未经独立复现,仅作行业量级参考。