企业官网建设流程全解析

做机器人的朋友应该都遇到过这种尴尬：机器人见人就躲，因为它既听不懂你在说什么，也根本没"长耳朵"。上一篇我们把大疆EP机器人的底盘控制跑通了，用键盘和程序指令能让它前前后后走位，但离"语音控制"还隔着一大截。这一篇就补上最关键的一环——给机器人装上"耳朵"和"嘴"：用Python从麦克风录音，把录音文件交给百度AI语音识别接口转成文字，再把原始录音回放出来，为后续"听到指令去执行"打地基。这篇文章适合正在做机器人语音交互、或者单纯想学Python录音和调用语音识别API的朋友，不需要你现在手里就有一台机器人，跟着代码在普通电脑上也能跑通。

这一步在整个语音控制项目里，属于"内容最不花哨但最容易翻车"的环节。很多人兴致勃勃装好库，一运行，要么录音文件是空的，要么百度AI接口返回一串看不懂的错误码。我在调这个模块的时候也踩了三四个坑，所以这篇干脆把录音参数、API调用、播放验证、排错思路全部写成一篇可以直接照抄的笔记。不信你看完照着做，十分钟内应该能听到自己的声音从识别结果里"走出来"。

1. 整体设计思路：为什么这条链路是这样搭的

1.1 语音控制机器人的完整链路拆解

在动手敲代码之前，我强烈建议先把整条语音控制的链路画在脑子里。从你对着机器人开口说话，到机器人真的做出动作，至少要经历六个环节：

1. 拾音：麦克风采集声波，转成电信号。
2. 数字化：声卡按照固定采样率把模拟信号采样成数字音频数据（PCM）。
3. 语音识别：把数字音频交给识别引擎，引擎返回对应的文字。
4. 语义理解：从文字里提取出机器人可以执行的指令，比如"向前走"。
5. 控制执行：把指令翻译成机器人底盘电机的速度参数。
6. 结果反馈：机器人用语音或者动作告诉你它执行了什么。

这一篇文章的实际作用是打通第2、3、6步的底部能力：录出合格的数字音频、把音频送到云端识别、把音频回放出来。第4和第5步（语义理解与机器人底盘控制）留给后面文章，但第2和第3步如果没做好，后面一切等于零。很多新手容易犯的毛病是一上来就想跳到最后一步——让机器人动起来，结果录音是坏的、识别是断的，最后把锅甩给硬件。真正稳扎稳打的顺序，永远是把每一层的地基打实了再往上垒。

1.2 云端识别与本地识别，我为什么选云端

在做语音识别选型时，市面上有两条路：本地识别库（比如离线版Whisper、Vosk、PaddleSpeech）和云端API。我一开始试图在PC上跑一个轻量本地识别模型，确实能识别一些固定指令，代价是模型体积动辄几百兆，占用明显，而且遇到稍微口语化的说法，识别率就往下掉。对大疆EP机器人这样的场景来说，它的主控模块资源有限，如果把几百兆的模型塞进去跑，机器人的底盘控制都会被拖慢。

所以最终选了云端API。把一段几秒钟的音频上传到服务器，识别的结果几百毫秒就返回来了。对控制机器人这个动作来说，300毫秒以内的网络识别延迟完全不影响体验，机器人不会因为"多等了一下"而失控。云端方案还有一个隐形好处：识别模型的升级是服务商在做，你这边一行代码都不用改，识别效果还会越来越好。这就好比你自己种粮食和去超市买米，自己种确实很酷，但超市货源稳定、品种更新快，你只需要专注做好"做饭"这件事。

1.3 为什么挑百度AI短语音识别

