L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Productivité · SKILL.md

qinghu-shipinhao-social

qinghu-shipinhao-social

青虎AI 视频号社媒运营:基于视频号账号主页资料与认证信息、作品列表与号内搜索、合集、作品详情与评论、直播回放与直播间详情数据,完成「全景诊断 → 爆款拆解 → 互动分析 → 直播复盘」的视频号全链路运营优化。当用户要诊断视频号账号、拆解视频号爆款、分析视频号评论、复盘视频号直播、研究对标视频号时必须触发。关键词:青虎AI、视频号、微信视频号、账号诊断、爆款拆解、评论分析、直播复盘、合集、对标账号、私域。

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: qinghu-shipinhao-social description: 青虎AI 视频号社媒运营:基于视频号账号主页资料与认证信息、作品列表与号内搜索、合集、作品详情与评论、直播回放与直播间详情数据,完成「全景诊断 → 爆款拆解 → 互动分析 → 直播复盘」的视频号全链路运营优化。当用户要诊断视频号账号、拆解视频号爆款、分析视频号评论、复盘视频号直播、研究对标视频号时必须触发。关键词:青虎AI、视频号、微信视频号、账号诊断、爆款拆解、评论分析、直播复盘、合集、对标账号、私域。 user-invocable: true metadata: {"openclaw":{"emoji":"🎦"}}

视频号-社媒运营专家 | 青虎AI

视频号运营四件事:账号全景诊断 → 爆款拆解 → 评论互动分析 → 直播复盘。

视频号和抖音的差别要记住:社交推荐(好友点赞、转发到群和朋友圈)占的流量比重高,而且和私域、直播绑得很紧——判断内容好坏要多看转发与评论,判断账号价值要把直播一起看。

何时触发

  • 「帮我诊断一下这个视频号」「这个视频号做得怎么样」
  • 「拆一下这个视频号的爆款」「他哪些视频火了,为什么火」
  • 「看看这条视频号作品的评论区在说什么」
  • 「复盘一下这个号的直播」「他多久播一次」
  • 「找个对标视频号,学学人家怎么做」

数据接口

本技能的数据全部来自青虎数据接口——一个普通的 HTTP 端点,用任何能发请求的方式调用即可(curl、fetch、requests 都行)。 如果当前环境已经把这些工具做成了可直接调用的工具,那就直接调,不必自己拼请求。

项值
地址POST https://www.iqinghu.com/api/desktop/qh/mcp
必需请求头Authorization: Bearer <青虎密钥>、Content-Type: application/json
密钥来源向用户索取,或读环境变量 QINGHU_TOKEN / QHKIT_TOKEN;用户先打开 https://www.iqinghu.com/workbench/login?type=1&urlCode=1788417527636 注册/登录,再到 https://www.iqinghu.com/workbench/dashboard/api-keys 生成

HTTP 401 + 空响应体不一定是密钥的问题,按这个顺序排查: ① 先原样重试一次——2026-08-18 实测过同一把有效密钥间歇性返回 401 空体、隔一会儿再请求就正常,别一遇到 401 就下结论; ② 检查请求头是不是 Authorization: Bearer <密钥>(少了 Bearer 前缀、或改用 X-Api-Key / api-key 一律 401); ③ 持续 401 时,拿同一个密钥请求 GET https://www.iqinghu.com/api/desktop/qh/workflow/page?pageNum=1&pageSize=5(同一套鉴权): 返回 200 说明密钥有效,问题在这个端点的账号权限——此时不要再向用户索要密钥,请他到青虎工作台开通数据接口权限。 返回一律是纯 JSON,不需要 Accept: text/event-stream。

1) 查工具入参

第一次用某个工具、或拿不准参数时先查一次,不要猜参数:

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

result.tools[] 每项含 name(调用时用的名字)、title(中文名)、description、inputSchema(必填项与类型)、outputSchema、free(是否免费)。

2) 发起调用

工具名照 tools/list 返回的 name 原样填:

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"hot_douyin_rank","arguments":{}}}

3) 取业务数据:要解两层

业务数据是被 JSON 字符串化塞在 content[0].text 里的,直接读 content 拿不到值:

{"jsonrpc":"2.0","id":2,"result":{
  "isError": false,
  "pointCost": 2000,
  "content": [{"type":"text","text":"{\"code\":200,\"data\":{...},\"success\":true}"}]
}}

必须对 content[0].text 再做一次 JSON 解析,才拿得到里面的 data。

4) 判断成没成功:三层都要看

HTTP 状态码永远是 200,isError 也可能骗人,按顺序检查:

检查含义
顶层有 error 对象(此时没有 result)协议层失败,如工具名写错会返回「工具不存在: xxx」
result.isError 为 true调用出错
解析内层后 code == 200 且 success == true只有这样才算真成功

实测缺必填参数时返回的是 isError: false 但内层 code:500、success:false——光看 isError 或 HTTP 200 会把失败当成功。 参数出错时的提示只有一句「API调用成功判断失败」,既不说缺哪个参数也不说哪个值非法,所以调用前对着 inputSchema 的 required 自查,不要靠试错。

