网站建设介绍：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d377b3dc27c.html
📄
网站建设介绍：旧系统字段无法完整迁入时怎样决定保留项
结论是：不要按“旧系统里有什么”决定保留项，而要按“新站上线后哪个角色必须用这个字段完成哪一步”来决定。只有当一个字段对应明确的业务动作、且没有可接受的替代来源时，才优先保留；否则应降级为备注、附件或人工台账。反例是：如果该字段是历史订单对账、合同履约或监管留存的唯一凭据，那么即使新站前台用不到，也不能因为“页面不显示”就删掉，此时决定权不在前端展示，而在留存义务。
先判断字段属于“展示事实”还是“业务凭据”
多角色对同一字段理解不同，通常是因为各自看到的用途不同：编辑关心它是否出现在页面，销售关心它能否支撑报价，财务关心它能否对账，法务关心它是否要留存。把分歧转成可核对的项目，第一步是给每个争议字段标注它服务的是哪一类事实。
- 展示事实：只影响用户阅读，例如旧站里的“公司简介补充说明”。新站可用新文案替代，原字段可只留摘要。
- 业务凭据：影响后续动作能否追溯，例如合同编号、历史服务起止日期、订单备注。它需要可核对，而不是好看。
- 过渡信息：只在迁移期间有用，例如旧栏目 ID、旧编辑账号。上线稳定后可归档，不进入新站日常维护。
这一步的实际动作是让每个角色只回答“没有这个字段，你会卡在哪一步”，而不是回答“你觉得它重不重要”。结果会直接影响下一步：如果没有人能说出具体卡点，该字段就不进入保留清单；如果有人能说出卡点，就进入可核对清单。
用“动作—替代—后果”三项核对保留项
对每个争议字段，建一行核对记录，只填三项：它支撑什么动作、有没有替代来源、缺失后最坏后果是什么。三项都空，说明它只是旧系统惯性；三项中有一项明确，才值得保留。
- 动作：谁在什么场景下会打开这个字段。写不出具体角色和场景，就先不保留。
- 替代：新站的其他字段、附件、邮件记录或线下台账能否替代。能替代的，优先替代，减少迁移复杂度。
- 后果：缺失后是“看起来不完整”，还是“无法对账、无法回复客户、无法证明承诺”。前者可降级，后者要保留。
假设某旧站有一个“历史报价备注”字段，新站没有对应位置。若销售说“客户追问时我会查它”，但没有替代来源，缺失后果是无法解释历史价格，那么这个字段应保留为只读记录，而不是硬塞进前台页面。反过来，若备注只是旧编辑的内部提醒，且新站已有工单记录，就可以不迁。
把分歧写成可核对的字段清单，而不是会议结论
多角色争论最容易停在“要”和“不要”。可核对的做法是把每个字段写成一条可验证记录，包含字段名、旧来源、新去向、保留理由、核对人。核对人不是负责人头衔，而是能实际打开旧数据并确认内容的人。
实际动作：先导出争议字段的前若干条样例，让各角色分别标注“这条缺失后我会不会卡住”。结果会影响下一步——如果同一字段在不同角色间标注冲突，就把它拆成两个用途：一个用于前台展示，一个用于后台留存，而不是强行合并成一个字段。
需要说明适用条件：这套方法适合旧系统仍可导出、且新站字段结构尚未冻结的阶段。如果旧系统已经无法访问，或新站已经上线且字段不可扩展，那么讨论重点应转为“用附件或台账补足”，而不是继续争论字段本身。
一个会让结论失效的反例
如果某个字段虽然前台完全不展示，但它是历史合同、发票、售后承诺或监管留存的唯一记录，那么“没有角色每天用它”不能成为删除理由。此时保留项的决定标准不是使用频率，而是可追溯性。反过来，如果该字段只是旧模板遗留的装饰性说明，且新站已有更准确的替代内容，那么即使旧系统里数量很多，也不应为了“完整”而全部迁入。
最后一步动作：把最终保留清单交给能实际核对旧数据的人逐条确认，确认结果只分“保留、替代、归档”三种，不再回到“重要不重要”的争论。这样下一轮迁移范围才能被锁定，开发与内容录入也才有明确边界。