选定云端之后，同样有多个服务商可选，我最终用百度AI开放平台的短语音识别接口，理由很实在：第一，它对中文普通话的识别优化在国内属于第一梯队，机器人控制指令通常就是短句；第二，有免费额度，个人学习和比赛测试足够用；第三，也是最打动我的一点——它的接口协议极其简单，不需要装官方SDK，直接用requests提交一个JSON请求就能拿到文字。整个过程里，token怎么申请、音频怎么编码、返回报文长什么样，全部透明可见。对想搞清楚原理的开发者来说，这种"不封装"的方式反而最好教学。很多做比赛的同学反馈，看清了这一步的完整数据流之后，换任何一家语音识别服务，都能在半天内接上。

2. 环境准备：两行命令和三个配置项

2.1 用对Python版本和依赖库

这一步的Python环境建议使用3.8以上版本，我自己的测试环境用的是3.10。整个项目只要三个核心依赖：pyaudio负责录音和播放，requests负责调用百度AI接口，wave是Python标准库，用来读写WAV文件，不需要额外安装。安装命令很简单：

pip install pyaudio requests

如果是在Linux环境，先执行apt-get install portaudio19-dev再装PyAudio，否则编译会报错。Windows用户如果直接pip装PyAudio报错，可以下载对应Python版本的wheel文件离线安装。macOS则要先用brew install portaudio。这些坑都是装库阶段最常见的，但一次配置好后面就很省心。

装完验证一下：

python -c "import pyaudio, requests; print('ok')"

能输出ok就说明环境没问题。如果输出ModuleNotFoundError，不要慌，顺着刚才说的平台安装方式重新来一遍，十有八九能解决。我在帮同学调试环境时发现，八成问题出在"装了一半没装干净"，多换几个安装渠道基本都能搞定。

2.2 在百度AI开放平台申请应用，拿到两个Key

接下来要去百度AI开放平台创建一个应用。登录后找到"语音技术"模块，选择创建应用，给应用随便起一个名字，服务接口勾选"短语音识别"，完成之后你会拿到两个重要字符串：API Key和Secret Key。它们一个像用户名，一个像密码，后续换取token都要用。

这里必须提醒一句：这两个Key千万不要提交到GitHub等公开仓库里。我见过很多同学把Key写在代码里直接传上去，没过多久就被别人盗刷额度。建议通过环境变量或者单独的配置文件保存，示例代码里先用占位符代替。

申请密钥后的常见疑问是"要不要下载官方SDK"。我的答案是：不用。直接requests调用HTTP接口，反而更容易看到数据流转的细节。SDK只是帮你把HTTP请求封装好了，自己写一次请求，后面任何平台都能想明白。特别是做机器人项目，你往往需要把识别逻辑嵌在自定义的控制流程里，越透明越容易改。

2.3 这套代码与大疆EP机器人的边界在哪里

可能有同学会问：这篇文章的标题叫"语音控制大疆EP机器人"，怎么环境准备阶段完全没有提到机器人？这就是典型的项目分步推进思维。语音识别模块先在普通电脑上调试通过，确认录音和识别都稳了，再和机器人SDK去对接，能省掉大量交叉排错的时间。如果一上来就把机器人、麦克风、网络、API全搅在一起，出了问题你根本说不清是麦克风坏了还是机器人SDK冲突还是API密匙填错。

大疆EP机器人提供的是配套Python SDK，开发者可以通过SDK控制底盘、云台、机械臂等部件。等到下一步，我们在识别结果里做一个指令映射，把"向前走"这样的文字映射到SDK的底盘运动接口上，这一步就会顺利很多。所以现在不用急着碰机器人硬件，先把PC端这条语音链路跑通再说。这个阶段你要做的，就是用最普通的笔记本电脑，把"声音进、文字出、声音出"的闭环建立起来。

3. 录音模块：给机器人装上"耳朵"

3.1 PyAudio录音参数背后，全是百度AI的硬指标

录音表面上是"打开麦克风收声"，实际上有一组参数必须在写代码前定好，因为这些参数直接决定了后面能不能通过百度AI的识别接口。我用到的参数如下：

