做了个年销几千万的亚马逊卖家供应链履约系统：从需求拆解到OpenClaw微信集成的完整复盘

qq_34489134

488人浏览 · 2026-06-10 18:02:01

qq_34489134 · 2026-06-10 18:02:01 发布

有两个朋友过去四五年一直在亚马逊上做跨境精品自营，因为都有过海外的学习和生活经历，对终端市场和审美也有些自己的体感，整体业务做得不错，年销已经到了小几千万人民币的量级。这两年规模上来之后，SKU 涨到了大几十个，合作供应商也到了小几十家，团队的运营效率开始遇到一些瓶颈。

起初几个月前刚找到我聊这件事的时候，先是整了个思维导图，从生产前到生产后把仓库、供应商、产品、合同、发货计划、质检、库存、财务这一整套供应链管理模块都罗列进去了，想看看哪些环节可以加上 AI 来降本增效。梳理了两次之后，达成共识以供应链履约作为切入口。两个多月开发下来，系统已经初步成型，初步试用下来反馈还行。

最近一两年开始火起来的 OPC 概念，背后更多是 AI Coding 带来的技术平权和技术下放，让越来越多的小而美团队和独立开发者也能跑出完整的业务闭环。从这个角度来说，在亚马逊上开店，其实算得上是一种更早期的 OPC 原型。OPC 和这行也或许一样，绝大部分下场的人并不会真正挣到钱。AI 这个新的技术变量，今天对于跨境电商卖家群体而言，主流应用还集中在电商生图、生成 Listing 文案、写邮件回复这一类内容产出层面，解决的更多是表层的人工替代。但真正值得进一步探索的，或许是它能不能在更精细的供应链管理和运营侧撑起新的增长竞争力，这也是这篇文章想探讨的一个命题。

这篇试图说清楚：

前面先讲讲这家几个人团队当下的真实运作状态和痛点；再聊聊这类需求为什么在传统 ERP 那里长期没被解决；接着顺着主线展开整套履约系统是怎么从需求拆解到产品定义、再到具体工程实现一步步落下来的；中间会穿插一段 OpenClaw 微信通知集成的实操；最后跳出项目本身，写了三段我个人对跨境电商工具生态、AI Coding 能力边界以及独立开发者选题方向的一些观察。

以下，enjoy:

1、行业大背景先说清楚

1.1、亚马逊跨境的宏观背景

公开可查的数据是，亚马逊从 02 年开始向第三方卖家开放平台到现在，累计开店的卖家已经接近一千万家。每年实际还在运营、有持续交易的活跃卖家口径，不同数据源给的数字大多在一百多万到两百多万之间。其中中国卖家的占比这两年首次过了一半，按 Marketplace Pulse 的统计是 50% 出头，如果把那些直接在海外注册公司、用海外团队运营的中国背景卖家也算上，实际比例可能还要高出不少。

跨境电商有两个老生常谈的行业红利，一是中国是全世界唯一拥有联合国产业分类中全部工业门类的国家，41 个大类、207 个中类、666 个小类一个不少，从原材料到加工到包装再到出口物流，几乎每一段都有成熟的产业集群可以挑供应商。当然这件事也有一个动态的过程，新手卖家刚入场的时候单量小，往往只能找一些小作坊承接，付款条件、起订量、交期也都不会太友好；做到一定规模之后议价能力上来，才有可能拿到稳定的大厂资源和合理的账期。

二是过去十多年美国一直有一条小额免税政策，单包货值在 800 美元以下进入美国可以免税、不走正式清关。这个阈值是 16 年奥巴马签署的 TFTEA 法案抬高到 800 美元的（之前是 200 美元），这条规则也很好地孵化了一大批以小包直邮起家的中国跨境卖家，同时也放大了亚马逊、Shein、Temu 这些平台的 GMV。不过 25 年 2 月特朗普政府取消了这个政策，这一刀直接砍在了依赖小包直邮、靠便宜走量的铺货模式上；有一定实力的玩家则开始通过把部分产能往东南亚、墨西哥转移来对冲关税成本。

1.2

三类主要玩家的画像

文章开头提到了精品卖家的概念，可能有盆友看得不明所以，为了方便不熟悉这个行业的盆友权当涉猎一下，这里简要介绍下三类玩家的大致画像。

