jiangjiax Steam 游戏市场调研
模式路由
先判断用户要哪一种结果：
- 榜单模式：用户要某个 Steam Indie 类别的 Top N、价格、评论、团队或人月。执行下文的两阶段榜单工作流。
- 单游戏案例模式：用户点名一个游戏，询问它为什么成功、经历了什么、如何开发/营销/经营账号，或要求一份该游戏调研报告。读取并执行 references/single-game-case-study.md。此模式不受榜单模式“第一阶段完成后必须停下”的限制。
两种模式都必须区分可核实事实与分析判断；但面向读者的 PDF 不放研究过程、证据免责声明或内部工作备注。证据边界应通过自然、简洁的正文表达，研究记录另存。
榜单模式
将调研严格分为两个阶段。默认只执行第一阶段；第一阶段交付完成后必须停下，不能顺手开始团队或人月调查。只有用户明确批准第二阶段后，才补查团队、周期和人月。
开始前读取 references/research-schema.md，按其中字段、计算和证据口径输出。
固定口径与可变类别
以下口径固定：
- 主标签：Indie
- 排序：Top Sellers，保留 Steam 页面原始顺序
- 地区：美国，URL 参数
cc=us - 界面语言：英语，URL 参数
l=english - 评论：评论详情页
All Languages的累计评论数量，不用 Recent Reviews，也不用商店页可能展示的单一语言评论数 - 价格：美国区 USD 的单体游戏
Basic原始标价；不用折后价、套餐价、捆绑包价、DLC 价格或页面正文里碰巧出现的美元数字 - 指标：
All Languages review count × US Basic list price - 默认排除免费游戏：
is_free=true、价格显示为 Free 或仅能游玩而无 Basic 价格的条目不计入 Top N；继续向下加载 Steam 主榜，直到收集到用户要求数量的付费条目。免费条目写入采集日志，不进入结果表。
Indie 之外的第二类别是每次任务的变量，例如 Simulation、Strategy、RPG 或其他用户指定类别：
- 用户给出类别时，在 Steam Indie 页面选择该类别；
- 用户给出已经筛选好的链接时，以链接当前显示的类别为准，并在页面上复核类别名称；
- 用户同时给出类别和链接但两者冲突时，先指出冲突并请用户确认；
- 用户既未给类别也未给筛选链接时，先询问本次要调研的 Indie 子类别；
- 不记忆上一次的 Simulation 或任何其他类别为下次默认值，也不硬编码某个 facet 参数。
基础入口可使用 https://store.steampowered.com/tags/en/Indie/?flavor=contenthub_topsellers&cc=us&l=english，再按本次任务选择第二类别。最终结果必须记录实际类别名称和最终筛选 URL。
硬边界：两阶段
第一阶段：Top N 付费条目
第一阶段按用户指定数量 N（未指定时为 20）采集和核对 Top N 付费条目、评论数、美国区单价、发售时间和“最少赚了多少钱（粗略估算）”。榜单原始排名保留在 steam_source_rank，过滤免费条目后的顺序写入 source_rank。不得在此阶段把公司总人数、融资或外包情况当作项目团队事实；团队深挖和人月仍留到第二阶段。
第一阶段必须同时生成以下可读交付物：
- UTF-8 CSV：完整字段和证据口径；
- 双语 HTML/PDF：封面（使用 Steam 封面）、方法说明、按排名纵向排列的条目页。每页至少包含英文标题、中文标题或译名、双语简介、All Languages 评论数、美国区 Basic 原价、最少赚了多少钱（粗略估算）、发售时间、开发商/发行商。团队和人月栏在第二阶段未批准前明确写“待补查 / Pending second-stage research”，不得留空或猜测。
第二阶段：团队与人月
用户明确批准后，可查全部 N 个或用户指定的候选游戏。全量任务优先按数量近似均分为三组；例如 Top 20 分为 1–7、8–14、15–20，Top 50 分为 1–17、18–34、35–50。每组独立保存 JSON，最后由主任务合并、去重并校验排名 1–N。没有可用子 Agent 时按同一分组顺序串行执行，不改变证据口径。
只有用户在看过第一阶段结果后明确同意，才进入第二阶段。用户可以要求调查全部 N 个，也可以只选择候选游戏。
第一阶段完成后，必须询问：
Top N Steam 付费条目数据和可读版 PDF 已经完成。是否进入第二步，补查团队人数、开发周期和人月？可以查全部 N 个，也可以先由你选出感兴趣的候选游戏。
发出问题后停止，不自行继续。
第一阶段执行流程
1. 打开并校验榜单
使用用户可见的应用内浏览器打开榜单。不要只依赖搜索引擎摘要或第三方聚合站。
在采集前确认：
- 页面界面为英语；
- 地区为美国，价格显示为
$； - 主标签为
Indie，且当前选择为用户本次指定的第二类别； - 当前榜单为
Top Sellers； - 数据来自主结果列表。
排除 Featured、Popular Discounted、Popular Titles、Top Demos、活动推荐、相似产品和个性化推荐等非主榜模块。
2. 获取榜单前 N 个付费条目
按主榜现有顺序记录结果。持续点击 Show More 或滚动加载，直到获得至少 N 个唯一、付费的 App ID，然后截取过滤后的排名 1–N；免费条目跳过并记入 notes/log。
- 以 App ID 去重，不按标题去重；
- 不因个人判断调整 Steam 排名；
- 遇到免费游戏时排除并继续向下补齐；DLC、序章、试玩版、软件或其他异常条目仍保留其付费排名并标注，不静默替换；
- 每条保留带
cc=us&l=english的可复查详情页 URL。
3. 逐个打开详情页
从榜单进入每个条目的 Steam 详情页，记录开发商、发行商、发布日期、支持语言数量和条目类型。
价格读取规则：
- 找到该单体条目的购买区；
- 读取
Basic对应的原始/标准售价； - 页面促销时仍记录划线前原价；
- 不取
Deluxe、Complete Edition、订阅、套餐或捆绑包价格； - 不从整页文本抓取第一个
$，游戏标题和正文也可能含美元数字； - 无 Basic 价格时留空并写明原因，不猜价。
4. 获取所有语言评论数
点击详情页的评论入口，进入评论页并打开语言筛选。读取 All Languages 后括号或旁边显示的累计数量。
- 必须记录精确整数，保留 Steam 页面显示的原始值；
- 同时记录
All Languages的评价标签； - 能可靠取得时记录全球好评率，否则留空，不反推；
- 不把
English、Recent或商店页摘要评论数当作 All Languages。
5. 计算和保存
逐行计算：
review_based_lower_bound_signal_usd = all_languages_review_count × us_basic_list_price_usd
该值展示为“最少赚了多少钱（粗略估算）”，但不是实际收入、净收入、销量或购买人数。它没有计入未评论购买者，也没有扣除退款、平台分成、税费、地区价格、免费 Key、折扣和历史价格差异；因此只适合作为统一口径的粗筛信号。
默认保存为 UTF-8 CSV（保存到当前项目的调研输出目录）：
research-output/YYYY-MM-DD-indie-<类别>-topN-paid-us-en.csv
同时生成到同一输出目录：
YYYY-MM-DD-indie-<类别>-topN-paid-bilingual.htmlYYYY-MM-DD-indie-<类别>-topN-paid-bilingual.pdf
PDF 必须达到项目既有最终版的可读级别：封面图片、双语方法页、每个条目独立页面、稳定的指标卡片和来源链接。未经用户明确要求，不上传飞书或其他外部服务。
第一阶段交付检查
交付前逐项确认：
- 恰好 N 行，
source_rank连续为 1–N，steam_source_rank唯一且按 Steam 主榜顺序递增； - N 个付费 App ID 唯一，结果表不含免费条目；
- 过滤后的排名与 Steam 主榜来源顺序一致；
- 评论数来自
All Languages； - 价格来自美国区 USD Basic 原价；
- 每个可计算结果都能由评论数和单价复算；
- 被排除的免费条目、缺价、DLC、非游戏或其他异常均有备注或采集日志；
- 输出明确写明采集日期、来源 URL、地区、语言和指标免责声明。
若 Steam 页面无法验证某字段，不伪造也不拿第三方估算填成事实。保留空值，写明失败原因和已尝试的页面。
第二阶段执行要求
用户明确批准后，再对用户指定的游戏调查：
- 核心团队规模与岗位构成；
- 开发开始时间、抢先体验时间、正式发行时间；
- 有效开发月数；
- 人月估算及计算区间；
- 外包、兼职、发行商支持、融资等会扭曲人月判断的因素；
- 每条结论的可追溯来源、发布日期和置信度。
外部多源核查协议
Steam 没有提供官网入口、官网页面没有团队资料或链接无法打开时，不得直接停止并写成“查不到”。必须继续做一次定向外查，至少覆盖以下路径中的可用项：
- 用“游戏名 + 开发商 + team / founder / credits / interview”等组合词搜索；
- 直接检查开发商官网、发行商官网、公司 About / Team / Credits / Careers 页面；
- 检查开发日志、GDC/公开演讲、开发者访谈、发行商新闻稿和可信媒体报道；
- Steam 的社交账号、Discord、LinkedIn、个人主页只作为线索，只有能明确归属于该开发团队且可追溯的内容才可入表。
来源优先级：开发者/发行商一手页面 > 开发者访谈、公开演讲、开发日志 > 可信媒体 > 搜索摘要。搜索摘要和 AI 回答只能作为线索，不能作为最终证据。每条已确认结论至少保存来源标题、URL、日期（若有）和短引文/准确摘要。
公司总人数、发行商人数或“数十人”等模糊表述不得直接当作单个项目人数。必须标明“公司级 / 项目级 / 核心团队 / 贡献者”，不能归因时保留未知。
人月估算纪律
事实字段（团队规模、开发开始、Early Access、正式发行）与估算字段分列。只有团队人数和有效开发月数都有可追溯依据时才计算：
person_month_estimate = team_size × effective_development_months
优先输出区间或保守下限，并在 support_factors / research_notes 写明口径、是否只覆盖核心团队、是否包含外包/发行商支持。缺少任一关键事实时写 Not estimable，不得把未知人数乘未知周期包装成精确值。
第二阶段交付
第二阶段默认生成：
YYYY-MM-DD-indie-<类别>-team-personmonths.json：N 条独立证据记录；- 双语可读 PDF：每个游戏一页，包含封面、简介、评论数、美国区单价、最少赚了多少钱（粗略估算）、发售时间、团队/人员、开发周期和人月；
- 可编辑 HTML（如使用项目内报告生成器）。
如果使用脚本生成报告，脚本应把类别、数量、日期和输入文件作为参数；更换类别时，文件名、输入数据和报告标题必须同步更换，不得把某个类别写死。脚本输出应保持本 Skill 规定的字段、证据和免责声明。
PDF 交付前检查：页数应为封面 + 方法说明 + 游戏条目数；排名连续、App ID 唯一；抽查免费游戏、DLC、超长标题和末页；确认“最少赚了多少钱”仍明确标注为粗略估算，不是实际收入。Not disclosed / Not estimable 必须保留原因和来源检索范围。