为什么16kHz而不是44.1kHz？虽然CD音质是44.1kHz，但语音识别引擎只需要覆盖人声范围就够了，16kHz在保证识别精度的同时能减小一半上传数据量，识别更快。为什么是单声道？百度AI接口的声道参数只支持1和2，用单声道数据量小，而且机器人周边收音场景里立体声没有实际意义。16位的位深则是接口识别效果最稳定的配置。这些参数你看官方文档也是一样的说法，本质是识别引擎训练时就用的这套规格，你按它的规格喂数据，识别率自然最高，报错也最少。

3.2 录音并保存WAV的完整代码

看代码。这段代码会录制5秒音频，保存成record.wav：

import pyaudio import wave CHUNK = 1024 FORMAT = pyaudio.paInt16 CHANNELS = 1 RATE = 16000 RECORD_SECONDS = 5 WAVE_OUTPUT_FILENAME = "record.wav" p = pyaudio.PyAudio() stream = p.open(format=FORMAT, channels=CHANNELS, rate=RATE, input=True, frames_per_buffer=CHUNK) print("开始录音，请说话...") frames = [] for i in range(0, int(RATE / CHUNK * RECORD_SECONDS)): data = stream.read(CHUNK, exception_on_overflow=False) frames.append(data) print("录音结束") stream.stop_stream() stream.close() p.terminate() wf = wave.open(WAVE_OUTPUT_FILENAME, 'wb') wf.setnchannels(CHANNELS) wf.setsampwidth(p.get_sample_size(FORMAT)) wf.setframerate(RATE) wf.writeframes(b''.join(frames)) wf.close()

运行之后，你会看到一个名为record.wav的文件生成。先别急着做识别，双击听一下录音，确认里面确实有你的声音，再做下一步。这一步听起来多此一举，其实是整个流程里性价比最高的验证方式：只要录音文件本身是好的，后面所有识别报错都只需要从代码层排查。

3.3 录音模块的三个关键细节

第一，stream.read里我加了exception_on_overflow=False。在Windows这类非实时操作系统上，如果缓冲区的数据来不及处理，PyAudio默认会抛IOError异常，导致录音中断。加上这个参数后，超出部分会被丢弃而不是中断程序，对一般语音识别场景没有影响，但程序稳定性提升明显。

第二，录音时长不要贪长。百度AI短语音识别接口的单次请求限60秒，机器人控制指令往往不超过5秒。我习惯把默认录音时间设成4秒，在代码里留一个seconds参数，后续可以根据实际指令长短动态调整。控制类语音项目的最佳实践是"够用就短"，录音越短，从开始说话到机器人响应的时间越短。

第三，录完音先看文件大小。一段5秒、16kHz、单声道、16bit的WAV文件，大小大约是16000乘以2字节，乘5秒等于160KB左右。如果你录出来的文件只有几KB或者几十KB，多半是声音太小或者麦克风没开，这时候直接做识别的结果就是"没有语音"。养成检查文件大小的习惯，能省下不少排查时间。我在教学时经常说：先看文件大小，再看识别报错，这样能把问题定位快一倍。

4. 语音识别：把音频交给百度AI，拿回文字

4.1 先拿"门票"：用API Key换取access_token

调用百度AI识别接口前，必须先用API Key和Secret Key换取access_token。你可以把令牌理解成大门口的门票：API Key和Secret Key是注册信息，不能每次都带进门，而access_token是有效期30天的临时通行证，接口认它不认你。每次请求都去申请token会浪费一两百毫秒，所以我更建议在程序启动时获取一次并复用。

import requests API_KEY = "你的API Key" SECRET_KEY = "你的Secret Key" def get_access_token(): url = "https://aip.baidubce.com/oauth/2.0/token" params = { "grant_type": "client_credentials", "client_id": API_KEY, "client_secret": SECRET_KEY } response = requests.post(url, params=params) return response.json().get("access_token")

运行后如果返回一串看起来像乱码的字符串，比如"24.xxxxxxxxxxx.xxxxxxxx"，那基本就是token申请成功了。如果返回错误信息，优先检查API Key和Secret Key有没有复制错，或者有没有多余的空格。这里还要留意一点：token获取成功后妥善保存在内存里，不要反复申请。百度AI对这个接口有频率限制，虽然限额不小，但降低请求次数总归是稳妥的做法。

