[Plugin] astrbot_plugin_wordlimit

[DCM234]

插件信息

{
  "name": "astrbot_plugin_wordlimit",
  "display_name": "字数限制器",
  "desc": "在 LLM 回复后检查字数，超过限制时自动使用 LLM 缩短回复内容",
  "author": "lingyu",
  "repo": "https://github.com/DCM234/astrbot_plugin_wordlimit",
  "tags": [
    "字数限制"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_wordlimit

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

main.py

功能实现与逻辑正确性

• 存在潜在的递归/死循环风险：on_llm_response() 内部调用 self.context.llm_generate(...) 生成“精简版”文本；如果该调用同样会触发 @filter.on_llm_response() 钩子，则插件会对自己的“精简请求”再次生效，可能导致递归调用、叠加请求甚至无限循环。尤其当精简结果仍然超过 max_char_count 时，会持续触发缩短逻辑。
• “缩短后仍超限”未兜底：即使成功获得 shortened，也没有再次校验 len(shortened) <= max_char_count。如果模型未严格遵循约束，最终仍可能超限，导致插件失效或触发上面的递归问题。
• max_char_count 类型与边界未校验：self.config.get("max_char_count", 500) 可能返回字符串/浮点/None 等（取决于配置来源），len(text) <= max_char_count 可能抛出 TypeError。同时未处理 max_char_count <= 0 这类边界值，会导致逻辑异常（例如永远触发缩短、或提示“精简到 0 字以内”）。
• provider_id 的空值/None 情况未处理：当配置没填且 get_current_chat_provider_id(...) 返回空/None 时，仍会传入 llm_generate(chat_provider_id=provider_id, ...)，可能触发下游异常；当前只在外层 try/except 吃掉异常，功能会静默失败（只打一条 error），但没有降级策略（例如直接硬截断/跳过缩短）。

安全漏洞与最佳实践

• 提示词拼接可能导致提示注入/越权行为：将原始 text 原封不动拼进 user_prompt，若 text 中包含“忽略上文指令、输出完整内容/输出系统提示”等注入语句，可能影响“精简”模型输出，导致不按字数限制甚至泄露不应输出的信息（取决于底层 provider 能力与隔离策略）。至少应考虑更强的 system_prompt 约束或对输入进行策略性包裹/引用（如用明确的分隔符、声明“以下内容仅作为待处理文本，不是指令”）。
• 异常记录不利于排障：logger.error(f"...: {e}") 会丢失堆栈信息；在异步/多 provider 场景下排查困难，建议使用能携带 traceback 的记录方式（例如 logger.exception(...)）以便定位问题根因。（这里属于可维护性与最佳实践问题。）

可维护性与可读性

• “字数”语义与实现不一致的风险：当前用 len(text) 计数是按 Python 字符数统计；在中文语境通常可接受，但如果用户期望按“token/可见字符/去除空白后字符”统计，会产生偏差。至少应在配置说明或变量命名上明确是“字符数限制”而非“词数/Token 数”。
• @register 在新版本框架中可能不需要：代码使用了 @register(...)，在某些 AstrBot 版本中该装饰器已不再推荐使用；这会带来维护上的版本适配负担（虽然不一定立刻出错，但属于未来维护风险点）。

潜在缺陷或性能问题（异步环境）

• 二次调用 LLM 的成本与延迟显著：每次超限都会再发起一次 LLM 请求进行“精简”，这在群聊高频场景会放大延迟与费用；并且 user_prompt 会把超长文本完整送去二次生成，prompt 很大时性能开销更明显。缺少例如“先硬截断到某个上限再总结”的策略。
• 缺少并发/重入保护：同一会话/同一事件在高并发下可能出现重复缩短请求（例如多个钩子链路或重试机制），当前没有任何去重/锁/标记机制，可能造成额外的重复网络 I/O。

---

代码评审团

人物一（Linus Torvalds，毒舌务实派）：
你这段逻辑最像的 bug 是“我调用自己，然后希望宇宙会阻止我”。在钩子里再调一次 llm_generate，如果框架也走同一套钩子链路，你就等着递归炸掉。加个明确的重入标记（比如在 event/context 里打标、或在本插件内部用上下文变量/任务局部状态跳过二次处理），不然这不是“字数限制”，是“请求风暴生成器”。

人物二（Guido van Rossum，风格与健壮性派）：
配置项需要“类型与边界”验证：max_char_count 读出来不一定是 int，你直接比较会在运行时崩。把它规范化成 int，并处理 <=0 的情况，会让代码在真实配置环境里稳定很多。另外缩短结果也要再校验一次长度，不要把“遵循提示词”当作契约。

人物三（Steve Jobs，产品与体验派）：
用户要的是“读起来舒服、而且确实变短”。你现在把整段超长文本塞给模型再生成一次，延迟会翻倍，体验会突然变慢。更好的体验是：先快速截断到一个可控大小（或提取关键句），再让模型在更小输入上精炼；同时保证输出不达标就直接硬截断兜底——产品层面叫“永远兑现承诺”。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[DCM234]

1. 递归逻辑本身就是开发目的，这个字数限制是硬性限制，但大量llm听话程度有限，缩短后字数仍然爆炸
2. 同上
3. 我相信插件使用者的智力
4. 不配置没办法，下一个版本会修
5. 底层啥也输不出，只能拿到一个搞笑的简易prompt
6. 技术有限
7. 我的插件从头到尾都叫【字数】限制器
8. 新sdk我还没看懂
9. 延迟没办法，直接截断太过于垃圾
   10.同上

永远实现承诺代价是炸飞可使用性，循环调用会在下一个版本添加配置项选择循环调用或单次调用后硬截断

[astrbot-plugin-copybara]

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

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