From 90812b7d0c051095fa3c627b86480689b517c9f9 Mon Sep 17 00:00:00 2001 From: s2_cc <1702138968@qq.com> Date: Wed, 1 Jul 2026 08:09:31 +0800 Subject: [PATCH] =?UTF-8?q?feat:=20add=20gitlink-research-matching=20skill?= =?UTF-8?q?=20(=E7=A7=91=E7=A0=94=E5=8D=8F=E4=BD=9C=E6=99=BA=E8=83=BD?= =?UTF-8?q?=E5=8C=B9=E9=85=8D)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 子任务4 场景B：科研协作智能匹配 skill。 - 委托 gitlink-insight 取贡献者活跃画像，自研科研角色匹配 - 4 科研角色体系（数据/算法/工程/评测）× 开放 Issue 需求 → 人-任务匹配 - 全程纯远程只读，证据导向建议记录（不算分、不评级） - 严格服务匹配的仓内资源探测（区别于场景A 的全面复现性清点） - 含可复现运行脚本模板（examples/matching-run.md） --- skills/gitlink-research-matching/SKILL.md | 257 ++++++++++++++++++ .../examples/matching-run.md | 160 +++++++++++ 2 files changed, 417 insertions(+) create mode 100644 skills/gitlink-research-matching/SKILL.md create mode 100644 skills/gitlink-research-matching/examples/matching-run.md diff --git a/skills/gitlink-research-matching/SKILL.md b/skills/gitlink-research-matching/SKILL.md new file mode 100644 index 0000000..86d0d32 --- /dev/null +++ b/skills/gitlink-research-matching/SKILL.md @@ -0,0 +1,257 @@ +--- +name: gitlink-research-matching +version: 1.0.0 +description: "科研协作智能匹配：纯远程只读分析一个 GitLink 科研仓库——委托 gitlink-insight 取贡献者活跃画像，再自研科研角色匹配（贡献者→数据/算法/工程/评测 角色 × 开放 Issue 科研角色需求），输出证据导向的《科研协作匹配建议记录》。当用户需要判断科研仓库里某个任务该交给哪种科研角色的人、仓内缺不缺会卡住匹配的资源时触发。" +metadata: + requires: + bins: ["gitlink-cli"] + cliHelp: "gitlink-cli issue --help" +--- + +# gitlink-research-matching（科研协作智能匹配） + +**CRITICAL — 开始前必须先阅读 [`../gitlink-shared/SKILL.md`](../gitlink-shared/SKILL.md)，其中包含认证、权限处理和 API 注意事项。** +**CRITICAL — 本 Skill 全程只读，不向仓库写任何内容（不指派、不建 Issue、不评论——科研匹配只是建议，不应污染他人仓库）。** +**CRITICAL — GitLink 操作只能用 `gitlink-cli`，禁止用 `gh`（GitHub CLI）操作 GitLink 资源。** + +## 说明 + +本 Skill 面向**科研场景**，回答一个 `gitlink-insight` 和 `gitlink-issue-triage` 都不回答的问题：**这个科研仓库里的某个开放任务，该交给哪种科研角色的人来做？仓内有没有这种人、缺不缺会卡住匹配的资源？** + +它**委托** `gitlink-insight` 跑贡献者活跃画像（"人"侧输入），自己专注科研独有的四部分：①贡献者科研角色推断；②开放 Issue 科研角色需求分析；③人-任务匹配；④服务匹配的仓内资源探测。 + +**产物哲学（重要）**：输出的是**证据导向的匹配建议记录**，不是分数排名。每条建议先呈现"看到了什么"（Issue 原文 + 贡献者历史证据），让科研负责人**自行决策**；匹配只是建议，不指派、不写入。 + +## 与 `gitlink-insight` / `gitlink-issue-triage` 的边界 + +| 维度 | `gitlink-insight`（被委托） | `gitlink-issue-triage`（**完全不碰**） | **`gitlink-research-matching`（本 Skill）** | +|---|---|---|---| +| 核心问题 | 谁**活跃**/贡献多 | 这个 Issue 是**什么工程类型** | 这个**科研任务**该哪种**科研角色**的人做 / 缺什么**科研资源** | +| 分类体系 | 不分类，只活跃度排名 | Bug/Feature/文档/咨询 + 后端/前端/PM | **数据/算法/工程/评测**（科研角色） | +| 动词 | 洞察（指标） | 分拣 + **写入**（打标签/指派/评论） | 匹配（**只读建议**） | +| 产物 | 健康度/周报/贡献者表 | 分拣方案表 + 实际打标签 | 《科研协作匹配建议记录》 | + +> 职责正交：insight 管"谁活跃"，triage 管"工程分类+打标签"，本 Skill 管"科研角色匹配"。完全不碰 triage（避免与写入型 triage 纠缠），Issue 的科研角色分析全自研。 + +## 科研角色分类体系 + +4 角色，每角色配套可观测信号（贡献者画像）+ Issue 关键词（任务需求）。这是区别于 triage 的后端/前端/PM、insight 的不分类的根本。 + +| 科研角色 | 职责含义 | 贡献者画像信号（PR 标题 `name` / 分支 `pull_request_head`） | Issue 需求关键词 | +|---|---|---|---| +| **数据** | 数据采集/清洗/标注/数据集制作/加载 | 标题或分支含 `data/`、`dataset`、`dataloader`、`prepare_*`、`download_*` | 数据集、dataset、dataloader、标注、annotation、数据缺失 | +| **算法** | 模型结构/损失/训练逻辑/核心方法 | 标题或分支含 `model`、`loss`、`train`、`src/`、`net`、`backbone` | 模型、model、训练、loss、损失、网络、精度、architecture | +| **工程** | 部署/性能/环境/基础设施 | 标题或分支含 `docker`、`requirements`、`deploy`、`ci`、`env`、`Makefile` | 部署、deploy、环境、docker、安装、fps、内存、推理速度 | +| **评测** | 指标/评测脚本/benchmark/结果验证 | 标题或分支含 `eval`、`evaluate`、`metrics`、`MOTA`、`test`、`benchmark` | 评测、eval、metric、MOTA、MAP、指标、benchmark、复现结果 | + +> **科研独有性**：「评测」角色在 dev triage 里根本不存在；「数据」在 triage 里被归成 question/feature，但在科研里是独立角色。 + +### 多角色标注规则 + +- 每个贡献者/Issue 标注**主角色 + 次角色**（次角色可空）。 +- 主角色 = 证据最多/信号最强的角色；次角色 = 有明确信号但弱于主角色。 +- 语义优先，关键词兜底：你是 AI Agent，价值在读懂 Issue 意图（如"训练 loss 不收敛"即使无"算法"字眼也应归算法），上表关键词只是兜底。 + +### 置信度规则 + +- 🟢 高：该角色有 ≥2 条明确证据（如 2+ 个该方向 PR）。 +- 🟡 中：1 条明确证据，或主次各 1 条但主角色略强。 +- 🔴 低：仅 `user +info` 关键词推断 / 信号模糊或冲突。 + +## ⚠️ 关键接口坑（已实测，务必遵守） + +| 需求 | 正确做法 | 说明 | +|---|---|---| +| 读文件内容 | `file +get`→`file +blob`（base64）两步走 | `file +get` 只返回 sha，`content` 恒为 None | +| 读 README | `file +readme` | 唯一一步取明文 content 的命令 | +| PR 按贡献者过滤 | **客户端过滤**（`pr +list` 无服务端 author 过滤） | 按 `data.issues[].author_login` 过滤 | +| PR 状态判断 | 客户端按 `pull_request_status`（0=open,1=merged,2=closed） | `--state` 仅影响统计计数，列表可能含全部状态 | +| PR 标题/作者字段 | `.name`（标题）、`.author_login`（作者） | **平铺字段**，非嵌套；列表项**不含改动文件路径** | + +> 数据结构要点：`pr +list` / `issue +list` 返回的 `data` 是**对象**，PR/Issue 列表在 **`data.issues[]`**（不是 `data[]`）。 +> `repo +info` **无 `language` 字段**，主语言需从 requirements/文件后缀推断。 +> ⚠️ **仓库选择坑**：避免用 GitHub 镜像 repo（`mirror=true`，协作数据在源站，GitLink 上 Issue/PR 基本为空）；优先选原生协作 repo。 + +## 工作流概览 + +| 步骤 | 操作 | 命令 | +|------|------|------| +| ① 仓库元信息 + 贡献者活跃画像（委托） | 语言/开放数 + 活跃贡献者 top-5 | `repo +info` + 委托 `gitlink-insight` 工作流3 | +| ② 贡献者科研角色推断（自研） | top-5 每位 → 主+次角色 + 证据 + 置信度 | `pr +list`（客户端按 author 过滤，最近30条）/ `issue +list` / 按需 `user +info` | +| ③ Issue 科研角色需求分析（自研） | 每个 open Issue → 主+次角色 + 原文证据 | `issue +list --state open` / `issue +view` | +| ④ 人-任务匹配（自研） | ②×③ 交叉 → 谁适合做哪个 Issue + 置信度 | （分析，无命令） | +| ⑤ 仓内资源互补（自研，服务匹配） | 数据/权重有无 + 缺资源型 Issue | `dataset +list` / `release +list` / `file +readme` | +| ⑥ 综合裁决 | 四类证据汇总 → 匹配建议记录 | （分析，无命令） | + +> 全程只读，串联 ≥6 类 CLI 调用。 + +--- + +## 详细工作流 + +### Step ① 仓库元信息 + 贡献者活跃画像（委托） + +```bash +gitlink-cli repo +info --owner --repo --format json +# 委托 gitlink-insight 工作流3（贡献者洞察）：按 ../gitlink-insight/SKILL.md 的「工作流 3」执行 +# → 取活跃贡献者（按合并 PR 数排序），截断 top-5 +``` + +记录：主语言（供 Step ②③ 关键词映射）、开放 Issue 数、活跃贡献者 top-5（不足 5 人以实际为准）。 + +> 活跃贡献者也可直接从 PR 列表聚合 author_login 得到（见 Step ② 的 PR 拉取）。 + +### Step ② 贡献者科研角色推断（多源，自研） + +对 top-5 每位贡献者： + +```bash +# a. 拉取该仓库全部 PR（列表项含 author_login / name 标题 / pull_request_head 分支 / pull_request_status） +gitlink-cli pr +list --owner --repo --format json \ + | jq '[.data.issues[] | {author: .author_login, title: .name, branch: .pull_request_head, status: .pull_request_status}]' +# → 客户端按 author == "" 过滤，取最近 30 条 +# → 看 title(name) + 分支(pull_request_head)，按角色体系匹配 + +# b. 该贡献者关闭/参与过的 Issue（客户端按 author_login 过滤） +gitlink-cli issue +list --owner --repo --state closed --format json \ + | jq '[.data.issues[] | {author: .author_login, subject}]' +``` + +**按需深挖（仅当 a+b 信号不足以判定主角色时）**： + +```bash +# c. user +info（只看名/简介关键词，不深挖其他 repo 内容） +gitlink-cli user +info --login --format json +``` + +**输出**：每位贡献者 → 主角色 + 次角色（可空）+ 证据（哪几条 PR/Issue 支撑）+ 置信度（见角色体系置信度规则）。 + +> ⚠️ PR 列表项**不含改动文件路径**，贡献者方向只能靠 PR 标题 `name` + 分支名 `pull_request_head` 推断（如分支 `feature/dataloader` → 数据角色）。 + +### Step ③ Issue 科研角色需求分析（自研） + +```bash +gitlink-cli issue +list --owner --repo --state open --format json \ + | jq '[.data.issues[] | {number, subject, author: .author_login, tags: .issue_tags}]' +# 逐个读详情 +gitlink-cli issue +view --owner --repo --number --format json +# → 读 subject + description，按角色体系的 Issue 关键词语义归类 +``` + +**输出**：每个 open Issue → 所需主角色 + 次角色 + 原文证据片段。 + +> 与 triage 的根本区别：triage 归 bug/feature/咨询，本 Skill 归**科研角色需求**（这个 Issue 本质需要数据/算法/工程/评测哪种人）。"训练 loss 不收敛" triage 可能归 bug，本 Skill 归**算法**。 + +### Step ④ 人-任务匹配（自研） + +②（贡献者角色）× ③（Issue 角色需求）交叉： + +- **主角色匹配**：Issue 主角色 == 贡献者主角色 → 高置信度候选。 +- **次角色匹配**：Issue 主角色 == 贡献者次角色，或 Issue 次角色命中 → 中置信度候选。 +- **无匹配 → 分两类**（关键，避免"缺人/缺资源"混淆）： + - **角色缺口**：Issue 所需角色无任何 top-5 贡献者覆盖（**缺人**）→ 记入报告"未匹配/缺口"表，类型=角色缺口，**不进入 Step⑤**。 + - **缺资源型**：Issue 在"要数据/要权重/要评测基准"，即使有人匹配也会被资源卡住 → 在 Step⑤ 用资源探测确认，并在匹配建议里打资源前提标签。 + +> 区分原则：先判角色是否有人覆盖（Step④），再判资源是否就绪（Step⑤）。**缺人 ≠ 缺资源**，两者报告分列。 + +### Step ⑤ 仓内资源互补（收窄，服务匹配，自研） + +**只查与 open Issue/任务相关的资源缺口**，不做全面复现性清点（那是 `gitlink-research-compliance` 的活）： + +```bash +# 数据集有无 +gitlink-cli dataset +list --owner --repo --format json +# → .data.releases（计数：.data.releases | length） +# 预训练权重/数据包 +gitlink-cli release +list --owner --repo --format json +# → .data.releases（计数同上） +# README 数据/权重说明（明文） +gitlink-cli file +readme --owner --repo --format json +# → 搜 download/weights/pretrained/数据集/指标 等 +``` + +**判定**： +- 识别**缺资源型 Issue**：Issue 在"要数据/要权重/要评测基准"（关键词：数据集、weights、pretrained、download、指标、复现结果），而仓内 `dataset +list` 为空 / 无权重 release。 +- 给 Step④ 匹配建议打**资源前提标签**：如"某某适合做（算法），但阻塞于缺评测数据集"。 + +> 与 `gitlink-research-compliance` 的区别：它问"仓库整体能不能复现"（全面清点），本 Skill 只问"**这个任务**缺不缺资源、会不会卡住匹配的人"（服务匹配，点到为止）。 + +### Step ⑥ 综合裁决 + +汇总四类证据，输出《科研协作匹配建议记录》。**先证据，后建议**，匹配只是建议，不指派、不写入。 + +## 综合匹配建议报告模板 + +````markdown +🤝 科研协作匹配建议记录 — / +═══════════════════════════════════════════════════ +生成日期: 主语言: +开放 Issue: 贡献者画像: top-（委托 gitlink-insight） +建议方式: 纯远程只读（gitlink-cli repo/issue/pr/dataset/release/file）。 +说明: 所有匹配均为只读建议，不指派、不写入；请结合团队实际自行决策。 + +─────────────────────────────────────────────────── +一、贡献者科研角色画像（top-） +─────────────────────────────────────────────────── +| 贡献者 | 活跃度(insight) | 主角色 | 次角色 | 置信度 | 证据 | +|--------|-----------------|--------|--------|--------|------| +| | <合并PR n> 最近活跃 | 算法 | 评测 | 🟢高 | PR"改进loss"×3, 分支 eval/*×2 | + +─────────────────────────────────────────────────── +二、开放 Issue 科研角色需求 +─────────────────────────────────────────────────── +| #Issue | 标题 | 主角色需求 | 次角色 | 缺资源型? | 原文证据 | +|--------|------|-----------|--------|-----------|----------| +| | <标题> | 算法 | — | 否 | "训练 loss 不收敛"→算法 | +| | <标题> | 评测 | — | ⚠️是 | "缺评测数据集，dataset+list为空" | + +─────────────────────────────────────────────────── +三、人-任务匹配建议（核心） +─────────────────────────────────────────────────── +| #Issue | 建议人选 | 匹配角色 | 置信度 | 资源前提 | 理由 | +|--------|----------|----------|--------|----------|------| +| | | 主角色(算法) | 🟢高 | 无 | 该Issue需算法，userA主角色算法(3个loss相关PR) | +| | | 次角色(评测) | 🟡中 | ⚠️阻塞于缺评测数据集 | 该Issue需评测，userB次角色评测，但仓内无数据集 | + +未匹配/缺口 Issue: +| #Issue | 所需角色 | 类型 | 说明 | +|--------|----------|------|------| +| | 工程 | 角色缺口 | top-5无工程角色贡献者（缺人，非缺资源） | +| | 数据 | 缺资源型 | Issue要数据但仓内无数据集（缺资源，非缺人） | + +─────────────────────────────────────────────────── +四、仓内资源互补（仅服务匹配） +─────────────────────────────────────────────────── +[证据] + • GitLink 原生数据集: dataset +list → <有n个/无> + • 预训练权重: release +list → <有n个/无> + • README 数据/权重说明: "<原文片段>" / 未发现 +[发现] + • 缺资源型 Issue: <#j, #m ...>（共n个） + • 这些 Issue 即使匹配到人也会被资源卡住 + +═══════════════════════════════════════════════════ +匹配状况概览（统计，非评分 — 算分会惩罚"正确识别缺口"） + 开放 Issue: + ├─ 已匹配(有候选贡献者): (🟢高置信 / 🟡中置信 ) + ├─ 角色缺口(缺人): — 所需角色 top- 未覆盖 + └─ 缺资源型(缺数据/权重): — 有人匹配也会被卡住 + 贡献者角色覆盖: 数据<✓/✗> 算法<✓/✗> 工程<✓/✗> 评测<✓/✗> +═══════════════════════════════════════════════════ +```` + +> 报告主体是建议表与证据，概览只给一眼可读的计数。不算分、不评级——匹配是建议而非客观事实，分数会惩罚"正确识别缺口"的行为（准确标出角色缺口反让覆盖度/消化力扣分）。 + +## 使用示例 + +见 [`examples/matching-run.md`](examples/matching-run.md)：在 `<验证仓库>` 上的完整匹配记录。 + +## 注意事项 + +- 本 Skill **全程只读**，不写仓库、不建 Issue、不指派——科研匹配只是建议，应尊重他人仓库。 +- **不碰 `gitlink-issue-triage`**：triage 会写入（打标签/指派/评论），本 Skill 避免与其耦合，Issue 科研角色分析全自研。 +- 多源画像有**截断策略**控制成本：贡献者取 top-5；PR/Issue 历史取最近 30 条；`user +info` 仅对"角色不明者"按需补，不全员深挖、不读用户其他 repo 内容。 +- `pr +list` 无服务端 author 过滤，须客户端过滤；`--state` 不精确，按 `pull_request_status` 二次判断。 +- 角色关键词表是**兜底**，语义优先（AI Agent 读懂 Issue 意图）。 +- 资源互补严格**服务匹配**，不做全面复现性清点（那是 `gitlink-research-compliance`）。 +- 团队实际分工受成员可用性影响，匹配建议仅供参考，不替负责人决策。 diff --git a/skills/gitlink-research-matching/examples/matching-run.md b/skills/gitlink-research-matching/examples/matching-run.md new file mode 100644 index 0000000..16becec --- /dev/null +++ b/skills/gitlink-research-matching/examples/matching-run.md @@ -0,0 +1,160 @@ +# gitlink-research-matching 运行记录模板 + +> **状态说明（重要，务必先读）**：本文档是一份**可复现执行脚本模板**，包含完整的命令序列、`jq` 解析逻辑与**预期输出结构**。 +> +> 它**尚未在理想的"原生协作型科研仓库"上填入真实报告数据**。原因：探测发现 GitLink 平台上原生科研仓库普遍缺乏协作 PR+Issue 数据（多为 GitHub 镜像、单作者展示型、或大赛 repo），少数有 PR 的仓库（如 `mindspore/mindspore`）是 CCF 比赛 repo——每个 PR 是一支队伍的独立参赛作品，而非同仓库协作改模块，与本 Skill「同仓库科研角色协作分工」的核心设计错配，硬跑会产出扭曲的空报告。 +> +> **如何使用本模板**：找到一个 GitLink 上**原生（`mirror:false`）、有 ≥10 个协作 PR、有多个 open Issue 的科研仓库**后，把下文 `/` 替换为目标仓库，逐 Step 执行命令，将真实输出与推断填入对应位置，替换本说明段，即得到一份真实的《科研协作匹配建议记录》。 +> +> 命令与 `jq` 解析逻辑均已用 `gitlink-cli` 实测数据结构校验（见下文「数据结构基准」），替换仓库后可直接复用。 + +--- + +## 0. 环境与前置 + +```bash +gitlink-cli auth status # 确认已登录 +gitlink-cli pr +list --help # 确认子命令可用 +``` + +**数据结构基准**（实测 `gitlink-cli`，2026-06-29）： +- 所有命令 `--format json` → `{ok, data, meta}`。 +- `pr +list` / `issue +list` 的 `data` 是对象，PR/Issue 列表在 **`data.issues[]`**。 +- PR 项：`author_login`（作者，平铺）、`name`（标题）、`pull_request_head`（分支）、`pull_request_status`（0=open,1=merged,2=closed）。 +- Issue 项：`number`、`subject`、`author_login`、`issue_tags`。 +- `dataset +list` / `release +list`：列表在 `data.releases[]`（计数 `length`；`dataset +list` 在某些仓库可能报 parse error，需注意）。 +- `repo +info`：有 `issues_count`/`pull_requests_count`/`mirror`，**无 `language`**。 +- `user +info --login `：返回 `login`/`name`/`bio`（可能为 null）。 + +--- + +## Step ① 仓库元信息 + 贡献者活跃画像 + +```bash +# 仓库元信息 +gitlink-cli repo +info --owner --repo --format json \ + | jq '{name:.data.name, issue:.data.issues_count, pr:.data.pull_requests_count, mirror:.data.mirror}' +``` +**预期输出结构**（待填）： +``` +{ "name": "<...>", "issue": , "pr": , "mirror": false } +``` + +```bash +# 委托 gitlink-insight 工作流3 取贡献者活跃画像 → 活跃贡献者 top-5 +# 按 ../gitlink-insight/SKILL.md「工作流 3」执行，记录每位：合并PR数、最近活跃时间 +``` + +**或直接从 PR 聚合作者活跃度**（与 insight 互补）： +```bash +gitlink-cli pr +list --owner --repo --format json \ + | jq '[.data.issues[].author_login] | group_by(.) | map({author:.[0], n:length}) | sort_by(-.n) | .[0:5]' +``` +**预期输出结构**： +``` +[ {"author":"","n":}, {"author":"","n":}, ... ] # top-5 +``` + +**记录（待填）**：主语言=___；开放 Issue=___；活跃贡献者 top-5 = ___ + +--- + +## Step ② 贡献者科研角色推断（多源） + +对 top-5 每位贡献者拉取其 PR（标题+分支作为角色证据）： + +```bash +gitlink-cli pr +list --owner --repo --format json \ + | jq -r --arg u "" '.data.issues[] | select(.author_login==$u) | "\(.name) | 分支:\(.pull_request_head // "?") | 状态:\(.pull_request_status)"' +``` +**预期输出结构**（每位贡献者，待填）： +``` + | 分支: | 状态:<0/1/2> + | 分支: | 状态:<0/1/2> +``` + +按需深挖（角色不明者）： +```bash +gitlink-cli user +info --login --format json \ + | jq '{login:.data.login, name:.data.name, bio:.data.description}' +``` + +**角色推断（按 SKILL.md 角色体系，待填）**： + +| 贡献者 | 主角色 | 次角色 | 置信度 | 证据 | +|--------|--------|--------|--------|------| +| `` | ___ | ___ | ___ | `→<角色>` | + +--- + +## Step ③ Issue 科研角色需求分析 + +```bash +gitlink-cli issue +list --owner --repo --state open --format json \ + | jq '[.data.issues[] | {number, subject, author:.author_login, tags:.issue_tags}]' +``` +**预期输出结构**： +``` +[ {"number":,"subject":"<标题>","author":"","tags":[...]}, ... ] +``` + +逐个读详情： +```bash +gitlink-cli issue +view --owner --repo --number --format json \ + | jq '{subject:.data.subject, desc:(.data.description // "" | .[0:200])}' +``` + +**Issue 科研角色需求（待填）**： + +| #Issue | 标题 | 主角色需求 | 次角色 | 缺资源型? | 原文证据 | +|--------|------|-----------|--------|-----------|----------| +| `` | `<标题>` | ___ | ___ | ___ | `"<原文>"→<角色>` | + +--- + +## Step ④ 人-任务匹配（分析，无命令） + +②（贡献者角色）× ③（Issue 需求）交叉。规则见 SKILL.md Step④。 +- 主角色匹配 → 高置信；次角色匹配 → 中置信；无覆盖 → 角色缺口（记入缺口表）。 + +**匹配建议（待填）**： + +| #Issue | 建议人选 | 匹配角色 | 置信度 | 资源前提 | 理由 | +|--------|----------|----------|--------|----------|------| +| `` | `` | ___ | ___ | ___ | ___ | + +--- + +## Step ⑤ 仓内资源互补（服务匹配） + +```bash +# 数据集 +gitlink-cli dataset +list --owner --repo --format json \ + | jq '{releases_len:(.data.releases|length?)}' # 注意：某些仓库可能 parse error +# 权重/release +gitlink-cli release +list --owner --repo --format json \ + | jq '{releases_len:(.data.releases|length)}' +# README 数据/权重说明 +gitlink-cli file +readme --owner --repo --format json \ + | jq -r '.data.content' | grep -iE "download|weights|pretrained|数据集|指标|dataset" | head -5 +``` +**预期输出结构**：数据集=___个；release=___个；README 数据/权重说明=___。 + +**判定**：识别"缺资源型 Issue"（Issue 要数据/权重，仓内无）→ 给匹配建议打资源前提标签。 + +--- + +## Step ⑥ 最终报告（待真实数据填充） + +> 按 SKILL.md「综合匹配建议报告模板」填写四张表 + 缺口表 + 统计概览。模板见 `../SKILL.md`。 + +--- + +## 附：在 mindspore/mindspore 上的探测记录（说明为何该仓库不适配） + +为完整记录探测过程，此处留存 `mindspore/mindspore`（CCF 比赛 repo）的实测数据，作为**仓库选型反例**： + +- **仓库本质**：CCF MindSpore AI 应用创新大赛仓库。每个 PR = 一支队伍的**完整参赛项目作品**（非协作改模块）；唯一 Issue = 大赛公告。 +- **数据**：19 个 PR（14 open / 5 closed），top 作者 Cvmax7(4)、limingjing2024(2)、zijunliang(2)…；PR 标题如"孕心导航——基于MindSpore的智慧孕育AIGC守护者""基于ViLT多模态模型的网络暴力检测"，分支是队名（如 `孕心导航_plugins`）。 +- **为何不适配**：PR 标题语义全是"参赛应用主题"，硬映射到 数据/算法/工程/评测 角色是牵强的；无真正待分配的 Issue（唯一 Issue 是赛公告），故"人-任务匹配"核心③为空；每人是自己参赛项目全栈，"贡献者角色画像"会全标成全栈，扭曲 Skill 设计。 +- **结论**：演示本 Skill 需要的是"同仓库协作分工"型仓库，而非大赛作品提交型仓库。 -- 2.34.1