[Plugin] astrbot_plugin_mimo_tts_decorator

[huachabobo]

插件信息

{
  "name": "astrbot_plugin_mimo_tts_decorator",
  "display_name": "MiMo TTS 语音合成装饰器",
  "desc": "使用 Xiaomi MiMo TTS 将 AstrBot 回复转成 wav 语音，支持 style、语速控制，以及规则/LLM 自动音频标签润色。",
  "author": "花茶",
  "repo": "https://github.com/huachabobo/astrbot_plugin_mimo_tts_decorator",
  "tags": [
    "mimo",
    "TTS",
    "语音",
    "合成",
    "小米"
  ],
  "social_link": "https://github.com/huachabobo"
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mimo_tts_decorator

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

这是一份针对 main.py 文件的综合代码审查报告。该文件整体遵循了 AstrBot 的开发规范，正确实现了异步操作与事件处理机制。以下是代码中可优化的具体细节与潜在问题。

---

1. 代码质量与编码规范

• 正则表达式的重复编译：
  在 _sanitize_for_speech、_normalize_text 和 _cleanup_generated_tag_text 等方法中，大量使用了内联的正则表达式（如 re.sub(r"[\t\f\v]+", " ", text)）。虽然 Python 的 re 模块有内置缓存，但在频繁调用的文本处理环节，建议将这些固定的正则表达式提取为类级别或模块级别的预编译对象（re.compile），以提升代码运行效率并增强可读性。
• 变量命名：
  整体命名规范，表意清晰。仅有一个小建议：_cfg 辅助方法的设计很好，但可以结合 Python 3.10 的类型注解，进一步明确返回值的泛型或 Any 类型，以增强静态类型检查的效果。

2. 功能实现与逻辑正确性

• Base64 解码异常未捕获：
  在 _call_mimo_tts 方法中，处理音频数据时使用了 raw = base64.b64decode(audio_b64)。此操作位于 try...except 块之外。如果上游 API 返回了格式损坏的非标准 Base64 字符串，这里会直接抛出 binascii.Error。建议将其移入上方的 try 块内，或单独捕获并抛出具名错误。
• JSON 解析潜在的崩溃点：
  在 _auto_tag_llm 和 _call_mimo_tts 中，直接调用了 data = resp.json()。如果远端服务器虽然返回了 HTTP 200/400 等状态码，但 Response Body 并不是合法的 JSON（例如某些网关超时会返回 HTML），resp.json() 会先于下面的 try 块抛出 json.JSONDecodeError。建议捕获此解析异常。

3. 安全漏洞与最佳实践

• HTTP 客户端（连接池）未复用：
  在 _auto_tag_llm 和 _call_mimo_tts 中，每次调用均使用 async with httpx.AsyncClient(...) as client: 动态创建和销毁 HTTP 客户端。这在异步高并发或高频调用的场景下，会导致无法复用底层 TCP 连接池（每次都要重新进行 TCP/TLS 握手），极大地影响了网络 I/O 性能。最佳实践：建议在 __init__ 中初始化一个全局或实例级的 httpx.AsyncClient，并在插件卸载（terminate 方法）时优雅关闭它。
• 硬编码的 UUID 临时文件安全性：
  生成临时文件时使用了 uuid.uuid4().hex，有效防止了文件名冲突，且后续也有 _cleanup_stale_temp_files 清理机制，此处处理得当，无安全隐患。

4. 可维护性与可读性

• 类职责过载（God Class 倾向）：
  MimoTTSDecorator 类长达近 500 行，承担了配置解析、本地文件系统管理、文本重写与清理（基于规则）、LLM 提示词组装与请求、以及 TTS 接口调用与消息事件链的拦截。随着后续版本演进，建议将“文本处理与规则清洗引擎”或“网络请求客户端”抽离为独立的 Helper 类，以便于单元测试和后续维护。

5. 潜在缺陷或问题

• 缺失的请求重试机制：
  调用远端 TTS API 和 LLM Tagger 时没有重试策略。如果遇到偶发的网络抖动（特别是在超时时间设为 45~60 秒的场景），当前逻辑会直接向上抛出 RuntimeError，导致整条消息语音化失败。可以考虑引入轻量级的 Tenacity 或自行实现 1-2 次的异步重试机制。

---

框架适应性检查 (Pass)

• 日志记录：✅ 完美。只使用了 from astrbot.api import logger，未引入违规的日志库。
• 并发模型：✅ 完美。所有网络请求均使用了 httpx.AsyncClient，不存在阻塞事件循环的同步网络 I/O。
• 数据持久化：✅ 合规。正确使用了 StarTools.get_data_dir()。代码中使用 Path(StarTools.get_data_dir()) 来兼容返回的 Path 对象，并且利用 / 运算符拼接路径，处理方式非常标准。
• 插件注册与主类：✅ 完美。类继承自 Star。
• filter 装饰器：✅ 完美。从 astrbot.api.event 正确导入。
• 消息发送方式：✅ 合规。在 on_decorating_result 钩子中，仅通过修改 result.chain 实现链替换，并且 after_message_sent 仅做资源清理，未使用违规的 yield 发送方式。

---

代码评审团

Linus Torvalds：（揉了揉眉头，敲击着键盘）

"你看过你写的 _call_mimo_tts 和 _auto_tag_llm 吗？你居然在每一次、每一次网络请求的时候都去 async with httpx.AsyncClient()？你知道什么是 TCP 握手吗？你知道每次重新建立 TLS 隧道要浪费多少毫秒吗？你这是在惩罚服务器，也是在惩罚使用你插件的人！把这个 Client 给我提出来变成实例属性，利用好连接池！别让你的异步代码跑得跟同步一样慢！"

Steve Jobs：（穿着黑色高领毛衣，双手合十，眼神深邃）

"这款插件的功能很有趣，把干瘪的文字变成带情绪的语音，这很人性化。但是……看看你的 MimoTTSDecorator。它臃肿、杂乱。一个类不应该同时做清洗文本、管理临时文件夹、发 HTTP 请求、还去处理机器人的消息链。它缺乏内在的优雅（Elegance）。我建议你把文本清洗的逻辑封装成一个 SpeechFormatter，让你的主类保持干净。记住，不仅是用户体验要好，代码的内核也需要是一件艺术品。"

GLaDOS：（带着机械合成的冷漠电子音，核心轻微转动）

"哦，真是令人感动的乐观主义。你竟然假设 resp.json() 永远能解析出完美的 JSON 数据，而且 base64.b64decode 永远不会遇到错位的字符。这就像是人类相信明天永远会更好一样可笑。当你的上游服务器崩溃并吐出一个 HTML 502 错误页面时，你的解析器也会随之抛出异常并华丽地死掉。也许我应该为此准备一块小蛋糕，为了纪念你那未被捕获的 JSONDecodeError。"

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

当前仓库：huachabobo/astrbot_plugin_mimo_tts_decorator
剩余触发次数：3