新西兰 AI 技术落地实践案例：一家跨境保健品零售企业，从微信群下单到顺丰面单的一百天

这篇新西兰 AI 落地案例的主角是一家跨境保健品零售企业：新西兰 5 家门店和一个本地网店，中国侧走天猫、京东、拼多多、抖音等十余个渠道，卖奶粉、保健品和蜂蜜，国际物流以顺丰为主。合作前，国内日销靠人看截图、逐条录进 Excel；顺丰下单靠一位业务员把微信群里的订单先抄进总表，再复制到下单模版导入系统。2026 年 6 月 4 日启动，9 月 9 日顺丰开始主动推送面单。下面用图讲这一百天。

原来一笔订单要抄几遍？

7 月 24 日，客户方负责顺丰下单的业务员这样描述自己的工作：“微信订单下做到总表里记录各种信息用的，然后复制内容到下单模版，导入顺丰系统。”一笔奶粉订单从微信群到顺丰面单，要经过人手五次。

对照图：原来业务员手工五步（认单、抄总表、复制模版导入、证件手工存档、逐张回传单号面单）；现在一句话加一次确认（@智能体、拆单映射、人核对四项说审核通过、建单归档回写、顺丰推送面单） — 合作前后对照。右侧唯一需要人做的，是核对四项后说一句“审核通过”。

一百天发生了什么

6 月 4 日启动，先做三个数据场景；7 月底因为电商平台 API 的合规规则换路线，转做顺丰下单；8 月 26 日顺丰接口接通；9 月 9 日面单回调打通；9 月 10 日转入陪跑。

一百天时间线：6.4 项目启动、7.9 首月复盘、7.28 换路线、8.5 微信号接入、8.26 顺丰 API 接通、9.2 生产首单、9.9 面单回调打通、9.10 转入陪跑 — 八个节点，每个都有群聊记录可查。

第一个月：先做最小的事

第一阶段只做三件事：群消息检索、国内日销报表、门店日报。四周一个闭环，第二周就拉客户进测试群。7 月 9 日首月复盘时定下一条后来反复被验证的共识：第三方接口只是原子能力，“不存在有接口即可直接使用的情况”。

首月落地计划：第一周开发与模拟数据测试，第二周进入测试阶段并拉群邀请客户，第三周测试迭代，第四周给客户落地项目 — 6 月 9 日的首月计划。目标写得很朴素：快速让客户感受机器人作用，解决眼前数据问题。

首月已落地场景总览：群消息检索已完成、全国日销售额录入汇总待微信接入、NZ 门店日报测试中、Gmail 基础能力已完成；下方为四个阶段的计划、实际、差距与处理 — 7 月 9 日首月复盘：四个场景的状态，以及每个阶段“计划、实际、差距”的对照。

两道坎：微信号与平台 API

让智能体读微信群，微信号得长期登录在一台在线的机器上。微信对异地和多端登录风控很严，双方配合了近一个月，8 月 5 日专用号才稳定接入。这段经历变成了我们所有微信项目启动清单的第一条。

客户希望直接接淘宝、视频号的 API。研究一周后发现平台要求申请方持有与店铺主体一致的软件著作权，本地部署的智能体拿不到。7 月 28 日换路线：国内日销保持“人报数、机器人记”，开发资源转向顺丰下单。

微信号接入四个前置条件：注册满三个月且长期在国内登录、注册人能配合验证、云端与本地不同时登录、先在测试群跑通再迁入客户环境 — 一个月的拉锯换来的四条前置条件。

电商平台 API 三条路线：直接申请需软著且主体一致（不可行）、借 ERP 或服务商通道（短期不可行）、选择截图识别加顺丰直连 — 7 月 21 日到 28 日的判断：一周研究清楚，然后换一条路。

一笔订单的旅程

8 月 28 日测试环境首单，9 月 2 日生产环境首单。整条链路里只有一个节点必须由人出手：核对收件信息、商品、付款、证件四项后，对智能体说“审核通过”。没有这句话，智能体不会调用顺丰的生产接口。

订单旅程流程图：微信订单原文→智能体解析拆单→核验卡片→人审核通过→顺丰 ISCO 建单→证件归档 NAS→顺丰面单回调→回写多维表格 — 八个节点，金色的那个是人。

