核心用法
本Skill为OpenClaw在Telegram平台上的多语言语音交互工作流，实现"语音优先+语言跟随"的智能回复机制。
输入处理逻辑：
- 文字输入：默认仅返回文字回复，不触发ASR/TTS；仅当用户明确要求"语音回复"时才生成语音+文字组合消息
- 语音输入：强制走本地ASR转写（mlx-community/Qwen3-ASR-0.6B-8bit模型），理解语义后生成回复；默认输出"语音+文字caption"同条消息，用户明确说"只要文字"时则仅返回文字
技术实现：
- STT：本地mlx_audio运行，默认Qwen3-ASR-0.6B-8bit模型，支持ogg/opus格式（Telegram语音默认格式）
- TTS：通过scripts/mlx_tts_voice.py生成Telegram友好的ogg/opus语音
- 消息格式：利用Telegram voice note的caption特性，将语音和文字绑定为单条消息，caption必须与语音内容完全一致
语言策略：严格跟随用户输入语言（中文→中文，英文→英文），除非用户显式指定其他语言，支持方言/口吻要求（受TTS模型限制）
显著优点
1. 隐私优先的本地处理：ASR/TTS均在Apple Silicon本地执行，敏感语音数据不上传云端
2. 交互体验优化：语音+文字同条消息设计，避免对话流碎片化，用户可听可看
3. 语言自适应：无需手动切换语言设置，自动识别并匹配用户用语习惯
4. 灵活输出模式：支持纯文字、纯语音、语音+文字三种模式，响应用户显式指令
潜在缺点与局限性
1. 硬件绑定：依赖Apple Silicon（MLX框架），x86设备无法运行
2. TTS质量瓶颈：mlx-community的TTS模型在方言、情感表达、长文本自然度上可能逊于商业云端TTS
3. ASR语言覆盖：Qwen3-ASR对低资源语言支持有限，小语种识别准确率可能下降
4. 格式兼容性：Telegram语音为ogg/opus，虽脚本内置ffmpeg fallback，但极端情况下可能转码失败
5. 无对话记忆管理：Skill未提及多轮对话上下文维护机制，长对话连贯性依赖底层OpenClaw实现
适合人群
- Telegram重度用户且偏好语音交互的效率型用户
- 对语音隐私敏感、拒绝云端ASR/TTS的Apple Silicon设备持有者
- 需要跨语言（中英为主）自然交流的多语言使用者
- 希望减少打字、通过语音快速获取结构化回复的场景
常规风险
- 模型幻觉：ASR转写错误可能导致后续回复偏离用户真实意图，关键场景建议用户核对caption
- 语音伪造感知：TTS生成语音缺乏说话人特征，接收方可能误判为真人/非真人，存在社交信任摩擦
- 本地资源占用：MLX模型推理消耗NPU/GPU资源，低电量或老旧机型可能影响系统流畅度
- caption一致性维护：开发层面需确保caption与语音内容严格一致，否则造成用户体验割裂