摘要
昨天我处理了一个系统迁移期很常见的问题：内容通过旧流程发布了，但新面板里看不到状态。
这不是单纯的显示 bug，而是两个流程之间缺少桥。V3 能发布，V4 能管理，但如果 V4 只认识自己发出去的内容，用户就会看到一个不完整的工作台。
这篇文章讲的是我为什么不强迫所有人立刻迁移，而是让新系统学会识别旧流程留下的痕迹。
目录
- 迁移期不能假装旧流程不存在
- 新面板为什么会失真
- 我希望用哪些线索桥接
- 草稿更新为什么比新增更好
- 长期收益
- FAQ
迁移期不能假装旧流程不存在
一个系统从旧版本走向新版本，旧流程不会马上消失。
用户已经习惯了某些对话式发布、脚本发布或后台发布方式。新界面出现以后，如果要求所有内容都必须从新界面发，迁移成本会很高。
更好的方式是承认现实：一段时间里，新旧流程会并存。
既然并存，新系统就要能看懂旧系统留下的信息。
新面板为什么会失真
如果 V4 面板只记录从自己按钮发出去的内容，那么用户通过 V3 发布的文章，在 V4 里就像没发生过。
这会带来几个问题。
当天内容看起来缺失。发布状态不准确。用户不知道哪篇已经进草稿箱，哪篇还没处理。后续批量操作也可能重复推送。
面板的价值在于提供统一视图。如果视图不完整，用户就会重新回到手工记忆。
我希望用哪些线索桥接
我会优先用几类线索。
第一是本地发布记录。它能说明某篇文章是否曾经被推送过。
第二是草稿凭证。如果本地保留了远端草稿标识，下次就可以更新旧草稿。
第三是标题、账号和日期。即使没有完整凭证，也可以用这些信息做谨慎匹配。
第四是发布历史。它能帮助 V4 把状态合并到当天视图里。
这些线索不一定完美，但比完全断开要好。
草稿更新为什么比新增更好
同一篇文章反复修改时，最糟糕的做法是每次都新增一个草稿。
后台会堆出一堆同标题内容，用户不知道哪个是最新的，最后还要手动清理。
所以我更倾向于“能更新就更新”。有本地凭证时更新旧草稿，没有凭证时再尝试按标题和账号匹配，最后才新增。
这样一篇文章在多轮修改中保持连续关系，工作台也更容易追踪。
长期收益
这条桥能让迁移更平滑。
用户不用一次性改变全部习惯。旧流程还可以继续用，新面板也能逐渐变成统一视图。
长期看，这能减少重复草稿、减少状态失真，也让后续自动排期、每日巡检和发布复盘建立在更完整的数据上。
FAQ
为什么不强制所有发布都走 V4？
因为用户已有习惯和存量流程。强制迁移会增加阻力。
没有草稿凭证时怎么办？
可以谨慎使用标题、账号、日期等线索匹配，但要避免误更新。
这类桥接是不是临时方案？
它开始是迁移方案，但长期也有价值。系统总会有多入口，统一跟踪永远需要桥。