01
为什么要折腾这个工作流？
做建筑建材供应链的朋友都懂，微信群早就成了“临时接单系统”：
“广州建采绿碳：C30商混50方，珠江新城A3地块，明早7点前到。联系人老李 13500001111。”
看起来只是一句聊天消息，背后其实是一条完整的订单信息。
传统做法是——人眼识别 → 打开表格 → 手敲字段。
累不说，项目多的时候还特别容易混淆信息。
我这次的目标很简单：
- 群里发一句话；
- AI 自动帮我“读懂”内容；
- 自动把订单写进飞书多维表格；
- 最好还能校验一下，少字段就不给过。
一句话总结就是：把微信群，从“聊着玩”升级成“轻量级接单入口”。
02
整体设计思路：一条小型“订单流水线”
整条链路工作流一共 6 个节点：
1）开始节点：接微信群的订单信息；
2）大模型节点：把原始中文订单转成 JSON数据；
3）代码节点：校验字段 + 规范交期 + 组装需写入多维表格的数据；
4）选择器（IF）节点：关键数据是否存在，存在则进入下一步，否则结束；
5）飞书多维表格节点：调用飞书多维表格 API 写入记录；
6）结束节点：把执行结果返回前端。
其中，真正关键有两个点：
- 大模型输出的数据要和飞书多维表格的表头一一对上号；
- 代码节点要把大模型输出的数据打包成飞书多维表格插件能直接吃的格式。
只要这两件事处理好了，剩下的就是“流水线开关”的问题了。
03
节点参数设置
1、开始节点：负责把微信群的订单信息传进来
• raw_text（String）：微信群里那句原始订单文案；
• msg_id（String）：这条消息在外部系统里的唯一 ID（后面会写回到表格里，方便追溯来源）。
2、大模型节点：从一句话到 JSON 订单
大模型节点输入变量只有一个：
• input （String）← 开始节点的 raw_text。
系统提示词给它定了一个很明确的角色和技能（详细提示词请在后台发送“订单系统提示词”领取），
这里有一个关键点：
JSON 数据的结构，必须和后面要写入的订单表头一一对应，否则写入多维表格会失败。
大模型节点的输出变量叫 parsed，类型是 Object。
3、代码节点：校验 + 规范交期 + 组装数据
代码节点是这条链路的“中枢”，输入和输出都比较讲究：
输入：
• parsed（Object）：直接接大模型节点的输出；
• msg_id（String）：来自开始节点。
输出：
• is_valid（Boolean）：这条订单是否通过校验（关键数据是否齐全）；
• validated（Object）：整理好的订单对象；
• records（Array<Object>）：专门给多维表格节点用的记录数组；
• error_reason（String）：校验失败时的中文报错。
代码里主要做了一件事：
把输出的数据组装成多维表格节点可以接收的数组；
4、IF 选择器：只让健康订单往后走
选择器节点的条件非常简单：
• 如果 代码节点.is_valid == true，则走“如果”分支；
• 否则直接结束。
5、飞书多维表格节点：把数据写进飞书多维表格
这个节点关键是三个输入：
• app_token：从飞书开发者后台复制过来的应用 Token；
• table_id：目标多维表格的数据表 ID；
• records：一定要连接代码节点输出的 records（类型是 Array<Object>）。
如果你发现 data 为空、或者 msg 里提示字段不匹配，优先检查两件事：
1）records 的结构是否为 [{"fields": {...}}] 这种数组；
2）fields 里的 key 是否和飞书表头完全一致（包括大小写和中英文）。
6、结束节点：给调用方一个清晰回执
结束节点我返回了三个变量：
• OK：直接映射代码节点的 is_valid；
• ID：映射 add_records.data.records[0].record_id；
• data：映射 add_records.data，方便后续调试或前端展示更多信息。
这样无论是从智能体里调用，还是从外部系统通过 API 调用，都能一眼看出：
这条订单到底有没有写入成功，如果成功写到了哪一行。
04
实战效果：一句话订单 → 表格一行
例如我在开始节点输入一句：
“广州建采绿碳：C50 商混 100 方，珠江新城 A3 地块，2025-11-14早上10点，联系人老李 13500001111。”
工作流跑完之后：
• 多维表格里自动新增一行：客户=广州建采绿碳、项目=珠江新城A3地块、品类=C50 商混、数量=100 方；
从此告别“截图+手抄+对着手机敲 Excel”的痛苦。
05
踩坑复盘：以后再搭工作流可以少掉几根头发
这次搭完，我给自己总结了几条“避坑指南”：
1）先想清楚“最终表头长什么样”，再去设计 JSON 结构和代码节点，别反着来；
2）字段名一定要和多维表格表头完全一致，改一个字都写不进去；
3）大模型尽量输出干净的 JSON，不要在代码里硬解析一堆中文句子；
4）交期这种“又有日期又有口语”的字段，最好集中封装成一个规范化函数，后面别处可以复用。
结语
这只是一个小小的起点。后面还可以继续扩展：比如增加重复订单检测、自动生成生产计划、和发货系统打通等等。
但至少从这条“微信群下单 → 飞书表格入库”的流水线开始，我们已经迈出了 AI 赋能建筑建材供应链的一小步。
以前我们总觉得，“自动化接单系统”是大厂才玩得起的东西，小团队、传统行业想要搞，要么上重型 ERP，要么请外包团队做一套系统，周期长、成本高，还不一定好用。
这次用扣子 + 飞书多维表格 + 大模型搭完之后，我最大的感受是：
很多看起来“需要系统开发”的需求，其实完全可以用 AI 工作流 + 现成 SaaS 拼出来，而且速度非常快。
接下来，我还准备继续往这条线两头延伸：
- 上游：做一个“对接客户的小助手”，自动和客户确认关键信息；
- 下游：把多维表格里的订单再推给生产、调度、司机的工作流。
如果你也在研究怎么把 AI 真正落在业务上，不妨从这样一个“小而具体”的流程先动手。
哪怕只解决一个微信群的接单问题，你也已经迈出了非常关键的一步。
如果文章对你有帮助，请别忘了点赞、收藏及转发~，想学习更多AI应用技巧，请关注我的公众号，每天为你更新不同的AI应用技巧文章。
欢迎加我的微信（Lilang7768），备注“加群”，免费送你：
①清华大学编写的DeepSeek应用教程（1~6弹）
②北京大学编写的提示词工程和落地场景
③《AI工具应用宝典》
④《AI高效办公提示词手册》
⑤一个上百人的AI交流社群
