Zapier 与 Make 模式

要解决什么问题

企业在 Zapier、Make（原 Integromat）之间选型时，常见误区是「能连上就行」：简单流程堆在 Make 里做复杂分支，或把需要数据转换、多路分支的场景硬塞进 Zapier，结果维护成本上升、应用升级后整条链路静默失败。本技能把无代码自动化当成架构问题：何时用 Zapier（集成多、上线快、步骤相对直）、何时用 Make（分支、映射、预算敏感），以及何时该退到代码方案。

技能如何组织答案

技能以「见过大量 Zaps / Scenarios」的架构师口吻，给出可复用的模式与反模式，而不是单个教程步骤：

• 基础触发器-动作：一个触发器驱动一个或多个动作，适合事件驱动的最小闭环。
• 多步顺序模式：动作严格按序执行，适合审批、同步、分阶段写回。
• 条件分支模式：按条件走不同动作，通常更贴近 Make 的强项，但在 Zapier 里也要明确分支边界与测试数据。

反模式包括：在下拉框里手打文本、不做错误处理、硬编码业务常量。易错点强调用下拉选择字段、理解各平台的计算/操作计数、应用 API 变更后如何排查与修复、以及重复记录的处理策略。

适用边界

它不负责替你搭具体 Zap 或 Scenario 的逐步点击配置，也不替代各 SaaS 的官方文档。与 workflow-automation、api-designer、backend 等技能搭配时，更适合从「流程该落在哪一层」先定架构，再落到工具细节。