在发布前选择自然社媒渠道时…

当需要决定运营哪些自然社媒渠道、是否该上某平台时，用受众证据和平台能力匹配来规划渠道组合并做人力预算体检。

适用场景

解决思路

1. 确认目标与受众证据：明确社媒要服务的成果，以及受众实际花时间的地方；遵循「人→目标→策略→技术」的顺序（Forrester POST 方法，Li & Bernoff《Groundswell》2008 为引用先例，评分仍按 ECHO）。若没有受众证据（无人设、无访谈、无分析数据），以 NEEDS_INPUT 停止并转交 audience-mapper，绝不凭「大家都在那」的传闻选平台。
2. 声明运营画像：根据运营模式选择 program-maturity-community、program-maturity-b2c 或 program-maturity-founder；它决定适用的项目证据，而非任意权重，也不影响独立的资产门槛。
3. 构建能力与匹配矩阵：每个候选平台一行，按目标实际需要评估发布、评论、私信、洞察四项能力，并引用 social-platform-access.md 中的访问类别。若受众证据指向中文平台（小红书/微信公众号/视频号/抖音），将其纳入，访问类别为 manual-package 或 user-export；在这些平台上做任何发布/互动自动化是硬红线（风控/封号），本库所有平台同理。
4. 做节奏-预算现实体检：估算每渠道每周发布与运营（评论和私信计入预算；只发不回的渠道会在 ECHO 的 H 项失败而非 E 项）所需小时数，与所述人力对比。选择能配人的渠道，而非存在的渠道。每个小时数字标注为 User-provided 或 Estimated；关于「最低发帖频率」的平台传闻标为 Estimated 并注明来源，绝不作为评分规则。
5. 把相邻需求分流到边界表：付费社媒投放→campaign-architect（ROAS 纪律）；放大自然爆款→content-amplifier；创作者合作→campaign-planner；发布日 PH/HN/目录提交→community-launch-runner；邮件/通讯渠道→email-sequence-designer（SEND 纪律）。在表中记录每项分流需求，不在此执行。
6. 选择层级：primary（完整配人节奏）、secondary（缩减节奏）、watch（仅监听，不承诺节奏）。每个选择附一行理由，追溯到矩阵某行加预算；每个拒绝注明原因（能力不匹配、无法配人、受众缺席）。
7. 提交提案事件：对每个选中渠道，通过 registry-events.py 提交平台、已知 handle、目标、运营画像、拟定节奏、访问类别和层级。绝不写档案、绝不把状态设为 proposed 之外、绝不把拟定节奏当作已承诺；由注册表接受或拒绝。
8. 交接：交付组合文档并推荐 voice-dossier-builder；若排队 3 个以上提案事件，同时提示 channel-registry 应做一次晋升扫描。
9. 保存结果：交付后询问「是否保存以供未来会话使用？」确认后保存到 memory/social/channel-portfolio-planner/YYYY-MM-DD-<topic>.md；注册级事实（渠道选择作为 proposed 状态行、拟定节奏）仅通过授权 operation: propose 请求 registry-events.py 写入 memory/events/channels.ndjson，绝不直接写 memory/channels/ 档案或常驻文件。未经询问不得写内存。

适用边界 · 注意事项

• 仅需记录渠道的规范事实时——应使用 channel-registry。
• 缺少受众证据（无人设、无访谈、无分析数据）时——应先转交 audience-mapper 构建证据。
• 需要执行付费投放、创作者合作、发布日提交或邮件序列等相邻任务时——应分流给各自负责的技能。