U4.05.5Verify alternatives at design time, not after feedback设计
替代方案需在设计阶段验证，不能等到反馈后补救
别名: 设计期验证 · 无障碍前置
概念解释
灰度检查、色觉模拟、去色测试这些验证手段必须在设计评审里执行，而不是发布后靠用户反馈发现。原因很直接：补救成本随阶段指数上升——设计稿阶段换编码是改几个参数；开发完成后返工要动数据结构、组件接口和测试；上线后发现，代价是用户流失与合规风险。无障碍缺陷在这三类里最贵，因为它是系统性覆盖问题而不是个别体验问题。
机制
颜色编码渗透在整条实现链路：色板决定数据映射，数据映射决定组件接口，组件接口决定测试用例。设计阶段的缺陷还只是参数级，同一缺陷进入开发后变成接口级，上线后变成迁移级——每往后一步，修复动作乘以整个下游。而验证手段本身极便宜：模拟转换与灰度检查是分钟级操作，能在成本最低的时点拦住最贵的缺陷。滞后验证不划算不是勤奋问题，是两个操作成本相差几个数量级。
边界
设计期验证也不是万能闸门：模拟工具覆盖不到实现层的对比度回退、主题切换与暗色模式，这些要在开发验收里复测；真实读者测试无法被模拟完全替代，高敏感场景仍应抽样复核。原则是"每阶段管本阶段的失效面"，设计期管编码与替代通道，开发期管实现保真，发布期管真实用户反馈——跳过任何一层，缺陷就从那一层的缝隙里漏过去。
怎么落地
- 把三项检查（灰度、色觉模拟、去色测试）写进设计评审清单，作为图类交付物的放行条件，未执行不进开发。
- 开发验收加两条：实现后的截图重跑灰度与模拟，暗色模式下复测对比度。
- 验证：检查近三个月的图表类缺陷单，若"颜色独占信息"类问题全部在设计评审阶段拦截，说明闸门在工作；若出现在开发后或线上，回溯该流程是否跳过了设计期验证。