第一类是铺货模式（俗称店群），开几十个店、上几千个 SKU，单店做不大但靠数量堆，对供应链能力要求很低，关键是供货稳定和价格够便宜，这一类在红利期增长最快，但在小包直邮政策取消之后压力也最大。

其次是精品自营，核心思路是聚焦少数几个品类，把 listing 当成长期资产去打磨、慢慢做品牌沉淀，相比铺货模式对供应链能力的要求高很多，单 SKU 周转和质量稳定性是关键，这类卖家在过去几年逐渐变成主流，本文要讲的也是这一类。

最后是已经做成全球品牌的成熟大卖，比如 Anker（安克）和泽宝旗下的 RAVPower、TaoTronics 这些，有自己的研发、自己的内部 ERP、自己的成熟运营体系，玩的是另外一个游戏。

2、案例卖家的背景信息

2.1、团队与分工

具体到这家朋友团队，团队规模一直保持得很精简，但分工很明确。一位专门盯运营和亚马逊端的销量、广告投放和库存补货节奏；另一位负责供应链管理，从工厂选择、合同签订到生产跟进、验货发货都是他的工作范围。

2.2、主营品类与供应商网络

出于商业敏感，本篇统一以家居收纳作为类比展开。实际经营品类相邻但不一致，在供应链结构上高度相似，同样是多部件组合，同样涉及尺寸精度、缝线针距、五金件牢固度、彩盒抗压这一类质检项。这类产品的特点是结构件、布艺、五金件、彩盒等部件往往要分别找不同的工厂去做，没法一家工厂搞定。

合作的供应商体系也因此是按零部件品种来匹配产业集群的，并不局限在单一地区。长三角和珠三角自然是主力，但根据不同零部件的需求，山东、江西等地的产业带也都有对应的合作工厂。中国完整工业门类的优势在这里体现得很直接，几乎每一类零部件都能在全国范围内找到合适的产业带资源，单一供应商出问题的时候替代选项也相对好找。

2.3、履约这一段的实际状态

选品方面他们一直有自己的一套对标策略，安全库存的判断也大致能靠经验用 Excel 来估。真正最费精力的是供应商履约这一段。因为产品本身相对非标，而出厂合格率又直接关系到亚马逊上的好评率，单个 SKU 往往要拆成多个同样非标的部件，再叠上几十家供应商和几十个 SKU 同时在生产，每个批次都是几十个需要远程沟通和线下确认的节点动作，工作量难免繁杂。

负责供应链的那位朋友大部分时间都在外面跑工厂，跟批次、盯生产、验货是他的主要工作内容。验货环节偶尔会外包给第三方质检，但绝大多数批次还是他亲自跑。日常跟工厂的沟通基本靠微信，载体大部分都是图片和短视频。

而且这里有一个容易被忽略但其实很关键的细节，就是微信对图片和视频是有保存有效期的，没顺手下载到本地的话，几天后再翻回去就已经过期、无法访问。这意味着所谓的验货记录、沟通过程、异常凭证，在长时间维度上其实是在持续消失的。

而市面上传统的通用工具大多只是对跨境电商通用动作的抽象，很难把这些非标动作沉淀成稳定 SOP，也就很难贴合他们实际的业务流程和工作习惯。

3、为什么传统跨境 ERP 没解决这一段

3.1、供应商履约这一段本质上就是非标的

一个精品卖家手上通常同时有几十个 SKU，每个 SKU 往下又会拆成多个非标零部件（结构件、布艺、五金件、彩盒分别归不同的工艺），这些零部件再向下分布在几十家供应商手里，有的工厂只做单一零部件、有的负责组装，链路本身类似一张密度不低的矩阵。再叠上时间维度，几十个 SKU 同时在不同生产阶段（打样、量产、验货、发货），各家节奏不一，沟通也天然异步。

其次字段层面差异也很大，不同品类的质检项基本是几套完全不同的东西（家居收纳看尺寸精度和五金牢固度，电子产品要测通电和老化，户外品类又关心防水耐候），不同卖家的合同条款、付款节奏、质检偏好也都不一样。再加上很多关键凭证以图片、视频这类非结构化形式存在于微信群。这些东西综合起来，没法用一张统一表单覆盖。

3.2、ERP 厂商也不愿接这块

