先提个有意思的现象我在测试现场盯数据的时候经常要一边看示波器一边算参数手上还戴着防静电手套按计算器特别别扭。后来干脆用LabVIEW给自己做了个带语音识别的计算器对着麦克风说一句“三加五乘二”结果直接显示出来还能语音播报。这就是这个项目的起因与其在仪器和键盘之间来回切换不如让计算器学会听懂人话。这篇内容适合两类人看一是想用LabVIEW做信号采集、仪器上位机但不太清楚怎么和现代语音识别引擎结合的人二是实验室里做课设或比赛Demo需要一个能现场演示、效果直观的完整案例的人。我会把这个项目的完整链路拆开讲清楚语音怎么进来、文字怎么变成算式、算式怎么在LabVIEW里算出结果、最后界面怎么交互以及我踩过的几个坑。1. 整体方案选型从“按下按钮”到“说出算式”的架构思路先说方案选型。拿到“语音智能识别计算器”这个需求时摆在面前的第一件事不是写界面而是确定语音识别引擎怎么接进LabVIEW。LabVIEW是图形化数据流编程环境它的强项是仪器控制、数据采集、界面搭建但在人工智能和自然语言处理这块非常薄弱。它自己不自带中文语音识别能力所以必须把语音识别引擎放到外部再和LabVIEW通信。我当时比对了三条路线下面这张表是我实测后的感受。方案接入方式中文识别质量离线使用工程复杂度我的结论Windows自带SAPI识别ActiveX调用一般依赖系统语音配置支持低适合快速验证原型在线语音识别服务HTTP/WebSocket调用较好不支持中不推荐有网络依赖和隐私问题本地开源模型VoskPython节点桥接较好支持中文模型支持中推荐稳定且可控SAPI这条路我一开始试过写起来确实快用LabVIEW自带的ActiveX容器直接调用Windows的SpInProcRecognizer就行。但实际用下来有个问题它依赖Windows的语音识别后台服务相同的一句话在笔记本自带麦克风和USB桌面麦克风上识别结果会差很多。而且SAPI的中文识别对短句支持尚可对“一百二十三乘以四”这样的较长表达式经常出现文字漏读。在线识别服务我没有采纳原因是测试现场的工控机经常不在外网环境里万一网络抖动整个计算器就卡住。最划算的方案变成了Vosk一个开源离线语音识别引擎有官方中文模型模型文件几十兆识别速度很快。技术上我用的是LabVIEW的Python节点也叫Python Connect作为桥LabVIEW负责界面、状态机、算式解析和结果展示Python负责麦克风采集、调用Vosk模型、把识别出来的文本返回给LabVIEW。这样分工很清晰。整个系统的数据流是麦克风采集音频 → Vosk离线模型识别成文本 → LabVIEW文本清洗和规范化 → 表达式解析器求出算式 → 结果上屏并TTS播报。每一步之间都是独立的模块后续替换识别引擎或修改解析规则都很方便。2. Python节点集成Vosk语音识别模块的落地过程2.1 环境准备与模型下载先说环境。我开发时用的是LabVIEW 2021这一版开始Python节点比较稳定支持Python 3.6到3.10。我装了Python 3.8个人建议不要用太新的版本有些第三方库对Python 3.11以上的支持还没完全跟上。Python侧要装的库有三个vosk识别引擎本体。pyaudio麦克风采集。numpyVosk调用的依赖顺便用于音频数据处理。模型方面要单独下载Vosk的中文模型我用的版本是vosk-model-small-cn解压后大概40MB。这个模型体积小、速度快在安静环境下对数字和运算符的识别准确率足够如果现场环境比较吵也可以换更大的vosk-model-cn模型。2.2 Python端脚本设计语音识别的Python端脚本我的核心思路是封装一个函数LabVIEW按下识别按钮时Python脚本开始录音2到3秒然后调用Vosk一次识别最后把文本返回。文件名为voice_calculator.py关键代码如下。import json import queue import sys import vosk import pyaudio _model None def init_model(model_dir): global _model if _model is None: _model vosk.Model(model_dir) return True def recognize_expression(record_seconds3.0): global _model if _model is None: init_model(vosk-model-small-cn-0.22) sample_rate 16000 rec vosk.KaldiRecognizer(_model, sample_rate) p pyaudio.PyAudio() stream p.open(formatpyaudio.paInt16, channels1, ratesample_rate, inputTrue, frames_per_buffer4000) result_text try: frames [] for _ in range(int(sample_rate / 4000 * record_seconds)): data stream.read(4000) frames.append(data) if rec.AcceptWaveform(data): res json.loads(rec.Result()) result_text res.get(text, ) if not result_text: res json.loads(rec.FinalResult()) result_text res.get(text, ) finally: stream.stop_stream() stream.close() p.terminate() return result_text这里有个容易忽略的细节Vosk的采样率固定要求16000Hz单声道。如果麦克风设备默认采样率是44100Hz或48000Hz需要在采集时做重采样否则识别率会断崖式下跌。我在代码里通过p.open强制指定rate为16000这依赖PyAudio底层的重采样能力实测大部分USB麦克风都能正常处理。另一个更容易踩的坑是模型加载。Vosk的模型文件在首次加载时需要解压并载入内存耗时约2到3秒。我一开始把模型初始化放在每次识别函数里调用导致按钮按下后要等两三秒才开始录音体验很差。后来我在整个程序的启动阶段就调用一次init_model让模型常驻内存后续识别就很快了实测单次识别在1秒内能出结果。2.3 LabVIEW侧的Python节点配置LabVIEW里调用Python节点的方式很直观在程序框图上放置Python节点右键选择“配置Python节点”指定Python解释器路径、脚本路径、函数名和参数类型。我踩过的第一个坑是解释器路径。如果电脑上装了多个Python环境LabVIEW默认调用的可能不是你装了Vosk那个解释器。我的建议是直接在配置面板里写死Python的完整路径比如C:\Python38\python.exe不要用系统默认否则发布会找不到那个环境。第二个坑是中文编码。Python返回的识别文本是UTF-8编码的中文字符串LabVIEW的字符串默认使用本机代码页存储直接接出来会出现乱码。我当时的解决办法是让Python端返回Unicode码点序列比如“三加五”变成203772085220116这样的十六进制码点串LabVIEW侧按码点还原成字符绕开了编码不一致的问题。如果你用的LabVIEW版本比较新也可以直接尝试带编码转换的字符串处理函数但码点方案最稳。3. 文本规范化让口语“一百二十三”变成机器不会算错的123语音识别引擎返回的是自然语言文本比如“一百二十三乘以四”它和计算器能处理的表达式123*4之间还隔着一层文本规范化。这一层不做后面解析器再强也没用。3.1 口语干扰词与空结果处理Vosk返回的文本经常夹杂噪声词比如“就是说”、“嗯”、“啊”、“那个”。在安静环境里这种情况少一些但只要旁边有人说话识别结果里就会混入无关词汇。我的处理很简单维护一个停用词表在做数字转换之前先把这些词删除。删除操作在LabVIEW里就是字符串数组匹配和替换运行成本很低。还有一种情况是识别为空文本或只有一个修饰词。比如用户只说了“嗯”或者录音期间麦克风没拾到有效音量。此时直接返回错误提示“没有听清楚请再说一次”不要硬着头皮往下走。我前面踩过这个坑空文本进入解析器后直接报数组越界程序崩溃。3.2 中文数字转阿拉伯数字这个环节是整个文本规范化的核心。中文数字和阿拉伯数字的转换之所以麻烦是因为中文有“十百千万”这样的数位词而且读数顺序和进制结构不完全一致。我使用的转换算法一句话概括从左到右扫描遇到“零一二三四五六七八九”累加到当前数字遇到“十百千万”就按数位乘以对应量级并累加到结果。举两个例子“一百二十三”读作1×100 2×10 3结果是123。“十万零五”读作1×100000 0×10000 5结果是100005。这里要小心处理“十”在开头的情况比如“十五”正确的做法是把它当作1×105。如果一个字一个字硬转很容易把“十五”转成“15”看着没错可以一旦出现在“十五加三”这种表达式里“十五”两个字会被当成两个独立的数字“十”和“五”解析就全错了。正确做法是在分词阶段就把连续的读数字段合并成一个整数。3.3 运算符与扩展功能的关键词映射接下来要把口语中的运算词映射成解析器认识的运算符。用户说法映射后加、加上、还有减、减去、少-乘、乘以、乘上*除、除以/的平方、平方^2开根号、开平方sqrt加括号、左括号、右括号( )映射过程中有个最值得注意的细节“除”和“除以”在数学上是两种相反的意思但在口语里绝大多数人说“三除五”其实心里想的是“三除以五”也就是3÷5。我在这个项目里做了简化将“除”和“除以”统一映射为“左侧数字 ÷ 右侧数字”。如果未来要支持更精确的语义就必须引入句法分析而不能只靠关键词替换这是这个简化方案的极限我把它记在项目说明里避免使用者产生误解。处理完这一步语音文本就变成了标准的算术表达式字符串比如123*4sqrt(16)。到这里终于可以把球交给计算引擎了。4. 表达式解析与求值在LabVIEW里写了一个不依赖eval的计算核心LabVIEW没有类似Pythoneval()的现成函数不能直接把一个字符串当成数学公式计算。所以我要自己实现一个小型表达式解析器。计算器用到的语法并不复杂数字、四则运算、括号、幂运算、平方根这里我采用“中缀转后缀 后缀求值”的方法也就是调度场算法。4.1 为什么不能直接用字符串拼接控件计算有人会问LabVIEW不是有公式节点吗把字符串塞进去不行吗公式节点是给固定公式用的它在编译时必须知道公式结构运行时不能动态改变。还有人说用“字符串转数值”控件那个只能处理单个数字比如把“123”转成数值123但绝不可能把123*4直接算出来。计算引擎本质上是编译原理中一个最小的“表达式编译器”只能字字扫描、Token化、按优先级归约。4.2 调度场算法与后缀求值调度场算法的核心是维护两个栈输出队列和运算符栈。规则是遇到数字直接进输出队列遇到运算符就与运算符栈顶比较优先级优先级低的先进输出队列遇到左括号直接入栈遇到右括号则弹出到左括号为止最后把运算符栈清空。这样中缀表达式35*2就会变成后缀表达式3 5 2 * 。后缀表达式的求值规则再简单不过从左到右扫描碰到数字压栈碰到运算符就弹出两个数字计算再把结果压回去。扫描结束时栈里唯一那个数字就是最终结果。我在LabVIEW里实现这个过程的方式是先用字符串数组保存Token序列再用两个长度可变的数组模拟栈和队列。程序框图里就是几个Case结构循环处理循环次数等于Token数量。对于学过一点数据结构的人来说这个模块并不难我前面做的时候反复确认了两处容易写错的地方优先级判断必须包含运算符之间的两两比较表而不能只看当前字符。乘除对加减优先幂运算对乘除优先括号优先级最高。后缀求值时弹出操作数的顺序不能反。比如5 2 -先弹出2作为右操作数再弹出5作为左操作数算出来是3。如果先弹出5作为左操作数就算出负数了。4.3 扩展运算的实现我不仅仅满足于四则运算语音口算里还有一个高频词是“平方”所以我给Token解析器加了两个特殊标记^表示幂运算sqrt表示平方根。关键点是这些运算符的位置处理。通常“五的平方”会被规范化成5^2那么中缀转后缀时我需要把^变成运算符参与优先级比较^的优先级比乘除更高而且是右结合。平方根则需要设计成类似函数调用sqrt(9)在Token化时被当作“函数调用token”求值时调用LabVIEW里的平方根函数而不是普通运算符。4.4 精度、除零与错误提示数值计算绕不开两个问题浮点数精度和非法输入。LabVIEW的双精度浮点数在计算3*0.1时会出现类似0.30000000000000004的尾差如果直接上屏看起来很难受。我显示结果前统一调用“格式化数值”控件保留8位有效数字顺手解决了尾差问题。除零问题要单独拦截当前缀表达式中出现5 0 /时求值器不能去执行真正的除法否则会产生无穷大。我在运算符执行环节加了一个条件判断如果除数为0直接返回一个错误标记停止计算提示“不能除以零”。解析器同理如果Token序列不合法比如9988-9999也要在求值前检查栈状态结束时操作数栈必须只有一个元素否则说明表达式非法返回“计算公式不符合规则”。5. 状态机与交互设计计算器也要有点“产品感”这一步其实很关键一个好的语音计算器交互逻辑比识别引擎更影响使用体验。如果每次按下按钮都需要盯着屏幕确认“它到底听没听”用户的信任感会直线下降。我用一个简单的状态机来管理整个程序流程。5.1 五状态轮转程序在五个状态之间切换空闲、录音中、识别中、解析中、结果完成。空闲状态下界面上的按钮提示“按住说话”用户按下按钮的瞬间程序从空闲进入录音状态同时Python端开始采集麦克风录音结束进入识别中界面显示“正在听”识别结果返回后进入解析中如果解析成功就跳到结果完成把算式、结果显示出来并触发TTS播报如果解析失败则回到空闲提示重说。状态机在LabVIEW里用枚举类型加While循环实现循环每100毫秒轮询一次当前状态状态转移由事件结构里的按钮事件触发。这个模型的好处是录音时如果用户再次按下按钮可以直接取消本次识别避免“我刚才其实不想让它算”这种误触。5.2 按住说话而不是点击说话计算器识别的是短句不是连续对话。连续识别模式下麦克风常开非常消耗CPU而且周围聊天声音很容易被误识别成算式。我最终选了“按住说话”按下按钮开始录音松开按钮停止录音并自动识别。这个交互在LabVIEW里实现的时候要注意按钮本身是机械动作类型不能直接用Click事件因为Click事件在鼠标抬起时才触发。正确做法是取布尔按钮的机械动作在Mouse Down事件里置录音标志位在Mouse Up事件里清标志位。程序框图的While循环里不断检查这个标志位一旦为真就调用Python识别函数。5.3 TTS语音播报结果识别和计算都完成了如果把算式用语音读出来这个工具才算真的完整。这里我直接用Windows系统语音引擎通过LabVIEW的ActiveX节点调用SpVoice对象。调用的核心代码很短创建SpVoice对象设置Voice属性为Microsoft Huihui中文语音调用Speak方法把“三加五乘二等于13”整个字符串传进去。有一点要提醒LabVIEW的ActiveX节点与Python节点一样有中文编码问题。如果字符串来自界面控件的Caption通常没问题但如果是代码里拼出来的中文字符串建议使用Unicode码点数组组装后再传给SpVoice。TTS播报还有一个附加好处出错时播报错误原因。我给解析失败和识别失败分别录了固定话术比如“没有听到算式”、“计算格式不正确”用户不需要看屏幕就知道发生了什么。5.4 前面板布局与视觉反馈界面我用的是极简布局思路上方一个大号结果显示框字号设在48磅以上让两米外的人都能看清下方一个按钮按钮标签就是“按住说话”边上给两个状态灯——绿色表示空闲黄色表示正在听红色表示识别失败。为了记录多次计算历史我放了一个表格控件把每次计算的表达式、结果、时间戳存进去。旁边一个小波形图显示最近20次计算结果的走向方便连续算一组参数时能直观看到趋势。虽然计算器最重要的功能不出彩但这些小细节让它在演示时很有说服力。6. 部署与调试踩过的坑和最后剩下的优化空间项目从能跑到能给别人用中间隔着一大堆调试细节。我按踩坑顺序把最有价值的几个问题整理出来。6.1 Python环境跟随程序走LabVIEW项目打包成EXE后Python节点仍然会去找开发机上配置的那个Python解释器路径。别人拿到你的EXE如果没有安装对应Python环境和依赖库程序启动时直接报错。解决办法有两条我用的组合拳是打包时写一个前置检查VI启动时探测python.exe是否存在不存在则弹窗提示安装Python并给出依赖清单。把Vosk模型放进项目目录不要写绝对路径模型路径动态读取当前VI所在目录这样整个项目文件夹拷到任意电脑都能跑。6.2 PyAudio安装失败与替代方案在Windows上用pip install pyaudio经常会卡在编译阶段尤其是缺少Microsoft Visual C Build Tools的机器。我后来直接用pip install pipwin和pipwin install pyaudio解决的或者去PyAudio官网下载预编译的whl文件安装。还有个小概率问题部分笔记本自带的麦克风阵列是多通道设备PyAudio打开输入流时会报错“Invalid argument”此时需要在设备索引里手动指定常规麦克风设备。如果不想折腾PyAudio还有个次选方案用LabVIEW自带的“采集声音”函数把音频录制为WAV文件再用Python读取文件进行识别。这个方案虽然多了一步文件I/O但绕开了Python侧录音的兼容性问题识别效果一样。6.3 模型加载与识别延迟优化前面提过模型常驻内存解决了首次加载慢的问题。但还有一个隐藏延迟每次调用Python函数时LabVIEW会在Python解释器里执行一次函数调用这个过程本身有几十毫秒开销。如果识别结果要等很久可以把Python脚本改成内部维护一个轮询队列这样延迟可以压到300毫秒以内。对于当前这个计算器场景2秒内的响应其实是够用的没有过度优化必要。6.4 现场嘈杂环境的处理思路最后说一个真实问题如果计算器放在测试车间里环境噪声很大Vosk的识别准确率会明显下降。我目前用到的缓解手段有三种模型升级到大体积中文模型牺牲一点加载时间来换准确率。录音时加入信噪比判断只有麦克风采集到的有效音量超过阈值才开始喂给识别引擎录音结束后低于阈值的片段直接丢弃。规范化层保留数字纠错功能比如识别结果里突然出现“三加百五”能通过常见读法推断出“百五”是“一百零五”的口误这种纠错能力是需要不断积累口语样本才能做扎实的。这些优化方向如果全部做完就是一个比较完整的“语音交互计算器”项目了。我自己的下一步计划是把这一整套语音输入能力复用到更复杂的场景比如语音控制仪器的量程切换、语音输入实验记录。坦白说计算器本身只是一个起点真正有价值的是这条从语音识别到语义解析再到LabVIEW交互的链路它能走的远比“算个数”要远。
先提个有意思的现象我在测试现场盯数据的时候经常要一边看示波器一边算参数手上还戴着防静电手套按计算器特别别扭。后来干脆用LabVIEW给自己做了个带语音识别的计算器对着麦克风说一句“三加五乘二”结果直接显示出来还能语音播报。这就是这个项目的起因与其在仪器和键盘之间来回切换不如让计算器学会听懂人话。这篇内容适合两类人看一是想用LabVIEW做信号采集、仪器上位机但不太清楚怎么和现代语音识别引擎结合的人二是实验室里做课设或比赛Demo需要一个能现场演示、效果直观的完整案例的人。我会把这个项目的完整链路拆开讲清楚语音怎么进来、文字怎么变成算式、算式怎么在LabVIEW里算出结果、最后界面怎么交互以及我踩过的几个坑。1. 整体方案选型从“按下按钮”到“说出算式”的架构思路先说方案选型。拿到“语音智能识别计算器”这个需求时摆在面前的第一件事不是写界面而是确定语音识别引擎怎么接进LabVIEW。LabVIEW是图形化数据流编程环境它的强项是仪器控制、数据采集、界面搭建但在人工智能和自然语言处理这块非常薄弱。它自己不自带中文语音识别能力所以必须把语音识别引擎放到外部再和LabVIEW通信。我当时比对了三条路线下面这张表是我实测后的感受。方案接入方式中文识别质量离线使用工程复杂度我的结论Windows自带SAPI识别ActiveX调用一般依赖系统语音配置支持低适合快速验证原型在线语音识别服务HTTP/WebSocket调用较好不支持中不推荐有网络依赖和隐私问题本地开源模型VoskPython节点桥接较好支持中文模型支持中推荐稳定且可控SAPI这条路我一开始试过写起来确实快用LabVIEW自带的ActiveX容器直接调用Windows的SpInProcRecognizer就行。但实际用下来有个问题它依赖Windows的语音识别后台服务相同的一句话在笔记本自带麦克风和USB桌面麦克风上识别结果会差很多。而且SAPI的中文识别对短句支持尚可对“一百二十三乘以四”这样的较长表达式经常出现文字漏读。在线识别服务我没有采纳原因是测试现场的工控机经常不在外网环境里万一网络抖动整个计算器就卡住。最划算的方案变成了Vosk一个开源离线语音识别引擎有官方中文模型模型文件几十兆识别速度很快。技术上我用的是LabVIEW的Python节点也叫Python Connect作为桥LabVIEW负责界面、状态机、算式解析和结果展示Python负责麦克风采集、调用Vosk模型、把识别出来的文本返回给LabVIEW。这样分工很清晰。整个系统的数据流是麦克风采集音频 → Vosk离线模型识别成文本 → LabVIEW文本清洗和规范化 → 表达式解析器求出算式 → 结果上屏并TTS播报。每一步之间都是独立的模块后续替换识别引擎或修改解析规则都很方便。2. Python节点集成Vosk语音识别模块的落地过程2.1 环境准备与模型下载先说环境。我开发时用的是LabVIEW 2021这一版开始Python节点比较稳定支持Python 3.6到3.10。我装了Python 3.8个人建议不要用太新的版本有些第三方库对Python 3.11以上的支持还没完全跟上。Python侧要装的库有三个vosk识别引擎本体。pyaudio麦克风采集。numpyVosk调用的依赖顺便用于音频数据处理。模型方面要单独下载Vosk的中文模型我用的版本是vosk-model-small-cn解压后大概40MB。这个模型体积小、速度快在安静环境下对数字和运算符的识别准确率足够如果现场环境比较吵也可以换更大的vosk-model-cn模型。2.2 Python端脚本设计语音识别的Python端脚本我的核心思路是封装一个函数LabVIEW按下识别按钮时Python脚本开始录音2到3秒然后调用Vosk一次识别最后把文本返回。文件名为voice_calculator.py关键代码如下。import json import queue import sys import vosk import pyaudio _model None def init_model(model_dir): global _model if _model is None: _model vosk.Model(model_dir) return True def recognize_expression(record_seconds3.0): global _model if _model is None: init_model(vosk-model-small-cn-0.22) sample_rate 16000 rec vosk.KaldiRecognizer(_model, sample_rate) p pyaudio.PyAudio() stream p.open(formatpyaudio.paInt16, channels1, ratesample_rate, inputTrue, frames_per_buffer4000) result_text try: frames [] for _ in range(int(sample_rate / 4000 * record_seconds)): data stream.read(4000) frames.append(data) if rec.AcceptWaveform(data): res json.loads(rec.Result()) result_text res.get(text, ) if not result_text: res json.loads(rec.FinalResult()) result_text res.get(text, ) finally: stream.stop_stream() stream.close() p.terminate() return result_text这里有个容易忽略的细节Vosk的采样率固定要求16000Hz单声道。如果麦克风设备默认采样率是44100Hz或48000Hz需要在采集时做重采样否则识别率会断崖式下跌。我在代码里通过p.open强制指定rate为16000这依赖PyAudio底层的重采样能力实测大部分USB麦克风都能正常处理。另一个更容易踩的坑是模型加载。Vosk的模型文件在首次加载时需要解压并载入内存耗时约2到3秒。我一开始把模型初始化放在每次识别函数里调用导致按钮按下后要等两三秒才开始录音体验很差。后来我在整个程序的启动阶段就调用一次init_model让模型常驻内存后续识别就很快了实测单次识别在1秒内能出结果。2.3 LabVIEW侧的Python节点配置LabVIEW里调用Python节点的方式很直观在程序框图上放置Python节点右键选择“配置Python节点”指定Python解释器路径、脚本路径、函数名和参数类型。我踩过的第一个坑是解释器路径。如果电脑上装了多个Python环境LabVIEW默认调用的可能不是你装了Vosk那个解释器。我的建议是直接在配置面板里写死Python的完整路径比如C:\Python38\python.exe不要用系统默认否则发布会找不到那个环境。第二个坑是中文编码。Python返回的识别文本是UTF-8编码的中文字符串LabVIEW的字符串默认使用本机代码页存储直接接出来会出现乱码。我当时的解决办法是让Python端返回Unicode码点序列比如“三加五”变成203772085220116这样的十六进制码点串LabVIEW侧按码点还原成字符绕开了编码不一致的问题。如果你用的LabVIEW版本比较新也可以直接尝试带编码转换的字符串处理函数但码点方案最稳。3. 文本规范化让口语“一百二十三”变成机器不会算错的123语音识别引擎返回的是自然语言文本比如“一百二十三乘以四”它和计算器能处理的表达式123*4之间还隔着一层文本规范化。这一层不做后面解析器再强也没用。3.1 口语干扰词与空结果处理Vosk返回的文本经常夹杂噪声词比如“就是说”、“嗯”、“啊”、“那个”。在安静环境里这种情况少一些但只要旁边有人说话识别结果里就会混入无关词汇。我的处理很简单维护一个停用词表在做数字转换之前先把这些词删除。删除操作在LabVIEW里就是字符串数组匹配和替换运行成本很低。还有一种情况是识别为空文本或只有一个修饰词。比如用户只说了“嗯”或者录音期间麦克风没拾到有效音量。此时直接返回错误提示“没有听清楚请再说一次”不要硬着头皮往下走。我前面踩过这个坑空文本进入解析器后直接报数组越界程序崩溃。3.2 中文数字转阿拉伯数字这个环节是整个文本规范化的核心。中文数字和阿拉伯数字的转换之所以麻烦是因为中文有“十百千万”这样的数位词而且读数顺序和进制结构不完全一致。我使用的转换算法一句话概括从左到右扫描遇到“零一二三四五六七八九”累加到当前数字遇到“十百千万”就按数位乘以对应量级并累加到结果。举两个例子“一百二十三”读作1×100 2×10 3结果是123。“十万零五”读作1×100000 0×10000 5结果是100005。这里要小心处理“十”在开头的情况比如“十五”正确的做法是把它当作1×105。如果一个字一个字硬转很容易把“十五”转成“15”看着没错可以一旦出现在“十五加三”这种表达式里“十五”两个字会被当成两个独立的数字“十”和“五”解析就全错了。正确做法是在分词阶段就把连续的读数字段合并成一个整数。3.3 运算符与扩展功能的关键词映射接下来要把口语中的运算词映射成解析器认识的运算符。用户说法映射后加、加上、还有减、减去、少-乘、乘以、乘上*除、除以/的平方、平方^2开根号、开平方sqrt加括号、左括号、右括号( )映射过程中有个最值得注意的细节“除”和“除以”在数学上是两种相反的意思但在口语里绝大多数人说“三除五”其实心里想的是“三除以五”也就是3÷5。我在这个项目里做了简化将“除”和“除以”统一映射为“左侧数字 ÷ 右侧数字”。如果未来要支持更精确的语义就必须引入句法分析而不能只靠关键词替换这是这个简化方案的极限我把它记在项目说明里避免使用者产生误解。处理完这一步语音文本就变成了标准的算术表达式字符串比如123*4sqrt(16)。到这里终于可以把球交给计算引擎了。4. 表达式解析与求值在LabVIEW里写了一个不依赖eval的计算核心LabVIEW没有类似Pythoneval()的现成函数不能直接把一个字符串当成数学公式计算。所以我要自己实现一个小型表达式解析器。计算器用到的语法并不复杂数字、四则运算、括号、幂运算、平方根这里我采用“中缀转后缀 后缀求值”的方法也就是调度场算法。4.1 为什么不能直接用字符串拼接控件计算有人会问LabVIEW不是有公式节点吗把字符串塞进去不行吗公式节点是给固定公式用的它在编译时必须知道公式结构运行时不能动态改变。还有人说用“字符串转数值”控件那个只能处理单个数字比如把“123”转成数值123但绝不可能把123*4直接算出来。计算引擎本质上是编译原理中一个最小的“表达式编译器”只能字字扫描、Token化、按优先级归约。4.2 调度场算法与后缀求值调度场算法的核心是维护两个栈输出队列和运算符栈。规则是遇到数字直接进输出队列遇到运算符就与运算符栈顶比较优先级优先级低的先进输出队列遇到左括号直接入栈遇到右括号则弹出到左括号为止最后把运算符栈清空。这样中缀表达式35*2就会变成后缀表达式3 5 2 * 。后缀表达式的求值规则再简单不过从左到右扫描碰到数字压栈碰到运算符就弹出两个数字计算再把结果压回去。扫描结束时栈里唯一那个数字就是最终结果。我在LabVIEW里实现这个过程的方式是先用字符串数组保存Token序列再用两个长度可变的数组模拟栈和队列。程序框图里就是几个Case结构循环处理循环次数等于Token数量。对于学过一点数据结构的人来说这个模块并不难我前面做的时候反复确认了两处容易写错的地方优先级判断必须包含运算符之间的两两比较表而不能只看当前字符。乘除对加减优先幂运算对乘除优先括号优先级最高。后缀求值时弹出操作数的顺序不能反。比如5 2 -先弹出2作为右操作数再弹出5作为左操作数算出来是3。如果先弹出5作为左操作数就算出负数了。4.3 扩展运算的实现我不仅仅满足于四则运算语音口算里还有一个高频词是“平方”所以我给Token解析器加了两个特殊标记^表示幂运算sqrt表示平方根。关键点是这些运算符的位置处理。通常“五的平方”会被规范化成5^2那么中缀转后缀时我需要把^变成运算符参与优先级比较^的优先级比乘除更高而且是右结合。平方根则需要设计成类似函数调用sqrt(9)在Token化时被当作“函数调用token”求值时调用LabVIEW里的平方根函数而不是普通运算符。4.4 精度、除零与错误提示数值计算绕不开两个问题浮点数精度和非法输入。LabVIEW的双精度浮点数在计算3*0.1时会出现类似0.30000000000000004的尾差如果直接上屏看起来很难受。我显示结果前统一调用“格式化数值”控件保留8位有效数字顺手解决了尾差问题。除零问题要单独拦截当前缀表达式中出现5 0 /时求值器不能去执行真正的除法否则会产生无穷大。我在运算符执行环节加了一个条件判断如果除数为0直接返回一个错误标记停止计算提示“不能除以零”。解析器同理如果Token序列不合法比如9988-9999也要在求值前检查栈状态结束时操作数栈必须只有一个元素否则说明表达式非法返回“计算公式不符合规则”。5. 状态机与交互设计计算器也要有点“产品感”这一步其实很关键一个好的语音计算器交互逻辑比识别引擎更影响使用体验。如果每次按下按钮都需要盯着屏幕确认“它到底听没听”用户的信任感会直线下降。我用一个简单的状态机来管理整个程序流程。5.1 五状态轮转程序在五个状态之间切换空闲、录音中、识别中、解析中、结果完成。空闲状态下界面上的按钮提示“按住说话”用户按下按钮的瞬间程序从空闲进入录音状态同时Python端开始采集麦克风录音结束进入识别中界面显示“正在听”识别结果返回后进入解析中如果解析成功就跳到结果完成把算式、结果显示出来并触发TTS播报如果解析失败则回到空闲提示重说。状态机在LabVIEW里用枚举类型加While循环实现循环每100毫秒轮询一次当前状态状态转移由事件结构里的按钮事件触发。这个模型的好处是录音时如果用户再次按下按钮可以直接取消本次识别避免“我刚才其实不想让它算”这种误触。5.2 按住说话而不是点击说话计算器识别的是短句不是连续对话。连续识别模式下麦克风常开非常消耗CPU而且周围聊天声音很容易被误识别成算式。我最终选了“按住说话”按下按钮开始录音松开按钮停止录音并自动识别。这个交互在LabVIEW里实现的时候要注意按钮本身是机械动作类型不能直接用Click事件因为Click事件在鼠标抬起时才触发。正确做法是取布尔按钮的机械动作在Mouse Down事件里置录音标志位在Mouse Up事件里清标志位。程序框图的While循环里不断检查这个标志位一旦为真就调用Python识别函数。5.3 TTS语音播报结果识别和计算都完成了如果把算式用语音读出来这个工具才算真的完整。这里我直接用Windows系统语音引擎通过LabVIEW的ActiveX节点调用SpVoice对象。调用的核心代码很短创建SpVoice对象设置Voice属性为Microsoft Huihui中文语音调用Speak方法把“三加五乘二等于13”整个字符串传进去。有一点要提醒LabVIEW的ActiveX节点与Python节点一样有中文编码问题。如果字符串来自界面控件的Caption通常没问题但如果是代码里拼出来的中文字符串建议使用Unicode码点数组组装后再传给SpVoice。TTS播报还有一个附加好处出错时播报错误原因。我给解析失败和识别失败分别录了固定话术比如“没有听到算式”、“计算格式不正确”用户不需要看屏幕就知道发生了什么。5.4 前面板布局与视觉反馈界面我用的是极简布局思路上方一个大号结果显示框字号设在48磅以上让两米外的人都能看清下方一个按钮按钮标签就是“按住说话”边上给两个状态灯——绿色表示空闲黄色表示正在听红色表示识别失败。为了记录多次计算历史我放了一个表格控件把每次计算的表达式、结果、时间戳存进去。旁边一个小波形图显示最近20次计算结果的走向方便连续算一组参数时能直观看到趋势。虽然计算器最重要的功能不出彩但这些小细节让它在演示时很有说服力。6. 部署与调试踩过的坑和最后剩下的优化空间项目从能跑到能给别人用中间隔着一大堆调试细节。我按踩坑顺序把最有价值的几个问题整理出来。6.1 Python环境跟随程序走LabVIEW项目打包成EXE后Python节点仍然会去找开发机上配置的那个Python解释器路径。别人拿到你的EXE如果没有安装对应Python环境和依赖库程序启动时直接报错。解决办法有两条我用的组合拳是打包时写一个前置检查VI启动时探测python.exe是否存在不存在则弹窗提示安装Python并给出依赖清单。把Vosk模型放进项目目录不要写绝对路径模型路径动态读取当前VI所在目录这样整个项目文件夹拷到任意电脑都能跑。6.2 PyAudio安装失败与替代方案在Windows上用pip install pyaudio经常会卡在编译阶段尤其是缺少Microsoft Visual C Build Tools的机器。我后来直接用pip install pipwin和pipwin install pyaudio解决的或者去PyAudio官网下载预编译的whl文件安装。还有个小概率问题部分笔记本自带的麦克风阵列是多通道设备PyAudio打开输入流时会报错“Invalid argument”此时需要在设备索引里手动指定常规麦克风设备。如果不想折腾PyAudio还有个次选方案用LabVIEW自带的“采集声音”函数把音频录制为WAV文件再用Python读取文件进行识别。这个方案虽然多了一步文件I/O但绕开了Python侧录音的兼容性问题识别效果一样。6.3 模型加载与识别延迟优化前面提过模型常驻内存解决了首次加载慢的问题。但还有一个隐藏延迟每次调用Python函数时LabVIEW会在Python解释器里执行一次函数调用这个过程本身有几十毫秒开销。如果识别结果要等很久可以把Python脚本改成内部维护一个轮询队列这样延迟可以压到300毫秒以内。对于当前这个计算器场景2秒内的响应其实是够用的没有过度优化必要。6.4 现场嘈杂环境的处理思路最后说一个真实问题如果计算器放在测试车间里环境噪声很大Vosk的识别准确率会明显下降。我目前用到的缓解手段有三种模型升级到大体积中文模型牺牲一点加载时间来换准确率。录音时加入信噪比判断只有麦克风采集到的有效音量超过阈值才开始喂给识别引擎录音结束后低于阈值的片段直接丢弃。规范化层保留数字纠错功能比如识别结果里突然出现“三加百五”能通过常见读法推断出“百五”是“一百零五”的口误这种纠错能力是需要不断积累口语样本才能做扎实的。这些优化方向如果全部做完就是一个比较完整的“语音交互计算器”项目了。我自己的下一步计划是把这一整套语音输入能力复用到更复杂的场景比如语音控制仪器的量程切换、语音输入实验记录。坦白说计算器本身只是一个起点真正有价值的是这条从语音识别到语义解析再到LabVIEW交互的链路它能走的远比“算个数”要远。
