我手上这台设备的全部输入，只有一个旋转编码器：能左转、能右转、能按下去。 三个动作，其中两个还是同一个物理量的两个方向。

而它要控制的东西有：一个屏幕、一个摄像头、一张 SD 卡里的图片、以及一个正在跑脚本的系统。 于是问题来了——用三个动作，怎么表达这么多意图，而且不让人按错？

下面是我当时写在便签上的设计，以及后来补上的几条理由。 把它整理成文字的过程比预想的更有用：有些决定我原本只是「觉得应该这样」， 写下来才发现自己其实说不出为什么。

01原始设计

一、旋转编码器长按用于切换模式，旋转不能切换模式。

二、长按之后：如果原来是图片浏览模式，就切到拍照模式；如果在拍照模式， 屏幕实时显示摄像头画面；在图片浏览模式下，摄像头可以不工作。

三、在图片浏览模式时，旋转编码器用于切换图片。

四、拍照模式时旋转编码器能干什么——这个我还没有想好。

五、每次切换的时候，屏幕上弹一个提示，一秒左右之后消失。

只有两个模式：图片浏览和拍照。 之所以这么少，不是因为想清楚了，而是因为输入手段实在有限——多加一个模式， 用户就得在脑子里多记一套映射关系，而编码器能给出的提示只有那一个屏幕。

02为什么切模式必须用长按

第一眼看去，用「旋转到尽头」来切模式更省事：转到最后一张图，再往右转就进拍照模式。 很多设备就是这么做的。我没这么做，理由有两条：

  • 旋转是连续的、物理的、会误触的。 手指离开旋钮时的余力、桌面的震动、编码器本身的机械抖动，都可能产生一次多余的脉冲。 让一个会抖的信号去承担「切换状态」这种不可逆的职责，是危险的—— 浏览图片时手一抖就跳进拍照模式，用户会以为设备坏了。
  • 按击是离散的、有明确意图的。 按下去是一个需要主动发力的动作，很难误触。而且「长按」比「短按」更重， 天然适合承载更重的操作。

由此得到一条我后来反复用到的规则： 连续量用于调整，离散量用于切换。 旋钮、滑条、摇杆这种可以取任意值的输入，适合「调大小」； 按钮、长按、双击这种取「有/无」的输入，适合「改状态」。

于是分工就清楚了：

  • 长按（≥ 1 秒）：切模式，这是全局操作，在任何模式下含义都一样。
  • 旋转：调整当前模式里的量。图片浏览模式下是上一张 / 下一张。
  • 短按（< 1 秒）：在当前模式里执行一个即时动作。拍照模式下就是拍照。

三个动作，各就各位。用户只需要记住一件事：长按是「换房间」，旋转和短按是「在房间里做事」。

03没想好的那个，我打算留着

原始设计里第四条写着「拍照模式时旋转编码器能干什么——没有想好」。 整理的时候我试着填上它，比如旋转调整曝光、或者切换分辨率。

但最后我决定保留这个空白。原因是：一个还没有真实需求的操作， 占着旋钮会让「旋转 = 切换」这个心智模型在不同模式下分裂。 用户在浏览模式转一下是换图，在拍照模式转一下却变成了改设置—— 同一个动作，两种含义，两种后果。这种不一致带来的困惑，比「少一个功能」代价大得多。

更好的做法是让它暂时什么都不做。空白是可以被理解的；含义不稳定不行。

04切换必须有回声

模式切换有个隐蔽的问题：它不产生可见的后果。 从浏览切到拍照，屏幕内容会变（预览画面出来了），这算一个反馈； 但如果摄像头启动慢了两秒，这两秒里用户不知道自己按成功了没有。

所以设计里加了一条：切换时弹一个提示，标明「拍照模式」或「浏览模式」，一秒后自动消失。

一秒这个数字值得说说。太短（300 ms）会被当成闪烁，用户来不及读； 太长（3 秒）会盖住他想看的画面，还得等它走。一秒刚好是「确认收到，不添麻烦」的量级—— 这也是绝大多数系统里 toast 提示的默认时长，不是巧合。

05还有一个非交互的约束：摄像头只在需要时开

设计里写着「图片浏览模式下，摄像头可以不工作」。这一条不属于交互设计， 属于资源管理，但它影响了交互：

如果摄像头一直开着，好处是切过去立刻有画面，代价是持续的功耗和发热， 在电池设备上不可接受。如果按需启动，就有启动延迟——而启动延迟必须由那个弹窗来兜住。

两条设计是咬合的：因为按需启动，所以必须有即时反馈。 写下来之后我才意识到自己当初并不是分别做的两个决定。

06把设计意图翻译成验收标准

设计做完之后还有一步，就是回答「怎么算做完了」。这件事比看起来难—— 「能用」不是一个可以打勾的条目。

我给自己定了个模板：每个模块给两个判断点，第一条看功能，第二条看品质。 整理便签时发现，底盘、舵机、雷达三块竟然都自然长成了这个形状：

模块 第一条：功能 第二条：品质
底盘 前进、后退、左右转弯都能用 动作是否平稳
舵机 180° 范围内能停在工作角度 转动是否平稳
雷达 数据能正常上传 上传的速度与平稳性

三条第二条都是「平稳」，这不是偷懒。让东西动起来通常很容易， 让它动得可控才是真正的工作量。 第一次让轮子转起来花了半天， 让它转得每个方向都可预测，花了两周。

07一个我答不上来的问题

整理这批笔记时，有个问题卡住了我：

我这个电机没有集成测速传感器，它能够知道它自己向前或向后走了多少吗？

严格地说：不能。没有编码器，电机只能知道「我通电了」，无法知道「轮子究竟转了几圈」。 电压相同、负载不同，转速可以差出一倍——这就是为什么小车重启后会一直转， 而且分不清方向（那段记录里的原话）。

当时我给自己的替代方案是：不要问「走了多远」，改用「能不能回到原点」来验收。 把初始化测试改成一轮：向前走一段、停下、向后走同样长的时间、停下， 最后看小车能不能回到起点附近。这样一个不需要测距的指标， 反而抓住了「前后对称性」这个更本质的东西。

另外我在便签里还记着「我有两个测速传感器，但是没接线」。 结论是：现在不需要，但得写进文档里——当「能不能回到原点」这个验收开始变得不稳定时， 就是该把线接上的时候。给未来留一个明确的触发条件，比现在就装上更划算。

08这些设计最后留下的东西

这套东西写在便签里的时候只是一堆散句。整理完之后，我觉得真正能复用的是四条：

  1. 连续量用于调整，离散量用于切换。 别让会抖的信号承担不可逆的操作。
  2. 一个动作在不同模式下的含义要尽量一致。 做不到的时候，宁可让它空着。
  3. 任何没有可见后果的操作，都必须给一个即时反馈。 哪怕只是一秒的弹窗。
  4. 验收标准写两条：功能跑通，以及它是否平稳。 第二条才是真正花时间的部分。
关于本文
整理自三段便签：2026 年 5 月 28 日的编码器交互设计、8 月 19 日的电机与验收标准讨论、 以及 9 月 13 日关于显示逻辑与重启后状态恢复的零散想法。
2026.09.20 整理
新增第 02、03 两节。原文只写了「旋转不能切模式」这个结论， 没有写理由——补理由的过程让我发现自己当初的直觉是对的，只是说不清为什么。