Fitts 定律：命中时间看的是距离和宽度的比
它是干嘛的。 预测一次瞄准移动要花多久（鼠标点按钮、手指点目标），让目标的尺寸和位置有证据可依，不凭感觉。
公式。
MT 是命中时间，D 是距离，W 是目标在移动方向上的宽度。ID = log2(D/W + 1) 是难度指数，单位 bit。a、b 是实验拟合出来的常数（Fitts 1954 年的敲击实验），不是第一性原理推出来的；而且 b 因设备而异，鼠标、触控板、手写笔不是同一个 b。
为什么是比值，不是距离本身。 时间随 D/W 的对数增长：距离翻倍，时间不是翻倍；宽度翻倍，收益递减。关键是比值，而且 W 是方向性的：一个又宽又扁的按钮，从侧面移过去还是难，因为它在移动轴上的宽度很小。
D = 400px，W = 36px，ID 约 3.60 bit：
D = 400px，W = 44px，ID 约 3.33 bit：
两行距离完全一样。真实宽度只差 8px，ID 就小了 0.27 bit：这就是比值在起作用。
边缘和角落：宽度做到无限大。 指针到屏幕边缘就停住了，过不去。贴着边缘的按钮，在朝边缘这个方向上的有效宽度就是无限大：滑过头了也没事，照样落在按钮上，这个轴根本不需要瞄准。W 趋向无限大时，ID 趋向 log2(1) = 0，只剩基线 a。角落是两个方向同时无限大，所以是桌面上最好点的目标。
管辖范围：只对指针成立。 边缘这招只在指针设备下成立。多显示器时，两个屏之间的边不是真边，指针直接穿过去，“边缘无限大”就没了；触屏更不用说：没有光标可停，手指还挡视线，边缘目标反而更难够。触屏不用边缘这招，改用最小尺寸：44pt（苹果 HIG）/ 48dp（安卓 Material），来历是手指指肚的尺寸。
实测：Lucerna 阅读页顶栏（按代码量，2026-10-25）。
- design-system 的 Button 尺寸（仓 main 7 月快照）：default 高 36px、sm 32px、lg 40px、icon 款 36x36px、图标 16px、圆角 4px。注意：MainApp 吃的 design-system 已发布版比这个快照新，线上尺寸可能已经动过。
- 阅读页顶栏约 14 个动作（返回、收藏、目录、书签、生词、笔记、搜索、跳页、AI 设置、主题、字号、上一页、下一页、菜单、用户菜单，按 wrapper 传的 prop 数出来的）。这个数就是 Hick 那边的账：Fitts 要目标大，Hick 要选项少，顶栏就是它俩谈判的现场。
- 断点：Tailwind v4 的 sm 默认 640px，MainApp 没有自定义；但阅读页根本不用 sm:/md:/lg: 类。真正的分界在 JS 里：useCompactViewport，分界线是 max-width: 639px。小于 640 走紧凑布局（另有手机单独的翻页条，正文字号小一档），大于等于 640 走完整布局。640 和 639 是同一条线的两面，只不过是用代码而不是响应式类实现的。
- 效应量（先声明假设：鼠标、b 约 100ms/bit，只比相对值）：D = 400px 时，W = 36px 的 ID 约 3.60 bit，W = 44pt 约 3.33 bit，省约 0.27 bit、一次点击约 27ms。D = 800px 时省约 0.28 bit。省的量基本不随距离变，这是对数比值的性质。
- 没验到：顶栏是不是贴着视口顶边——这决定它能不能吃到“边缘无限大”。那份布局在已发布的 core UI 包（0.5.75）里，仓 main 分支里没有，所以这里不对它做边缘断言。
设计题深挖五问。
- 来历：这个数或常数是哪个实验给出来的？
- 边界：规则在什么条件下失效？
- 对家：它跟哪条规则打架？
- 实测：真界面的数是多少，按代码量出来的？
- 反例：照着规则做会在哪变差？
给 agent 的检查清单。读完本节点，按每一条去验界面，验出结果要带证据（文件、配置或算出来的 ID）。
- 各端目标尺寸，按代码量：高、宽、图标尺寸，按断点分别对；触屏端对照 44pt/48dp。
- 边缘与角落位置：哪些目标贴着真屏幕边，设备是不是指针设备？多显示器内侧边不算。
- 高频任务的 ID：每个任务写明 D 和方向上的 W，算出 ID，用 bit 比方案，不凭感觉。
- Hick 张力：数清同一表面上的动作数，说明缩小或分组要付什么代价。
- 触屏行为：同一表面改用触屏时，边缘推理是不是还出现？如果出现，标出来。
- 未验项：列出按代码确认不了的东西，别把它当测过的报。