看到 FansToys FT-63 TURBO COMING SOON! 这条预告时，玩家通常的回应是去搜索，然后得到一堆不完整的信息。有人说是新品，有人说是系列改版，有人贴出一张没有来源的渲染图，还有人已经开始发预订链接。信息分散、真假混杂、节奏不确定，这是第三方模玩预告阶段最常见的状态。
这篇内容不是替玩家预测这组产品，也不讨论具体发售日期。它要做的是用工程技术手段解决一个真实问题：当新的预告信息出现时，如何把“又出了一条消息”变成一组可追踪、可验证、可提醒的结构化情报。换句话说，文章会带读者完成一个“模玩新品情报追踪系统”的最小实现，包括预告信息拆解、数据模型设计、定时抓取、变更检测、Webhook 推送和交叉验证流程。
这套流程适合收藏玩家、模玩经销商和内容编辑使用。学完后，可以把任何以 COMING SOON、PRE-ORDER、IN STOCK 等形式出现的商品预告，纳入自己的监控体系，而不是每一条都靠手动刷新页面。
1. 从一条预告开始，先定义清楚要追踪什么
很多人在搭建监控脚本时犯的第一个错误，是直接去找页面结构、去写抓取逻辑，还没想清楚这条信息在未来几天可能产生多少次变化。预告并不是一个静态文本，而是一个不断变化的流程。先定义清楚追踪对象，后面写代码才会省力气。
1.1 一句“COMING SOON”里缺什么
“FansToys FT-63 TURBO COMING SOON!”这句话至少包含两类信息。
第一类是相对确定的标识信息：产品系列是 FansToys，产品代码是 FT-63，附加标识是 TURBO，当前阶段是 COMING SOON。这些字段适合直接建表。
第二类是缺失的、需要后续信息补全的字段：预订什么时候开放、官方通告发布在哪里、经销商列表是什么、价格是多少、计划出货时间是什么、是否会有多个版本。这些字段不能靠一次抓取得到，必须持续监听不同信源。
这里有个容易忽略的点：TURBO 这个单词并不一定代表某个具体产品。它可能是系列名、可能是配色版本、可能是玩法形态，也可能只是营销文案。在下游系统里，它应该作为“别名”或“版本详情”存在，而不是被直接当成产品主名。
1.2 为预告信息建立字段模型和状态模型
一个可以长期使用的追踪系统，记录的不应该只是“今天页面标题是什么”，而应该是一份持续累积的事件表。
先看字段模型。下面的表适合所有模玩预告类信息，字段不是一次写死的，可以随进度扩充：
| 字段 | 说明 | 推荐取值 |
|---|---|---|
| product_code | 产品代码，如 FT-63 | 字符串 |
| alias | 版本名或俗称，如 TURBO | 字符串 |
| series | 所属系列 | 字符串 |
| status | 当前状态 | 见状态表 |
| announce_date | 首次预告日期 | ISO 时间 |
| pre_order_date | 预订开放日期 | 可空 |
| release_date | 预计出货日期 | 可空 |
| price | 价格 | 数字 |
| currency | 币种 | CNY/USD 等 |
| source_url | 信息来源链接 | URL |
| raw_title | 抓取到的原始标题 | 字符串 |
| checked_at | 最近检查时间 | ISO 时间 |
再看状态模型。预告信息会沿一条状态链移动：
| 状态 | 含义 | 玩家动作建议 |
|---|---|---|
| COMING_SOON | 已公开预告，但未开放预订 | 记录信息，不付款 |
| PRE_ORDER_OPEN | 经销商开放预订 | 核验货源，核对授权 |
| RELEASE_SOON | 临近出货或即将发货 | 关注补款通知 |
| IN_STOCK | 现货销售 | 比较渠道价格和售后 |
| STOCK_OUT | 售罄或下架 | 保留监控，等待补货 |
| UNKNOWN | 无法判断 | 停止动作，人工复核 |
这套状态机最大的价值，不是让程序判断“产品现在有没有货”，而是让玩家在每一个阶段都知道自己该做什么。比如状态是 COMING_SOON 时，最合理的操作是继续观察，而不是收到一条预告消息就去付款。
1.3 三类信源要分开处理
不同来源的信息可信度差别很大。系统如果不区分信源，就会出现“把路边店的预订链接当成官方公告”的情况。
建议把信源分成三级。
第一级是官方渠道，包括品牌账号、官方网站和官方公告。它们的信息密度不一定最高，但可信度最高，应该作为状态变更的首要依据。
第二级是授权经销商或渠道商，包括官方合作店铺、规模较大的第三方零售渠道。它们能提供预订时间、价格和配额，但价格和库存数据可能波动较大。
第三级是社区和二手交易平台，包括玩家论坛、讨论群、社交平台内容。它们的信息最杂，适合收集线索和反馈，不能直接作为状态判断依据。
在代码里，每个目标源都建议带上 source_level 字段，这样推送提醒时可以在标题中带上可信度等级，官方消息和社区传闻的提醒样式应该分开。
2. 搭建最小抓取与变更检测脚本
定义好追踪对象之后，就可以开始写程序。这一章先做本地可运行的最小版本，并把功能拆成三个部分：抓取页面、提取内容、检测变化。
2.1 工作目录与依赖准备
本机需要 Python 3.9 或更高版本。创建项目目录：
mkdir toy-info-watcher cd toy-info-watcher python3 -m venv .venv source .venv/bin/activate建议使用虚拟环境，避免污染系统 Python。安装依赖：
pip install requests beautifulsoup4需要处理图片元数据时可以额外安装：
pip install Pillow最后生成依赖清单：
pip freeze > requirements.txt注意：requests 和 beautifulsoup4 的具体版本会随时间变化。落地前先确认当前稳定版本，不要直接照抄旧版本号。
