[Plugin] astrbot_plugin_mcbe_news

[YueHua46]

插件信息

{
  "name": "astrbot_plugin_mcbe_news",
  "display_name": "MCBE 更新监控与 AI 总结插件",
  "desc": "定时监控 Minecraft 基岩版官方更新，自动使用 AI 总结并推送到群聊，支持 Beta 和正式版",
  "author": "Yuehua",
  "repo": "https://github.com/YueHua46/astrbot_plugin_mcbe_news",
  "tags": [
    "MC",
    "我的世界",
    "我的世界基岩版",
    "MCBE"
  ],
  "social_link": "https://github.com/YueHua46"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mcbe_news

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

main.py

代码质量与编码规范

• 存在未使用的导入：MessageEventResult、re 未被使用（会增加噪音，也可能触发静态检查告警）。
• 类型标注不一致/不精确：
  • _fetch_articles 返回 List[tuple]、_process_new_articles 参数 List[tuple] 都过于宽泛；实际是 List[tuple[Article, str]]（可读性与维护性变差）。
  • registered_groups: dict 建议至少标注为 dict[str, str]（当前存的是 group_id -> unified_msg_origin）。
• 异常处理过宽：多处 except Exception as e 直接吞掉细节，仅记录日志。对可预期异常（如网络超时、HTTP 状态码、JSON 解析）建议分层处理，否则定位问题成本高。

功能实现与逻辑正确性

• 图片去重逻辑存在缺陷，可能发送重复图片：
  _extract_content_with_images 中用 processed_imgs 去重，但“去重判断发生在 URL 归一化之前”。例如同一图片先以 "/path" 形式出现（figure 分支），你会在追加前检查 "/path" not in processed_imgs 成立；随后将其归一化为 "https://feedback.minecraft.net/path" 并加入集合。之后在遍历到独立 img 标签时，src 仍是 "/path"，再次判断 "/path" not in processed_imgs" 仍成立，从而重复发送。
  影响：同一图片在消息中重复出现，且日志显示“添加图片”次数异常。
• 定时任务可能重入并发执行，导致重复推送/状态竞争：
  apscheduler 默认允许同一个 job 在上一次未结束时再次触发（取决于配置）。你的 _check_updates 内会修改共享状态（self.seen_article_ids、写 JSON），若并发运行，可能出现：
  • 同一文章被重复判定为“新文章”并发送多次
  • seen 文件写入时序竞争导致丢数据/覆盖
    （建议通过 add_job(..., max_instances=1, coalesce=True) 或在 _check_updates 内部加 async 锁。）
• 群聊 origin 生成可能不符合框架规范，导致发送失败：
  _send_to_groups 中用 unified_msg_origin = f"group_{group_id}" 猜测 origin 格式；但你在注册模式下保存的是 event.unified_msg_origin（通常包含平台/适配器信息）。这两种格式可能不兼容，导致“配置 group_ids 方式”在某些适配器下不可用或不稳定。
• 首次运行逻辑的“首次”判定较脆弱：
  self.is_first_run = not self.seen_articles_file.exists() 仅以文件存在与否判断。如果文件存在但内容损坏/空（加载失败返回空 set），会被当作“非首次运行”，从而把历史文章都当成“新文章”推送（潜在刷屏）。
• LLM 输入未截断，可能导致超长请求失败或成本飙升：
  _summarize_article 中 truncated_text = article_text 实际没有任何截断/限长处理；遇到超长正文时，可能触发：
  • 提供商最大 token 限制报错
  • 请求时间明显变长，甚至卡住定时任务
  • 成本不可控

安全漏洞与最佳实践

• 数据持久化路径硬编码（框架适应性问题，属于规范要求）：
  使用了 Path("data/mcbe_news")。按照审查要求，应使用 StarTools.get_data_dir() 获取规范目录（data/plugin_data/<plugin_name>），避免在不同部署方式下路径不一致、权限问题、以及多插件数据混杂。
• 对外部内容缺少“输出边界控制”：
  文章正文会被完整解析并发送（图片最多 10 张，但文本部分未限制）。当文章内容很长时，可能导致消息过长被平台拒收或触发风控（这属于可靠性/可用性风险）。

可维护性与可读性

• 方法职责偏大：_check_updates / _process_new_articles / _create_article_message 同时处理拉取、去重、持久化、LLM、拼装消息、发送；后续扩展（分页、指定文章、失败重试）会变得更难测试和维护。
• 注册/反注册的 group_id 解析逻辑不清晰且含裸 except：
  mcbe_register 里对 unified_msg_origin 的解析规则不明确，还存在裸 except: pass，会掩盖真实解析错误，导致存入的 key 不可预期（例如把整段 origin 当 group_id）。

潜在缺陷或问题（异步环境）

• 网络 I/O 的健壮性不足（只指出网络相关）：
  所有 HTTP 请求都未设置重试策略；一旦短暂网络抖动，定时检查就直接失败并等待下个 cron。对于“监控类”插件，这会造成漏报/延迟明显。

main.py 专项框架检查

• filter 的导入方式正确：from astrbot.api.event import filter（避免与内置 filter 冲突的问题已规避）。
• 插件主类继承 Star 满足要求。
• @register(...) 使用符合允许格式（四参）。但注意：如果运行环境属于“自动识别 Star 子类”的模式，继续使用装饰器可能带来重复注册/加载行为风险（取决于框架加载器实现）。此处属于兼容性隐患点。
• 未实现 on_llm_request/on_llm_response 等钩子，因此不存在“钩子里禁止 yield”的违规点。

---

models.py

代码质量与编码规范

• PEP 8 空行不足：导入与类定义之间缺少标准的空行分隔（可读性下降）。
• 类型/字段健壮性不足，易触发校验失败：
  你把大量字段定义为必填且为非 Optional（如 edited_at: datetime、outdated_locales: List[str]、user_segment_ids: List[int] 等）。但这类第三方 API 字段在实际响应中经常出现 null 或缺失；一旦发生，model_validate 会直接抛异常，导致整个抓取失败。
  影响：插件在 API 某次返回字段缺失/变更时，会“全量不可用”（而不是降级运行）。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你这图片去重写得像“我觉得差不多就行”。URL 归一化前后不一致，重复图片这种低级 bug 迟早让用户怀疑人生。把 URL 统一成绝对地址后再去重，这是基本功；别让集合背锅。

人物二（Grace Hopper，偏工程可靠性与可调试性）：
到处 except Exception 再打个日志就算完，这会让线上故障变成“玄学”。至少把 HTTP 错误、解析错误、LLM 错误分开处理，并记录关键上下文（请求 URL、文章 id、响应片段/状态码）。监控类程序最怕的就是“失败但不说清楚为什么”。

人物三（Guido van Rossum，关注可读性与结构）：
核心流程揉在一起了：拉取、判重、总结、拼消息、发送、落盘都耦合在同一条链路。建议把“状态管理（seen/registered）”“抓取层（API）”“渲染层（message components）”拆开，这样你以后要加“分页”“指定 id 查询”“失败重试”不会改一处炸三处。

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

---

🔍 审核摘要

统计信息

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

main.py
models.py

---

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

[LDD123]

这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。

[YueHua46]

🤖 AI代码审核报告 for astrbot_plugin_mcbe_news

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

main.py

代码质量与编码规范

• 存在未使用的导入：MessageEventResult、re 未被使用（会增加噪音，也可能触发静态检查告警）。

• 类型标注不一致/不精确：

  • _fetch_articles 返回 List[tuple]、_process_new_articles 参数 List[tuple] 都过于宽泛；实际是 List[tuple[Article, str]]（可读性与维护性变差）。
  • registered_groups: dict 建议至少标注为 dict[str, str]（当前存的是 group_id -> unified_msg_origin）。

• 异常处理过宽：多处 except Exception as e 直接吞掉细节，仅记录日志。对可预期异常（如网络超时、HTTP 状态码、JSON 解析）建议分层处理，否则定位问题成本高。

功能实现与逻辑正确性

• 图片去重逻辑存在缺陷，可能发送重复图片：
  _extract_content_with_images 中用 processed_imgs 去重，但“去重判断发生在 URL 归一化之前”。例如同一图片先以 "/path" 形式出现（figure 分支），你会在追加前检查 "/path" not in processed_imgs 成立；随后将其归一化为 "https://feedback.minecraft.net/path" 并加入集合。之后在遍历到独立 img 标签时，src 仍是 "/path"，再次判断 "/path" not in processed_imgs" 仍成立，从而重复发送。
  影响：同一图片在消息中重复出现，且日志显示“添加图片”次数异常。

• 定时任务可能重入并发执行，导致重复推送/状态竞争：
  apscheduler 默认允许同一个 job 在上一次未结束时再次触发（取决于配置）。你的 _check_updates 内会修改共享状态（self.seen_article_ids、写 JSON），若并发运行，可能出现：

  • 同一文章被重复判定为“新文章”并发送多次
  • seen 文件写入时序竞争导致丢数据/覆盖
    （建议通过 add_job(..., max_instances=1, coalesce=True) 或在 _check_updates 内部加 async 锁。）

• 群聊 origin 生成可能不符合框架规范，导致发送失败：
  _send_to_groups 中用 unified_msg_origin = f"group_{group_id}" 猜测 origin 格式；但你在注册模式下保存的是 event.unified_msg_origin（通常包含平台/适配器信息）。这两种格式可能不兼容，导致“配置 group_ids 方式”在某些适配器下不可用或不稳定。

• 首次运行逻辑的“首次”判定较脆弱：
  self.is_first_run = not self.seen_articles_file.exists() 仅以文件存在与否判断。如果文件存在但内容损坏/空（加载失败返回空 set），会被当作“非首次运行”，从而把历史文章都当成“新文章”推送（潜在刷屏）。

• LLM 输入未截断，可能导致超长请求失败或成本飙升：
  _summarize_article 中 truncated_text = article_text 实际没有任何截断/限长处理；遇到超长正文时，可能触发：

  • 提供商最大 token 限制报错
  • 请求时间明显变长，甚至卡住定时任务
  • 成本不可控

安全漏洞与最佳实践

• 数据持久化路径硬编码（框架适应性问题，属于规范要求）：
  使用了 Path("data/mcbe_news")。按照审查要求，应使用 StarTools.get_data_dir() 获取规范目录（data/plugin_data/<plugin_name>），避免在不同部署方式下路径不一致、权限问题、以及多插件数据混杂。
• 对外部内容缺少“输出边界控制”：
  文章正文会被完整解析并发送（图片最多 10 张，但文本部分未限制）。当文章内容很长时，可能导致消息过长被平台拒收或触发风控（这属于可靠性/可用性风险）。

可维护性与可读性

• 方法职责偏大：_check_updates / _process_new_articles / _create_article_message 同时处理拉取、去重、持久化、LLM、拼装消息、发送；后续扩展（分页、指定文章、失败重试）会变得更难测试和维护。
• 注册/反注册的 group_id 解析逻辑不清晰且含裸 except：
  mcbe_register 里对 unified_msg_origin 的解析规则不明确，还存在裸 except: pass，会掩盖真实解析错误，导致存入的 key 不可预期（例如把整段 origin 当 group_id）。

潜在缺陷或问题（异步环境）

• 网络 I/O 的健壮性不足（只指出网络相关）：
  所有 HTTP 请求都未设置重试策略；一旦短暂网络抖动，定时检查就直接失败并等待下个 cron。对于“监控类”插件，这会造成漏报/延迟明显。

main.py 专项框架检查

• filter 的导入方式正确：from astrbot.api.event import filter（避免与内置 filter 冲突的问题已规避）。
• 插件主类继承 Star 满足要求。
• @register(...) 使用符合允许格式（四参）。但注意：如果运行环境属于“自动识别 Star 子类”的模式，继续使用装饰器可能带来重复注册/加载行为风险（取决于框架加载器实现）。此处属于兼容性隐患点。
• 未实现 on_llm_request/on_llm_response 等钩子，因此不存在“钩子里禁止 yield”的违规点。

models.py

代码质量与编码规范

• PEP 8 空行不足：导入与类定义之间缺少标准的空行分隔（可读性下降）。
• 类型/字段健壮性不足，易触发校验失败：
  你把大量字段定义为必填且为非 Optional（如 edited_at: datetime、outdated_locales: List[str]、user_segment_ids: List[int] 等）。但这类第三方 API 字段在实际响应中经常出现 null 或缺失；一旦发生，model_validate 会直接抛异常，导致整个抓取失败。
  影响：插件在 API 某次返回字段缺失/变更时，会“全量不可用”（而不是降级运行）。

代码评审团

人物一（Linus Torvalds，毒舌但务实）： 你这图片去重写得像“我觉得差不多就行”。URL 归一化前后不一致，重复图片这种低级 bug 迟早让用户怀疑人生。把 URL 统一成绝对地址后再去重，这是基本功；别让集合背锅。

人物二（Grace Hopper，偏工程可靠性与可调试性）： 到处 except Exception 再打个日志就算完，这会让线上故障变成“玄学”。至少把 HTTP 错误、解析错误、LLM 错误分开处理，并记录关键上下文（请求 URL、文章 id、响应片段/状态码）。监控类程序最怕的就是“失败但不说清楚为什么”。

人物三（Guido van Rossum，关注可读性与结构）： 核心流程揉在一起了：拉取、判重、总结、拼消息、发送、落盘都耦合在同一条链路。建议把“状态管理（seen/registered）”“抓取层（API）”“渲染层（message components）”拆开，这样你以后要加“分页”“指定 id 查询”“失败重试”不会改一处炸三处。

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

🔍 审核摘要

统计信息

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

main.py
models.py

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

非常好审查，使我 cursor 旋转

[astrbot-plugin-copybara]

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

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