如何把你用 AI 做的应用，接入你已经在用的那些工具

一个 AI 做的应用，常常会迎来这样一个时刻：它能用了，你用了一个星期，然后你注意到自己一直在把数据从里面往外抄。

也许你把新的客户注册信息粘贴进一张你的销售同事会看的 Google Sheet 里。也许你在手动把提交上来的表单转发到一个 Slack 频道。也许你团队的日历在一个地方，你的预约在另一个地方，而你就是夹在两者之间的”人肉胶水”。

这时候就该把你的应用接入其余的工具了。你不需要开发者。你需要的是把”什么该跟什么对话”想清楚，再就怎么对话做几个决定。本文就是一份指南，教你让它融入你已经在用的工具集。

关于集成的大实话

大多数人把集成想成一个你加上去的功能，就像深色模式或搜索框。它们不是。集成是两个系统之间的一种约定 —— 关于谁拥有哪部分数据，以及当某样东西发生变化时该做什么。

在让你的 AI 构建器”接入 Slack”之前，先回答三个问题：

我应用里的哪些变化，应该触发别处的某件事？（一次新注册、一次状态更新、一个上传的文件。）
当这些变化发生时，别处应该做什么？（发条消息、加一行、发封邮件。）
有没有东西需要反向流回我的应用？（有时答案是”没有”，那就轻松多了。）

这三件事你想得越清楚，集成就越简单。集成之所以会变得一团乱，原因通常不在技术 —— 而在于没人提前决定，对于某条信息，到底是哪个系统”拥有”它。如果你的应用和你的 Google Sheet 都自认是客户邮箱的权威来源，那你就得没完没了地去对账了。

接通东西的三种方式

把你的应用接到其他工具，基本上有三种模式。挑那个合适的，剩下的别想太多。

1. 对外通知（单向输出）

这是最简单的一种，而且它覆盖的场景比人们以为的要多。你的应用做了某件事，它就往某处发一条消息。完事。

例子：

一次新的表单提交，发到一个 Slack 频道。
一位新客户，通过你的邮件工具触发一封欢迎邮件。
一个上传的文件，自动复制一份丢进共享的 Google Drive 文件夹。

告诉你的 AI 构建器：“当一个新项目被创建时，往一个 Slack 频道发一条消息，包含项目名称、客户名称，以及一个指向项目页面的链接。” 这就是一条指令，大多数构建器会用一个 webhook 或内置的 Slack 集成把它接好。

这个模式之所以管用，是因为没有任何东西反向流回来。Slack 不会试图去更新你的应用。你的应用是”发了就不管”。哪怕 Slack 宕机一小时，你的应用照样运转 —— 你只是收不到通知，等它恢复了就好。

2. 定时同步（按时钟，单向输入或输出）

当你有一个由别人更新的工具，而你的应用需要知道那些变化时，最简单的模式就是定时同步。每小时一次，或每天一次，你的应用把最新数据拉进来。

例子：

每天一次，把 Google Sheet 里的新行拉进你的应用，作为待审核的草稿条目。
每小时一次，从你的日历刷新即将到来的预约清单。

这之所以比实时集成轻松得多，原因在于：顺序无所谓。如果今天的同步失败了，明天的同步会把一切补上。你不必像处理实时连接那样去应对每一种边界情况。

大多数 AI 构建器，一条指令就能设好一个定时任务：“每天早上 8 点，从这个 Google 表单获取新的回复，并在 Submissions 表里为每一条创建一条记录。“

3. Webhook（实时模式）

第三种模式，也是需要小心对待的那一种，是 webhook。一个 webhook，就是另一个工具在某件事发生时发给你应用的一条小消息。它是定时同步的实时版本。

Webhook 很强大，正经的集成都是这么搭出来的。但它也是 AI 做的应用最容易翻车的地方，因为你既要信任另一个服务能把数据正确地发给你，又要信任你的应用能处理好它收到的一切。

在下列情况下使用 webhook：

你需要在几秒内、而不是几分钟内得到响应。
来源工具提供了它（大多数现代工具都有）。
你愿意去测试那些失败的情况 —— 如果同一个 webhook 来了两次怎么办？如果它永远没来怎么办？

一条合理的 webhook 指令：“在 /webhooks/stripe 添加一个 webhook 端点，接收支付事件。当一笔成功的支付到达时，按邮箱找到对应的客户，把他们的状态更新为 ‘Paid’。” 然后去测它。发一笔假支付。发一笔真的。连着发两笔。

Zapier 的问题

很多人想接通东西时，第一个想到的就是 Zapier 或 Make。这有个很好的理由 —— 那些工具本身就是把集成做成了一个产品。它们给你一个可视化构建器，让你去连”当工具 A 里发生 X 时，在工具 B 里做 Y”。

你完全可以把 Zapier 和你 AI 做的应用一起用。最干净的模式是：

当有趣的事情发生时，你的应用往 Zapier 发一个 webhook。
由 Zapier 来负责扩散 —— Slack 消息、邮件通知、表格行、CRM 更新。

为什么要绕道 Zapier，而不直接让 AI 构建器接入每一个工具？两个原因。第一，等你明天又想顺便创建一张 Trello 卡片时，你在 Zapier 里两分钟就加上了，不用去让 AI 构建器重新部署。第二，如果某个下游工具改了它的 API（它们确实会改），Zapier 会替你处理，你完全不用碰你的应用。

代价是成本。如果你的量很大，Zapier 会很快变贵。如果你每月发送的事件不到几百个，Zapier 大概是对的选择。如果你发的是几万个，那就让 AI 构建器直接集成。

在信任它之前要测什么

集成会悄无声息地失败。这是它们最糟糕的脾性。你的表单也许某天就不再同步到表格了，而你直到一个星期后、有人注意到表格少了十二行，才会发现。

任何你新增的集成，都跑这三个测试：

**它端到端真的能用吗？**别只是确认你的应用发出了消息。去目的地工具里，确认那条消息到了、而且看起来没问题。
**目的地宕机或出错时会怎样？**把你的 Zapier zap 暂停掉。提交数据。你的应用是优雅地处理了，还是直接报错、连本地数据都不肯保存？（你想要的是优雅那种。）
**有没有办法重试或重发？**如果出了岔子，你能针对某一条特定记录重新跑一遍集成吗？如果答案是不能，那你就搭了一道单向的活板门。

如果你的 AI 构建器没主动给出这些问题的答案，那就问。“我怎么知道一条 Slack 消息有没有发送失败？” 是个合理的问题，而答案应该类似于”错误会记录在这里，你可以从这个页面重试”。

一个合理的起点

如果你才刚开始加集成，这里有个务实的顺序：

一个对外通知 —— 挑那个最有用的。“当一条新线索进来时，发到 Slack”，或者”当一个项目被标记为已完成时，给客户发封邮件”。
一个定时同步 —— 通常是把数据从你的应用里拉出来，送到你团队已经在用的地方（一张共享表格、一个 CRM）。
然后，只在你真的需要时，为某一个特定的实时场景加一个 webhook。

大多数应用永远用不上比这更多的东西。那些用得上的应用，都在经营真正的生意，而等你做到那个规模时，你会非常清楚自己缺哪些连接。

如果你盯着一个 AI 做的应用，觉得它像座孤岛，那就挑那个本周最能帮你省下复制粘贴的集成，从它开始。等那一个跑通了，剩下的自然就一目了然了。