反过来从供给侧看，传统 ERP 厂商有自己的路径依赖。他们的商业模式上最大的约束条件来自人力和开发成本，所以业务越做大、越倾向于聚焦订单、库存、广告报表这种高频、能跨客户复用的标准模块。原因也很好理解，一方面是成本算的清楚，其次标准模块的开发投入可以摊给 N 个客户去复制使用。

鉴于供应商履约这种深度定制的非标流程很难复制，加上中小型精品卖家这一档的付费意愿和付费能力都没有大客户那么强，让一个年销几千万的卖家一次性掏几十万去做一套高度适配的系统，多数老板我想都会犹豫。两头对不上，所以卖家这里这块长期只能靠人盯。

4、方案实现过程拆解

4.1、需求与产品定义

换个角度看，供应链履约这一段的复杂度并不是均匀分布的。里面有一部分是相对稳定的主线，几乎每家精品卖家都长得差不多；另一部分才是真正非标的，会随着每家卖家、每个品类、每个 SKU 不同而不同。

把前者抽出来变成主数据加自动化，能覆盖大概一半的工作量；后者留给业务人员手工填，配合合适的工具承接。这也是整个产品形态成立的前提。

如何用两份主数据收敛复杂度

数据这一层的复杂度其实不在产品本身，而在多级映射关系。一个亚马逊 Listing 下挂多个 SKU，每个 SKU 由若干零部件组装而成。一个零部件归一家供应商做，一家供应商可能同时承接多个产品的多个零件，构成一张多对多的网。

这家朋友团队目前在售十几款产品、大几十个 SKU、合作小几十家供应商，背后大几十条零部件关系，了解下来也算是典型的中型卖家的实际规模。

角色这一层分布会更分散。甲方内部分管理员、供应链负责人、跟单员几类；工厂分两类，一类只做单一零部件（生产型），另一类既能生产又能承担组装入库（综合型），每类内部又有老板、厂长、跟单等角色；再加上每次都可能不同人的临时司机。所有可能的活跃角色加起来差不多有十种，分散在不同地区、不同微信群里。

状态这一层最容易被忽略，但实际上测试下来发现最难搞。一张合同会被拆成多个交付批次，每个批次又包含多个零件类型，每个零件独立流转。同一时刻里，一份合同下面可能某些零件已经验货通过等发货、某些还在生产、某些上次质检没通过被退回重做。

为了便于理解，可以参考下图再对照看下：

仔细看会发现，复杂度里相对稳定的那一部分可以被抽象出来，比如产品和零部件的从属关系、零部件和供应商的归属关系、合同到批次到零件的状态流转。这些几乎每家精品卖家都长得差不多，我也在初期选型的时候决定把它们抽出来变成两份主数据。

其中第一类主数据是供应商部分，每家供应商在系统启用前都需要建一份完整档案，包含工商信息、银行账户、收发货地址、内部成员和细粒度权限。最关键的两个字段是这家供应商旗下做哪几种零件类型，以及它本身是否具备组装能力，这两个字段决定了后面下单、发货、收货的自动路径。

产品 BOM 主数据是其二。每款产品在系统里展开成 Listing → SKU → 零部件三层映射，每个零部件挂到对应的零件类型和供应商上。这条引用链一旦建好，相当于把整个生产网络的拓扑都写进了系统。

这两份主数据建好之后，下单这一步就能尝试做自动化。甲方在 PC 上选一款产品、按 SKU 填采购量，系统自动按 BOM 把每个 SKU 拆出零部件清单，按零件类型反查到对应供应商，再按供应商分组拆出 N 份独立的合同草稿，每份合同对应一家供应商。整个过程不需要人工选哪家工厂做什么。数据和角色两个维度的复杂度，到这里被这两份主数据吃掉了一大半。

三端 + 一套云函数

主数据建好之后，前端怎么分、后端怎么搭就更加清楚了些。整套系统的三层结构如下：

三端分开是因为用户场景天然分散。甲方（亚马逊卖家）人员在办公室处理大量复杂列表、合同 Word 导出、PDF 归档这类事情，桌面屏才放得下，所以是 PC。

工厂里的供应商老板、厂长、跟单员日常挂在微信里，桌面电脑不一定常开，小程序入口在微信里、加上服务通知能直接推送，使用门槛比浏览器低很多，所以这一段走小程序。