飞书群截图：工程师回复“核验通过，无需付款，无需证件”，智能体回写工单并指出唯一卡点是确认 6 袋是否为 1 个履约单元；确认后智能体成功出单 — 8 月 31 日的一次真实往返：人说“核验通过”，智能体只剩一个问题“6 袋是不是 1 个履约单元”，人答“一单 6 袋”，它才出单。人名与单号已打码。

飞书群截图：智能体回复“接单拉运单成功”，返回运单号与尾程单号，并注明顺丰未返回面单地址 — 8 月 26 日顺丰接口接通当天：运单号拿到了，面单没有。面单这件事接下来卡了两周。

面单为什么拿不到

对跨境电商，面单是给客户的收据，拿不到等于没做完。顺丰的机制是仓库拣货装箱、出库审核通过后才生成面单，出库前接口查不到，网页能看到也查不到。最终方案是顺丰主动回调：9 月 9 日晚生产环境打通，9 月 11 日面单路径开始自动填进工单。

面单机制流程：创建出库单→仓库拣货装箱→出库审核通过后面单生成；反复查询接口行不通；最终方案顺丰主动回调推送 — 建单和拿面单是两个独立动作。

顺丰对接群截图：顺丰方解释面单以实际仓库打包出库为准，涉及拆单换单会变，接口只在最终打包装箱出库后回传面单 url — 8 月 31 日顺丰对接人的解释：面单以实际打包出库为准。群名、人名与头像已打码。

一次“假失败”

9 月 2 日晚，一单数量从 1 改成 6，取消重建后接口报“无库存”，工单被标记失败。智能体自查发现重建时误换了 SKU，回查顺丰：单其实已建好、运单已生成。它的结论写进了工作流规则：“请勿再次重试或再建单，避免重复发货。”

假失败时序：19:35 取消并重建→19:48 接口报错标记失败→19:57 智能体自查误换 SKU→19:59 回查顺丰已真实建单→结论勿重试 — 系统报错不等于顺丰没建单。任何报错先用交易号回查对方系统，再决定是否重试。

一个改错了一个月的公式

7 月 30 日，客户希望利润计算的成本口径从“平均成本”改成“最新成本”，我们改了公式。日报每天 21 点准时发出、格式完整，没有一个环节报错，利润率却在 74% 到 96% 之间停了一个月。8 月 29 日客户看数据时提出偏高，9 月 1 日修复。教训在我们：改核心公式时没有同时设“超出正常区间就报警”。

利润率折线图：7 月 30 日 18.28%，7 月 31 日起跳到 85%，8 月整月 74% 到 80%，8 月 29 日 74.31%，9 月 1 日修复后 20.46%，正常区间 17% 到 24% — 日报显示的利润率，数值取自当日日报卡片。

飞书多维表格门店日报截图：五家门店的 Profit Margin 列显示 77.82%、79.74%、74.65%、74.71%、60.69%，合计 74.31%；门店名与金额已打码 — 8 月 29 日当天的日报。表格完整、准时，正是它看起来正常，才一个月没人看第二眼。门店名与金额已打码。

机器人为什么会“忘事”

对话越长，早期约定的规则越可能在自动压缩时被丢掉。“不是忘了，而是已经看不到了。”所以规则要写进技能文件和多维表格，不能只留在聊天里。这张 6 月 12 日发给客户的图解，后来成了我们所有项目的默认说明。

八格图解：用户提问门店编号，机器人从早期对话中找到并回答；聊天很多轮后系统自动压缩，摘要保留大意但丢掉具体编号；下午再问答不出来；真相是它不是忘了，而是看不到了 — 上下文压缩机制图解。解法是把规则写进文件。

合作方式：第一季度做一条，之后教着做

第一季度全托管，搭建、调试、对接由我们完成；第二到第四季度陪跑，我们出方案、答疑、复盘，落地由客户团队自己完成。目的是让客户长出自己用 AI 的能力。顺丰下单是客户说清“真正占人力的环节还没释放”后加进第一季度做完的，这就是“先做一条、做透一条”。9 月 10 日起，我们做教练。

服务阶段对比表：Q1 全托管，服务商完成所有搭建调试对接；Q2 到 Q4 陪跑，只输出方案与答疑，落地由客户自行完成 — 7 月 9 日首月复盘纪要里的服务边界表。

