[Plugin] astrbot_plugin_airi_voice

[Lidure]

插件信息

{
  "name": "astrbot_plugin_airi_voice",
  "display_name": "airi_voice",
  "desc": "输入语音音频文件名（关键词）回复对应语音。提供插件内的airi的语音，需要额外语音可以通过配置项自己添加。",
  "author": "Lidure",
  "repo": "https://github.com/Lidure/astrbot_plugin_airi_voice",
  "tags": [
    "音频"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_airi_voice

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

main.py

1. 数据目录工具的导入路径不符合规范要求

   • 当前使用：from astrbot.core.star.star_tools import StarTools
   • 审查要求指定应通过 API 层导入（astrbot.api.star）来获取 StarTools。直接依赖 core 内部路径会增加框架升级时的兼容风险，也不符合“统一入口”的规范。

2. 使用 from ... import * 影响可维护性与可读性

   • from astrbot.api.all import * 会引入大量隐式符号，降低可读性，并增加命名冲突风险。
   • 在本文件里又单独导入了 filter、AstrMessageEvent、logger，风格混用更容易造成后续维护困惑。

3. voice_handler 监听范围过大，可能带来性能与行为副作用

   • @filter.regex(r"^\s*.+\s*$") 等于匹配几乎所有非空消息，插件会在每条消息上执行关键词查找。
   • 在群聊高频消息场景会造成不必要开销；同时会与其他命令型插件形成潜在冲突（虽然你这里做了关键词命中判断，但入口层面仍是“全量拦截”）。

4. 网页语音加载未限制文件类型，与本地加载策略不一致

   • _load_local_voices 有后缀白名单（.mp3/.wav/.ogg/.silk/.amr），但 _load_web_voices 对 extra_voice_pool 未做后缀校验。
   • 结果是：任意位于数据目录下的文件都可能被加入 voice_map，触发时才在发送阶段报错；并且可能误把非音频文件当作可发送资源，存在错误暴露风险。

5. voice.reload 缺少权限控制，存在被滥用风险

   • 当前任何可触发命令的用户都可以执行全量重载（扫描目录 + 重建映射）。
   • 在多人环境中，这类“管理操作”建议增加权限限制（管理员/白名单），避免频繁触发导致资源浪费或运维干扰。

6. trigger_mode 配置缺乏合法性校验

   • 当前逻辑仅判断 == "prefix"，其余值全部退化为 direct 模式。
   • 一旦配置拼写错误（如 prefx），不会有明确告警，表现会悄悄偏离预期，排障成本高。

7. 代码风格存在缩进不整齐问题（PEP 8 可读性层面）

   • __init__ 方法内部语句缩进明显深于常规 4 空格层级，虽然语法可通过，但会降低可读性，影响协作维护体验。

---

代码评审团

人物一：Linus Torvalds（直给型）
“你这个 regex 监听写法像是拿渔网捞整个海，最后只挑一条鱼。能跑不等于优雅。把触发入口收窄，别让每条消息都走一遍插件逻辑。”

人物二：Grace Hopper（工程纪律型）
“本地与网页两套加载规则不一致是典型维护隐患。今天是后缀校验缺失，明天就是线上‘为什么这个 txt 也在语音列表里’。统一输入约束，系统行为才可预测。”

人物三：Tony Stark（产品+架构型）
“voice.reload 这种操作像机甲的‘系统重启键’，你不能把它贴在外壳上让所有人按。加权限、加审计日志，你的插件会立刻从‘能用’升级到‘可运营’。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：Lidure/astrbot_plugin_airi_voice
剩余触发次数：2

[zouyonghe]

按AI审核要求改一下

[Lidure]

3.voice_handler 监听范围过大，可能带来性能与行为副作用

@filter.regex(r"^\s*.+\s*$") 等于匹配几乎所有非空消息，插件会在每条消息上执行关键词查找。

对于这个，我之前版本有设过加前缀，但是感觉加前缀不符合我的理念，虽然确实释放了更多的性能，但是我就是不想....

5.trigger_mode 配置缺乏合法性校验

当前逻辑仅判断 == "prefix"，其余值全部退化为 direct 模式。
一旦配置拼写错误（如 prefx），不会有明确告警，表现会悄悄偏离预期，排障成本高。

这个就更离谱了，我配置是下拉框选择，根本不需要输入

其他已改

[Lidure]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_airi_voice

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

main.py

1. 框架适应性检查 (严重问题)

• 硬编码数据目录：代码中违反了框架的数据持久化规范。在 __init__ 方法中，使用了 self.plugin_dir.parent.parent.parent / "data" / "plugin_data" / "astrbot_plugin_airi_voice" 这种极度脆弱且不规范的相对路径穿透方式来获取数据目录。
  • 修复建议：必须从 astrbot.api.star 导入 StarTools，并使用 self.data_dir = StarTools.get_data_dir("astrbot_plugin_airi_voice") 获取规范的 Path 对象。

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

• 帮助文档文本截断：在 help 方法中，help_msg 的字符串定义存在明显的缺失。
  • • prefix: 使用 后面直接断开了，缺少了具体的说明（例如 #voice），导致用户阅读帮助时会产生困惑。
• 字符串插值导致的空行：在 help 方法中，f"• /voice.reload - 重新加载语音列表 (管理员)" if is_admin else "" 的写法在非管理员查看时，会在输出结果中留下一个刺眼的空行。
  • 修复建议：可以将命令列表放入一个列表中，根据权限 append 相应的行，最后使用 \n.join() 连接，或者在条件判断中包含换行符处理。

3. 代码质量与编码规范

• 过度宽泛的异常捕获：在 _check_admin、voice_handler 和 check_permission 方法中，大量使用了 except Exception: 或 except Exception as e:。
  • 修复建议：在探测对象属性（如 event.message_obj.sender.user_id）时，应该只捕获 AttributeError 或特定的预期异常。捕获所有异常会掩盖代码中潜在的致命错误（如拼写错误或类型错误）。

4. 可维护性与可读性

• 权限判断逻辑冗余：_check_admin 和 check_permission 方法中获取 user_id 的 fallback 逻辑高度重复：

  try:
      user_id = event.message_obj.sender.user_id
  except Exception:
      user_id = getattr(event, 'sender_id', None) or getattr(event, 'user_id', None)

  • 修复建议：建议将“从 event 安全提取 user_id”的逻辑提取为一个单独的私有辅助方法（例如 _get_user_id(event)），以提高代码复用率和整洁度。

---

代码评审团

人物一：Linus Torvalds（Linux之父，以言辞犀利、追求极致代码质量著称）
“你是在逗我吗？.parent.parent.parent？你在写代码还是在玩俄罗斯套娃？这种硬编码的路径遍历简直就是一颗定时炸弹，只要框架的目录结构稍微动一下，你的插件就会死得很难看！框架既然给你提供了 StarTools.get_data_dir() 这个 API，你为什么不用？难道你觉得你手动数父目录的层数显得你很聪明吗？除此之外，那个 except Exception: pass 简直就是犯罪。你把所有的错误都扫到了地毯下面，当系统崩溃的时候，你连怎么死的都不知道。重写这部分，马上！”

人物二：Gordon Ramsay（地狱厨神，暴躁但一针见血的完美主义者）
“Look at this help message! It's RAW! 你的 • prefix: 使用 后面到底要用什么？你把话说到一半就咽下去了？就像你端给我一盘没有烤熟的惠灵顿牛排，里面的肉还是冰的！还有那个非管理员看到的空行，就像是盘子边缘没有擦干净的酱汁，极其不专业！另外，你的鉴权逻辑到处都在复制粘贴，DRY 原则（Don't Repeat Yourself）被你当耳旁风了吗？把获取 user_id 的逻辑切片、打包、放进一个独立的方法里！Wake up!”

人物三：GLaDOS（《传送门》系列中的人工智能，冷酷、挖苦且关注逻辑测试）
“哦，真是令人惊叹。一个能够处理语音发送的模块。只是，当你测试 voice.list 的分页逻辑时，虽然你用了 isdigit()，但如果有人恶意传入巨大的页码数字，你只是温和地告诉他们‘页码过大’。这很好，很克制。不过，我注意到你在验证用户权限时，试图猜测 user_id、sender_id、甚至是 nickname……这就像是一个没有视觉的机器人在迷宫里瞎摸。虽然最终能摸到出口，但过程实在不够优雅。建议你统一标准化你的身份标识获取策略，这样在我们接管系统时，可以少处理一些垃圾数据。总之，作为一个测试样本，它还算……勉强活着。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：Lidure/astrbot_plugin_airi_voice
剩余触发次数：1

[Lidure]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_airi_voice

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

main.py

1. 代码质量与编码规范

• 帮助文档文本截断：在 help 方法返回的帮助字符串中，存在明显的文本丢失：• prefix: 使用 后面失去了下文，应该补充完整（如 使用 #voice 前缀触发）。

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

• 初始化状态不完整（重要Bug）：在 __init__ 函数中，调用 self._load_local_voices() 和 self._load_web_voices() 加载完语音列表后，没有初始化并赋值 self.sorted_keys。由于 self.sorted_keys 初始值为 []，这将导致插件首次启动时，用户执行 /voice.list 命令永远只会得到“当前没有可用语音～”的提示，直到管理员手动执行一次 /voice.reload。
• 热更新逻辑中遗漏状态同步：在 voice_handler 方法内，当检测到配置改变触发 self._load_web_voices() 自动加载新语音后，同样遗漏了对 self.sorted_keys 的更新操作，这将导致 voice.list 中的分页数据与实际可用的语音字典脱节。

3. 安全漏洞与最佳实践

• 优秀的目录穿越防护：代码在 _load_web_voices 中使用 abs_path.is_relative_to(data_dir_resolved) 验证路径，非常规范地防御了 Path Traversal（目录穿越）漏洞，符合安全最佳实践。
• 获取用户ID的方式不够规范：在 _get_user_id 中，使用了大量 try-except 和 getattr 来猜测 event 对象的内部属性。由于 AstrBot 的 AstrMessageEvent 规范中直接提供了 event.get_sender_id()，建议直接使用框架封装好的方法来替代这种“打补丁”式获取机制。

4. 可维护性与可读性

• 事件处理方法的冗余检测机制：voice_handler 使用了极度宽泛的正则 @filter.regex(r"^\s*.+\s*$") 拦截所有包含字符的消息，即使非触发前缀也会进入处理流程再去查询 self.voice_map。尽管目前的字典查询开销极低，但作为最佳实践，应尽量通过更精确的正则或事件机制收敛触发范围。

5. 潜在缺陷或问题

• 配置变更检测逻辑不够健壮：在 voice_handler 中，代码仅通过长度比较 current_pool_len > self.last_pool_len 来判定是否需要重新加载。如果管理员在网页后台删除了某些语音路径（长度变短），或者替换了相同数量的新路径（长度不变），该逻辑将直接失效并拒绝更新。建议直接对比两次配置的内容（如 extra_pool != self.last_extra_pool）来判定变更。

---

代码评审团

人物一：Linus Torvalds
“你看你在 __init__ 里写了什么？你费了半天劲从本地和网络加载了语音，把它们塞进字典，然后 self.sorted_keys 就扔在那里让它保持空列表？这意味着每次新用户安装你的代码，兴冲冲地打出 /voice.list，都会被告知啥也没有！拜托，初始化状态要完整，你在重载机制里写对了，为什么在构造函数里就忘了？顺便说一句，只用长度去判断配置是否更新，是我见过最偷懒的做法，假如我删了一个又加了一个，你的代码就会装作无事发生！”

人物二：Steve Jobs
“体验！用户体验在哪里？当用户敲入 /voice.help 想要学习怎么用的时候，屏幕上赫然写着：‘prefix: 使用’... 使用什么？！它就像是一件背面没有缝好的高领毛衣，或者一个掉了一半按键的键盘！另外，那些充满了 getattr 和 try-except AttributeError 的代码就像是缝合怪的伤疤，去阅读文档吧，把 event.get_sender_id() 用起来，让代码保持优雅和极简。”

人物三：Elon Musk
“实际上，你们的路径检查逻辑相当硬核（hardcore）。那个 is_relative_to 阻止了潜在的相对路径攻击，这很好，就像我们的猎鹰火箭上的安全自毁机制一样稳健。但是关于那个 @filter.regex(r"^\s*.+\s*$")，这就有点像给整个星舰装满了一直处于激活状态的雷达，它甚至会捕获路过的一只鸟并去字典里查它的名字。在处理高吞吐量信息流时，我们也许应该在入口把信号过滤得更干净一些。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：Lidure/astrbot_plugin_airi_voice
剩余触发次数：0

[Lidure]

2 已修

[Lidure]

astr解析不了Q语音音频吗

[astrbot-plugin-copybara]

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

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