[Plugin] astrbot_plugin_diyrule

[landamao]

插件信息

{
  "name": "群唤醒增强",
  "display_name": "自定义群聊的唤醒规则",
  "desc": "为每个群聊自定义唤醒规则",
  "author": "懒大猫",
  "repo": "https://github.com/landamao/diyrule",
  "tags": [
    "工具",
    "辅助",
    "群聊",
    "功能"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_diyrule

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

main.py

1) 框架适配性 / AstrBot 规范问题

• logger 导入不符合要求：当前 from astrbot.api.all import ... , logger。按规范 logger 必须且只能 from astrbot.api import logger 导入；从 astrbot.api.all 导入不符合检查要求，可能导致框架侧日志路由/封装不一致。
• 事件监听装饰器体系不符合要求：代码使用 @event_message_type(...)（来自 astrbot.api.all），但要求“所有事件监听器的装饰器都来自 filter 对象”，且必须 from astrbot.api.event import filter。当前未导入 filter，也未使用 @filter.xxx 体系，存在与框架推荐用法不一致的问题（也增加与内置 filter() 混淆风险规避点未落实）。

2) 逻辑正确性问题（会导致行为明显异常）

• “启用的指令”判断逻辑几乎必然误判：

  elif any(指令 not in 指令文本 for 指令 in 规则['启用的指令']):
      event.stop_event()

  只要启用列表里存在任意一个指令不在当前 指令文本 中，就会拦截；而启用列表通常包含多个指令，因此对绝大多数指令都会拦截（几乎永远为 True）。更合理的语义通常是：如果没有任何启用项匹配当前指令才拦截（not any(...)），或按“精确命令名”匹配。
• 群号类型/规范化不一致导致规则可能失效：self.l启用群号.append(群号.strip()) 存的是字符串；event.get_group_id() 返回值在不同适配器下可能是 int 或 str。你在外层 if 群号 in self.l启用群号: 以及内层 if 群号 == j.strip(): 都可能因类型不一致导致匹配失败。建议统一转字符串或统一转整数，并集中规范化一次。
• “禁用系统指令”使用精确相等，实际易绕过：
  指令文本 = 消息文本[len(前缀):] 后直接 if 指令文本 in self.系统指令。用户输入常见形式如 help xxx、plugin ls xxx 会因为带参数导致不等于列表项而绕过。需要先解析“命令名/子命令”，再匹配白黑名单。
• “禁用的指令”使用子串匹配，误伤概率高：
  any(指令 in 指令文本 for 指令 in 规则['禁用的指令']) 会导致例如禁用 he 误伤 help，禁用 l 误伤大量命令。若你的语义是命令级别禁用，应按 token/首段/精确命令名匹配。
• 概率跳过的随机判定位置不合理：
  在遍历 消息链 的 for seg in 消息链: 里执行：

  elif 规则['概率跳过'] and random.random() < 规则['概率跳过']:
      return

  这意味着每个消息段都会重新抽一次概率，消息段越多越容易被跳过，概率不再是“对整条消息一次判定”的直觉语义，造成行为不可预测。

3) 可维护性 / 可读性问题

• 嵌套层级过深、早返回/拦截分支过多：主函数 中多层 for + 多层 if/elif + 多处 return/stop_event()，使得阅读和验证逻辑非常困难，也容易引入“某个分支提前 return 导致后续规则永远不执行”的问题。建议把“规则选择”“指令判定”“唤醒判定”“跳过判定”拆成若干小函数，并将规则按群号预索引（字典映射）。

• 重复遍历与重复计算：对每条群消息，你会：

  • 遍历所有规则 self.规则列表
  • 每条规则再遍历 规则['群号']
  • 再遍历所有指令前缀 self.l指令前缀

  在规则较多、群较多时会增加不必要的 CPU 消耗。可以在 __init__ 把规则按群号构建映射：group_id -> [rules...]，事件里只取当前群对应规则。

• 对 config 的键缺少健壮性：多处直接 config['指令前缀']、config['额外指令']、规则['禁用的指令'] 等，若配置缺键会直接 KeyError 导致插件加载/运行失败。建议使用 .get() 并设默认值，或启动时做配置校验并给出清晰错误。

• 依赖内部实现细节，升级风险高：from astrbot.core.star.star_handler import star_handlers_registry、CommandFilter/CommandGroupFilter 属于偏内部结构；f获取所有指令() 依赖它们的属性结构（如 alias），可维护性较弱，后续框架内部变动可能导致崩溃或拿不到命令。

4) 潜在缺陷/行为边界

• self.l启用群号 未去重：同一个群号出现在多个规则或重复配置会重复插入，虽不影响 in 判断正确性，但体现配置处理不严谨，也增加调试噪音。
• 日志可能过噪/泄露：初始化时 warning 打印“所有指令”清单，若运行环境日志可被非预期人员读取，可能暴露管理类命令/插件能力面；且 warning 级别可能导致长期刷屏。更适合 debug/info，并可加开关。
• 直接写入 event.is_at_or_wake_command 可能不稳定：这是对 event 对象动态加/改属性，若框架/适配器对 event 使用 __slots__ 或后续改动，会引发属性错误或不可预测行为。更稳妥是使用框架提供的标准方式标记唤醒/上下文（如果有）。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你的 主函数 像一锅意大利面：能吃但很难保证每次都熟。尤其“启用的指令”那段 any(not in ...) 基本属于逻辑自杀——配置一多就全拦。把“解析命令名/参数”“命令放行策略”“唤醒判定”拆成函数，再用表驱动（按群号映射规则）会让这段代码从“不可维护”变成“还能改”。

人物二（Guido van Rossum，偏 Pythonic 的温和挑剔）：
我看到大量嵌套 if/elif 和早返回，这会让你很难证明每条路径都正确。更 Pythonic 的写法是：先规范化输入（群号类型、消息文本、命令名），再把判定写成一组清晰的 predicate（例如 should_block_command()、should_wake()）。另外，子串匹配命令非常不“显式”，建议解析 token 后做精确匹配。

人物三（Margaret Hamilton，强调可靠性与工程纪律）：
这段逻辑在“配置缺失/配置异常/概率值越界/群号类型变化”时缺少防御式设计，会让系统在边界条件下失控。建议在启动时做配置 schema 校验（键是否存在、类型是否正确、概率是否在 0~1），并将随机判定从“按消息段多次抽样”改为“按消息一次抽样”，否则系统行为不可预测，难以测试与复现。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[Soulter]

已上架