[Plugin] astrbot_plugin_prompt_inject

[Zhalslar]

插件信息

{
  "name": "astrbot_plugin_prompt_inject",
  "display_name": "提示词注入器",
  "desc": "根据用户消息内容，自动向 LLM 注入预设提示词，从而临时或持续影响 AI 的回复行为, 支持在面板设置多套提示词和触发行为",
  "author": "Zhalslar",
  "repo": "https://github.com/Zhalslar/astrbot_plugin_prompt_inject",
  "tags": [
    "提示词",
    "prompt",
    "注入"
  ],
  "social_link": "https://github.com/Zhalslar"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_prompt_inject

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

以下是针对所提供文件的代码审查报告。

---

main.py

代码质量与编码规范

1. 无效的日志导入: 代码第 1 行 from astrbot import logger 违反了框架规范。必须从 astrabot.api 导入 logger（即 from astrbot.api import logger）。
2. 类型提示不准确: 在 on_llm_request 等方法中，event.unified_msg_origin 被赋值给 umo。在 AstrBot 中，unified_msg_origin 通常是一个对象（如 Pydantic 模型）而非字符串。虽然它可能作为字典键工作（如果是可哈希的），但在 core/session.py 等处将其类型标记为 str 是误导性的，且可能导致类型检查错误。建议使用 Any 或导入正确的类型，或在使用前显式转换为 str(umo)。

功能实现与逻辑正确性

1. 潜在的 NoneType 错误: 在 on_llm_request 方法中，代码直接执行 req.system_prompt += ...。虽然 AstrBot 通常初始化此字段，但在某些边缘情况或特定 Provider 实现下，system_prompt 可能为 None。建议在拼接前进行空值检查或初始化：req.system_prompt = (req.system_prompt or "") + ...。

可维护性与可读性

1. override_same_priority 逻辑: 该函数通过两次反转列表来实现同优先级去重（保留最后一个）。虽然逻辑正确，但注释可以更明确地指出“保留列表中靠后的同优先级项”。

---

core/config.py

代码质量与编码规范

1. 无效的日志导入: 代码第 5 行 from astrbot import logger 违反了框架规范。必须从 astrabot.api 导入 logger。

可维护性与可读性

1. 过度设计 (Over-engineering): ConfigNode 类实现了一个复杂的对象-字典映射（ORM-like）层，包含递归属性访问和元编程（get_type_hints）。对于一个插件配置来说，这种实现大大增加了代码复杂度，使得调试和维护变得困难。简单的 Pydantic 模型或直接字典访问通常更易读且不易出错。
2. _is_optional 的脆弱性: 手动解析 Union 类型来判断 Optional 是比较脆弱的实现，容易随着 Python 版本更新而失效。

---

core/prompt.py

代码质量与编码规范

1. 导入规范: 此文件正确使用了 from astrbot.api import logger，符合规范。

潜在缺陷或问题

1. 严重的性能隐患: 在 match_prompts 方法中，代码在一个嵌套循环里调用 re.search(pattern, text)。

   for prompt in self.enabled_sorted_prompts():
       for pattern in prompt.regexs:
           re.search(pattern, text) # 性能瓶颈

   这意味着对于每条用户消息，都会重新处理所有正则字符串。虽然 Python 的 re 模块有内部缓存，但最佳实践是在 PromptItem 初始化时使用 re.compile 预编译正则表达式，以避免重复的字符串哈希计算和缓存查找开销。

功能实现与逻辑正确性

1. PromptItem 状态管理: PromptItem 继承自 ConfigNode。ConfigNode 旨在处理配置数据，但 PromptItem 混入了运行时状态（_activated_at, _inject_count）。虽然通过下划线前缀避开了配置保存逻辑，但这破坏了“配置对象”的单一职责原则。

---

core/session.py

潜在缺陷或问题

1. 内存泄漏风险: SessionCache 使用一个字典 self._data 存储会话状态。目前的实现中，仅在调用 get 方法时清理该特定 umo 的过期 prompt。如果一个用户（umo）在激活 prompt 后再也不发送消息，该用户的条目（包含 prompt 对象）将永远保留在内存中。缺乏一个全局的过期清理机制（TTL）或定期清理任务。

代码质量与编码规范

1. 类型提示不匹配: get, activate, deactivate 方法的签名中 umo 被标注为 str，但 main.py 传入的是 unified_msg_origin 对象。这会导致静态类型检查失败，并且如果 unified_msg_origin 对象不可哈希，会在运行时抛出异常。建议显式转换为字符串或修正类型提示。

---

代码评审团

Linus Torvalds:
“我在 core/prompt.py 里看到了什么？在双重循环里直接跑 re.search？即使 Python 有缓存，这也是在浪费 CPU 周期。把正则预编译好能杀了你吗？还有那个 ConfigNode 类，简直是过度设计的典型教材。如果你想把字典变成对象，用 dataclass 或者 Pydantic，别自己造一个蹩脚的轮子，这只会让看代码的人想把键盘摔到显示器上。”

Steve Jobs:
“这个设计的‘品味’不够。你在 main.py 和 core/config.py 里导入 logger 的方式是错误的，这就像是给法拉利装了拖拉机的排气管——它不仅难看，而且违反了框架的规则。简单即是极致的复杂，但 ConfigNode 并不简单，它是混乱的。你需要剥离那些不必要的层级，让代码像用户体验一样流畅。”

GLaDOS (Portal):
“看来你在 core/session.py 里制造了一个很棒的‘内存黑洞’。你把会话数据存进去，如果用户不再说话，那些数据就永远留在那里，像一个个无用的实验体。没有清理机制？多么令人失望。不过，这也算是一种永久的‘保存’方式，不是吗？另外，你的 umo 类型提示在撒谎。永远不要对测试计算机撒谎。”

---

🔍 审核摘要

统计信息

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

main.py
core/config.py
core/prompt.py
core/session.py

---

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