CGL SCRM / parity
复原对照
与原站逐模块对照
这一页回答：老系统的东西，搬全了吗
一句话：数据层面能搬的都搬完了，一块没落下。剩下几处「看着像缺」的，回去查过——是原系统本来就没有。
做法是分六批搬：每批搬完都在新系统里核对一遍，确认跟老系统对得上再搬下一批。 这样出问题时范围小，好定位。
| 批次 | 模块 | 搬了多少 | 状态 | 内容 |
|---|---|---|---|---|
| 1 | 活动 | 125 | 已进生产 | 活动 + 报名名单 + 字段定义 |
| 2 | 问卷调研 | 3 | 已进生产 | 题目 / 选项 / 答卷 |
| 3 | 内容中心 | 25 | 已进生产 | 含 10 个标签 |
| 4 | 流量溯源 | 61 | 已进生产 | 渠道 / 来源 |
| 5 | 会议微站 | 34 | 已进生产 | 以活动形式承载 |
| 6 | 用户分组 | — | 原站就 0 条 | 不是我们没导 —— 源站本就没有数据 |
第 6 批「用户分组」为什么是 0：不是我们漏了，是老系统里这个功能本来就没有数据。
这一点专门回去查过才敢写。
为什么值得单独说一句： 「老系统没有」和「我们没搬」在数量上长得一模一样——都是 0。 如果不回去核对，就会把一个「本来就没有」当成自己的缺口，去瞎补一堆不存在的数据。 写「缺什么」之前，先回源系统找那个字段——这条已经被记成项目硬规矩了。
为什么值得单独说一句： 「老系统没有」和「我们没搬」在数量上长得一模一样——都是 0。 如果不回去核对，就会把一个「本来就没有」当成自己的缺口，去瞎补一堆不存在的数据。 写「缺什么」之前，先回源系统找那个字段——这条已经被记成项目硬规矩了。
逐模块对照表
| 功能模块 | 老系统里对应什么 | 搬过来多少 | 结论 | 说明 |
|---|---|---|---|---|
| 线索（潜客） | ctm_register 等 | 11,348 | ✅ 逐字段复原 | 67 列全量搬；手机号等 PII 默认脱敏展示 |
| 活动 + 报名 | act_* / ctm_apply 等 | 160 活动 / 9,924 报名 | ✅ 复原 | 源站名单页表头按活动动态生成（11~15 列）⇒ 按表头驱动 + CSV 权威，按 uid 配对 |
| 问卷 | quest_* | 3 卷 | ✅ 复原 | 题型编号沿用原站 moduletype 语义 |
| 内容中心 + 标签 | content* | 25 篇 / 10 标签 | ✅ 复原 | 标签-线索关联 1,464 行 |
| 流量溯源 | traffic* | 61 条 | ✅ 复原 | |
| 会议微站 | act_* | 34 场 | ✅ 复原 | 在原站是活动的一个视图，不是独立实体 |
| 用户分组 | — | 0 | ⏳ 原站就 0 条 | 「原站没有」与「我们没导」在计数上长得一模一样 ⇒ 先回源站确认过 |
| 约见申请 | ctm_meetlist | 178 | ⚠️ 误报更正 | 原站 ctm_meetlist 是线索列表的另一视图，不是独立实体 ⇒ 不单独建表 |
| 签到时刻 | — | — | ⚠️ 误报更正 | 原站本就没有签到时刻字段 ⇒ 空是对的，不是漏导 |
| 对外开放 API / MCP | — | — | 🆕 原站完全没有 | 本次新增：/api/v1 + /mcp + 出厂技能包 |
几处「查过之后要更正」的
这些一开始被记成「缺口」，回源系统核对后发现是我们记错了，不是真的缺。 单独列出来，是因为一个猜错的台账比一个空着的台账更坏—— 它会让人去补根本不存在的东西。
「约见申请 178 条没导」→ 不成立
老系统里那个列表，其实是线索列表的另一个看法（换个筛选条件而已），
不是一个独立的东西。所以不该单独建一张表——数据本来就在线索里，没丢。
「签到时间没导」→ 不成立
老系统里根本没有「签到时刻」这个字段——只有「有没有签到」。
所以新系统里那一列是空的，是正确的还原，不是漏导。
这两个更正教了一件事：
「这个字段没有值」和「我们忘了导这个字段」看起来一样。
所以判缺口时必须回老系统看那个字段到底存不存在，
不能只看新系统里有没有值。
数据对得上的证据
最硬的一条：新系统本机干净复原后的线索条数，正好等于线上系统自己报出来的条数。
| 比对项 | 数值 | 说明 |
|---|---|---|
| 本机干净复原后的线索数 | 11,348 | 清空 → 跑测试 → 按档案重灌之后得到 |
| 线上系统自报的线索数 | 11,348 | 从一个公开的体检地址读到，见「安全模型」页 |
| 结论 | 一致 | 两个数字来自完全不同的两条路，互相对上 |
为什么这个比对有意义：它不是「同一份数据自己跟自己比」——
一边是本机从档案重建的结果，一边是线上库实时数出来的。
两条独立路径得出同一个数，才说明搬过来的东西是完整的。
搬数据这件事的几个坑
表头会变
老系统的报名名单页，表头是按活动动态生成的（有的活动 11 列、有的 15 列）。
如果按「第几列」去取数据，换一个活动就整个串位。
实测有 61.1% 的手机号因此错位
会串味
有一次用造出来的假数据做测试，其中一条假数据里的「容量」值，
意外写进了线上一条真实活动里。
逐行数条数的清理办法看不见这种问题
口径会飘
同一个数字（比如标签关联了多少条线索）曾经有四种算法，
每改一次口径，所有引用它的汇总都得跟着重算。
地址不能改
所有对外的网址、参数名、字段名一律照搬老系统——
连
Botch_qrcode 这个拼写错误也一起照搬了。