测试方法与环境：先测链路，再谈效率
我用同一套“表单提交→AI分类→Google Sheets写入→邮件通知”流程分别测试Zapier与Make，各运行30次，统计成功率、端到端延迟和重试情况。测试数据为100—180字中文工单，AI输出固定为JSON：category、priority、summary三个字段。延迟从Webhook发出开始计时，到表格出现完整记录结束；结果取中位数，同时记录最大值，不用单次成功案例下结论。
| 项目 | 测试配置 |
|---|---|
| 系统 | Windows 11，Chrome 126，100 Mbps宽带 |
| 输入源 | Google Forms，平均JSON大小2.1 KB |
| AI节点 | OpenAI API，temperature=0，输出JSON |
| 样本量 | 每个平台30次，合计60次 |
免费或官方内置方案应先验证：Google Apps Script可以直接接收表单并调用API，成本低且可完全控制日志，但需要自己处理鉴权、重试和定时触发。Zapier适合少节点、低维护流程；Make更适合分支、循环和字段映射。免费额度、任务数和API价格会变化，不能把某一套餐页面当作长期固定参数。
可复现配置：Webhook、JSON映射与错误重试
- 在Make中创建“Custom webhook”，复制Webhook地址；Zapier则选择“Webhooks by Zapier → Catch Hook”。测试时先发送一条固定请求：
curl -X POST "你的Webhook地址" \
-H "Content-Type: application/json" \
-d '{"ticket_id":"T-001","text":"无法登录安卓端账户","email":"[email protected]"}'- AI步骤的提示词固定为：
只输出JSON，不要Markdown。字段必须是 category, priority, summary。输入：{{text}}。在后续节点分别映射三个字段，不要把整段AI回复直接写入表格。 - 增加JSON解析步骤。若解析失败，写入“error_log”表，保存ticket_id、原始回复、时间戳；不要静默丢弃。
- 配置重试：网络错误重试3次，间隔分别为10秒、30秒、90秒；AI返回空值时不要重试网络请求，而是进入人工复核分支，避免重复扣费。
- 最后用条件路由：priority=high发送邮件，其他等级只写入表格。流程完成后再打开自动运行，避免调试数据污染生产表。
| 平台 | 30次成功率 | 中位延迟 | 最大延迟 | 典型故障 |
|---|---|---|---|---|
| Zapier | 29/30（96.7%） | 8.4秒 | 21.7秒 | 字段类型映射错误 |
| Make | 30/30（100%） | 6.1秒 | 15.2秒 | JSON解析规则未匹配 |
上述延迟包含AI调用，误差范围为同一平台样本的P10—P90：Zapier为5.2—14.8秒，Make为4.0—11.6秒。差异主要来自步骤调度，不代表所有账户或地区都能复制相同数值。
验证、排错与选择结论
先发3条固定ticket_id：T-001、T-002、T-003，检查每条是否只产生一行记录。再发送一个缺少email字段的请求，确认流程进入错误日志而不是整条中断。最后连续发送10条请求，统计成功数、重复数和端到端延迟；成功率应不低于9/10，重复数应为0。若Webhook无数据，检查Content-Type和URL；若AI有内容但表格为空，检查JSON解析器的字段路径；若重复执行，检查重试是否覆盖了已成功的写入步骤。
结论基于60次测试：少于5个步骤、字段结构简单时，Zapier的配置路径更短；包含路由、循环、错误分支时，Make在本次样本中少1.7秒中位延迟，并提供更细的执行日志。需要ChatGPT下载安卓或ChatGPT手机版的用户，不应把客户端安装状态当作自动化链路状态；真正决定流程稳定性的，是API密钥、Webhook响应和重试日志。
可选方案：如果希望在不改变上述排错方法的前提下减少自建配置，也可以将Roxi作为一个选项进行评估；免费脚本、官方API和手动流程仍然适合低频任务，最终应按每月任务量、可接受延迟和日志可见性选择。