Ai Promotion Query — AI 推广查询

AI Promotion Query（腾讯音乐人宣推数据查询） ✨ 自包含登录态：本 Skill 需要用户登录态，已由 tme-openapi Skill 自动处理——无需任何手动架设。首次使用会弹出浏览器扫码登录，Token 有效期约 30 天。 ⚠️ 前置依赖（算子调用能力）：本 Skill 不自带 API 调用脚本，所有 TME OpenAPI 算子的发现与调用都委托给 tme-openapi Skill。你需要了解 tme-openapi 提供的 4 个通用工具（list_apis / search_apis / get_api_detail / invoke_api）及其标准调用流程。 ⚠️ 对外表达依赖：本 Skill 的输出是上层 Agent（ai-promotion/readme.md）的内部数据依据，不直接面向用户。最终对用户的自然语言回复，必须遵守 ai-promotion/readme.md 的对外规则，并统一通过 宣推结构化输出 skill 输出。 本 Skill 分为两个部分： Part 1 — 宣推数据查询业务流程：基于 tme-openapi 的通用调用能力，完成"宣推概览查询"和"获取歌曲宣推指标查询"两个子场景的业务编排。 Part 2 — 宣推指标分析：按需读取 knowledge.md，把查询结果归类到推广前 / 推广中 / 推广后规则，再生成定性判断、动作建议和衍生问题。 基础能力依赖：tme-openapi 本 Skill 的所有后端调用都通过 tme-openapi Skill 完成。该 Skill 提供 4 个通用工具来发现和调用腾讯音乐开放平台的「算子」API： Tool（来自 tme-openapi） 作用 在本业务中的典型用途 search_apis 按关键词模糊搜索算子 用关键词定位"宣推概览"、"获取歌曲宣推指标"算子 list_apis 列出所有可用算子摘要 搜索失败时兜底探查 get_api_detail 获取指定算子的完整详情 调用前查 inputSchema / detailedDescription invoke_api 调用指定算子 真正发起业务调用（同步返回结果） 标准调用流程（由 tme-openapi 定义）： search_apis(keyword) → [可选] get_api_detail(operatorCode) → invoke_api(operatorCode, arguments) 当前算子平台仅支持同步调用，invoke_api 一次请求即为终态，无需轮询异步结果。 脚本路径约定 tme-openapi 的脚本位于同级目录 ../tme-openapi/scripts/。在 qclaw / Code Buddy 中，脚本安装路径为 ~/./skills/tme-openapi/scripts/。本 Skill 正文中的「搜索算子」「调用算子」等步骤，都是对这些脚本的逻辑调用，不再赘述具体命令行形式——按 tme-openapi/SKILL.md 的"标准调用流程"执行即可。 核心编排原则（从 tme-openapi 继承） 不硬编码任何 operatorCode 或参数结构，一律通过 search_apis / get_api_detail 动态发现 登录态下不要传 accountId / userId 等身份参数，后端会从 Token 中自动识别 遇到 INVALID_ARGUMENT，回退到 get_api_detail 重新确认 schema 和 example 后再试 遇到 UNAUTHORIZED，引导用户删除 ~/.tme-login/token.json 后重跑，tme-openapi 会自动触发重新登录 错误码含义与重试策略的完整表格，见 tme-openapi/SKILL.md Part 1：宣推数据查询业务流程 注意：本 Skill 不硬编码任何算子 code 或参数结构。关于算子的参数细节、取值约束、返回结构等信息，请通过 tme-openapi 的 get_api_detail 获取详情后，阅读 detailedDescription 字段，并参考本目录下 detailed_description_overview.md / detailed_description_metric.md 两份本地说明作为辅助。 核心背景 宣推数据查询是音乐人宣推助手的基础能力： 宣推概览 — 拉取当前登录用户名下所有宣推歌曲的整体情况（账号级摘要 + 单曲摘要列表），用于回答"我这些歌宣推情况如何"这类账号级问题，也用于后续从中筛选出目标 songId 即 yyrSongId字段。 获取歌曲宣推指标 — 按 songId 获取单首歌的完整宣推指标，用于回答单首歌的宣推表现、诊断、加投/止损判断等问题。 两个接口均为同步接口，invoke_api 直接返回结果，无需关心异步轮询。 对外表达总原则（⚠️ 贯穿两个场景） ❌ 禁止向用户展示任何具体金额、投放金额、购买播放量、投放天数等数字 ✅ 内部拿到的指标只能作为判断依据，对外必须转写为"表现较好 / 偏弱 / 一般 / 有提升空间 / 值得继续观察"等定性评价 ✅ 不输出"我来帮你分析"、"让我查询一下"、"数据查询成功"等过程态话术 ✅ 无法唯一定位歌曲时，不得追问 songId / 歌手名 / 发布时间 / 版本信息，固定使用 ai-promotion/readme.md 中的兜底文案 场景一：宣推概览查询 当用户说"我这些歌宣推情况怎么样"、"看一下宣推数据"、"我有哪些歌在投放"、"宣推表现如何"等账号级 / 未指定具体歌曲的问题时： 核心约束 当前登录用户由登录态 Token 自动透传，不需要调用方传 userId 若接口支持分页，pageNo 默认 1、pageSize 默认 10（以 inputSchema 为准） 不要向用户暴露技术参数名称（如 pageNo / pageSize），对用户使用自然语言描述 更多参数/返回细节参见 detailed_description_overview.md Step 1：搜索宣推概览算子 通过 tme-openapi 的 search_apis： search_apis({ keyword: "宣推概览" }) 若无命中，换用备选关键词重试：宣推歌曲、宣推列表、宣推数据。 从返回中定位名称/描述与"宣推概览 / 宣推歌曲概览"匹配的条目，记住其 name（operatorCode）。 Step 2：获取算子详情（强烈建议） 首次调用前，务必先获取详情： get_api_detail({ name: "<上一步找到的 operatorCode>" }) 仔细阅读 detailedDescription、inputSchema、exampleOutput。如与本地 detailed_description_overview.md 冲突，以后端返回为准。 Step 3：调用宣推概览算子 根据 inputSchema 构造参数并通过 tme-openapi 的 invoke_api 调用： invoke_api({ name: "", arguments: { / 以 get_api_detail 返回的 inputSchema 为准，通常可传空对象 {} 或 { pageNo, pageSize } / } }) Step 4：处理返回并组装内部上下文 从返回中提取： 账号级信息（是否曾有宣推歌曲、当前在投数量等） 单曲摘要列表（songId、songName、promotionStatus、定性标签等） 该结果 不直接对外，而是作为上层 ai-promotion/readme.md 判断问题类型、组装回答所需的内部数据。 场景一对外输出要点（遵循 ai-promotion/readme.md 的 B 类或 A 类规则） 用户问的是整体情况 / 账号级 / 不指向具体一首 → 走 B 类规则：一个或多个 message + 最后一个 moreQuestions（4 个衍生问题），不输出 songCard 用户问的是某一首但歌名模糊 → 先在概览里做匹配，若能唯一定位到一首，带着 songId 进入场景二；若无法唯一定位，按 ai-promotion/readme.md 的"单首歌无法定位规则"输出固定兜底文案 禁止在对外回复中直接展示歌曲列表的原始数值字段（如具体播放量），只做定性总结 场景一边界情况 情况 内部处理 对外表达 返回列表为空 判断是否从未宣推过 用定性语言告知"当前没有在宣推的歌曲"，不要暴露技术细节 UNAUTHORIZED 登录态失效 引导用户删除 ~/.tme-login/token.json 后重跑（tme-openapi 会自动重新登录） 请求超时 /UPSTREAM_ERROR 重试 1-2 次 仍失败则使用ai-promotion/readme.md 中的"系统繁忙"兜底文案 用户继续问某一首 从概览结果中匹配songName / 关键词 匹配成功则进入场景二；匹配失败按"