软件页面越加越不统一，怎样建立够用的组件与状态清单
够用的组件清单应同时记录外观、行为、输入和适用边界。先统一频繁重复且问题明确的组件，再规定新页面如何引用；不需要为了一致而把所有旧页面一次重做。
阅读目录5 个章节
先查真实页面中的重复与差异
从一组正在使用的查询、编辑和审批页面截取按钮、输入框、表格、提示和弹窗，同时记录使用场景。两个按钮颜色一样，可能一个立即提交、一个只是进入下一步；两个列表长得不同，也可能确实承担不同任务。盘点应先看含义，再决定是否合并。
为每个候选组件列出出现位置、当前问题、使用频率和负责人。不以“全部统一”作为无法验收的目标，可先处理同一操作名称不一致、错误提示丢失和同类字段尺寸混乱等具体问题。
一张组件卡片需要说明什么
- 用途与不用的情形：例如确认按钮执行哪个动作，导航链接不能伪装成提交。
- 状态：正常、聚焦、禁用、处理中、成功和失败，按真实功能选取。
- 输入：文字长短、图标是否必要、数据为空或过多时怎么办。
- 交互：键盘、触摸、重复点击、关闭和返回的行为。
- 版本：设计与实现对应关系、负责人、修改原因和替换范围。
状态不是再画几张颜色稿。禁用状态要解释发生条件，处理中要说明是否允许离开，失败状态要提供重新操作或查询结果的方法。这些内容需要设计与开发共同确认，不能由样式文件自动决定。
新增组件前先证明现有组件不适用
GOV.UK组件贡献标准将有用、独特以及可用、一致等条件用于审查组件。这可以作为管理思路参考，不必照搬其审批流程。企业项目可要求新增组件说明：现有哪项能力不满足、为什么扩展现有组件不合适、哪些页面会真正复用。
如果差异只是一个间距或标签，优先修正规则；如果业务行为不同，例如选择单条与选择整组对象，则应保留明确变体。强行用一个组件装下所有情形，容易产生难以理解的参数组合。
让新旧页面可控共存
先选一条完整任务使用新版组件，核对状态和返回路径，再扩大范围。组件升级时保留版本说明，避免一个共享改动让几十个旧页面同时变形。旧页面暂不迁移时记录边界；新增页面应使用确认版，而不是再复制旧代码形成第三套。
假设新的弹窗增加了关闭前检查未保存输入的行为，就需要区分只读弹窗和编辑弹窗，不能一刀切地对所有关闭操作弹出确认。这是版本影响分析的示例，并非已有客户配置。
采购与验收怎样落到结果
交付清单可以是一组组件卡片、对应设计源文件、可运行实现和代表页面，而不只是长篇视觉规范。纯设计项目不默认包含代码；已有组件库的版本、许可和限制也应先核对，不为建立清单强制更换技术栈。
- 在至少两种不同任务页面使用同一组件，检查规则是否仍成立。
- 输入长文本、空值和错误值，查看变体是否有明确处理。
- 切换中英文、窄屏和键盘操作，核对状态与焦点。
- 升级一个组件后复查引用页面，记录未迁移的旧版本。
当某个特殊页面无法使用通用组件时，应记录原因及维护者，而不是假装完全统一。清单的价值在于让下一次加页有明确选择，不在于组件数量越多越好。
组件清单可以从最常用的表格、表单和弹窗开始，记录各自状态与使用页面，再并入原型交付资料。旧系统则先按界面改版约束标出必须保留的行为。对接UI设计服务时，优先确认组件范围和状态覆盖，不以稿件张数代替完整程度。