4.2 音频怎么"寄"给接口：Base64编码与JSON组织

录音文件是二进制数据，而HTTP接口的JSON请求体是纯文本协议，二者没法直接放到一起。解决方式是把二进制音频转成Base64文本，再放进JSON字符串里一起提交。这个过程可以理解成：你想在信纸上描述一张照片，得先把照片扫描成文字，这封信才能塞进信封寄出去。接口收到后再把文字还原成音频去识别。

组装请求时，关键字段包括format（音频格式，这里用wav）、rate（采样率16000）、channel（声道数1）、token（前面拿到的access_token）、cuid（自定义设备标识，填什么都可以，但要保持稳定）、len（音频字节长度，注意是原始字节长度，不是Base64后的长度）、speech（Base64编码后的音频内容）。这里经常有人把len写成Base64后的长度，接口就会报"音频格式错误"，我一开始也翻过这个车。len的实际作用就是告知服务端音频原始体积，方便它做体积校验，数值一旦和音频真实大小对不上，服务端会直接判定请求不合法。

完整的识别函数如下：

import requests import base64 def recognize(audio_file, token): with open(audio_file, "rb") as f: audio_data = f.read() speech_data = base64.b64encode(audio_data).decode("utf-8") payload = { "format": "wav", "rate": 16000, "channel": 1, "cuid": "ep_robot_speech", "token": token, "len": len(audio_data), "speech": speech_data } url = "https://vop.baidu.com/server_api" headers = {"Content-Type": "application/json"} response = requests.post(url, json=payload, headers=headers) return response.json()

上传时有一个体积小的优势：16kHz单声道录音通常只在几十KB到一两百KB之间，Base64之后大约扩展为原来的4/3，依然很小。即使是在校园网或者比赛场地的公共Wi-Fi环境下，上传也很快。这也反过来说明为什么前面录音参数一定要用16kHz单声道，如果录的是44.1kHz立体声，文件体积直接翻两三倍，浪费带宽不说，识别速度还会被拖累。

4.3 识别结果怎么读：返回JSON解析与容错

识别接口返回的是一个JSON对象，格式大概是这样的：

{ "err_no": 0, "err_msg": "success", "corpus_no": "7200008726430731603", "sn": "281723520915720260252", "result": ["向前走"] }

err_no为0就是成功，result列表里的第一个元素就是识别出来的完整文字。如果err_no不是0，说明出了问题，常见错误码我列一张表方便对照：

所以在代码里最好写一个解析函数，把最终文字提取出来，同时把错误信息也显示出来，方便调试。我在完整整合时会给出这个函数，建议你也这样做：永远不要假设接口第一次调用就成功。错误码不是给你制造麻烦的，它是帮你定位问题的最短路径，把常见的几个背下来，调试时能省一半时间。

5. 播放模块：让机器人开口"复述"

5.1 用PyAudio播放WAV文件的实现

录音能录，接下来要能播。播放本质上和录音是互逆过程：录音是麦克风采集数据存进文件，播放是文件数据送到扬声器。PyAudio把这两个过程都封装得很干净，播放代码比录音还简洁：

import pyaudio import wave def play_wav(filename): wf = wave.open(filename, 'rb') p = pyaudio.PyAudio() stream = p.open(format=p.get_format_from_width(wf.getsampwidth()), channels=wf.getnchannels(), rate=wf.getframerate(), output=True) data = wf.readframes(1024) while data: stream.write(data) data = wf.readframes(1024) stream.stop_stream() stream.close() p.terminate()

