从现状到 vNext:
新旧并行,按批切换,CRM 先行。

本计划的每一个数字都来自生产库直查(2026-07-25/26/27 快照)。 总策略三句话:CRM 先上、不碰旧系统;只迁 delivery 存量, 谈判上游继续跑、向新系统投递 pick;每一批都可回退, 回退开关(suppress_received_channel_agent_runs)今天已存在。

结构性事实(决定打法的那几条)

• CRM 先行,零 LLM。P1 上线的 CRM 不含任何模型调用,先让运营能纯手工跑通 —— 这是所有后续阶段的回退地板
• 新旧并行,单向流动。旧系统只出不进(pick 出、消息共享读);新系统绝不回写旧表;比对期用只读校验,不做双向同步
• 每批可回退。批次粒度 = Collaboration;回退 = 取消 suppress + 新表该批标记 parked,消息一条不丢

P0 止血(可立即,与重构无依赖)
P1 身份接线 + CRM 上线(L0)
P2 Campaign 归类 + 建档管线 + delivery 存量迁入
P3 Studio 手动看板(泳道/引用/快捷操作)
P4 L1 只读理解 + 付款采集确认
P5 Campaign 变更发布 → L2 起草待审 → L3 全自动

P0 · 止血(3 个独立 PR,不等重构)

P1 · 身份接线 + CRM 上线(L0)

• 建 contact_methods + assignments;从旧 engagement_channel_identities(email 38,225 / whatsapp 1,136 / phone 954 行)回填,经纪域名批量打 agency + mergeable=false(名下 >5 合作的 197 个信箱人工过一遍,约 2 小时)
• 身份回填四级阶梯(见 §04),只跑确定性两级;歧义进队列不猜
• CRM 界面:threads 按 Campaign 分组(暂按旧 campaign 名聚合,P2 归类后切新 Campaign)、邮件新 thread 自动绑定、WA 待绑定队列 + 一键绑定
• 验收:拔掉所有 LLM key,运营在 CRM 完成一次真实建联→跟进全流程
• 回退:CRM 只读旧消息表,任何时刻可直接回旧界面,零数据风险

P2 · Campaign 归类 + 建档管线 + 存量迁入

• Campaign 归类(运营,半天):112 个 product 归入 60–80 个 Campaign,判据「同一张提报总表」;允许暂不归类(campaign_id=null 队列)
• 建档管线:pick 入口(谈判侧加一个按钮即可)+ 手动建档 + 迁移入口
• 存量迁入 8,586 条 delivery 活跃:身份已接线的批次先走;快照从旧谈判结果拼(价格取 negotiation_price_items 已接受项,要求/限制取 Campaign);52% 无 deliverable 行的按快照播种 provisional 泳道
• 迁移批次协议:suppress 该批旧 agent → 写新表(带 legacy_engagement_id 回指)→ 比对(会话数/价格/状态)→ 运营确认 → 切新界面;回退 = 反向单开关
• 验收:抽样批(≥200 条)零差异;运营在新界面完成一周日常无回旧

P3 · Studio 手动看板

• 泳道组界面 + 快捷操作 + 消息引用跳转;阶段全人工写(actor=operator)
• 旧里程碑 → 新阶段一次性映射(§04 映射表);映射不到的默认 provisional,运营补录时逐条点掉 —— 别指望 15 条 in_progress 能自动分出先后
• 验收:运营对齐一个真实 Campaign 的全部泳道后,「等谁/缺什么」在看板上答得出来

P4 · L1 只读理解 + 付款采集

• 每条新消息读一次(新消息 + 该泳道当前状态,不喂历史),产出:阶段建议、issue、付款/发布信号 —— 全部「待确认」,必须带 source_message_ids
• 与运营人工写入并行两周,比对采纳率;采纳率达标后「待确认」变默认勾选
• 付款:采集→确认落 payments,幂等键防重;「谈成 vs 实付」对账报表首次可用

P5 · 变更发布 → L2 → L3

• Campaign release + 订阅收敛(冲突 pending_review)
• L2:催办草稿(附原始意见)+ 回复审核队列;L3:常规直发,LLM 判高危强制转人工(代码路径,模型不可绕过)
• 每级放开前的门槛:上一级运行 ≥2 周、修正率低于阈值(阈值 L1 达标后定,不拍脑袋)

① 身份回填阶梯(存量 51,455 → contacts)

铁律:允许「身份未解析」长期存在;错误合并会把一个达人的记录暴露给另一个,比留白严重得多。 写入前先解 merged_into;contacts 合并事务同步收敛新表(先于任何新表写入上线)。

② 旧里程碑 → 新阶段

映射只定「当前阶段」初值;历史轮次(哪一版脚本改了几次)旧数据没有,不伪造 —— 从 P3 起真实累积。 distribute 初值从旧 crossPosts 带入。

③ 会话归组回填

• thread 本体不动(291,196 条原地);为迁入的每条 Collaboration 生成 bindings:旧 engagement 挂过的 thread → granted_from = 迁移时刻
• 重复投影(如 608 行那类)在绑定生成时天然去重:一条 thread N 条绑定,而不是 N 份拷贝
• WA 未归属的进待绑定队列;邮件侧新消息一律走「新 thread 自动绑定」

• 唯一索引先行:creator_profiles(id, creator_id) 等前置约束用 CONCURRENTLY 在迁移事务外建
• 写路径幂等:payments 幂等键;迁移脚本可重跑(upsert by legacy_engagement_id)
• 比对指标(每批):会话计数一致率、价格快照一致率、泳道数 ≥ 旧 deliverable 数、运营回旧界面次数(目标 0)
• 灰度粒度 = Collaboration,不按 Campaign(同 Campaign 内有未解析身份时会切漏)
• env 强制在发送适配器:sim 只能解析到 sim 渠道 —— 迁移演练全程在 sim 跑一遍再动 live
• 终局:delivery 存量全部迁完、谈判存量自然收敛后,冻结旧表写入 → 终局对账 → VALIDATE 全部 NOT VALID 外键 → 再议旧表退役与改名

数据快照:2026-07-25/26/27 生产库直查;方法与明细存 Research/coordinator-vnext/evidence/。
设计定稿:《设计文档》 · 周会版:presentation