检查界面组件与设计约束一致性

这个场景能帮你做什么

不同页面使用相似组件，却可能有不同名称、参数和状态。WorkBuddy 可以对照设计规范、组件清单和代码检查文字与配置层的一致性，为设计评审准备问题。

开始前需要准备什么

提供设计约束、组件说明、命名及样式配置、页面文字或代码，以及本轮目标。明确已批准规范和允许例外。仅有截图时无法完成本任务的配置核对。

具体怎么做

第一步：列出必须遵守的约束

将品牌、布局、交互、内容、设备和无障碍等已提供要求整理为可核对条目。缺少规范时只盘点现状，不让 AI 自创一套强制规则。

第二步：盘点组件及使用位置

从可读资料记录名称、参数、状态、调用位置和版本。语义相同但命名不同的列候选，外观类似但行为不同的保持区分。

第三步：对照规范找差异

检查同一组件的配置、提示、交互状态与规则是否一致。对每项差异说明违反哪条约束，或是否属于已批准例外；不只罗列个人审美偏好。

第四步：整理修订顺序

优先处理会造成行为误解、状态冲突和复用困难的事项，再处理低影响差异。反馈若改变设计约束，先回到约束讨论，不能无止境生成变体。

可以直接交给 WorkBuddy 的完整要求

按附件已批准设计规范检查组件与页面配置，列组件、使用位置、参数/状态、规范要求、实际差异和依据。
没有规范的只记录现状；已批准例外保留。不因名称相近就强行合并，不添加与目标无关的设计元素。
将行为冲突、配置不一致和纯建议分开，给修订清单。只判断文本、代码和配置，不评价未查看的视觉画面。

完成后会得到什么

一份组件使用对照表和有依据的差异清单，设计与研发能据此统一修改范围。

结果应该怎么检查

核实规范版本、差异位置及例外记录。检查建议是否真实改善一致性，避免把所有页面强制改成同一种布局。

遇到这些情况怎么处理

规范与代码版本不同时先确认目标版本。组件确需不同表现时记录适用条件。涉及视觉层次、触达和阅读体验的判断留给实际设计验证。

哪些必须人工决定

设计负责人批准规范与例外，研发确认组件复用和改动影响。AI 提供差异，不替代视觉和可用性评审。