[Plugin] astrbot_plugin_maskoff

[Yue-bin]

插件信息

{
  "name": "astrbot_plugin_maskoff",
  "display_name": "识人术",
  "desc": "防止你的小llm因为别人把名字改成你的就认错人",
  "author": "Moncak",
  "repo": "https://github.com/Yue-bin/astrbot_plugin_maskoff",
  "tags": [
    "llm",
    "多人聊天",
    "用户识别"
  ],
  "social_link": "https://github.com/Yue-bin"
}

这是一个插件版本更新请求

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_maskoff

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

main.py

1. 代码质量与编码规范

• 命名规范: is_nickname_contain_and_id_mismatch 函数命名虽然表意明确，但过于冗长，建议简化为 check_fuzzy_match 或类似名称，并通过文档字符串解释其行为。
• 类型提示: parse_id_map_list 使用了 list[dict[str, str]]，符合 Python 3.10 的 PEP 585 标准，写法规范。

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

• 潜在的误报逻辑 (False Positive):
  在 is_nickname_contain_and_id_mismatch 方法中：

  if expected_nickname in nickname and expected_id != user_id:
      return True, expected_nickname

  这种包含匹配（Substring Matching）逻辑非常激进。

  • 场景: 假设映射表中有 {'Admin': '1001'}。
  • 问题: 如果一个合法用户名为 "Administrator" (ID: 2002) 进入对话，"Admin" in "Administrator" 为真，且 ID 不匹配，系统会判定为冒充者并修改 Prompt。这可能导致无辜用户被误判。
  • 建议: 建议增加边界检查，或者仅在某些特定字符（如空格、括号）分隔时才判定为包含，或允许配置“严格匹配模式”。

• 循环中断过早:
  同上方法，一旦发现第一个满足条件的 expected_nickname 就会立即返回。如果映射表中存在多个相互包含的键（例如 "Test" 和 "TestUser"），匹配顺序将依赖于字典的迭代顺序（虽然 Python 3.7+ 字典有序，但逻辑上仍可能产生非预期的优先匹配）。

3. 安全漏洞与最佳实践

• Prompt 注入风险:
  代码将 warning_msg 和 notice_msg 直接追加到 req.system_prompt 中。虽然这是为了警告 LLM，但如果攻击者能够巧妙构造自己的 nickname（虽然 AstrBot 获取的昵称通常经过清洗，但平台实现各异），可能会干扰 LLM 的上下文。
  • 建议: 确保 nickname 在放入 Prompt 模板前进行适当的转义或清洗，虽然通常风险较低，但作为“识人”插件，应考虑到昵称中包含特殊指令的情况。

4. 可维护性与可读性

• 配置容错性: 在 parse_id_map_list 中，使用了 item.get("nickname") 和 item.get("user_id")。如果配置文件格式有误（例如键名拼写错误），该条目会被静默忽略。建议添加一条 logger.debug 或 logger.warning 来提示被跳过的无效配置项，方便用户排查。

5. 框架适应性检查

• 导入检查: filter, Star, AstrMessageEvent 等导入均符合规范。
• 事件钩子: check_id 使用了 @filter.on_llm_request()，且正确定义了 async def check_id(self, event: AstrMessageEvent, req: ProviderRequest) 三个参数，符合 v3.5.20+ 的规范。
• 消息发送: 在 LLM 请求钩子中仅修改了 req 对象，未使用 yield 或发送消息，符合设计规范。

---

代码评审团

Linus Torvalds

“你的 is_nickname_contain_and_id_mismatch 函数名字长得像在写 Java。更糟糕的是里面的逻辑——用简单的 in 操作符做身份验证？如果我的名字是 'Linux Kernel Fan'，而你把 'Linux' 映射到了别人身上，我就成冒牌货了？这种模糊匹配简直是在邀请误报，要么把它删了，要么写个像样的正则边界匹配。代码能跑不代表它是对的。”

GLaDOS (Portal)

“哦，看起来你在这个插件里加入了一些... 偏执。为了防止那个名叫‘Subject #458’的人把名字改成‘Chell’来骗取蛋糕，你建立了一个列表。很有趣。但是，你的算法似乎连‘Michelle’也会误认为是那个哑巴测试对象。这种宁可错杀一千的策略... 嗯，我很欣赏。继续保持这种对他人的极度不信任，这对科学很有帮助。”

福尔摩斯 (Sherlock Holmes)

“这不仅仅是识人术，这是基于数据的演绎推理，虽然略显粗糙。你试图通过昵称和ID的矛盾来揭露伪装者，这很好。但你忽略了‘部分与整体’的谬误。当一个嫌疑人的名字包含另一个人的名字时，并不意味着他在伪装。名字是线索，但不是证据链的全部。如果不修正那个包含匹配的逻辑漏洞，你的推理将在法庭上... 或者说在聊天记录里，彻底崩溃。”

---

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

---

🔍 审核摘要

统计信息

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

main.py

---

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