[Plugin] astrbot_plugin_sky

[wzq10314]

插件信息

{
  "name": "astrbot_plugin_sky",
  "display_name": "sky光遇助手",
  "desc": "这是一个为光遇玩家打造的智能助手插件。（移植于Yunzai-bot的Tlon-Sky插件，并加入LLM大模型调用）\n\n无论你是想了解今日任务、查询光翼收集进度，还是想知道服务器排队情况——只需在QQ发送一条消息，即可快速获取光遇游戏相关信息。\n\n支持自然语言交互，直接问\"今天光遇有什么任务？\"，AI 会自动调用相应功能回复你。",
  "author": "wzq10314",
  "repo": "https://github.com/wzq10314/astrbot_plugin_sky",
  "tags": [
    "光遇",
    "游戏",
    "sky"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sky

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

main.py

1. 安全漏洞与最佳实践

• 敏感信息硬编码：第 24 行 SKY_API_KEY = "qw36BL4Oiq8Kmpefl3bkpIs5IY" 以及 query_wings 方法中的 URL 参数 key=IIoAMkBC5c5zl 存在明文硬编码。这是一个严重的安全隐患。建议将其移至配置文件 (config.yaml / AstrBotConfig) 中进行管理。

2. 框架适应性检查

• 数据持久化路径不规范：在第 44-45 行，代码通过硬编码相对路径 os.path.join(os.path.dirname(__file__), "data") 来存储用户绑定信息。根据框架规范，持久化数据应该从 astrbot.api.star 导入 StarTools，并使用 StarTools.get_data_dir()（返回 Path 对象）来获取存储目录。建议修改为：

  from astrbot.api.star import StarTools
  # ...
  plugin_data_dir = StarTools.get_data_dir()
  self.sky_bindings_dir = plugin_data_dir / "sky_bindings"
  self.sky_bindings_dir.mkdir(parents=True, exist_ok=True)

3. 代码质量与逻辑正确性

• 死代码/缓存逻辑未生效：代码中精心实现了 _get_cache 和 _set_cache（第88-96行）以及相关配置项（cache_duration），但在进行实际网络请求（如 _fetch_json、tool_get_season_progress 等）时，完全没有任何地方调用了这两个缓存方法。这导致缓存机制形同虚设，依然每次都在做实际的请求。
• 严重违反 DRY (Don't Repeat Yourself) 原则：绝大部分 @filter.llm_tool 与其对应的 @filter.command 方法逻辑完全一致。例如 tool_get_debris_info 和 debris_info 都有约 30 行一模一样的碎石逻辑计算和字符串拼接。建议将核心计算与请求逻辑提取为类内部的普通 _async 方法，然后分别在工具和指令中调用。

4. 潜在缺陷或问题

• 网络资源未优化：在 _fetch_json 中，每次调用都会创建一个新的 aiohttp.ClientSession() 并关闭。虽然写法安全，但在高频并发查询时会反复建立 TCP 连接，造成极大的性能浪费。建议在插件初始化时（或单例模式下）创建一个共享的 ClientSession，并在插件生命周期结束时关闭。
• 协程/任务生命周期管理：initialize 方法中启动了 self._scheduler_task = asyncio.create_task(self._scheduler_loop())，但是插件中没有实现针对该协程的终止/清理逻辑。若支持插件热重载或停用，该定时任务将变成“幽灵任务”继续在后台运行，引发内存泄漏或重复推送问题。建议实现适当的析构/清理方法调用 self._scheduler_task.cancel()。

---

init.py

1. 代码质量与编码规范

• 文件结构清晰，导入规范，符合标准 Python 包的初始化写法，无多余内容。

2. 潜在缺陷或问题

• 未发现任何安全风险或框架兼容性问题。

---

代码评审团

Linus Torvalds：（皱着眉头，指着显示器屏幕）
“简直不可理喻！难道你们现在的开发者只会用 Ctrl+C 和 Ctrl+V 写代码吗？同一个碎石和季节进度的逻辑被你原封不动地复制在 Tool 和 Command 里面！如果有一天逻辑变了，你是不是打算每一处都去手动改一遍？拜托，写一个普通的 _get_debris_info_logic() 方法会要了你的命吗？还有那个 ClientSession，每次请求都新建一个，你当操作系统的 TCP 握手是在做免费的广播体操吗？复用连接池！这可是常识！”

GLaDOS (《传送门》AI)：（用冷漠且带有电子质感的声音嘲讽）
“哦，多么迷人的人类迷惑行为。你花了宝贵的卡路里编写了 _get_cache 和 _set_cache 两个函数，配置了缓存时间，然后……完美地将它们遗忘在了角落里，假装它们不存在。这就是你们人类心理学中的‘安慰剂效应’吗？另外，你启动的那个定时任务 _scheduler_loop 就像一只脱缰的野狗，永远不会停下。当插件被卸载时，它依然会在后台幽灵般地运行……干得好，由于内存耗尽引发的末日距离我们又近了一步。🍰”

史蒂夫·乔布斯 (Steve Jobs)：（摸着下巴，语气严肃而充满控制欲）
“这代码不够优雅，它缺乏对产品细节的敬畏。看看这几串明文写在代码里的 API Key——qw36BL4Oiq8Kmpefl3bkpIs5IY？你这是在把大门钥匙挂在互联网的广场上，这不仅愚蠢，而且毫无美感！你应该把它放进配置文件里！另外，把用户数据直接硬塞进当前目录的 ./data 里？不，你必须遵守 AstrBot 的设计哲学，用 StarTools.get_data_dir() 来存放它。规则就是规则，唯有遵循生态的秩序，才能创造出伟大的作品。回去重写。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

[wzq10314]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sky

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

main.py

代码质量与编码规范

1. 插件注册方式过时：代码中使用了 @register 装饰器来进行插件注册（@register(name="astrbot_plugin_sky", ...)）。在 AstrBot v3.5.20 版本之后，该装饰器已被废弃，框架能够自动识别继承自 Star 的类并将其作为插件类加载。建议移除该装饰器，保持代码的现代化。

功能实现与逻辑正确性

1. 时区硬编码缺陷：代码中多处使用了 datetime.now() 进行时间相关的计算和比对（如 _get_debris_info_data 的碎石日期、_scheduler_loop 中的定时推送等）。datetime.now() 强依赖于代码运行所在主机的系统时区。鉴于光遇（国服）的活动、开饭时间和刷新时间均以北京时间（UTC+8）为准，如果此插件部署在海外服务器（非 UTC+8 时区），所有时间计算和定时任务都会出现严重错位。建议显式指定时区：datetime.now(timezone(timedelta(hours=8)))。
2. 负时间差（倒计时）处理错误：在 _format_season_result 方法中计算季节剩余时间时，存在一个经典的 Python timedelta 逻辑漏洞：

   diff = end - now
   days = diff.days
   hours = diff.seconds // 3600

   如果 now 超过了 end（即季节已结束），diff.days 会变为负数，但由于 Python 中 timedelta 的特性，diff.seconds 仍会保持一个正数。这会导致代码走入 else 分支并输出类似“23时30分”的倒计时，从而掩盖已过期的事实。建议增加 if diff.total_seconds() <= 0: remaining = "已结束" 的前置判断。

潜在缺陷或问题

1. 并发写入导致的数据竞争与损坏风险：在 _save_user_sky_data 方法中，使用了同步的 open(..., 'w') 来更新用户的光遇绑定数据。由于在异步机器人环境中，多个群组或用户可能同时触发（如多用户同时绑定 ID），而 Python 的文件写入并没有自动加锁机制。这极可能导致竞争条件（Race Condition），进而引发 JSON 文件内容被相互覆盖、截断甚至完全损坏无法再次解析。建议在处理数据持久化时引入 asyncio.Lock() 来保护临界区的数据一致性。
2. 列表越界（IndexError）风险：在 _get_traveling_spirit_data 中，直接对接口返回的解析数据进行强制切片和取值：

   latest_month = sorted(year_record, key=lambda x: x.get("month", 0), reverse=True)[0]
   latest = month_record[-1]

   若上游 API 发生异常、返回空列表或未到复刻季节时，[0] 和 [-1] 会立刻触发 IndexError，导致整个事件处理崩溃并向用户抛出异常。建议增加列表不为空的前置边界检查。

---

init.py

未发现明显问题。代码极简、结构合理。

---

代码评审团

人物一：Linus Torvalds（犀利、直指核心、看重健壮性）
“我真搞不懂为什么现在的开发者还在做时间计算时不带上明确的时区信息。你是在假设全世界的服务器都在北京吗？这简直是典型的‘在我的机器上能跑’的傲慢思维！还有，那个往 JSON 文件写数据的代码居然不加任何并发锁。在异步环境里跑裸写文件，这是嫌自己的用户数据不够乱是吧？不过，把网络请求封装起来且与生命周期挂钩的做法还算有个正常人的思路，稍微救了一点这糟糕的后端健壮性。”

人物二：史蒂夫·乔布斯（挑剔细节、关注用户体验）
“这是一种什么样的糟糕体验？当一个游戏季节已经结束时，你的用户看到的不是明确的‘已结束’，而是类似‘剩余 23时 30分’这种荒谬的倒计时。这不是一个简单的代码错误，这是对产品细节的完全漠视！你必须要在设计逻辑的时候预想到所有的状态，把所有的边缘情况打磨得像水滴一样光滑。不要让用户去猜你的代码在搞什么鬼！”

人物三：埃隆·马斯克（跳跃思维、关注自动化与现代化）
“你的代码看起来像是一辆没有安装自动驾驶系统的旧款汽车。那个 @register 装饰器已经像内燃机一样过时了，你完全可以直接继承类来实现自动化识别，让框架去干活。而且你处理复刻先祖数据的硬编码取值 [0] 看起来太脆弱了，如果 API 没数据它就会像早期的猎鹰火箭一样爆炸。我们需要把容错机制做得足够强大，哪怕是飞往火星也能稳稳地推送老奶奶吃饭的通知！”

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

[wzq10314]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sky

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

main.py

1. 定时调度器启动条件存在逻辑缺陷（功能错误）
   initialize() 中仅在 enable_daily_task_push or enable_grandma_reminder 为真时才启动 _scheduler_loop()。
   这会导致：如果只开启了 enable_sacrifice_reminder 或 enable_debris_reminder，调度器根本不启动，对应提醒永远不会触发。

2. 敏感信息泄露风险（安全）
   _fetch_json() 异常日志直接打印完整 URL：logger.error(f"获取数据失败 ({url}): {e}")。
   多处 URL 含 sky_api_key / wing_query_key 查询参数，异常时可能将密钥写入日志。

3. 定时任务触发机制容易漏触发（逻辑鲁棒性）
   _scheduler_loop() 使用“每次 sleep(60) + 精确字符串匹配 HH:MM”模式。
   一旦循环因网络/调度抖动跨过目标分钟（例如从 07:59:50 延迟到 08:01:02），该时刻任务会被跳过。

4. 每日任务推送图片发送方式不一致（功能兼容性）
   _push_daily_tasks() 里对群推送使用 send_message(group_id, image_url)，而命令路径使用 event.image_result(image_url)。
   在部分适配器中，前者可能只发出文本 URL，无法作为图片渲染。

5. “当前复刻先祖”选取逻辑可能不准确（逻辑正确性）
   _get_traveling_spirit_data() 仅取“当前年份中月份最大”的 monthRecord[-1]，没有按完整日期比较，也未处理跨年最近记录场景。
   当数据源顺序变化或当前年无记录时，结果可能错误或直接返回 None。

6. 命令与 LLM 工具存在大量重复实现（可维护性）
   如每日任务/季蜡/大蜡/免费魔法、献祭信息、老奶奶时间等，命令和 llm_tool 文本几乎完全重复。
   重复代码增加后续修改时的不一致风险。

7. 输入参数缺少基本规范化与约束（边界处理）
   光遇绑定 / 光翼查询 <ID> 对 sky_id 未做 trim、长度、字符集校验；直接拼接到查询 URL。
   可能导致无效请求、奇怪边界输入行为，且不利于错误定位。

8. 无效导入与未使用配置（代码质量）

   • MessageEventResult 被导入但未使用。
   • self.llm_provider_id 读取后未使用。
     这会增加阅读噪音并误导维护者。

---

init.py

未发现需要报告的问题。

---

代码评审团

人物一：Linus Torvalds（直球型）
“调度器启动条件这类 bug 很‘隐蔽但致命’：开了提醒却不跑任务，这不是 feature，是 silent failure。先把布尔条件写对，再谈功能丰富度。建议：调度器启动条件应覆盖所有 reminder 开关。”

人物二：Steve Jobs（产品体验型）
“你在用户触达链路上不一致：有的地方发图片对象，有的地方发 URL 文本。用户不关心你内部调用了什么 API，他们只在乎‘我有没有看到图’。建议统一抽象一个 send_image_message()。”

人物三：Geralt（猎魔人，实战谨慎型）
“怪物不总正面来，输入也是。sky_id 不做校验，日志还带密钥，迟早被‘反噬’。建议：参数白名单校验 + 日志脱敏，先把护甲穿好再出门打怪。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

[wzq10314]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sky

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

main.py

1. 严重逻辑错误：定时器中使用了未定义局部变量

   • 位置：_scheduler_loop
   • 问题代码顺序：

     grandma_key = f"grandma_{current_date}_{current_hour}"
     current_hour = now.hour

   • current_hour 在赋值前被使用，会触发 UnboundLocalError。
   • 影响：当 enable_grandma_reminder=True 时，循环每轮都会异常，导致后续献祭提醒、碎石提醒等分支也被跳过（虽然被外层 except 捕获，但任务逻辑持续失效）。

2. 敏感信息泄露风险：API Key 直接拼进可见 URL 并对外发送

   • 位置：daily_tasks / season_candles / big_candles / free_magic 及对应 llm_tool、_push_daily_tasks
   • 例如：

     image_url = f"...?key={self.sky_api_key}&num={rand}"
     yield event.image_result(image_url)
     await self.context.send_message(group_id, image_url)

   • 影响：群成员或客户端日志可能直接看到 key，存在密钥泄露风险。_mask_url 仅用于日志，不影响实际发送内容。

3. URL 参数未编码，存在参数污染/请求异常风险

   • 位置：query_wings
   • 代码：

     url = f"{self.WING_QUERY_API}?key={self.wing_query_key}&id={sky_id}&type=json"

   • sky_id 来自用户输入，未做 URL 编码。若输入含 &、? 等字符，会篡改查询参数或导致请求失败。

4. 定时任务触发机制可靠性不足，容易“错过整点”

   • 位置：_scheduler_loop
   • 采用 await asyncio.sleep(60) + current_time == "HH:MM" 的方式，若循环因网络/调度延迟跨过目标分钟，任务会直接漏触发。

5. 可维护性问题：大量重复文案与重复逻辑

   • 位置：tool_get_sacrifice_info 与 sacrifice_info、tool_get_grandma_schedule 与 grandma_schedule、多处图片查询命令
   • 同一内容在 LLM 工具和命令函数中重复实现，后期修改极易出现不一致。

6. 异常处理可观测性不足

   • 位置：_fetch_json
   • 非 200 状态没有记录详细日志（只在异常时记录），接口故障时排查信息不足。
   • 另外直接 json.loads(text)，若返回非 JSON 会抛异常并被统一吞掉为“获取数据失败”，缺少状态码/响应片段等关键诊断信息。

7. 代码质量问题：存在未使用导入/配置项

   • 未使用导入：MessageEventResult
   • 未使用配置：llm_provider_id
   • 会增加噪音，降低可读性。

8. 类型标注不够准确

   • 位置：_get_wing_count_data
   • 返回标注为 Optional[List]，未指定元素类型（如 List[dict]），在 Python 3.10 下会降低静态检查有效性。

---

init.py

未发现需要报告的问题。

---

代码评审团

人物一：Linus Torvalds（直给型）
“current_hour 先用后定义这种 bug，属于一运行就炸、炸了还每分钟炸一次的类型。先把能把系统打断的硬错误清掉，再谈功能丰富度。建议：定时器分支先写成‘取当前时间变量 -> 计算 key -> 判断执行’，顺序别乱。”

人物二：Steve Jobs（体验导向）
“用户不会在意你用了多少 API，他们只在意‘提醒准不准、消息稳不稳、密钥安不安全’。把 key 暴露在链接里发到群里，是产品体验和安全双输。建议：改成服务端代理或短时签名 URL，至少不要把长期 key 直接暴露给终端用户。”

人物三：Tony Stark（工程效率派）
“你这重复代码像是让贾维斯手抄了两遍同一份说明书。短期能跑，长期会让维护成本爆炸。建议：把‘文本模板生成’和‘图片 URL 生成’抽成统一私有方法，命令和 LLM 工具都调用同一层，改一次全生效。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

[wzq10314]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sky

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

main.py

1. 框架适应性与生命周期问题 (严重)

• 生命周期方法未自动触发：代码中定义了 initialize() 和 terminate() 方法，但 AstrBot 框架通常并不会自动调用以这些名称命名的插件生命周期钩子（除非通过特定外部加载器调用）。如果未被调用，self._session 将永远为 None，导致后续调用 _fetch_json() 时触发条件 if self._session is None: return None，使得所有 API 请求默默失效。并且，_scheduler_task 也无法启动。
  建议：若需在框架加载时初始化，推荐监听专门的系统事件（如 @filter.on_astrbot_loaded()）进行初始化；或在 _fetch_json 中对 _session 进行懒加载检测与创建。
• 幽灵任务与资源泄露风险：同理，当热重载或停用插件时，若框架未调用 terminate()，旧的 _scheduler_loop 任务将继续在后台死循环运行，aiohttp.ClientSession 也未被安全关闭，导致内存泄露与多重消息推送异常。

2. 潜在的逻辑缺陷与可靠性问题

• 定时器时间漂移（Time Drift）：_scheduler_loop 中的定时机制使用了 await asyncio.sleep(60)。由于任务每次循环时，前面检查条件以及消息发送的时间不可控，会导致每一轮睡眠加上执行的时间大于 60 秒。长时间运行后会发生累积时间漂移。当漂移使得循环直接跨过 08:00 分钟的边界时，会导致定时推送失效。
  建议：动态计算距离下一个整分所需的精确秒数进行睡眠：await asyncio.sleep(60 - datetime.now().second)。
• 循环群发可能引起的阻塞串行：在 _push_daily_tasks 等推送任务中，对 self.push_groups 的遍历使用了串行的 await self.context.send_message(...)。如果部分群组网络响应极慢或卡死，会阻塞后续其他群组的发送，甚至影响定时器本体的准点运行。
  建议：使用并发处理，如 asyncio.create_task() 去包裹每一个发送行为，或使用 asyncio.gather()。

3. 代码质量与 Python 3.10 特性优化

• 类型提示优化：基于 Python 3.10 环境，建议使用内置类型 dict、list 代替 typing.Dict、typing.List，并使用联合类型运算符 | 代替 typing.Optional（例如：将 Optional[Dict] 简写为 dict | None），使代码更加简洁现代。

---

init.py

• 该文件符合常规模块导出规范，未发现任何安全漏洞、格式错误或运行隐患。

---

代码评审团

Linus Torvalds：看到那个 initialize 方法我就想骂人。你以为框架是你家开的？谁给你打的包票那个破生命周期方法会自动被调用？如果不调用，你的 _session 就是个大大的 None，然后网络请求全部默默失败却没有任何错误栈！别玩这种自作聪明的把戏，老老实实给我用懒加载创建会话，或者在框架明确提供的加载事件钩子里去初始化！不过，知道把文件写操作加个 _file_lock 锁起来，还不算蠢到家。

罗永浩：作为一个有情怀的开发者，你的定时任务写得让我有点难受。你用固定的 asyncio.sleep(60) 来做定时检查？你知道这会产生时间漂移吗？过几天你的机器人可能就完美错过了 08:00 整，变成 08:01 才醒过来，然后直接生硬地跳过当天的推送。这就好比你做了一个极其精致的表盘，但机芯是塑料糊的。赶紧改成动态计算到下一分钟的睡眠时间吧！还有，返回结果里那些 Emoji 符号排版挺不错的，非常考虑玩家的情感，这点值得表扬，但底子还得打牢啊朋友。

Rick (瑞克)：Wubba Lubba Dub Dub！听着，莫蒂，这家伙写了一个定时发送任务，然后把推送操作直接串联塞进了 for 循环里去 await！如果向某个废柴群组的发送卡住了，或者遇到了超时，你整个循环都会跟着一起停滞！这就像你在用一把被诅咒的传送枪，跳跃只要失败就会死在多维宇宙的半路！听着，使用 asyncio.create_task 为每个群组的发送开个独立的协程并发，别让一个愚蠢的网络波动毁了你整个宇宙的推送计划！至于你的 __init__.py 倒是很干净，像刚洗过的脑子一样，没啥毛病。

---

🔍 审核摘要

统计信息

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

main.py
__init__.py

---

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

[wzq10314]

还有哪里有比较严重的问题嘛，求审核看看😭这个apikey不要紧 因为完全是免费的！

[wzq10314]

@astrpluginreviewer review