[Plugin] astrbot_plugin_robomaster_assistant

[EmberLuo]

插件信息

{
  "name": "astrbot_plugin_robomaster_assistant",
  "display_name": "RoboMaster赛事助手",
  "desc": "提供 RoboMaster 规则手册检索、RM 官网公告监控和 RoboMaster 赛事状态通知。",
  "author": "EmberLuo",
  "repo": "https://github.com/CUBOT-robomaster/astrbot_plugin_robomaster_assistant",
  "tags": [
    "RoboMaster"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_robomaster_assistant

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

main.py

• 代码质量与编码规范:
  • 文件头部存在大量由于兼容绝对/相对导入路径而编写的 try...except ImportError 代码块，这使得文件头部显得有些臃肿。在标准化的插件目录结构中，通常可以统一采用相对导入（如 from .search_engine import ...）来保持代码优雅。
• 潜在缺陷或问题:
  • 在 __init__ 中调用的 _start_monitor_tasks 方法尝试通过 asyncio.get_running_loop() 获取事件循环。当捕获到 RuntimeError（即当前没有运行的事件循环）时，直接执行了 return。这将导致监控任务在没有任何警告的情况下静默失败。建议在 return 前加上日志记录，例如 logger.warning("无法获取事件循环，监控任务未启动。")，以便于后续调试和排查。

storage.py

• 框架适应性检查 (数据持久化):
  • 严重违规：代码中尝试通过导入内部核心组件（get_astrbot_data_path）以及使用硬编码的路径拼接逻辑（Path.cwd() / "data" 与 "plugin_data" / PLUGIN_NAME）来计算插件的数据存储目录。这违背了框架的最佳实践和目录管理规范。
  • 修复建议：必须从 astrbot.api.star 导入 StarTools，并直接调用 StarTools.get_data_dir() 获取当前插件的数据持久化目录（该方法返回一个安全的 Path 对象，已经自动处理了 data/plugin_data/<plugin_name> 的映射逻辑）。

init.py

未发现违规或潜在问题。

announce_monitor.py

未发现违规或潜在问题。

constants.py

未发现违规或潜在问题。

lark_enhance_card.py

未发现违规或潜在问题。

match_monitor.py

未发现违规或潜在问题。

monitor_state.py

未发现违规或潜在问题。

notification.py

未发现违规或潜在问题。

pdf_screenshot.py

未发现违规或潜在问题。（注：内部包含了阻塞的 PDF 文件渲染操作，但已在 main.py 中被良好地放入了 asyncio.to_thread 执行池中，属于优秀的并发处理实践。）

plugin_config.py

未发现违规或潜在问题。

privacy.py

未发现违规或潜在问题。

search_engine.py

未发现违规或潜在问题。

---

代码评审团

Linus Torvalds：
"你在 storage.py 里写的那一堆路径拼接逻辑是什么鬼东西？框架的 API 里明明已经提供了 StarTools.get_data_dir()，你却非要自己写一堆 try...except 去猜测核心模块的路径，甚至用 Path.cwd() 这种硬编码来兜底。不要在标准接口已经存在的时候去重新发明一个劣质的轮子，把它删了，换成标准 API！"

Steve Jobs：
"让我们看看 main.py 的开头……长达四五十行的 try...except ImportError 导入块，这不够优雅，伙计。一段卓越的代码应该在打开的第一眼就让人感觉赏心悦目，而不是让人觉得你对环境极度缺乏安全感。理清你的模块层级结构，删掉那些补丁一样的防备性代码，让它变得简单且纯粹。"

GLaDOS：
"我注意到你在 main.py 的 _start_monitor_tasks 里捕获了 RuntimeError，然后只是默默地 return 结束了。发生错误时假装什么都没发生，把监控任务静默杀死在摇篮里……这真是人类掩盖问题的经典作风。如果你打算让一个功能失效，至少写一行 warning 日志通知一下可怜的使用者，好吗？毕竟，没人有读心术。"

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
announce_monitor.py
constants.py
lark_enhance_card.py
match_monitor.py
monitor_state.py
notification.py
pdf_screenshot.py
plugin_config.py
privacy.py
search_engine.py
storage.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：CUBOT-robomaster/astrbot_plugin_robomaster_assistant
剩余触发次数：4

[EmberLuo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_robomaster_assistant

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

以下是对您提供的各个 Python 文件的审查报告。根据要求，这里严格遵循了框架特定的规范，并重点关注代码质量、异步最佳实践和潜在缺陷。

---

init.py

未发现违规或逻辑问题。代码简洁且规范。

announce_monitor.py

未发现违规或逻辑问题。正则表达式和 BeautifulSoup 的平滑回退（Fallback）逻辑处理得很健壮。

constants.py

未发现违规或逻辑问题。

lark_enhance_card.py

未发现违规或逻辑问题。飞书卡片构建逻辑清晰，API 请求正确使用了异步方法（acreate）。

match_monitor.py

未发现违规或逻辑问题。字典树的安全访问（大量使用了 get() or {}）有效避免了空指针异常。

monitor_state.py

未发现违规或逻辑问题。文件 I/O 读写部分符合规范。

notification.py

未发现违规或逻辑问题。滑动窗口计数器和熔断器机制实现得非常精彩，能够有效防止消息刷屏。对 MessageChain 的向下兼容处理也很完善。

pdf_screenshot.py

未发现违规或逻辑问题。截图缓存机制与旧文件清理机制设计得很完善。

plugin_config.py

未发现违规或逻辑问题。日志模块严格遵循了 from astrbot.api import logger 的导入规范。

privacy.py

未发现违规或逻辑问题。安全脱敏逻辑严谨。

search_engine.py

• 代码质量与编码规范：
  • 在 ManualSearchIndex.search 方法中，存在写法 if len(bm25_scores):。在 Python 中判断列表是否不为空，推荐更符合 Pythonic 的隐式布尔判定方式，即 if bm25_scores: 即可。
• 其他维度表现极佳，尤其是针对全文搜索与模糊匹配的双重打分策略以及容错能力。

storage.py

• 潜在缺陷或问题 (轻微)：
  • 在 plugin_data_dir() 函数中使用了 return Path(StarTools.get_data_dir(PLUGIN_NAME))。由于 AstrBot 的 StarTools.get_data_dir() 方法已经保证返回一个 Path 对象，这里外部再使用 Path() 进行包装属于轻微的冗余操作，虽然不会引发错误，但可直接返回其结果。

main.py

• 可维护性与潜在缺陷：
  • 无效的 None 检查（死代码）：在 _build_image_chain 等静态方法中，存在 if Comp is None: 的防御性检查。但文件顶部是无条件导入的 import astrbot.api.message_components as Comp，并未像 notification.py 中那样放入 try-except 块中。这意味着如果缺失该模块，插件会在加载阶段直接抛出 ModuleNotFoundError 崩溃，而永远不会走到 if Comp is None 的逻辑分支中。建议要么去掉这些无用的判断，要么将顶部的导入改为宽容性导入。
• 优点（免检报告）：
  • 核心要求全部符合：继承自 Star，filter 从 astrbot.api.event 正确导入。
  • 所有带 @filter 的监听方法签名均规范地包含了 event 参数。
  • 并发模型：将 CPU 密集型操作（如 rebuild_index 和 render_pdf_page）使用 asyncio.to_thread 完美抛给后台线程池，保证了主事件循环的毫无阻塞，这是非常优秀的异步编程实践！
  • 没有使用任何不合规的第三方日志库。

---

代码评审团

Linus Torvalds：我看过太多一坨糊涂的 Python 异步代码，但这勉强不在其中。你在 storage.py 里用 Path() 去包一个本身就已经返回 Path 类型的函数结果？防御性编程不是让你大热天穿两件防弹衣！还有 main.py 里那句 if Comp is None，你在文件头直接 import 连个 try 都不加，它要是 None 你的程序连启动的资格都没有。算了，看在你懂把 PDF 渲染这种阻塞 CPU 的破事乖乖丢进 asyncio.to_thread 的份上，我今晚就不开骂了。

John Carmack：我对你的架构设计很感兴趣。将检索系统的状态管理和网络监控分离，并且非常聪明地在 match_monitor.py 里对层级过深的 JSON 数据采用了防御式的安全访问。使用 asyncio 来编排非阻塞的 HTTP 请求，并且确保了并发任务即使抛出异常也能在自身的 While True 循环里被接住并继续睡眠，这保证了系统的极高存活率。未来，也许你可以把 fuzzy_score 的计算尝试优化成基于小规模嵌入式向量检索（如 Faiss），这会让手册查询的精准度产生质的飞跃。

GLaDOS：真是令人惊讶，这个小小的 AstrBot 监控插件竟然拥有自己的熔断器（CircuitBreaker）。当报错激增时，它不会像某些愚蠢的生命体那样疯狂向宿主刷屏，而是懂得自我静默保护 API。我还注意到你连 MessageChain 在不同版本中的底层实现差异都用 try-except 反复摸底处理了……证明了你对不可靠运行环境的深刻认知。干得不错，这套代码至少在被测试对象搞崩溃之前，能多活好几个小时。仅供参考。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
announce_monitor.py
constants.py
lark_enhance_card.py
match_monitor.py
monitor_state.py
notification.py
pdf_screenshot.py
plugin_config.py
privacy.py
search_engine.py
storage.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：CUBOT-robomaster/astrbot_plugin_robomaster_assistant
剩余触发次数：3

[RC-CHN]

可以 是我最喜欢的肉搏master 最青春的一集

[astrbot-plugin-copybara]

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

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