[Plugin] astrbot_plugin_clonetts

[Radiant303]

插件信息

{
  "name": "astrbot_plugin_clonetts",
  "display_name": "克隆语音",
  "desc": "基于火山引擎音色克隆的文本转语音插件",
  "author": "Radiant303",
  "repo": "https://github.com/Radiant303/astrbot_plugin_clonetts",
  "tags": [
    "声音",
    "语音",
    "火山引擎",
    "豆包"
  ],
  "social_link": "https://github.com/Radiant303"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_clonetts

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

main.py

代码质量与编码规范

• 导入未使用：import json 仅用于 json.dumps/异常捕获还算使用；但 requests + json.dumps 的组合方式不理想（见后文阻塞与请求构造问题）。另外 base64 仅用于校验，若不需要校验可移除以简化（否则建议把校验改为更明确的异常处理与日志）。
• 重复获取 result：on_decorating_result() 内先 result = event.get_result()，合成后又再次 result = event.get_result()；这不是错误，但可读性一般，且容易引入“前后 result 不一致”的维护成本（你已经用第二次判空规避了一部分）。

功能实现与逻辑正确性

• 请求体中的 token 字段疑似写错：request_json["app"]["token"] 被写死为字符串 "access_token"，看起来更像应该填真实 token（例如 self.access_token）或按接口要求填入其它值。当前写法很可能导致鉴权失败或行为不符合预期。
• Authorization 头格式可疑：{"Authorization": f"Bearer;{self.access_token}"} 使用了分号 ;。常见格式是 Bearer <token>（空格分隔）。如果火山接口确实要求分号则另说，但从代码一致性上看（body 里 token 又写死），这里很容易成为“看不出来但一直 401/鉴权失败”的根因。
• 直接覆盖返回消息链：result.chain = [Comp.Record.fromBase64(audio_b64)] 会丢弃原本 LLM 的文本/其它组件。若期望“语音 + 文本共存”，这里会造成逻辑偏差（用户只收到语音）。
• 长度判断按字符数可能不符合语音限制：len(llm_text) 对中文/多字节字符的限制未必等价于 TTS 接口的“字数/字节/时长”限制，可能出现“字符数合规但接口仍报超限”的边界问题（属于潜在逻辑不匹配）。

安全漏洞与最佳实践

• 隐私风险：日志记录完整回复文本：logger.info(f"正在合成克隆语音: {llm_text}") 会把对话内容原文写入日志。在机器人/LLM 场景里这经常包含敏感信息，建议至少降到 debug 或做脱敏/截断（例如只记录前 N 字）。
• 错误信息可能过度暴露上游响应：HTTP 非 200 时把 body={resp_json} 拼进异常信息；如果上游返回包含内部信息/调试字段，会被日志带出。建议只记录必要字段（code/message/reqid）。

异步环境与并发模型（仅指出网络 I/O 阻塞问题）

• 在 async 方法里使用 requests 造成事件循环阻塞：tts_synthesize() 是 async def，内部却调用 requests.post(...)（同步网络 I/O）。这会阻塞整个事件循环，导致机器人在合成期间无法及时处理其它消息/事件。应改为异步 HTTP 客户端，或把同步请求放到线程池/执行器中运行。
• resp.json() 解析同样是同步阻塞路径的一部分：在大响应或慢解析时会进一步拉长阻塞窗口（虽通常较小，但在高并发下会放大）。

潜在缺陷/异常处理

• JSON 解析异常捕获不准确：你捕获的是 json.JSONDecodeError，但 requests.Response.json() 通常抛出的是 requests.exceptions.JSONDecodeError（或 ValueError 体系，取决于 requests 版本/后端 json 库）。因此该分支可能捕获不到，导致异常走到外层（虽然 on_decorating_result 会兜底捕获，但会丢失你这里想给出的更明确错误语义）。
• 请求构造方式不规范，易引发兼容问题：requests.post(self.api_url, json.dumps(request_json), headers=header, ...) 使用位置参数传入 body（作为 data），但未设置 Content-Type: application/json，也没有用 json=request_json。在某些服务端/网关下会被按表单或纯文本处理，导致接口返回不可预期错误。
• 缺少对非 JSON 响应的健壮性处理：当服务端返回 HTML/纯文本错误页时，resp.json() 会抛异常；目前既没有在抛异常时记录 resp.text（用于排障），也没有保证能落入你期望的 JSONDecodeError 捕获分支。

框架适应性检查（AstrBot）

• @register 的前向兼容性风险：代码使用了 @register(...)。在较新的 AstrBot 版本中该装饰器已被标注为废弃（框架可自动识别 Star 子类）。这不是立刻的运行错误，但属于“未来升级时可能出现行为变化/加载逻辑差异”的维护风险点（尤其在多插件共存时）。
• filter 导入与事件签名：from astrbot.api.event import AstrMessageEvent, filter 符合要求；on_decorating_result(self, event: AstrMessageEvent) 也满足必须包含 event 参数的要求（此项无问题，不再展开）。

---

代码评审团

人物一（Linus Torvalds 风格：直球毒舌）
你把 requests.post() 塞进 async def 里，这是典型的“看起来能跑、实际上把事件循环当单线程脚本用”。在异步框架里这类阻塞会让整个 bot 卡住；修复思路很简单：要么全程异步 HTTP，要么丢到线程池，别让主循环替你等网络。

人物二（Grace Hopper 风格：重视可调试性与鲁棒性）
异常处理现在“看似细致、实际漏网”：resp.json() 抛的异常类型未必是 json.JSONDecodeError，导致你精心写的错误语义可能根本触发不了。建议围绕“响应可能不是 JSON”设计：先检查 Content-Type，解析失败时记录 status_code 与截断后的 resp.text，并把真正的 reqid/关键信息结构化打出来，排障效率会高很多。

人物三（GLaDOS 风格：冷幽默但给可执行建议）
你把 app.token 写成了 "access_token"，又把 Authorization 写成了 Bearer;xxx。这非常适合做一个“永远鉴权失败”的实验装置。建议把鉴权相关逻辑收敛成一个小函数：统一生成 header/body 的 token，并在启动时做一次“最小探活请求”（不含用户文本）验证配置是否可用，否则线上只能靠用户报错来发现问题。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#255
已自动合并 PR #255

该插件已上架。
This plugin is now published.