临时司机每次可能都不同人，让对方专门为这一单装小程序、注册账号不现实，所以做成 H5，扫码即用，本质是过去纸质单据的线上化升级。

后端选了微信云开发。给不熟悉的盆友简单解释一下云函数，可以理解为你不用买服务器、不用管运维、不用配证书、不用搭数据库，就写一段 JavaScript 函数扔上去，自动接收请求、自动按流量扩容、按调用次数算钱。

微信云开发个人版一个月 19 块就能基本覆盖这家朋友团队目前的全部业务量，且这个价格里已经把云函数、云数据库、云存储都包进去了。自建一套等价的环境每月至少几百到上千，且要花精力维护，对这种业务规模来说不划算。

另一个隐性好处是小程序天生就有微信侧身份鉴权，云函数能直接拿到，省了一整层登录系统的开发量。PC 和 H5 没有微信身份，但和小程序共享同一套云函数，三端代码量降到最低。

最后，权限分层从一开始就要做好。甲方走模块授权，按产品、合同、质检、库存这类模块独立可授可不授；供应商走动作授权，按看不看合同金额、能不能创建发货单、能不能确认收货这类具体动作勾选。两套模型分开做的原因是甲方更看重模块边界，供应商更看重动作边界。

走一遍完整链路

前面交代了主数据和产品形态，不过最直观的方式还是按一批货从下单到出货代的完整链路走一遍，把它们落到具体动作上，可能才更好理解些。整条链路大致归到五步上，每一步都有明确的状态字段和路由接口对应：

第一步：下单与合同。甲方在 PC 上选好产品和数量，系统按 BOM 自动拆解、按供应商分组拆出 N 份合同草稿，乙方信息、产品明细和单价从主数据带出，付款比例和交付批次的日期由甲方填。供应商在小程序在线确认无误后，甲方导出 Word 走线下盖章，签好的 PDF 上传回系统归档。

上传已签 PDF 还会顺带触发一件事，系统会按合同里的交付计划自动生成多个交付批次，每个零件初始状态是待生产，供应商进自己的小程序工作台就能看到要做什么、多少件、什么时候交付。

第二步：生产与验货。供应商完成生产后在小程序点已生产，零件状态推到待验货。甲方收到提醒后可以在 PC 集中处理，也可以让在外面跑工厂的跟单员或第三方质检员直接在小程序提交。

验货结果分通过、部分通过、不通过三种，通过推到待发货，不通过退回整改。这里的关键是状态管到零件颗粒度，同一份合同下面可能某些零件已经待发货、某些还在生产、某些验货失败正在整改，每一步都有时间戳和状态字段，往回追溯有据可查。

第三步：发货与司机交接。供应商对验货通过的零件在小程序发起发货，目的地系统按规则自动过滤：综合型工厂做的是成品发往货代，生产型工厂的零部件发往综合型工厂。如果实际数量和合同计划有偏差，供应商必须填写修改原因，发货单进入待甲方确认状态，甲方在 PC 上确认后才放行。

司机这边没有登录、没有账号，二维码里带一个一次性 token，扫码进 H5 输入姓名、车牌、手机号，系统自动获取 GPS 作为接单证据；到了现场之后再扫同一个二维码，签名加装车照加再获取一次 GPS，发货单进入在途状态，一两分钟做完就走。

第四步：综合厂收货与入库。货到了综合型工厂，工厂用小程序点确认到达、拍现场收货照。这一步会同时把发货单里的零件清单写进库存表和库存调整流水，收货等于自动入库。综合型工厂在系统里维护两份库存，从生产型工厂来的配件库存、自己包装好的成品库存。

第五步：成品出货代。综合厂完成包装组装后再次发起发货，目的地是货代地址，司机交接流程和第三步一样。货物到达货代仓后，由甲方跟单员在 PC 上确认到达。

到这里一批货就从下单到出货代完整闭环了一次。中间任何一个节点出问题（供应商延期、质检不通过、发货数量异常、司机签到信息缺失、组装厂收货后发现差异），状态字段会停在那一步，相关角色的工作台都能看到。

4.2、工程与技术实现

