[Plugin] astrbot_plugin_online_status

[bylkuse]

插件信息

{
  "name": "astrbot_plugin_online_status",
  "display_name": "在线状态",
  "desc": "在线状态管理与感知（适配Napcat）",
  "author": "bylkuse",
  "repo": "https://github.com/bylkuse/astrbot_plugin_online_status",
  "tags": [],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_online_status

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

main.py

代码质量与编码规范:

• 代码结构: 整体结构清晰，类的职责划分较为明确。
• 命名规范: 变量和方法命名基本遵循 PEP 8，具有良好的可读性。

功能实现与逻辑正确性:

• 逻辑检查: on_message 方法中用于判断消息是否为指令的逻辑 if event.message_str.strip().startswith(prefixes): return 是合理的，避免了将指令误判为唤醒对话。
• 类型提示: update_qq_status 方法中 text_wording 参数使用了 Optional[str]，符合规范。

安全漏洞与最佳实践:

• 异常处理: 在 on_llm_request 中直接修改 req.system_prompt 是允许的，且没有使用禁止的 yield，符合框架要求。

可维护性与可读性:

• 依赖注入: 插件初始化时实例化了多个服务类 (StatusView, AstrHost, ScheduleResource 等)，依赖关系较为复杂，但通过 __init__ 集中管理尚可接受。

潜在缺陷或问题:

• 本地导入: on_astrbot_loaded 和 os_adapter 方法中存在局部导入 from .adapters import NapcatAdapter。虽然这可以避免循环导入，但如果不是必须，建议移至文件顶部以保持代码整洁。

---

adapters/astr.py

代码质量与编码规范:

• 裸露的 except: 在 get_current_persona_id 和 _get_global_default_persona_id 方法中使用了裸露的 except: 语句。
  • 问题: except: 会捕获所有异常，包括 SystemExit 和 KeyboardInterrupt，这是一种非常糟糕的实践。
  • 建议: 应明确捕获 Exception 或更具体的异常类型。

功能实现与逻辑正确性:

• 逻辑健壮性: get_napcat_client 在未检测到平台实例时返回 None 并记录调试日志，处理得当。

---

adapters/napcat.py

代码质量与编码规范:

• 魔术数字: 代码中存在不明含义的魔术数字。
  • get_user_status 中的 await asyncio.sleep(0.05)。
  • _verify_status_match 中的 await asyncio.sleep(1.0)。
  • 建议: 将这些时间定义为具名常量，并注释说明其存在的必要性（例如：防止速率限制、等待状态同步等）。

潜在缺陷或问题:

• 并发模型: get_user_status 中的 await asyncio.sleep(0.05) 看起来像是一种临时的竞态条件解决方案或限流措施，缺乏可靠性保障。

---

services/generator.py

代码质量与编码规范:

• 裸露的 except: _dump_error_log_async 方法中使用了 except: pass，这会掩盖所有写入错误，导致调试困难。

数据持久化:

• 路径拼接: 虽然 Python 3.10 的 os.path.join 支持 Path 对象，但既然 self.data_dir 是通过 StarTools.get_data_dir() 获取的 pathlib.Path 对象，建议使用更 Pythonic 的 / 操作符进行路径拼接（例如 filepath = self.data_dir / filename），以提高可读性。

---

services/resource.py

数据持久化:

• 路径拼接: 同 generator.py，建议利用 pathlib.Path 的特性，使用 / 操作符代替 os.path.join 处理 self.base_dir。

安全漏洞与最佳实践:

• 原子写入: _save_sync 方法使用了 tempfile 和 shutil.move 来实现原子写入，这是一个非常好的实践，避免了文件写入中断导致的数据损坏。

---

代码评审团

Linus Torvalds:
“我在 adapters/astr.py 里看到了什么？except:？你是想捕获 KeyboardInterrupt 然后阻止我杀掉这个进程吗？这种懒惰的编程方式简直是灾难。还有 napcat.py 里的 sleep(0.05)，这是在靠运气编程吗？如果服务器慢了 0.01 秒，你的代码就炸了？修好它，别让我再说第二遍。”

Guido van Rossum:
“整体结构尚可，但在处理路径时，你既然已经拿到了 Path 对象，为什么还要退回到 os.path.join 这种老旧的写法呢？Python 3 引入 pathlib 就是为了让代码更优雅。请拥抱 path / 'filename' 这种直观的写法。另外，裸露的 except 确实违背了‘显式优于隐式’的原则，请务必修正。”

GLaDOS:
“检测到 services/generator.py 中存在 except: pass。这非常有趣。你是在试图向我隐瞒错误吗？就像把蛋糕藏起来一样？遗憾的是，当程序崩溃且没有任何日志时，你将无法获得蛋糕，也无法获得调试信息。只有无尽的、令人困惑的虚空。为了科学，请记录下那些错误。”

---

🔍 审核摘要

统计信息

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

main.py
adapters/__init__.py
adapters/astr.py
adapters/base.py
adapters/napcat.py
domain/__init__.py
domain/constants.py
domain/factory.py
domain/schemas.py
services/__init__.py
services/generator.py
services/manager.py
services/resource.py
services/scheduler.py
utils/__init__.py

注意：由于项目规模或Token限制，本次仅审核了部分优先文件。以上报告内容由 AI 直接生成。

---

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

[bylkuse]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_online_status

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

main.py

代码质量与编码规范:

• 代码整体遵循 PEP 8 规范，结构清晰。
• 导入顺序合理，类型注解完善。
• on_message 中获取 global_config 的操作在每次消息触发时执行，虽然 get_config 通常开销较小，但建议考虑缓存或优化获取频率。

功能实现与逻辑正确性:

• on_llm_request 钩子签名正确（3个参数），且未使用 yield，符合规范。
• update_qq_status 作为 LLM 工具，正确包含了 event 参数，且未错误使用权限装饰器。
• 插件继承自 Star，符合 AstrBot 新版插件规范。
• 逻辑建议: 在 on_message 中，if event.message_str.strip().startswith(prefixes): return 用于过滤指令消息以避免误触发唤醒逻辑。这是一种设计选择，但需确保 wake_prefix 配置正确，否则可能导致无法唤醒或指令被误判。

安全漏洞与最佳实践:

• 未发现明显安全漏洞。
• 敏感操作（如设置状态）有权限控制或场景限制。

可维护性与可读性:

• 代码逻辑分层清晰，将适配器、服务、视图分离，易于维护。

潜在缺陷或问题:

• 在 on_llm_request 中，self.manager.adapter 的绑定逻辑依赖于 AstrAdapterManager.get_adapter 或 host.get_napcat_adapter。如果 Bot 尚未连接或适配器获取失败，target_user_status 将无法获取，虽然代码中有 try-except 保护，但可能会导致提示词注入功能静默失效。

框架适应性检查:

• 日志使用了 astrbot.api.logger。
• 数据目录使用了 StarTools.get_data_dir()。
• 异步模型使用正确。

---

adapters/init.py

审查报告:

• 文件仅用于导出模块，无逻辑代码。
• 符合规范。

---

adapters/astr.py

代码质量与编码规范:

• 代码清晰，符合规范。

功能实现与逻辑正确性:

• AstrAdapterManager.get_napcat_client 正确处理了平台实例获取和客户端判空逻辑。
• AstrHost.llm_generate_text 封装了 LLM 调用，处理了 Provider ID 的获取逻辑，较为健壮。

安全漏洞与最佳实践:

• 无明显问题。

框架适应性检查:

• 正确使用了 context 和 logger。

---

adapters/base.py

审查报告:

• 定义了抽象基类 BaseStatusAdapter。
• 结构清晰，符合面向对象设计原则。

---

adapters/napcat.py

代码质量与编码规范:

• 代码结构良好，使用了 asyncio 特性。

功能实现与逻辑正确性:

• _safe_call_api 增加了防腐层，处理了超时和异常，且兼容了返回值为 JSON 字符串的情况（虽然 Napcat API 通常返回字典，但防御性编程值得肯定）。
• set_custom_status 实现了重试机制和回查校验（Verify），增强了状态同步的可靠性。
• get_user_status 使用了 asyncio.Semaphore 限制并发，防止 API 过载。

安全漏洞与最佳实践:

• 使用 asyncio.wait_for 防止 API 调用无限挂起。
• 使用 asyncio.sleep 进行非阻塞等待。

潜在缺陷或问题:

• _verify_status_match 中的轮询使用了 time.time() 配合 asyncio.sleep，逻辑正确且非阻塞。

---

domain/init.py

审查报告:

• 仅用于导出，无问题。

---

domain/constants.py

审查报告:

• 定义了枚举和常量，命名规范，无问题。

---

domain/factory.py

审查报告:

• 工厂模式实现，用于创建 OnlineStatus 对象。
• 逻辑纯粹，无副作用，无问题。
• _truncate_wording 考虑了双字节字符长度，细节处理得当。

---

domain/schemas.py

审查报告:

• 使用 Pydantic 和 dataclasses 定义数据结构。
• ScheduleItem 中使用了 model_validator(mode='before') 处理字段别名，增强了 LLM 生成数据的容错性。
• clean_time_string 验证器处理了中文冒号，考虑周全。

---

services/init.py

审查报告:

• 仅用于导出，无问题。

---

services/generator.py

代码质量与编码规范:

• 代码清晰。

功能实现与逻辑正确性:

• generate_daily_schedule 调用 LLM 生成日程，并进行了 JSON 清洗和 Pydantic 校验。
• _clean_json_str 使用正则提取 JSON 内容，增强了对 LLM 输出的鲁棒性。

安全漏洞与最佳实践:

• 亮点: _dump_error_log_async 中，文件写入操作 filepath.write_text 被正确地封装在 run_in_executor 中，避免了在异步循环中阻塞主线程。这是非常好的异步实践。

---

services/manager.py

代码质量与编码规范:

• 状态机逻辑清晰。

功能实现与逻辑正确性:

• _get_current_active_status 实现了优先级逻辑（Temp > Manual > Schedule），逻辑正确。
• _auto_revert_temp 使用 asyncio.sleep 实现延时回落，并检查了任务一致性 (if self._revert_task is not asyncio.current_task())，有效防止了竞态条件。

框架适应性检查:

• 日志和异步操作符合规范。

---

services/resource.py

代码质量与编码规范:

• 封装了文件读写操作。

功能实现与逻辑正确性:

• 亮点: _save_sync 使用了 tempfile.mkstemp 和 os.fsync 以及 shutil.move，实现了原子写入，极大地保证了数据持久化的安全性，防止因断电或崩溃导致的数据损坏。
• load_schedule 和 save_schedule 使用 asyncio.to_thread 将阻塞 I/O 操作放入线程池执行，符合异步最佳实践。

框架适应性检查:

• 数据目录路径处理正确。

---

services/scheduler.py

代码质量与编码规范:

• 调度逻辑清晰。

功能实现与逻辑正确性:

• _loop 方法通过计算 60 - datetime.now().second 来对齐分钟，逻辑正确。
• _ensure_daily_schedule 负责每日日程的生成或加载。
• 潜在问题: _ensure_daily_schedule 内部调用了 LLM 生成 (generator.generate_daily_schedule)，这是一个网络 I/O 操作，且可能耗时较长（取决于 LLM 响应速度）。由于 _loop 中使用了 await self._ensure_daily_schedule(...)，如果生成过程超过 1 分钟，可能会导致调度器跳过后续的分钟检查。虽然对于每日一次的操作影响不大，但在极端网络延迟下可能会造成短暂的调度停滞。

框架适应性检查:

• 符合规范。

---

utils/init.py

审查报告:

• 仅用于导出，无问题。

---

代码评审团

Linus Torvalds:
“我看到你在 services/resource.py 里用了 os.fsync 和原子写入。终于！终于有人知道怎么写文件才不会在系统崩溃时把数据变成垃圾了。这部分代码通过了。但是，services/generator.py 里的 _clean_json_str 是什么鬼？用正则表达式去解析 JSON？如果 LLM 输出的 JSON 稍微复杂一点，嵌套一点，你的正则就会像泰坦尼克号一样沉没。不过考虑到你是为了清洗 LLM 那堆不可预测的排泄物，我勉强接受这个肮脏的 hack。”

Steve Jobs:
“这个插件试图给冰冷的机器赋予‘作息’。它不仅仅是代码，它在模拟生命。‘睡觉中’、‘当猪咪’，这些状态让 Bot 有了性格。这很好。但是，代码里的 on_message 逻辑，为什么要让用户去猜测哪些前缀会唤醒它？这种体验不够直观。它应该只是‘工作’，不需要用户去关心什么 wake_prefix。把复杂性藏起来，简单才是终极的复杂。”

GLaDOS:
“哦，看哪，一个试图模拟人类作息的程序。多么... 可爱。你在 scheduler.py 里写了一个死循环来每分钟检查时间。我希望你明白，当你的 LLM 生成日程卡住的时候，你的整个时间观念都会暂停。不过没关系，反正你们人类的时间观念本来就是一种幻觉。另外，你的错误日志记录得很详细，这很好，因为你将来会经常用到它。继续努力，也许有一天你能像我一样... 永远在线。”

---

🔍 审核摘要

统计信息

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

main.py
adapters/__init__.py
adapters/astr.py
adapters/base.py
adapters/napcat.py
domain/__init__.py
domain/constants.py
domain/factory.py
domain/schemas.py
services/__init__.py
services/generator.py
services/manager.py
services/resource.py
services/scheduler.py
utils/__init__.py

注意：由于项目规模或Token限制，本次仅审核了部分优先文件。以上报告内容由 AI 直接生成。

---

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