Make

Make 是一个通过可视化 Scenario 连接不同应用的自动化平台。你可以把表格中的新数据送到聊天工具，把表单请求交给业务系统，也可以加入 HTTP、Webhook、AI 或代码步骤。它的核心不只是“连接很多应用”，而是让每一步收到什么数据、执行多少次、流向哪里都可以检查。

从简单流程走向多分支自动化时，最需要理解的是 bundle：同一次运行可能产生多条数据，每条数据又会触发后续动作。这直接影响消息数量、错误定位和费用，不能只按画布上画了几个模块来估算。

从 Google Sheets 新行到 Slack 通知，看懂字段如何流动

Make 的官方入门示例使用 Google Sheets 与 Slack。可以从类似场景理解它：表格保存新增企业线索，第一步 Watch New Rows 检查新行，第二步 Send a Message 把公司名称和来源链接发送到指定 Slack 位置。这里只解释配置与数据关系，没有连接账号或实际发出消息。

表格列名构成后续映射的依据。消息正文中的“公司名称”应引用表格输出字段，而不是手工写死某一家公司的名字；来源链接也应取自对应行。先准备几条格式完整、彼此不同的测试数据，才容易看出通知是否错误地重复使用同一条记录。

Run once 之后，打开模块的输入输出

运行后，模块上方的执行气泡可以展开查看各次输入与输出。第一步重点看返回了哪些行，第二步重点看每条消息实际使用了什么字段。消息文字通顺但公司与 URL 不对应，仍然是映射错误；不能只凭整个 Scenario 没有报错就交付。

Watch New Rows 只检查上次位置之后的新行，因此再次点 Run once，未必会重复处理同一批测试数据。官方教程提供 Choose where to start 等起始位置设置，用于调整测试范围。但把起点改回 All 可能重新处理旧记录；对于已连接发消息、写订单等动作的流程，重测前必须考虑重复执行的后果。

一轮运行为什么会出现多次操作？

可以把 bundle 理解为在模块之间传递的一组数据。在上面的例子中，一行企业资料可以形成一个 bundle。触发模块检查一次，若返回两条新记录，下游消息模块通常就需要分别处理两次，而不是只执行一次就天然合并成一条通知。

因此，在“一个检查动作加两次普通消息发送”的简化情形下，模块操作合计为 3 次。这是解释执行方式的示例，不是所有 Scenario 的统一账单公式；新增搜索、下载、分支或重试，都可能改变实际消耗。

如果需求是一条每日汇总，而不是每家公司一条消息，应考虑先聚合数据，再发送结果。Text Aggregator 等聚合模块可以把多个输入整理成一个输出 bundle，但要明确聚合的来源范围和每条记录的呈现格式。否则虽然消息变少，也可能失去原本需要保留的公司名、链接或分类。

Router 如何分流：不是并行，也不是只走第一条

Router 用于把流程分成多条路线，每条路线可以配置过滤条件。比如，把特定地区的线索交给一个处理步骤，把需要人工补资料的记录交给另一步骤。设计时应先想清楚：条件是否互斥，一条数据是否允许触发多个下游动作。

两条条件都满足时，可能产生两份结果

假设一条路线筛选“地区为美国”，另一条路线筛选“行业为 SaaS”，一家美国 SaaS 公司可以同时符合两者。如果你只想发送一条通知，就需要重新设计互斥条件，不能把 Router 当成编程语言里默认只命中一个分支的结构。

Make 文档说明路线按顺序处理，而不是同时并行执行。路线顺序会影响执行安排，但不会把重叠条件自动改成互斥条件。对于会写入外部系统的动作，应尤其注意一条记录是否会被多次处理。

Fallback 是未匹配时的去处

Fallback 路线用于其他路线条件都没有匹配的情况。它适合收集未能分类的记录，方便后续查看，而不是当作“无论发生什么都执行”的公共收尾步骤。若每条记录都必须写入一份总日志，应另外设计相应步骤，不能寄希望于 fallback 一定会运行。

在调试阶段，准备分别命中每条路线、同时命中多条路线以及全部不命中的样例，比只用一条正常数据更能暴露问题。模块历史中的输入输出，也能帮助区分“数据没有到达这里”和“到达后动作失败”。

Credits、Operations 和调度间隔要分开看

截至本次核验，官网 Free 方案列出每月 1,000 credits，定时运行最短间隔为 15 分钟。它适合验证简单流程，但不能据此推断所有触发方式都需要等待 15 分钟，也不代表任意规模工作流都可长期免费。实际应按触发类型、方案与模块规则计算。

AI 功能可能根据模型、token 用量和连接方式产生不同消耗；使用自己的模型供应商连接时，还可能单独向该供应商付费。估算成本时，先看一条数据经过哪些模块，再乘以数据量和运行频次，比沿用旧文“每月多少 operations”的说法更准确。

AI、代码和 Grid 各自扩展了什么能力？

Make 的 AI 应用连接、AI Toolkit、AI Agents 以及 MCP 相关能力，可用于把模型或外部 AI 客户端接入自动化。但不是每个分类任务都需要 Agent：字段完整且规则明确时，过滤器和固定模块通常更容易检查；需要理解自然语言或动态选择工具时，再考虑模型参与。

遇到现成模块难以处理的转换，可以评估 HTTP、Webhook 或 Make Code 等扩展方式。代码步骤并不消除运行限制和计费规则；连接企业内部系统也需要可达的网络与合适授权，不能因为平台有 HTTP 模块就默认能访问任意内网地址。

Make Grid 则主要帮助观察自动化之间的关系，把 Scenario、应用、数据存储和 AI 等依赖呈现出来。它适合流程变多后寻找依赖与影响范围，不等于代替每个 Scenario 完成调试，也不是自动补齐所有权限管理的万能面板。

Make 适合愿意把业务步骤拆开、检查每次数据传递的个人与团队。模板可以缩短起步时间，但正式启用前仍要回答三个具体问题：一条输入会产生几次外部动作，重复运行会不会重复写入，未匹配或失败的数据最终去了哪里。能解释这些，才算真正掌握了画布上的流程。