整套系统的技术栈大致包括：PC 端 Vue 3 + Element Plus + Vite + Pinia；小程序走原生开发（不用 uni-app，跨端框架的小程序适配层有不少坑）；司机 H5 用纯 HTML + CSS + JS（一次性场景，加载越快越好，引一个框架白增加几十 KB）；后端 Node 16 + 微信云数据库 NoSQL，一共 20 个集合。

代码量方面 PC 约 670 KB、小程序约 660 KB、云函数约 330 KB。下面挑 4 个我个人觉得做下来比较有意思、且换个场景做别的项目也能直接用得上的工程取舍展开讲。

单入口 serverless 函数 + 自维护路由表

整个后端业务接口大约 90 多个、分布在 19 个模块里（auth / contract / order / batch / shipment / inspection 等），但它们全部挂在一个云函数 api 下。前端调用约定是 callFunction({ name: 'api', data: { action: 'contract.create', token, params } })，云函数入口拿到 action 字符串后从路由表里查到对应 handler 来执行。路由表本身把 19 个模块的 export 平铺合并成一个大查找表，O(1) 查表分发。

代码层面，整个路由分发其实就是这么几行：

// router.js  路由表 = 各模块 export 平铺合并
const routes = {
  ...require('./routes/auth'),       // { 'auth.smsLogin': fn, 'auth.me': fn }
  ...require('./routes/contract'),   // { 'contract.create': fn, 'contract.list': fn, ... }
  ...require('./routes/order'),
  // ...总共 19 个模块
}

exports.dispatch = ({ action, params, auth }) => routes[action]({ params, auth })

这个做法和 serverless 教科书答案是反着来的。传统做法会让你 function-per-handler，每个 action 一个独立函数，看起来更像微服务那一套。但小团队场景下这个答案有两个明显成本，一是 serverless 平台的冷启动惩罚以函数粒度计算，每个函数第一次调用都要 1 到 3 秒延迟，动作越多冷启动碎片越严重；二是部署、监控、日志、权限都要按 N 个函数管理，运维心智成本无疑会变重。

单入口路由的考虑是把这两个成本压成一个。这条路子换到 Cloudflare Workers / Vercel Functions / AWS Lambda 这些 serverless 平台上同样成立。小团队跨业务模块的项目，一开始不要被微服务那套叙事带着走，先用单入口 + 路由表跑起来，等某个模块流量真的撑到瓶颈了再单独拆出去。

模板占位符 + 结构化数据驱动文档导出

合同正文涉及到的字段大致有六大块：甲乙方信息、产品明细表、规格说明表、付款条款、交付计划、签章区。系统里这些字段全部是结构化存储的（buyer_info / supplier_xxx / product_items / delivery_rows / clause_sections），导出 Word 时按模板占位符依次填充：甲方信息从平台模板带、乙方信息从供应商主数据带、产品明细从 BOM 拆解出来、付款条款从默认条款模板带、交付计划由甲方手填。

图片链接：做了个年销几千万的亚马逊卖家供应链履约系统：从需求拆解到OpenClaw微信集成的完整复盘

合同正文在系统里的内部表达其实就是一个普通对象：

// 合同正文 = 各数据源拼装出来的结构化对象
const contract = {
  buyer_info: createBuyerInfo(),                                  // 甲方固定模板
  supplier_legal_person: org.legal_person,                        // 从供应商主数据带
  supplier_bank_account: org.bank_info.bank_account,
  product_items: buildProductItems(bomItems),                     // 从 BOM 拆解
  clause_sections: createClauseSections({ depositRatio: 0.3 }),   // 默认条款
  delivery_rows: [createEmptyDeliveryRow()],                      // 甲方手填
}

这件事最直观的反面是用富文本编辑器，富文本上手快、编辑顺手，但产出的是一坨 HTML 或者 Markdown，下游做不了任何结构化处理。比如合同金额变了没法自动重算、供应商改名了没法同步更新、签署后想做快照比对完全没着力点。

虽然结构化字段加占位符渲染前期投入重一些，但下游所有自动化都能挂上去。前面讲过的合同状态机、签署后自动生成批次、快照存档这些联动，全部依赖于合同正文是结构化数据。

这个思路也可以直接迁移到任何 to B SaaS 涉及模板化文档输出的场景，比如保险公司的保单、律所的协议、企业内部的报价单、外贸订单、跨境物流的报关单。判断标准很简单，看下游需不需要对这份文档的字段做自动化的事情（比对、联动、统计、改版），需要就用结构化加占位符，不需要就富文本省事。

