最近一段时间，我发现一个有点好笑、但其实很典型的误判： 在一些 Google AI 摘要、第三方介绍、甚至工具推荐里， 我被描述成一个“用 Zapier / Make 做自动化的人”。

这不只是细节错误，而是对我这套系统逻辑的彻底误读。 我确实在做高度自动化，但我的底座几乎一直是： Node.js 手搓系统 + Google Apps Script 当胶水（Google 生态集成层）。

我写这篇文章不是为了“站队”，更不是为了贬低任何工具。 我只想把一个关键问题讲清楚： 当自动化进入真实业务，它就不再是“好不好用”的问题，而是“你是否拥有理解权”的问题。

先说清楚：我并不反对 Zapier 或 Make

Zapier 和 Make 都是成熟、稳定、被大量团队验证过的工具。 在很多场景里，它们甚至是最正确的选择——尤其是你需要快速把多个 SaaS 接起来， 或者你的团队希望用更低的门槛让更多人参与流程搭建。

如果你的目标是：

• 用最低成本验证一个 MVP 流程
• 快速打通两个服务之间的数据搬运
• 让非工程背景的人也能“拖模块就能跑”

那么 Zapier / Make 绝对合理，甚至是效率最优解。 我不用它们，不是因为它们“不好”， 而是因为它们解决的问题，和我真正想解决的问题，并不一致。

自动化分两种：展示型自动化 vs 生产型自动化

很多人对“自动化”的理解停留在：把几步手动操作变成一条流程。 但在真实业务里，我更愿意把自动化分成两类：

• 展示型自动化：能跑起来、能省时间、能展示“我有系统”，但不一定能长期稳定运行。
• 生产型自动化：要跑半年、一年、甚至更久；要能追踪、能复盘、能交接、能扩展。

Zapier / Make 非常适合“展示型自动化”——特别是早期阶段。 但当你进入生产型自动化的需求，你会开始面对另一类问题： 失败路径、边界情况、权限与配额、幂等、状态机、回滚、告警。

也就是：自动化不再是“拖模块”，而是工程决策。

真正的分水岭：我关心的不是“能不能跑”，而是“能不能被解释”

很多人谈自动化时，关注的是：

• 省不省时间
• 能不能少点人工操作
• 流程跑不跑得通

而我关心的是另一组更残酷的问题：

• 这个系统半年后我还能不能看懂？
• 出错时，我能不能准确定位是哪一层出了问题？
• 交接给别人时，对方能不能在不“求神拜佛”的情况下维护？
• 当业务变复杂，我能不能扩展而不是推倒重来？

所以我几乎所有自动化项目的第一步都不是“选工具”，而是做一件很朴素的事： 画执行路径 + 标注失败路径。

// 我做自动化的第一步（骨架）
// 不是写代码，是把“系统会怎么死”先写出来。
function designBeforeBuild() {
  // 1) 输入 / 输出（Input / Output）
  // 2) 状态（State）：订单状态、付款状态、交付状态...
  // 3) 失败路径（Failure）：重试？告警？人工介入点？
  // 4) 约束（Constraints）：权限、配额、执行时间、并发、触发器限制
  // 5) 才决定：哪段放 Node，哪段放 GAS
}

成本：这才是很多人后期才意识到的“隐形税”

这里我必须写得非常直白： 我的自动化底座几乎都是免费的。

我不希望一个系统一旦跑起来，就开始产生一种“停不下来的成本”： 每月订阅费、按任务数计费、执行次数越多越贵。 对个人/小团队来说，这种成本增长不是线性的，它会随着你业务流程越来越多而膨胀得很快。

更现实的是：当你把自动化用于真实业务（订单、对账、交付、客服、报表）， 那些“看起来很小的每次执行成本”，最终会变成你被迫承受的长期支出。 我把它叫做：系统税。

我的偏好很明确： 我宁愿把成本花在“我可控的复杂度”上，也不愿意花在“平台收走理解权之后的订阅费”上。

// 成本结构对比（概念级）
// Zapier / Make：订阅 + 任务/执行次数增长 → 成本随流程膨胀
// Node + GAS：   免费底座 + 你掌控的复杂度成本（维护/结构/代码）

