1. 项目概述为什么我们需要自定义唤醒词在智能语音交互领域“Hey Siri”或“小爱同学”这类通用唤醒词已经深入人心。但作为一名开发者或产品经理你是否想过为什么你的智能台灯、车载设备或者个人助手项目不能有一个独一无二的唤醒词比如“开启星辰”、“启动引擎”或者干脆是你家宠物的名字这不仅仅是追求个性化背后更有着强烈的实际需求。通用唤醒词在公共或家庭多设备场景下极易引发误唤醒。想象一下客厅里的电视广告喊一声“小爱同学”所有房间的小爱音箱都齐声应答的尴尬场面。自定义唤醒词则能实现设备级的精准控制让指令只在你期望的设备上生效。更深层次地对于一些垂直行业应用——例如工业巡检中的“开始记录”、医疗设备中的“紧急呼叫”——一个特定、无歧义的唤醒词是保障操作安全与效率的关键。它不再是一个简单的语音开关而是成为了人机交互意图的精准入口。然而从萌生“自定义”的想法到真正让设备可靠地响应这个词中间横亘着一条从算法训练到工程部署的完整链路。这涉及到语音信号处理、深度学习模型训练、模型优化与跨平台部署等一系列技术环节。市面上虽有现成的语音唤醒SDK但它们往往是黑盒不支持自定义训练或者定制费用高昂。因此掌握从零构建自定义语音唤醒能力的完整实践对于希望将语音交互深度集成到自身产品中的团队和个人而言是一项极具价值的核心技能。本文将围绕“自定义语音唤醒词”这一目标拆解从数据准备、模型训练以OpenWakeWord框架为例、模型转换与优化ONNX格式到最终在边缘设备或服务端部署的完整流程。我会结合近期的技术热点如ONNX Runtime的高性能推理、Docker化部署以保障环境一致性以及针对资源受限环境的模型轻量化技巧为你呈现一条清晰、可复现的实践路径。无论你是想为个人项目增添趣味还是为产品开发寻找可靠的语音唤醒方案这篇内容都将提供直接的参考。2. 核心思路与方案选型为何是OpenWakeWord ONNX面对自定义语音唤醒任务我们首先需要确定技术路线。一个完整的语音唤醒系统通常包含以下几个核心模块前端音频处理VAD、降噪、特征提取、唤醒词检测模型、以及后处理逻辑。其中模型部分是核心。2.1 模型框架的选择OpenWakeWord的独特优势在开源社区可用于唤醒词训练的框架有不少如Snowboy已基本停止维护、Porcupine功能强大但部分高级功能需付费、以及Mycroft Precise等。我选择OpenWakeWord作为本次实践的框架主要基于以下几点考量完全开源与可训练性OpenWakeWord 的设计初衷就是提供一个完全开源、从数据准备到模型训练全流程透明的工具包。它基于 PyTorch 构建你可以清晰地看到模型结构通常是基于MobilenetV2或类似轻量级架构改造的时序分类模型并完全掌控训练过程。这与一些仅提供二进制模型或云端训练服务的方案有本质区别。技术栈友好它使用 Python 作为主要语言与当前深度学习生态无缝集成。其数据预处理、特征提取如MFCC梅尔频率倒谱系数和训练脚本都写得较为清晰便于理解和二次开发。社区活跃与可扩展性虽然相对较新但其社区在持续发展。更重要的是其模型输出是标准的分类概率这使得后续的模型转换如转ONNX和集成变得非常直接。注意选择 OpenWakeWord 意味着你需要亲自动手处理数据、调整训练参数并承担模型效果优化的责任。如果你追求“开箱即用”且对效果要求极高商业方案如科大讯飞、思必驰的唤醒引擎仍是更稳妥的选择。但我们的目标是掌握全链路能力因此开源可训的方案是更合适的学习和起点。2.2 部署格式的锚定ONNX 的战略意义模型训练好后我们面临部署环境的多样性可能是 x86 的服务器、ARM 架构的树莓派、嵌入式开发板如 RK3568甚至是手机 App。为每一种环境都维护一套 PyTorch 运行时和依赖库是灾难性的。这就是ONNX登场的原因。ONNX是一个开放的模型表示标准它定义了一个通用的计算图格式。将 PyTorch 模型转换为 ONNX 格式后你可以使用ONNX Runtime这个高性能推理引擎在任何支持 ONNX 的平台上运行模型。ORT 针对 CPU、GPU、ARM 等不同硬件提供了高度优化的执行内核。选择 ONNX 部署的核心理由跨平台一致性一次转换多处部署。无论是在Docker容器中还是在本地Windows/Linux/macOS系统或是嵌入式设备上只要 ONNX Runtime 支持模型就能以相同的方式运行。性能优化ONNX Runtime 内置了大量图优化如算子融合、常量折叠能显著提升推理速度降低延迟这对于实时性要求极高的语音唤醒场景至关重要。生态集成ONNX 模型可以轻松接入各种部署框架。例如你可以将 ONNX 模型封装成 gRPC 或 HTTP 服务也可以集成到C、C#、Java等主流语言开发的应用中灵活性极高。与热点技术协同观察提供的热词pt转onnx、onnx runtime、docker部署等都是高频词汇。这说明 ONNX 已是当前模型工程化部署的事实标准。掌握它就等于掌握了连接 AI 模型与生产环境的桥梁。因此我们的技术链路非常明确使用 OpenWakeWord 框架进行自定义唤醒词模型的训练然后将训练好的 PyTorch (.pt) 模型转换为 ONNX (.onnx) 格式最后利用 ONNX Runtime 在各种目标环境中进行高效部署。3. 实战第一步数据准备与模型训练理论清晰后我们进入实战环节。模型训练的质量七分靠数据三分靠调参。对于唤醒词任务数据准备尤为关键。3.1 唤醒词数据集的构建与处理一个典型的唤醒词数据集需要两类数据正样本包含目标唤醒词的语音片段。例如如果你要训练“开启星辰”就需要收集成百上千条不同人、不同口音、不同语速、不同环境噪声下说“开启星辰”的录音。负样本不包含目标唤醒词的语音片段。这包括其他无关语音、静音、环境噪声、以及可能容易混淆的类似发音词组。负样本的质量和数量直接决定了模型的抗干扰误唤醒能力。数据收集途径自录最直接的方式。组织多人涵盖不同性别、年龄在多种环境安静室内、街道、车内下录制。可以使用手机录音软件或专业录音笔。确保音频格式为单声道、16kHz 采样率、WAV 格式这是语音处理的常见标准。公开数据集可以利用Common Voice、LibriSpeech等大型语音语料库从中裁剪出不含唤醒词的片段作为负样本。对于正样本如果公开数据集中没有自录仍是主要方式。数据增强这是低成本扩充数据集、提升模型鲁棒性的法宝。对已有的正样本语音可以施加以下增强操作添加不同信噪比的背景噪声可从ESC-50环境音数据集中获取。改变语速时间拉伸。改变音高音高移动。模拟房间混响。随机裁剪或拼接。数据处理流程格式统一将所有音频转换为 16kHz单声道WAV 格式。可以使用ffmpeg工具批量处理。ffmpeg -i input.mp3 -ar 16000 -ac 1 output.wav静音切除使用工具如librosa或webrtcvad切除每条音频首尾的静音段让模型更关注有效语音部分。划分数据集按照典型比例如 70% 训练集15% 验证集15% 测试集划分数据。确保同一个说话人的语音不要同时出现在训练集和测试集中以防止模型只是记住了特定人的声音而非唤醒词本身。准备数据清单OpenWakeWord 通常需要一个文本文件如train.csv其中每一行包含音频文件路径和对应的标签例如正样本为1负样本为0。实操心得负样本的数量至少应是正样本的 3-5 倍甚至更多。一个常见的错误是只关注正样本的多样性而忽略了负样本的丰富性导致模型在真实场景中极易被无关语音触发。可以将一些常见的控制命令、设备名称、甚至电视节目音频作为负样本加入。3.2 使用 OpenWakeWord 进行模型训练假设我们已经准备好了符合格式要求的数据清单接下来开始训练。环境准备# 创建虚拟环境 python -m venv wakeword_env source wakeword_env/bin/activate # Linux/macOS # wakeword_env\Scripts\activate # Windows # 安装 OpenWakeWord 及相关依赖 pip install openwakeword pip install torch torchaudio # 根据你的CUDA版本安装对应的PyTorch pip install librosa scikit-learn pandas训练脚本核心步骤解析 OpenWakeWord 提供了命令行工具和 API。这里我们以编写训练脚本为例以便更灵活地控制参数。import openwakeword from openwakeword.data import get_audio_features from openwakeword.model import train_wakeword # 1. 定义模型配置 model_config { model_name: my_custom_wakeword, wakeword: 开启星辰, # 你的目标唤醒词 n_mels: 40, # MFCC特征维度常用40或80 hop_length: 160, # 帧移对应10ms16000Hz * 0.01s n_fft: 512, sample_rate: 16000, train_epochs: 50, # 训练轮数根据数据集大小调整 batch_size: 32, learning_rate: 1e-3, # 指定一个轻量级的基础架构便于后续部署 base_model: mobilenetv2 } # 2. 加载和预处理数据 # 假设你有函数 load_data() 来读取你的 train.csv, val.csv train_audio_paths, train_labels load_data(train.csv) val_audio_paths, val_labels load_data(val.csv) # 提取特征这里简化实际OpenWakeWord内部会处理 # 通常你需要将音频路径和标签传递给训练函数 # 3. 开始训练 # OpenWakeWord 的高级API可能封装了训练循环具体请查阅其最新文档 # 以下为示意流程 model, history train_wakeword( train_data(train_audio_paths, train_labels), val_data(val_audio_paths, val_labels), configmodel_config ) # 4. 保存模型 torch.save(model.state_dict(), my_custom_wakeword.pt) print(模型已保存为 my_custom_wakeword.pt)关键参数调优经验n_mels和hop_length这决定了输入模型的声学特征图的时间-频率分辨率。hop_length16010ms是实时语音处理的常用值。n_mels40在精度和计算量之间取得了较好平衡对于嵌入式设备可以尝试降低到 32 甚至 24 以加速。base_modelmobilenetv2是一个在精度和速度上权衡得很好的选择。如果你对资源极其敏感可以寻找或设计更小的网络如果追求更高精度且部署资源充足可以考虑稍大的网络。train_epochs务必监控验证集上的损失和准确率。当验证集指标不再提升甚至开始下降时过拟合就应该提前停止训练。使用EarlyStopping回调是标准做法。学习率从1e-3开始是常见的。可以配合学习率调度器如ReduceLROnPlateau在验证损失停滞时降低学习率有助于模型收敛到更优的点。训练完成后除了保存.pt文件务必在独立的测试集上评估模型性能。关键的评估指标包括唤醒率、误唤醒率每小时的误报次数。一个可接受的模型需要在唤醒率 95% 的同时将误唤醒率控制在极低的水平例如 0.5次/小时。4. 模型转换与优化PT 到 ONNX 的蜕变得到 PyTorch 模型后下一步就是将其转换为 ONNX 格式并进行必要的优化为部署做准备。4.1 PyTorch 模型导出为 ONNX转换的核心是使用 PyTorch 内置的torch.onnx.export函数。但在此之前我们需要确保有一个完整的、可追踪的模型推理流程。import torch import onnx import onnxruntime as ort from openwakeword.model import get_model # 假设有函数能加载我们训练好的模型架构 # 1. 加载训练好的模型权重 model_config {...} # 与训练时相同的配置 model get_model(model_config) model.load_state_dict(torch.load(my_custom_wakeword.pt, map_locationcpu)) model.eval() # 切换到评估模式这很重要 # 2. 创建示例输入dummy input # 模型的输入通常是经过预处理的音频特征形状为 [batch_size, channels, freq_bins, time_frames] # 我们需要根据模型实际的前向传播逻辑来确定。 # 假设我们的特征提取输出是 (40, 98)即40维MFCC98个时间帧。 batch_size 1 channels 1 # 单通道特征图 freq_bins 40 time_frames 98 # 这是一个示例值必须与模型训练时处理的帧数一致 dummy_input torch.randn(batch_size, channels, freq_bins, time_frames) # 3. 执行导出 onnx_model_path my_custom_wakeword.onnx torch.onnx.export( model, # 要导出的模型 dummy_input, # 模型输入示例 onnx_model_path, # 输出ONNX文件路径 export_paramsTrue, # 将模型参数也存储在文件内 opset_version14, # ONNX算子集版本建议11以上 do_constant_foldingTrue, # 执行常量折叠优化 input_names[input], # 输入节点名称 output_names[output], # 输出节点名称 dynamic_axes{ # 定义动态维度这对处理可变长度音频至关重要 input: {3: time_frames}, # 第3维时间帧是动态的 output: {0: batch_size} } ) print(f模型已导出至 {onnx_model_path})关键点解析model.eval()必须调用。这会禁用Dropout、BatchNorm等的训练模式确保推理行为的一致性。dummy_input的形状这是最容易出错的地方。你必须精确知道模型期望的输入特征维度。这需要查看 OpenWakeWord 特征提取代码或模型的前几层来确定。time_frames可以是动态的以适应不同长度的输入。dynamic_axes指定动态维度非常有用。它允许导出的 ONNX 模型接受可变长度的输入如不同时间长度的音频特征而无需为每种长度导出一个单独的模型极大地增加了部署的灵活性。4.2 ONNX 模型检查与简化导出后建议对 ONNX 模型进行检查和可能的优化。# 检查导出的模型是否有效 onnx_model onnx.load(onnx_model_path) onnx.checker.check_model(onnx_model) print(ONNX 模型检查通过。) # 可选使用 onnx-simplifier 简化模型 # 安装pip install onnx-simplifier try: import onnxsim model_simp, check onnxsim.simplify(onnx_model_path) assert check, 简化后的模型验证失败 onnx.save(model_simp, my_custom_wakeword_simplified.onnx) print(模型简化完成。) except ImportError: print(未安装 onnx-simplifier跳过简化步骤。)简化可以移除计算图中不必要的操作有时能小幅提升推理速度并让模型结构更清晰。4.3 使用 ONNX Runtime 验证推理一致性在部署到目标环境前先在 Python 环境下用 ONNX Runtime 跑一遍确保转换前后模型的输出是一致的。# 使用ONNX Runtime进行推理 ort_session ort.InferenceSession(my_custom_wakeword.onnx) # 或简化版 # 准备与导出时 dummy_input 相同数据的numpy数组 import numpy as np input_data np.random.randn(batch_size, channels, freq_bins, time_frames).astype(np.float32) # ONNX Runtime 推理 ort_inputs {ort_session.get_inputs()[0].name: input_data} ort_outs ort_session.run(None, ort_inputs) print(ONNX Runtime 输出:, ort_outs[0][0]) # 假设输出是概率 # PyTorch 原始推理用于对比 with torch.no_grad(): torch_input torch.from_numpy(input_data) torch_out model(torch_input) print(PyTorch 原始输出:, torch_out.numpy()[0]) # 比较两者差异通常在可接受的误差范围内如1e-5 np.testing.assert_allclose(ort_outs[0], torch_out.numpy(), rtol1e-3, atol1e-5) print(推理结果一致性验证通过)这一步是质量的保证。如果输出差异过大就需要回头检查导出过程特别是dummy_input的形状和数据类型。5. 部署策略与实践从服务器到边缘模型转换验证无误后就来到了最终的部署环节。根据应用场景部署策略可分为服务端部署和边缘端部署。5.1 服务端部署Docker 推理服务对于需要集中处理、或者与复杂业务逻辑集成的场景将唤醒模型封装成独立的微服务是常见做法。Docker化部署能完美解决环境依赖问题。1. 创建推理服务 (app.py)from flask import Flask, request, jsonify import numpy as np import onnxruntime as ort import librosa import soundfile as sf # 假设有一个特征提取工具函数 from feature_extractor import extract_features app Flask(__name__) # 全局加载模型避免每次请求重复加载 ort_session ort.InferenceSession(/model/my_custom_wakeword.onnx) # 获取输入输出名 input_name ort_session.get_inputs()[0].name app.route(/detect, methods[POST]) def detect_wakeword(): 接收音频文件进行唤醒词检测 if audio not in request.files: return jsonify({error: No audio file provided}), 400 audio_file request.files[audio] # 1. 读取音频 audio_data, sr sf.read(audio_file, dtypefloat32) if sr ! 16000: # 重采样到16kHz audio_data librosa.resample(audio_data, orig_srsr, target_sr16000) # 2. 特征提取 (需要与训练时完全一致) features extract_features(audio_data, sr16000) # features 形状应为 [1, 1, freq_bins, time_frames] if features.shape[-1] 0: # 处理可能无有效语音的情况 return jsonify({detected: False, score: 0.0}) # 3. ONNX Runtime 推理 ort_inputs {input_name: features.astype(np.float32)} ort_outs ort_session.run(None, ort_inputs) score ort_outs[0][0][1] # 假设输出是 [batch, 2]索引1是正类概率 # 4. 后处理与决策 threshold 0.8 # 唤醒阈值需根据模型在测试集上的表现调整 detected score threshold return jsonify({ detected: bool(detected), score: float(score), threshold: threshold }) if __name__ __main__: app.run(host0.0.0.0, port5000)2. 编写 Dockerfile# 使用轻量级Python镜像 FROM python:3.9-slim WORKDIR /app # 复制依赖文件并安装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制模型文件和应用代码 COPY my_custom_wakeword.onnx /model/ COPY feature_extractor.py . COPY app.py . # 暴露端口 EXPOSE 5000 # 启动服务 CMD [python, app.py]3. 构建与运行# 构建镜像 docker build -t wakeword-service . # 运行容器 docker run -p 5000:5000 --name wakeword-api wakeword-service现在你就可以通过向http://localhost:5000/detect发送 POST 请求包含音频文件来调用唤醒词检测服务了。这种部署方式易于水平扩展可以方便地集成到更大的微服务架构中。5.2 边缘设备部署ONNX Runtime 直接集成对于智能音箱、车载设备等边缘场景需要在资源受限的设备上直接运行模型。ONNX Runtime 提供了针对 ARM、x86 等平台的预构建包甚至支持使用NCNN、MNN等更轻量的推理引擎进行二次转换但 ONNX Runtime 通常是第一选择。在树莓派ARM上的部署示例安装 ONNX Runtime选择适用于 ARM 的版本。# 对于 Python可以使用 pip 安装针对 ARM 的轮子如果官方提供 # 或者从源码编译以获得最佳性能 pip install onnxruntime # 或者安装针对 ARM 优化的版本如 onnxruntime-arm编写边缘推理脚本与服务端类似但更注重实时流式处理。import pyaudio import numpy as np import onnxruntime as ort from collections import deque from feature_extractor import stream_feature_extractor # 初始化音频流 CHUNK 1600 # 100ms 的音频数据 (16000 Hz * 0.1s) FORMAT pyaudio.paInt16 CHANNELS 1 RATE 16000 p pyaudio.PyAudio() stream p.open(formatFORMAT, channelsCHANNELS, rateRATE, inputTrue, frames_per_bufferCHUNK) # 加载模型 ort_session ort.InferenceSession(my_custom_wakeword.onnx) input_name ort_session.get_inputs()[0].name # 滑动窗口用于累积一定时长的音频进行推理 audio_buffer deque(maxlen30) # 存储3秒的音频30*100ms threshold 0.8 print(开始监听...) try: while True: # 读取音频块 data stream.read(CHUNK, exception_on_overflowFalse) audio_int16 np.frombuffer(data, dtypenp.int16) audio_float32 audio_int16.astype(np.float32) / 32768.0 # 将音频块加入缓冲区 audio_buffer.append(audio_float32) # 每隔一定时间如300ms或缓冲区满时进行一次推理 if len(audio_buffer) audio_buffer.maxlen: # 拼接缓冲区内的音频 audio_window np.concatenate(list(audio_buffer)) # 提取特征 features stream_feature_extractor(audio_window) if features is not None: # 推理 ort_inputs {input_name: features.astype(np.float32)} ort_outs ort_session.run(None, ort_inputs) score ort_outs[0][0][1] if score threshold: print(f唤醒词检测到置信度: {score:.4f}) # 触发后续动作如播放提示音、启动语音识别等 # ... # 检测到后可以清空缓冲区以避免连续触发 audio_buffer.clear() except KeyboardInterrupt: print(停止监听。) finally: stream.stop_stream() stream.close() p.terminate()边缘部署优化技巧量化如果设备性能依然吃紧可以考虑对 ONNX 模型进行动态量化或静态量化将float32转换为int8能大幅减少模型体积和提升推理速度通常精度损失很小。# 使用ONNX Runtime的量化工具需要示例数据 from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic(my_custom_wakeword.onnx, my_custom_wakeword_quantized.onnx, weight_typeQuantType.QUInt8)使用特定执行提供器在 ARM 设备上可以尝试使用TensorRT如果有 Nvidia GPU或OpenVINOIntel 设备等执行提供器它们能针对特定硬件进行更深度的优化。# 在支持CUDA的平台上使用CUDA执行提供器 ort_session ort.InferenceSession(model.onnx, providers[CUDAExecutionProvider])6. 避坑指南与效能调优在实际操作中你一定会遇到各种预料之外的问题。这里分享一些常见的“坑”和对应的解决方案。6.1 训练阶段的常见问题问题1模型不收敛准确率始终在50%左右徘徊。排查首先检查数据标签是否正确。一个经典错误是正负样本的标签弄反了。其次检查数据预处理流程是否与模型期望的输入完全一致如MFCC参数、归一化方式。最后尝试降低学习率或者使用更简单的模型架构。技巧在训练初期打印出几批数据的特征和标签用眼睛直观检查。同时绘制训练损失和验证损失的曲线观察是否过拟合或欠拟合。问题2唤醒率尚可但误唤醒率极高。根源负样本不足或缺乏代表性。模型没有学会区分“非唤醒词”的多样模式。解决大规模扩充负样本库。除了常规语音加入音乐片段、环境噪声风声、雨声、键盘声、电视/广播音频片段以及与唤醒词发音相似的词组对于“开启星辰”可以加入“开始行程”、“凯瑟琳”等。数据增强时对负样本也可以添加噪声和混响。问题3模型对特定人的声音效果好对其他人效果差。根源数据集中说话人多样性不足导致模型过拟合到特定音色。解决尽可能收集更多不同年龄、性别、口音说话人的数据。在数据划分时严格按说话人ID划分训练集和测试集确保没有数据泄露。6.2 部署与推理阶段的常见问题问题1ONNX 导出失败报错“torch.onnx.errors.UnsupportedOperatorError”。原因模型中包含了 ONNX 不支持的 PyTorch 算子。解决检查opset_version是否足够新建议 11。简化模型结构避免使用过于复杂或自定义的算子。OpenWakeWord 的基础模型通常是标准 CNN问题不大。如果使用了自定义操作可能需要为其实现一个 ONNX 符号函数symbolic function。对于大多数情况选择通用的网络层可以避免此问题。问题2转换后的 ONNX 模型推理速度慢无法满足实时性要求如 200ms。优化方向模型层面使用更小的base_model如mobilenetv1减少n_mels维度或降低输入特征的时间长度。推理引擎确保使用了正确的 ONNX Runtime 执行提供器如CPUExecutionProvider并设置合适的线程数。对于 ARM CPU可以尝试启用ARMNN提供器如果编译时支持。量化如前所述int8量化通常能带来 2-4 倍的推理加速。批处理在服务端部署时如果请求量大可以考虑批处理输入能显著提升吞吐量。问题3在边缘设备上内存或CPU占用过高。解决降低推理频率不必对每个音频块都进行推理。可以每 300ms 或 500ms 推理一次这能大幅降低 CPU 使用率。使用更高效的特征提取优化特征提取代码避免使用librosa等重型库。可以考虑使用pyworld或直接使用优化过的 C 库进行 MFCC 计算。模型剪枝在训练后可以对模型进行剪枝移除不重要的神经元连接得到一个更稀疏、更小的模型再导出为 ONNX。问题4真实环境下的唤醒效果远差于测试集。原因训练/测试数据与真实环境存在分布差异。这就是所谓的“领域偏移”。解决增量训练。在真实环境中收集一些新的正负样本尤其是误唤醒和漏唤醒的案例用这些数据对已有模型进行微调fine-tuning。这是一个持续迭代的过程是提升产品最终体验的关键。可以参考热词中的增量训练实战思路但要注意控制学习率避免遗忘原有知识。自定义语音唤醒词的从训练到部署是一条涉及算法、工程和产品的完整链路。它没有银弹需要你在数据、模型、代码和部署环境之间反复迭代和调优。但一旦走通你获得的将不仅仅是一个能响应特定词语的模型而是一套可复用于各种语音交互场景的底层能力。这套能力正是构建智能化产品过程中最具价值的核心壁垒之一。