[Plugin] astrbot_plugin_screen_companion

[menglimi]

插件信息

{
  "name": "astrbot_plugin_screen_companion",
  "display_name": "我会一直看着你",
  "desc": "这是一款智能屏幕观察（视奸）插件，通过截图分析和环境感知，为用户提供个性化的互动体验。它不仅能观察用户的屏幕活动，还能感知环境变化，如系统状态、天气情况和节假日，甚至能监听麦克风音量，为用户提供全方位的智能陪伴。灵感来源于妹居物语，使用请注意隐私保护。",
  "author": "menglimi",
  "repo": "https://github.com/menglimi/astrbot_plugin_screen_companion",
  "tags": [
    "视奸",
    "陪伴"
  ],
  "social_link": "https://github.com/menglimi"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_screen_companion

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

main.py

1. 代码质量与编码规范

• 方法过于庞大（臃肿）：_analyze_screen 方法长达百余行，内部混合了系统状态检测、天气信息获取（aiohttp 异步调用）、节假日计算、长文本系统提示词拼接、LLM 接口调用以及图片写入本地等多项操作。这严重违反了单一职责原则，不仅降低了代码的可读性，也给后续维护和异常排查带来极大困难。建议将天气获取、状态检查、场景判定等抽取为独立的方法。
• 模块导入规范问题：代码中有大量位于函数内部的导入，例如 import os、import datetime、import json 等。如果是为了防止可选库（如 pyautogui, psutil）不存在而引发错误，放在内部是合理的。但对于 Python 标准库（如 datetime, os, json），应统一放置在文件顶部，以符合 PEP 8 规范并提升可读性。
• 超长字符串硬编码：在 _analyze_screen 中直接硬编码了极其冗长且详细的“诺星缘”人设 Prompt。从长远来看，应将其抽离到外部 JSON/YAML 配置文件或常量定义模块中，以保持主体代码清爽。

2. 框架适应性与数据持久化

• 违规的数据路径硬编码（重要）：
  在 __init__ 与 _analyze_screen 方法中，使用了手动拼接相对路径的方式来存储数据，例如：
  os.path.join(os.path.dirname(__file__), "..", "..", "data", "diary")
os.path.join(os.path.dirname(__file__), "..", "..", "data", "learning")
os.path.join(os.path.dirname(__file__), "..", "..", "data", "screen_shot_latest.jpg")
  修复建议：必须导入 from astrbot.api.star import StarTools，使用 StarTools.get_data_dir() 来获取规范的数据存储目录（例如：plugin_dir = StarTools.get_data_dir() / "diary"）。请注意，get_data_dir() 返回的是一个 Path 对象而不是字符串，使用时可以直接用斜杠 / 进行路径拼接，并使用 .mkdir(parents=True, exist_ok=True) 替代 os.makedirs。
• 废弃的 @register 装饰器：代码中依然使用 @register 装饰器注册插件。在 AstrBot v3.5.20 之后该装饰器已废弃。AstrBot 会自动识别继承自 Star 的类，建议将其移除，保持代码干净。

3. 潜在缺陷与问题

• 临时文件写入的数据竞争冲突：
  在 _analyze_screen 中，临时图片被写入：temp_file_path = os.path.join(temp_dir, f"screen_shot_{id(self)}.jpg")。
  由于插件实例的 id(self) 在运行时是固定的，如果同时触发了两次并发的屏幕截图任务（例如自动监控刚好触发，同时用户又发送了 /kp 指令），两张截图将写入同一个文件，可能会发生一张截图正在写入一半就被另一张覆盖的竞争现象，导致发送损坏的图片。建议使用 uuid 或时间戳生成独立的文件名，并在发送完成后清理（删除）它，防止磁盘垃圾累积。
• 后台死循环协程的生命周期泄漏：
  在 __init__ 中直接使用了 asyncio.create_task() 创建了 _task_scheduler、_diary_task、_custom_tasks_task、_mic_monitor_task 等无限循环的后台协程，且没有保留这些 Task 对象的引用。当框架对插件进行热重载（或销毁该实例）时，这些老实例所拉起的协程依然会在后台像“幽灵”一样运行，造成内存泄漏甚至并发冲突（如重复发送日记）。建议将它们保存在 self.background_tasks = [] 中，并通过覆写或挂载适当的卸载钩子来执行 task.cancel()。

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

• 天气 API 调用的异常捕获粒度：在 _analyze_screen 函数中，庞大的 try-except Exception as e: 包裹了整个过程，如果在拉取天气的 aiohttp 请求阶段就抛出了普通超时异常，将会跳过后续所有的逻辑（包括识别和对话交互），导致返回“我已经看到了你的屏幕，但是无法进行分析...”。应缩小 try-catch 范围，保证非核心流程（如天气失败）不影响核心流程（看屏幕）。

---

init.py

该文件为空，符合作为包标识文件的基础要求，无明显问题。

---

代码评审团

Linus Torvalds：
你看过自己的 _analyze_screen 方法吗？！快 200 行了！里面塞进了天气请求、系统资源状态、节假日判定、还要构建一长串像老奶奶裹脚布一样的系统 prompt 字符串！为什么不拆分开来？这简直就是一锅乱炖！另外，你在 __init__ 里丢出去不管的那些 asyncio.create_task 死循环是在开玩笑吗？如果你不自己跟踪这些 Task 并在重载时 cancel() 掉，它们会在后台像僵尸一样吃掉用户的内存，然后疯狂重复发消息！拜托，写点对得起自己智商的生命周期管理代码好吗？

乔布斯：
优秀的软件应该像一件艺术品，从里到外都应该优雅。你的设计愿景很酷，交互很有人情味，但底层实现上却缺乏美感。比如数据持久化，你为什么还要手动拼接 ../../data/... 这种丑陋的路径？直接用框架提供的 StarTools.get_data_dir() 不是更完美吗？记住，它返回的可是现代化的 Path 对象，别再混用 os.path 了。还有那些在函数里随处可见的 import datetime，它打破了代码的和谐感，把标准库归置到文件开头吧。

银狼（星核猎手）：
嘿，就这点代码水平还想监控我？看这里，你用 temp_file_path = os.path.join(temp_dir, f"screen_shot_{id(self)}.jpg") 存截图，要是系统同一时间触发了两次截图任务，第二张图瞬间就把第一张图覆盖了，最后发出去的图直接错位穿模。加个 uuid 或者时间戳有那么难吗？还有，你在系统里生成完图片不主动删？用完记得打扫战场啊，别在人家的服务器磁盘里留下一堆垃圾缓存文件。回去重写！

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

[astrbot-plugin-copybara]

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

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