[Plugin] astrbot_plugin_sadstory

[Towqs]

插件信息

{
  "name": "astrbot_plugin_sadstory",
  "display_name": "伪装聊天",
  "desc": "在群聊中以合并转发消息的形式展示伪装聊天，支持 LLM 生成、Prompt 风格管理、故事模板参考、自定义角色等",
  "author": "Towqs",
  "repo": "https://github.com/Towqs/astrbot_plugin_sadstory",
  "tags": [
    "QQ",
    "聊天",
    "故事",
    "转发"
  ],
  "social_link": "https://github.com/Towqs"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sadstory

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

main.py

1. 配置解析对类型过于乐观，存在运行时崩溃风险（逻辑正确性）

   • self._parse_int(cfg.get(...)) / self._parse_list(cfg.get(...)) 假设配置值是字符串，并直接调用 .strip()。
   • 若 WebUI/配置系统返回的是 int、list、bool，会触发 AttributeError（_parse_int 仅捕获了 ValueError，兜不住）。
   • 影响：插件在 _reload_config() 阶段可能直接报错，命令不可用。
   • 建议：统一先 str() 再处理，或按类型分支处理；_parse_int 至少捕获 TypeError/AttributeError。

2. bystander_count=0 时会触发空列表随机选择异常（边界条件）

   • _generate_story() 中允许 bystander_count 配置为 0，bystanders=[]。
   • 后续 role_map.get(speaker, random.choice(bystanders)) 会在未知 speaker 时触发 IndexError: Cannot choose from an empty sequence。
   • 影响：特定配置下故事生成稳定失败。
   • 建议：确保最少 1 个旁观者，或 fallback 到主角而不是 random.choice([])。

3. 共享可变状态在异步并发下有竞争风险（异步最佳实践）

   • self.user_pool、self.group_users、self.cooldown_map 都是实例级共享状态，多个群/多个管理员同时触发命令时可能并发读写。
   • random.shuffle(users) 还是原地打乱（users 实际就是 self.user_pool 引用），会引入跨请求副作用。
   • 影响：角色分配、用户池顺序、冷却行为在并发下不可预测。
   • 建议：
     • 对用户池使用拷贝：users = list(self._get_available_users())；
     • 冷却检查与设置做原子化（如 group 级锁）；
     • 对共享状态更新加 asyncio.Lock 或拆分为不可变快照。

4. 冷却机制可被并发绕过（逻辑正确性）

   • 当前流程是先 _check_cooldown()，成功后才在发送完成时 _set_cooldown()。
   • 两个并发请求可在同一时刻都通过检查并同时生成/发送故事。
   • 影响：冷却限制失效，造成刷屏和额外 LLM 开销。
   • 建议：按群加锁，或在通过检查后立即预占冷却（失败再回滚）。

5. “虚拟用户模式”与“素材群拉取”逻辑冲突（功能实现）

   • 即使 use_virtual_users=True，只要配置了 source_group_id，sadstory() 仍会优先尝试拉群成员并写入 user_pool。
   • _get_available_users() 里又是“user_pool 非空就优先返回”，导致虚拟模式可能被真实群成员覆盖。
   • 影响：配置语义与实际行为不一致，运维排查困难。
   • 建议：在虚拟模式下明确禁止/跳过群成员拉取，或增加优先级配置并在日志里明确说明。

6. 用户输入主题未做长度/内容约束，存在成本与滥用风险（安全与稳定性）

   • theme 直接拼入 prompt，未限制长度。
   • 影响：可被超长输入放大 token 消耗，增加响应时延与费用，甚至触发上游限流。
   • 建议：对主题做长度上限（如 50~200 字）和基础清洗。

---

代码评审团

人物一：Linus Torvalds（直球型）
“你这共享状态在异步里到处裸奔，shuffle 还直接改全局列表，等于在并发下玩俄罗斯轮盘。先把状态隔离和锁补上，再谈优雅。”

人物二：Steve Jobs（产品体验型）
“配置项应该‘所见即所得’。用户勾选了虚拟模式，却可能被真实群成员覆盖，这是产品语义不统一。把模式优先级设计清楚，体验会立刻上一个台阶。”

人物三：Deadpool（吐槽型）
“bystander_count=0 然后 random.choice([])？这不是剧情反转，这是程序自爆。边界值就是用来搞崩你的，先把它们驯服。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：Towqs/astrbot_plugin_sadstory
剩余触发次数：4

[Towqs]

@astrpluginreviewer代码已更新，麻烦重新审核

[Towqs]

@astrpluginreviewer review

[astrpluginreviewer]

❌ 插件审核失败

您好！在对您的插件进行审核时遇到了问题：

验证metadata.yaml失败:
- metadata.yaml中的desc字段 "在群聊中以合并转发消息的形式展示伪装聊天，支持 LLM 生成、Prompt 风格管理、故事模板参考、自定义角色等" 与JSON中提交的desc "在群聊中以合并转发消息的形式展示伤感故事，支持 LLM 生成、故事模板参考、自定义角色、群白名单等" 不一致

---

请根据上述问题进行修改。修改完成后，请在 Issue 正文 中勾选"重新提交审核"复选框以再次触发审核。

此消息由系统自动生成

当前仓库：Towqs/astrbot_plugin_sadstory
剩余触发次数：4

[Towqs]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sadstory

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

main.py

1. 冷却逻辑存在并发竞态条件（异步环境）
   _check_cooldown() 和 _set_cooldown() 分离调用且无锁保护。并发触发同一群命令时，可能多个请求都通过冷却检查，导致冷却失效。

2. 冷却时间在“生成前”就被消耗
   在 sadstory() 中先 _set_cooldown()，后调用 LLM 生成与发送。若生成失败/发送失败，用户仍进入冷却，属于逻辑体验问题（失败请求不应消耗冷却）。

3. 用户池为全局共享，存在跨群污染风险
   self.user_pool/self.group_users 是插件级全局状态，不按群隔离。

   • 某群动态加入的 @用户（forced_protagonists）会永久写入全局池；
   • 在另一个群调用时可能被随机到，造成“跨群身份串用/伪造感”。

4. 昵称作为角色映射键，存在重名冲突
   _generate_story() 中 role_map 用昵称做 key。QQ群里重名很常见，会把 A 的台词映射到 B 的 user_id，导致转发消息“说话人错位”。

5. LLM JSON 提取方式脆弱
   多处通过 find("[")/rfind("]") 或 find("{")/rfind("}") 截取 JSON。若模型输出里出现额外括号（解释文本、示例片段），会截错并解析失败。

6. 未对 LLM 返回消息条数做二次约束
   虽在 prompt 里要求 min/max，但代码未在解析后再次裁剪。模型超量输出时，可能造成超长合并转发、平台拒发、性能抖动。

7. 双主角模式与“自定义风格模板变量”不兼容风险
   双主角模式需 {protagonist_a}/{protagonist_b}，但 sadstory_addstyle/sadstory_aistyle 强制校验的是单主角变量 {protagonist}。导致双主角场景可能出现未替换占位符，影响生成质量与稳定性。

8. 虚拟用户模式下自定义 QQ 角色昵称可能为空
   use_virtual_users=True 时会跳过群成员拉取，custom_protagonists/custom_bystanders 的昵称可能长期是空字符串，prompt 角色名为空，角色映射质量下降。

9. 命令处理函数存在未使用参数，增加维护噪音
   例如 add_template(..., tpl_name: str = "")、delete_template(..., tpl_name: str = "") 实际未使用该参数，易误导后续维护者。

10. 类职责过重，维护成本偏高
    SadStoryPlugin 同时承担配置加载、数据导入、角色池管理、提示词拼接、LLM调用、消息解析与发送、模板/风格CRUD，单类过于庞大，后续改动易引入回归问题。

---

db.py

1. 数据库连接初始化状态未防御
   各 CRUD 方法默认 self._conn 已初始化；若初始化失败或生命周期异常（如未调用 init() 就调用查询），会触发 NoneType 相关错误，缺少显式保护与错误信息。

2. init() 失败时连接清理不完整
   init() 中连接建立后若建表/commit 异常，没有 try/except/finally 兜底关闭连接，存在连接悬挂风险。

3. 单连接串行瓶颈风险（高并发命令场景）
   所有操作复用同一个 aiosqlite 连接，在高频并发下会形成串行队列，可能导致命令响应抖动；当前无任何排队/超时/退避策略。

---

代码评审团

人物一：Linus Torvalds（直球硬核）
你这核心问题不是“能跑”，是“并发下还能不能讲理”。冷却检查+设置分离就是典型竞态，线上一压测就露馅。建议把冷却判定和写入做成原子区（asyncio.Lock 按 group_id 分桶）。

人物二：Steve Jobs（体验洁癖）
失败也进冷却、跨群串角色、重名说错人——这些会直接破坏用户对产品“真实感”的信任。体验不是 UI 文案，是边界条件。先修身份映射（用 user_id 而非昵称）和失败不扣冷却。

人物三：Tony Stark（工程化脑回路）
这类 LLM 插件最怕“模型输出不听话”。你现在的 JSON 截取太乐观了，像把方舟反应堆连在脆皮插排上。建议：结构化输出强校验 + 超量消息裁剪 + 双主角模板变量契约校验，不然迟早在生产群里炸一次。

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

---

🔍 审核摘要

统计信息

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

main.py
db.py

---

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

当前仓库：Towqs/astrbot_plugin_sadstory
剩余触发次数：3

[Towqs]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sadstory

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

main.py

1. 框架适配问题：StarTools 导入路径不符合要求

   • 当前使用：from astrbot.core.star.star_tools import StarTools
   • 按规范应从 astrbot.api.star 导入。使用 core 层路径会增加内部 API 变更带来的兼容风险。

2. _generate_story 函数职责过重，可维护性较差

   • 同时承担了：角色选择、模板装配、Prompt 渲染、LLM 调用、JSON 提取、角色映射、结果裁剪等多个职责。
   • 函数过长导致调试困难，边界问题（如角色匹配失败、JSON 异常）不易定位。

3. LLM 返回 JSON 的提取逻辑脆弱，存在误解析风险

   • 使用正则 \[(?:\s|\n)*\{.*\}(?:\s|\n)*\]（贪婪匹配）和 find("[")/rfind("]") 的兜底方式，容易在包含额外方括号或说明文本时截取错误区间。
   • 在模型输出稍有偏差时会频繁触发解析失败。

4. 默认权限策略存在滥用风险

   • _check_permission 中，allowed_users 为空时默认“所有人可用”。
   • 在群环境下会导致任意成员可调用 LLM 生成功能，存在资源消耗和刷屏风险（尤其 /sadstory、/sadstory_aistyle、/sadstory_aitpl）。

5. 冷却状态并发一致性存在小概率竞态

   • _check_and_set_cooldown 使用了锁，但 _clear_cooldown 未加锁。
   • 在高并发下，可能出现“刚设置又被清除”或清除时序不一致，导致冷却行为偶发异常。

6. 输入内容缺少上限控制，可能导致存储与调用压力

   • /sadstory_addtpl、/sadstory_addstyle 对内容长度没有硬上限。
   • 虽有主题长度限制，但模板/风格正文可无限增长，可能导致数据库膨胀、提示词过长、LLM 调用成本异常上升。

7. 代码规范问题：重复导入与局部重复 import

   • 文件头已 import re，_generate_story 内又二次 import re，属于冗余代码，降低可读性。

---

db.py

1. 数据模型缺少名称唯一性约束，易产生重复数据

   • writing_styles.name、story_templates.name 未设置 UNIQUE。
   • 当前仅 has_template_by_name 在特定导入流程中做了预检查，但命令入口仍可重复插入同名项，后续管理/展示易混淆。

2. 数据库异常未分层处理，错误可观测性不足

   • 除 init() 外，大多数读写方法不做数据库异常分类（如 SQL 执行失败、连接状态异常），由上层统一接收为通用失败。
   • 出现问题时难以快速判断是数据问题、SQL 问题还是连接状态问题。

---

代码评审团

人物一：Linus Torvalds（直白硬核型）
你这 main.py 是“上帝函数博物馆”：一个 _generate_story 快把半个插件都塞进去了。能跑不代表好维护，拆成“角色选择 / prompt 构建 / LLM解析 / 映射回填”四段，未来你会感谢现在的自己。

人物二：Steve Jobs（体验导向型）
功能很全，但“默认所有人可调用”这件事会毁掉体验：群里一旦有人滥用，其他人看到的是噪音，不是产品价值。把权限和配额做成“默认安全”，用户才会觉得这是精致工具而不是失控按钮。

人物三：Tony Stark（工程效率型）
LLM 输出解析像在拆炸弹：先正则一把梭，再手动找括号。建议直接要求模型输出 fenced JSON + 严格 schema 校验，不合规就自动重试一次。少一点玄学，多一点工程化，服务器和你都能少掉头发。

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

---

🔍 审核摘要

统计信息

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

main.py
db.py

---

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

当前仓库：Towqs/astrbot_plugin_sadstory
剩余触发次数：2

[Towqs]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sadstory

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

main.py

1. 并发下存在重复导入/重复写库风险（_import_webui_data）
   sadstory 每次调用都会执行 _import_webui_data()，且该方法没有并发锁。多个请求同时进入时，可能在 cfg["add_writing_styles"] / cfg["add_story_templates"] 清空前重复写入数据库，造成重复数据。

2. JSON 提取逻辑较脆弱，容易误截取或解析失败
   _generate_story 里用正则 \[(?:\s|\n)*\{.*\}(?:\s|\n)*\] 提取数组，.* 为贪婪匹配，LLM 输出稍复杂（多段 JSON、示例代码块、额外括号）时容易截错，导致解析失败或拿到非目标数组。

3. 角色名模糊匹配可能分配错人
   speaker 匹配失败后使用 if speaker in nick or nick in speaker 兜底，会出现“短昵称误命中长昵称”的情况（如“阿明”和“小阿明”），可能把消息映射到错误 user_id。

4. 主题中 @ 去除规则不可靠
   re.sub(r'@\S+\s*', '', theme) 对昵称含空格/特殊符号时不稳定，且可能误删正常文本中的 @xxx 片段，导致主题被意外篡改。

5. 配置热重载导致状态可预期性变差
   多个命令中频繁调用 _reload_config()，会重建 self.user_pool（把 custom_* + group_users 重新拼接），在并发请求下可能出现“刚刷新用户池又被配置重载覆盖”的可维护性问题，排障困难。

6. 超长输入缺少统一上限控制（资源消耗风险）
   sadstory_addtpl / sadstory_addstyle / sadstory_aitpl 等路径对内容长度几乎无限制，可能导致数据库膨胀、提示词过大、LLM 调用成本异常升高。

7. 代码可读性问题：重复导入与超大函数职责混杂
   _generate_story 内再次 import re（文件顶部已导入），且函数集成了“选角、拼 prompt、调 LLM、解析 JSON、映射角色”等多职责，复杂度偏高，后续维护和单元测试成本较高。

---

db.py

1. PEP 8 格式问题
   from astrbot.api import logger 与 class SadStoryDB: 之间缺少两行空行（顶级定义之间应保留 2 行空行）。

2. 缺少并发写入下的一致性保护（业务层面）
   表结构没有唯一约束（如 name），在上层并发调用 add_style/add_template 时可能出现同名重复数据；后续“按 ID 开关/删除”虽可用，但管理体验和可预测性会变差。

3. 异常上下文信息不足，排障信息粒度不一致
   仅 init() 有集中异常日志；其余 CRUD 失败时直接抛出，业务层拿到异常但缺少“具体 SQL 操作上下文”日志，不利于定位线上问题（尤其并发场景下）。

---

代码评审团

人物一：Linus Torvalds（毒舌务实型）
“你这 main.py 功能是能跑，但 _generate_story 已经像‘巨石函数’了。把角色选择、LLM 调用、解析、映射拆开，不然任何小改动都像拆地雷。代码不是只给机器跑的，也是给人读的。”

人物二：Steve Jobs（产品体验型）
“用户不会关心你内部用了多少 prompt 模板，他们只会关心‘为什么这次 speaker 映射错了’。模糊匹配带来的错误会直接损害体验。宁可严格失败并提示重试，也别悄悄分配错角色。”

人物三：Tony Stark（工程极客型）
“并发下 _import_webui_data 没锁这点，像把实验反应堆放在客厅。平时没事，一高并发就冒烟。加互斥和幂等约束，顺便给 DB 名称加唯一索引，系统稳定性会立刻上一个台阶。”

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

---

🔍 审核摘要

统计信息

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

main.py
db.py

---

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

当前仓库：Towqs/astrbot_plugin_sadstory
剩余触发次数：1