Odoo 社交传播为什么不能靠“把图发出去”：责任人交接、营销卡协作与分享治理讲透

先说结论

社交传播最容易翻车的，不是“能不能发出去”，而是：

• 这个品牌到底该用哪个官方账号出口
• 这次传播素材由谁负责推进
• 审核与催办有没有留痕
• 外部分享之后，内部是否还能看到谁动了、谁没动

在 /home/ubuntu/odoo-temp/addons/social_media/models/res_company.py 与 addons/marketing_card/models/card_campaign.py、card_card.py 里，Odoo 给出的不是一个巨大的“发帖按钮”，而是一套更偏治理的结构：

1. 公司级社媒身份字段统一出口
2. campaign 级责任人与协作上下文承接动作
3. 分享请求、奖励文案、预览卡由 campaign 统一管理
4. shared / visited 状态把执行回写到单张 card

所以这条链真正解决的问题，不是“能不能做海报”，而是：

一次社交传播从品牌出口、内部协作到外部转发，能不能围绕同一个对象被管理。

第一层：为什么公司上的 social_* 字段虽然简单，却非常重要

res.company 在 social_media 里只加了几类字段：

• social_twitter
• social_facebook
• social_github
• social_linkedin
• social_youtube
• social_instagram
• social_tiktok
• social_discord

看起来很轻，甚至有点“这不就是几条账号字段吗”。

但它背后的治理价值很高。

因为大多数团队的社交传播问题，根本不是缺少发帖工具，而是品牌出口不统一：

• 不同同事用不同账号名
• 官网、邮件、海报上的社媒入口不一致
• 活动页挂一个账号，营销卡文案里又写另一个账号

一旦公司层没有“官方出口”这层锚点，后面所有 campaign 都会越来越散。

所以 social_* 字段虽然不花哨，却在做一件很基础也很必要的事：

先把品牌官方身份收口。

没有这一层，所谓社交传播审批，最后常常只是审批一堆互相不一致的文案。

第二层：为什么 marketing card campaign 更像传播项目单，而不是图片模板

card.campaign 的继承非常说明问题：

• mail.activity.mixin
• mail.render.mixin
• mail.thread

这意味着 campaign 一开始就不是纯素材对象，而是：

• 可以分配责任
• 可以挂协作活动
• 可以留下讨论记录
• 可以渲染动态内容

同时它还有：

• user_id 负责人
• request_title
• request_description
• reward_message
• reward_target_url
• post_suggestion

这已经很接近一张完整的传播任务单了。

也就是说，Odoo 这里真正想管理的不是“图片文件”，而是：

• 要传播什么
• 希望谁去传播
• 给对方什么默认文案
• 传播后跳去哪里
• 成功后怎样反馈和激励

这对社交营销非常关键。 因为真实团队协作里，卡在半路的从来不是出图，而是交接。

第三层：为什么责任人与 activity 协作就是最现实的审批抓手

不少团队提到“社交审批”，脑子里都是复杂工作流。 但对中小团队和多数活动营销来说，真正实用的反而是更轻的机制：

• 一个明确的 user_id
• 一组 mail.activity
• 一条贯穿 campaign 的 thread

这套东西虽然不叫“审批流引擎”，但已经覆盖了最现实的治理需求：

1. 谁是当前 owner

传播任务不会永远漂在团队公共池里。

2. 谁该在什么时间前补内容、确认发布

activity 本质上就是催办和待办。

3. 讨论和改动为什么发生

thread 让传播对象本身成为协作上下文。

很多公司社媒执行之所以混乱，不是因为少了一个“批准按钮”，而是因为：

• 设计在群里发图
• 市场在私聊改文案
• 销售再转给合作伙伴
• 最后没人说得清版本是谁定的

而 card.campaign 这种对象化协作，恰好就是在压缩这类隐形混乱。

第四层：为什么 preview_record_ref 很像“发帖前审样锚点”

preview_record_ref 要求 campaign 绑定一个预览记录，这一点特别重要。

因为社交传播最怕的是：

• 模板很好看
• 但换到实际记录上就爆版
• 动态字段为空
• 图片比例不对
• 链接文案和对象不匹配

而 Odoo 的做法是先把 campaign 绑定到某个实际记录，再生成 image_preview。

这背后的逻辑非常适合作为“发帖前审样”机制：

• 你不是审批一张抽象模板
• 你是在审批它对某个真实对象的最终落地效果

在活动传播里这尤其重要。 因为 booth、track、registration、partner 这类对象一旦动态字段缺失，最终出来的海报和分享页就会非常尴尬。

所以 preview 不是小功能，而是治理动作里的“样稿冻结点”。

第五层：为什么 campaign 会把“请求你来分享”和“分享后回报你什么”放在一起

request_title、request_description、reward_message、reward_target_url 这组字段很有意思。

它们说明 Odoo 不是把社交传播理解成后台单向发布，而是更像一种请求式传播：

• 我希望你帮我扩散
• 我给你明确的传播对象
• 我给你默认文案和入口
• 传播完成后，我还给你一个反馈页或奖励动作

这特别适合几类场景：

• 活动主办方向演讲嘉宾要转发
• 招商团队邀请赞助商帮忙扩散
• 培训团队请学员社群帮忙宣传课程

社交传播真正难的，常常不是品牌自己发一次，而是如何让相关方愿意转发且不跑偏。

Odoo 在 campaign 里把请求与回报放在同一对象上，就是在降低这种协同摩擦。

第六层：为什么分享治理一定要落到 card 级别，而不是只看 campaign 总数

card.card 里最关键的不是图片本身，而是：

• 每个 campaign_id + res_id 唯一
• share_status 记录为 shared 或 visited

而 card.campaign 会进一步聚合成：

• card_count
• card_share_count
• card_click_count

这套设计很聪明。

因为社交传播最怕一种假繁荣：

• campaign 建了
• 邮件发了
• 群里也转了
• 但到底多少对象真的去分享、多少只是点开看过，没人知道

把状态落到 card 级别之后，你才有机会回答：

• 哪些对象真的完成分享
• 哪些对象只访问没转发
• 哪个 campaign 的参与度高

这比“发出去多少封邀请邮件”更接近真实传播效果。

第七层：为什么真正的社交治理，不一定要内建全平台发布器

从当前源码看，Odoo 在这里更强调的是：

• 品牌身份统一
• 动态卡片资产统一
• 分享请求统一
• 执行状态统一
• 协作和催办统一

而不是把所有平台 API 发布细节都塞进同一个模型里。

这其实是很现实的取舍。

因为对很多团队来说，最大的风险不是“平台 API 少一个按钮”，而是：

• 传播入口不统一
• 责任不清
• 样稿没审
• 合作伙伴拿到错误版本
• 分享后无法回看执行情况

所以 Odoo 这里更像是在搭一个社交传播控制面，而不只是一个“群发工具”。

最后一句

社交传播真正需要管理的，不只是帖子内容，而是整条交接链：

• 品牌官方出口是谁
• 这次 campaign 由谁负责
• 审样和修改围绕哪个对象进行
• 谁收到分享请求
• 分享后系统能不能看到执行结果

把这些都落在 company、campaign、card 这三层对象上，社交营销才会从“大家帮忙转一下”升级成真正可治理的流程。