[Plugin] astrbot_plugin_sora

[CCYellowStar2]

插件信息

{
  "name": "astrbot_plugin_sora",
  "desc": "使用newAPI生成视频。指令 文生视频 <提示词> 或 图生视频 <提示词> + 图片。",
  "author": "CCYellowStar2",
  "repo": "https://github.com/CCYellowStar2/astrbot_plugin_sora",
  "tags": [
    "sora"
  ],
  "social_link": "https://github.com/CCYellowStar2"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sora

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

好的，遵命。以下是我对您提供的 main.py 文件进行的详细代码审查报告。

main.py

本次审查发现了一些潜在问题，主要集中在代码的健壮性、可维护性和逻辑实现方面。

1. 潜在缺陷或问题

• API 响应解析过于脆弱

  在 _generate_and_send_video 方法中，您使用了正则表达式 re.search(r'\(([^)]+\.mp4)\)', content) 来从 API 返回的文本中提取视频 URL。这种方式非常脆弱，严重依赖于 API 返回的字符串格式。如果未来 API 的响应格式发生任何微小变化，例如：

  • 去掉括号 ()
  • URL 不再以 .mp4 结尾
  • 返回的是一个完整的 Markdown 链接 [video](url)
  • 返回一个纯 URL，不带任何修饰

  当前的解析逻辑都会失败，导致插件功能中断。

  建议:
  与 API 提供方确认其标准的响应格式。如果可能，应优先解析 JSON 格式的数据。如果 API 确实只返回一个包含 URL 的文本字符串，建议使用更灵活的 URL 提取方式，或者至少在提取失败时提供更明确的错误信息，告知用户可能是 API 响应格式变更。

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

• 获取头像的逻辑存在歧义

  在 _get_avatar 方法中，当传入的 user_id 不是纯数字时，代码会生成一个随机的 9 位数字作为 user_id 来获取头像：if not user_id.isdigit(): user_id = "".join(random.choices("0123456789", k=9))。

  这会导致一个意想不到的用户体验：如果用户 @ 的目标无法解析为 QQ 号（例如在某些平台或特殊情况下），机器人会回复一个完全随机的陌生人头像生成的视频。这可能会让用户感到困惑或认为是 Bug。

  建议:
  如果 user_id 无效，更合理的做法是直接返回 None，并在上层调用（get_images 方法）中忽略这个无效的头像，而不是用一个随机值来替代。

3. 可维护性与可读性

• get_images 方法逻辑重复且可简化

  get_images 方法为了从不同来源（回复、当前消息）获取图片，包含了多段结构相似的代码块，特别是这两段：

  # 第一次检查
  for s in event.message_obj.message:
      if isinstance(s, Comp.Reply) and s.chain:
          for seg in s.chain:
              # ... 获取图片逻辑 ...
  if images: return images
  
  # 第二次检查
  for seg in event.message_obj.message:
      if isinstance(seg, Comp.Image):
          # ... 几乎相同的获取图片逻辑 ...
  if images: return images

  这种重复使得函数变长，且不易维护。如果未来需要修改图片处理逻辑（例如增加对其他图片格式的支持），可能需要在多个地方进行修改。

  建议:
  可以将消息链（无论是回复中的还是当前消息的）的遍历和图片提取逻辑整合。可以设计一个辅助函数来处理任何消息链，或者将所有可能包含图片的消息段收集起来再一次性处理。

  例如，可以重构为：

  async def get_images(self, event: AstrMessageEvent) -> list[bytes]:
      images = []
      
      # 统一处理消息链
      async def extract_from_chain(chain):
          for seg in chain:
              if isinstance(seg, Comp.Image):
                  if seg.url and (img := await self._load_bytes(seg.url)):
                      images.append(img)
                  elif seg.file and (img := await self._load_bytes(seg.file)):
                      images.append(img)
  
      # 优先处理回复中的图片
      for s in event.message_obj.message:
          if isinstance(s, Comp.Reply) and s.chain:
              await extract_from_chain(s.chain)
  
      # 如果回复中没有图片，再处理当前消息的图片
      if not images:
          await extract_from_chain(event.message_obj.message)
  
      # 如果仍然没有图片，尝试获取At对象的头像
      if not images:
          for seg in event.message_obj.message:
              if isinstance(seg, Comp.At):
                  if avatar := await self._get_avatar(str(seg.qq)):
                      images.append(avatar)
                      
      return images

  这个重构版本虽然行数可能没有减少很多，但通过 extract_from_chain 辅助函数消除了核心逻辑的重复，使得代码意图更清晰，更易于维护。

---

代码评审团

Linus Torvalds
你的代码能跑，仅此而已。用正则表达式去解析一个随时可能变化的 API 响应，就好像用胶带去粘火箭的燃料管一样愚蠢。当它因为 API 加了个空格就崩溃时，别来哭着找我。不过，你至少知道怎么用 run_in_executor 来处理阻塞操作，没把整个事件循环都给卡死，这比我见过的很多“异步程序员”要强。

Steven Jobs
这插件的功能很有趣，但实现缺乏美感。get_images 函数里的代码重复得像廉价墙纸。好的设计是把复杂的东西变得简单，而你只是把简单的东西复制粘贴了两遍。还有，当找不到头像时去偷一个随机路人的？这简直是反用户体验设计的典范，毫无优雅可言。不过，你把 API 请求、负载构建和视频发送拆分成了不同方法，这种结构上的清晰感值得肯定，至少骨架是美的。

Elon Musk
造视频插件，目标是星辰大海，但你的实现方式却像是只为了在后院飞无人机。那个脆弱的正则表达式解析是任务的“单点故障”，一次 API 更新就能让你的“火箭”在发射台上爆炸。我们需要的是能够适应变化的、有冗余设计的系统。不过，你确实交付了一个能用的产品，而不是停留在 PPT 阶段，执行力值得赞赏。现在，回去把它做得能抵抗太阳风暴，而不是一阵微风。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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