在 Notion 里规划内容，再手动发布出去，这道缝隙正是本文要弥合的。Zap 本身很简短。数据库的设计，以及两个具体的陷阱，才是决定它能不能正常运作的关键。
先设计好数据库
| 属性 | 类型 | 用途 |
|---|---|---|
| Content | 文本 | 帖子正文 |
| Status | 单选 | Draft、Ready、Published |
| Channels | 多选 | 目标平台 |
| Publish at | 日期 | 什么时候发出去 |
Status 不是可选项。 一个 Notion 页面从被创建的那一刻起就对集成可见，哪怕有人正在往里打字。没有门控，你会把写到一半的想法发布出去。
具体的 Zap
触发器：Notion 中的”更新数据库项目”。 监视这个数据库。
筛选：仅当 Status 为 Ready 时才继续。 这就是门控。
格式化，可选。 清理文本。
动作：在 BulkPublish 中创建帖子。 内容、频道、计划发布时间。
动作：更新 Notion 中的数据库项目。 把 Status 设为 Published。
两个陷阱
陷阱一：没有写回状态。 如果 Zap 没有把 Status 设为 Published，这一行就会一直保持 Ready。之后对这个页面的每一次编辑都会重新触发 Zap，把它再发一遍。这个错误会产生重复的帖子，而且一旦发生就是公开可见的。
要把状态写回去，如果想要第二道保险，可以再筛掉那些已经有帖子 URL 的行。
陷阱二：Notion 的富文本。 Notion 的内容是结构化的：标题、加粗、项目符号、折叠块、行内链接。而社交平台只接受纯文本。
如果原样传递一个 Notion 区块，你会得到被原样渲染出来的 markdown 字符，或者——如果字段映射选错了属性——一条空帖子。要专门提取纯文本，并在信任它之前，先看看一条真实的记录实际生成了什么。
你真的需要 Zapier 吗
有一个直接的 Notion 集成，不用中间夹一个 Zap 就能发布内容。如果你的工作流就是”这一行标记为就绪，帖子就发出去”，那种方案环节更少，也没有按任务计费的成本。
只有当你需要介于两者之间的东西时，才值得搭建这个 Zap：按多个属性筛选、转换文本、按内容类型路由，或者把 Notion 和另一个数据源连接起来。
用排期发布，不要在触发时就直接发布
把 Publish at 属性映射到一个计划发布时间。行被标记为 Ready 的时候，通常是有人正坐在桌前的时候，而这很少是你受众在看内容的时候。而且一条已排期的帖子，如果发现这一行数据有问题，依然可以取消。
先跑草稿
先跑一周的草稿。富文本处理是最容易出错的部分，而在一堆草稿列表里，出错是立刻能看出来的。
套餐限制
- 频道数： 免费版：3 个（每个平台 1 个）。Pro：30 个（每个平台 2 个）。Business：75 个（每个平台 5 个）。
- 帖子数： 免费版：每天 3 条。Pro：每天 30 条。Business：无限。
- 每日 API 请求数： 免费版：30。Pro：5,000。Business：50,000。
BulkPublish 支持发布到 15 个平台：Facebook、Instagram、TikTok、YouTube、X、Threads、Bluesky、Pinterest、Google Business Profile、LinkedIn、Mastodon、Discord、Telegram、Tumblr 和 Snapchat。
简而言之
用 Status 属性做门控，否则你会把草稿发布出去。发布之后要把 Status 写回去，否则之后每一次编辑都会重新发布这一行。要提取纯文本，因为 Notion 的格式经不起这趟旅程。而且在给自己添一个需要维护的 Zap 之前，先看看那个直接的 Notion 集成是否已经覆盖你的场景。