把前面录好的record.wav传进去，如果听到你自己的声音原样回来，说明录音和播放链路全线畅通。这步别看简单，它是后面整个对话循环能跑起来的出口，机器人最终"开口回答"全靠它。有一类问题会在这里暴露出来：如果录音时麦克风音量太小，播放出来的声音听起来像蚊子叫，这时需要回到录音端调节输入音量，而不是在播放端调高音量，因为播放端调大只是放大底噪，识别端拿到的是原始音频，音量问题仍然会影响识别率。

5.2 播放模块在整个对话闭环里的位置

在"语音控制并对话"这个项目里，播放模块承担两个角色。其一是调试期确认录音质量的"照妖镜"：录完直接播出来，环境噪音大不大、说话音量够不够，一听便知。其二是正式对话时的"回声"：机器人执行完指令后，需要通过扬声器把结果告诉你，比如"好的，我在向前走"。虽然这篇文章里播放的是原始录音，但到后续文章里，把播放对象换成语音合成接口生成的音频，逻辑是完全相同的，播放函数一行都不用改。这一点非常关键——播放模块只管"给音频流放出来"，至于音频是录音还是合成语音，它不关心，所以前期只要把这条路打通，后面接入语音合成就是白送的。

6. 完整闭环：录音、识别、播放一次跑通

6.1 整合成VoiceHandler类

到了这一步，我把三个模块整合成一个类，方便后面在机器人项目里直接复用。把密钥初始化、token获取、录音、识别、播放都收进同一个对象里，主程序只需要调用run()，几秒钟内完成"录音-识别-回放"的闭环：

import pyaudio import wave import requests import base64 class VoiceHandler: def __init__(self, api_key, secret_key): self.api_key = api_key self.secret_key = secret_key self.token = None self.rate = 16000 self.chunk = 1024 self.channels = 1 def get_token(self): url = "https://aip.baidubce.com/oauth/2.0/token" params = { "grant_type": "client_credentials", "client_id": self.api_key, "client_secret": self.secret_key } resp = requests.post(url, params=params).json() self.token = resp.get("access_token") return self.token def record(self, seconds=4, filename="record.wav"): p = pyaudio.PyAudio() stream = p.open(format=pyaudio.paInt16, channels=self.channels, rate=self.rate, input=True, frames_per_buffer=self.chunk) frames = [] for _ in range(int(self.rate / self.chunk * seconds)): data = stream.read(self.chunk, exception_on_overflow=False) frames.append(data) stream.stop_stream() stream.close() p.terminate() wf = wave.open(filename, 'wb') wf.setnchannels(self.channels) wf.setsampwidth(p.get_sample_size(pyaudio.paInt16)) wf.setframerate(self.rate) wf.writeframes(b''.join(frames)) wf.close() def recognize(self, filename="record.wav"): if not self.token: self.get_token() with open(filename, "rb") as f: audio_data = f.read() payload = { "format": "wav", "rate": self.rate, "channel": self.channels, "cuid": "ep_robot_speech", "token": self.token, "len": len(audio_data), "speech": base64.b64encode(audio_data).decode() } url = "https://vop.baidu.com/server_api" resp = requests.post(url, json=payload, headers={"Content-Type": "application/json"}).json() if resp.get("err_no") == 0: return resp["result"][0] return f"识别失败：{resp.get('err_no')} {resp.get('err_msg')}" def play(self, filename="record.wav"): wf = wave.open(filename, 'rb') p = pyaudio.PyAudio() stream = p.open(format=p.get_format_from_width(wf.getsampwidth()), channels=wf.getnchannels(), rate=wf.getframerate(), output=True) data = wf.readframes(self.chunk) while data: stream.write(data) data = wf.readframes(self.chunk) stream.stop_stream() stream.close() p.terminate() def run(self): self.record() text = self.recognize() print("识别结果：", text) self.play()

主程序调用就三行：

voice = VoiceHandler(API_KEY, SECRET_KEY) voice.run()

6.2 现场调试流程实录

