社交媒体日历
将一条内容转化为多个频道的帖子，并放入 Airtable 日历供他人审批。发布通过 scripts/publish_approved.py 完成，该脚本将已批准的帖子交给 Upload-Post 的调度器。你只在用户要求时运行它。
字段名称、状态值和环境变量来自仓库中的 docs/data-model.md。不要重命名任何东西。下面的脚本路径是相对于本技能文件夹的。
开始之前
- 检查
AIRTABLE_TOKEN和AIRTABLE_BASE_ID是否已设置（环境变量或工作目录/仓库根目录下的.env文件）。运行python3 scripts/airtable_calendar.py channels作为冒烟测试。如果表还不存在，请将用户引导至仓库根目录的scripts/setup_airtable.py。 - 找到策略文件夹。如果设置了
STRATEGY_DIR则使用它。否则在工作目录、./my-strategy/和./strategy/中寻找strategy.md。如果没有，询问策略文件的位置。如果用户还没有策略文件，主动提供复制templates/strategy.md和templates/channels/_channel-template.md并在撰写任何帖子之前一起填写。
如果 Airtable MCP 连接器可用，你可以用它代替脚本进行读写。此文件中的规则仍然适用。请参阅 references/airtable.md。
工作流
1. 阅读策略和频道文件
完整阅读 strategy.md：目标、OKR、受众、内容支柱、全局规则。然后列出 channels/*.md 并阅读此内容可能投递到的频道的文件。每个频道文件包含该账号的风格、目标、节奏、格式、注意事项和示例帖子。
通过 Channel file 字段将频道文件与 Channels 表中的行匹配。只有 Airtable 中状态为 Active 的频道才能接收帖子。如果某个频道文件没有匹配的 Channels 行，请说明并跳过它。
2. 确定帖子类型和营销活动
确定内容是什么：功能发布、新闻、播客或视频片段、客户评论、活动照片、数据或文本见解、文章推广，或其他。阅读 references/post-types.md 了解每种类型如何转化为帖子、适合哪些频道以及分发范围。
给这批帖子一个 Campaign 标签，格式为 YYYY-MM <类型> <标签>，例如 2026-11 播客第12集 或 2026-11 功能 CSV导出。将原始输入放入 Source（链接、文件名、剧集或一行说明）。
仅当答案会改变帖子时才提问，例如策略未明确说明时的“哪些频道？”或“这个是否有发布日期禁令？”。否则，由你决定并说明你的决定。
3. 查看日历
列出你要填充的时段内已经计划好的内容（默认为接下来的 4 周，播客片段则更长）：
python3 scripts/airtable_calendar.py list --from today --to +28 --json > /tmp/calendar.json
对于每个目标频道，确定：
- 节奏缺口。 每周帖子数量与频道文件目标的对比。统计除
Rejected和Failed之外的所有状态。 - 冲突。 该频道已有帖子的日期。默认情况下每个频道每天最多一个帖子，除非频道文件另有说明。
- 主题组合。 一周内某种类型过多（三条新闻帖子，连续两条推广）。将新帖子推到内容较少的周。
- 重复。 相同信息已安排或近期已发布。
create命令会运行相似度检查。你也可以单独运行check-duplicates。
4. 起草帖子
每个频道每个日期写一篇帖子。每篇帖子均遵循该频道的文件：风格、长度、格式、话题标签、行动号召。适用于所有地方的规则：
- 仅使用来源或策略文件中的事实。不要编造数字、引用、客户名称或结果。
- 不要在频道间粘贴相同文本。创始人的个人简介和公司页面关于同一功能要说不同的话。
- 员工和联合创始人频道以该人的风格撰写，并需要其审批。将
Owner设置为频道文件中指定的审批人。 PostContent保存最终文本，包含真正的换行符。表情符号和 Unicode 是可接受的。话题标签内联在文本中，通常放在末尾，按频道文件的要求。- LinkedIn 和 X 会将
**text**显示为字面星号。仅在人类会粘贴到支持 Markdown 的编辑器（如 Substack）的频道中使用**粗体**。如果频道文件另有说明，则遵循它。 - 长度限制：X 将超过 280 个字符的任何内容拆分成线程，Threads 超过 500，Bluesky 超过 300。除非频道文件要求线程，否则写适合的长度。
- 遵循
strategy.md中的写作规则。如果其中没有规则，则写简单直接的句子，跳过填充词、夸张词汇和套话。
5. 选择日期
Scheduled for 仅为日期，格式 YYYY-MM-DD。时间来自频道的 Post time 和 Timezone，所以不要在帖子中包含时间。
- 优先填补节奏缺口，然后分散剩余帖子。一个项目的推广帖子分布在 2 到 3 周内，不要全放在同一天。
- 新闻在同一天或第二天发布，否则不发布。
- 播客片段大约每个频道每周一到两篇，持续约 3 个月。
- 混合一周内的类型：教育、互动、产品、社交证明。
- 绝不要使用过去的日期。仅当用户要求且知道每日发布可能已经进行过时，才使用今天。
- 如果一周已满，将帖子移至下一周并在报告中说明。
6. 托管媒体
Airtable 仅接收公开 URL。本地路径和 file:// 链接会被静默忽略。创建批次中的图片和视频可以是本地路径。脚本会先将它们上传到 catbox.moe，然后将公开 URL 传递给 Airtable，Airtable 将文件复制到自己的存储中。Catbox 上传说说是公开且不可删除的，所以不要用于任何机密内容。在这种情况下请让用户更换其他托管方。详情请参阅 references/airtable.md。
对于需要视觉效果的文本和数据帖子（Instagram、TikTok 或要求视觉效果的频道文件），制作一张简单图片。遵循 references/visuals.md。
7. 创建记录
将批次写为 JSON 列表，使用 Posts 字段名称：
[
{
"Name": "功能 - CSV 导出",
"Status": "待审批",
"Scheduled for": "2026-11-12",
"Channel": "Brightloop LinkedIn",
"PostContent": "您现在可以将任何报告导出为 CSV。\n\n单击右上角即可。",
"Media": ["/tmp/csv-export.png"],
"Source": "发布说明 2026-11-10",
"Campaign": "2026-11 功能 CSV导出",
"Owner": "[email protected]"
}
]
按如下方式选择状态：
| 情况 | 状态 |
|---|---|
| 准备好让所有者审阅（默认情况） | To approve |
| Instagram、TikTok、YouTube 或 Pinterest 帖子尚无媒体 | Needs media |
| 用户想先在文字上来回推敲 | Draft |
| 用户明确代表自己的频道审批（见下文） | Approved |
先进行空跑，向用户展示计划，然后创建：
python3 scripts/airtable_calendar.py create /tmp/batch.json --dry-run
python3 scripts/airtable_calendar.py create /tmp/batch.json
create 会验证字段名称、状态、日期和频道名称，将缺少媒体的纯图片平台帖子降级为 Needs media，并且在发现可能的重复时拒绝写入。修复批次，或者如果用户确认想要重复，则传递 --allow-duplicates。它以每批 10 条记录写入。存储在 CSV 中（包含列 Date, Channel, Content Type, Post Text, Hashtags, Image Suggestion）的计划可以直接用 --csv 导入。
8. 报告结果
以表格结束，每个创建的记录一行，按日期排序：
| 日期 | 频道 | 状态 | 名称 | 首行 |
|---|
在其下方，用纯文本句子列出：跳过的频道及原因、推后到更晚周的帖子、处于 Needs media 状态的帖子及其需要的内容，以及所有者应检查的任何内容（声明、名称、链接）。
其他请求
- “给这些帖子添加图片。” 运行
python3 scripts/airtable_calendar.py attach <record_id> <file or URL>。处于Needs media状态的帖子会自动移至To approve。 - “移动这个帖子”、“拒绝那个。” 运行
update <record_id> --set "Scheduled for=2026-11-20"或--set Status=Rejected。如果帖子已经是Scheduled状态，之后运行python3 scripts/publish_approved.py --sync以使 Upload-Post 的副本也更新。 - “这周要发布什么？” 运行
list --from today --to +7并按频道和日期汇总。 - 更改策略或风格。 编辑 Markdown 文件，而不是 Airtable。每周的
social-calendar-review技能会提出这些编辑建议。
代表用户审批
仅在用户明确说明时（“审批我的”、“这些可以直接发布”），且仅限用户是 Owner 的频道。绝不要审批员工或联合创始人简介的帖子，即使被顺带要求。引导用户联系该人。将这些记录设置为 Approved，可以在创建时或通过 update <record_id> --set Status=Approved 实现，并在报告中单独列出。
移交给发布系统
当用户要求安排已批准的帖子时（“安排所有已批准的内容”、“将这些发布出去”）：
- 运行
python3 scripts/publish_approved.py --sync --reconcile --mode schedule --dry-run并展示它将发送的内容：频道、日期和时间、媒体类型、文本首行。 - 用户确认后，不带
--dry-run运行。Upload-Post 保存计划，帖子变为Scheduled。 - 如果任何已批准帖子的时间段已过去，请提及并提供
--mode now。
用户可能也有例行程序或 cron 任务运行该脚本，在这种情况下已批准的帖子会被自动安排。阅读 references/publishing.md 了解重新安排、取消、对账和完整字段映射。优先使用脚本而不是自己调用 Upload-Post，因为脚本每个帖子不消耗令牌。
绝不要发布或安排用户在本对话中未要求的内容。将记录写为 To approve 是本技能的正常结束。