bilibili-video-summary

name	bilibili-video-summary
display_name	B 站视频总结
description	用户给一个 B 站视频 URL / BV 号，基于已登录 B 站账号抓取元数据、字幕和官方 AI 总结，产出一份完整 Markdown 总结并落盘到 /workspace/outputs/bilibili/。
when-to-use	用户发送一个 B 站视频链接/BV 号，希望整理、总结、生成视频笔记或提炼时间轴。
allowed-tools	["Bash","Write","Read"]
metadata	{"requires":{"bins":["bilibili"],"connectors":["bilibili"]}}

B 站视频总结

参考：references/shared.md 记录 URL/BV 解析、CLI、登录态挂载和目录约定；references/extraction.md 记录 bilibili extract 的原料格式。

目的

用户只发一个 B 站 URL / BV → 你基于登录态抓取字幕、官方 AI 总结和元数据 → 产出一份完整 Markdown → 同时在对话里展示给用户 + 落盘到指定路径。

触发

• 输入是 B 站视频链接、BV 号、b23.tv 短链
• "帮我整理这个视频 / 生成 md / 总结一下"

输入

$ARGUMENTS 可以是：

• 裸 URL：https://www.bilibili.com/video/BV1xx411c7mD
• 裸 BV：BV1xx411c7mD
• 短链：https://b23.tv/xxxxxx
• JSON：{"url": "...", "output_dir": "..."}

不要让用户手贴 Cookie，也不要在命令中传 --sessdata。B 站登录态由 Ripple connector 控制面保存；在 nsjail connector runtime 中会只读挂载到 CLI 默认读取路径，在 Codex app-server shell 中会通过 BILIBILI_CREDENTIAL_FILE 指向同一份只读凭证文件。

登录前提

• 本 skill 要求 bilibili connector 已连接；未连接时通常不会出现在 Available Skills。
• 不要运行 bilibili auth start/poll/status/logout。二维码登录、状态轮询、断开连接都属于 Ripple server control plane。
• 如果执行中发现登录态缺失或过期，不要降级写半成品 Markdown；停止当前产出，并让 Ripple 重新发起 Bilibili connector 授权。

如果需要触发重新授权，回复内容只包含下面的内部控制面请求，不要追加其它文字：

<ripple_connector_auth_request>{"connector":"bilibili","force_reauth":false,"reason":"needs Bilibili login to fetch subtitles and official AI summary"}</ripple_connector_auth_request>

流程（2 步：抓取 → 写 MD）

Step 1 — 用 bilibili prepare-md 抓取原料 + 算出 output_path

bilibili prepare-md --url "<url 或 BV>" --json

输出一行 JSON，关键字段：

字段	说明
work_dir	/workspace/.bilibili-work/<bvid>[-p<N>]/，含 meta.json / subtitle.json / summary.json / content.txt（字幕 ok 时）
output_path	最终 md 落盘路径，默认 /workspace/outputs/bilibili/YYYY/MM/YYYY-MM-DD-<bvid>-<slug>.md
title / owner / duration / pubdate / url / stat	元信息摘要
subtitle.status	ok / empty / need_sessdata / error
ai_summary.status	同上
has_view_points + view_points_count	是否有 UP 主打的原生章节

