今天，我被一个“打时间戳”按钮折腾了一个小时
今天，我被一个“打时间戳”按钮折腾了一个小时
今天做网站的时候，被一个特别小的交互折腾了一个多小时。
小到什么程度呢？
就是一个歌词时间戳编辑器里的按钮。
功能也不复杂：播放音乐的时候，我需要给每一句歌词打时间戳。
原本的操作是：
找到这一句歌词，点一下“打时间戳”。
然后再找下一句，再点。
再下一句，再点。
看起来没什么问题。
但真正用起来以后，我很快发现，这个交互特别难受。
因为歌词是一行一行往下排的。
我每打完一句，下一句的位置都会继续往下。
于是我的鼠标也得跟着往下挪。
一首歌几十句、上百句歌词还好，如果碰到唱得特别快的歌，可能零点几秒就是一句，我根本没有时间：
滚动歌词 → 找下一句 → 移鼠标 → 再点。
所以我想到一个很简单的办法。
人不要追着界面走，让界面自己来找人。
我的鼠标停在一个固定的位置。
我点完当前这句以后，下一句没有打时间戳的歌词，自动滚到我鼠标下面。
然后我再点一下，然后再下一句自动上来。
我整个过程甚至不需要移动鼠标，只需要一直点、点、点。
一直点完整首歌。
我当时觉得，这不就是一个特别小的交互吗？应该几句话就能做完。
结果，我错了。
AI 做一个游戏可能只需要一句话
最让我想不通的一点是：
现在让 AI “帮我做一个小游戏”，它可能一句话就能给我生成出来。
贪吃蛇、俄罗斯方块、打砖块，甚至带动画、积分、按钮、音效。
几百行甚至几千行代码，它很快就能写出来。
但是今天这么一个小按钮，却来来回回改了不知道多少次。
我说：
用户点击上一个时间戳以后，下一句未打时间戳的歌词自动滚动到用户鼠标的位置，用户不用动鼠标就能一直打完整首歌。
我觉得已经说得很清楚了。
AI第一次理解成：
“滚到下一句。”
不对。
第二次变成：
“下一句进入可视区域。”
还是不对。
第三次可能是：
“把下一句高亮。”
依然不对。
我真正想要的是：
鼠标的位置不动。下一句的“打时间戳”按钮，要准确地移动到刚才这个按钮的位置。
这里看起来只差了一点点，但产品体验上完全是两回事。
“滚到下一句”和“下一句准确来到鼠标下面”，只有几个字的差别。
代码可能也只差几十行。但这几十行，今天差点把我磨死。
后来我突然明白了一个问题，不是 AI 不会做这种细活。
而是这种事情对 AI 来说，本身就很难“感受到”。
如果是一个真人工程师坐在这里开发这个功能，他可能根本不需要我解释那么多。
他自己用一次就会发现：“怎么每打一句都还要往下挪鼠标？”
打十句以后，他自己可能就烦了。
他会自然地想：“能不能让下一句自己过来？”
因为他有手。有鼠标。有眼睛。
他真的在用这个东西。他能够感受到这个交互造成的摩擦。
可是 AI 不会。对 AI 来说：
按钮能点击。时间戳成功写进去了。下一句也显示出来了。
从功能角度来说：已经完成。
可是人真正使用的时候：很难用。
这两个标准完全不一样。AI 看到了交互，但它没有经历交互。
今天我还碰到了另外一个问题。
我给 AI 看 GIF。
因为这个功能用语言解释很麻烦，我想，那我直接录给你看总行了吧？
结果又发现一个很现实的问题。
很多 AI 对 GIF、视频这类动态内容的理解，并不像人一样。
人看一段动画，可以很自然地意识到：鼠标没动。点了一下。歌词滚动了。
下一句按钮刚好来到原来的位置。
这是一个连续的动作。
但是 AI 对动态视觉的理解，本质上仍然是把视觉信息拆开以后再分析。
即便现在的视频理解已经比以前强很多，它也还是很容易漏掉这种特别细微的关系：
按钮到底移动了多少像素？
鼠标有没有动？
滚动的是整个页面还是歌词容器？
下一句只是“出现”了，还是准确地到了鼠标位置？
对人来说，这些东西一眼就能看出来。
甚至不是“看出来”，是感觉出来。
而 AI 很多时候只能从图像、坐标、代码和状态里推断。
所以今天我突然想到一句话：AI 可以看到交互，但是人是在经历交互。
这两件事情差得很远。最后几句又出了问题
好不容易前面的连续打点终于做对了。我以为结束了。
结果打到歌词最后几句的时候，又坏了。
下一句不再继续滚到鼠标的位置，一开始我还以为逻辑又错了。
后来才发现，不是，是因为歌词已经到底了，页面下面已经没有内容可以继续滚。
假设歌词区域一次能显示二十行，我的鼠标固定在中间第十行的位置。
前面有很多歌词的时候没有问题，因为下面还有内容，所以它可以一直往上滚。
但是到了最后一句，下面什么都没有了，
浏览器就没办法继续把最后一句往上推到鼠标的位置。
解决方法其实也非常简单，给歌词最后面加一段“看不见的空白”。
相当于虽然歌词结束了，但滚动区域还没有结束。
这样最后一句也可以继续滚到鼠标下面。
又是一个特别小的问题，又是一个如果真正使用，很快就会发现的问题。
我开始重新理解所谓的“用户体验”
以前说用户体验，我总觉得这几个字很虚。
好不好用。舒不舒服。顺不顺手。听起来都是一种感觉。
但是今天这个例子让我发现，很多所谓的“痛苦”，其实是可以计算的。
比如我最开始那个版本：一首歌一百句歌词。
每打一句，我的鼠标就往下移动一次。
那么整首歌下来，可能产生：几十次鼠标移动。十几次滚轮操作。几十次重新寻找按钮。
还有不断移动视线。
如果是快歌，还会产生误操作。
这些东西，其实都可以变成数字。
鼠标移动距离。点击次数。滚动次数。目标重新定位次数。完成任务需要多少时间。
误操作概率。
突然之间，“这个功能好难用”就不再只是情绪了。
它其实是一种用户操作成本。
AI 不需要真的感受到痛苦
这个时候我又想到另外一个问题。
AI 没有痛苦。
它不会因为一个按钮难点而烦。
不会因为鼠标要一直移动而累。
不会因为连续改错十次害怕丢工作。
它没有这些人类的反馈。
所以我们不能期待 AI：
“你自己用用，你就知道难受了。”
它不知道。
但是这不代表这个问题没有办法解决。
AI 不需要真的拥有人的痛苦。
它只需要有一个：
对应于人类痛苦的计算指标。
比如：
如果用户完成一个任务，需要移动鼠标 4000 像素。
成本 +10。
需要滚动 20 次。
成本 +20。
需要不断切换视线。
成本 +15。
需要等待动画。
成本 +5。
误点击率变高。
成本继续增加。
那么 AI 不需要真的觉得烦。
它只需要知道：
这个方案的用户成本很高。
然后继续优化。
我后来把这个东西想成了一个：
Human Friction，人的交互摩擦。
或者更直接一点：
用户动作成本。
现在很多 AI 只检查“功能有没有做出来”
比如：
按钮能不能点？
能。
时间戳有没有保存？
保存了。
页面有没有报错？
没有。
那它就会认为：
任务完成。
但真人用户真正关心的是另外一套东西：
我要点几次？
我要移动多少次鼠标？
我要不要反复找东西？
我要等多久？
我会不会点错？
我能不能一口气把整个任务做完？
这两个评价体系其实完全不同。
我甚至觉得，以后的 AI Agent 应该同时有两套评价系统。
一套是工程上的。
程序有没有错误。
数据有没有问题。
测试有没有通过。
另外一套应该是人的。
这个东西到底累不累。
费不费眼睛。
费不费手。
费不费脑子。
浪不浪费时间。
普通人真正难的地方，也许不是不会写代码
今天这个事情还有一个让我挺有感触的地方。
现在很多人会说：
AI 让人人都能写程序。
这句话不能说错。
至少现在普通人确实已经可以用自然语言做出很多以前完全做不出来的东西。
但是我越来越觉得：
做出来，和打磨好，是完全不同的两件事情。
让 AI：
“给我做一个歌词时间戳工具。”
可能很快。
真正到了：
“我要连续打一百句歌词的时候，一次鼠标都不要移动。”
难度突然就上来了。
而普通人很难知道应该怎么描述。
什么 scrollTop。
什么 clientY。
什么 anchor。
什么 bottom spacer。
普通用户怎么可能天然知道这些东西？
如果最后所谓的“自然语言编程”，变成：
虽然不用学 JavaScript 了，
但是你得学会写一份特别专业的 PRD、交互规范、验收标准和测试报告，
那其实只是把一个门槛换成了另外一个门槛。
我觉得真正好的 AI，不应该让我学会怎么像程序员一样说话
我只需要告诉它：
这个东西我用起来很累。
我希望鼠标不要一直移动。
我想一直点就能完成整首歌。
剩下的东西，本来应该由 AI 去推导。
它应该自己理解：
用户是在进行高频重复操作。
鼠标移动是额外成本。
下一操作目标应该主动进入固定操作位。
最后一条歌词还存在滚动边界。
需要增加底部滚动空间。
然后自己实现、自己测试。
甚至自己连续点一百次。
如果最后一句没对齐，就继续改。
而不是等我告诉它：
“最后一句为什么不能再往上滚了？”
今天只是一个按钮
今天折腾我的，其实就只是一个很小的按钮。
但这个小按钮让我看到了一件挺大的事情。
现在 AI 已经非常擅长：
从 0 做到 60 分。
一句话生成一个页面。
一句话生成一个小游戏。
一句话生成一个能跑的软件。
这些已经很厉害了。
但真正从：
60 分到 80 分。
80 分到 90 分。
90 分到“这个东西真的很好用”。
仍然有大量工作藏在这些很小很小的细节里。
而这些细节最难的地方，往往不是代码。
是人。
人的手怎么动。
眼睛怎么看。
脑子需要记住什么。
哪里会烦。
哪里会累。
哪里会因为多做一个动作而打断节奏。
AI不一定需要变成人。
但如果以后它真的想成为一个能够独立做产品的工程师，它至少要学会一件事情：
虽然自己不会痛，但要知道什么东西会让人痛。
今天这个按钮，大概就是我第一次这么具体地意识到这件事。