嵌入数组 + 局部状态机

交付批次集合 delivery_batches 每条文档代表一个批次，里面 parts[] 是一个嵌入数组，每个元素是一个零件，独立维护自己的 status 字段。比如一份合同被拆成三个交付批次，每个批次里有金属支架、塑料卡扣、彩盒三类零件，那这个批次文档里 parts 数组就是三个对象，每个对象有自己的 part_type_id、planned_qty、actual_qty、status。状态推进时只更新这一个 part 的 status 和 status_updated_at，整批其他零件不受影响。

状态推进的核心代码也就是这几行：

// 标记某个零件已生产，只动这一个 part
async function markProduced({ batchPartId, actualQty }) {
  const { batch, partIndex } = await findBatchPartById(batchPartId)
  batch.parts[partIndex] = {
    ...batch.parts[partIndex],
    actual_qty: actualQty,
    status: 'PENDING_INSPECTION',
    status_updated_at: new Date().toISOString(),
  }
  await db.collection('delivery_batches').doc(batch._id).update({ data: { parts: batch.parts } })
}

当然，这个模式也可以迁移到任何父对象包含 N 个子对象、每个子对象独立流转的场景。比如一个订单包含多个商品行，每个商品行独立履约；项目包含多个子任务，每个子任务独立完成；合同包含多个条款，每个条款独立审批。

关系型数据库下通常会拆成父子两张表加外键，读取要 join、写入要事务；NoSQL 下嵌入数组方案读取一次拿全、写入是单文档原子操作。代价是 parts 数组不能太大（几十个还行，几百个就不合适了，因为整个文档每次都要读写一遍），所以这条经验有边界。

一次性 token 替代账号体系

司机 H5 没有登录、没有账号、没有微信身份。所有交互靠发货单创建时生成的一次性 token（h5_token）作为凭证。供应商在小程序点创建发货单，云函数生成一个 token 写入 shipment_orders 集合，二维码里就带这个 token。司机扫码进 H5 后，所有云函数 action（h5.shipmentInfo / h5.driverStep1 / h5.driverStep2）都拿这个 token 反查发货单做凭证校验。

更关键的一个设计是同一二维码可以反复扫。每次扫描会根据当前发货单 status 决定司机这次能做什么：status 是 CREATED 就让司机做第一步（登记姓名、车牌、GPS），status 是 VEHICLE_DISPATCHED 就让司机做第二步（签名、装车照、送达），status 是 IN_TRANSIT 就告诉司机这单已经在途、不能再操作。换句话说，token 是身份，业务状态机决定流程。

代码上的体现：

// H5 入口：token 即凭证，按发货单 status 分支
async function driverStep2({ params }) {
  const shipment = await getShipmentByToken(params.token)
  if (shipment.status !== 'VEHICLE_DISPATCHED') {
    throw new Error('当前状态不允许提货')
  }
  await db.collection('shipment_orders').doc(shipment._id).update({
    data: { status: 'IN_TRANSIT', driver: {
      signature_file_id: params.signatureFileId,
      loading_photo_file_id: params.loadingPhotoFileId,
      step2_gps_lat: params.gpsLat,
    }}
  })
}

这个组合（一次性 token + 状态机驱动）能直接迁移到任何临时用户加一次性参与加不能装 App 不能注册的场景，像扫码点餐、外部审批确认、问卷调研、临时账号、扫码报修。比起每个动作签发独立 URL 的做法，状态机驱动有几个明显好处：现场断网刷新不会断档、用户切设备继续操作不影响、流程多一步少一步只需要改后端状态机、不用前端管理一堆 URL。轻交互场景里这套思路用起来很顺手。

5、OpenClaw 微信通知集成

5.1、OpenClaw 是什么、和这套系统怎么连

前面把 PC、小程序、H5 三端加云函数这条主链跑通了，但小程序的入口还是略深了些，所有的状态变更和待办都需要用户主动打开小程序、登录、查看。供应商负责人、厂长、跟单员一天看微信几十次，如果能直接在微信里查询和处理，使用门槛能再降低不少。这也是系统开发完之后为什么又加上了 OpenClaw 这一层的初衷。

