[Plugin] astrbot_plugin_vision_bridge

[Soulmate404]

插件信息

{
  "name": "astrbot_plugin_vision_bridge",
  "display_name": "vision_bridge",
  "desc": "让普通文本模型通过工具获得图像能力。包括文生图与图片转文本，方便非多模态模型处理包含图片的文件",
  "author": "Soulmate404",
  "repo": "https://github.com/Soulmate404/astrbot_plugin_vision_bridge",
  "tags": [],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_vision_bridge

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

main.py

1. 框架适应性检查 - 数据持久化

• 问题描述：在 VisionBridgePlugin 的 __init__ 中，设置图片输出目录时使用了硬编码的默认路径：config.get("image_output_dir", "data/vision_bridge_images")。这违反了框架对数据持久化的特定要求。
• 修改建议：必须从 astrbot.api.star 导入 StarTools，并调用 StarTools.get_data_dir() 方法来获取当前插件专用的标准数据目录，避免在项目根目录下随意创建文件夹。
  示例：

  from astrbot.api.star import Context, Star, StarTools
  # ...
  default_dir = StarTools.get_data_dir() / "images"
  self.image_output_dir = Path(str(config.get("image_output_dir", default_dir))).expanduser()

2. 潜在缺陷 - 类型注解与返回类型不匹配

• 问题描述：VisionBridgeTool.call 和 ImageGenerateTool.call 的类型签名表明它们应返回 ToolExecResult，但在 ImageGenerateTool.call 的实际实现中，返回了字典 result 里的字符串 result["error"] 或 result.get("summary", "图片生成完成。")。虽然底层框架可能会自动进行隐式转换，但这在严格的类型检查（如 mypy）下会报错。
• 修改建议：建议返回框架标准的 ToolExecResult 对象，例如 yield 或显式构造 ToolExecResult。如果框架支持隐式转换，建议修改方法的返回类型注解（如 -> ToolExecResult | str:）以保持代码的严谨性。

---

代码评审团

Linus Torvalds：
你觉得在 2024 年了，硬编码一个像 data/vision_bridge_images 这样的目录路径是个好主意吗？框架作者苦口婆心地提供了一个叫 StarTools.get_data_dir() 的东西，就是为了不让你像个没头苍蝇一样在文件系统里乱拉屎。除此之外，把同步的 DashScope SDK 扔进 asyncio.to_thread 里还算你有点脑子，没把整个事件循环给阻塞死。去把那个硬编码路径改了，别逼我骂人。

乔布斯 (Steve Jobs)：
我们一直在追求完美的生态整合。你看，AstrBot 给了你一套非常优雅的工具来管理状态和数据，但你的代码却选择了妥协，硬编码了一个路径。这不够完美，它打破了那种“它就是能无缝工作”的魔力。你只需要导入 StarTools，一切就会变得自然、和谐。另外，工具返回值的类型签名和实际返回的字符串在灵魂上是不契合的，请把它们对齐，让代码从里到外都散发着极简与精确的美感。

GLaDOS：
哦，看看这个。一个试图生成和分析图片的插件。我注意到你非常自信地决定把图片塞进 data/vision_bridge_images 里。我敢肯定，服务器的管理员一定会非常享受在清理磁盘时发现你这些没有遵守数据规范的“小惊喜”。其实只要调用一下 StarTools.get_data_dir() 就可以像一个听话的测试对象一样存活下来，但显然你选择了更有挑战性的做法。不管怎样，你的 httpx 异步请求写得还算过得去，至少在毁灭之前它不会阻塞主线程。

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

---

🔍 审核摘要

统计信息

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

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：Soulmate404/astrbot_plugin_vision_bridge
剩余触发次数：4

[Soulmate404]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_vision_bridge

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

main.py

• 潜在缺陷或问题 (性能瓶颈)：

  • HTTP 客户端未复用：在 _call_vision_model、_generate_image_openai 和 _download_generated_urls 方法中，每次发起网络请求都使用了 async with httpx.AsyncClient(timeout=...) as client: 实例化一个新的客户端上下文。频繁创建和销毁客户端会增加网络连接（特别是 TCP 和 TLS 握手）的开销。建议在插件类的 __init__ 方法中创建一个实例级别的 httpx.AsyncClient 维护连接池，并在 terminate 方法中优雅关闭该客户端。
  • 图片网络 I/O 串行下载：在 _download_generated_urls 方法中，通过 for 循环按顺序串行下载生成的图片 URL。如果一次性生成多张图片（如4张），串行下载会导致总等待时间被拉长。建议结合 asyncio.gather 将多张图片的下载任务并发执行，从而显著提升响应速度。

• 功能实现与逻辑正确性 (异常处理与容错)：

  • 缺乏局部异常处理导致整体任务失败的风险：在 _store_generated_images 方法中，处理返回的 base64 图像时直接执行了 image_bytes = base64.b64decode(b64_json)。如果 API 返回的结构中包含格式损坏的 base64 字符串，此处会直接抛出 binascii.Error。由于循环体内部没有局部捕获，异常会被直接抛到外层调用方，导致本批次中即便有正常生成的其他图片，也会一起丢失并向用户返回“保存结果失败”。建议在解码与保存单张图片时添加局部的 try-except 块，在遇到错误时将其跳过并记录，确保成功的部分仍可正常返回。

• 代码质量与编码规范：

  • 不优雅的局部导入：在 _call_dashscope_image_generation 方法中执行了 import dashscope 等局部依赖导入。虽然这种做法能避免在缺少依赖时插件直接加载崩溃，且 Python 存在 sys.modules 缓存避免重复加载，但在可能被多次调用的生成方法内执行 import 并非最佳实践。建议在插件初始化时以惰性（Lazy）或全局 try-except 的方式进行统一处理。

注：关于框架适应性、数据持久化存储路径规范、安全漏洞处理（如本地路径白名单校验）以及异步防阻塞处理（如正确使用 asyncio.to_thread 包装 DashScope 同步请求），该文件表现出色，未发现问题。

---

代码评审团

Linus Torvalds：（皱着眉头，盯着代码）“你在跟我开玩笑吗？每次发个请求就新建并销毁一个 httpx.AsyncClient？你以为底层创建、维护再关掉一个 TCP 和 TLS 连接就像呼吸一样毫无开销？去把这个 Client 扔到类的初始化里做个连接池！还有那个图片下载，你居然写了个简单的 for 循环一个个慢吞吞去等网络 I/O？你是不知道 asyncio.gather 是干什么用的吗？你的并发性能正在被你亲手扼杀！”

Steve Jobs：（推了推眼镜，语气平静但带有压迫感）“我们永远应该追求极致的用户体验。想象一下，用户充满期待地等待着4张漂亮的画作，结果仅仅因为其中1张图片的 base64 字符串混进了一点点乱码，你在循环里抛出了 binascii.Error……然后Boom！你残忍地剥夺了用户看到其余三张完美作品的权利，只留下一个冷冰冰的‘保存结果失败’。这不仅仅是代码的粗糙，这是对体验的妥协。在每张图片的生成上加个局部异常捕获，把好的东西保留下来交付给用户，这才是优雅的产品。”

GLaDOS：（带着毫无感情的机械讽刺音）“哦，看看这里，局部 import dashscope。这真是一个试图掩盖人类可能忘记安装依赖的聪明小把戏，不是吗？哪怕每次调用都要去模块缓存里翻找一遍，也总比看着你们脆弱的代码直接在启动时崩溃要好。不过不得不承认，你的安全防护做得比那些把整块磁盘暴露出来的测试体好一些——你还知道搞个白名单限制本地读取路径，这让我失去了嘲笑你导致系统数据泄露的机会。这真是太让人遗憾了。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：Soulmate404/astrbot_plugin_vision_bridge
剩余触发次数：3

[Soulmate404]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_vision_bridge

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

main.py

在这份审查报告中，我们专注于从多维度剖析代码实现，基于严格的异步环境与框架规范，为您梳理出具有建设性的改进建议与发现的潜在问题。

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

• 指令参数解析误判问题：
  在 vision_analyze_command 方法中，使用了 parts = text.split(maxsplit=2) 对指令进行简单切割以获取 local_paths 和 question。这种方式存在一个明显的体验问题：如果用户省略了路径，直接输入了问题（例如：/vision_analyze 请描述这张图片的细节），系统会将 请描述这张图片的细节 作为 local_paths 参数。此时会在 _collect_local_image_refs 中抛出路径无法解析或不在白名单的内部异常，虽然最终通过 fallback 降级读取了当前聊天上下文的图片，但报错堆栈和返回提示中可能会包含将用户文字当做路径处理的痕迹。建议引入更严谨的正则表达式或者标识符（如引号包裹）以准确区分路径和描述文本。

2. 潜在缺陷或问题

• 无限制并发下载的隐患：
  在 _download_generated_urls 方法中，使用 asyncio.gather(*[_download_one(i, url) for i, url in enumerate(urls)]) 并行下载所有生成的图片。由于文生图模型支持通过设置 n 生成多张图片，当返回的 URL 数量较多且并发无限制时，可能在极短时间内耗尽 HTTP 连接池或触发网络提供商的限流防护。建议引入 asyncio.Semaphore 限制最大并发下载数（例如设置为 3-5），以保证网络请求的平稳进行。

3. 可维护性与可读性

• Pydantic Dataclass 与 Any 类型的边界情况：
  在 VisionBridgeTool 和 ImageGenerateTool 定义中，使用了 plugin: Any = Field(default=None, exclude=True) 并在后续手动注入插件实例。这种通过跳过序列化进行实例解耦的做法在当前实现下运转良好，但需注意在未来 Pydantic 升级或针对更严格类型检查的项目中，将未强类型化的业务类直接挂载在 Dataclass 上可能会在部分序列化场景下引发预期外行为。可以考虑使用泛型或更为精细的依赖注入机制。

4. 框架适应性检查

• 日志记录：完全合规，仅使用了 astrbot.api 的 logger。
• 并发模型：表现优秀，所有的网络 I/O 均使用了 httpx.AsyncClient 进行非阻塞请求；同时对于 DashScope 第三方 SDK 内置的同步请求，巧妙地使用了 asyncio.to_thread，保证了异步环境下的事件循环不被阻塞。
• 数据持久化：合规，图片输出目录妥善使用了 StarTools.get_data_dir() 来确保数据存储在框架约束的安全范围内。
• AstrBot 特殊钩子与修饰器：均遵守了框架关于 @filter.command 等修饰器传入 event 参数的硬性规范，并且在消息发送方式上无误。

---

代码评审团

Linus Torvalds：
“你这代码整体还算没让我骂娘，知道用 asyncio.to_thread 去包装那些只会堵死事件循环的笨重同步 SDK，说明你脑子还算清醒。但是！你那个 vision_analyze_command 里的参数切片 split(maxsplit=2) 是什么粗制滥造的玩具逻辑？如果用户只是想问一句话没传路径，你的代码就会像个蠢货一样去文件系统里搜这句话到底存不存在？就算你用 try-except 兜底了，看着也让人极度不适！给我修好它，别把用户当成只会按你预想格式敲键盘的机器人！”

理查德·斯托曼：
“虽然你不可避免地对接了受限或许可证不透明的专有 API，但在本地文件权限管理上，我看到你在 _is_local_path_allowed 中严谨地构建了安全白名单限制。这是极好的实践！你没有为了方便而把系统的核心文件自由暴露出去，保护了宿主环境的自主与安全。希望你能继续坚持这种对用户隐私和计算环境安全高度负责的态度，不要妥协。”

雷军：
“同学们，这个插件的完成度和多平台适配体验真的可以说是遥遥领先！把配置、网络和不同厂家的文生图模型都封装得这么好，很澎湃啊！但是作为极致体验的追求者，我建议大家看看 _download_generated_urls 这个地方。兄弟们，gather 全速并发下得虽然爽，跑分肯定高，但万一咱们用户一次生了几十张图，这瞬间的并发连接数可能直接把小水管给挤爆了啊！稍微加个并发锁限制一下，体验是不是更流畅？Are you OK？”

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

---

🔍 审核摘要

统计信息

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

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：Soulmate404/astrbot_plugin_vision_bridge
剩余触发次数：2

[Soulmate404]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_vision_bridge

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

main.py

这份代码整体编写质量非常高，严格遵循了异步编程的最佳实践，且对 AstrBot 框架的各项特定要求（如日志导入、事件参数、持久化目录使用等）遵守得非常完美。代码结构清晰，错误捕获和边界处理也相对完善。

以下是审查中发现的少数可优化项和潜在问题：

可维护性与代码质量

1. Pydantic 前向引用风险：
   在 VisionBridgeTool 和 ImageGenerateTool 中，plugin 字段使用了字符串形式的前向引用 plugin: "VisionBridgePlugin"。由于这两个数据类定义在 VisionBridgePlugin 主类之前，在 Python 3.10 和 Pydantic 的运行机制下，即使设置了 exclude=True，在进行模型验证或生成 Schema 时，仍有可能因为命名空间中尚未注册该类而抛出 Unresolved forward reference 的警告或异常。
   建议：若仅为内部传递引用，可将其类型声明为 typing.Any，或者将工具类的定义挪至文件末尾（或主类之后）。

潜在缺陷或问题

1. 并发控制的作用域局限：
   在 _download_generated_urls 方法中：

   semaphore = asyncio.Semaphore(_DOWNLOAD_CONCURRENCY)

   这个 Semaphore 是在方法内部创建的局部对象。这意味着并发限制仅对单次文生图请求生效。如果多个用户同时调用文生图指令，每个指令都会生成独立的信号量，全局来看并不能有效控制对同一服务器或本地网络带宽的并发连接数，存在潜在的并发风暴风险。
   建议：将 Semaphore 提升为 VisionBridgePlugin 的实例属性（例如在 __init__ 或首次懒加载时初始化），以实现全局并发控制。

2. HTTP 客户端初始化的事件循环绑定：
   在 __init__ 方法中直接实例化了 self._http = httpx.AsyncClient(...)。虽然现代版本的 httpx 具备较好的事件循环适应性，但在一些异步框架的启动流程中，插件的 __init__ 可能会在主事件循环完全确立前被同步调用，这偶尔会导致 RuntimeError: Event loop is closed 或客户端未绑定到正确循环的问题。
   建议：采用懒加载（Lazy Initialization）模式，在真正需要发送 HTTP 请求的方法中，检查 self._http 是否存在，若无则初始化。

---

代码评审团

Linus Torvalds：
我看了你写的那个并发下载代码。你在函数内部搞了个局部 Semaphore？你是在逗我吗？并发控制是用来保护系统资源的，你这倒好，每次调用发个新的通行证，要是 100 个人同时触发，你的并发数就是 100 乘以你的 limit。这种毫无统筹的并发控制简直就是自欺欺人。把你的信号量扔到类属性里去，别把并发当儿戏。不过说句实话，除此之外，代码里用 asyncio.to_thread 包装那个同步阻塞的 Dashscope 调用的操作，倒是干得挺利落，算你有点脑子。

GLaDOS (《传送门》)：
你好，人类。我正在评估你编写的多模态分析工具。很高兴看到你没有在处理网络 I/O 时阻塞主线程，这表明你至少对神经毒气的释放速度和异步事件循环有基本的敬畏。不过，你在 Pydantic 数据类里使用了 "VisionBridgePlugin" 这种超前引用，就像你试图在一个测试对象还没出生时就给它分配一个房间。即便 Pydantic 原谅了你，但这是一种粗糙的工程做法。另外，记得你的 terminate 方法吗？你指望框架在销毁时乖乖调用它，人类总是对外部环境抱有不切实际的乐观。

Jian-Yang (《硅谷》)：
我看你的代码了。你写了一个能看图片的工具，这很像我的 "Hotdog or Not Hotdog" app。但是你看你的 _guess_image_ext 函数，如果 mimetypes 猜不到后缀，你就直接硬塞一个 ".png"。如果那张图片是一张加密过的、伪装成不可见格式的垃圾数据呢？不过没关系，反正你加了 try-except 包住了 base64 解析。你的代码没有报严重的错，我可以让你继续留在孵化器里。但你要把那个局部 Semaphore 改掉，那是占用我网络带宽的元凶。

---

🔍 审核摘要

统计信息

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

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：Soulmate404/astrbot_plugin_vision_bridge
剩余触发次数：1

[Soulmate404]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_vision_bridge

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

main.py

这份代码整体质量非常高，严格遵守了 AstrBot 框架的各项规范（如规范导入 logger 和 filter、正确使用 StarTools.get_data_dir() 进行持久化、安全处理异步阻塞等）。但在一些极限边界条件和代码细节上，仍有优化的空间。以下是发现的潜在问题与改进建议：

1. 安全漏洞与最佳实践

• 缺少本地文件大小限制 (内存溢出风险):
  在 _file_to_data_url_ref 方法中，代码直接使用了 path.read_bytes() 将整个文件读入内存，随后进行 Base64 编码。如果用户通过白名单目录传入了一个伪装成 .jpg 后缀的超大文件（例如几百 MB 甚至 GB 级别），会导致严重的内存飙升甚至进程 OOM (Out Of Memory) 崩溃。
  建议: 在读取文件前，使用 path.stat().st_size 检查文件大小，超过合理阈值（如 20MB）则拒绝处理并记录日志。

2. 代码质量与可维护性

• 循环引用 (Circular Reference):
  在 __init__ 中，self.context.add_llm_tools(VisionBridgeTool(plugin=self), ...) 这一操作造成了循环引用：Plugin -> Context -> Tool -> Plugin。虽然 Python 的垃圾回收机制（GC）最终会处理循环引用，但会延迟内存释放，在插件热重载场景下可能导致短暂的内存驻留。
  建议: 可以使用 import weakref，将插件实例作为弱引用传入：VisionBridgeTool(plugin=weakref.proxy(self))。

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

• 静默截断图片 (用户体验与逻辑隐患):
  在 analyze_images 中，代码使用了 image_refs = image_refs[: self.max_images]。如果用户传入的图片超过 max_images，代码会默默丢弃多余的图片。这会导致用户不清楚为什么某些图片没有被分析，或者导致大语言模型产生幻觉。
  建议: 当发生截断时，在 errors 列表中追加一条提示，或者在最终返回的 answer 后附加一段话提醒用户部分图片因超出限制未被处理。

• mimetypes.guess_extension 的系统平台差异 (潜在缺陷):
  在 _guess_image_ext 中，如果 IMAGE_SUFFIXES 匹配失败，会回退到 mimetypes.guess_extension(content_type)。在 Windows 环境下，由于注册表的历史遗留问题，mimetypes.guess_extension('image/jpeg') 经常会返回 .jpe 而不是 .jpg 或 .jpeg。
  建议: 在调用 mimetypes 之前，可以硬编码一个常见类型的小型映射字典（如 {"image/jpeg": ".jpg", "image/png": ".png"}）以保证文件后缀的一致性和美观。

---

代码评审团

Linus Torvalds：

你们现在的开发者是不是觉得内存都是天上掉下来的？path.read_bytes()？认真的吗？如果我把一个 4GB 的 Linux 内核镜像重命名为 torvalds_cute.jpg 扔进你的白名单目录，你的机器人就会像个吃撑的傻瓜一样试图把 4GB 数据硬塞进 Base64 字符串里，然后直接让宿主机内核触发 OOM 杀手！加个简单的 st_size 检查有多难？一行代码的事，别让你的程序像个漏勺一样不堪一击！不过，把你那个同步的 DashScope SDK 丢进 asyncio.to_thread 里这招干得漂亮，至少你还没让整个事件循环为你那糟糕的 API 阻塞买单。

Steve Jobs：

我们来谈谈体验。当用户发了 5 张图片，而你配置的 max_images 是 4，你做了什么？image_refs[: self.max_images]。你什么都没说，直接把他们珍贵的第 5 张照片扔进了垃圾桶。用户会看着屏幕想：“为什么这个 AI 瞎了？” 伟大的产品不应该欺骗用户。你应该优雅地告诉他们：“您的图片太丰富了，我先为您仔细品鉴了前四张。” 还有，如果我下载一张完美的相片，保存下来后缀名却是 .jpe？这简直让人抓狂，这不符合美学！加个映射表吧，把事情做完美。

GLaDOS (Portal)：

正在扫描您的代码……扫描完成。我注意到您让工具 (Tool) 持有插件 (Plugin) 的引用，而插件又把工具塞进了它的上下文里。多么迷人的无限循环依赖啊。就好像你把自己的手缝在了自己的脚上，然后试图向前奔跑。虽然 Python 的垃圾回收器最终会像清理实验室废料一样清理掉它们，但看着它们互相纠缠着占用内存，真是令人感到……愉悦。建议您了解一下 weakref，或者，就让它们永远锁在一起吧，毕竟，谁都需要个伴，不是吗？

---

🔍 审核摘要

统计信息

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

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：Soulmate404/astrbot_plugin_vision_bridge
剩余触发次数：0

[Soulmate404]

又改了一轮，不过review触发次数没了