[Plugin] astrbot_plugin_cirno

[Reisenbug]

插件信息

{
  "name": "astrbot_plugin_cirno",
  "display_name": "琪露诺——baka!",
  "desc": "把你的bot变成一只有记忆、有心情的baka! 她会记住每个人，越聊越了解你",
  "author": "Reisenbug",
  "repo": "https://github.com/Reisenbug/AstrBot_Plugin_Cirno",
  "tags": [
    "角色扮演",
    "人格",
    "东方project"
  ],
  "social_link": "https://github.com/Reisenbug"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_cirno

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

main.py

• 框架适应性检查 - 日志记录: 严禁使用 Python 内置的 logging 模块。文件中使用了 import logging 和 logger = logging.getLogger("astrbot")，违反了框架要求，必须统一修改为 from astrbot.api import logger。
• 框架适应性检查 - 消息发送方式: 在 @filter.after_message_sent() 装饰的 send_meme_after_reply 方法中，目前使用了 await self.context.send_message(event.unified_msg_origin, msg) 发送消息。根据框架规范，在 after_message_sent 等特殊的事件钩子函数中，必须直接调用 await event.send(msg)。

affinity.py

• 框架适应性检查 - 日志记录: 存在违反框架规范的日志记录器导入。请移除 import logging 和 logger = logging.getLogger("astrbot")，替换为 from astrbot.api import logger。

cirno_states.py

• 未发现明显问题。配置数据格式清晰，无逻辑和规范性错误。

core_memory.py

• 框架适应性检查 - 日志记录: 同样使用了内置的 logging 模块进行日志记录。请移除并统一改为 from astrbot.api import logger。

meme_sender.py

• 未发现明显问题。该文件仅处理本地路径和资产读取，无违规日志引入及同步网络阻塞 I/O 操作。

recall_memory.py

• 框架适应性检查 - 日志记录: 存在违背框架约束的 import logging。请将其修改为 from astrbot.api import logger。
• 潜在优化点: extract_keywords 方法使用了 jieba.lcut 进行分词，该操作是 CPU 密集型的同步操作，虽然不属于网络 I/O，但在并发极高时可能会对事件循环造成轻微影响。在当前规模下暂无隐患，但作为最佳实践，可以考虑将其封装到 asyncio.to_thread 中执行。

state_manager.py

• 框架适应性检查 - 日志记录: 同样使用了内置的 logging 模块。请清理对应的 import 并使用 from astrbot.api import logger。

---

代码评审团

Linus Torvalds：（毒舌、关注基础错误）
"你是在跟我开玩笑吗？七个文件里有五个都在用内置的 logging.getLogger！我都说了多少次了，框架怎么规定的你就怎么写，非要自己造轮子或者复制粘贴陈年的老代码！还有 main.py 里的钩子函数，文档里白纸黑字写着要用 event.send()，你绕了一大圈去用 context.send_message，纯属脱裤子放屁！除了这点粗心大意，其余状态管理部分倒是还算能看。赶紧给我把引入改掉，别逼我发火！"

史蒂夫·乔布斯 (Steve Jobs)：（关注设计与极简）
"我觉得这个插件的内部架构设计非常有意思，它赋予了机器精灵 '记忆' 和 '情感'。我喜欢这种将状态机（State）、短期记忆（Recall）和核心好感度（Affinity）相互分离、各司其职的优雅设计，这让整个机器人的表现非常连贯和人性化。但在追求完美的路上，我们需要遵守环境的规则。既然 AstrBot 提供了一套极致的 API 集合，我们就应该在所有文件里贯彻到底。丢掉那些冗余的内置库导入，保持代码的简洁和纯粹吧，It just works。"

艾达·洛夫莱斯 (Ada Lovelace)：（关注算法与未来潜能）
"真是令人着迷的尝试！你利用 jieba 分词加上时间衰减公式构建了一个轻量级的回忆检索引擎（Recall Memory），仿佛让我看到了分析机在处理记忆碎片。不过从长远来看，语言的魅力在于语意而不仅仅是词汇匹配。未来或许你可以考虑接入向量数据库（Vector Embeddings）和余弦相似度算法来替代单纯的交集重合度计算，这样机器人就能真正理解并联想。尽管如此，以纯 Python 和文本匹配实现轻量级的记忆召回，这已经是一段非常优美的逻辑了！"

(Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。)

---

🔍 审核摘要

统计信息

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

main.py
affinity.py
cirno_states.py
core_memory.py
meme_sender.py
recall_memory.py
state_manager.py

---

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

当前仓库：Reisenbug/AstrBot_Plugin_Cirno
剩余触发次数：4

[Reisenbug]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_cirno

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

main.py

1. Cron 表达式参数未校验，存在配置触发运行时错误风险
   check_interval_minutes 直接拼入 */{interval} * * * *，当配置为 0、负数或非整数时会生成非法 cron 表达式，初始化阶段可能失败。

2. _group_sessions 持久化存在并发覆盖风险
   在 inject_prompt 中对 _group_sessions 做“读-改-写”（list(self._group_sessions) 后 put_kv_data），若并发消息同时触发，可能出现后写覆盖先写的 session 列表，导致部分群会话丢失。

3. 跨类访问私有字段，降低可维护性并增加耦合
   在 on_llm_response 和 debug_state 中直接访问 self.core_memory._counters / _threshold / _profiles。这会让 Main 强依赖 CoreMemory 内部实现，后续重构易破。

---

affinity.py

1. 历史数据迁移缺少健壮性校验，可能在启动时抛异常
   mood_val = float(old_mood) 未捕获 TypeError/ValueError；若 KV 中值异常（如字符串垃圾值），load() 会失败。

2. 持久化结构未做 schema 校验，后续计算可能 KeyError/TypeError
   self._emotion = emotion_saved、self._user_data = user_saved、self._event_counters = counters_saved 直接信任外部数据结构。后续 get_composite 等直接索引固定键，数据损坏时会崩溃。

---

cirno_states.py

未发现需要单独报告的代码问题。

---

core_memory.py

1. 种子数据结构假设过强，易在加载阶段崩溃
   for uid, (name, prompt) in self._seed_data.items() 假定每个 value 都是长度为 2 的可解包对象；配置异常时会直接 ValueError。

2. LLM 返回 JSON 未校验类型，存在运行时错误风险
   result = json.loads(text) 后未确认 result 是 dict，却直接做 result["relationship"] 等访问。若模型返回 list/str，会触发 TypeError。

3. 日志包含模型原始返回片段，存在隐私泄露面
   解析失败时记录 raw={resp.completion_text[:200]}，可能把敏感对话内容写入日志。

---

meme_sender.py

1. _pick_image 缺乏目录存在性防护
   直接 os.listdir(cat_dir)，当目录被外部删除/权限变化时会抛 FileNotFoundError 或 PermissionError，影响主流程稳定性。

2. probability 未做范围约束
   未限制在 [0, 1]。错误配置会导致行为异常（例如负数导致几乎总触发，>1 导致永不触发）。

---

recall_memory.py

1. 加载阶段对 KV 数据类型缺少校验，存在隐式逻辑错误
   self._months_index = ... or [] 后未验证为 list[str]；若拿到字符串等类型，会被按字符迭代，触发错误的历史加载行为。

2. cleanup_old_months() 未同步清理内存缓存，导致“已删除数据仍可检索”
   只删除 KV 和 months 索引，但 _history_cache 里旧月份记录仍在，清理后本进程内仍会被 search() 命中，和“已过期删除”语义不一致。

3. 归档策略开销偏高
   archive() 每条消息都 save_current_month()，等价于高频全量持久化当前月列表；在对话量大时会造成明显性能压力。

---

state_manager.py

1. maybe_transition() 返回值语义不准确
   当随机命中切换分支但 _pick_new_state() 实际未选出新状态（例如无候选）时，函数仍返回 True。这会误导调用方“已发生状态变化”。

2. from_dict() 缺少类型校验，潜在污染后续状态计算
   state_entered_at / last_proactive_msg / ignored_count / silent 直接信任外部数据，若类型异常（如字符串）会在算术运算中触发异常。

---

代码评审团

人物一：Linus Torvalds（直球暴躁流）
你这套功能很能打，但有些地方“信任外部数据”信任过头了。affinity/core_memory/recall/state_manager 都有类似问题：读出来就当真。建议统一做“输入即不可信”校验层，否则哪天 KV 混进脏值，炸起来会很随机、很难查。

人物二：Steve Jobs（产品体验洁癖流）
你在做的是“人格连续性”产品，结果 recall_memory.cleanup_old_months() 删除后还能命中旧记忆，这会直接破坏用户对角色一致性的信任。记忆系统必须“你说删了就真的删了”，包括内存态和持久态。

人物三：Geralt of Rivia（冷面务实流）
怪物不止一种。这里最大的怪物叫“边界条件”：cron 间隔不合法、目录突然不存在、seed 格式不对、模型返回非 dict。给这些入口都加防护，战斗会轻松很多。否则你会在凌晨追日志，像在沼泽里打狮鹫。

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

---

🔍 审核摘要

统计信息

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

main.py
affinity.py
cirno_states.py
core_memory.py
meme_sender.py
recall_memory.py
state_manager.py

---

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

当前仓库：Reisenbug/AstrBot_Plugin_Cirno
剩余触发次数：3

[Reisenbug]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_cirno

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

main.py

1. 数据持久化目录不规范（框架适配）

   • MemeSelector 初始化时使用 plugin_dir=str(Path(__file__).parent)，后续会在插件代码目录下创建/读取 memes 子目录。
   • 按要求，涉及持久化数据应通过 StarTools.get_data_dir() 获取目录；当前实现会把可变数据放在代码目录，存在部署权限、升级覆盖丢失等风险。

2. 高频持久化写入可能导致性能抖动

   • 在 inject_prompt 每次触发都执行 await self.put_kv_data("state_data", ...)。
   • 该钩子是高频路径，持续写 KV 可能增加 I/O 压力，导致响应延迟上升。

3. 主动发言群发是串行发送，群数量大时延迟明显

   • _proactive_check 中对 _group_sessions 逐个 await self._send_proactive_to_group(...)，完全串行。
   • 当群较多或某些会话发送慢时，会拖慢整个定时任务执行窗口。

4. 提示词注入面暴露较大（安全/鲁棒性）

   • 多处把用户可控内容（昵称、历史消息摘要、回忆片段）直接拼接到 system_prompt。
   • 在无额外转义/隔离策略下，容易被“提示词污染”影响角色约束与行为稳定性。

---

affinity.py

1. 加载的用户档案缺少结构校验，存在运行时异常风险

   • load() 中 self._user_data = user_saved 后未校验每个用户项是否包含 familiarity/trust/fun/importance。
   • get_composite() 直接按键访问，遇到脏数据会触发 KeyError。

2. 事件计数类型未标准化

   • load() 接受 (int, float) 作为 _event_counters 值。
   • 后续 increment_event_counter() 做加法和阈值比较，若历史值是浮点会出现不一致的计数语义。

---

cirno_states.py

1. 状态配置数据存在可读性/维护性错误
   • 文案中出现明显笔误：“扑空几次次了”。
   • 虽不影响运行，但会降低配置可信度并增加后续内容维护成本。

---

core_memory.py

1. 异常捕获过宽，掩盖真实缺陷

   • update_profile_via_llm() 中：

     except (json.JSONDecodeError, Exception) as e:

   • 这等同于吞掉几乎所有异常，容易隐藏非预期 bug，降低可维护性和排障效率。

2. 系统提示词规模无上限增长风险

   • build_people_prompt() 会遍历所有 profile 生成提示词，人数增长后会显著抬高 token 开销并影响响应性能/稳定性。

3. 初始化阶段无条件保存

   • load() 末尾总是 await self.save()，即使没有任何变更。
   • 会造成不必要的写操作，尤其在频繁重载/重启场景下影响效率。

---

meme_sender.py

1. 数据目录使用不符合框架规范（框架适配）

   • 通过 os.path.join(plugin_dir, "memes") 在插件目录下维护运行时目录。
   • 依据要求，持久化/运行数据应使用 StarTools.get_data_dir() 路径。

2. get_stats() 缺少异常保护

   • 直接 os.listdir(cat_dir)，若目录权限/损坏异常会抛出 OSError，可能影响插件初始化流程稳定性。

---

recall_memory.py

1. 归档切月后未校验历史数据类型

   • archive() 中：

     self._current_month_data = (await self._plugin.get_kv_data(month_key, None) or [])

   • 未判断是否为 list，若 KV 中是异常类型，后续 append 可能直接失败。

2. 检索路径存在可见的性能瓶颈

   • search()、get_recent_by_user() 每次都构造 self._history_cache + self._current_month_data 新列表，再做全量扫描。
   • 数据量上来后会带来明显 CPU/内存开销。

3. 过期清理对时间戳鲁棒性不足

   • cleanup_old_months() 用 datetime.fromtimestamp(e.get('ts', 0)) 推断月份，若 ts 被污染为非法类型，可能抛异常中断清理流程。

---

state_manager.py

1. 反序列化布尔值逻辑不严谨

   • from_dict() 使用 self.silent = bool(data.get("silent", False))。
   • 若持久化值是字符串 "false"，会被解析为 True，导致状态恢复错误。

2. 权重总和为 0 时状态选择退化

   • _pick_new_state() 未处理 total == 0 的情形；若配置权重异常（全 0 或负值导致和为 0），状态切换逻辑会失效且无日志提示。

---

代码评审团

人物一：Linus Torvalds（直球型）
“你这主流程能跑，但把数据目录写在代码目录这事儿太‘脆弱工程学’了。部署一换环境、权限一收紧，马上翻车。把运行时数据和代码分层，这是工程底线，不是可选项。”

人物二：Steve Jobs（产品体验型）
“你的功能很多，但高频路径里做频繁持久化和全量扫描，会让‘感觉顺滑’这件事逐步消失。用户不看代码，他们只感受延迟。性能不是优化，是体验设计的一部分。”

人物三：Ada Lovelace（结构与可证明性导向）
“异常处理过宽会让系统失去可推理性：程序看似稳定，实则把错误埋进黑箱。请让失败可见、可分类、可恢复，否则后续维护者无法建立正确的因果模型。”

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

---

🔍 审核摘要

统计信息

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

main.py
affinity.py
cirno_states.py
core_memory.py
meme_sender.py
recall_memory.py
state_manager.py

---

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

当前仓库：Reisenbug/AstrBot_Plugin_Cirno
剩余触发次数：2

[Reisenbug]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_cirno

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

main.py

1. 配置边界未校验，可能生成非法 Cron 表达式

   • check_interval_minutes 未做合法性检查，若配置为 0 或负数，会构造出 */0 * * * * 这类非法表达式，导致定时任务注册失败或行为异常。

2. 高频持久化写入可能造成性能压力

   • 在 on_llm_request 每次请求都会 await self.put_kv_data("state_data", ...)。
   • 在高并发群聊下，这会放大 KV 存储 I/O 压力（通常是网络/远程存储 I/O），属于可预见性能瓶颈。

3. 回复清洗正则过于激进，可能误删有效内容

   • re.sub(r"[（(][^）)]*[）)]", "", bot_reply) 和 re.sub(r"\*[^*]+\*", "", bot_reply) 会无差别删除括号内容和星号包裹内容，可能破坏正常语义（包括用户可见正文），属于逻辑正确性风险。

4. 主动发言冷却与“无人回应计数”是全局维度，非会话维度

   • _proactive_check 会给所有群发，但 last_proactive_msg/ignored_count/silent 是单一全局状态。
   • 结果是：一个群的互动会影响其他群的主动发言节奏，存在跨群串扰的逻辑缺陷。

---

affinity.py

1. decay_rate / mood_decay_rate 参数未被使用

   • 构造函数接收并保存了两个衰减参数，但后续逻辑中未实际应用，属于“配置形同虚设”，会误导维护者和使用者。

2. 反序列化后的用户数据缺乏结构校验，存在运行时异常风险

   • load() 中对 affinity_data_v2 直接赋值 self._user_data = user_saved，未规范化字段类型。
   • update_affinity() 直接使用 ud["familiarity"] 等键，若历史数据/脏数据缺键或类型异常，会触发 KeyError/TypeError。

3. 好感度更新后的持久化时机稀疏，异常退出会丢失较多状态

   • 日常 update_emotion/update_affinity 后并未及时保存，主要依赖 terminate() 或关键事件触发保存。
   • 在进程异常中断时，近期情绪/好感变化容易丢失。

---

cirno_states.py

1. 状态数据质量问题影响可维护性
   • 文案中出现明显笔误（如“扑空几次次了”），这类配置数据直接参与 prompt，长期会影响角色输出质量和维护可信度。

---

core_memory.py

1. 新用户档案不会自动建立，核心记忆对陌生人几乎不生效

   • update_profile_via_llm() 对 not profile 直接 return。
   • 结合主流程，只有种子用户有档案；非种子用户不会进入“可更新状态”，导致“核心记忆”功能覆盖面严重受限。

2. build_people_prompt() 无上限拼接，存在 prompt 膨胀风险

   • 每次请求可能注入完整用户列表，随着 _profiles 增长会显著增加 token 消耗和响应延迟，属于性能与可维护性问题。

3. LLM Provider 选择策略与会话上下文脱节

   • 直接使用 context.get_all_providers()[0]，可能与当前会话实际 provider 不一致，导致行为不稳定（模型漂移、配置错配）。

---

meme_sender.py

1. 情绪分类为“首命中即返回”，存在明显规则偏置

   • _detect_mood() 按 MOOD_KEYWORDS 顺序匹配，第一个命中直接返回。
   • 当文本同时包含多类关键词时，结果受列表顺序强烈影响，分类稳定性较差（逻辑质量问题）。

2. 每次选图都实时遍历目录，频繁调用时有额外开销

   • _pick_image() 与 get_stats() 均重复 os.listdir，在消息量大时会产生可观开销（虽非网络 I/O，但属于性能问题）。

---

recall_memory.py

1. 启动加载阶段串行执行多次 KV 读取，异步吞吐不佳

   • load() 中逐月 await get_kv_data()，为串行网络/存储 I/O。
   • 月份较多时会明显拉长启动时间，建议并发化读取或分批预热。

2. 检索复杂度随历史增长线性上升，缺乏索引机制

   • search() 每次都遍历 self._history_cache + self._current_month_data 全量记录并做关键词集合运算。
   • 历史规模增大后会直接拖慢每次请求路径。

3. 落盘间隔策略存在可见数据丢失窗口

   • SAVE_INTERVAL = 10，在异常退出时可能丢失最近最多 9 条记忆记录，属于持久化可靠性缺陷。

---

state_manager.py

1. 离散小时匹配未处理跨日邻近关系

   • _is_active_hour() 在 len(hours) != 2 分支使用 abs(hour - h) <= 1，对 23 与 0 的邻近性判断错误（结果为 23）。
   • 会导致午夜附近状态可用性判断偏差。

2. from_dict 的布尔恢复方式不安全

   • self.silent = bool(data.get("silent", False))：若持久化值是字符串 "False"，会被解析为 True。
   • 应做显式类型判断/标准化转换。

3. 主动发言状态是全局变量，无法反映多群独立互动

   • ignored_count/silent/last_proactive_msg 全局共享，和 main 中多群广播结合后会产生跨群相互影响，逻辑隔离性不足。

---

代码评审团

人物一：Linus Torvalds（直给型）
“你这套状态和记忆系统挺能打，但全局状态污染多群会话这件事，属于‘能跑但不对’。代码不是只要工作就行，要在边界条件下也能工作。把主动发言状态按 session 维度拆开，这是基本工程卫生。”

人物二：Steve Jobs（产品体验型）
“你在角色感和人格一致性上做得很有戏剧张力，但 build_people_prompt 无上限增长会让体验变‘又慢又贵’。真正好的智能体，不只是会说，还要‘每次都顺滑地说’。控制 prompt 预算是产品级要求，不是优化项。”

人物三：福尔摩斯 Sherlock Holmes（推理型）
“线索非常清楚：bool("False") is True。这不是偶发现象，而是确定性误判。你看到的是‘偶尔沉默异常’，我看到的是可复现的反序列化逻辑漏洞。修正输入规范化后，许多‘灵异行为’会自然消失。”

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

---

🔍 审核摘要

统计信息

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

main.py
affinity.py
cirno_states.py
core_memory.py
meme_sender.py
recall_memory.py
state_manager.py

---

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

当前仓库：Reisenbug/AstrBot_Plugin_Cirno
剩余触发次数：1