如果输出顶层有 error 字段（找不到 BV / extract 子进程崩、或 auth_required=true 等阻断），直接把错误告诉用户或触发 Ripple connector auth，不继续写 MD，不调用 Write，也不要自己构造 /workspace/outputs/bilibili/*.md 路径。注意：subtitle.status = "error" 或 ai_summary.status = "error" 是 字段级错误，不算这里说的"顶层 error"——按下面"失败回退"表静默处理即可， 不要因此中断流程。

Step 2 — 读原料 → 组装 MD 字符串 → Write 落盘 → 原文贴回对话（顺序严格）

进入 Step 2 的前置条件：Step 1 返回了 output_path，且顶层没有 error / auth_required。没有 output_path 时禁止写 Markdown。

1. Read <work_dir>/meta.json 拿 meta + view_points
2. 若 ai_summary.status == "ok"：Read <work_dir>/summary.json 拿 summary + outline（优先用这个做"摘要"和"时间轴"）
3. 若 subtitle.status == "ok"：Read <work_dir>/content.txt 拿字幕纯文本（用作"要点"的素材源 + AI 总结缺失时的兜底）
4. 按下面"模板与硬规则"在心里（不要先贴给用户）组装出一段 Markdown 字符串，记作 MD
5. 用 Write 工具把 MD 落盘到 output_path（工具返回 success 即可，不用读回来）
6. 在同一条回复里把 MD 原封不动（逐字符等同，禁止加 emoji 标题 / 改表格 / 重排列表 / 加粗小标题 / 换章节顺序）贴在对话正文里给用户看
7. 末尾补一行 已生成: <output_path>（约 N 字、M 个章节）

关键硬约束："贴给用户看的内容" 必须和 "Write 工具写进文件的内容" 一字不差。 这两份不是"两份产出"，是同一个字符串的两处引用。装饰化改写 = 违规。 如果你忍不住想"给用户看的版本稍微漂亮一点"——忍住。用户会打开文件的，和你给他看的不一样会让他困惑到底哪个是真的。

收尾 — 末尾用一行说明确认

已生成: <output_path>（约 N 字、M 个章节）

模板与硬规则（直接照抄）

# {{meta.title}}{{ 若 p>1 则追加 " · P" + p + ": " + meta.part_title }}

- **UP 主**：{{meta.owner.name}}（mid: {{meta.owner.mid}}）
- **发布**：{{meta.pubdate | YYYY-MM-DD}}
- **时长**：{{meta.duration | "X 分 Y 秒"}}
- **数据**：{{stat.view | 用 万 / 亿 格式}} 播放 · {{stat.like | 万}} 点赞 · {{stat.coin}} 投币 · {{stat.favorite | 万}} 收藏
- **链接**：{{meta.url}}

## 简介

{{meta.desc 截至前 ~300 字；无则写 "_（UP 主未填简介）_"}}

## 摘要

**一句话**：{{≤ 60 字的本期最浓缩定位}}

> 硬约束：这"一句话"必须可以从 `summary` 字段或 `meta.title` / `meta.desc` 直接
> 派生。**禁止**从 outline 的 part.content 推断"视频风格 / 情绪走向 / 叙事手法 /
> 配乐特点"等节目外解读。

> 下面所有判断里："`subtitle.status` 不是 `ok`" 包括 `empty` / `error` / `need_sessdata`
> 三种情况——也就是说 **error 在用户视角下等价于 empty**，模板分支不为它单独写文案。
> 同理 `ai_summary.status` 不是 `ok` 也包括所有非 ok 状态。

{{
  如果 ai_summary.status=="ok" 且 summary 存在：
    直接使用 summary（官方 AI 总结），可略做语句打磨，不得新增节目外信息
  否则若 subtitle.status=="ok"：
    基于 content.txt 由模型写 1~2 段、≤ 300 字的中等长度摘要
  否则（双方都不是 ok，且不属于双方同时 need_sessdata 的授权阻断场景）：
    "_暂无字幕和 AI 总结，只能基于标题/简介概述：…_"（≤ 100 字，明确标注信息不全）。
    **不要**写"接口被风控 / 抓取失败"之类的技术细节
}}

## 时间轴

> 时间戳来源优先级：`ai_summary.outline[].parts[].timestamp` > `meta.view_points[].from` > 无
> **禁止伪造时间戳**。无时间轴时按下方规则处理。

{{
  优先 ai_summary.outline（仅 ai_summary.status=="ok"）：
    ### {{section.title}}
    - {{HH:MM:SS}}  {{part.content}}
    - ...
  其次 view_points（meta.view_points 非空）：
    - {{HH:MM:SS}}  {{vp.content}}
  都无：
    _（本期无原生章节，也无 AI 总结时间轴）_
}}

## 要点

- 条数规则（**宁少勿多**，禁止凑数）：
    - 有字幕（`subtitle.status=="ok"`）：3~7 条都行，从 content.txt 里抽取关键句
    - 无字幕（`subtitle.status` 非 `ok`，含 `empty` / `error` / `need_sessdata`）但有 AI 总结：
      条数 = `ai_summary.outline[*].parts[*]` 的**总数**，**最少 1 条、最多 5 条**。
      如果 outline 只有 3 个 parts，你就写 3 条要点，不要扩展到 5 条，更不要再加
      "总体风格/整体基调/意外感十足"这种主观条
    - 既无字幕也无 AI 总结（双方都非 `ok`）：写 `_（信息不足以提炼要点）_`，
      **禁止**从 title / desc 硬脑补
- 每条要点的**来源**硬性要求：
    - 必须能一一对应到 `meta.json` 的某个字段、`summary.json` 的某个 `part.content`、
      或 `content.txt` 的某一行。找不到出处就**直接删掉这条**，不要硬凑
    - 可以语句打磨（改词序、合并同义词），但**不得新增原料里没有的事实**
- **禁用词清单**（这些是"加戏"的典型信号，如果你的要点里出现其中之一，**删了
  这整条要点**，不要改）：
    - 主观评价：活跃 / 火爆 / 经典 / 独特 / 精彩 / 精巧 / 生动 / 深刻
    - 风格归纳：情感独白 / 文艺范 / 市井风 / 反差感 / 意外感 / 戏剧张力
    - 技术推断：BGM / 剪辑节奏 / 镜头语言 / 叙事结构（除非原料里明确出现这些词）
    - 情绪推断：从迷茫到释然 / 情绪基调 / 内心世界（除非 summary 原句出现这类词）
    - 数字评价：「7500+ 条评论」可以写，但加"活跃/热烈"就违规——只罗列数字不下判断

## 相关链接

- 视频：{{meta.url}}
- UP 主：https://space.bilibili.com/{{meta.owner.mid}}
- {{meta.desc 中出现的外部链接（如有）}}

---

<sub>由 B 站视频总结自动整理。原料：`{{work_dir}}`。</sub>

内容硬规则

• 所有人名 / 数字 / 机构 / 引述都必须能在 meta.json / summary.json / content.txt 里找到出处，不引入节目外知识
• 中文引号统一用 「」 / 『』，不要半角 "
• 时间戳格式统一 HH:MM:SS（含 0 前缀）；< 1 小时 也写成 00:MM:SS 方便对齐，或统一写 MM:SS——整篇保持一致
• 播放 / 点赞 / 收藏数据用人类可读格式：10000 → 1.0 万，100000000 → 1.0 亿
• 如果 ai_summary.status == "need_sessdata" 且 subtitle.status == "need_sessdata"： 说明登录态缺失或过期。不要写 Markdown，改为触发 Ripple Bilibili connector 授权。
• Markdown 不超过 3 级标题
• 不要在 md 里出现调试信息 / <details> / "由模型生成" 字样

输出 Schema（给上层 caller 的整个回复）

1. 完整 Markdown 文本（用户要看的产物）
2. 一行确认：已生成: <output_path>（X 字 / Y 个章节）

不需要返回 JSON。上层 caller 直接用 output_path 作为 artifact。

失败回退

核心原则：别把技术错误甩给用户。 普通用户对 -412 风控 / WBI 签名失败 / HTTP 412 这类术语既看不懂、也没办法解决，写在 MD 里只会让对话像出 bug。 因此：status = error 在 MD 用户视角下，等价于 empty —— 静默走"没有字幕 / 没有 AI 总结"分支，不暴露任何错误码、不加 ⚠️、不留任何技术债气味。 真正的错误信息已经写在 subtitle.json / summary.json 的 raw_code / raw_message 里，开发者排查时自己 cat 即可。

场景	行为
prepare-md 顶层返回 error（找不到 BV / 进程异常 / extract 子进程崩）	把 error.message 告诉用户，不产出 MD（这种是真的没法继续）
prepare-md 返回 auth_required=true	不写 MD，不调用 Write。回复内部 <ripple_connector_auth_request>，让 Ripple server 发起 Bilibili 授权
subtitle.status = need_sessdata 且 ai_summary.status = need_sessdata	凭证缺失或失效。先不写 MD，回复内部 <ripple_connector_auth_request>，授权完成后重跑 prepare-md
仅 subtitle.status = need_sessdata，ai_summary 正常	通常意味着 UP 主没开字幕（B 站返回 -101 也有这种歧义）。正常产出，"字幕节选"章节写 _（本期未提供字幕）_ 即可，不要为此重登
subtitle.status = error（任何原因：风控 / WBI / 网络 / 字幕文件下载失败）	静默按"无字幕"处理 —— 模板里"字幕节选" / "要点"分支按 empty 走（写 _（本期未提供字幕）_），不在 MD 任何位置写错误码、不加 ⚠️、不告诉用户「被风控了 / 接口失败」。如果同时 AI 总结正常，输出体验对用户来说就是"这视频没字幕"，刚好和"empty"一样
ai_summary.status = error（任何原因）	静默按"无 AI 总结"处理，等同于 empty
subtitle.status = ok、ai_summary.status = empty（含真 empty 和静默并入的 error）	正常产出，摘要改由模型基于字幕写（B 站该视频暂无 AI 总结是常见情况）
subtitle.status = empty（含静默并入的 error）、ai_summary.status = ok	正常产出，时间轴/要点基于官方 AI 总结；"字幕节选"相关内容跳过
subtitle.status = empty 且 ai_summary.status = empty（含双方静默并入的 error）	两边都没内容。产出 MD 但"要点"章节写 _（信息不足以提炼要点，建议直接打开视频查看）_；禁止从 title/desc 硬脑补要点
meta.desc 空 / view_points 空 / duration 空	用 _未标注_ / _（本期无…）_ 占位，绝不编造

禁用项

• ❌ 不要生成任何 summary.json / outline.json（bilibili prepare-md 已生成，你只读不写）
• ❌ 不要调完 prepare-md 之后又反复 Read meta.json 多次 —— 一次就够
• ❌ 不要把"对话正文"和"Write 文件"做成两份差异化产物。两者必须完全等同 （一字不差）。严禁给对话版加 emoji 标题（📌 📖 🕐 🔑 等）、把列表改成表格、 给章节小标题加粗、重排章节顺序、添加对话专用的介绍语 / 总结语。贴给用户的 版本 = 文件内容，不是"文件内容 + 装饰"
• ❌ 不要运行 bilibili auth start/poll/status/logout；B 站授权属于 Ripple server control plane
• ❌ 不要用正则 / 字符串扣 B 站网页来替代 bilibili extract/prepare-md——API 路径已经封装稳了
• ❌ 不要对无 AI 总结的视频硬编"伪时间轴"——缺就缺，明确标注