[Plugin] astrbot_plugin_live_dashboard

[DBJD-CR]

插件信息

{
  "name": "astrbot_plugin_live_dashboard",
  "display_name": "Live Dashboard",
  "desc": "一个为 AstrBot 设计的「Live Dashboard」插件，用于对接上游 Live Dashboard 服务。支持在私聊/群聊中通过指令快速查询当前手机、电脑的活动状态信息。还支持用自然语言让 LLM 自主查询，让 Bot 和群友都能随时随地视奸你！❤️",
  "author": "DBJD-CR & GPT",
  "repo": "https://github.com/DBJD-CR/astrbot_plugin_live_dashboard",
  "tags": [
    "状态查询",
    "设备信息",
    "娱乐",
    "面板"
  ],
  "social_link": "https://github.com/DBJD-CR"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_live_dashboard

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

services/message_renderer.py

1. 音乐应用前台判断存在大小写逻辑错误（功能正确性）

   • 位置：_build_activity_description
   • 问题：app_lower = cleaned_app.lower() 后用 app_lower in MUSIC_APP_NAMES 判断，但 MUSIC_APP_NAMES 集合里多数是原始大小写（如 "Spotify", "AIMP"）。
   • 影响：很多音乐应用不会被识别为音乐前台，进而错误触发标题模板逻辑，导致“正在做什么”描述偏差。
   • 建议：将 MUSIC_APP_NAMES 统一预处理为小写集合，或判断时对集合成员做小写比较。

2. 敏感词脱敏覆盖不完整，存在信息泄露路径（安全/隐私）

   • 位置：render_dashboard_message
   • 问题：已对“应用”“标题”字段做 _mask_sensitive_text，但“现在：{activity_text}”未做同样脱敏；而 activity_text 可能包含 display_title 原文。
   • 影响：即使标题行被替换，敏感内容仍可能从“现在”行泄露。
   • 建议：对 activity_text 也应用同一套关键词脱敏策略，确保脱敏策略一致。

3. 重复筛选与配置解析带来不必要开销（性能/可维护性）

   • 位置：render_dashboard_message 与 _pick_device_items
   • 问题：render_dashboard_message 先 _apply_device_keyword_filters 计算计数，随后 _pick_device_items 内再次执行同样筛选并重复读取解析配置。
   • 影响：数据量增大时会有额外 CPU 开销，也增加后续维护的逻辑分叉风险。
   • 建议：在一次渲染流程中复用同一份筛选结果或预解析配置。

---

services/payload_client.py

1. 日志可能泄露敏感连接信息（安全）

   • 位置：fetch_current_payload 中 logger.info("[...地址：%s...]", url, ...)
   • 问题：完整 URL 会被记录；若 base_url 含用户信息、内网主机细节或 query 参数，可能被日志持久化暴露。
   • 影响：运维日志泄露风险增加。
   • 建议：日志中仅记录脱敏后的 host/path，避免输出完整 URL。

2. 复用外部 client 时日志超时值可能与真实请求超时不一致（逻辑可观测性）

   • 位置：fetch_current_payload
   • 问题：当调用方传入 client 时，请求实际超时由该 client 决定，但日志打印的是配置解析出的 timeout_sec。
   • 影响：排障时容易误判“为何日志写 30s 但实际更早/更晚超时”。
   • 建议：传入外部 client 时避免打印固定配置超时，或额外标注“使用外部 client 超时配置”。

---

代码评审团

人物一：Linus Torvalds（硬核直给）
你这段音乐应用判断像是“我都转小写了，但集合死活不配合”。这是典型会悄悄出错、测试又不一定马上覆盖到的逻辑坑。建议把所有比对表统一成 lower-case，不要让大小写在业务里当地雷。

人物二：Steve Jobs（体验导向）
你已经做了标题和应用脱敏，这很好，但“现在”这一行漏掉，让用户感受到的是“不一致、不可靠”。隐私能力的产品体验必须是“端到端一致”，别让一个字段毁掉整体信任。

人物三：Jeff Dean（系统与可观测性）
日志里打印的超时参数和真实行为不一致，会严重干扰线上诊断；完整 URL 进日志也会制造额外安全负担。建议把日志从“信息多”升级到“信息准且可安全共享”。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
services/__init__.py
services/app_descriptions.py
services/dashboard_service.py
services/message_renderer.py
services/payload_client.py
utils/__init__.py
utils/config_parser.py
utils/time_formatter.py

---

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

当前仓库：DBJD-CR/astrbot_plugin_live_dashboard
剩余触发次数：4

[DBJD-CR]

关于音乐应用前台大小写的判断：

• 核实点：[_build_activity_description()] 里 app_lower in MUSIC_APP_NAMES（见 [services/message_renderer.py]）
• 结论：当前不成立/不必改。因为 [MUSIC_APP_NAMES] 里已经是小写规范集合（中文项不受大小写影响），与 [app_lower] 匹配逻辑一致。

其他项已经优化。

[DBJD-CR]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_live_dashboard

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

main.py

1. LLM 工具错误判定过于脆弱（逻辑耦合字符串前缀）
   query_live_dashboard_status_tool() 通过 message.startswith(known_error_prefixes) 判断是否失败，这会导致：

   • 业务层文案一旦调整（哪怕只改标点/措辞），工具层可能误判成功；
   • 错误语义被“文本格式”绑死，维护成本高，容易引入回归问题。

2. on_llm_request 无去重地追加 system prompt，存在提示词膨胀风险
   inject_live_dashboard_tool_prompt() 每次都直接拼接到 req.system_prompt。如果同一请求链路中钩子被重复触发/重试，可能出现重复注入，增加 token 消耗并干扰模型行为一致性。

3. 黑名单配置每次查询都重复解析，热路径有不必要开销
   _get_query_denied_text() 每次调用都执行 parse_list_config(get_text_value(...))。在高频消息场景下会形成重复字符串处理，属于可避免的性能损耗（适合初始化时或配置变更时缓存）。

4. 空消息边界下可能生成空转发节点
   _split_message_blocks() 在输入为空白字符串时会返回 [""]，后续转发节点可能出现空 Plain(text="")。这在部分平台可能触发发送失败或无意义消息。

---

services/app_descriptions.py

1. 大小写归一化字典存在“静默覆盖”风险
   APP_DESCRIPTIONS_LOWER = {k.lower(): v ...} 与 TITLE_TEMPLATES_LOWER[name.lower()] = template 在遇到大小写变体键（如 Kirikiri / KiriKiri）时会后写覆盖前写，且无告警。后续维护新增词条时，容易出现“配置了但不生效/被覆盖”的隐性问题。

---

services/payload_client.py

1. base_url 未做协议与目标约束，存在 SSRF 风险窗口
   _build_url() 直接拼接配置项并发起请求。若配置来源可被低信任方影响，可能被用于探测内网或访问非预期目标（典型 SSRF 面）。建议至少限制为 http/https 并做基础校验。

2. 日志脱敏不彻底：仍记录完整 path
   _mask_url_for_log() 去掉了 query/fragment，但保留 path。若 path 中包含业务敏感标识（某些系统会把 token/ID 放路径），仍可能在日志暴露。

---

utils/time_formatter.py

1. 过宽异常捕获导致问题被静默吞掉
   except Exception: return raw_text 会掩盖非预期错误（不仅仅是时间解析失败），降低可观测性和可排障性。建议收窄到明确的解析异常类型。

---

代码评审团

人物一：Linus Torvalds（直给型、关注工程稳健性）
你这套逻辑能跑，但“靠字符串前缀判断错误”这件事太脆了。错误是结构化语义，不是文案猜谜。把失败状态做成明确返回码/状态字段，不要让维护者在中文提示词里踩雷。

人物二：Steve Jobs（产品体验导向）
重复注入 system prompt 是“用户看不见但会被体验背刺”的典型问题：token 变多、回答风格漂移、成本上升。好产品不是“功能加上去”，而是“每次都稳定地对”。

人物三：Gordon Ramsay（暴躁但实用）
base_url 直接拿来请求？这在安全厨房里属于“生鸡肉放熟食旁边”。先把输入洗干净：协议、主机、范围都做校验，再下锅。否则迟早“食物中毒”（SSRF）找上门。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
services/__init__.py
services/app_descriptions.py
services/dashboard_service.py
services/message_renderer.py
services/payload_client.py
utils/__init__.py
utils/config_parser.py
utils/time_formatter.py

---

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

当前仓库：DBJD-CR/astrbot_plugin_live_dashboard
剩余触发次数：3

[DBJD-CR]

先这样吧，99.99% 的场景下不会遇到以上问题。
留着哪天再水几个 commit，先改其他插件去了😋

[DBJD-CR]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_live_dashboard

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

main.py

1. on_llm_request 每次请求都无条件追加 system prompt，存在提示词膨胀风险
   在 inject_live_dashboard_tool_prompt 中：

   req.system_prompt = (req.system_prompt or "") + instruction

   这会在同一会话多轮调用时不断追加相同说明，导致：

   • token 持续增长，增加推理成本与延迟；
   • 后续关键信令被稀释，工具调用稳定性反而下降。
     建议至少做一次“是否已注入”判定（例如标记串去重）。

2. LLM 工具错误识别依赖“字符串前缀”判断，鲁棒性较弱
   query_live_dashboard_status_tool 通过：

   if message.startswith(known_error_prefixes):

   来判定失败。该方式与文案强耦合，后续只要错误文案调整（哪怕是标点变更）就可能误判成功/失败。
   建议让 service 返回结构化结果（如 ok: bool, message: str, error_code: str | None），避免文本协议化。

---

services/payload_client.py

1. 未校验响应 Content-Type 即直接 response.json()，错误分类不清晰
   当前对 200 响应直接做 JSON 解析，若上游返回 HTML/纯文本（反向代理异常页等），会抛出解码异常并在上层落入“未预期错误”。这会降低可观测性与排障效率。
   建议：

   • 先检查 Content-Type 是否为 JSON；
   • 对 JSON 解码错误单独捕获并转为可识别的“响应格式错误”。

2. 缺少响应体大小约束，存在内存压力风险（边界安全/稳定性）
   直接读取并解析完整响应体，若上游异常返回超大 payload，可能造成内存与延迟问题。
   在可控场景建议增加响应大小上限或流式读取策略（至少在业务层做大小防护）。

---

utils/time_formatter.py

1. except Exception 过宽且静默兜底，掩盖真实数据质量问题
   format_time_text 对所有异常一律返回原文，虽然“不会崩”，但会把时区/格式问题完全吞掉，后续很难定位上游时间格式异常。
   建议最少记录 debug/warning 日志或收敛异常类型（如 ValueError），避免无痕失败。

---

代码评审团

人物一：Linus Torvalds（硬核、直接）
“字符串前缀当错误码？这叫把控制流写在文案里。文案是给人看的，不是给程序判定分支的。把错误结构化，不要让‘中文句号’决定系统行为。”

人物二：Steve Jobs（产品体验导向）
“提示词每轮都叠加，是一种‘看不见的界面污染’。用户看不到，但体验会越来越慢、越来越笨。好产品不只是能跑，而是每一轮都保持干净和一致。”

人物三：Geralt of Rivia（冷峻务实型）
“你把所有时间解析异常都吞了，就像夜里听见怪声却说‘风吹的’。短期省事，长期要命。至少留个日志痕迹，不然追踪问题时只剩猜。”

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
services/__init__.py
services/app_descriptions.py
services/dashboard_service.py
services/message_renderer.py
services/payload_client.py
utils/__init__.py
utils/config_parser.py
utils/time_formatter.py

---

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

当前仓库：DBJD-CR/astrbot_plugin_live_dashboard
剩余触发次数：2

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#403
已自动合并 PR #403

该插件已上架。
This plugin is now published.