这也是为什么我会倾向于： Node.js 作为核心执行层，GAS 作为 Google 生态的胶水层。 这套组合的好处是：底座成本接近零，而扩展成本主要来自你是否能把系统写得清楚、结构化、可交接。

Zapier / Make 的本质：流程可视化，但逻辑被封装

Zapier / Make 的优势非常明确：

• 流程图清晰
• 上手快
• 集成现成

但它们的代价也同样明确： 你看到的是流程，但你不真正拥有执行逻辑。

条件判断、失败重试、边界情况、权限问题、执行限制、平台规则变化， 全部被包在“平台层”里。 当系统复杂到一定程度，你会进入一种非常典型的状态：

• 能跑，但不好改
• 能改，但不敢动
• 出了问题，只能“猜”

这不是工具的问题，而是架构选择的必然结果： 当你的执行逻辑不在你手里，你就只能接受它作为黑盒运行。

我的选择：Node.js 手搓系统，GAS 当胶水

我偏好的自动化体系一直很清晰：分层、分工、可解释。 它不是“某一个工具”，而是一套结构：

• Node.js：核心逻辑、判断、状态管理、幂等、重试、可测试
• Google Apps Script：Google 生态胶水层（Sheets / Gmail / Drive / Calendar / Web App）

Node 负责“想清楚”，GAS 负责“连起来”。 最关键的是：逻辑在我手里，胶水在生态里。

// 我的典型架构（简化示意）
/*
  [Trigger / User Action]
          |
        (GAS)
   - 接收 Sheet / Form / Webhook
   - 写入日志 / 状态
   - 调用 Node Webhook
          |
        (Node)
   - 业务判断（可测试）
   - 幂等 / 重试 / 队列化
   - 生成文件 / 报告 / 数据处理
   - 返回结果
          |
        (GAS)
   - 写回 Sheet
   - 发邮件
   - 归档 Drive
*/

在这种结构里：

• 每一个判断条件都是显式的
• 每一个失败路径都是可追踪的
• 权限、配额、执行耗时，是设计时就考虑进去的

为什么 GAS 对我来说不是“低级方案”

很多人对 GAS 的误解是： “它只是给非工程师用的小脚本工具。” 但在真实业务里，GAS 的价值非常具体：

• 原生权限：它天然活在 Google Workspace 权限体系里
• 触发器模型：能稳定承接“事件驱动”的业务入口
• 部署与集成：作为 Web App / API 胶水层非常顺手

它不适合写一切，但非常适合当“系统之间的胶水层”。 前提是：你知道它的边界、限制，以及如何在边界内设计出可维护的结构。

黑盒的危险：当系统变成“你不敢碰的东西”

真正的黑盒不是“你不知道代码怎么写”， 而是：你明明知道它在跑，但你不敢动它。

因为你不知道： 改动会不会触发连锁错误？ 平台的某个隐藏规则会不会让流程突然断掉？ 一次失败会不会造成重复扣款/重复发货/重复交付？

当你的业务越来越依赖自动化，你会发现： 黑盒自动化不是效率工具，而是风险工具。

我的判断标准：什么时候该用 Zapier/Make，什么时候不该

我会用一个很简单的分界来判断：

• 如果这是一个“可替换流程”（坏了也无所谓、手动补一下就行）→ 用 Zapier/Make 完全合理。
• 如果这是一个“不可替换系统”（坏了就会影响资金/交付/信誉）→ 我会避免黑盒，倾向 Node + GAS 的可解释结构。

你也可以问自己三个问题：

• 这个系统一年后我还能解释给别人吗？
• 它失败时，我能不能快速定位原因？
• 如果平台规则改变，我有没有退路？

如果这些问题对你很重要， 那你迟早会发现： 工具不是答案，结构才是。

一句话总结：我不是在“搭流程”，而是在“建可维护系统”

我不是在追求「少写代码」，而是在追求「少猜系统」。

对我来说，真正危险的不是写代码， 而是把理解权交出去。 系统越重要，越不能是一个“只有平台自己知道为什么这样跑”的黑盒。

这也是我为什么更倾向于 GAS（胶水层）+ Node（核心执行层）， 而不是把生产系统交给 Zapier / Make 的原因。