**做有原型的界面时，原型是唯一真源：要求「完全忠于原型」，不接受「差不多」的近似替代。** 这个主题下的几条判断：- 逐片对照，不整块重写：把浮层按家族（菜单/弹窗/下拉/编辑器菜单）一片片审，每片都对照原型的具体数值（尺寸、间距、icon、定位）。
- 共享 primitive 优先：公共行为（白底、外点关闭、右下弹出、开合过渡、icon）收敛到一处，避免逐页补丁互相打架。见 浮层要收敛到一个共享primitive。
- 不用替代物：原型里有的 icon 就用真的 icon，不用文字符号/emoji；原型没有毛玻璃就不加毛玻璃。
- 考虑周边状态：浮层弹出要顾及 AI 栏打开、侧栏折叠等状态下的定位与夹取。
- 判断机制而非抄常量：原型 JS 里的阈值若与用户要的机制冲突（如固定像素 vs 元素可见性），按用户要的机制实现。见 显示阈值应按元素可见性而非固定像素。
- 把原型当合同：UI 任务固定成 ① 找到对应原型 → ② 截一张目标状态图 → ③ 找真实组件位置 → ④ 只搬必要结构/样式，不凭感觉重画 → ⑤ 同 viewport 验证桌面 + 移动、浅色 + 深色。慢的不是看原型，是没把原型当合同导致返工。
- 原型不能替代眼睛：UI 的核心是「原型先行 + 截图验证 + 深浅色验证」，静态测试只能兜底。见 开发流程要按任务大小分级。
- 原生化只改外壳，不改结构：把 Web 产品做成原生 App 时，原生只该体现在菜单、焦点、键盘、窗口行为上；结构、信息架构、状态与视觉 token（侧栏/列表宽度、圆角、面板层级）仍以 Web 为事实源。退化成系统默认
NavigationSplitView/List/toolbar 视觉、自动生成英文标题、系统蓝色链接，是 spec compliance（规范一致性）失败，不是合理的 macOS native adaptation。
- CI 绿不代表看起来还是这个产品：CI 只证明能构建。视觉一致性要靠深浅主题 × 三种窗口尺寸的真实构建截图验收，且这类缺陷应作为验收缺陷发回原 worker，而不是当 style 问题放过。
相关