得益于 OpenClaw 的微信插件，可以让 OpenClaw 登录一个真实的个人微信号、在后台代替这个微信号自动收发消息。整套机制下，只需要一个微信小号专门跑在服务器上作为代收发渠道，每个真实用户用自己的微信加这个小号为好友、各自完成绑定，后续推送和指令交互都通过这个小号中转。也就是说，服务器侧只需要维护一个代收发小号，用户侧 N 个人各自用自己真实微信绑定，是多对一的关系。

最外层是真实用户的微信，每个用户和代收发小号之间走的是普通的微信好友关系，发消息收消息和平时给同事发消息没区别。中间一层跑在腾讯轻量应用服务器上，包含三块：代收发小号本质是个真实微信账号、由 OpenClaw 登录、消息进出由插件代理；OpenClaw 加微信插件对外只监听 127.0.0.1 本机端口、不开公网。

桥接服务是个 Node.js 进程、systemd 托管，一边连 OpenClaw 拿微信消息和会话上下文，另一边调云函数完成业务逻辑。最里层是云函数 openclaw.* 模块和云数据库，负责绑定关系、通知队列、推送状态的存储。

整体看，OpenClaw 这一层就是消息出入口，所有业务事实仍然落在云数据库里。这个边界很重要，OpenClaw 不替代系统事实源，PC、小程序、H5 仍然是关键操作的入口，OpenClaw 做的事情是把信息送到用户面前、把用户的轻量请求接回系统。

5.2、整套链路怎么跑通的

具体到链路实现，OpenClaw 这一层做的事情可以拆成三段：用户绑定、主动推送、指令响应。

用户绑定。一个甲方账号或供应商账号要收到微信通知，第一步是把这个系统账号和某个真实微信号关联起来。流程是这样：管理员在 PC 后台找到那个用户，点生成绑定码，系统返回一个 6 位数字，有效期 30 分钟。用户拿到这个绑定码，比如在自己微信里给那个代收发小号发一条 绑定 123456。桥接服务从微信侧拿到这条消息，调云函数 openclaw.consumeBindingCode，云函数校验绑定码、把这个微信号的 peer_id 和 session_key 写到这个用户的 users 文档里。后续这个用户在系统里产生的任何通知，就能找到对应的微信号了。

绑定的核心代码就是几行：

// 云函数侧：消费绑定码，把微信会话信息写进用户文档
await getCollection('users').doc(user._id).update({
  data: {
    openclaw_binding: {
      status: 'bound',
      peer_id: wechat.peer_id,
      session_key: wechat.session_key,
      bound_at: now,
    }
  }
})

主动推送。这部分是 OpenClaw 这一层最核心的价值。系统里每个关键状态变更都对应一个通知：合同推送给供应商确认、发货数量待甲方确认、司机已接单、货物到达组装厂这类。业务模块在状态变更时调一个统一的 helper safeCreateNotification，往 notifications 集合里写一条记录，状态字段是 wechat_push_status: 'pending'。桥接服务每 15 秒轮询一次云函数 openclaw.pendingNotifications，把所有 pending 状态的通知拿出来，按 user_id 查到对应用户的微信绑定，通过 OpenClaw 微信插件发出去；发完了再调 openclaw.markNotificationPushed 把状态改成 sent。

业务模块要让一个状态变更触发微信通知，调用层面也就一行：

await safeCreateNotification({
  type: 'shipment_needs_confirm',
  title: '发货数量待确认',
  content: `${doc.shipment_no} 存在数量调整，待甲方确认`,
  receiverRole: 'admin',
  targetType: 'shipment',
  targetId: addResult._id,
})

指令响应。这一段是双向的：用户主动发指令、系统返回结果。当前桥接服务能识别三个固定指令：绑定xxxxxx 完成绑定、我的待办 返回最近 5 条未读通知、帮助 或 help 返回可用指令清单。桥接服务收到消息后会先做正则匹配，匹配到指令就调对应的云函数 action，把返回结果再通过微信插件发回去。指令解析的代码也就这么几行：

function parseIncomingText(text) {
  const trimmed = String(text || '').trim()
  if (/^绑定\s+\d{6}$/.test(trimmed)) return { type: 'bind', code: trimmed.match(/\d{6}/)[0] }
  if (/^(我的待办|待办|todo)$/i.test(trimmed)) return { type: 'todo' }
  if (/^(帮助|help|\?)$/i.test(trimmed)) return { type: 'help' }
  return { type: 'unknown' }
}

