TB
TransBuddy · AI 改造方案总览
2026-08-06 · 产品组
Trans 物流系统 · AI 改造

两套方案,一个目标:
让 AI 直接办理物流核心业务

查单、拦截、妥投、签收、批量筛选、转代理、附件上传、数据看板——全部可通过 AI 完成,状态权限严格校验,操作全程可追溯。本页可切换查看汇报视频与两套方案的可运行原型。

方案一 · 改界面

TransBuddy 对话工作台

  • 纯聊天窗口完成全部核心业务,无业务版面
  • 多轮转代理:追问 → 确认单 → 一键转出
  • 执行/咨询双模式、@引用、附件上传
  • Web 端 + APP 端双形态,交互一致
  • 方案二 · 做服务

    Trans MCP 服务化 + 令牌授权

  • Trans 能力封装为 10 个标准 MCP 工具
  • 个人访问令牌按模块只读/读写授权
  • IP 黑白名单 + 活动日志,全程可审计
  • WorkBuddy / Cursor 等 AI 客户端即插即用
  • 📦 交付物清单

    TransBuddy-AI改造双方案汇报.mp4双方案汇报视频(3'40",带字幕与配音解说)
    TransBuddy-AI改造双方案.md双方案对比与方案二完整设计(推荐主读)
    TransBuddy-AI升级改造方案.md方案一演进全过程:现状摸底 → V1/V2/V3 → 工程化
    transbuddy-web-v3.html / transbuddy-app.html方案一 Web 端 / APP 端可交互原型
    transbuddy-token-admin.html方案二个人令牌管理页原型
    transbuddy-web/ · transbuddy-mcp-server/工程代码与可运行 MCP 服务(14 项测试全过)

    🎬 双方案汇报视频

    3 分 40 秒 · 带字幕与配音解说 · 适合直接投屏汇报
    ① 为什么改现状 AI 只能查不能办;目标是让 AI 直接办核心业务,严守状态规则。
    ② 方案一演示Web 端 + APP 端实景操作:签收、拦截、多轮转代理、看板汇报。
    ③ 方案二演示MCP 真实调用:只读令牌被拒、全权令牌打通、审计日志留痕。
    ④ 对比建议方案一是界面(面子)、方案二是底座(里子),建议组合落地。

    🖥 方案一 · TransBuddy Web 端原型

    可直接在下方操作:点欢迎页快捷卡片,或输入「签收运单 TRANS260430085892102,签收人:张先生」 新窗口打开 ↗

    📱 方案一 · TransBuddy APP 端原型

    底部 Tab 切换:对话 / 看板 / 我的;点「预警通知」会自动汇报看板 新窗口打开 ↗

    🔌 方案二总体架构

    AI 客户端WorkBuddy / Cursor
    →
    MCP 服务层10 个工具 · 权限校验
    →
    令牌 + API 网关只读/读写 · IP名单 · 日志
    →
    Trans 业务系统状态机兜底

    🧰 MCP 工具(10 个)

    工具说明权限
    query_waybill单号查全量详情运单·读
    batch_query_waybills多单号批量查询运单·读
    time_query_waybills时间区间批量筛选运单·读
    intercept_waybill拦截(拦截即锁定)运单·写
    deliver_waybill妥投(仅已派件)运单·写
    sign_waybill签收(需签收人)运单·写
    list_agent_transfers转代理记录转代理·读
    create_agent_transfer批量转出转代理·写
    validate_attachments附件校验上传附件·写
    get_dashboard统计与双预警看板·读

    🔑 接入方式(以 WorkBuddy 为例)

    { "mcpServers": { "trans": { "command": "node", "args": [".../transbuddy-mcp-server/server.js"], "env": { "TRANS_PAT": "trans-pat-你的令牌" } } } }
    ✅ 自动化测试 14 / 14 通过(只读拒写 · 无令牌拒调 · 状态机防重复)

    🎫 个人令牌管理页原型

    可交互:创建令牌(仅展示一次)、权限范围勾选、IP 黑白名单、活动日志 新窗口打开 ↗