[Plugin] astrbot_plugin_lyubishchev

[LynieCN]

插件信息

{
  "name": "astrbot_plugin_lyubishchev",
  "display_name": "柳比歇夫时间管理插件",
  "desc": "通过柳比歇夫时间管理方法让Astrbot帮助你进行时间管理，只适合个人使用",
  "author": "Lynie",
  "repo": "https://github.com/LynieCN/astrbot_plugin_lyubishchev",
  "tags": [
    "工具",
    "日常",
    "时间管理",
    "记录查询"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_lyubishchev

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

main.py

1. @filter.command_group("lyu") 方法签名不符合你给定的专项规则
   def lyu(self) -> None 未包含 event 参数。按你给的严格规则（除 on_astrbot_loaded 外，所有 @filter 装饰的监听方法都要有 event），这里属于不合规点。

2. 用户可见错误信息存在“原始异常直出”问题
   _parse_rule_spec() 中 custom: 分支直接 int(...)，当输入如 custom:abc 时会抛出 Python 原始 ValueError 文本，最终在 lyu_rule_add 里返回给用户（规则格式错误：invalid literal...）。这会造成用户体验和可读性问题。

3. 记录已成功入库后，后置反馈流程异常可能导致指令整体失败
   lyu_note 在 create_record 成功后，直接进入 _build_record_created_reply() / _build_batch_record_reply_with_feedback()，但未对反馈生成链路异常做兜底。若后续 LLM/会话处理报错，可能出现“数据已写入但用户收到失败或无响应”的不一致体验。

---

init.py

（未发现需要报告的问题）

---

scheduler.py

1. 规则调度失败仅记录日志，不做状态降级或修复标记
   _schedule_rule() 捕获异常后仅 logger.error，数据库内规则仍可能保持 enabled=1，后续 reload_rules() 会反复尝试并重复报错，形成“坏规则持续扰动”。

2. reload_rules() 全量移除并重建任务，缺少差量更新策略
   当前实现每次都移除全部 job 再重建，规则量增大时会造成不必要调度抖动；在边界时刻还可能引入“刚好重载时错过触发窗口”的风险。

---

service.py

1. 存在明显的“过时代码 + 调用签名不一致”缺陷
   _generate_record_feedback_reference() 调用了 _generate_record_feedback_with_llm(...)，但传参使用 record=...，而实际方法签名是 records=..., failures=...。该路径一旦被调用会直接 TypeError。

2. 异常兜底不足：_generate_current_bot_reply() 关键链路可能向上抛出异常
   build_main_agent(...)、step_until_done(...) 等步骤没有统一 try/except。上层如 generate_records_feedback() 首次调用该方法时也未包裹异常，可能导致命令处理流程被中断。

3. 重复实现较多，维护成本高且易引入行为漂移
   例如 _feedback_signal_summary_reference 与 _build_feedback_signal_summary、若干 _..._reference 方法与现行方法并存，语义重叠。当前已出现签名漂移，后续继续演化时风险更高。

4. 潜在性能问题：每次反馈都解析整段会话历史 JSON
   _get_recent_chat_lines() 对 conversation.history 执行完整 json.loads 后再倒序截取，历史很长时会放大 CPU 和内存开销，且该路径在高频记录场景会反复触发。

---

storage.py

1. ID 前缀解析未转义 SQL LIKE 通配符，存在匹配歧义风险
   _resolve_record_id_sync() / _resolve_rule_id_sync() 使用 LIKE '{prefix}%'，若前缀中含 %、_ 会被当通配符，导致非预期匹配范围和歧义。

2. 记录 ID 解析未排除已删除记录
   _resolve_record_id_sync() 不过滤 status='active'，可能命中已软删除记录，进而影响上层 show/amend/delete 行为一致性。

3. memory_chunks 唯一键未包含 session_id，存在跨会话覆盖隐患
   当前唯一约束为 UNIQUE(source_type, source_id)。若出现跨会话相同 source_id（数据迁移/外部导入/异常写入场景），会触发“后写覆盖前写”。

---

代码评审团

人物一：Linus Torvalds（直给型）
“你这套功能是能跑的，但 service.py 那批 _reference 代码像‘遗留地雷区’——签名都漂移了还在仓库里，迟早炸。建议：删掉不用的分支，保留一条唯一真实路径，先把可执行面收窄。”

人物二：Steve Jobs（产品体验导向）
“用户不该看到 invalid literal for int() 这种工程师语。main.py 规则解析错误要做成‘人话’，否则再强的功能也会在交互细节上掉分。建议：统一异常映射层，所有命令参数错误都走同一套友好文案。”

人物三：Geralt of Rivia（务实猎魔人风格）
“怪物不只会正面来。_generate_current_bot_reply 缺少全链路异常护甲，一旦 LLM/Agent 那边抖一下，就把主流程带崩。建议：把‘已入库’与‘反馈生成’解耦，反馈失败时回退模板，别让用户替你扛异常。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
scheduler.py
service.py
storage.py

---

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

当前仓库：LynieCN/astrbot_plugin_lyubishchev
剩余触发次数：2