下面录屏覆盖了几个真实场景下推送、查询的实际效果：

视频链接：https://mp.weixin.qq.com/s/TCGwJd8vc4lVjCUgZBKWjw

5.3、现在实现到哪、还有哪些没做

整套链路本质上是个消息总线，业务事实在云数据库里、状态变更通过 safeCreateNotification 进队列、桥接服务把队列里的内容送到对应用户的微信、用户能用固定指令反向查询。这条线已经跑通。

但当前覆盖范围还有限，主要接在履约主链上对时效敏感的几处节点（合同推送供应商确认、发货数量待甲方确认、司机已接单、货物到达），剩下的节点钩子代码里基本都埋好、但还没完整跑通联调。指令解析也是写死的三个正则匹配，自然语言对话、主动巡检、图片语音反向上传这几个方向都是同一套架构往前再推一步就能做的，工程量不大。

最后想强调一下 OpenClaw 这一层在整套系统里的定位，它不是事实源，唯一做的事情是把消息送到用户面前、把用户的轻量请求接回系统。另外对于跨组织协作的业务系统来说，关键操作（合同签署、数量确认、库存调整）必须保留人工的审批权和系统的状态机。这一层的真正价值是降低信息流转成本和操作门槛，而不是直接绕开人工判断。

6、写在最后

跨境电商这门生意里其实从来不缺工具，选品有 Helium 10、Jungle Scout，广告投放有亚马逊自家加各种第三方 SaaS，店铺管理有成熟的 ERP，仓储发货有海外仓配套服务，几个人的小卖家完全用得起。但真正没有被工具承接的恰恰是后端的供应商履约这一段，前面第三章也大致分析了这块工具市场为什么长期空白。站在卖家自己的角度，这也意味着一个不平衡的格局，前端越来越自动化、后端越来越靠人盯。一旦前端工具差距被拉平，真正决定卖家能不能做大做久的，就是后端这块。

回到 AI Coding 的话题，它的确把 PoC 这一步的边际成本压缩到了忽略不计。跑通一个原型这件事三年前可能需要好几个人天，现在一个人几个小时就够了。但要从 PoC 走到生产级、能稳定运行、能往工具化产品化方向延伸，需要的还是严格的需求抽象、技术选型、流程取舍和工程判断。我在这次开发过程里的每一个流程怎么切、每一个状态字段怎么定义、每一个权限怎么分配，背后都依赖业务方手里那些非常具体的行业经验和我作为外部技术服务方对这一类系统的工程判断。AI Coding 没让这些事变简单，只是让做这些事的人不用再为基础设施和大量重复劳动付出传统的时间代价。换句话说，AI Coding 是个杠杆，但放大的仍然是已有的能力。

最后想稍微跳出这个项目来收尾，亚马逊作为跨境电商平台给国内卖家提供了一种很特殊的杠杆，和纯软件 OPC 不一样，跨境电商这条路上做的是实物买卖，背后是真实的供应链、真实的工厂、真实的物流。这门生意下过场的人很多，但真正能挣到钱的应该不算多。能长期经营的卖家不见得是技术最强或最早入场，而是把后端那段重业务管得明白的人。这件事反过来对现在做 PoC 的独立开发者其实也算是个参考。一个工具周末就能上线，但越是容易复刻的东西越难形成真正的积累。从这个角度来说，对于现在转型 OPC 的盆友，与其和别人拼谁先做出一个工具，不如先想清楚自己手里有哪段是别人不容易复刻的，可能是某个传统行业里几年的工作经验、可能是对某类用户群体的体感、也可能是和某类合作方多年打交道的关系网。找到这部分有真实积累的方向，再用 PoC 工具把它显式化做出来，那种 PoC 或许才更有继续走下去的可能。

这一版POC的三端源代码我会发布在知识星球里供参考（视频课程暂不会同步），代码已经做过必要的脱敏处理，本地搭好环境就能直接复现。如果想往正式生产环境使用，还需要自己采购微信云开发、一台轻量应用服务器、独立域名以及短信服务等。另外如果有哪位盆友也在亚马逊上做精品自营、或者手头有类似的供应链管理需求，也欢迎找我交流。