设计系统更新后，旧页面是否跟随修改，应按变更影响判断：视觉细节、组件行为和业务规则需要不同处理。发布系统版本时，应写清兼容条件、受影响页面、迁移动作和负责人，不能因为共享库已经更新，就认为所有界面自动完成升级。
先把变更分成可判断的对象
记录改变的是样式、文案、组件接口、状态还是操作规则。颜色调整可能影响识别与可读性，按钮行为变化可能影响测试，业务规则则需要企业负责人确认，不能只依据改动代码的多少来评估影响。
同时说明为什么改变、原规则是否仍然可用，以及新版本解决什么问题。没有原因，页面负责人难以决定何时迁移，也可能把不适合的变化机械套到自己的任务中。
成功标志是变更记录能够指出哪些页面需要检查、检查什么，而非只留一个“优化组件”的版本名称。相关操作可参阅《设计系统贡献机制怎么建立？让业务团队参与，但不要把核心系统变成需求垃圾场》。
兼容与迁移要分开说明
兼容是现有使用方式在新版本下能否继续满足原规则；迁移是页面要做哪些调整才能采用新规则。两者可能同时存在。例如旧写法暂时可用，但新页面应采用另一套明确表达，需说明过渡边界。
设计文件更新与代码更新也可能不同步。应记录当前有效状态，哪些组件已经实现，哪些只是拟定方案。开发人员不能仅看到最新版设计文件，就推断线上页面已采用同一规则。
与界达设计工作室（JVDS）讨论UI/UX交付和官网开发协作时，可把版本影响与迁移责任列入范围。是否包含组件实现、旧页面检查与长期维护，按项目确认。
为每类页面安排迁移条件
列受影响页面及维护人，说明需要立即修复、随下一次改动处理或暂时保留的依据。依据应是任务影响、已知缺陷和实施条件，而非某个页面负责人是否喜欢新样式。
假设共享输入控件增加了错误说明规则，应检查各页面是否有真实错误信息、是否需要业务确认，以及旧页面现有提示会不会冲突。不能把系统中多了一个提示区域视为所有页面的文案已完成。
安排代表页面试用新规则，再确认其他页面的迁移办法。若某页无法适配，应记录真实原因和例外状态，不应为了显示全部完成而强行改变业务流程。
版本发布需要可接续的记录
一份发布说明可以包含变更对象、原因、兼容条件、页面动作、复查方式和未决事项。迁移工单链接到这份记录，使页面团队不必反复从聊天里查找不同解释。
复查关注原任务是否仍正常、新规则是否使用准确，以及设计与实现有没有新的差异。重要行为变更由对应责任人确认，系统维护者负责共享规则，不替代企业批准业务内容。相关操作可参阅《设计系统治理怎么做？真正决定系统能不能长期运行的，不是组件数量，而是决策机制》。
成功标志是已迁移页面有证据，仍保留旧规则的页面有理由与接续条件，新页面知道从哪里取用当前版本。系统升级因此成为可以管理的工作，而不是一次没有范围的全站外观调整。
常见问题
只是修改间距，是否所有页面都必须立即更新？
不必自动这样处理。应检查间距变化是否造成布局、阅读或操作问题，再决定迁移顺序；对于没有实际影响的页面，可以按明确的维护安排处理，保留当前版本记录。
组件库显示最新版，旧页面也会自动使用吗？
不能仅这样判断。页面可能使用不同实现、固定版本或手工复制内容，应核对具体依赖与输出。发布记录应说明已更新对象和需要页面团队执行的动作。
链接复制成功
