场景：每天手动回订单消息，回不过来
做餐饮、零售、社区团购这类本地生意，订单消息基本都落在微信、表单或者店铺后台里。模式很固定：新订单进来，看一眼内容，判断是常规下单还是客诉，然后回一条确认消息。单量小的时候无所谓，单量一上来，大部分时间都耗在重复回复上。
这篇教程的目标很具体：用 n8n 搭一条自动化流水线，新订单进来之后，AI 自动判断意图、生成回复，普通单直接自动回，客诉类订单转发给人处理，同时发一条通知。全程不写代码，接模型只需要一个 HiAPI 的 API key。
2026 年以来，n8n 在多篇自动化工具盘点里被反复推荐给中小商家（如 Atlassian、techaigoz 的 2026 年度盘点），理由很直接：自托管、开源、LLM 节点体系成熟。2026 年 10 月，X 上一条用 n8n 给本地小商家做自动化接单的帖子单条就有约 5.1 万浏览，说明这个需求已经很普遍了。
准备：一个 HiAPI key + 一个 n8n
开始前只需要两样东西。
第一，HiAPI 的 API key。在 HiAPI 控制台创建并复制，格式是 sk- 开头。这个 key 是 OpenAI 兼容的，后面 n8n 里所有模型都走它。
第二，n8n。云版或自托管都行，这篇不挑部署方式。唯一的要求是版本别太旧，原因下面会讲。
核心一步：OpenAI Chat Model 节点接 HiAPI
整条流水线的关键是让 n8n 连上模型。做法比想象中简单：n8n 的 AI 节点体系里有一个 OpenAI Chat Model 子节点，它的 Credential 里带 Base URL 输入框，填上 OpenAI 兼容端点和 API Key 就能用（这个能力 n8n 社区早有讨论，见社区帖 Override baseURL for OpenAI Node）。
具体填三样东西：
- Base URL：
https://api.hiapi.ai - API Key：你的 HiAPI key（
sk-开头） - Model：手填
deepseek-v4.1-flash
注意两点。第一，要用的是 AI 节点体系里的 OpenAI Chat Model 子节点，不是旧的 OpenAI 节点。第二，Base URL 字段在较新版本的 n8n 里才有，个别旧版本缺这个字段，先在 n8n 里升级到较新版本再配置。
填好之后，整条工作流里所有 AI 节点共用这一个 Credential。之后想换模型，改 Model 那一栏就行，比如客诉场景换成 claude-opus-4-8，key 不用动。
到这里模型就接通了。接下来是工作流本身。
工作流四步
整条流水线四个节点串起来：Webhook 触发、AI 分类并拟回复、IF 分支、通知。
1. Webhook 触发
用 Webhook 节点做入口，订单系统（表单、店铺后台、中转机器人）有新订单时把消息内容 POST 到这个地址。触发器拿到的订单文本会传给后面的 AI 节点。
如果暂时没有系统对接，也可以先用 n8n 的表单触发节点手动模拟新订单，跑通流程再换真实数据源。
2. AI 节点：分类 + 拟回复
接一个 AI Agent 节点（或者简化的 Chain 节点），挂上刚才配好的 OpenAI Chat Model Credential，模型填 deepseek-v4.1-flash。系统 prompt 负责两件事：判断这条消息是常规订单还是客诉，然后分别以商家口吻拟一条回复。
下面是一份可以直接用的系统 prompt，替换成你自己的店名和品类就能跑：
你是一个本地餐饮商家的接单助手。请按以下规则处理每条用户消息：
1. 先判断消息类型：
- 常规订单：用户明确下单，包含商品、数量、地址或取餐方式
- 客诉：用户对商品或服务表达不满、要求退款、投诉
- 其他：询问营业时间、菜单等不需要立即回复的内容
2. 再按类型生成回复：
- 常规订单：以商家口吻确认订单内容，复述商品和数量，说明预计出餐或送达时间，语气亲切自然
- 客诉：先表达歉意和重视，说明会尽快人工处理，不要承诺具体赔偿方案
- 其他：正常回答用户问题
3. 输出格式严格为 JSON，两个字段：
- category：order / complaint / other
- reply：拟好的回复文本
只输出 JSON，不要输出任何解释。
要求 AI 输出结构化 JSON 是重点，这样后面的 IF 分支才能稳定判断。如果偶尔输出不标准，在 AI 节点后加一个简单的数据清洗步骤兜底。
3. IF 分支：普通单自动回，客诉升级人工
用 IF 节点读 category 字段：
order或other：走自动回复，把reply文本通过你的通知渠道发回给客户（微信机器人、邮件或短信，看你接的是什么）complaint：不自动回复，把订单原文和分类结果打包发通知给店主或值班人员，附带建议处理的话术，等人接手
这个分流是整条流水线的价值所在。AI 处理掉大部分重复的确认消息，人只处理需要判断力和同理心的客诉。
4. 通知节点
最后接一个通知节点，把处理结果发到你的协作工具（飞书、微信、邮件均可）。普通单通知一条已自动回复，客诉单通知完整订单信息并标记待人工。这样即使你不盯着流水线的执行记录，也能实时知道店里发生了什么。
成本控制：常规走 flash，复杂走 opus
按任务选模型是这套流程控制成本的关键，没必要所有请求都用最贵的。
- 常规分类和回复走 deepseek-v4.1-flash，输入 $0.44 / 百万 token、输出 $1.32 / 百万 token（HiAPI 平台价，截至 2026-10）。接单消息一般几百 token，一条订单的模型成本非常低，估算不到 1 美分
- 客诉分析、长上下文总结这类复杂场景再切 claude-opus-4-8，输入 $2.29 / 百万 token、输出 $11.47 / 百万 token（截至 2026-10）。客诉占比小，总成本影响有限
价格点到为止，详细定价看模型详情页。想深入了解为什么按任务选模型能省成本，可以看我们之前写的 Notion AI 自动路由实践，里面有按任务分发请求到不同模型的完整思路，和这篇的接单场景是同一套逻辑。
FAQ
API key 放在 n8n 里安全吗？
key 要填在 n8n 的 Credential（凭证）里，而不是直接写进节点的参数或代码。Credential 由 n8n 加密存储，工作流导出分享时不会带出 key。另外建议在 HiAPI 控制台给这个 key 设置用量上限，即使泄露损失也可控。
遇到 429（请求太频繁）怎么办？
429 说明触发了限流。先检查是否短时间内批量灌入了大量订单，可以拉长触发间隔或给 AI 节点加排队。如果持续出现，到 HiAPI 控制台查看当前 key 的并发和额度设置，必要时调整套餐。工作流里也可以给 AI 节点配重试策略，遇到 429 自动延迟后重试。
能不能换别的模型？
可以。Model 栏换成 HiAPI 上任意模型的名称即可，比如常规单换 deepseek-v4.1-flash、客诉换 claude-opus-4-8，key 和 Base URL 都不用改。一个 key 全模型通用，这正是用 HiAPI 而不是分别申请各家官方 key 的省事之处。
和直接申请官方 API key 有什么区别？
核心是两点。第一，一个 HiAPI key 覆盖多个模型，不用每家官方平台分别注册、分别充值、分别管理额度。第二，按量计费统一结算，对调用量分散在多个模型上的场景更划算。对中小商家来说，管理成本比单价差异更重要。
流式输出（streaming）不支持有关系吗？
没关系。这条流水线是异步处理订单，AI 生成完回复一次性返回即可，不像聊天界面那样需要逐字显示。流式与否不影响效果。
n8n 里没有 Base URL 这个字段怎么办？
说明你用的 n8n 版本太旧。Base URL 是 AI 节点体系里 OpenAI Chat Model 子节点的参数，较新版本才有。先在 n8n 里升级到较新版本，再按上面的 Credential 配置步骤操作。
关键结论
- 接入就是改一处 Credential：Base URL 填
https://api.hiapi.ai，API Key 填 HiAPI key，模型名手填deepseek-v4.1-flash，不写代码。 - 分类和拟回复放在同一次 AI 调用里完成，用严格的 JSON 输出格式，后面的 IF 分支才能稳定判断。
- 普通单自动回，客诉每次都升级人工，这条边界由 IF 分支强制执行。
- 钱花在难度上：常规单走 flash，难处理的消息切
claude-opus-4-8，同一个 key 只改模型名。 - key 放 n8n Credential 里统一管理，遇到 429 做延迟重试，换模型是一处改动。