我实际跑这个类的过程大致是这样的。运行程序，它提示开始录音，我对着麦克风说"向前走"，录音结束，程序先去换token，再上传音频，大概半秒之后终端打印出识别结果："向前走"。与此同时扬声器里播放出我刚才那句录音。整个流程从开口到看到文字，体感在1到2秒之间，其中录音占4秒是因为我设的固定时长，实际识别本身只用了不到1秒。

这里有一个值得优化的点：固定录4秒有点拖沓。如果你的控制指令通常只有两三秒，可以把录音时长动态缩短，或者加一个"静音检测"：检测到说话结束后马上停止录音。我测试时是先把固定时长方案跑通，再逐步优化时间。对一个项目来说，先追求链路通，再追求体验好，顺序不能反。很多同学一上来就想做最完美的语音助手，结果一个环节都跑不通，最后反而失去信心。先把最简单的闭环用最朴素的实现方式跑起来，这是做项目最有效的路径。

7. 避坑记录：实测中踩过的六个坑

7.1 录音文件是空白的，或者全是底噪

这个问题最常见。先检查系统麦克风是否开启了访问权限，尤其是macOS和Windows 10以上系统，首次使用麦克风会弹权限申请框，没点允许的话，PyAudio仍然能打开录音流，但采到的全是静音。其次检查PyAudio默认输入设备是不是你要用的那个麦克风。我遇到过笔记本同时有内置麦克风和USB声卡，PyAudio默认选了那个没有插任何设备的USB声卡，录出来自然是空的。可以用PyAudio遍历设备列表，打印出输入设备编号，然后指定input_device_index使用正确设备。

排查录音问题的顺序建议是：先看录音文件大小，如果大小正常但播放没声音，就用系统录音软件比对测试；如果系统软件能录出声音而PyAudio不行，再去查设备索引和权限。按照这个顺序能少走很多弯路。

7.2 百度AI返回3300、3301、3302的排查顺序

这三个错误码几乎是第一次调百度AI的人必踩的。我看到3300先怀疑文件打不开，但其实更多时候是文件内容不符合接口要求。排查顺序建议这样：先用系统自带录音软件录一段WAV，手动上传到百度AI在线调试工具，如果能识别，说明音频本身没问题，问题出在代码组装环节；如果在线也识别不了，说明录音参数不对。接着确认wav文件的采样率、位深、声道数，最好在代码里加一行打印wave模块读出来的实际参数，和payload里填的rate、channel逐一比对。3301大概率是参数没对齐，3302则是录音时间超过了60秒，这个只要把录音上限控制住就行。

我还遇到过一种情况：明明录音文件是好的，但错误码始终是3300。最后发现是代码里把文件路径拼错了，程序读了一个不存在的文件，读出来的audio_data长度是0，Base64编码后是一个空字符串。所以看到3300先打印len(audio_data)，如果是0，问题根本不在音频格式，而在文件读取。

7.3 播放没声音，但录音文件确实有内容

如果录音文件能在播放器里正常出声，但用PyAudio播就没声音，先看输出设备。同样需要确认PyAudio选中的输出设备是不是你正在听的扬声器。很多开发板机器人的HDMI输出和3.5mm耳机口共用音频栈，如果插了耳机但系统还在走HDMI音频，就会无声。在代码里调试时，先直接把电脑当成播放器测试一次，把环境变量最小化。另外还有一个容易忽略的点：如果程序从头到尾没有调用p.terminate()，播放结束后音频资源可能一直被占用，下一次播放时就静默失败。确保每次play都完整执行到terminate，这个问题就能避免。

7.4 Token过期和网络请求异常

access_token有效期是30天，但如果程序长期不重启，到期后会突然开始报错。我在一次演示前就遇到过这个问题，当时排查了很久才发现是token过期。技巧是写一个包装函数，每次请求前检查token是否存在，如果请求返回token相关的错误，重新获取一次token再重试。网络请求异常则主要发生在课堂或比赛现场这种公共Wi-Fi环境，requests.post超时会直接抛异常，建议设置timeout参数（比如5秒），并配合简单的重试机制，别让一次瞬时断网把整个演示搞挂。重试还有一个隐含好处：如果因为网络抖动导致第一次请求失败，第二次请求能大概率成功，这在演示场景里能救命。

