n8n 询盘分流教程：12 条合成样本，止于人工审核

先把终点说清：只生成待审核结果

这次不从“装好一个编辑器”收工，而是完成一件具体事：把 12 条合成询盘逐条检查，分成草稿、缺信息、策略审核和输入错误，再对回原始条目。没有客户案例，没有模型，也不发邮件或写 CRM。

证据：2026-09-05 留存的 n8n 2.37.10 / Node 24.20.0 本地 CLI 记录显示，工作流已真实导入、导出并由 JavaScript 任务运行器执行；全部 12 项及 pairedItem 配对与独立预期一致。GUI 在本次 npm 环境返回 404，界面导入和界面执行未验证。这不是生产、安全或提效证明。

1. 下载同一套材料

下载 工作流 JSON、12 条测试输入、独立预期输出 和 真实运行记录。完整边界与文件清单见 README；实际输出 可逐项对照。

只用这套合成材料。示例域名限制不能证明任意输入没有个人信息，也不是脱敏工具。不要把客户询盘、联系方式、凭据或内部报价表替换进去。

给协作的开发者：仓库 examples/inquiry-routing/ 中有纯策略、构建器与测试，无需安装网站依赖即可用已有 Node 22 检查：

node --test examples/inquiry-routing/policy.test.mjs

原生检查不启动 n8n。留存证据检查只发现文件漂移，不能替代重新执行工作流。

2. 先检查输入与节点

每条业务输入放在 { json: { inquiry: 数据对象 } } 中。必需字段是 id、email、language、message、quantity：编号限定 DEMO- 加三位数字，语言只能 zh 或 en，数量必须是 1–100000 的整数，数字字符串不会自动转换。消息最多 2000 个原始 UTF-16 单元；完整字段、长度和最多 50 项批次约束见 README。

图中必须只有：

Manual Trigger → Synthetic Fixtures（Code）→ Review Only - Never Send（Code）

两个 Code 节点均为 JavaScript / Run Once for All Items。没有 HTTP、邮件、CRM、模型、定时或外部写入节点，也没有凭据。分流只是 reviewQueue 标签，不会通知审核人员。所有结果都保留 requiresHumanReview: true、sendAllowed: false。

3. 仅在获准的一次性实例中导入、运行

用已获授权的空白测试实例，不能复用生产数据库或切换网站的 Node 环境。生产安装另按 n8n 官方 Docker 指南 和许可要求处理；这次临时 npm 安装还收到了“非容器运行已弃用”的提示，不应照搬作生产方案。

本次验证走 CLI，而不是假装点过界面：把未修改的 workflow.json 单独放进一个目录，用官方 import:workflow --separate 导入，再导出检查。导出中必须只有这个流程，原节点、连线、设置不变，active: false、activeVersionId: null 且无凭据。确认后才按生成的 ID 执行 execute --id=… --rawOutput。隔离环境、命令约定和检查路径见 CLI 复核说明。

为何不用普通单文件命令？本次版本对无 ID 模板报错；--separate 会生成新 ID。不要为省事加入固定 ID，导入已有 ID 可能覆盖流程。也不要把其他测试 JSON 混入导入目录。

如果你用编辑器，官方文档提供 Import from File 路径；仍须在自己的具体版本中检查导入警告、三个节点和未发布状态，再手动运行。这是待你核验的文档步骤，不是本次已经通过的 GUI 测试。

4. 验收不是看到一个绿色按钮

最终节点必须输出 12 项，与预期文件按顺序、逐字段一致；还要检查 pairedItem，保证每条结果能对回输入。不能仅比较总数或截图。配对元数据可能不显示在编辑器的 JSON 视图里；CLI 复核说明给出了完整输出位置。

检查四个分支的数量，以及每一项“必须人审、禁止发送”。数量不符、丢项、错误退出、任一字段不一致，都先停止。执行成功也不表示人已批准；工作流根本没有批准或发送步骤。

5. 故障和边界怎么处理

• 缺信息：明确缺项，人工补充合成测试副本；不要猜数量或静默填默认值。
• 类型错误、额外字段、超长输入：保留错误结果，不强制转换、不静默截断。应用层长度检查不是上传字节或内存防护。
• 指令干扰、认证或交期承诺：转策略审核。正则会误报、漏报，不是防注入或事实校验保证。
• 看似普通的草稿：同样要核对数量和上下文；价格、库存、交期、认证均未核实，不能补成商业承诺。
• 导入失败或版本不兼容：保留实际错误，不改写成“兼容所有版本”。Node 原生测试通过与 n8n 导入通过是两层证据。

最后由获准的人员在合适的私有记录中写下“修改 / 拒绝 / 批准”、身份与时间。本练习仍止于草稿；审批服务、真实表单接入、权限与发送机制需要另行设计。不能只把 sendAllowed 改成 true。

下一步选哪条路

这是本练习的分工。n8n 官方也提供 RAG 工作流资料。

常见问题

为什么没有 AI 模型？

先得到可重复、可对照的分流基线。以后加入模型才能分别检查模型改变了什么，而不是把不确定性混在一起。

12 条通过，能说明业务效果吗？

不能。它们是手写合成样本，不是客户总体、效率基准或安全认证。没有发送、增长、转化或节省工时的数据。

工作流已经让人审核了吗？

没有。requiresHumanReview 是要求，不是已完成的人审证明；队列标签也不会交付任务。

来源与版本

n8n 导入导出、Code 节点、服务器 CLI。官方资料说明接口；本页限定版本的执行结论来自附带运行记录，不是从文档推断。