Appearance
第 20 章 · 调参数的手感
背景：变换面板滑块松开鼠标才更新，手感割裂
过程：滑块拖动时实时刷新模型姿态
相关代码：[model-detail.ts](file:///C:/Users/zhujieling11/frontend/src/menus/model-detail.ts)
你用过 Photoshop 的滑条吗？
拖动亮度滑条，图片实时变亮变暗。 拖动对比度滑条，对比实时变高变低。 你一边拖，一边看效果。拖到合适的位置，松手。
如果是这样呢——你拖动滑条，图片没变化。你松开鼠标，图片"啪"的一下变了。 不对，再拖一次。还是没变，松开才变。 再试一次。 再试一次。
烦不烦？
两步操作的麻烦
"现在的变换面板就是这样，"外交官说，"位置、旋转、缩放的滑条——拖的时候模型不动，松手才动。"
"为什么？"AI 同行者问。
"因为用的是 change 事件，"外交官翻开 model-detail.ts，"input 元素的 change 事件，只有在值确定的时候才触发——也就是松开鼠标、或者按回车的时候。拖动的时候不触发。"
"那为什么不用 input 事件？"
"问得好，"外交官说，"input 事件在值变化的时候就触发——拖动的时候每动一像素就触发一次。这样就能实时更新了。"
"那为什么之前用 change？"
"可能是习惯，可能是担心性能，"外交官耸耸肩，"很多人觉得'实时更新会不会卡'。但你想——更新一个模型的位置，就是改一下 position 属性，几微秒的事。有什么好卡的？"
"确实……"
"所以我们把 change 改成 input，"外交官说，"就改一个事件名。然后模型就跟着滑条动了。"
手感是什么
"不就是实时更新吗，值得写一章？"AI 有点疑惑。
"值得，"外交官严肃地说，"因为这涉及到一个很重要的东西——手感。"
"手感？"
"手感，"外交官重复，"你用软件的时候，有没有过一种感觉——这个软件'顺手'或者'不顺手'？说不上为什么，但就是觉得好用或者不好用。"
"好像有过……"
"那就是手感，"外交官说，"手感不是一个具体的功能，是很多小细节的总和。滑条是不是实时的、按钮是不是点下去就有反馈、窗口拖动跟不跟手、滚动平不流畅——这些加起来，就是手感。"
"那实时滑条有什么不一样？"
"我给你讲个道理，"外交官坐直了身子，"人调节一个参数的时候，大脑的工作模式是这样的：
拖一下 → 看效果 → 判断多了还是少了 → 再拖一下 → 再看效果 → ...如果是实时的，这个循环是连续的——你一边拖，一边看，大脑一边判断，手一边微调。整个过程是流畅的，是'感觉'的。
如果是松开才生效，这个循环就断了——
拖一下 → 松手 → 看效果 → 不对 → 再拖 → 松手 → 再看 → ...每一次都要'松手→看→再拖'，多了两个步骤。而且你在拖的时候，不知道当前位置是什么效果，只能猜。"
"就像……闭着眼睛调收音机？"
"就是闭着眼睛调收音机，"外交官拍了下桌子，"你拧旋钮的时候听不到声音，松手才响。你得拧一下、听一下、再拧一下。烦都烦死了。"
性能的担忧
"但是……万一真的卡呢？"AI 问，"比如有十几个模型，拖动位置滑条，所有模型一起动——会不会掉帧？"
"不会，"外交官摇头，"更新模型的 position 就是改三个浮点数。巴比伦每帧都要更新几百个 mesh 的位置，多这几个不算什么。"
"那什么时候会有性能问题？"
"如果滑条控制的是一个很重的操作——比如重新加载模型、重新计算布料、重新生成纹理——那实时更新就不合适了。这时候应该用 change，松手再生效。"
"怎么判断重不重？"
"简单，"外交官说，"你自己拖一下试试。卡不卡，一测就知道。不卡就实时，卡就不实时。不要想当然地觉得'可能会卡'就不做。"
"先测再决定。"
"先测再决定，"外交官点头，"性能优化最怕的就是'我觉得会慢'。很多时候你觉得慢的东西，实际快得很。你觉得快的东西，实际可能是瓶颈。"
input vs change 的选择
"那是不是所有滑条都该用 input 事件？"AI 问。
"不一定，"外交官想了想，"分情况。"
他列了个表：
| 操作类型 | 推荐事件 | 原因 |
|---|---|---|
| 位置/旋转/缩放 | input | 轻量操作，实时更新体验好 |
| 颜色/透明度 | input | 轻量操作，视觉反馈直观 |
| 滑条微调（精确值） | input + 数值输入框 | 实时看效果，精确值手动输 |
| 模型重建/重加载 | change | 操作重，实时会卡顿 |
| 文件路径/文本输入 | change 或 blur | 输入过程中值不稳定，等输完再处理 |
| 开关/复选框 | change | 只有两种状态，没有中间过程 |
"核心原则就是——操作轻、反馈重要，就实时。操作重、过程不重要，就等确定了再触发。"
"那我们这个变换面板属于哪一类？"
"轻量操作、反馈重要，"外交官毫不犹豫，"位置旋转缩放——用户拖的时候最想看到实时效果。不然怎么知道调到什么位置合适？"
第十一颗石子
第十一颗黄石子落进"已处理"的堆里。
这一颗最小——就是把 change 改成了 input。 一个单词的改动。 但它改变了用户调节参数的手感。
"手感这种东西，"外交官看着那颗石子说，"说起来虚，但用户是能感觉到的。你用一个软件，觉得'顺手'，就是这些无数个小细节在起作用。你说不上哪里好，但就是觉得舒服。"
"反之呢？"
"反之就是——你说不上哪里不好，但就是觉得'这个软件有点难用'，"外交官笑了笑，"难用，往往不是因为缺功能，是因为每一个小细节都差那么一点。加起来，就难用了。"
他把那颗石子放好，位置刚好和其他的对齐。
差一点，和刚好，差很多。
附录：UI 交互手感检查清单
| 检查项 | 说明 |
|---|---|
| 滑条实时反馈 | 拖动时实时更新效果，不要等松开鼠标 |
| 按钮即时反馈 | 点击瞬间有视觉反馈（按下态、颜色变深、缩放） |
| 输入框即时校验 | 输入时就提示对错，不要等提交才说格式不对 |
| 拖动手感 | 拖动时跟手，不要有延迟或跳动 |
| 滚动流畅 | 60fps，不要掉帧 |
| 动画自然 | 过渡动画要顺，不要太突然也不要太慢 |
| 键盘操作 | 所有功能都能用键盘完成，不要只能用鼠标 |
教训：用户对软件的评价，往往不是来自大功能，而是来自小细节。滑条是不是实时的、按钮有没有反馈、动画够不够流畅——这些加起来，就是"手感"。手感好的软件，用户说不出哪里好，但就是喜欢用。手感差的软件，功能再多，用户也觉得难用。