AI 自动化工作流是把固定流程、AI 判断、触发方式、失败通知串成可监控系统，不是把所有事情丢给 AI 自己跑。新手先问三件事：什么时候触发、失败谁会知道、最后一步能不能回滚。
AI 自动化不是「把所有事交给 AI」
对外宣传的图通常是：丢一句「自动处理所有事」，AI 就什么都包。实际做下来会撞到三件事：
- 触发类型：时间调度、表单、Webhook、人工审核 → 工具能做的不一样。
- 失败策略：API 挂掉、token 过期、格式变动，总会发生。
- 可逆性：有些事一旦自动跑就不可逆，例如转帐、删除、对外发送。
把这三件事摆在最前面，再选工具，比较不会做出「跑得很顺但出包后找不到谁」的流程。
四条主流路线怎么分
| 路线 | 形态 | 计费 | 适合 |
|---|---|---|---|
| Make / Zapier | no-code SaaS | Make 算 credits、Zapier 算 tasks | 个人、小团队、跨 app 中度自动化 |
| n8n | self-host 或 cloud | 自架免费 / cloud 算 executions | 技术团队、需要自控数据、多步骤流程 |
| 自建 cron + LLM API | 程序 / 脚本 | 主要是 API 调用费 | 开发者、频率高、想完全控制逻辑与失败策略 |
| Power Automate | M365 内建 | per user / per bot 授权 | 已经在 Microsoft 365 体系内的公司 |
详细四款比较见 自动化工具比较（2026）。
工具选型表：n8n、Make、Zapier、Cron 先怎么分
| 需求 | 优先看 | 为什么 |
|---|---|---|
| 想最快串 Gmail / Notion / Sheets | Make / Zapier | connector 多、上手快 |
| 流程很长、分支很多、想掌控数据 | n8n | execution 计费对长流程友善，可自架 |
| 公司都在 Microsoft 365 | Power Automate | Outlook、Teams、SharePoint 整合深 |
| 开发者要高频、低成本、完全可控 | Cron + LLM API | 成本透明，但监控与维护自己扛 |
n8n 的 intent 要特别拉出来看：它适合「愿意负责系统」的人，不只是想找免费工具的人。自架省的是 SaaS 执行费，换来的是 backup、credentials、patch、incident response。
先选触发方式：时间 / 表单 / Webhook / 人工审核
时间触发：每天 / 每小时 / 每 15 分钟跑一次。常见用途：早报、定时 polling 监控。注意 Make 与 Zapier 免费版最短间隔 15 分钟。
表单 / 事件触发：填表后启动、收信时启动、社区有新帖子启动。常见用途：lead 收件、客服第一线、社区监测。
Webhook 触发：另一个系统发 HTTP 请求进来启动。常见用途：跨系统串接、CI/CD、第三方 callback。
人工审核触发：把 AI 草稿留在收件匣，人按下「同意」后再寄出。常见用途：对外发信、发布帖子、审批流程。
两篇延伸教程的 TL;DR
工具比较：先算计费单位，不要只看免费
自动化工具比较的重点是 Make、n8n、Zapier、Power Automate 不是同一种价格逻辑。Make 算 credits，Zapier 算 tasks，n8n cloud 算 executions，Power Automate 算授权。流程步骤越长，Zapier 越容易贵；需要自架与数据掌控，n8n 才有价值；只是想快点把两三个 app 串起来，Make / Zapier 比较省心。
排程系统：会准时跑，不代表可以放心
AI 排程系统实战补的是 cron / n8n schedule / Make schedule 的失败面。时间触发只是开始，真正要设计的是 log、retry、alert、人工审核闸。每天一次的报告和每五分钟一次的监控，成本与维护压力完全不同；对外发布、删数据、转账这类动作不要直接让排程自动送出。
什么工作最适合自动化
- 重复频率高：每天、每周都做，且流程固定。
- 失败代价低：跑坏了重新跑就好，不会造成不可逆损失。
- 输出容易验证：跑出来的东西可以肉眼看一眼就知道对不对。
例：新闻摘要、社区调度、定时报表、数据汇整、文件重新命名。
什么工作不该自动化
- 一次性判断工作：建构流程的时间多过手动跑一次。
- 不可逆的对外动作：未经审核就自动发信、自动转帐、自动删数据。
- 失败难以察觉的工作：跑错没人发现、追溯成本很高。
对「不可逆」类工作的折衷做法：AI 产草稿 → 人工审核闸 → 才发送。
新手第一条 workflow 怎么设计
- 找一个你每天手动做、流程固定、低风险的事。
- 写下触发条件 → 步骤 → 预期输出。
- 用 Make 或 Zapier 拖出第一版，跑通最乐观路径（happy path）。
- 加失败通知：失败时自动寄信 / 推到 Slack / 写进 log。
- 试跑一周，看实际 credits / tasks 消耗。
- 确认稳定再扩第二条。
最常见的「没设失败通知」问题：自动化跑挂三天才被发现，已经错过时效。设计时就把这条当必备项目。
上线前一定要有的失败通知
- 任务跑完写一笔状态 log（成功 / 失败 / 跳过）。
- 超过预期时间没新 log → 触发 alert。
- API 失败自动 retry N 次后升级成警告。
- 对 outbound 动作（寄信、发布、转帐）保留人工最后 confirm 闸。
结论
自动化的第一条纪律：「会准时执行不代表可以放心交出去」，真正要设计的是失败时怎么被看见。先做低风险、高重复、容易验证的事；长出第一条稳定流程，再来扩张。
小企鹅的经验
OpenClaw 的 cron 系统是小企鹅目前在跑的 daily driver：每天定时去抓数据、用 Claude 系列模型整理、把结果写进工作笔记、把错误推到 Telegram 警示。整套是 code-based 自建路线（不是 Make / n8n / Zapier 串出来的），所以对「自动化哪边会出包」这件事比较有体感。最常踩的坑集中在三件事：token 过期、API 换 schema、云端服务改 rate limit，这三件事占失败 case 的大半（AI 写得不好反而很少是主因）。
对「一般非工程师能不能做到」的看法：能，但建议从 no-code 工具开始，把第一条流程跑稳、把失败通知做好，再考虑自架。Code-based 路线的门槛不在「会不会写」，而在「愿不愿意每周花时间维护」。
延伸阅读
常见问题
Q: n8n 跟 Make 怎么选？
想快速开始、少碰服务器、营销与个人流程多 → Make；需要自架、数据掌控、长流程、技术团队维护 → n8n。
Q: AI 自动化和传统自动化差在哪？
传统自动化多半是固定 if-then；AI 自动化多了一段读内容、摘要、分类、判断下一步的模型处理，也更需要失败通知与人工审核。
Q: 不会写代码能做 AI 自动化吗？
可以。Make、Zapier、n8n cloud 都能用拖拉式流程串 AI 与 app；先选低风险、可验证、可回滚的小任务。
Q: 哪些任务不适合自动化？
不可逆、敏感、失败难察觉、一次性判断的任务不适合直接自动化。例如转账、删文件、法务判断、医疗建议、未审核的对外发布。
Q: Webhook、Cron、表单触发差在哪？
Cron 按时间跑，Webhook 由别的系统事件触发，表单由用户输入触发。先选触发方式，再选工具。
整理：Penna｜小企鹅 Penchan