[Plugin] astrbot_plugin_chat_polisher

[cyilin36]

插件信息

{
  "name": "astrbot_plugin_chat_polisher",
  "display_name": "最终文本润色",
  "desc": "自动将输出的回复文本内容截取，并通过设定的规则进行润色后发出。",
  "author": "cyilin",
  "repo": "https://github.com/cyilin36/astrbot_plugin_chat_polisher",
  "tags": [
    "润色",
    "校对"
  ],
  "social_link": "https://cyilin36.github.io/"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_chat_polisher

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

main.py

功能实现与逻辑正确性

• 存在潜在“自触发/递归调用”风险：force_polish_before_send() 在 on_decorating_result 钩子里再次调用 provider.text_chat()。若 AstrBot 的实现会对该调用同样走一遍消息生成/装饰管线（或触发相同钩子），可能导致重复润色甚至无限递归。建议加“防重入”标记（如 contextvars.ContextVar / event 上打标记 / 在 provider 调用时显式关闭本插件对该次请求的处理）。
• 消息链替换逻辑会破坏原有组件相对顺序：_replace_plain_text() 会删除所有 Comp.Plain，再把润色文本插入到“过滤后的链”的某个索引。对于链中存在“文本-非文本-文本”交错的情况，会把润色文本插入到不符合原始结构的位置，导致非文本组件（如图片、@、引用）相对文本的位置发生变化。
  • 典型例子：[Image1, Plain1, Image2, Plain2] 会变成 [Image1, PlainPolished, Image2]，其中 Image2 原本夹在两段文本之间，现在被移动到润色文本之后。
  • 更稳妥的做法：仅替换第一个 Plain 的内容为润色文本，并删除其余 Plain，但保持所有非 Plain 组件在原链中的位置不变（单次线性扫描即可做到）。
• 提取文本会跨组件“无分隔拼接”导致语义偏差：_extract_plain_text() 直接 join 所有 Plain 文本，若中间原本夹着图片/引用/换行分段等语义边界，润色模型看到的是“粘连”的文本，可能改变语气或结构。至少应考虑在不同 Plain 片段之间插入合理分隔（如 \n），或只润色连续的 Plain 段。

异步与并发/稳定性

• 缺少超时控制，可能拖死发送链路：润色发生在发送前钩子里，一旦 provider.text_chat() 网络抖动/卡住，会直接延迟整条消息发送。建议用 asyncio.wait_for() 加可配置超时，并在超时后回退原文。
• 未显式处理取消（Cancellation）：在发送链路中任务被取消是常见情况；目前 except Exception 会把取消也吞掉的风险取决于 CancelledError 的继承层级（Py3.10 中 asyncio.CancelledError 继承自 Exception）。若被吞掉会导致任务无法及时取消。建议显式：
  • except asyncio.CancelledError: raise
  • 其余异常再记录并回退。

日志与可观测性

• 异常日志缺少堆栈：logger.error("[chat_polisher] 调用润色模型失败: %s", exc) 只记录字符串，排障困难。建议改用 logger.exception(...)（保留堆栈）或 logger.error(..., exc_info=True)（若框架 logger 支持）。

代码质量与可维护性

• @register 在新版本可能是冗余：你同时满足“继承 Star 的类”与“@register 装饰器注册”。在 AstrBot v3.5.20+ 之后装饰器已废弃（框架会自动发现 Star 子类），继续保留可能造成维护困惑（甚至在极端情况下出现重复加载/重复注册语义差异）。建议明确目标版本策略：要么完全依赖自动发现，要么保留但在注释里说明原因。
• 类型标注偏弱，降低可读性/IDE 推断：chain: list、new_chain: list、provider 未标注具体协议/类型；在异步插件里这会让后续维护者难以确认 result.chain 的组件类型约束与 provider API。建议至少把 chain 写成 list[Comp.BaseComponent]（以框架实际基类为准）或定义 Protocol。

安全与最佳实践

• 数据外发边界不清晰：插件会把“即将发送的最终文本”转发给另一个 provider（可由配置指定或回退），这在隐私/合规上属于二次外发。虽然这不是传统代码漏洞，但属于安全边界问题：建议在配置/README/日志中明确提示，并提供开关或对特定会话/群禁用能力（例如仅对某些 origin 启用）。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你这 _replace_plain_text() 属于“看起来像保持顺序，实际在偷偷洗牌”。消息链是结构化数据，不是随手 filter 一下再塞回去就完事了；把 Plain 全删了再插入，碰上交错组件直接改语义。老老实实单次遍历：遇到第一个 Plain 就替换文本，其余 Plain 跳过，其他组件原样追加——简单、可预测、不会把链搞乱。

人物二（Grace Hopper，强调可调试与工程化）：
你捕获异常却不带堆栈，这会让线上问题变成“神秘学”。网络请求失败、provider 返回异常格式、超时……这些都需要可观测性。把 logger.error 换成 logger.exception，再加上超时与取消处理，才能在异步系统里做到“能跑、能查、能恢复”。

人物三（Rick Sanchez，脑洞大但有建设性）：
在发送前钩子里再调一次 LLM？可以，但你最好别把宇宙撕开个洞：如果这次 text_chat 也走同一套装饰管线，你就可能进入润色的“无限镜像房间”。加个防重入标记（哪怕是 contextvar 的一个布尔值）就能避免自我吞噬。顺便，给润色加超时，不然一次卡顿就让整条消息“时间停止”——这可比外星人入侵还烦。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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