7.5 识别结果不准或者不完整

如果你说"向前走"，结果识别成"向前走一步"甚至"相前走"，先别急着换引擎。排除法走一遍：第一，录音距离保持在20到50厘米，离太远环境噪音一大识别率直线下降；第二，语速放慢，指令越短越准，控制类指令尽量不超过五个字；第三，检查网络波动，识别质量受网络影响很明显，本地网络不稳时返回会异常。最后一个技巧是给指令加"唤醒词"式的固定前缀，比如先说"小飞"，再说指令，这样既能把上下文切分清楚，又能减少误识别。这个做法和手机语音助手的"你好某某"是同一个思路，本质上是在音频层面制造一个明显的停顿分隔点，让识别引擎更容易断句。

7.6 关于延迟的实测心得

有人担心云端识别慢，但实际上瓶颈往往不在识别，而在录音等待时间。固定录4秒，就意味着至少4秒后才可能开始识别。如果你想追求敏捷响应，两个改造方向：一是用PCM裸数据替代WAV，省去文件头，上传体积更小；二是引入端点检测，检测到有声音才正式开始采集，检测到停顿就立刻停止并上传。我在做一个比赛项目时就是这样优化的，把"说完话到机器人动作"的延迟从6秒压到了1.5秒左右。这个优化做完，整个语音控制的体验才真正配得上"控制"两个字。很多选手在比赛现场表现不好，不是算法不行，而是整套流程里录音等待时间太长，导致指令响应慢，给人感觉机器人很"笨"。

8. 下一步：让识别结果驱动机器人真正动起来

8.1 从文字到机器人指令的映射

识别拿到"向前走"这种文字之后，下一步就是在程序里做指令映射。思路不复杂：维护一个简单的条件判断或者字典，把语音文字对应到机器人SDK的底盘接口，比如"向前走"映射到底盘前进、"停下来"映射到底盘停止。这里贴一个示意代码，具体接口参数以你手上设备的SDK文档为准：

if text == "向前走": robot.chassis.move(x=0.5, y=0, z=0).wait_for_completed() elif text == "停下来": robot.chassis.stop()

注意，这样的映射只适合固定指令集。想实现真正的"对话"，需要引入更聪明的语义理解模块，但不管后面接什么，前面语音识别的文字结果都是所有决策的地基。实际接入时你会遇到一个新挑战：麦克风收音环境从安静的室内变成嘈杂的比赛现场，识别准确率会下降。所以到那一步，除了算法层面的优化，多测试不同的麦克风位置和音量增益，往往比换更大的模型更有效。

8.2 从"听懂"到"对话"的技术路线

把识别文字变成机器人行为，最简单第一版可以用关键词匹配，比如包含"向前"就前进，包含"停止"就停下。缺点很明显：换种说法就不认识。更稳的做法是接一个对话式大模型或者意图识别接口，把用户说的话交给大模型处理，模型返回结构化指令，再由程序解析执行。这条路我后面会专门写一篇展开。到那一步，你还会用到语音合成技术，让机器人不只听懂，还能开口回应，形成完整的"你问它答、你指令它执行"的交互闭环。到那一步，整个项目的完整形态就出来了：你开口，机器人听，机器人做，机器人答，一圈回来，像和一个有手有脚的小助手在交流。

我在实际做完这一步后最大的体会是：语音识别本身不神秘，关键在把音频参数和接口参数对齐，以及把每个环节的错误信息都暴露出来。你在跑demo时千万不要跳过录音回放这个验证动作，多听一次自己的录音，能省下后面数小时的抓狂时间。等PC端这条链路彻底稳了，再接机器人SDK，你会发现"语音控制机器人"离你已经非常近了。下一篇文章，我会把这段识别结果真正接到大疆EP机器人的底盘控制上，让那句"向前走"变成真实的移动距离。