[Plugin] astrbot_plugin_content_safety_guard

[Kalospacer]

插件信息

{
  "name": "astrbot_plugin_content_safety_guard",
  "display_name": "阿瓦隆Avalon",
  "desc": "内容安全守卫 - 拦截用户提示词攻击和模型输出偏离人设问题，支持前置/后置审核、关键词匹配、LLM自审查、黑名单等功能",
  "author": "Kalospacer",
  "repo": "https://github.com/Kalospacer/astrbot_plugin_content_safety_guard",
  "social_link": "https://github.com/Kalospacer"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_content_safety_guard

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

main.py

1. 逻辑正确性与 JSON 解析隐患
在 _parse_llm_audit_result 与 _parse_combined_audit_result 方法中，使用非贪婪正则 re.search(r"\{.*?\}", text, re.S) 来提取大模型返回的 JSON。如果 LLM 生成的 JSON 内部包含花括号（例如 {"safe": false, "reason": "包含了{敏感内容}"}），该正则匹配会在第一个内层 } 处提前截断！这将导致 json.loads 抛出 JSONDecodeError 并且被静默捕捉，代码会无奈地落入低级的 fallback 匹配中，极大地降低了 LLM 自审查的准确度。建议使用 text[text.find('{'):text.rfind('}')+1] 或其他更严谨的方式提取 JSON。

2. 代码质量与异常控制流滥用
在 _check_keywords 方法内，代码直接将任意 keyword 交由 re.search 执行，若抛出 re.error 异常，才在 except 块中退化为普通的 in 字符串判断。利用异常来做常规的控制流判断是不规范的（"Ask for forgiveness not permission" 不该用在业务可预见的逻辑分支上）。此外，如果用户输入的是一个恰好合法的复杂错误正则，可能会引发意外的匹配或极耗性能的回溯。建议在配置文件中明确区分纯文本匹配和正则匹配，或者在需要纯文本匹配时显式使用 re.escape。

tests/test_slash_block.py

1. 可维护性与存根(Stub)对象构建方式
在 install_astrbot_stubs 中，代码手动编写了大量的 Dummy* 类并通过直接篡改 sys.modules 来模拟 AstrBot 的运行环境。虽然这种做法在当前能有效隔离依赖，但在框架 API 演进时极难维护，且代码显得极为冗长。建议使用标准库 unittest.mock 中的 MagicMock 配合 patch.dict('sys.modules', ...) 来进行更优雅、更少侵入性的测试环境打桩。

---

代码评审团

Linus Torvalds：
老天，你在 _parse_llm_audit_result 里写的那个提取 JSON 的正则表达式 r"\{.*?\}" 简直是一场灾难！非贪婪匹配？你认真的吗？你指望大模型乖乖输出的 reason 字段里永远不会出现任何花括号？一旦出现，你的匹配就会当场被腰斩，产生一堆无法被 json.loads 解析的垃圾碎片。然后你居然写了一个空的 except (json.JSONDecodeError, ValueError): pass 把它直接吞掉？这意味着你的程序发生了灾难，而你不仅不修复它，还假装什么都没发生一样滑向下面那个简陋的字符串 fallback。看在上帝的份上，用 rfind('}') 找到真正的结尾，别再用这种幼稚的正则去处理嵌套结构了！

乔布斯 (Steve Jobs)：
伟大的产品需要内外兼修的优雅，但我在 _check_keywords 这个函数里只看到了妥协和混乱。你试图把用户的关键词直接扔进正则表达式的引擎里，如果引擎崩溃抛出了 re.error，你就委曲求全地退回到普通的文本匹配。这种连蒙带猜的执行逻辑，是对代码艺术的亵渎。为什么不从一开始就给用户一个清晰的设计——告诉他们哪些是正则表达式，哪些是普通文本？或者为普通文本披上一层 re.escape() 的外衣？你本可以掌控全局，但你却选择了把判断权交给异常捕获机制，这太不“Apple”了。

雷军 (Lei Jun)：
兄弟们，这个插件做的还是非常符合实际业务场景的，特别是这个多次调用大模型重试的 on_llm_response_hook，思路很酷，能感觉到是真正在解决用户遇到安全拦截时体验不好的痛点。不过我还是要提个醒，在重试的 for attempt in range(1, self.max_retries + 1) 循环里，你们对同一个 prompt 加上了警告词去反复请求大模型。但是遇到一些比较“死脑筋”的大模型，它可能怎么改都不合规。这种不断发起的 API 请求可是要消耗 token 和网络资源的，很贵的啊！建议以后可以加入动态退避策略或者切换到一个更严格的 System Prompt，尽量一次搞定。Are you OK 啦，总的来说 AstrBot 框架的规范你跟得很严，值得点个赞！

---

🔍 审核摘要

统计信息

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

main.py
tests/test_slash_block.py

---

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

当前仓库：Kalospacer/astrbot_plugin_content_safety_guard
剩余触发次数：4

[zouyonghe]

后续可以根据review再完善一下

[astrbot-plugin-copybara]

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

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