shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringAPI key requirement unconfirmed

OceanBase 大赛赛题侦察

给定语雀文档 slug，抓取正文与目录、抽取分值表与验收点，产出赛题交付清单。适用于 OceanBase 数据库大赛等语雀赛事文档的快速侦察。

personAuthor: zhouweirunhubModelScope
downloadDownload package

OceanBase 大赛赛题侦察（ob-contest-recon）

单文件技能：无需安装任何依赖，只需能发 HTTP 请求 + 一个能渲染 JS 的取页工具。 把"翻几十篇语雀文档、手抄分值表"变成一条可复现的流水线： 定位文档 → 取正文 → 补全目录（ToC）→ 抽取分值/验收点 → 产出可执行清单。

何时使用

  • 用户贴一个语雀链接，问"这题要交什么""几分""怎么判"。
  • 用户给书名（book slug），想知道"这本书下面一共有哪些子文档"。
  • 需要把赛题整理成表格：题目 / 分值 / 交付物 / 判分方式 / 时效 / 外部账号。
  • 需要判断"这条提交是 PR 制、仓库制还是纯材料制"，以及"哪些分能累计"。

何时不要使用

  • 文档在登录墙后面（返回页标题是 登录 · xxx）→ 明确告诉用户"需登录后手工确认"，不要猜内容。
  • 用户要你代他报名、提测、领 Token、扫码→ 拒绝执行，只给步骤。

四条核心事实（先记住，能省一半时间）

  1. 取正文：任意语雀文档 URL 后拼 /markdown?plain=true&linebreak=false&anchor=false，即得纯 markdown 原文。 例：https://<org>.yuque.com/<ns>/<book>/<slug>/markdown?plain=true&linebreak=false&anchor=false
  2. 取目录：markdown 导出不含侧栏 ToC。书首页、/sitemap.xml、/api/v2/repos/*/toc 要么是 SPA 空壳、要么 302 到登录页、要么 401 —— 全部没用。 唯一稳定办法：渲染页面后读侧栏 ToC 的链接。
  3. ToC 只展开"当前节点"的下一层，所以要对每个容器父文档各渲染一次，不能指望一次拿全书。
  4. SPA 平台页同理（如 open.oceanbase.com/train/detail/<id>）：直接 HTTP 只拿到站点标题， 必须渲染后再读 —— 渲染后能拿到官方"题目介绍"原文（分值、验证码获取步骤、计分规则）。

工作流

步骤 1 · 取正文（纯 HTTP，无需依赖）

对每个 slug 抓一次 markdown 原文，存为 <slug>.md：

# 单篇
curl -sSL "https://<org>.yuque.com/<ns>/<book>/<slug>/markdown?plain=true&linebreak=false&anchor=false" -o <slug>.md
# 或纯 Python（无第三方库）
python3 -c "import urllib.request,sys;u=sys.argv[1];open(sys.argv[2],'w',encoding='utf-8').write(urllib.request.urlopen(u,timeout=30).read().decode('utf-8'))" "<url>" "<slug>.md"

判定空壳/登录墙：正文 < 20 字符，或出现 登录 与站点名 → 这页是容器节点或需登录。 此时不要重试，而应去找它的父节点或子节点。

步骤 2 · 补全目录（需要渲染能力）

用能执行 JS 的取页工具（如 tavily_extract，参数 extract_depth=advanced、format=markdown） 渲染以下三类页面，从返回文本的 ToC / Outline 区块里把所有 …/<book>/<20位slug> 链接抓出来：

  1. 书首页 https://<org>.yuque.com/<ns>/<book> → 顶层节点；
  2. 每个容器父文档（正文很短、只有一句简介）→ 它的直接子节点；
  3. 交叉验证：正文里的「重要索引 / 目录」表格常直接给出 4–6 个关键子文档链接。

结果记成 slugs.tsv（slug<TAB>标题），后续步骤都以它为输入。

步骤 3 · 抽分值表与验收点（三条规则，人眼或正则都能做）

  • 表格里出现 总分 / 分数 / 分值 且单元格是数字 → 记为分值行；
  • 出现 | 项目 | 说明 | 这类键值对表 → 抽为元数据（题目、任务、提交产物、评价方式）；
  • 出现 验收 / 评分 / 通过条件 / 得 X 分 的段落 → 记为验收点，并标注判分模式（见下表）。

步骤 4 · 产出清单

固定 6 列：题目 | 分值 | 交付物 | 判分方式 | 时效 | 外部账号/Token， 每项都标证据来源（哪个 slug 的哪一段）。没查到就写"未查到，需登录/需实测"，禁止编造。

判分模式的识别要点

| 措辞特征 | 判分模式 | 应对策略 | |---|---|---| | "全部通过得 X 分，任一项不通过得 0 分" | 全或无 | 先把最弱的验收项补到能过 | | "权重 40% / 30% / 20% / 10%" | 加权评分 | 优先攻高权重维度 | | "从基线提升 50% 即为满分，0% 以下为 0 分" | 连续打分 | 先保证非零，再冲阈值 | | "PASS (35/35)" 逐项列出 | 分项计分 | 可逐项累加，适合分批提交 | | "已通过项会保留，后续不再重复核验" | 累计制 | 先交容易的，锁定分数 |

提交形态的识别要点

  • 仓库制：题面写"代码仓库地址""Branch/Commit"→ 平台克隆你的私有仓，留空即取默认分支最新。 ⚠️ 填了 commit id 就会一直测同一份代码 —— "改了代码结果没变"多半是这个原因。
  • PR 制：题面写"提交 Pull Request 并把地址/编号交到平台"→ 分记在上游仓库，通常不要求合并。
  • 验证码制：题面要求"队伍验证行/校验码"→ 一般平台侧生成、队伍级、本题内不失效； 常见要求是"原样、独立一行，写进 README 或 PR 正文（不是评论）"。
  • 纯材料制：只需一个 Markdown 或一个网址/编号 → 性价比最高，优先做。

输出格式

| 题目 | 分值 | 交付物 | 判分方式 | 时效 | 外部账号/Token | 证据 |
|---|---|---|---|---|---|---|

末尾必须附一节 「未决项」，列出所有"官方未公开 / 需登录 / 需实测"的点，并写清验证办法。

约束

  • 只读公开页面；不代用户登录、报名、提测、领券。
  • 抓取失败先判是"网络"还是"SPA/登录墙"：前者重试一次，后者换方法或如实上报。
  • 任何结论都要能指回一个 URL 或一段原文；当两处总分冲突时，以分值表/平台题目页为准， 并在输出里显式指出冲突（实战教训：同一赛事文档里"210 / 240 / 620"三个口径都出现过）。

一个最小可用示例

输入：xkmkblbzlzk581ya（某赛事的"算分规则"页）

  1. 取正文 → 得到一个 8 行的分值表；
  2. 渲染该页并读 ToC → 拿到同书 13 个兄弟节点 slug；
  3. 抽表 → 识别出"基础实践 30 分（部署/Fork/PR 各 10，累计制）"这类可增量拿分的条目；
  4. 输出 → 一张带证据的表格 + 未决项「平台每日提测次数未公开，需实测」。

结论：先做"纯材料制 + 累计制"的题锁定底分，再攻"全或无"的高分题。

OB-P:BWyQKIIEoAjPalsYyx6Keg

<!-- OB-S:FactpgTgy6uQTLzutV93Mg -->