作为内容日历，Airtable 几乎是理想之选。同一份数据可以用表格视图和日历视图查看，附件和文字放在一起，支持多人协作，还能按活动建立不同的视图。
从这里走到真正发布出去的帖子，是一段不长的工作流，其中有两个细节决定了它是否可靠。
值得设置的字段
| 字段 | 类型 | 用途 |
|---|---|---|
| Content | 长文本 | 帖子内容 |
| Status | 单选 | Draft、Ready、Published |
| Channels | 多选 | 目标平台 |
| Publish at | 日期 | 排期发布时间 |
| Media | 附件 | 图片或视频 |
| Post URL | URL | 发布后写回 |
Airtable 的附件字段，正是它相较于表格文件在这里的真正优势：媒体文件和这一行数据放在一起，而不是一个你还得单独托管的 URL。
工作流程
1. 定时触发器（Schedule Trigger），每 15 或 30 分钟运行一次。
2. Airtable 节点，搜索记录，筛选条件为 Status = "Ready"。这是一道门槛，也是这个工作流不会把写了一半的行发布出去的原因。
3. 按发布日期过滤，如果这一行应该由它自己控制发布时间。
4. 从字段构建帖子内容，把多选的 channels 字段映射到频道列表。
5. BulkPublish 节点，Post → Create。
6. Airtable 节点，更新该记录。 把 Status 设为 Published，并把帖子的 URL 写回去。
第六步不是可选项
如果没有这一步”写回”，下一次运行时还是会找到同样标记为 Ready 的那些行，然后再发一遍。再下一次运行也是如此。一个每 15 分钟轮询一次的工作流，一天之内会把同一条帖子重复发布 96 次。
这是这类工作流出问题最常见的一种方式，而且这种失误一旦公开会相当尴尬。
如果想双重保险，还可以额外筛掉那些已经有 Post URL 的记录。两道独立的检查，这样一道失效了也不至于产生重复发布。
附件
Airtable 的附件自带 URL，你要传递的正是这个 URL。有两点需要了解。
附件的 URL 可能有时效性。 不要设计一个先存下来、几天后才使用却不重新获取的工作流。
要对照平台规则检查文件。 Airtable 可以毫无压力地存下一张 50 MB 的图片，而 Instagram 不会接受。媒体规则会在帖子创建时被校验，所以你会得到一个清晰的报错，而不是一次悄无声息的失败，但工作流本身也应该把这个错误记录到你能看到的地方。
排期发布还是立即发布
优先把 Publish at 字段映射到一个排期时间，而不是工作流恰好运行的那一刻就直接发布。
有两个理由：一行数据被标记为 Ready，往往是因为有人正坐在电脑前处理它，而这不一定是你受众正在阅读的时间；而且一条排期中的帖子，如果发现这一行数据有问题，仍然可以被取消。
先用草稿
在第一周，先创建草稿。这样你能在任何内容真正公开之前，看清楚字段映射实际落地的效果，尤其是频道和附件这两部分。
方案限额
- 频道： 免费版：3 个（每个平台 1 个）。Pro：30 个（每个平台 2 个）。Business：75 个（每个平台 5 个）。
- 帖子： 免费版：每天 3 条。Pro：每天 30 条。Business：无限。
- 每日 API 请求数： 免费版：30。Pro：5,000。Business：50,000。
一个每 15 分钟轮询一次的工作流，在发布任何内容之前每天就要消耗 96 次请求，所以免费档位只适合用来测试，而不适合用来真正运行这套流程。
BulkPublish 支持发布到 15 个平台。
简而言之
用 Status 字段做筛选，让草稿保持未发布状态，并在发布后写回 Airtable，避免这些行被再次抓取，这正是这类工作流产生重复帖子的原因。把 Publish at 字段映射到排期时间，而不是一触发就发布，并且对照平台的媒体规则检查附件。