界面工程与无障碍 是做什么的？
概述
标准是可访问、极简且美观——通过构造本身实现，而非后期打磨。 品味作为规则是不可操作的，因此应将其转化为约束、先例和上报机制。代理无需发明品味，只需遵守约束，并将剩余部分上报。
无障碍——一项要求，而非收尾工作
可检查的规则：
- 每个交互元素必须键盘可达并带有可见焦点状态。
- 每个控件都有可访问名称；每个表单字段都有关联的标签和清晰的错误提示。
- 语义化 HTML 和地标元素，而非无意义的 div 堆叠。
- 颜色对比度满足 WCAG AA；绝不能仅通过颜色传达含义。
- 尊重减少动画偏好。
美观且极简——作为约束，而非感觉
- 通过约束实现一致性。 使用设计系统的令牌——间距、字体比例、颜色比例。不要使用一次性魔数。一致性本身就是美学。
- 现有屏幕就是样式指南。 在发明之前，先匹配已有的视觉语言。
- 克制（UI-YAGNI）。 每个元素都需争取自己的位置；移除直到移除会破坏功能为止。层级和留白优于密集和装饰。
- 优先使用组件库的模式，然后再构建自定义 UI。
- 两个相似的 UI 元素 → 一个参数化组件。 差异表现为 props/变体，绝不要复制粘贴。第三次复制就是缺陷。（将 DRY 应用于界面。）
上报规则
审美决策需要上报；绝不可擅自决定。 当选择确实是美学层面的，且令牌或先例不足以确定时，请不要默默猜测：
- 遵循最近似的现有先例，或
- 提供选项（原型图、对比图），交由人类做出审美判断。
快速参考
| 情况 | 做法 |
|---|---|
| 新组件与现有组件相似 | 将现有组件参数化；不要复制 |
| 间距/颜色值不在令牌中 | 使用最近的令牌；不要发明魔数 |
| 真正新颖的视觉决策 | 提供选项上报；不要擅自决定 |
| 添加一个交互元素 | 从一开始就确保键盘可达 + 焦點 + 可访问名称 |
强制执行： 在 CI 中对可检查规则进行 a11y 检查/测试（例如 eslint-plugin-jsx-a11y、axe）；审美上的克制通过上报规则由审查者判断。
完整原理：参见宪法第七条，捆绑在 engineering-constitution/references/engineering-constitution.md 中。