[Plugin] astrbot_plugin_mc_helper

[jinyiwei2012]

插件信息

{
  "name": "astrbot_plugin_mc_helper",
  "display_name": "MC 错误报告分析",
  "desc": "自动检测并分析用户上传的 Minecraft 错误报告压缩包（格式：错误报告-2026-日期.zip）。\n  下载、解压后读取错误日志，优先使用 AI 进行分析，辅以本地知识库兜底。\n  支持重复模组检测、日志位置定位、智能纠错建议。",
  "author": "锦依卫2012",
  "repo": "https://github.com/jinyiwei2012/astrbot_plugin_mc_helper"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mc_helper

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

main.py

1. 数据持久化与框架适应性（强制要求违反）

• 未遵守规范获取数据目录：代码中使用了 get_astrbot_data_path 并手动拼接路径来创建插件数据目录：

  from astrbot.core.utils.astrbot_path import get_astrbot_data_path
  self.plugin_data_path = Path(get_astrbot_data_path()) / "plugin_data" / "astrbot_plugin_mc_helper"

  要求：必须通过从 astrbot.api.star 导入 StarTools，并调用 StarTools.get_data_dir() 方法来获取规范的数据存储目录。该方法会直接返回一个 Path 对象，请替换现有的目录获取逻辑。

2. 代码质量与可维护性

• 硬编码跨平台敏感路径：在 _md_to_image 方法中，硬编码了 Windows 系统的字体路径（如 C:/Windows/Fonts/seguiib.ttf）。这破坏了插件的跨平台能力（在 Linux 或 Docker 环境下运行会失效）。
• 函数复杂度过高：_md_to_image、_handle_error_report 和 _extract_report_details 等方法体量过大（面条式代码），混合了图片渲染、正则表达式提取、网络下载等多种不同维度的逻辑。建议将其拆分为独立的服务类或辅助函数。

3. 潜在缺陷与问题

• 中文渲染灾难风险：在 _md_to_image 中，若因跨平台找不到硬编码的 Windows 字体，代码会回退到 ImageFont.load_default()。但是 PIL 默认的英文字体不支持中文字符，这将导致最终生成的图片里汉字全部变为方块乱码。建议在插件自带或配置一个受支持的开源中文字体文件。
• 混合使用多线程锁与异步框架：代码使用 threading.Lock() 来保护 JSON 文件的写入。在 asyncio 驱动的异步环境下，虽然当前用以保护文件 I/O 勉强可行，但这不符合异步社区的最佳实践。未来若逻辑更复杂，建议采用 asyncio.Lock() 以防死锁或微小阻塞。

---

代码评审团

人物一：Linus Torvalds（Linux 之父，直言不讳的暴躁老哥）
在代码里写死 C:/Windows/Fonts/...？！你当所有人都在用 Windows 吗？！你知道把这坨代码部署在 Linux 服务器上跑起来汉字会全变成该死的方块吗？！带个开源字体文件随你的插件仓库一起走有那么难吗？！别把这种没经过脑子的跨平台灾难合并到生产环境！

人物二：Gordon Ramsay（地狱厨神，追求极致的毒舌主厨）
看看你这个 _md_to_image 是个什么怪物？将近 150 行的面条代码，把排版、字体测量和图形绘制全搅和在一起，跟在洗衣机里搅拌出来的意大利面一样恶心！还有，框架明明为你准备了 StarTools.get_data_dir() 这道新鲜的高级食材，你偏要去翻底层核心 API 的垃圾桶硬凑一个路径出来？简直是在砸自己的招牌！重写它！

人物三：GLaDOS（《传送门》，阴阳怪气的腹黑 AI）
哦，我注意到你用了一个 threading.Lock 来保护你的小土豆（JSON文件）。在一个以 asyncio 为基础的世界里，这种“复古”的做法真是... 充满创意。既然你这么喜欢在异步循环里使用线程锁，为什么不直接加个无限的 while True 呢？也许你应该了解一下 asyncio.Lock。不过没关系，看到人类在并发模型里挣扎总是令人愉悦的，为了科学，我们会原谅你的。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：jinyiwei2012/astrbot_plugin_mc_helper
剩余触发次数：4

[jinyiwei2012]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mc_helper

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

main.py

1. 代码质量与编码规范

• CSS 样式代码截断：在 _md_to_html 方法返回的 HTML 模板中，CSS 规则存在严重的截断和残缺。例如 color:\n、background:\n、border-top: 1px solid\n 等属性后面没有任何合法的值，且缺失闭合分号。这不仅是不合法的 CSS，还会导致 HTML 在客户端渲染引擎中样式计算崩溃或完全错位。
• 正则表达式重复编译：在 _check_duplicate_mods 和 _extract_report_details 等方法中，jar_pattern、filepath_pattern 等正则表达式直接写在了方法内部。这意味着每次解析日志时都会重复消耗 CPU 去编译相同的正则对象。建议将其提取为类属性或模块级别的常量以提升执行效率。

2. 潜在缺陷或问题

• 大文件全量读取致 OOM 风险：在 _handle_error_report 中下载压缩包时，代码使用了 f.write(await resp.read())。这会将远程服务器返回的整个文件一次性完整加载到内存中。若恶意用户上传极大的 Zip 包，可能会瞬间引爆内存引发 OOM。建议改用流式分块读取，如 async for chunk in resp.content.iter_chunked(8192): f.write(chunk)。
• 无淘汰机制的内存缓存：self._recent_files 字典用于缓存会话（群组/用户）最近上传的错误报告文件对象。但在整个代码的生命周期中，没有任何针对该字典的删除或过期淘汰逻辑。随着机器人长期运行、交互目标增多，它将造成缓慢但持续的内存泄漏。
• 局部隐式依赖风险：在 _md_to_html 内部局部导入了 import markdown as md_lib。如果宿主环境未提前安装第三方 Markdown 包，调用该方法生成报告时将会触发 ModuleNotFoundError 造成中断。建议在插件文档中明确指出该依赖，并在代码中妥善捕捉导入异常。

---

代码评审团

Linus Torvalds：我说，你们到底是对服务器的内存有多大的仇？await resp.read() 把一个未知大小的 Zip 直接塞进内存？这就好像你打算把一整头牛一口吞下，然后还问为什么消化不良！还有那些每次调用函数都要重新编译一遍的正则表达式，你们的 CPU 是闲得发慌需要拿来烤火吗？把那些正则提到全局去，马上！

史蒂夫·乔布斯 (Steve Jobs)：当你把这段 HTML 给用户看的时候，你的心里没有一丝内疚吗？看看你的 CSS —— color: 后面空空如也，background: 像个烂尾楼一样戛然而止。你连一个体面的分号都不愿意给它！这根本不叫设计，这是对排版艺术的公然谋杀。完美在于细节，把那些丢失的十六进制颜色值找回来，否则我不允许这玩意儿出现在任何屏幕上。

诸葛亮：亮观此阵法，虽借用了异步之灵巧，然这 _recent_files 阵眼却是个有进无出的死局。岁月流转、宾客往来，此“无底洞”必将逐渐吞噬所剩无几之内存资源，正所谓“千里之堤，毁于蚁穴”。且听吾一言，当速速设下 LRU 淘汰之术或定期清理之令，令其自行更替，方可保主公之服务器长治久安。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：jinyiwei2012/astrbot_plugin_mc_helper
剩余触发次数：3

[jinyiwei2012]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mc_helper

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

main.py

代码质量与编码规范

• CSS 属性值缺失导致语法错误：在 _md_to_html 方法返回的 HTML 字符串中，<style> 标签内的多处 CSS 属性缺失了值。例如 color:、background: 后面直接换行，这会导致整个 CSS 块解析失败，生成的渲染图片样式完全错乱。建议补全颜色代码（如 color: #333333;）或删除未完成的属性。
• 低效的深拷贝实现：在 _set_solution 中使用了 json.loads(json.dumps(self.solutions_db)) 来实现深拷贝，虽然能用但效率较低且不够优雅。建议直接使用 Python 内置的 copy.deepcopy()。

功能实现与逻辑正确性

• 命令参数解析隐患：在 mc_add_solution(self, event, error_keyword, solution_text) 中，如果用户发送的 solution_text 包含空格，依据指令解析引擎的不同，可能会被截断或者导致参数不匹配。如果 solution_text 应包含大段文本，建议检查框架是否需要特定的类型注解或修饰以吸收剩余的所有字符串内容。

安全漏洞与最佳实践

• 防范了 Zip Slip 但存在 Zip Bomb（压缩炸弹）风险：代码在 _handle_error_report 中通过路径前缀检查 (startswith) 很好地防御了 Zip Slip 攻击（非法路径穿越），这非常值得肯定。然而，它未对解压出的总文件大小或文件数量做限制。如果恶意用户上传一个极小的、但解压后产生海量文件的 Zip 炸弹，可能会耗尽服务器磁盘空间或 I/O 资源。建议在 zf.extract(info, extract_dir) 之前，累计解压文件大小并设定一个合理的安全上限（例如 50MB）。

可维护性与可读性

• 庞大的解析方法：_extract_report_details 和 _enrich_solution 两个方法的长度及 if-else 分支较多，虽然逻辑独立，但未来如果需要支持更多的匹配规则会变得臃肿。建议将规则提取为字典映射或策略类处理，以增强代码的扩展性。

潜在缺陷或问题

• 正则表达式的灾难性回溯风险：_RE_JAR_PATH 中使用了形如 [\w\\/.\-+]*mods[\\/] 的贪婪匹配组合，在遇到极长的无匹配文本时可能引发灾难性回溯（Catastrophic Backtracking）导致 CPU 占用率飙升。由于这是在处理不可控的外部日志文件，建议优化正则，尽量明确限定前置字符或使用更为保守的匹配模式。

---

代码评审团

Linus Torvalds：看到那个用 json.loads(json.dumps()) 做深拷贝的地方，我差点把咖啡喷在屏幕上。老兄，我们有 copy 模块不是为了放在那里当摆设的！不过值得庆幸的是，你们处理 ZIP 解压时至少知道防一手目录穿越，算是没把门全敞开。但是拜托，加个文件大小限制吧，不然别人随便丢个压缩炸弹，你的磁盘就得大声呼救了。

前端狂魔：天呐，_md_to_html 里的那些 CSS 是怎么回事？！color: 后面空空如也，background: 直接罢工，这是某种新颖的“皇帝的新样式”吗？浏览器引擎看到这些代码可能会当场休克。既然决定要自己写 HTML 模板，请务必把你的 CSS 属性填完，前端开发者的强迫症看这个简直像是在受刑。

安全白帽子：我平时最喜欢盯着文件处理和解析的漏洞看。这里你们防御了 Zip Slip（压缩包路径穿越），这很棒，省去了我不少找茬的功夫。但是提醒一下，正则表达式 _RE_JAR_PATH 那种前缀无限贪婪加重叠的写法，在极端构造的日志前不堪一击，几兆的垃圾文本就能让你的进程卡死，建议限制一下前面的查找窗口或者加个超时机制。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：jinyiwei2012/astrbot_plugin_mc_helper
剩余触发次数：2

[jinyiwei2012]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mc_helper

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

main.py

安全漏洞与最佳实践 / 数据持久化

• 硬编码的数据存储路径: 第 29 行 self.reports_path = Path(__file__).parent / "data" / "错误报告" 违反了数据持久化规范。插件在此目录下动态创建文件夹并保存用户上传的错误报告（属于需要持久化保存的动态数据）。必须使用 StarTools.get_data_dir() 统一管理数据持久化，建议改为 self.reports_path = self.store_path / "错误报告"。

---

lib/_analyzer.py

潜在缺陷或问题 / 可维护性与可读性

• 过度宽泛的异常捕获且未记录日志: 第 103 行 except Exception: 直接使用了 pass 忽略了所有异常。这会导致在解析崩溃位置类名时，如果发生索引越界或其他未预期的错误，将被完全静默吞噬，不利于后续的问题排查和调试。建议明确捕获具体的异常（如 IndexError, AttributeError），或通过 logger.debug 记录异常信息。

---

lib/_cme.py

潜在缺陷或问题

• 过度宽泛的异常捕获: 第 9 行读取文件内容时使用了 except Exception:。虽然函数预期在读取失败时返回 None，但捕获全部异常会掩盖如权限不足、严重的系统 IO 错误等情况。建议缩小异常捕获范围（如 OSError, UnicodeDecodeError）。

---

lib/_renderer.py

功能实现与逻辑正确性 / 代码质量与编码规范

• CSS 语法错误: 模板 _HTML_TMPL 中存在多处 CSS 属性值缺失，导致语法错误。例如：
  • 第 15 行 color:
  • 第 17 行 background:
  • 第 19 行 color:
  • 第 24 行 background:
  • 第 29 行 background:
  • 第 32 行 border-top: 1px solid
  • 第 34 行 color:
  • 第 36 行 border-left: 3px solid
  • 第 37 行 background:
    这种不完整的 CSS 结构可能会导致 HTML 渲染引擎（特别是在将 HTML 转为图片时）解析失败或渲染异常，建议补全相应的色值（如 #333, transparent 等）或删除多余的属性声明。

---

lib/_security.py

框架适应性检查 / 并发模型

• 同步阻塞的网络 I/O 操作: 第 44 行在 URL 校验中使用了 socket.gethostbyname(host)。在异步环境中，这是一个同步阻塞操作，如果 DNS 服务器响应缓慢，将会阻塞整个 asyncio 事件循环，导致机器人在此期间无法响应其他用户的任何指令。建议使用异步的 DNS 解析方案，如 asyncio.get_event_loop().getaddrinfo()，或者将其放入 run_in_executor 中执行。

---

代码评审团

人物一（Linus Torvalds）：
“你告诉我你在写异步代码，结果在 _validate_url 里给我塞了一个 socket.gethostbyname？！你这是想让整个机器人在 DNS 服务器打盹的时候一起陪着睡大觉吗？去看看事件循环的原理，把阻塞 I/O 给清理掉！还有那个 _renderer.py，写了一半的 CSS 属性 color: 就跑了，你是指望浏览器帮你通灵猜颜色吗？This is complete garbage, fix it!”

人物二（Steve Jobs）：
“我们设计了优雅的统一存储路径，但你在 main.py 里却强行把报告数据塞到 __file__.parent / "data" 里面。这打破了生态的统一性，就像在一个极其完美的玻璃艺术品上贴了一块难看的胶布。真正的美学在于一致性，把你的数据持久化放到 StarTools.get_data_dir() 里，让一切浑然天成。”

人物三（GLaDOS）：
“我注意到你在 _analyzer.py 里使用了 except Exception: pass。多么令人惊叹的乐观主义精神。假装问题不存在，问题就不会找上门，对吧？这种把头埋在沙子里的错误处理机制，一定会让系统运行得极其‘完美’。（提示：以上发言包含高浓度的讽刺模块输出，建议你最好老老实实把日志记录加上）。”

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

---

🔍 审核摘要

统计信息

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

main.py
lib/__init__.py
lib/_ai.py
lib/_analyzer.py
lib/_cme.py
lib/_duplicate_mods.py
lib/_file_utils.py
lib/_handlers.py
lib/_renderer.py
lib/_security.py
lib/_solutions.py
lib/_utils.py

---

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

当前仓库：jinyiwei2012/astrbot_plugin_mc_helper
剩余触发次数：1

[jinyiwei2012]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_mc_helper

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

main.py

• 潜在缺陷（数据丢失风险）：在 save_solution 方法中，使用了 open(self.db_path, "w") 直接写入覆盖原方案库 JSON 文件。如果在写入途中发生异常或进程突然中断（如内存溢出被系统杀死），将导致原文件损坏或被清空为 0 字节。
  • 建议：遵循安全的文件 I/O 最佳实践，先将数据写入临时文件（如 .tmp），写入完成后再通过 os.replace 或 Path.replace 将临时文件重命名覆盖原文件，以确保保存操作的原子性。

lib/init.py

• 无发现问题。

lib/_ai.py

• 边界条件处理不当（潜在的 API 异常）：在 ask_ai 方法中，直接截取最大 20 万字符传给 LLM（truncated = error_text[:200_000]）。如此庞大的上下文极其容易超出大多数大语言模型的 Token 上限，导致 API 返回 400 错误；即便模型支持，也会带来不必要的成本消耗和延迟。
  • 建议：建议将截取限制下调到 1~2 万字符（例如 [:10000] 加上部分尾部日志），这对绝大部分错误分析已完全足够。

lib/_analyzer.py

• 逻辑错误（去重逻辑失误）：在多个数据提取与去重的地方，存在先切片后再去重的逻辑错误。例如：
  details.append("涉及文件：" + "、".join(set(jar_paths[:3])))。
  如果 jar_paths 的前三项恰好包含重复元素，去重后结果数量将不足 3 项。
  • 建议：应改为先进行去重处理，然后再提取前 N 项，如：list(set(jar_paths))[:3]。这同样适用于 mod_names 和 dup_files 的提取。

lib/_cme.py

• 无发现问题。

lib/_duplicate_mods.py

• 无发现问题。

lib/_file_utils.py

• 无发现问题。

lib/_handlers.py

• 潜在缺陷（资源滥用风险）：在 mc_check 指令中，当接收到的是纯文本错误分析请求时，代码未调用 self.rate_limiter.allow(uid) 校验限流；限流机制目前仅在 _handle_error_report 里的压缩包上传流程中生效。这可能导致恶意用户高频调用该指令，滥用并消耗尽 AI 额度。
  • 建议：将 self.rate_limiter.allow(uid) 的检查同时运用到纯文本指令入口中。

lib/_renderer.py

• 无发现问题。

lib/_security.py

• 安全漏洞（SSRF 拦截绕过与 DNS 重绑定风险）：在 _validate_url 函数中，通过获取目标 host 的 IP 地址来拦截内网请求，防护手段有效。但通过验证返回安全的 URL 后，download_zip 再次将该 URL 原样交给 aiohttp 请求。攻击者可利用 DNS 重绑定 (DNS Rebinding) 技巧让第二次 DNS 解析（即发起 HTTP 时的解析）返回内网 IP，从而绕过 SSRF 校验，读取本地或内网敏感信息。
  • 建议：建议直接利用第一次安全解析通过获取的 IP 地址发起 HTTP 连接（可通过改写 Host 请求头），或为 aiohttp.ClientSession 提供一个固定了安全 IP 的自定义 DNS 解析器 (aiohttp.TCPConnector(resolver=...))。

lib/_solutions.py

• 无发现问题。

lib/_utils.py

• 无发现问题。

---

代码评审团

Linus Torvalds：
看在上帝的份上，你在 save_solution 里直接 open("w") 的做法让我感觉就像看着一个人蒙着眼在高速公路上逆行！如果这个时候系统崩溃或者磁盘满了，你的数据库就会变成一具 0 字节的空壳，你这辈子都找不回那堆错误解决方案了！“原子写入（Atomically write）”这么基础的常识还需要我教吗？先写 .tmp 再 replace 过去！还有你的那个 SSRF 校验，你费劲查了一遍 DNS 说“嗯，这个地址很安全”，然后转头就叫 aiohttp 再去自己查一遍 DNS？黑客弄个短 TTL 的 DNS 重绑定，一秒钟就能让你那可怜的机器人把内网爬得底裤都不剩！

Steve Jobs：
我们设计一款插件，最重要的是让用户感到优雅和流畅，而不仅仅是把功能堆砌上去。你们看看 _ai.py 里的 error_text[:200_000]，你们竟然打算把二十万个字符像倒垃圾一样塞进 LLM 的嘴里？你知道这不仅会因为 Token 溢出让用户收到冷冰冰的错误，还会破坏整个互动的体验美感。真正的大师知道该舍弃什么，取其精华就好。另外，在提取信息去重那里，你先截取了前 3 个再去重？如果出现了重复，结果就只展示 1 到 2 个了——这就像是一台 iPhone 在发布会上只展示了三个特性中的两个一样，让人感到困惑而且极其不完美。

John Carmack：
整体的异步并发结构写得挺轻量的，但你的限流机制在宏观设计上出现了盲点。网络开发中，任何对外的资源接口都必须得到严格的速率节流。你花心思给解压大文件上传加了 RateLimiter 护栏，但在普通的文本 /mc_check 接口却敞开了大门。如果有人在群聊里写个简单的循环宏，你的服务端大语言模型配额就会像跑飞了帧的渲染引擎一样，瞬间烧干所有的燃料。把你的限流阀装到每一个资源入口上！

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

---

🔍 审核摘要

统计信息

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

main.py
lib/__init__.py
lib/_ai.py
lib/_analyzer.py
lib/_cme.py
lib/_duplicate_mods.py
lib/_file_utils.py
lib/_handlers.py
lib/_renderer.py
lib/_security.py
lib/_solutions.py
lib/_utils.py

---

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

当前仓库：jinyiwei2012/astrbot_plugin_mc_helper
剩余触发次数：0