game-opportunity Checked

node game-opportunity/scripts/game-opportunity.mjs <discover|radar|collect|collect-checklist|dedupe|plan|demand|evaluate|decision-checklist|render|daily>

用户只说“运行小游戏监测”时执行 daily。自动任务分成 collect 和 demand + evaluate 两个时段：

平台增量与 24 小时雷达先形成稳定输入，需求阶段再按全球、国家、竞争顺序查数并生成日报。

`radar`

24 小时内的新名字先从发布源和玩家现场发现，再进入搜索量验证：

1. 供给端：游戏平台 sitemap、itch.io 最近 7 天、GameJolt Hot、Poki / CrazyGames 新游位、

Scratch / Cocrea、SteamDB New & Trending、GitHub 游戏仓库与 App Store / Google Play 新游戏；

2. 玩家端：Reddit 的 r/WebGames、r/playmygame、r/IndieGaming、玩法垂直社区；

3. 传播端：YouTube 当日上传、X 最新帖，以及目标语言的本地游戏论坛；

4. 搜索端：Google Trends 实时热搜、7 天曲线和 related rising，以及 Google Autocomplete / Related

Searches 里的 play <name> online、<name> unblocked、<name> html5 等长尾萌芽；

5. 验证端：Similarweb 最近 28 天关键词与流量去向、Semrush 分国家搜索量与 KD。

使用 Agent Reach 当前可用后端读取社区；桌面登录态优先走 OpenCLI：

opencli reddit search "<游戏名>" --sort new --time day --limit 10 -f json
opencli youtube search "<游戏名> game" --upload today --sort date --limit 10 -f json
opencli twitter search '"<游戏名>" since:<YYYY-MM-DD>' --product live --limit 10 -f json

同时搜索 new browser game、playable demo、release trailer、HTML5 game 与各语言对应表达，

从正文、标题和落地链接提取新实体。每条雷达记录保存 firstSeen、来源 URL、发布时间、互动量、

可玩链接、语言、市场和别名。同一作者、官方账号及相同文案的跨社区发布合并为一个 campaign；

独立发布者、平台类型和非官方互动分别计数。雷达线索先进入验证队列，达到下方早期爆发闸门后升级。

新词按首次发现后的第 3、7、14、28 天复查。早期保存 volumeStatus: not-yet-observed，继续用

社区增速、跨平台重复、可玩供给和 Trends 判断；搜索量出现后再并入常规 KD、SERP 和国家筛选。

Similarweb 用于最近 28 天的关键词、国家和流量去向验证，Semrush 用于分国家搜索量与 KD。

外部需求双轨闸门（AI 判读指引，脚本不执行）

站内新增页、首页入口和 sitemap 批量更新时间负责发现候选。外部需求分从独立 Google SERP、本地

搜索量、Trends、竞品自然搜索词，以及非官方社区传播中取得。

下面两轨的分值和通过线是 **AI 对着原始信号打分判读时的参考口径**，不是脚本行为：

脚本只把每个来源的原始数值、状态和失败现场交出来。某来源 status:'failed' 或关键词行

status:'not-queried' 时，对应打分项标「未测」，整条判决按证据不全处理，不得按 0 分计。

### 搜索需求轨

| 项目 | 分值 |

|---|---:|

| 目标国家精确词月搜：1–99 / 100–499 / 500–1999 / 2000+ | 5 / 10 / 15 / 20 |

| Google 前十存在多个独立域名且意图与游戏一致 | 10 |

| 30 天或 7 天 Trends 形成连续曲线并向上 | 10 |

| Similarweb 能在竞品自然搜索词中看到该词 | 5 |

| KD：≤30 / 31–40 / 41–50 / >50 | 15 / 12 / 8 / 3 |

| SERP 有低权重、新页面或独立站空位 | 10 |

| 可玩供给 / 移动端稳定 / 两天内可上线 | 10 / 5 / 5 |

| 目标国家与搜索意图匹配 | 10 |

精确词、玩法大类和多语言变体分别打分。搜索量达到“全球精确词 1,000，或目标国家精确词 500”

只进入调研，不代表可以开发。AI 判 develop 的参考硬门槛是全球精确词至少 10,000、最高国家至少

2,000、KD 不高于 30、游戏意图已核实、存在独立外部需求并且可玩供给稳定；任一项缺失或未测就判

调研或观察。候选再计算 KGR

（allintitle 结果数 ÷ 月搜）：社区初筛线为 KGR <0.25 或 allintitle <100；同时查看 EMD 与前十

专业站占位。总分 70+ 判 quick-ship，50–69 判 priority-research，其余判 watch——这套打分

由 AI 完成并连同理由写进 evaluation 文件，脚本只透传。

### 早期爆发轨

面板尚未形成数据时，保存 4 小时、24 小时、7 天三个快照，并以去重后的 campaign 计算：

| 项目 | 初始通过线（先运行 1–2 周回测再校准） |

|---|---|

| 24 小时非官方独立发布者 | ≥3 |