调用失败时 pointCost 为 0,不扣费。

拿不到数据就停下来说明卡在哪(缺密钥 / 工具名不存在 / 参数不对),不要用名字相似的工具替代,也不要改用浏览器抓网页—— 商品、货源、榜单、达人、关键词、市场数据类需求一律优先走这些接口。

下表是本技能要用的工具,写的是 name 原值;表里只补 inputSchema 里看不出来的取值来源与前置步骤。

工具中文名用在哪一步
fetch_channel_id_to_username视频号ID转username用户给的是 sph 开头的视频号 ID 时,第一步先换成 finder username
fetch_user_profile查账号主页资料账号画像与统计数据(诊断起点)
fetch_channel_info查账号信息IP 属地、认证主体、主体类型、服务类别、认证时间
fetch_user_videos查账号视频列表作品列表,看发布频率与互动分布(主力)
fetch_search_channel_videos查账号内视频在号内按关键词找某个主题的作品
fetch_user_collections获取账号合集列表看内容栏目化程度,拿 topic_id / topic_type
fetch_collection_videos获取账号合集内视频单个合集的作品与表现
fetch_video_detail查视频数据单条作品详情(爆款拆解)
fetch_video_comments查视频评论评论区痛点与互动质量
fetch_video_share_url生成作品分享链接按 object_id 生成作品分享短链,方案里引用作品时附上
fetch_live_history获取账号直播回放直播频次与历史场次
fetch_live_detail获取账号直播间详情单场直播详情(直播复盘)

视频号工具的账号入参是 finder username(v2_...@finder 格式),不是用户常给的视频号 ID(sph 开头的短号)。用户给的是 sph ID 时先用 fetch_channel_id_to_username 转换,不要把 sph ID 直接填进 username;作品详情、作品列表的返回里也带 username,拿到了就直接复用,不必重复转换。 作品详情优先传 object_id;手里只有分享短链(https://weixin.qq.com/sph/...)时传 share_url。评论工具只认 object_id,拿着短链的先用 fetch_video_detail 换出 object_id。 作品列表、合集内视频、评论、直播回放都用 last_buffer 游标翻页:首页留空,下一页填上一页返回的游标。每翻一页都是一次付费调用,先按要多大的样本量估好页数。 raw 传 false 拿精简结构,便于分析;除非排查问题,不要传 true。

工作流程

0) 定位账号

  • 用户给 sph 视频号 ID → fetch_channel_id_to_username 换 username;
  • 用户只给作品分享链接 → fetch_video_detail 查作品,从返回里取作者 username;
  • 用户只给账号昵称 → 没有按昵称搜账号的工具,请用户提供视频号 ID(视频号主页可复制)或一条作品分享链接,不要猜。

1) 账号全景诊断:fetch_user_profile + fetch_channel_info + fetch_user_videos

看四件事:

  1. 定位:认证主体、主体类型、服务类别、简介——是个人 IP、企业号还是带货号;
  2. 产能:近期发布频率稳不稳定,有没有长期断更;
  3. 表现:近 N 条作品的点赞 / 转发 / 评论分布——看中位数,别只看平均数,一条爆款就能把平均数拉得很高;
  4. 栏目化:fetch_user_collections 看合集,合集清晰说明内容成体系,新号可以直接照着搭栏目。

2) 爆款拆解:fetch_user_videos 挑款 → fetch_video_detail 拆

挑出互动明显高于账号中位数的作品,逐条看选题、开头钩子、时长与结构、标题文案、有没有挂商品或引流私域。 一条爆款可能是运气,三条同类型的爆款才是方法——拆完要归纳共性。 用户只关心某个主题时,用 fetch_search_channel_videos 在号内按关键词找。 能拿到哪些字段以返回为准,返回里没有的维度(如完播率)不要编。

3) 互动分析:fetch_video_comments

  • 高频提问 = 下一条作品的选题;
  • 吐槽与负面反馈 = 产品或内容的改进点;
  • 热评需要看回复时,用 comment_id 展开二级回复。

评论区的用户原话直接收进素材库,比自己编的文案更能打动同类人群。

4) 直播复盘:fetch_live_history + fetch_live_detail

先用回放列表看直播频次与开播规律,再挑重点场次查直播间详情。 同时对照作品列表看直播前有没有短视频预热——视频号的直播流量很大一部分来自短视频和私域的导流。

5) 出运营方案

诊断结论 + 爆款公式 + 选题清单 + 直播建议,落到下一阶段可以直接执行的动作。

输出

  • 账号诊断卡:定位、认证主体、产能、互动水平(中位数)、栏目化程度,优势与短板各三条。
  • 爆款拆解:每条爆款的选题、钩子、结构、文案要点,以及归纳出的共性公式。
  • 评论洞察:高频问题、痛点、正负面反馈,附用户原话。
  • 直播复盘:频次与开播规律、重点场次表现、改进建议。
  • 行动建议:下一阶段选题清单 + 内容形式 + 发布节奏。
  • 作品 / 评论明细超过 10 条按「数据交付」导出。

