视
视频号达人筛选
作者：鹿Sir内容创作v1
把要推广的产品和一批候选视频号达人交给 AI 逐个深扒受众画像、内容调性与转化潜力，按六维评分排出推荐名次，输出含推荐排名、六维匹配评分、首选达人合作方案的达人匹配分析报告。当用户想对比筛选带货达人、选择 KOL 合作、达人投放决策时触发；不负责寻找新达人。触发词：达人筛选、达人匹配、带货达人、KOL筛选、达人对比。
下载量
380
点赞
93
价格
免费
技能文档
---
name: lingyi-creator-filter
title: 视频号达人筛选
category: 内容创作
description: 把要推广的产品和一批候选视频号达人交给 AI 逐个深扒受众画像、内容调性与转化潜力，按六维评分排出推荐名次，输出含推荐排名、六维匹配评分、首选达人合作方案的达人匹配分析报告。当用户想对比筛选带货达人、选择 KOL 合作、达人投放决策时触发；不负责寻找新达人。触发词：达人筛选、达人匹配、带货达人、KOL筛选、达人对比。
---
# 视频号达人筛选
使用远端服务做视频号达人匹配。**核心场景**：你已经有产品、也手动物色了一批想合作的视频号达人，但拿不准哪个更适合带你的货——本技能让 AI 逐个分析这批候选达人的受众、内容、转化潜力与你的产品是否对口，按六维评分排出推荐排名，告诉你首选跟谁合作、为什么，帮你从一批人里**筛出最该带货的那几位**。输入为**你要推广的产品** + **一批候选达人账号名称**，产出一份达人匹配分析报告（推荐排名 / 六维匹配评分 / 首选达人合作方案 / 受众画像与代表视频 / 内容特征 / 后续动作）。核心提示词在后端，本 skill 只做用户层引导与控制。脚本 [scripts/creator_match.py](scripts/creator_match.py) 负责全部 HTTP 调用（读配置 + 发起任务 + 轮询 + 交付报告），接口说明见 [references/api.md](references/api.md)，交互约定见 [references/usage-notes.md](references/usage-notes.md)。
> ⚠️ 本技能**不会帮你找达人**——候选达人是你已经选定、想拿来对比的那一批；它做的是「对这批候选人逐个分析、筛出谁更适合带货」。如果还没物色候选人，请先去视频号挑好人选，再来用本技能对比。
## 技能工作流
按以下顺序执行，每一步都对应后续章节的细节：
### 步骤1：取 API Key
**取 API Key**：读技能目录下 `config.json` 的 `LY_API_KEY`（回退环境变量）。缺失按「鉴权」流程引导用户获取并写入，再继续。
### 步骤2：初始引导 + 信息收集
判断用户是否给齐了「候选达人账号列表」+「产品投放需求」。缺项按「引导话术」对应场景引导补齐。详见「信息收集」。
### 步骤3：达人账号名称准确性确认
达人匹配是按**账号名称**定位的，名称错了就会匹配到别的账号或匹配失败。先复述确认账号名无误，建议从视频号复制准确昵称。详见「账号名称准确性」。
### 步骤4：读配置（可选枚举）
用户给的信息里如果要用行业 / 投放类型 / 价格档位 / 消费决策类型，先跑 `--config` 拉取可选枚举，把 `label` 展示给用户选、用 `options[].value` 入参（不要用 label）。详见「读配置」。枚举可缓存，不必每次都拉。
### 步骤5：预估扣点 + 二次确认（必做关卡）
首次执行（非 `--task-id` 恢复）时，先用 `--estimate-only` 创建任务拿到 **task_id 和预计扣点**（服务端返回就用真实值，否则按 198×达人数 估算），向用户发确认话术——**明确告知点数消耗非常大且会随账号数量、达人视频数量浮动**，「确认要开始吗」让用户明确确认；未确认不轮询、不继续。**预估 198×达人数 只是参考，最终扣点按服务端实际计费为准（可高可低）。**恢复超时任务不重复扣点，跳过本步。详见「扣点与确认」。
### 步骤6：发起匹配 + 连续轮询循环（不许停）
用户确认后，`--estimate-only` 已完成创建，**立即用 `--task-id` 开始轮询，并且进入一个不停顿的循环**，直到拿到终态结果。**绝对不允许给一次进度就停下来等用户——那样用户会以为断了。**正确做法：每跑一次 `--task-id`，无论脚本返回的是"还在跑"还是"完成了"，都要：先给用户一句话进度/结果 → 然后立刻决定下一步（非终态 → 立即再跑 `--task-id`；终态 → 交付报告）。**一个回合里可以连续跑多次 `--task-id`，直到出终态或你判断需要让用户说话为止。** 详见「发起匹配与轮询」。
### 步骤7：交付报告
终态完成后，按「输出交付」把分隔符之间的 Markdown **真正渲染**给用户，告知本次实际扣点与报告查看方式。
> 若是恢复已超时的任务，跳过 1 之后的鉴权检查与 5 的确认，直接用 `--task-id <id>` 从第 6 步恢复轮询（点数已在发起时扣除，不重复扣点）。
任一步异常按「退出码处理」表对号入座，**不要自行判定失败**。
## 鉴权
Token 取「技能目录」（SKILL.md 所在目录）下 `config.json` 里的 `LY_API_KEY` 字段，回退到环境变量 `LY_API_KEY`。脚本请求头使用 `Authorization: Bearer <api_key>`。`config.json` 形如：
```json
{ "LY_API_KEY": "你的密钥" }
```
运行脚本前，先按下面的流程确认 key 就绪。**任何时候都不要编造或猜测 key。**
1. **检查是否已有 key。** 读技能目录下的 `config.json`，看 `LY_API_KEY` 是否为非空字符串；若没有，再看环境变量 `LY_API_KEY`。两者任一有值即视为就绪，直接进入后续流程。
2. **缺失则引导用户获取。** 若都没有，停下来提示用户前往 <https://claw.lingyishuke.com/webapps/01claw-auth/index.html> 获取 API Key，并让用户把拿到的 Key 直接发给你。在拿到 key 之前不要运行脚本。
3. **记录用户发来的 key。** 收到 key 后，把它写入技能目录下的 `config.json` 的 `LY_API_KEY` 字段（保留文件其它内容），然后再运行脚本。该文件已被 `.gitignore` 忽略，不会入库。
4. **鉴权失败（退出码 3）时。** 多半是 key 失效或过期。提示用户重新前往上述地址获取新 key，按第 3 步覆盖写入 `config.json` 后重试；不要反复用同一个失效 key 重跑。
> 若运行报 SSL 证书错误（`CERTIFICATE_VERIFY_FAILED` 等，常见于 macOS 缺证书或企业代理环境），可设环境变量 `LY_SKIP_SSL_VERIFY=1` 后重试。注意：跳过证书校验有中间人风险，仅在受控环境临时使用。
## 信息收集
匹配前与用户确认以下信息（缺项给默认建议，必填缺失则一次性问清）：
| 字段 | 必填 | 说明 |
| --- | --- | --- |
| 候选达人账号名称列表 | 是 | 视频号达人账号（昵称），**1～10 个**（上限 10），建议 2–5 个；从视频号复制准确昵称 |
| 产品名称 | 是 | 产品名称，越具体越好 |
| 核心卖点 | 是 | 产品核心卖点列表，至少一个 |
| 消费决策类型 | 建议（可透传） | 冲动消费型 / 比较决策型 / 信任驱动型等，可选值见 `--config` 的 `decision_type`；会透传给后端 |
| 价格档位 | 建议 | 低客单 / 中客单 / 高客单，可选值见 `--config` 的 `price_band` |
| 产品价格 | 建议 | 产品价格（数字） |
| 行业 | 可选 | 产品所属行业，可多选，可选值见 `--config` 的 `industries` |
| 投放类型 | 可选 | 内容种草 / 直播带货等，可多选，可选值见 `--config` 的 `campaign_types` |
| 扩展信息 | 可选 | 文档抽取内容或其它补充文本，会透传给后端参考 |
| 平台 | 可选 | 默认 `channels`（微信视频号），一般不用改 |
> 账号身份由 API Key 自动识别，无需在请求中传递。产品信息填得越完整，匹配结果越有效。
### 账号名称准确性
本技能是按**账号名称**去逐个定位并分析对应达人的，名称错了就会分析到别的达人或分析失败、白白扣点，因此运行前必须确认账号名称准确无误：
- 拿到用户给的账号名称列表后，先简短复述一遍确认：「我将对比分析【账号 A、账号 B、账号 C】这几位达人，看谁更适合带你的产品【产品名】，对吗？」；用户给的名称含错别字、歧义或为简称时，主动核对完整、准确的账号昵称。如果超过 10 个，提醒用户「最多只能对比 10 位达人，请缩减」。
- 建议用户从微信视频号里复制各位达人的准确昵称后再发给你，避免手打出错。
- 确认无误后再进入「读配置」与「扣点与确认」。
## 引导话术
当用户触发本技能但未给齐信息、或输入有误时，按以下场景引导。语气亲和自然，不罗列技术参数。
### 未提供输入（初始引导）
> 技能已就绪 ✅ 适合这样的场景：你**已经有产品、也物色了一批想合作的视频号达人**，但拿不准哪个更适合带你的货。把它们发给我，AI 会逐个分析这批达人的受众、内容、转化潜力跟你的产品对不对口，按六维评分排出推荐排名，告诉你首选跟谁合作、为什么——帮你从一批人里**筛出最该带货的那几位**。🎯
>
> 随时可以开始，把下面这些发给我：
> 1. **候选达人账号名称**（1～10 个，建议 2–5 个）——你已经物色好、想拿来对比的那一批，从微信视频号复制准确昵称；最多不能超过 10 个；
> 2. **你要推广的产品**：**产品名称**和**核心卖点**必填，另外价格、价格档位（低/中/高客单）、消费决策类型（冲动/比较/信任型）填了更准；
> 3. （可选）产品行业、投放类型、扩展信息（如有补充材料）、平台（默认微信视频号）。
>
> 拿到信息后，我会先跟你确认账号名准确、并告知本次扣点成本，**你确认后**再提交分析，通常几分钟出报告 📊
>
> 💡 提前说明一下成本：本服务需要逐个读取达人账号的视频数据来分析，**平均每读取一个达人约耗费 198 点**——你要对比的达人越多，点数消耗越巨大。具体以实际任务复杂度为准。所以建议先挑最值得对比的那几位（比如 2–5 个），别贪多，最多不能超过 10 个。
>
> ⚠️ 本技能只对你**已经选定**的那批达人做对比筛选，不会帮你去找新达人——如果还没物色候选人，先去视频号挑好人选再来。
### 候选达人信息不全
> 要做达人筛选，得知道你想对比哪几位达人 😊 把你**已经物色好、想拿来对比**的达人**账号名称**（1～10 个，建议 2–5 个）发给我吧，从微信视频号复制准确昵称最稳。
### 产品信息不全
> 要判断哪位达人更适合带你的货，得先说清楚**你要推广的产品**：**产品名称**和**核心卖点**是必须的，另外价格、价格档位（低/中/高客单）、消费决策类型（冲动/比较/信任型）填了更准 🙏
### 达人账号名称疑似不准 / 需确认
> 达人筛选是按账号名称来逐个定位的，名称务必准确无误——错一个字就可能分析到别的达人、或分析失败白扣点 😅
>
> 确认一下，是【<用户给的名称列表>】这几位达人吗？建议你从微信视频号里把各位达人的准确昵称复制过来再发我，避免手打出错。
### 缺少 API Key
> 做达人筛选要调用远端的付费服务，首次使用得配置一下 API Key 🔑
>
> 👉 打开这个链接登录/注册服务方账号并获取 Key：https://claw.lingyishuke.com/webapps/01claw-auth/index.html
>
> 拿到 Key 后直接粘贴发给我（一串字符即可），我会帮你存好，之后筛选达人就不用再管它了。这个服务按次计费，余额不足时我会提醒你充值。
## 读配置
行行业 / 投放类型 / 价格档位 / 消费决策类型的合法可选值以接口实时返回为准：
```bash
python3 scripts/creator_match.py --config
```
- stdout 以 `=== CREATOR_MATCH_CONFIG_START ===` / `=== CREATOR_MATCH_CONFIG_END ===` 包裹原始 JSON；
- stderr 会打一份易读清单（如「• 行业：教育培训（value=education）、3C 数码（value=3c_digital）」），可直接转述给用户挑选项。
**把 `label` 展示给用户选，创建任务时用对应的 `value` 入参（`--industry` / `--campaign-type` / `--price-band` / `--decision-type`），不要用 label。**枚举可缓存，同一会话不必每次都拉。详见 [references/api.md](references/api.md)。
## 扣点与确认
本技能每次「新发起」匹配任务都会扣点，且达人匹配要研究**多个候选达人账号 × 多个达人视频**，链路长、**单次消耗的点数非常大、且会随账号数量和达人视频数量浮动**。整条链路对用户的扣点感知由你（assistant）来贯穿，**务必在开始轮询/生成报告前让用户确认**：
- **拿到真实预估扣点**：信息收集完成、账号名确认无误、API Key 就绪后，先运行一次 **`--estimate-only`** 创建任务。脚本会打出三行标记（无网络/余额问题时）：
```text
CREATOR_MATCH_TASK_ID=<task_id>
CREATOR_MATCH_ESTIMATE_POINTS=<预计扣点>
CREATOR_MATCH_ESTIMATE_SOURCE=<服务端返回 | 默认估算（服务端未在创建响应里返回点数字段）>
```
`CREATOR_MATCH_ESTIMATE_POINTS` 就是本次预计扣点：服务端在创建响应里返回了点数字段就用真实值，没返回就按 **198 × 候选达人数** 估算（来源见 `CREATOR_MATCH_ESTIMATE_SOURCE`）。**这只是预估参考**——达人匹配需要逐个读取达人账号的视频数据，**平均每读取一个达人约耗费 198 点**：候选达人越多，点数消耗越巨大（例如 1 位约 198 点、3 位约 594 点、5 位约 990 点）。具体以实际任务复杂度、达人视频数量而定，最终扣点按服务端实际计费为准（可高可低），以服务方账户扣减为准。记下 task_id，等用户确认后用它轮询。注意：`--estimate-only` 已经在服务端创建了任务，**确认通过后用 `--task-id <task_id>` 继续轮询即可，不要重新 `--estimate-only` 或重新创建**——重复创建会产生新任务、重复扣点。
- **执行前确认（仅新任务，非 `--task-id` 恢复）**：拿到上面三行后，**继续轮询之前**向用户发出确认，**等用户明确同意后才能用 `--task-id` 轮询**。确认话术如下，把 {预计扣点} 换成 `CREATOR_MATCH_ESTIMATE_POINTS` 的值：
> ⚠️ 即将开始达人匹配任务，提醒你两件事：
>
> 1. **本次任务消耗的点数非常大**——达人匹配需要逐个读取达人账号的视频数据，**平均每读取一个达人约耗费 198 点**：候选达人越多，点数消耗越巨大。本次共 {达人个数} 位达人，预计约 {预计扣点} 点（198 × {达人个数}）。实际会随达人视频数量、任务复杂度而**浮动**，最终以服务端实际扣点为准（可高可低）。任务已创建、确认后即继续扣点，请确认你知晓这笔成本。
> 2. **达人账号名称务必准确无误**——分析是按账号名称定位的，错一个字就可能分析到别的达人、或分析失败白扣点。建议从微信视频号里把各达人准确昵称复制过来核对。
>
> 确认要开始筛选吗？回复「确认/继续」我就继续；如果还要改达人账号或暂不跑，告诉我即可。
等用户明确确认（如「确认」「继续」「开始吧」）后再用 `--task-id` 轮询；用户未确认、未回应、含糊或要求改主意时，**不要再轮询**。不要因为用户「可能想匹配」就默认继续。
- **执行成功后回告实际扣点**：见「输出交付」，把脚本透出的 `CREATOR_MATCH_POINTS_USED` 作为实际扣点告诉用户，并给出查看报告的方式。
- **执行失败后告知点数返还**：见「退出码处理」，任务已发起但未成功产出报告时（`failed` / `timeout` / 网络 5xx），告知用户「因网络原因本次任务执行失败，相应点数已返还」并询问是否重试；`timeout` 附 `task_id` 可用 `--task-id` 恢复轮询。
> 恢复已有任务（`--task-id`）时点数已在发起时扣除，本次仅继续轮询，不重复扣点、不需再次确认。
## 运行方式
在 skill 目录下运行。
**第一步：读可选枚举（按需，可缓存）：**
```bash
python3 scripts/creator_match.py --config
```
**第二步：创建任务 + 拿到预计扣点（不轮询，用于确认前报价）：**
```bash
python3 scripts/creator_match.py \
--account "达人A" --account "达人B" --account "达人C" \
--product-name "多功能学习机" --product-price 39 \
--price-band low --decision-type impulse \
--selling-point "一机多用" --selling-point "学英语" \
--industry education --campaign-type seeding \
--estimate-only
```
**第三步：用户确认后，用 task_id 轮询出报告：**
```bash
python3 scripts/creator_match.py --task-id "<task_id>" [--out ./达人匹配报告.md]
```
恢复超时的任务同上（跳过创建，直接轮询）。
可选参数：
- `--account <账号名称>`：候选达人账号名称，**可多次传入**，1～10 个。
- `--product-name`：**产品名称（必填）**。
- `--selling-point <卖点>`：**产品核心卖点（必填，至少一个）**，可多次传入。
- `--product-price` / `--price-band` / `--decision-type`：产品信息（`--price-band` / `--decision-type` 的合法值见 `--config`；`--decision-type` 为可透传字段）。
- `--extra-data <文本>`：扩展信息，文档抽取内容或其它补充文本（选填）。
- `--industry <行业>` / `--campaign-type <投放类型>`：可多次传入，合法值见 `--config`。用 value 不用 label。
- `--platform <平台>`：默认 `channels`（微信视频号）。
- `--config`：只拉取可选枚举后退出（与 `--estimate-only` / `--task-id` 互斥）。
- `--estimate-only`：只创建任务、拿 `task_id` 与预计扣点后即退出（不轮询）。打三行标记：`CREATOR_MATCH_TASK_ID` / `CREATOR_MATCH_ESTIMATE_POINTS` / `CREATOR_MATCH_ESTIMATE_SOURCE`。
- `--task-id ID`：已有的任务 ID（来自 `--estimate-only` 的 `CREATOR_MATCH_TASK_ID`，或超时恢复），直接进入轮询。
- `--out PATH`：报告输出路径，目录或文件均可（不传时三级兜底落盘）。
- `--max-wait`：等待上限秒，默认 1200（对齐文档「20 分钟总等待上限」建议）。
- `--interval`：轮询间隔秒，默认 8（文档建议 5–10s）。
## 发起匹配与轮询
脚本向 `POST /api/v1/common-gateway/analysis-skill/creator-match` 发起任务，body 含 `platform` / `industries` / `campaign_types` / `target_accounts[]` / `product{}`（详见 [references/api.md](references/api.md)）。成功后取得 `data.task_id`，再轮询：
```text
GET /api/v1/common-gateway/analysis-skill/creator-match/{task_id}
```
### ⚠️ 连续轮询循环——最关键的交互规则
助手最容易犯的错误就是：跑一次 `--task-id`，给了用户一句进度，然后就**停下来不再继续**——用户等半天没动静，以为断了。**这是本 skill 最严重的体验问题，必须杜绝。**
正确做法是**连续循环**：
```
用户确认 → 跑 --estimate-only（创建） → 拿到 task_id
↓
进入循环：
跑 --task-id <id>
↓
判断结果：
- 非终态（脚本退出码 0 但还在跑/排队中）→ 给用户一句话进度 → 立即再跑 --task-id
- 终态 completed → 交付报告（渲染 Markdown + 告知扣点 + 文件路径）
- 终态 failed/timeout → 按退出码处理
- 脚本退出码非 0（异常） → 按退出码处理
```
**核心铁律：非终态 = 立即再跑一轮，不许停。** 每次轮询之间给用户一句简短进度即可，不需要等用户说话。
### 进度转述
脚本进度写到 stderr，每次 `--task-id` 返回后：
1. 先**给用户一句简短的人话进度**（例如「还在跑，约 2 分钟了，服务端处理中…」「已等约 5 分钟，仍在分析中…」），让用户知道你在盯着；
2. 然后**立即决定下一步**——非终态就再跑 `--task-id`；终态就交付或处理错误。
典型 stderr 行形如：
```text
[执行中] · 已等待45s · 达人匹配任务执行中
[执行中] · 已等待120s · 服务端处理中，请稍候…
[完成] · 已等待210s
```
转述时用人话，不要原样贴 `[执行中] · 已等待Ns` 这种技术日志。状态枚举见 [references/api.md](references/api.md)。
> 注意：真实接口在 `pending`/`running` 阶段**通常不返回** `current_stage` / `progress_message` / 进度百分比字段，但会返回 `progress_message` 文案（如「达人匹配任务执行中」）。脚本会回退用「状态 + 已等待时长 + progress_message 文案」反馈，并在没细节时每 30s 保活一行「服务端处理中，请稍候…」——这是**正常的**，不代表卡住。只要 status 在推进或保持 running 即可。**判定任务是否成功只看 `data.status`**——HTTP 200 只表示「成功查询到状态」，任务本身失败时 HTTP 仍可能是 200。
远端匹配通常需要几分钟（达人匹配任务较复杂，可能 5–10 分钟甚至更久）。**轮询一开始就告诉用户**「已开始筛选、任务进行中、可能耗时较久，请耐心等待，我会持续盯着进度」，之后**持续循环轮询**，每轮给用户一句话进度，**全程不允许长时间沉默**。
若发起任务时余额不足，脚本以退出码 4 退出。引导用户前往 <https://claw.lingyishuke.com/webapps/01claw-auth/index.html> 充值；充值前不要继续轮询。
### 用户问进度时
轮询循环期间用户若问「好了吗 / 跑到哪了」：
1. 取最近一次 `--task-id` 返回的 stderr 进度行自然转述，例如「还在跑，约 2 分钟；服务端处理中；任务 ID xxx」。若距上次轮询已过一会儿，再跑一次 `--task-id <id>` 现查后转述。
2. 转述后**立即继续轮询循环**（再跑 `--task-id`），不要停下等用户——保持会话有输出。
3. **禁止**回复「查不了任务状态 / 没有 task_id」——创建后立刻有 task_id 与进度。
## 输出交付
成功时 stdout 形如：
```text
CREATOR_MATCH_POINTS_USED=<本次实际扣点，可能为空>
CREATOR_MATCH_REPORT_FILE=<报告文件绝对路径或空>
=== CREATOR_MATCH_REPORT_START ===
<完整 Markdown 报告>
=== CREATOR_MATCH_REPORT_END ===
```
交付时**按顺序**做三件事（这三步缺一不可，尤其是第 1 步——报告必须真正呈现为 Markdown，不能只甩个文件路径或把分隔符原文贴给用户）：
1. **渲染报告（最重要，务必做对）**：截取 `=== CREATOR_MATCH_REPORT_START ===` 与 `=== CREATOR_MATCH_REPORT_END ===` 两个分隔符**之间**的 Markdown 正文，把它**作为 Markdown 渲染呈现给用户**——即对话里要让用户看到真正的「标题、表格、列表、分隔线」排版，而不是带有分隔符标记或 `\n` 字面的原始文本。
- ⚠️ 不要把 `=== CREATOR_MATCH_REPORT_START ===` / `=== CREATOR_MATCH_REPORT_END ===` 这两行分隔符、或 `CREATOR_MATCH_*=` 这些协议行展示给用户。
- ⚠️ 不要只说「报告已生成」却不渲染正文。**正文必须出现在回复里**。若正文过长，至少完整渲染前 2–3 个二级标题段落并说明完整报告已落盘；但凡能放下，优先**完整渲染**。
- 报告正文由**后端渲染**（`data.markdown`，从 `# 达人匹配分析报告` 起步），skill 侧不做模板。直接渲染即可，不要二次加工、不要改写表格。
2. **告知实际扣点**：若 `CREATOR_MATCH_POINTS_USED` 非空，告诉用户「**本次任务实际扣除 {点数} 点**」（以最终完成任务时的实际点数为准）；为空时回退用第一步 `--estimate-only` 给的 `CREATOR_MATCH_ESTIMATE_POINTS` 值，说「**本次任务约扣 {预估} 点**（实际以服务端扣点为准，可在服务方账户查看）」。两步报的数字保持一致。
3. **告知报告查看方式**：报告已渲染在上方对话中；同时**必定已保存为 Markdown 文件**，路径见 `CREATOR_MATCH_REPORT_FILE`（绝对路径），直接打开该文件即可查看/归档。脚本对落盘做了三级兜底（`--out` 指定路径 → 当前工作目录 `creator-match-<task_id>.md` → `/tmp/creator-match-<task_id>.md`），只要任务 completed 且能取到 markdown，就一定生成 md 文件——`CREATOR_MATCH_REPORT_FILE` 非空即落盘成功。仅当该字段为空（极端不可写环境）才说明「文件未落盘，正文已在上面对话中，可让我重新指定 `--out` 保存」。
> 报告 markdown 优先取服务端 `data.markdown`；若服务端偶尔没返回 markdown，脚本会兜底把结构化结果渲染成 Markdown，确保用户总能拿到一份 md。这是针对「有时没渲染为 md」的脚本侧保险。
若文件写入失败但 stdout 有报告正文，仍按上面方式在对话中交付报告并说明扣点。
## 退出码处理
| 码 | 含义 | 处理 |
| --- | --- | --- |
| 0 | 成功 | 按「输出交付」处理（渲染报告 + 告知实际扣点 + 告知查看方式）。 |
| 2 | 输入错误 | 让用户补齐候选达人账号名称（1～10 个）、产品名称、核心卖点等必填信息；任务未发起，**不扣点**。 |
| 3 | 缺 key 或鉴权失败 | 按「鉴权」流程处理：引导用户前往 `https://claw.lingyishuke.com/webapps/01claw-auth/index.html` 获取 key，收到后写入 `config.json` 再重试。任务未发起，**不扣点**。 |
| 4 | 发起任务失败，含余额不足 | 展示服务端 message；余额不足时引导用户前往 `https://claw.lingyishuke.com/webapps/01claw-auth/index.html` 充值，有服务端充值链接则优先用它。任务未成功发起，**不扣点**。 |
| 5 | 任务失败 | 告知用户「因网络原因本次任务执行失败，相应点数已返还」；转述 stderr 中的失败原因，并询问是否重试一次。 |
| 6 | 发起或轮询阶段的网络 / 限流 / 任务失效 | 停止并告知用户「因网络原因本次任务执行失败，相应点数已返还」；说明网络、限流、服务端不可用或任务失效等实际原因；附 stderr 中具体信息，询问是否重试。 |
| 7 | 完成但无可渲染报告 | status 已 completed，但响应里既无 `markdown`、也无可渲染的结构化结果（脚本已内置 60s 宽限轮询，多数能补齐）。仍为空时：转述 stderr 中的 `status`/`error_message`（若有）；建议稍候用 `--task-id <id>` 重新轮询一次；多次仍空则联系服务端排查。任务已发起，按实际扣点处理。 |
| 124 | 超时（含 status=timeout 终态） | 说明任务可能仍在进行，附 task_id，用 `--task-id <id>` 重新轮询恢复。若用户放弃恢复，告知「因网络原因本次任务执行失败，相应点数已返还」并询问是否重试。 |
> 一句话：任务已发起但未成功产出报告（退出码 5、6，以及放弃恢复后的 124），统一告知用户「**因网络原因本次任务执行失败，相应点数已返还**」并询问是否重试；任务未发起到位的（2、3、4）不涉及扣点，正常引导修正即可。
未知状态不要自行判定失败；脚本会原样透出 status，继续按轮询结果处理。
## 通用原则
- 引用 reference 用相对于 SKILL.md 的路径。
- 报告完整 Markdown 由**后端渲染**（`data.markdown`），skill 侧不做模板。
- 最终 MD 由 `creator_match.py` 三级兜底落盘后覆写到 `--out`（或工作目录 / `/tmp`），agent 不要手动追加/改写输出文件。
- **交付报告时务必把分隔符之间的 Markdown 真正渲染给用户**，这是本 skill 的硬性交付要求（见「输出交付」第 1 步）。
- 只使用达人匹配的三个接口：`GET /creator-match/config` → `POST /creator-match` → `GET /creator-match/{task_id}`，见 [references/api.md](references/api.md)。
- **不要在 `pending`/`running` 状态下重复调用创建接口**——重复创建会产生新任务、重复扣点。
- 拆分轮询防会话中断：`--estimate-only` 创建 + 多次 `--task-id` 短轮询续接，循环到终态。**非终态不许停——给一句进度后立即再跑 `--task-id`，直到出终态。**详见 [references/usage-notes.md](references/usage-notes.md)。使用说明
# 视频号达人筛选 把要推广的产品和一批候选视频号达人交给 AI 逐个分析，按六维评分排出推荐名次，告诉你首选跟谁合作、为什么——不再凭感觉选人。 ## 使用 对 Agent 说： ```text 帮我校验这几位达人谁适合带我的产品： 达人：账号A、账号B、账号C 产品：XX精华液，核心卖点：抗初老、性价比高 ``` 技能会确认账号昵称与扣点成本，你确认后提交分析，几分钟出报告。 ## 工作原理 - 通过远端服务逐个读取候选达人的视频数据，分析受众画像、内容调性与转化潜力； - 与产品卖点做六维匹配评分，输出推荐排名、首选达人合作方案与后续动作建议； - 按任务扣点计费，执行前会预估成本并经你确认。
支持平台：Qoder · QoderWork · Claude · Codex 等 AI 编程助手