五条教训

回头看，最难的部分没有一件是模型能力。

前置条件先于开发：合规的专用微信号要提前一个月准备，写进启动清单第一条。
合规卡点要早判断：一周研究清楚然后换路，比拖三周好。
建单和拿单据是两件事：面单在出库后才生成，靠对方回调，不靠我们轮询。
系统报错不等于事情没发生：任何报错先用交易号回查，再决定重试。
核心公式改动要有阈值校验：改公式的同时设报警，这是我们自己该做到的。

现在怎样了？

9 月 11 日，微信下单、核验、出单、证件归档、面单回传的日常工单在正常跑。客户方运营人员开始提下一步：让机器人每一两小时出一份下单总表，面单批量下载；十几个客户每天要更新的账单表也想交给机器人。国内日销和门店日报每天 21 点准时发出，利润率回到正常区间。

证据边界：本文数字与引文来自项目群聊记录和 7 月 9 日、9 月 1 日两份会议纪要，日期均已标注。门店与渠道的日销售额不写具体数值；顺丰交易号、订单号、运单号、证件与收件人信息一律未采用。客户为新西兰跨境保健品零售企业，已匿名；截图中的公司名、人名、头像与单号已裁除或打码；示意图为本文绘制。

一手参考

顺丰速运（官网） ↗飞书多维表格（官方产品页） ↗

FAQ · 快速回答

新西兰跨境电商的 AI 落地案例里，微信群下单能自动生成顺丰面单吗？

能，分两步。智能体把微信群里的自然语言订单拆单、核验、调用顺丰 ISCO 接口创建出库单，几分钟完成；面单要等顺丰仓库拣货装箱、出库审核通过后才生成，由顺丰通过回调主动推送，智能体再归档并回写表格。“下单即出面单”在顺丰的机制下做不到。

这个案例里 AI 做哪一步，人做哪一步？

AI 做：解析订单、映射 SKU、拆单、生成核验卡片、归档证件、调用顺丰接口建单、回写单号和面单、汇总日销与门店日报。人做：核对收件信息、商品、付款、证件四项后说“审核通过”；判断是否需要清关证件；报错时决定是否重试。没有人工指令，智能体不调用顺丰生产接口。

需要换 ERP 或换微信、飞书吗？

不需要。客户的 ERP、顺丰 ISCO、微信、群晖 NAS 一个都没换，智能体跑在客户自己的 Mac mini 上，用 OpenClaw 做调度，数据落在客户自己的飞书多维表格里。唯一新增的是一个长期在国内登录的专用微信号。

微信下单到顺丰出单多久能跑通？

这个项目 7 月 31 日确定顺丰范围，8 月 26 日接口接通，8 月 28 日测试环境跑通，9 月 2 日生产首单，9 月 9 日面单回调打通，约 6 周。开发本身不到一半，其余时间花在顺丰正式环境参数、面单机制确认和微信号接入上。

BEE Sigma 落地团队

把工作流真正接进企业现有系统的一线交付团队，方法来自已交付项目。

新西兰 AI 技术落地实践案例：一家建筑公司的工地工时管理，从 Excel 到飞书群与成本看板的三个月

新西兰 AI 技术落地实践案例（建筑业）：一家南岛建筑施工公司，工时靠工头下班后回忆、Excel 汇总，项目信息散在微信群和邮件里。三个月后，工头在飞书群里说一句话，智能体写进日工时明细，老板在成本看板上看到 20 个项目、1 万多小时工时、334 条日常记录。这篇实录写的是中间那三个月：第一个月卡在稳定性、客户说“AI 改进太小”、上线后天天靠人抓数据错误。

阅读全文

AI 落地案例 · 新西兰建筑内容复核 2026.09.1111 分钟

新西兰 AI 技术落地实践案例：一家建筑公司发票自动分流 91% 的三个月实录

新西兰 AI 技术落地实践案例（建筑业）：供应商发票每月 500 到 1000 张，一位工料测量师手工分类、匹配采购单、提交审批。三个月后，一个完整会计月里 798 份发票文档中 730 份由 AI 自动识别分流，人工复核降到 68 份。这篇实录写的是中间那三个月：识别率不是问题、发票总数对不上、以及客户真正要的是什么。