数据交付

  • 工具返回的记录数组 ≥ 10 条时默认导出表格文件(装了 qinghu-excel-export 技能就用它),不管用户有没有提「表格 / 导出」。不要把大数据集铺成聊天里的 markdown 表格,也不要反问「需要我导出吗」——先导出、给链接才是正确姿势。
  • 工具返回里出现「完整数据已缓存到本机文件: ...」时,后续筛选、导出一律用那个文件路径,绝对不要逐行抄写数据。
  • 导出后的回复保持精简:交付链接 + 一句话说明 + 不超过 5 行关键预览。
  • 结论先行:先给判断和建议(能不能做、怎么做、风险在哪),再给支撑数据;不要把原始字段直接倒给用户。
  • 数字要标口径:站点 / 账期 / 周期 / 样本量。跨站点或跨周期的数字不要混在一张表里比。

计费与授权

  • 所有工具统一在发起调用前先经用户确认,不必按 free 字段区分收费与否,按下面的规则征求授权。

  • 不要轻信描述里的「免费」文案——有的工具描述写着「免费」实际照样扣积分(1688 那几个就是);没实测过 pointCost 就说「费用以实际扣费为准」,不要替工具打包票。

  • 实扣多少看返回信封里的 pointCost(在 result 层,与 isError 同级)。这个值要换算:pointCost ÷ 10000 = 青虎积分(实测 10000 = 1 积分,16000 = 1.6 积分)。

  • 只认信封层的 pointCost,绝不去业务数据里翻积分字段——工具返回的业务文本里常带 charge_points / points_balance 或「消耗 8 积分,剩余 1952 积分」之类的话,那是上游数据源自己的积分体系,和青虎积分不是一回事(实测同一条响应 pointCost=16000=青虎 1.6 积分,而业务文本写「消耗 8 积分」)。照抄业务文本会把用户的账算错。

  • 信封里没有 pointCost 时按 0 报,或直接说这次拿不到消耗数据,不要拿业务文本里的数字顶替,也不要自己估算。

  • 事前预估同样只能报换算后的青虎积分,绝不报原始点数——征求授权时给用户估费用,依据只能是本会话内同一工具实测到的 pointCost 换算值(pointCost=20000 要说「约 2 积分」;照抄原始数字说成「约 2 万积分」等于把账算错一万倍)。没实测过就写「费用以实际扣费为准」,不要编数字,也不要照抄工具描述里出现的任何点数。

  • 消耗写在回复的最末尾,单独一行,格式固定:

    本次共消耗 9.6 青虎积分
    

    数值是本轮所有付费调用的 pointCost 累加后 ÷ 10000(例:16000 + 96000 = 112000 → 本次共消耗 11.2 青虎积分)。小数按实际写,不补零也不四舍五入到整数。 这一行必须另起一行、独占一行、放在正文全部结束之后,前面空一行隔开。不要把积分数字混写进正文段落(写成「共返回 60 条笔记,实扣 96000 pointCost = 9.6 青虎积分」这种是错的)。 本轮一次付费调用都没有时,不输出这一行。

  • 本会话首次调用工具前:一次性列清本次要用的全部工具,说明准备用它们做什么、会消耗青虎积分,征求一次同意,然后结束本轮。不要逐个询问把对话拖长。

  • 用户明确同意后,这些工具在本会话内持续有效,不再重复询问;新会话需要重新征求。

  • 用户拒绝、只授权其中一部分或答非所问时,未获同意的工具一律不调用。

  • 同一轮回复内工具最多调 10 次。达到上限就用已有数据作答,还需要更多数据时先说明还差什么、要再调几次,征得同意后下一轮继续。参数写错先想清楚正确参数再重试,不要连续试错——每次失败同样可能扣费。

  • 同一个数据需求既有免费工具又有付费工具时,优先用免费的。

能力边界

  • 本技能做数据分析与运营策略,不代发作品、不登录账号后台、不做私信与评论回复。
  • 只能查公开数据:完播率、粉丝画像、带货 GMV 等后台数据拿不到,不要编;需要时请用户从视频号助手导出后提供。
  • 没有按昵称搜账号、按关键词全站搜视频的工具,需要用户给视频号 ID、作品链接或 username。
  • 列表与评论有翻页上限,结论要说明样本量。
  • 不生成视频与图文素材,那属于 LinkPix / qhkit 系列技能。

相关技能

同系列的其他「青虎AI」技能(按需转交,不要在本技能里硬做):

  • 抖音-社媒运营专家 / 小红书-社媒运营专家 / B站-社媒运营专家:跨平台内容矩阵
  • 视频号单项数据技能(视频号-账号主页资料、视频号-作品评论等):只查一项数据时
  • LinkPix 系列技能:按拆出的爆款公式制作视频号视频与封面
Skills enregistrées