← 目录
otter-coordinator · 周会 · 2026-07

重构 Engagements

让系统认得出老朋友、说得清「现在等谁」、对得上账。
两半分工:CRM 聊天 · Studio 制片 —— CRM 不动,日常沟通零影响。

数字均来自线上库直查 · 方向键 / 空格翻页 · 第 5 页可以点

01 · 运营的三个日常痛点

今天每天都在发生的三件事

①

认不出老朋友

同一个达人第二次合作,系统当新人 —— 上次多少钱、靠不靠谱,全靠翻聊天记录。 5,460 个邮箱可证明的复购;最夸张的一位达人是 20 条互不相干的记录(下页真人案例)。

②

说不清「现在等谁」

催办只能发「有更新吗?」。更糟:打包合作第 1 条片发布后,其余几条的催稿静默消失(线上正在发生的 bug)。

③

对不上账

谈成价格 2,036 条,实付有记录的只有 16 条 —— 「按谈成的价付了没?」这个问题,系统答不出来。

02 · 为什么

两个根因,都不是谁的锅

① 达人身份在交接处丢了。 平台早就有完整档案(247 万联系人、445 万社媒账号),但谈判系统一条外键都没连过去, 自己拿文本字段重记 —— 于是一个人裂成 N 条互不相干的记录。
② Java 侧的 campaign 是「招募批次」,不是「合作项目」。 换个月份、换个平台、找不到人重开,都是一条新 campaign(88% 是重开)—— 我们一直拿它当业务容器,复购和汇总自然乱。

顺带:这也是系统每轮重读全部聊天记录、LLM 成本居高的根因 —— 一并解决,细节在文档站。

03 · 方案

两半,四个词

Engagement= 这个达人。所有合作、渠道、历史价格、可靠度,都在这一个记录下
Collaboration= 一次合作。挂合同、打包报价、实付账本;可打包多人
Deliverable= 一条泳道。每条片子独立推进:等谁 · 缺什么 · 卡多久 · 付了多少
Campaign= 活动方向。边界 = 提报总表:能进同一张提报/进度总表的就是一个(8、9 月同表即同一个);Java 侧降级为只读招募批次
CRM聊天。threads 按 Campaign 分组;完全不依赖 LLM,永远可用的地板
Studio制片。泳道推进做片;自动化 L0→L3 全局渐进,高危转人工

工程量:达人层直接接平台现有数据,76.6% 存量自动接上 —— 独立评审结论:「20% 新模型,80% 接线」,不是重写系统。
建档从「议价成功、运营 pick」那一刻开始 —— 谈判上游暂不动。

04 · 线上真人案例 · 可以点

三个真实达人,Before / After

@anvi__lifestyle IG 39.6万粉 · 近12条中位播放 66.7万 · collab.a***@gmail.com
20 条互不相干的记录 20 个不同的 kol_id 608 行会话投影 = 同样 30 条对话复制 20 遍 复购历史:不可见
#1 Pippit US April Promotion delivery·archived · 挂 31 条会话
#2 CapCut En Promotion April-copy delivery·archived · 挂 30 条会话
#3 MiniMax AI USA April Promotion delivery·active · 挂 31 条会话
#4 Temu North America May Tech collab delivery·active · 挂 30 条会话
#5 Pippit South Korea Promotion delivery·archived · 挂 30 条会话
… 还有 15 条,每条都当 TA 是新人

真实数据(2026-07-27 生产库)。20 条记录互相不知道对方存在 —— 每次合作都从零开始认识这个人。

1 个 Engagement 5 个 Campaign · 20 条 Collaboration 30 条会话只存一份,按 Campaign 分组 复购一眼可见
Pippit(全球推广)7 次合作US·BR·KR·ES·DE·EN·Global ▾
Pippit US April 已交付2026-05
Pippit Global 2026 进行中最近一条 · 复购第 7 次
+ BR / KR / ES / DE / EN March 共 5 条已结
CapCut(剪辑工具)5 次合作▾
En April → ES April → JUNE → PC 2606 → Web IG July(进行中)—— 同一方向被旧系统拆成 5 个"campaign",新模型里是一个 Campaign 下的 5 轮复购
Temu(北美+区域)4 次合作▾
May Tech(active)· May AI Fashion(谈判中)· CE-HUN · Malaysia —— 按提报表可再归组,运营半天定
MiniMax + TikTok2 + 2 次▾
MiniMax ×2 · TikTok Lite US · TikTok US 2026

分组按品牌方向演示;正式归组由运营按「同一张提报总表」判定。点组名可展开。

@bengeskin IG 19.7万 · TT 8.5万(中位 11.4万)· X 34.9万 · b***n@gmail.com · WA +371 26** **35
Temu May Tech:15 条交付物 状态全部 = in_progress 日期 0 · 金额 0
#1 in_progress#2 in_progress#3 in_progress #4 in_progress#5 in_progress#6 in_progress #7 in_progress#8 in_progress#9 in_progress #10 in_progress#11 in_progress#12 in_progress #13 in_progress#14 in_progress#15 in_progress

