[Plugin] astrbot_plugin_genshin_activity_cover

[galaxy-b612]

插件信息

{
  "name": "astrbot_plugin_genshin_activity_cover",
  "display_name": "米游社官方咨询实时搬运插件",
  "desc": "自动轮询米游社API，实时搬运原神官方资讯到QQ群聊",
  "author": "iris",
  "repo": "https://github.com/galaxy-b612/astrbot-plugin-genshin-activity-cover",
  "tags": [],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_genshin_activity_cover

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

main.py

1. 框架适应性与规范问题

• 日志记录器导入错误
  代码中使用了 from astrbot.core import logger，违反了插件开发规范。必须且只能从 astrbot.api 导入，即应该修改为 from astrbot.api import logger。
• 数据持久化路径硬编码
  代码在 __init__ 中硬编码了数据存储路径：

  self.plugin_dir = os.path.dirname(os.path.abspath(__file__))
  self.data_dir = os.path.join(self.plugin_dir, "data")

  这违反了数据持久化的规范。对于需要持久化保存的数据，应该使用框架提供的标准方法。需导入 from astrbot.api.star import StarTools，并通过 StarTools.get_data_dir("astrbot_plugin_genshin_activity_cover") 来获取规范的存储目录（注意它返回的是 Path 对象）。

2. 代码质量与可读性

• 平台与群组遍历逻辑存在严重重复
  _send_images_batch、_send_forward_message、_send_batch_forward 这三个方法中，几乎复制粘贴了相同的“获取 platform_manager -> 校验 platform 实例 -> 遍历 platform -> 提取 bot -> 遍历 target_groups”的样板代码。强烈建议提取一个如 _get_available_bots() 或一个统一的消息下发包装函数，以降低代码维护成本并符合 DRY (Don't Repeat Yourself) 原则。
• 类型提示（Type Hinting）可以更现代化
  在 Python 3.10 环境下，无需从 typing 导入 List 和 Set，根据 PEP 585，直接使用内置的 list 和 set 作为类型注解即可（如 list[dict]、set[str]）。

3. 潜在缺陷或问题

• 任务生命周期处理不当（CancelledError）
  在 terminate 方法中调用了 self._task.cancel()，由于 self._poll_activity_covers 内存在 await asyncio.sleep，取消操作将会在挂起的地方引发 asyncio.CancelledError。而代码中使用了通用的 except Exception as e: 捕获异常，并且没有向上抛出或针对 CancelledError 的处理。建议显式捕捉并忽略 asyncio.CancelledError 以避免插件关闭时出现不必要的报错堆栈。
• 平台过度耦合（跨平台隐患）
  虽然 AstrBot 强调多平台兼容，但代码中直接调用了 bot.call_action("send_group_forward_msg", **payload) 并在 payload 中组装了典型的 OneBot/Napcat 格式的消息节点字典。当此插件加载在非 OneBot 生态体系的平台实例（如 Telegram 或微信）上时，不仅会无法工作，还会引发内部调用异常。应当增加对目标平台类型的检测判断机制。

---

代码评审团

Linus Torvalds：
你看过你写的 _send_images_batch、_send_forward_message 和 _send_batch_forward 吗？它们看起来就像是用复制粘贴键写出来的。如果你觉得把同一段遍历 bot 的恶心代码连续塞进三个函数里是个好主意，那你一定是不介意未来维护时在三个地方修同一个 Bug。赶紧给我把它重构成一个统一的消息分发器接口，不要让这种重复的样板代码污染了整个类！

Steve Jobs：
我们设计产品的核心是“优雅”与“无缝体验”。而你的代码在这个框架下显得格格不入。你绕过了框架精心设计的数据持久化接口（StarTools），非要自己在本地拼一个硬编码的 data 目录；你甚至没有用到我们推荐的 api logger。请去拥抱系统提供的生态规则好吗？不要再让它看起来像个上个世纪组装出来的拼装品。

GLaDOS：
我在检查你的协程生命周期。你通过 self._task.cancel() 粗暴地结束了轮询任务，然后你的 except Exception as e 像个无底洞一样试图吃掉所有异常，甚至包括 CancelledError。这就好比你在测试对象还在做测试的时候直接关闭了光圈科技的电源，然后抱怨为什么仪器上显示出红色的错误堆栈。请温柔一点，显式处理你的取消操作。另外，测试不仅限于你家里的 QQ，你确定其他通讯平台也能理解你那些充满 OneBot 味道的魔法调用指令吗？显然不能。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：galaxy-b612/astrbot-plugin-genshin-activity-cover
剩余触发次数：4

[galaxy-b612]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_genshin_activity_cover

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

main.py

在对 main.py 的代码进行细致审查后，整体代码结构清晰，网络请求使用了异步处理，任务生命周期管理也较为规范，且严格遵守了框架的日志记录要求与数据持久化规范。但仍存在以下一些值得优化的缺陷或问题：

1. 性能瓶颈与最佳实践

• aiohttp.ClientSession 未复用：在 _check_new_articles 方法中，每次调用该方法都会通过 async with aiohttp.ClientSession() as sess: 创建并销毁一个新的会话实例。在后台轮询任务中，频繁创建和销毁 TCP 会话是低效的且无法利用连接池（Keep-Alive）。
  建议：在插件 initialize 时创建一个类级别的 ClientSession 并在插件的生命周期内复用，最后在 terminate 时进行关闭。

2. 可维护性与代码耦合

• 绕过框架抽象过度依赖底层实现：为了实现发送 OneBot 特有的“合并转发”消息，代码在 _send_forward_message 等方法中提取了底层的 bot 实例并直接调用 bot.call_action("send_group_forward_msg", ...)，甚至调用了 bot.send_group_msg(...)。这不仅将代码与 OneBot 协议强耦合，还意味着如果 AstrBot 运行在非 OneBot 生态（如 Telegram 或其他平台），这部分功能将彻底瘫痪。
  建议：虽然为了某些富文本功能做出了妥协，但应该尽可能依赖 AstrBot 提供的统一消息构建器和 context.send_message 接口；或者使用更明确的平台适配策略。

3. 逻辑细节与优化空间

• 冗余的文件写入操作：_save_posted_ids() 在 _check_new_articles 循环内部被频繁调用。例如：当出现多个需要过滤的文章，或分批发送完单篇文章后，都会触发完整记录集合的全量同步覆盖写入。
  建议：考虑到该方法在 terminate 时也会调用，日常轮询只需在一次 _poll_activity_covers 批次结束后（或发生数据变动时）统一调用一次即可，减少毫无必要的文件 I/O 损耗。
• 宽泛的异常捕获：代码中大量使用了 except Exception as e: 来进行防御性编程。尽管在后台轮询里这能防止任务异常崩溃，但它可能吞噬掉关键的运行时错误并增加排查难度。

---

代码评审团

人物一（Linus Torvalds）：
“你是在逗我吗？在轮询循环里每次都要 async with aiohttp.ClientSession()？你以为每次都新建一个 TCP 连接是在开玩笑吗？网络连接资源不是免费的，TCP 握手也不是为了让你浪费的！把那个该死的 Session 放到类属性里复用它，搞懂底层的连接池是怎么运作的再来写高频请求！”

人物二（Steve Jobs）：
“用户体验是无缝的，而你的架构设计却露出了底层的齿轮。你直接调用 bot.call_action 和依赖具体的 OneBot 平台逻辑，就好像在一台极简的 Mac 里塞进了一根裸露的排线。我能理解你为了炫酷的‘合并转发’而作出的让步，但从艺术和设计的角度来看，它破坏了抽象层的一致性。你应该思考如何与框架更加优雅地融为一体。”

人物三（Deadpool）：
“哇哦，看看这满地的 except Exception as e，这防弹衣穿得比我还厚实！你知道吗，这种‘不管发生啥老子都要继续跑’的精神简直太对我胃口了。就像我的自愈因子一样，哪怕逻辑断了一条腿它也会自己长好！不过老兄，如果哪天你的代码不小心触发了毁灭地球的 Bug，记得它会被这些 except 静悄悄地藏起来哦！💥”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：galaxy-b612/astrbot-plugin-genshin-activity-cover
剩余触发次数：3

[galaxy-b612]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_genshin_activity_cover

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

main.py

代码质量与编码规范

1. 单一职责原则 (SRP) 违背：_check_new_articles 方法过于庞大（长达 60 多行）。它同时负责构建请求、发送网络请求、解析 JSON、过滤文章、判断是否仅为活动封面、提取图片、决定发送策略（合并转发或批量发送）以及更新状态。这不仅增加了阅读难度，也使得后续难以对单独的逻辑（如解析策略或发送策略）进行单元测试和维护。
2. 魔法数字与硬编码 (Magic Numbers & Hardcoding)：
   • gids = 2、news_types = [1, 3] 缺乏注释说明这些具体代表原神社区的哪个板块，后续接手的人很难理解。
   • 请求头中的 User-Agent 被硬编码为特定的 Windows Chrome 版本。
   • 各种阈值（如 page_size: 5, fwd_img = 4, fwd_art = 2）虽然在方法内有部分 fallback 到 config，但散落在各处，建议统一提取为类常量或在 __init__ 中初始化。

功能实现与逻辑正确性

1. 潜在的重复发送风险：在 _iter_bots_and_groups() 中，如果 self._target_groups() 由于配置错误（用户手滑在 config 中填了两个相同的群号），该方法会 yield / append 重复的 (bot, gid) 对，导致在目标群组发送两遍完全相同的资讯。建议在 _target_groups 返回时使用 set 去重，例如 return list(set(int(g) for g in groups))。
2. self._forward_sender_uin 初始化逻辑缺陷：在 _delayed_start 中，通过 self._forward_sender_uin = str(p.bot.self_id) 获取机器人 QQ 号，如果失败则回退到 "0"。但在 _send_forward_message 等发送方法中，直接使用了这个 "0" 作为合并转发的 UIN。某些严格校验 OneBot 协议的无头客户端（如 Lagrange）可能会直接拒收 uin="0" 的伪造节点，导致合并转发静默失败。

可维护性与可读性

1. 异常处理颗粒度过大：_check_all_types 和 _send_images_batch 中的 except Exception as e 捕获了所有异常。在网络请求中，最好显式捕获 aiohttp.ClientError 等特定的异常，将意外的代码逻辑错误（如 KeyError, TypeError）暴露出来，或者进行区分处理。

框架适应性检查

• 日志记录：✅ 正确导入并使用了 astrbot.api.logger。
• 并发模型：✅ 未发现阻塞的网络 I/O，aiohttp 的使用符合异步规范。
• 数据持久化：✅ 正确使用了 StarTools.get_data_dir()，并且正确处理了返回的 Path 对象。
• 插件注册与主类：✅ GenshinActivityCoverPlugin 正确继承了 Star。

---

代码评审团

Linus Torvalds：
看着你的 _check_new_articles 函数，我简直要得高血压了。你是不是觉得把所有的逻辑——请求、解析、过滤图片、算术判断、发送消息——全塞进一个缩进层级深达五层的循环里，显得你的屏幕特别宽？拆分它！把获取数据的逻辑、解析数据的逻辑和发送消息的逻辑分开！另外，那个 User-Agent 硬编码得就像是十年前从 StackOverflow 上复制粘贴下来的，至少把它放进类属性里吧，别让它藏在函数的肚皮底下。

GLaDOS (《传送门》)：
分析完毕。我注意到你在尝试获取机器人账号失败时，非常“聪明”地把 UIN 设置成了 "0"。真是个了不起的后备计划。我确信底层的那些严谨的协议端看到一个名叫“米游社搬运工”、账号是 0 的幽灵节点时，一定会非常开心地帮你转发，而不是直接抛出错误然后把你的请求扔进焚化炉。如果你找不到身份，也许你应该停止发送，而不是假装自己是一个不存在的实体。

Tony Stark：
Hey kid，这插件的底子不错，能自动搬运图片，省去人工切瓜的麻烦。不过看看这些魔法数字：gids = 2，type: 1, 3。这就像在我的战衣操作系统里写满了未经说明的十六进制内存地址一样。给它们取个有意义的名字吧，比如 GENSHIN_COMMUNITY_ID，或者 NEWS_TYPE_ANNOUNCEMENT。顺便一提，你的目标群组配置最好加个去重过滤，我不觉得谁会愿意在同一个群里一秒钟内看两遍一模一样的七圣召唤海报——哪怕你已经很努力地把它过滤掉了。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：galaxy-b612/astrbot-plugin-genshin-activity-cover
剩余触发次数：2

[galaxy-b612]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_genshin_activity_cover

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

main.py

1. 综合审查维度

• 代码质量与编码规范:
  • 代码整体结构清晰，类的方法划分合理，功能拆分得当。
  • 命名规范，常量的使用（如 _GAME_ID, _API_TIMEOUT）有助于维护。
• 功能实现与逻辑正确性:
  • 严重逻辑缺陷 (跨平台兼容灾难)：在 _do_send_forward 方法中，使用了全局的 sent_any 来记录是否发送成功。当同时连接多个平台时（例如一个支持 OneBot 的平台和一个不支持的平台），遇到不支持的平台时代码会通过 continue 跳过，但只要 OneBot 平台发送成功，函数就会返回 True。外部的 _dispatch_pending 接收到 True 后，便不会触发 _send_images_batch 进行降级发送。这将导致所有不支持 OneBot 协议的平台被静默忽略，永远收不到被合并的资讯或图片。应针对各个具体的 bot 实例分别记录发送状态并处理降级。
  • 框架过度耦合：代码中强依赖底层方法如 bot.send_group_msg 和 bot.call_action。AstrBot 提供跨平台的消息发送能力，直接调用底层平台特定方法会破坏多平台兼容性，在非 OneBot 平台运行时会导致抛出 AttributeError 或方法签名不匹配异常。
• 安全漏洞与最佳实践:
  • 未发现明显的安全漏洞。
  • User-Agent 与 Referer 被硬编码在代码中。虽然在抓取官方接口时很常见，但若未来接口封禁该固定 UA，维护起来会比较麻烦，建议将其也放入 config 中进行管理。
• 可维护性与可读性:
  • 异常捕获策略细致，区分了 aiohttp.ClientError 与常规异常，并且使用 traceback.format_exc() 进行了详尽日志记录，可维护性较好。
  • 在异步死循环 while not self._shutdown 中，正确捕获并重新抛出了 asyncio.CancelledError，符合异步编程最佳实践。
• 潜在缺陷或问题:
  • Session 管理潜在隐患：_get_session 内部执行了 self._session = aiohttp.ClientSession()。虽然该方法大多在异步上下文被调用，但如果在非事件循环代码里误调用该方法，会导致 Session 绑定错误的 loop 并引发不可预测的异常。建议仅在 initialize() 等明确被框架挂载的异步生命周期内创建，或者使用 async with。

2. 框架适应性检查

• 日志记录: ✅ 合规。仅使用了从 astrbot.api 导入的 logger，未使用其他任何日志库或内置 logging。
• 并发模型: ✅ 合规。使用了异步 aiohttp 处理所有网络 I/O，并且包含恰当的 await asyncio.sleep()，没有发现任何阻塞事件循环的同步网络操作。
• 数据持久化: ✅ 合规。正确使用了 StarTools.get_data_dir(PLUGIN_NAME)，并且后续逻辑将其作为 pathlib.Path 对象处理，创建目录和文件的操作正确无误。

3. 针对 main.py 的额外审查要求

• 插件注册与主类: ✅ 合规。代码正确使用了 @register 装饰器，并且类 GenshinActivityCoverPlugin 正确继承了 Star，并包含带有 context 参数的 __init__ 初始化方法。
• filter 装饰器导入: ✅ 不适用/合规。本文件主要作为定时推送插件，未使用任何 @filter 事件监听相关的装饰器，故不存在命名冲突。
• LLM 事件钩子: ✅ 不适用。无。
• 通用事件监听器签名: ✅ 不适用。无。
• 消息发送方式: ✅ 不适用。未触及禁止使用 yield 的特殊钩子。

4. 代码评审团

Linus Torvalds：
你看过你写的这段 _do_send_forward 吗？你用一个全局的 sent_any 变量来判断合并转发是否成功。如果你的系统里挂着两个不同的平台，一个是 OneBot，一个不是，你的 OneBot 平台发送成功了，返回了 True，然后非 OneBot 平台就被你直接丢进黑洞里了！它连降级逐条发送的机会都没有！你不能用一个宏观状态去掩盖微观的失败，这简直是灾难性的逻辑泄漏。还有，直接调用 bot.send_group_msg 这种底层方法，把多平台框架的抽象层按在地上摩擦，实在不够优雅。

诸葛亮：
夫为将者，当未雨绸缪。此代码中轮询之法虽善，亦能在循环中不忘放还 CancelledError，深谙异步之机巧，实属难得。然将军于 _get_session 之中随手实例化 aiohttp.ClientSession()，虽眼下暂无大碍，若日后偶在事件循环之外唤起，恐生“Event loop is closed”之异变。宜在 initialize 之内一以贯之，方为万全之策。且那硬编码之 User-Agent，犹如明火执仗，若敌方（接口方）设伏，极易被识破，纳入锦囊（配置文件）岂不美哉？

雷军：
同学们，我们写代码也是要讲究“用户体验”的对不对？你这个 self._cfg 去获取配置数据的方法写得很清爽，可是你想过没有，万一用户在填写 YAML 或 JSON 配置文件的时候，把 forward_threshold_images 的 4 不小心加上了引号，变成了字符串 "4" 呢？你在 _dispatch_pending 里面直接拿去跟 len 的结果做大小对比，这程序直接就崩了呀！在这里顺手加一个 int() 转换，或者用更强类型的解析，容错性绝对大大提升，把问题拦截在跑起来之前，Are you OK？

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：galaxy-b612/astrbot-plugin-genshin-activity-cover
剩余触发次数：1

[galaxy-b612]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_genshin_activity_cover

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

main.py

代码评审团

Linus Torvalds：（揉了揉眉心，叹了口气）
我们来谈谈你对变量和字典的理解。在 _try_forward_to_group 里，你写了 sn = self._forward_sender_name 和 su = self._sender_uin，然后呢？然后你就把它们晾在那儿了！你根本没在这个方法里用到它们，真正用到它们的地方在底下的 _build_forward_nodes。留着这种毫无用处的本地变量，是为了给垃圾回收器增加工作量吗？
还有，看看 _extract_images 里的这行：for u in post.get("images", []) or []:。你知道自己在干什么吗？如果你只是怕字典里 "images" 键的值是 None，写成 post.get("images") or [] 就足够了。现在的写法就像是一个人穿了背带裤还要再系一根皮带，纯粹的冗余。

GlaDOS：（摄像头转动，散发出冷幽幽的蓝光）
哦，看看这段 _do_batch_to_group 里的 bot.send_group_msg(group_id=gid, message=msg)。你是如此自信地认为，每一个接入 AstrBot 的平台都恰好是 OneBot，并且恰好拥有一个名为 send_group_msg 的方法。
你在合并转发的时候还知道聪明地用 hasattr(bot, "call_action") 做个检查，怎么到了批量发送的“降级方案”里，就开始盲目调用了？当用户接入 Telegram 或者官方 QQ 机器人，因为找不到这个方法而导致整个发送任务抛出 AttributeError 异常时，我会在旁边为你鼓掌的。建议你加上 hasattr 检查，或者使用框架更通用的跨平台发送抽象——如果你们人类的大脑还能处理这种程度的容错机制的话。

Steve Jobs：（双手合十，目光锐利）
伟大的产品不应该有无法解释的“黑盒”逻辑。在你的 _poll_activity_covers 协程里，第一行就是 await asyncio.sleep(30)。为什么是 30 秒？这 30 秒的等待缺乏上下文，破坏了代码的美感。
还有 _delayed_start 里面的 max_wait = 120。这些都是所谓的“魔法数字”（Magic Numbers）。如果网络环境差导致初始化需要更久呢？你应该把它们抽离出去，或者至少放到类的顶部作为常量甚至是可以通过 self._cfg 让用户在配置中自定义的选项。不要把硬编码的数字散布在优美的异步循环体里，这让代码显得粗糙。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：galaxy-b612/astrbot-plugin-genshin-activity-cover
剩余触发次数：0