零容错的数据，不要交给语音识别
如果产品里某一步容不下一个字符的错误，就别让语音成为通过这一步的唯一方式。这就是全部教训，代价是一个客户关系。
当时在做什么
客户要做一台面向学校的语音设备。核心流程很简单，学生对着设备报出自己的学号，系统自动拉出这个学生的学习记录和老师评语，念给他听。没有屏幕、没有 App、不用登录，走过去开口就行。
逻辑是干净的，在会议室里听着体验也不错。它在第一步就断了。
识别意图和识别数字是两回事
语音识别很擅长判断一个人想干什么，捕捉精确的数字序列则明显差一截，而这里的学号是八位。错一位就找不到对应记录，流程当场停住，没有部分正确这一说。
测试里出现了三类问题，而且是叠加的。
口音与近音字
普通话里三和四很容易混，一和七也是，带上方言差距更大。英语里 fifteen 和 fifty、信道差的时候 M 和 N，是同一类问题。任何语言都有这样的字对，而身份编号恰恰是它们伤害最大的地方。
弱网
网速一慢，识别的往返时间就拉长。用户等了半天，最后拿到的答案还是错的。延迟不只是让人烦躁，它让人不再相信重试有用。
孩子真实的说话方式
孩子不会因为你需要就把字咬清楚，而且他一直在动，嘴和麦克风的距离一直在变。在安静环境里由成年人测出来还不错的准确率，到了真实教室里明显下滑。
没有屏幕，把一个糟糕的步骤变成了死路
在手机或平板上，识别错了是能救回来的。用户看到屏幕上是 38472619，发现那个 7 应该是 1，自己改掉。无屏设备上，用户永远不知道机器听到了什么，他能得到的只有一句「没找到记录」。于是他再报一遍，再错一遍，从失败到成功之间没有路。
这一点值得说明白，因为它在写需求的时候很容易被忽略。去掉屏幕不只是去掉显示，它同时去掉了纠错回路。
后来改成了什么
学号改成在手机端注册时绑定到账号。设备端的语音只负责身份确认和日常对话，不再需要承载精确的数字串。语音去做它擅长的事，也就是模糊的、容错高的输入，大致对了也仍然有用的那种。
重做之后我们重新联系了这个客户。耽误的时间是我们造成的，客户生气也合理，除了把设计改对之外没什么可辩解的。
我们现在会先问的那句话
在这一步，如果模型判断错了，用户能不能察觉，能不能自己纠正？
能，语音可以用。不能，就别把这一步交给语音，提前绑定、换一条通道，或者加一个用户真的能操作的确认环节。
「AI 能做这件事」和「AI 在这个具体场景里能做可靠」是两个不同的说法。把它们分开，是做语音硬件最基本的纪律，而且在写规格的阶段执行，通常比开完模再执行便宜得多。