| 独立平台类型 | ≥2（如 Reddit + YouTube） |

| 24 小时发布速率 / 前 7 天日均 | ≥3 倍 |

| 非官方互动或观看 | ≥20 次互动，或 ≥500 次观看 |

| 搜索萌芽 | Trends rising、Autocomplete 长尾、相关查询或新 SERP 页面命中一项 |

| 可玩供给 | 已有可打开的网页游戏、demo 或稳定 iframe |

前四项全部达到并在 4 小时复查后继续增长，进入 priority-research；再取得搜索萌芽与可玩供给，

升级为 quick-ship。这些数字是自动化的第一版校准值：每天保存命中与后续真实搜索结果，运行 1–2 周

后按成功样本调整。每个发布者的账号、文案、落地链接和发布时间都保存在证据里，方便识别自然扩散

与集中推广。

新词用 7 天、30 天窗口看加速度；有历史的玩法词再看 3 年、5 年窗口，区分长期向上与短时毛刺。

同一痛点在 3 个以上独立平台重复出现，记录为跨平台需求证据。

数据边界

本 Skill 是 Rankup 的可复用专项能力，不是项目 .rankup/ 里的临时流程：

• 通用 SOP、Checklist 与脚本保存在 game-opportunity*、rankup/ 和 backlink/；
• 每个网站自己的平台清单、快照、候选、取数结果与日报只保存在该项目 .rankup/；
• 项目中验证稳定的新规则写回通用 Skill，项目名、域名和私有数据不写入通用规则。

• 平台清单：.rankup/demand/game-platforms.json
• sitemap 快照：.rankup/demand/game-sitemap-snapshots/
• 发布源快照：.rankup/demand/game-radar-snapshots/
• 原始报告、KD 输入与结果、候选 JSON、日报：.rankup/demand/game-review/
• 长期候选与判断：.rankup/research.md

这些都是当前项目自己的数据。复用规则和脚本保存在本 Skill、Rankup 与 Backlink 中。

collect 会把当天 discovery URL 与 radar 的 Steam/itch/Poki 游戏标题合并成唯一的 games[]，社交

campaign 只保留在 radar 原始输入里，不计入新增游戏数。dedupe 可在不联网的情况下重建该文件。

`discover`

在仓库根目录执行：

node game-opportunity/scripts/game-opportunity.mjs discover

平台配置里的 include、exclude、kind 和 timeout 分别负责游戏路径、杂页路径、内容类型和

单站抓取窗口。保留每个平台的独立快照与统计，让报告可以按平台、语言和市场回溯。

`evaluate`

先运行入口脚本生成当天候选队列并验活：

node game-opportunity/scripts/game-opportunity.mjs evaluate

### 1. 验证并归并

读取当天 discovery JSON，对新增 URL 依次完成：

1. 直接 HTTP 检查状态、最终 URL、正文长度和标题；

2. 用 Jina Reader 提取可读正文；

3. 页面依赖登录态或浏览器渲染时，用 OpenCLI 读取；

4. 按 canonical、游戏名、slug 和 iframe URL 合并同一游戏的多语言页面；

5. 分成 playable-game、new-on-platform、game-adjacent、stale-url。

new-on-platform 表示监测站今天刚收录；另行查明游戏首次发布时间。两者同时写入报告。

### 2. 生成关键词

每个有效实体提取 1–3 个真实搜索表达：官方原名、官方英文名、已有本地名。大小写变体合并；Demo

只作为版本标记，不单独占一个词。平台所在国家只记录发现来源，不用于断定游戏产地或目标市场。

英文不能因为游戏来自小语种平台而省略：有官方英文名或通用英文名就进入全球查询。非英语原名也

单独查全球，因为全球查询只统计完全相同的字符串，不会自动把 ノノグラム 翻译成 nonogram。

先把候选标成 brand、category 或 generic，再建立需求簇：

1. brand：官方名、英文名、本地名，以及已有信号支持的 pc、online、guide 等承接意图；

2. category：本地用户对同一玩法的不同叫法、免费/在线/直接玩等意图词；

3. generic：先用 SERP 确认它确实指向同一种游戏需求，再决定是否保留。

Semrush/Similarweb 的相关词用于扩展候选，不能直接当开发证据；扩出的词仍要分别查国家量、KD 和

SERP。同义词可能由同一批用户搜索，报告分别列数，不把它们简单相加成市场总量。游戏平台所在国家

只代表发现来源；全球、英语大市场和真实有量国家不能因小语种来源而跳过。

先执行：

node game-opportunity/scripts/game-opportunity.mjs plan
node game-opportunity/scripts/game-opportunity.mjs demand

demand 固定按下面顺序运行：

1. 按优先级取前 6 个真实游戏，查询其原名、英文名和本地名，读取 globalVolume 与 Top-N byCountry；

2. 把发现市场、byCountry 中有量的国家合并成国家计划；

3. 在同一个 Semrush 页面会话中批量取完所有国家的当