真实数据,一字未改:15 条一模一样 —— 哪条在等脚本、哪条已发布、哪条该催,系统一概不知,全靠运营脑子记。

Campaign · Temu 科技交付中15 条泳道 ▾
Reel 1–6已发布发布链接已归档,待录入实付▾
6 条发布证明各自带消息引用;付款按聊天采集→运营确认
Reel 7等我们样片 v2 等我们审 · 达人已交超时 2 天▾
达人 · WhatsApp(演示引文,结构即真实形态)“Sent the updated cut for reel 7, trimmed the intro as discussed.”
等我们超时会先催内部,不打扰达人
Reel 8等达人缺 开场 3 秒产品特写(我们提的意见)9 天▾
我们 · 邮件(演示引文)“开场 3 秒先给产品特写,再进使用场景 —— 其余都好。”
缺口指向具体一条意见,催办可以指名道姓
Reel 9–15脚本期7 条并行推进,互不阻塞 —— 今天它们全叫 in_progress▾
每条独立阶段:选品 ✓ → 寄样 ✓ → 脚本(3 条待达人 / 4 条待我们复核)
Campaign · CapCut 剪辑工具谈判中▾
Web IG July · 建议起价按 Campaign 规则由 TT 中位 11.4万 自动算出,运营决定是否直接用(决定 11)

泳道阶段为演示状态 —— 因为今天的系统里这 15 条真的完全分不出来,这正是要修的。

@tech_with_nandini 13 条记录 · 12 个旧 campaign
社媒档案 4 行,躺在另一张表 TikTok 还重复建了 2 行 谈判系统只存了 handle 文本
creator_profiles youtube · 27.1万订阅 · 中位 1.1万 ← 报价该看这个,但系统连不到
creator_profiles instagram · 63.5万粉 · 中位 11.7万
creator_profiles tiktok · 3.1万粉 重复行:2.1万粉那条也是 TA
coordinator creator_handle = "tech_with_nandini"(纯文本 ×13 遍)

四行档案真实存在、指标齐全 —— 但 coordinator 一条外键都没连,报价时等于全瞎。

1 个 Engagement · 社媒组 3 个平台 重复 TT 行合并 指标直接喂报价建议
YT 27.1万订阅 · 中位 1.1万 IG 63.5万粉 · 中位 11.7万 TT 3.1万粉 · 中位 1.8万 Snapchat:只记 handle,供分发
CapCut(剪辑工具)5 次合作▾
Web April → May → May YT → PC 2606 → Web IG July:旧系统 5 个 campaign,新模型 1 个 Campaign 复购 5 轮 —— YT 单和 IG 单各挂对应社媒账号
Pippit ×3 · MiniMax ×2 · Temu · TikTok7 次合作▾
跨 YT/IG 两条社媒线的合作在同一个 Engagement 下,历史价与按时率共享

同一个人在 YT 和 IG 的报价不同(中位 1.1万 vs 11.7万)—— 新模型里 Deliverable 挂具体社媒账号,报价规则各算各的。

点 tab 换达人 · 点 Before/After 切换 · 点组名/泳道展开 · 数据取自 2026-07-27 生产库(邮箱/手机已脱敏,泳道阶段与引文为演示)

05 · 关键保证

CRM 不动 —— 日常沟通完全不受影响

照常运行 · 零迁移 · 零停机
  • 收件箱、消息收发、已读状态
  • 29.1 万条会话线程原地不动
  • 邮件 / WhatsApp / XDM 全渠道照常
  • 手工回复、内部备注照常
暂停重建 · 按批灰度 · 可回退
  • 只暂停 agent 的自动动作(现成的逐合作开关)
  • 暂停期间这批由人工跟进,消息一条不丢
  • 新状态从消息重建,比对一致才切回
  • 达人那边完全无感知
06 · 节奏

怎么推进,需要大家什么

1三个先行小修(与重构无关,本周可发):催办停摆 bug · 沙箱与生产隔离 · 消息入库清洗
2Campaign 归类 —— 需要运营半天:112 个现有分组归入 60–80 个 Campaign。判据一句话:「能不能单独出一张提报表 = 对接人是不是同一批」
3实付数据源确认 —— 需要财务/运营:实付金额从哪来(财务回调 / 手填 / 合同额),决定「按谈成的价付了没」能不能自动对账
4存量 delivery 合作迁入建档(身份回填 76.6% 自动)→ 按批暂停-重建-比对-切回
一句话:我们不是重写系统,是把丢掉的达人身份接回来,把谈判结果落成账本。

完整设计与全部证据:coordinator-refactor.pages.dev

1 / 7
← → 翻页 · 第 5 页可以点