[Plugin] astrbot_plugin_upfanswatcher

[laopanmemz]

插件信息

{
  "name": "astrbot_plugin_upfanswatcher",
  "display_name": "astrbot_plugin_upfanswatcher",
  "desc": "b站up粉丝数定时推送",
  "author": "laopanmemz",
  "repo": "https://github.com/laopanmemz/astrbot_plugin_upfanswatcher",
  "tags": [
    "b站",
    "哔哩哔哩",
    "up",
    "监控",
    "粉丝"
  ],
  "social_link": "https://space.bilibili.com/447591776"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_upfanswatcher

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

main.py

1. 代码质量与编码规范

• 未定义的方法调用 (严重):

  • 代码中多次调用了 self.get_kv_data 和 self.put_kv_data (在 fans_compare 方法中)，但在 UPfansWatcher 类及其父类 Star 中并未定义这两个方法。这将导致 AttributeError，插件运行到此处会直接崩溃。
  • 建议: 需要在类中实现这两个方法。根据数据持久化规则，应使用 astrbot.api.star.StarTools.get_data_dir() 获取插件数据目录，并在其中读写 JSON 或数据库文件来保存粉丝数历史数据。

• 配置初始化缺失:

  • 在 task_run 方法中直接访问 self.config["uplist"]。如果用户初次安装插件，配置文件中可能没有 uplist 字段，这将导致 KeyError。
  • 建议: 在 initialize 或 __init__ 中检查 uplist 是否存在，不存在则初始化为空列表 []。或者在访问时使用 self.config.get("uplist", [])。

• 资源管理效率低:

  • get_upname 方法中，每次调用都实例化一个新的 aiohttp.ClientSession()。在并发任务较多时，这会产生巨大的 TCP 开销和性能浪费。
  • 建议: 应该在 initialize 中创建一个全局的 session (保存为 self.session)，在 terminate 中关闭它；或者使用 AstrBot 提供的共享 session (如果有)。

• PEP 8 规范:

  • import 排序混乱，标准库、第三方库和本地库混合。建议按照标准库、第三方库、本地库分组。

2. 功能实现与逻辑正确性

• 异步环境中的同步阻塞/错误调用 (严重):

  • get_upfans 方法中使用了 sync(u.get_relation_info())。bilibili_api 本身是异步库，其方法返回协程。在 async def (已经处于事件循环中) 内部调用 sync() (通常会尝试启动新的循环或阻塞等待) 是错误的，会导致 "RuntimeError: This event loop is already running" 或阻塞当前循环。
  • 建议: 直接 await u.get_relation_info()。

• 定时任务逻辑复杂且脆弱:

  • _run_periodic_tasks 中的时间计算逻辑非常复杂且难以维护（手动计算 total_minutes_since_midnight 等）。这种手动计算日期时间的方式容易在跨天、跨月或闰年时出现边界问题。
  • 建议: 考虑记录“上次运行时间戳”，在循环中检查 now - last_run >= interval，或者简化为 await asyncio.sleep(interval_minutes * 60) (虽然会有漂移，但对于粉丝数检查通常可接受)。

3. 安全漏洞与最佳实践

• 缺乏错误处理:

  • get_upname 进行网络请求时没有 try...except 块。如果 API 挂了或网络超时，未捕获的异常会向上冒泡，导致 _execute_single_task 失败，甚至可能影响整个 task_run 的稳定性。
  • 建议: 捕获 aiohttp.ClientError 和 json.JSONDecodeError。

• 数据持久化:

  • 既然需要比较粉丝数变化，就涉及数据持久化。目前代码完全缺失持久化实现（见第一点 get_kv_data）。
  • 建议: 引入 from astrbot.api.star import StarTools，使用 path = StarTools.get_data_dir(__name__) 获取路径，确保存储路径合规。

4. 可维护性与可读性

• 函数职责:
  • _run_periodic_tasks 承载了过多的时间调度逻辑，导致核心业务逻辑（执行任务）被深埋。

5. 潜在缺陷或问题

• 消息发送的 Session ID 依赖:
  • get_original_umo 依赖 event.message_obj.type.value。虽然在 AstrBot 事件中通常存在，但缺乏防御性编程。
• 任务并发风险:
  • 在 task_run 中使用 asyncio.gather 等待所有周期任务。如果其中一个周期任务抛出了未捕获的异常（尽管有 try-except，但仅包裹了 while 循环内部），可能会导致 gather 行为不可预测。目前的 try-except 放在 while 内部是正确的，但要注意 _execute_single_task 内部如果崩溃且未被捕获，会打断该时间组的后续任务。

---

代码评审团

Linus Torvalds:
“这简直就是一场灾难。你在 async 函数里用 sync() 包装器？这是想让 CPU 闲得发慌还是想让事件循环自杀？还有，self.get_kv_data 是什么鬼？如果是你自己脑补的方法，至少把它写出来。编译器不会读心术，我也不会。去把那些未定义的方法实现了，别让代码像个半成品的瑞士军刀，看着挺全，实际上一把刀都拔不出来。”

Steve Jobs:
“这代码缺乏‘灵魂’。看那个 _run_periodic_tasks 里的时间计算逻辑，太丑陋了，像是一堆乱七八糟的电线缠在一起。真正的工艺应该是优雅的、简单的。你每次请求网络都新建一个 Session，这就像每打一个电话就买一部新手机一样荒谬。为了用户体验，为了效率，请优化它。要让代码像艺术品一样流动，而不是磕磕绊绊。”

GLaDOS (Portal):
“检测到未定义的函数调用。这很有趣。由于你忘记了实现 get_kv_data，这个插件将在第一次运行时完美地崩溃。这或许是某种由于粉丝数下降而触发的自毁机制？非常聪明。还有，那个时间计算算法……我用了 0.003 秒分析了它，它的混乱程度仅次于人类的情感。继续保持，当你的服务器因为内存泄漏而着火时，记得叫我，我有蛋糕。”

---

🔍 审核摘要

统计信息

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

main.py

---

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

[laopanmemz]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_upfanswatcher

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

main.py

1. 代码质量与编码规范

存在的问题:

1. 命名不规范:

   • get_original_umo 函数名含义不明确，umo 是什么缩写？建议改为更有意义的名称，如 get_unique_message_origin
   • 变量名 ifequal 应改为 send_when_equal 或 notify_on_no_change 等更清晰的名称

2. 硬编码字符串:

   • "true", "false" 作为字符串在多处使用，应定义为常量或使用布尔类型

3. 代码重复:

   • get_original_umo(event) 在多个地方重复调用，可以在函数开始时保存到变量中

2. 功能实现与逻辑正确性

存在的问题:

1. 时间计算逻辑复杂且存在潜在问题:

   • _run_periodic_tasks 方法中的时间计算逻辑过于复杂，存在多个条件分支，容易出错
   • 跨天处理的逻辑有重复判断，可能导致某些边界情况下计算错误

2. 任务重启逻辑有缺陷:

   • 在 add 和 delete 方法中，取消所有任务后立即创建新任务，但没有等待旧任务完全取消
   • self.runtask.cancel() 后应该 await 等待取消完成

3. 缺少错误处理:

   • get_upfans 方法调用 bilibili_api 但没有异常处理
   • 如果 API 调用失败，整个任务会中断

3. 安全漏洞与最佳实践

存在的问题:

1. 并发模型问题 - 同步阻塞操作:

   • 严重问题: 代码中没有发现明显的网络 I/O 同步阻塞操作，但需注意 bilibili_api 库的 get_relation_info() 方法已经是异步的，使用正确

2. API 密钥/凭证管理:

   • 使用了第三方 API (uapis.cn, api.chyt.top)，但没有看到任何认证或限流处理
   • 这些 API 可能随时失效，应该有降级方案

3. 数据验证不足:

   • 用户输入的 uid 和 time 只检查了是否为数字，但没有检查范围（如 time 不能为 0 或负数）

4. 可维护性与可读性

存在的问题:

1. 职责不单一:

   • UPfansWatcher 类承担了太多职责：任务调度、数据获取、消息发送、命令处理等
   • 建议将任务调度逻辑提取到独立的类中

2. 魔法数字:

   • 代码中出现 60（秒）、24（小时）等魔法数字，应定义为常量

3. 文档字符串不完整:

   • 部分方法缺少详细的参数说明和返回值说明
   • _run_periodic_tasks 等复杂方法应该有更详细的说明

5. 潜在缺陷或问题

存在的问题:

1. 资源泄漏风险:

   • aiohttp.ClientSession 在 initialize 中创建，在 terminate 中关闭，但如果插件初始化失败，session 可能不会被正确关闭
   • 建议使用上下文管理器或确保异常情况下也能关闭

2. 竞态条件:

   • task_run 和任务重启逻辑中，self.running_tasks 可能在多个协程中被访问和修改，存在竞态条件风险

3. 任务取消后的异常处理:

   • 取消任务时，CancelledError 异常可能会被 return_exceptions=True 捕获，但没有对这些异常进行特殊处理

6. 框架适应性检查

存在的问题:

1. 日志记录 ✅ 正确:

   • 正确使用 from astrbot.api import logger

2. 并发模型 ✅ 正确:

   • 使用了异步编程，没有发现同步网络 I/O 阻塞

3. 数据持久化 ❌ 问题:

   • 使用了 self.get_kv_data() 和 self.put_kv_data() 方法，这是正确的数据持久化方式
   • 但没有发现对配置文件等其他数据的存储路径处理

7. main.py 专项检查

存在的问题:

1. 插件注册 ⚠️ 注意:

   • 使用了 @register 装饰器，在 v3.5.20 之后已废弃
   • 建议移除装饰器，直接继承 Star 类

2. filter 导入 ✅ 正确:

   • 正确使用 from astrbot.api.event import filter

3. 事件监听器签名 ✅ 正确:

   • 所有事件监听器都正确包含了 event 参数

4. 构造函数参数 ❌ 问题:

   • __init__ 方法接收了 config: AstrBotConfig 参数，但这不符合标准的 Star 子类签名
   • Star 子类的 __init__ 应该只接收 context: Context 参数
   • 配置应该通过 context 或其他方式获取

具体代码问题示例

# 问题 1: 构造函数签名错误
def __init__(self, context: Context, config: AstrBotConfig):  # ❌ 错误
    super().__init__(context)
    self.config = config

# 应该改为:
def __init__(self, context: Context):  # ✅ 正确
    super().__init__(context)
    self.config = context.get_config()  # 或通过其他方式获取配置

# 问题 2: 任务取消没有等待
self.runtask.cancel()  # ❌ 没有等待
self.runtask = asyncio.create_task(self.task_run())

# 应该改为:
self.runtask.cancel()
try:
    await self.runtask  # ✅ 等待任务完全取消
except asyncio.CancelledError:
    pass
self.runtask = asyncio.create_task(self.task_run())

# 问题 3: 缺少输入验证
time_int = int(time)  # ❌ 没有检查范围

# 应该改为:
time_int = int(time)
if time_int <= 0:  # ✅ 验证有效性
    yield event.plain_result("检查间隔必须大于 0")
    return

---

代码评审团

Linus Torvalds：
"我看到你在 __init__ 里塞了一个 AstrBotConfig 参数？你是不是觉得框架的设计者是白痴，不知道怎么传配置？Star 类的构造函数签名是有原因的，不是让你随便改的！还有，那个 _run_periodic_tasks 的时间计算逻辑，我数了数至少有 5 层 if 嵌套，这是在写 Perl 吗？重构它！不过话说回来，你至少知道用 asyncio，这比某些还在用线程的人强多了。另外，API 调用失败时没有异常处理？你是想让整个插件在半夜 2 点崩溃吗？加上 try-except，现在就加！"

Ada Lovelace：
"优雅的异步设计理念我很欣赏，但执行上还有改进空间。你的时间调度逻辑展现了对日期时间处理的思考，但过于复杂的算法会让未来的维护者（包括你自己）陷入困惑。我建议使用 APScheduler 或类似的成熟库，站在巨人的肩膀上，而不是重新发明轮子。另外，你对粉丝数据的持久化做得不错，但为什么不考虑添加历史记录功能？这样可以绘制粉丝增长曲线，提供更有价值的洞察。数据的价值不仅在于当下，更在于趋势分析。最后，get_upname 的双重回退机制很聪明，但应该添加日志记录每次 API 失败，以便分析 API 的可靠性。"

Tony Stark (钢铁侠)：
"嘿，Jarvis，分析一下这段代码... 开玩笑的。说真的，你这个插件就像 Mark I 装甲——能用，但不够酷。为什么不加点缓存？每次都去请求 B站 API 获取昵称，这效率简直是在用柴油发动机驱动反应堆。建议加个 LRU 缓存，把 UP 主的名字缓存起来。还有，你的错误处理就像没装护甲的战衣——太脆弱了。如果网络抖动或者 B站 API 限流，你的整个任务调度就会炸掉。加个指数退避重试机制，或者至少在失败时发个通知给用户，别让他们稀里糊涂地等着。最后，考虑一下 WebSocket 实时推送？虽然可能有点过度工程，但谁不想要实时通知呢？未来就是现在，伙计！"

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[laopanmemz]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_upfanswatcher

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

main.py

代码审查报告

经过全面审查，发现以下问题：

---

1. 代码质量与编码规范

问题 1.1: 变量命名不规范

• 位置: get_original_umo 函数返回值以及相关使用
• 问题: umo 这个缩写的含义不明确，降低了代码可读性
• 建议: 考虑使用更有意义的名称，如 session_identifier 或添加注释说明 umo 的含义

问题 1.2: 过长的方法

• 位置: _run_periodic_tasks 方法
• 问题: 该方法包含复杂的时间计算逻辑（约70行），职责过重，难以理解和维护
• 建议: 将时间计算逻辑提取为独立的辅助方法，如 _calculate_next_run_time(now, interval_minutes)

---

2. 功能实现与逻辑正确性

问题 2.1: 时间计算逻辑冗余且复杂

• 位置: _run_periodic_tasks 方法中的 next_run_time 计算部分（第40-70行）
• 问题:
  • 存在多个嵌套的条件判断和重复的时间计算
  • 逻辑分支过多，容易出错
  • 对跨天场景的处理过于复杂
• 示例问题代码:

if next_run_hour >= 24:
    next_run_hour -= 24
    next_run_time = datetime(...)
    if next_run_time <= now:
        next_run_time += timedelta(days=1)
else:
    next_run_time = datetime(...)

if next_run_time.date() == now.date() and next_run_time <= now:
    # 又一次计算...

• 建议: 简化为：

def _calculate_next_run_time(self, now: datetime, interval_minutes: int) -> datetime:
    """计算下一次运行时间"""
    total_minutes = now.hour * 60 + now.minute
    periods_passed = total_minutes // interval_minutes
    next_period_start = (periods_passed + 1) * interval_minutes
    
    next_run = now.replace(hour=0, minute=0, second=0, microsecond=0)
    next_run += timedelta(minutes=next_period_start)
    
    if next_run <= now:
        next_run += timedelta(days=1)
    
    return next_run

问题 2.2: 异常处理过于宽泛

• 位置: _run_periodic_tasks 方法的 except 块（第78行）
• 问题: 捕获所有异常后仅记录日志并等待60秒，可能掩盖严重错误，且固定的60秒等待时间缺乏依据
• 建议: 区分不同类型的异常进行处理，或至少记录完整的堆栈信息

问题 2.3: 任务取消后未等待清理完成

• 位置: add 和 delete 方法中的任务重启逻辑
• 问题:

for task in self.running_tasks:
    task.cancel()
self.runtask.cancel()
try:
    await self.runtask
except asyncio.CancelledError:
    pass

仅等待了 self.runtask，但没有等待 self.running_tasks 中的任务完成取消

• 建议: 应该等待所有任务：

for task in self.running_tasks:
    task.cancel()
self.runtask.cancel()

# 等待所有任务完成取消
all_tasks = [self.runtask] + self.running_tasks
await asyncio.gather(*all_tasks, return_exceptions=True)

---

3. 安全漏洞与最佳实践

问题 3.1: 外部 API 调用缺乏超时控制

• 位置: get_upname 方法中的 HTTP 请求
• 问题:

async with self.session.get(
    f"https://uapis.cn/api/v1/social/bilibili/userinfo?uid={uid}"
) as resp:

未设置超时参数，可能导致请求无限期挂起

• 建议: 添加超时控制：

async with self.session.get(
    f"https://uapis.cn/api/v1/social/bilibili/userinfo?uid={uid}",
    timeout=aiohttp.ClientTimeout(total=10)
) as resp:

问题 3.2: 外部 API 响应未验证

• 位置: get_upname 方法
• 问题: 直接访问响应数据的字段（data["name"]、data["username"]）而不检查键是否存在或响应状态码
• 建议: 添加响应验证：

if resp.status == 200:
    data = await resp.json()
    name = data.get("name") or data.get("username")
    if name:
        await self.put_kv_data(f"{str(uid)}_name", name)
        return name

---

4. 可维护性与可读性

问题 4.1: 魔法值过多

• 位置: 多处
• 问题:
  • "false" / "true" 字符串用于表示布尔值
  • 固定的60秒错误重试间隔
  • 固定的API超时时间（未设置）
• 建议: 定义为类常量：

class UPfansWatcher(Star):
    BOOL_TRUE = "true"
    BOOL_FALSE = "false"
    ERROR_RETRY_DELAY = 60
    API_TIMEOUT = 10

问题 4.2: 缺少类型注解

• 位置: 多个方法
• 问题: task_run、_run_periodic_tasks、_execute_single_task 等方法缺少返回类型注解
• 建议: 添加类型注解以提高代码可读性：

async def task_run(self) -> None:
    """遍历任务并开始执行"""
    
async def _run_periodic_tasks(self, interval_minutes: int, items: list) -> None:
    """根据指定的时间间隔运行周期性任务"""

---

5. 潜在缺陷或问题

问题 5.1: 会话对象未在初始化时创建

• 位置: initialize 方法
• 问题: self.session = aiohttp.ClientSession() 在异步方法中创建，但未使用 async with 确保正确管理
• 建议: 虽然在 terminate 中有 close() 调用，但考虑使用更明确的生命周期管理模式

问题 5.2: 并发安全问题

• 位置: self.config["uplist"] 的修改
• 问题: 在 add 和 delete 方法中修改配置列表，同时 _execute_single_task 也在读取该列表，可能存在并发访问问题
• 建议: 考虑使用锁保护共享资源，或使用不可变数据结构

问题 5.3: test 命令中存在调试代码

• 位置: test 方法
• 问题:

print(event.message_obj.session_id)

使用 print 而非 logger.debug，不符合框架规范

• 建议: 移除或改为 logger.debug(f"测试命令会话ID: {event.message_obj.session_id}")

---

6. 框架适应性检查

问题 6.1: 同步阻塞操作（网络I/O）

• 位置: 无
• 状态: ✅ 通过 - 所有网络请求均使用了异步库（aiohttp、bilibili_api）

问题 6.2: 日志记录器使用

• 位置: 第3行
• 状态: ✅ 通过 - 正确从 astrbot.api 导入 logger

问题 6.3: 数据持久化

• 位置: 使用 self.get_kv_data 和 self.put_kv_data
• 状态: ✅ 通过 - 使用了框架提供的键值存储机制，无需手动管理文件路径

---

7. main.py 专项检查

问题 7.1: 插件注册

• 状态: ✅ 通过 - 正确使用 @register 装饰器，参数格式符合规范

问题 7.2: filter 导入

• 状态: ✅ 通过 - 正确从 astrbot.api.event 导入 filter

问题 7.3: 事件监听器签名

• 状态: ✅ 通过 - 所有命令处理器都包含 event 参数

问题 7.4: 消息发送方式

• 状态: ✅ 通过 - 所有消息发送均使用 yield 语句，未使用特殊钩子函数

---

代码评审团

Linus Torvalds（Linux 之父，以直言不讳著称）:
"看到 _run_periodic_tasks 那一坨时间计算逻辑，我的血压都上来了！这是在写什么？俄罗斯套娃吗？if 套 if，datetime 套 datetime，这代码的作者是打算让后来的维护者崩溃吗？70 行代码干一件事，还全是边界判断，这不是工程，这是折磨！把时间计算抽出来，写个清晰的辅助函数，难道很难吗？

不过，我得承认异步部分处理得还算靠谱，至少知道用 aiohttp 和 asyncio。但是，那个 except Exception 是什么鬼？捕获所有异常然后睡 60 秒？为什么是 60 秒？你家祖传的吗？至少告诉我为什么要这么设计！

还有，print(event.message_obj.session_id) 留在生产代码里？这是在调试时忘了删，还是故意恶心人？用 logger 很难吗？"

---

Grace Hopper（COBOL 之母，倡导代码可读性和标准化）:
"亲爱的，代码写得还不错，能看出来你花了心思在异步处理上。但是，我必须指出几个让我担忧的地方：

首先，你的命名系统需要改进。umo 是什么意思？我猜了半天，是 'unified message object' 还是什么缩写？代码应该像讲故事一样清晰，让任何人读了都能明白。如果我要向一个新人解释这个系统，我会从命名开始改起。

其次，你的错误处理策略过于简单。想象一下，如果网络持续故障，你的程序会每隔 60 秒记录一次日志，然后继续重试，直到天荒地老。这不是容错，这是自欺欺人。区分可恢复错误和致命错误，设置重试上限，这些都是基本的工程实践。

最后，我很欣赏你使用了框架提供的 KV 存储和日志系统，这说明你理解了标准化的重要性。继续保持这种意识，你的代码会越来越好！"

---

Rick Sanchez（《瑞克和莫蒂》中的疯狂科学家）:
"Burp 好吧，让我们看看这个... 粉丝监控插件。首先，我得说，至少你知道用异步，不像那些还在用同步阻塞的蠢货。但是，兄弟，你这个时间计算逻辑是什么垃圾？你是从多元宇宙的某个糟糕维度抄来的吗？

你知道吗？在 C-137 宇宙，我们早就用 AI 自动优化这种任务调度了。你这里还在手动计算下一个运行时间，而且还搞得这么复杂。为什么不直接用 APScheduler 或者类似的库？非要重新发明轮子？

不过，我倒是挺喜欢你这个 API 降级策略。一个 API 挂了就试另一个，这是聪明的做法。但是，Burp，你有没有想过，如果两个 API 都挂了呢？你只是返回一个尴尬的 '获取UP昵称时出现错误'？Come on！缓存是个好主意，但你应该考虑得更远。比如，设置一个后台任务定期刷新缓存，而不是等出错了才想起来用缓存。

还有，你的任务重启逻辑有个 bug。你取消了 running_tasks 里的所有任务，但只等待了 runtask。那些子任务呢？它们在后台继续运行，变成了僵尸任务。这就像打开了一个传送门然后忘了关，迟早会出问题。

总的来说，功能能用，但架构上还有很大的优化空间。如果这是为了拯救宇宙的关键代码，我会重构它。但如果只是监控 B 站粉丝数？Eh，凑合吧。Burp"

---

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[Soulter]

已上架