从爬虫到CSV导出：电影节入围名单采集与获奖预测实战

前阵子帮团队搭国际电影节年度数据链路，发现很多人都卡在同一个位置：入围名单是公开的，但散在官网公告、媒体通稿和资料站里，格式五花八门；就算好不容易抓到一张Excel表，距离“用数据说话”也还差着十万八千里。正好这个项目完整走了一遍从采集、清洗到分析预测的流程，所以我按落地的真实顺序整理一版，标题里的“CSV导出”不是凑数，后面每一步的数据流转都离不开它。

这个项目适合三类人：刚学完Python基础、想找个不无聊的requests练手项目的爬虫新手；已经在写爬虫、但没接触过“数据抓完以后怎么用”的开发者；以及真正在做影视数据、奖项分析，想把获奖预测从玄学变成可解释模型的运营和分析同学。整条链路不用Selenium，也不上深度学习，依赖的就是requests、BeautifulSoup、pandas和scikit-learn这一套熟脸。

1. 先想清楚再动手：这个系统到底要做什么

1.1 为什么拿“电影节入围名单”当实战样本

电影节预测和普通影评人凭感觉押片不一样，它其实是一个非常标准的结构化决策问题。每年入围名单公布后，每部影片就是一行数据，包含单元、奖项、导演、地区、制片方这些字段；等颁奖礼结束，官方又会公布一份获奖名单，这份名单就可以作为历史标签存下来。

相比豆瓣电影Top250那种静态榜单，电影节入围名单有几个很明显的优点。

数据更新节奏稳定。每年同一个时间窗口，电影节组委会会集中公布入围片单，这种周期性非常适合做增量抓取。字段半结构化但需要处理。不同页面给的信息密度差别很大，有的只给片名和导演，有的会连带制片地区、国际发行商、首映性质一起列出，这种“半脏、半规整”的数据最能锻炼清洗能力。结果有清晰的标签可用。一部影片最后获奖还是陪跑，是明确的二分类标签，这让后面的预测模型有监督信号，而不是自说自话。

所以我一直觉得，想做爬虫项目却不知道抓什么的人，与其盯着电商价格、招聘岗位这种变化极快又容易触发风控的目标，不如先拿电影节公开公告练手。服务器压力小，数据结构够复杂，分析环节又有得写，指数级提升经验值。

1.2 模块拆解：把“抓—存—析—出”串成一条流水线

项目标题看着长，实际做下来就四个模块：数据采集、数据存储、智能分析、结果导出。我在正式写代码前会先在纸上画数据流，确定每一步的输入输出都是什么，不然很容易写着写着就把逻辑绕成一团。

第一层是采集调度。给定电影节ID和年份，抓取当年的入围名单页，解析成统一的record列表。每一条record至少包含festival、year、section、category、film、director这些核心字段。第二层是标准化存储。所有record合并后转成pandas DataFrame，做字段对齐、缺失值标记，最终导出为CSV。这一步是整个项目的地基，后面所有分析都基于这份CSV。第三层是特征工程和模型训练。读取历年CSV，把“导演入围次数”“前哨获奖数”“首映性质”“题材类型”等转成数值特征，再训练一个能输出概率的二分类模型。第四层是预测输出。把新一年的入围名单喂给模型，生成每部影片的获奖概率排序表，再次落成CSV，方便别人拿去继续做透视表或画图。

这套流水线的好处是每一层都可以单独替换。今天用requests，明天想换httpx，不需要动解析代码；今天想用CSV，过两个月数据量大了想换SQLite，只需要改存储层。很多初学者喜欢把爬虫、清洗、建模全塞在一个脚本里，单次跑通没问题，但一旦页面结构改变或者要增加分析维度，整个人就会陷入改一处崩三处的泥潭。

1.3 技术选型，以及为什么刻意绕开重型工具

这次项目技术栈很克制：requests负责HTTP请求，BeautifulSoup加lxml解析HTML，pandas处理表格，scikit-learn做建模，CSV作为存储交换格式。之所以不选Scrapy，是这个项目的数据源规模和页面数量还没到需要分布式抓取的程度；Scrapy的中间件、Item Pipeline、Twisted异步机制本身是很好的东西，但对一个每日几十次请求量级的学习型项目来说，学习成本高于实际收益。

我也没上Selenium或Playwright。电影节官网的入围名单公布页，绝大多数是发布会当天生成静态HTML，不需要执行复杂JavaScript。用Selenium去渲染只会消耗更多内存，还会让反爬判断变得敏感，更麻烦的是调试起来要同时维护浏览器驱动版本。先检查页面源码里有没有数据，比直接开浏览器靠谱得多。这个道理放在新闻站、公告站、政府公开数据页都成立。

模型方面同样只用了逻辑回归和随机森林。原因很简单，电影节入围样本通常一届主竞赛单元就三四十部片子，能积累的历史有效记录可能只有两三百条，这种量级的数据上深度学习等于让小学生做博士论文，过拟合会让你产生虚假的预测成就感。在样本量小、特征维度不高的情况下，可解释的线性模型和带约束的树模型反而更稳。

2. 数据抓取：从页面到结构化的第一公里

2.1 数据源选型：优先找结构化程度高的公开页面

许多新人一上来就盯着电影节官网首页，但首页通常是动态轮播图，对爬虫并不友好。我的习惯是优先找两类页面：一类是官网自己的“入围名单/官方评选”栏目，它们有时会发布成列表页或PDF公告；另一类是公开资料站按年份整理的奖项页面，这类页面表格结构规整，字段相对完整。

目标站点很明确，第一件事不是写代码，而是看目标站点的robots.txt，同时确认要抓的页面本身有没有“禁止采集”的声明。电影节入围名单是公开宣传材料，个人学习与研究用途通常问题不大，但仍要遵守最基本的爬虫礼仪：控制请求频率、标明可追溯的User-Agent、不抓登录后才能看的内容。关于网络访问，这里只提一句：你的运行环境只要能正常打开目标页面就行，打不开就换一个公开可用的页面做练习，网络连通性不是这个项目要解决的技术重点，不用在无谓的环境问题上消耗时间。

2.2 写爬虫前的准备：请求头、超时和重试

在具体抓数据之前，推荐先手动把目标页面保存成一份HTML文件放在本地，拿这份本地文件调试解析逻辑。不要每次都在线调试，页面结构即使没变，频繁请求也容易触发限流。本地文件调试稳定以后，再切换成在线抓取。

在线请求模块我习惯保持简洁，但以下几个参数一定不会省：请求头里面的User-Agent、Referer；连接超时和读取超时；出错后的指数退避重试。示例代码如下：

python复制import time
import random
import requests

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                  "(KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
    "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8",
}

def safe_get(session, url, retry=3):
    for attempt in range(retry):
        try:
            resp = session.get(url, headers=HEADERS, timeout=(3, 10))
            if resp.status_code == 200:
                resp.encoding = resp.apparent_encoding
                return resp.text
            if resp.status_code in (403, 429, 500, 502, 503):
                wait = 2 ** attempt + random.uniform(0, 1)
                print(f"收到 {resp.status_code}，等待 {wait:.2f}s 后重试")
                time.sleep(wait)
        except requests.RequestException as exc:
            print(f"第 {attempt + 1} 次请求失败：{exc}")
            time.sleep(1 + attempt)
    return None

def main():
    url = "https://example.org/festival/2025/nominations"
    with requests.Session() as session:
        html = safe_get(session, url)
        if html:
            print("抓取成功，长度", len(html))

这里有几个细节值得解释一下。timeout=(3, 10)分别代表连接超时3秒、读取超时10秒，如果服务器卡住但不断开连接，没有读取超时的请求会一直挂在那边，程序看起来就像死循环。resp.encoding = resp.apparent_encoding是处理乱码的关键，很多非中文站点返回的响应头charset缺失或者错误，这时候用requests的apparent_encoding做二次推断，比手动指定UTF-8更稳。

重试只在部分状态码下触发，不把所有异常都无脑重试。403和429说明被限流，退避一下是有意义的；404说明URL本身不存在，再怎么重试也没用。还有一个容易忽略的点：连续请求同一个站点时，尽量在两次请求之间加一个0.5到1秒的随机sleep。每秒一个请求对正规官网来说不算压力，但你的日志更好看，对方服务器也更不容易把你拉黑。

2.3 解析策略：表格、列表和页面内嵌JSON

很多电影节官网的入围名单都长得很像一张奖项导览表。以这种简化的HTML结构为例：

html复制<table class="nomination-list">
    <thead>
        <tr><th>奖项</th><th>影片</th><th>导演</th><th>地区</th></tr>
    </thead>
    <tbody>
        <tr>
            <td class="award">最佳影片</td>
            <td class="film">某部电影</td>
            <td class="director">某位导演</td>
            <td class="country">法国 / 日本</td>
        </tr>
    </tbody>
</table>

对应的BeautifulSoup解析代码可以这样写：

python复制from bs4 import BeautifulSoup

def parse_nomination_table(html):
    soup = BeautifulSoup(html, "lxml")
    records = []
    rows = soup.select("table.nomination-list tbody tr")
    for row in rows:
        cells = row.find_all("td")
        if len(cells) < 4:
            continue
        records.append({
            "award": cells[0].get_text(strip=True),
            "film": cells[1].get_text(strip=True),
            "director": cells[2].get_text(strip=True),
            "country": cells[3].get_text(strip=True),
        })
    return records

为什么推荐CSS选择器而不是正则表达式？因为正则匹配文本内容会把HTML标签语义完全丢掉，页面结构稍有调整就全盘失守；CSS选择器依托的是文档结构，可读性也高得多。比如以后新增了“制片方”一列，不需要改选择器逻辑，只要把遍历规则从4列改成5列，并增加一个字段映射即可。

真正麻烦的是另一种页面：入围名单不直接渲染成表格，而是放在页面内嵌JSON里，前端脚本再把它拼成卡片。面对这种页面，好用的方案是先找到<script type="application/json">标签，解析里面的JSON；实在找不到才考虑用Selenium渲染。

python复制import json
import re
from bs4 import BeautifulSoup

def extract_json_from_html(html):
    soup = BeautifulSoup(html, "lxml")
    for script in soup.find_all("script"):
        if script.string and "nomination" in script.string:
            data = json.loads(script.string)
            return data
    return None

有些内容管理系统会把中文双引号转义成\u201c之类的Unicode编码，看着吓人，实际json.loads都能正常还原。如果发现返回的内容是乱码，先检查是不是请求阶段编码判断错了，不要急着动解析代码。

电影节官方的入围名单页结构其实每年都会微调，有的年份加了个筛选交互，有的年份把单元名称改了。所以解析代码里我强烈建议不要硬编码单元格顺序，最好用表头文字去定位列索引。即使解析逻辑要重写，也能尽量保证下游字段名不变。

2.4 断点续抓和增量更新思路

一个真实项目通常不会只抓一届数据。抓最近三到五年的入围名单是基本操作，这时就需要考虑断点续抓和增量更新。

我常用的方案是把“已完成年份”记录到一个meta.json文件里：

json复制{
  "last_success_year": 2023,
  "festival": "example_festival",
  "updated_at": "2025-06-01 12:00:00"
}

每次启动爬虫先读meta.json，只抓大于last_success_year的年份；某一年抓完后立即写回。中间如果请求失败，终止程序后再次运行，会从失败年份重新开始，不会白白浪费时间。

字段冲突也是一个不容忽视的问题。不同年份的官网页面字段叫法不同，去年是“Country”，今年改成“Production Country”，合并时一定要做字段名映射，宁可多维护一张映射表。去重时不要只以片名为唯一键，因为同名电影太多，我通常使用“festival + year + category + film + director”的组合作为唯一标识符，这样既能防止重复入库，又保留了多版本信息的可能性。

3. 把数据收拢：CSV导出与数据清洗

3.1 统一字段设计：让历年数据能横向合并

如果你只抓某一年，字段随便叫都无所谓；但要做预测分析，必须让三年、五年的数据放进同一张表，字段名就是这时候的“数据结构契约”。

我最终落表的字段大致如下：

前四个字段解决“这是一条什么记录”的定位问题，中间四个字段是影片基本信息，最后四个是给分析模块准备的特征和标签。别试图在第一版就把所有能想到的字段都加进去，数据落地后随时加字段的成本很高，反而会拖累采集进度。

3.2 清洗引擎：脏字符、别名和缺失值

清洗不是一上来就写一个Big Cleaner函数，而是分轮处理。

第一轮处理编码和不可见字符。全角空格、零宽空格、不间断空格这类字符肉眼根本看不见，但在后续字符串匹配时会莫名其妙地出问题。统一用正则替换掉即可。第二轮处理括注信息。比如片名写成“某种电影(The English Title)”，如果不需要英文原名，把括号里的内容去掉，只留片名主干。第三轮处理分隔符。多个制片国家之间有时用“/”，有时用“、”，有时用逗号，统一成竖线分隔，后面要做多标签统计就方便。

缺失值处理需要分情况讨论。像片长这种数值型字段缺失，可以用该单元所有入围影片的中位数填充，不用刻意去外部平台补全，补全成本高且未必准确。导演入围次数缺失，则填0，因为缺失更可能代表“查无此前记录”而不是“数据没抓到”。

这一步输出一份标准化的DataFrame，并用to_csv落地一个中间版本文件，起名clean_nominations.csv。注意保存中间结果，不要只有一份最终文件，后面如果发现特征计算有误，重跑整条链路太浪费时间。

3.3 CSV导出看起来简单，真实坑全在编码和换行

CSV本身没有字符集标准，不同软件默认打开方式不一样。用Excel打开CSV出现乱码，绝大多数情况是编码问题。pandas导出时直接指定utf-8-sig，而不是utf-8，是当前最省事的方案。

python复制import pandas as pd

df = pd.DataFrame(records)
df.to_csv("nominations.csv", index=False, encoding="utf-8-sig")

utf-8-sig会在文件开头加一个BOM头，Excel识别这个头之后就会按UTF-8解析，中文和特殊符号都能正常显示。如果导出时不带BOM，Excel在Windows简体中文环境下常会按GBK解析，结果就是满屏乱码。这个坑十次里有九次会踩，提前写在工具函数里，能省掉不少麻烦。

除了编码，还有三个需要注意的细节。写入CSV时index=False是必须的，否则pandas会把行号作为第一列写进去。包含较长中文文本或逗号的字段，pandas会自动加引号包裹，这是CSV标准行为，别手动去掉。如果文件只用来做数据分析，不追求Excel直接打开，可以采用compression="gzip"导出为.csv.gz，体积能缩小到原来的十分之一，以后读取时pandas也能直接识别。

3.4 从CSV到Excel透视：不做重复劳动

CSV在Excel中直接打开确实会丢失一些视觉格式，如果团队同事不习惯看CSV，可以用Excel的“数据—自文本/CSV”导入功能，在导入向导里手动指定分隔符和编码。相比直接把csv后缀改成xlsx，这种方式不会出现字符截断和列错位。

不过我更推荐在pandas里顺手做一版透视结果再导出。比如统计各单元、各年份、各国或地区的入围影片数量：

python复制pivot = pd.pivot_table(
    df,
    values="film",
    index=["year", "section"],
    columns=["country"],
    aggfunc="count",
    fill_value=0,
)
pivot.to_csv("festival_overview.csv", encoding="utf-8-sig")

这样既保留了明细CSV，又提供了一份方便共享的汇总CSV。真正需要Excel的视觉样式时再用openpyxl生成带样式的报告，没必要每次都手动把CSV转来转去。

4. 智能分析：做预测前先把“人脑先验”变成特征

4.1 标签定义：先搞清楚在预测哪一件事

预测“电影节获奖”听起来很宏大，落到模型里必须非常具体。我这次的标签定义是：在某电影节主竞赛单元入围影片中，最终获得该单元最高奖的那一部记为won=1，其余入围影片记为won=0。如果需要预测最佳导演、评审团大奖等其他奖项，就要做多标签训练，第一版不必搞那么复杂，先把“最高奖归属”预测做通，再复制到其他奖项上。

每年正样本只有1个，负样本可能有30个以上，这种不平衡在分类任务里非常常见。处理方式分两头：模型层面用class_weight="balanced"给少数类更高惩罚权重；评估层面不用准确率，改用ROC AUC或者查准率、查全率。一个所有影片都预测0的模型在准确率上可能高达95%，但它毫无意义。

4.2 把一部电影抽象成可计算的特征

特征是对问题的理解，模型只是把这种理解变成数字化的权重。围绕电影节评审场景，我把特征分成三类。

第一类是导演历史特征。导演此前是否入围过该电影节主竞赛，入围次数多少，是否获得过重要奖项。电影节评委对“熟脸”有天然偏好，哪怕是评审换了一批，这种惯性也真实存在。第二类是影片本身特征。首映性质是否世界首映、片长是否落在100到130分钟这个常见区间、是不是剧情片或作者电影。第三类是行业先行信号。这部片在入围公告发布前是否已经拿了若干前哨奖，发行方是不是知名的艺术片发行厂牌，业内热度是否明显走高。

特征可以用一个函数集中构建：

python复制def build_features(row):
    return {
        "screen_world_premiere": 1 if row["premiere_type"] == "World Premiere" else 0,
        "runtime_normalized": (row["runtime"] or 120) / 120.0,
        "is_drama": 1 if row["genre"] == "剧情" else 0,
        "dir_prev_count": row.get("director_prev_count", 0),
        "prior_award_count": row.get("prior_award_count", 0),
    }

这里必须先明确一个问题：前哨奖等外部信息，只有在“数据产生时间早于预测时间”时才有资格成为特征。如果你拿2023年的年度榜单去预测2023年获奖者，然后把2023年年底才出现的评论风向也当成特征，这就是典型的数据泄漏，模型在验证集上会表现得很漂亮，真正预测未来时却会失灵。

4.3 规则基线先行：给预测一个可以解释的框架

机器学习不是必须的，先写一个规则基线反而能帮你建立对数据的直觉。我用的是一套人工赋权重规则，大概长这样：一部影片的基础分是0，世界首映加20分，导演此前入围过加30分，拿到过一个重要前哨奖加25分，发行商属于头部艺术片厂牌加15分，片长处于110到130分钟之间加10分。最终按得分排序取Top5，看看和真实获奖结果的重合率。

这个规则看似简单，却能完成两件事。帮你在没有模型的情况下快速跑通“预测—回测”闭环，验证CSV里的字段和真实世界的关系是否成立。给后续机器学习模型提供基准线，如果模型连简单规则都跑不赢，要么是特征没做好，要么是样本量实在不够支撑复杂模型。

规则模型的分数还能作为“人脑先验特征”喂给机器学习模型，相当于把领域知识硬编码进去。我最终落地的版本里就有这样一个rule_score特征，它和统计特征的共生效果比单独使用任何一种都更平滑。

4.4 机器学习增强：逻辑回归和随机森林的具体实现

规则模型的上限取决于人工赋权，机器学习模型则能从历史数据里学习权重。逻辑回归胜在稳定可解释，随机森林擅长捕捉非线性交互，在样本量只有几百条的场景下，两者都比神经网络更合适。

先按时间切分训练集和测试集，防止随机切分带来的信息穿越：

python复制import pandas as pd
from sklearn.ensemble import RandomForestClassifier
from sklearn.linear_model import LogisticRegression
from sklearn.preprocessing import StandardScaler
from sklearn.metrics import roc_auc_score

df = pd.read_csv("clean_nominations.csv", encoding="utf-8-sig")
feature_cols = [
    "screen_world_premiere",
    "runtime_normalized",
    "is_drama",
    "dir_prev_count",
    "prior_award_count",
    "rule_score",
]

train = df[df["year"] <= 2022].copy()
test = df[df["year"] == 2023].copy()

X_train = train[feature_cols].fillna(0)
y_train = train["won"]
X_test = test[feature_cols].fillna(0)
y_test = test["won"]

model = RandomForestClassifier(
    n_estimators=300,
    max_depth=4,
    class_weight="balanced",
    random_state=42,
)
model.fit(X_train, y_train)
test["prob"] = model.predict_proba(X_test)[:, 1]
print("ROC AUC:", round(roc_auc_score(y_test, test["prob"]), 4))

随机森林不一定比规则模型好，但它的特征重要性会告诉你哪些信息在历史数据里真的起作用。如果prior_award_count的重要性显著高于其他字段，那么后续采集数据时就要更重视前哨奖的追踪记录。逻辑回归提供的是权重方向和置信区间，可以配合p值筛选无效特征，只是要注意对连续特征先做标准化。

样本量小的时候，不要依赖默认的交叉验证随机分组。同一届入围影片之间并非完全独立，随机分配会导致模型“记忆”整届特征。更稳妥的做法是滚动时间窗口验证：用2020到2022年训练，预测2023年；再用2021到2023年训练，预测2024年，如此循环。这种方法得到的分数才更接近真实预测表现。

4.5 输出预测结果：概率之外还要给理由

最终输出不能只是prob这一列，我习惯合并出一份prediction_2025.csv，包含电影节、单元、片名、导演、规则得分、模型概率、综合排序等多个字段，让使用者能看清概率高在哪、低在哪。

生成综合排序时可以把规则模型分数和机器学习概率做一个简单归一化融合。比如final_score = 0.4 * normalized_rule_score + 0.6 * model_prob，两者的绝对值量级不同，直接相加没有意义，务必先做min-max归一化。归一化的目的是保留排序信息，不是制造一个拿来横向比较的绝对指标。

如果涉及最终Top名单，建议在导出的CSV里增加一列“推理说明”，用规则模型的可解释性来生成一段简短理由。举例来说：某部影片概率排第一，可能因为导演是上一届评审团大奖得主，这次带着新片回到主竞赛，同时该片已经拿下两个前哨奖。这一段话比一个孤零零的概率数字更能说服人，也更方便业务侧做交叉验证。

5. 我踩过的坑：从pycharm退码0到动态页面拿不到数据

5.1 爬虫程序明明跑完了，为什么没有任何输出

这是搜索热词里反复出现的问题，用PyCharm运行爬虫脚本，底部显示Process finished with exit code 0，控制台却什么都没有。很多人以为这说明程序“成功执行了”，其实它只代表Python解释器没有抛出异常，和爬虫有没有抓到内容完全是两码事。

结合我自己的经历，最常见的原因有几种。脚本只有函数定义却没有调用入口，解释器读完全部代码后自然退出；数据抓取阶段出现了异常，但被大段try/except吞掉，没有打印任何日志；目标页面返回的是空内容，列表推导结果为空，后续打印又放在循环外；程序入口使用了if __name__ == "__main__":，但函数名拼写错误，入口没被执行。

排查的第一步是去掉所有装饰性的try/except，或者在代码开头直接加一行醒目的print("start")，先确认程序有没有走到业务逻辑。第二步是在每个关键节点打印状态，抓完页面打印HTML长度，解析完打印记录条数。我见过不少同事在解析函数里把所有异常都捕获后静默处理，结果页面结构改了，爬虫不报错也不输出，很难排查。更稳妥的做法是依赖logging模块输出到文件，控制台保持干净的同时，出问题时能回溯到具体行。

5.2 403与429：被识别后如何正确重试

国际展会类官网通常套了一层CDN，对非浏览器流量有一定识别策略。实测下来，触发反爬的时候，响应的状态码集中在403和429两种。403表示请求被拒绝，429表示请求过于频繁。

遇到403，优先检查请求头，尤其User-Agent是否被设置成了requests的默认值，那种默认UA在服务端日志里非常显眼。遇到429，说明并发或频率超过了对方的阈值，这时只能退避重试。继续切IP属于高风险动作，不推荐在个人项目里使用。我自己的做法是尊重服务器的限制，把采集窗口拉长，每两个请求之间固定休息1.2到2秒，并且在请求失败后指数退避。

一个更实际的建议是：每次抓取前先看目标页面的robots.txt，有的目录明确标注了抓取延迟要求。开放数据不等于可以无限制访问，要留出足够的缓冲时间。

5.3 中文乱码、繁体别名和地区拆分

电影节数据一个很折磨人的地方是中文译名不统一。比如同一位导演，在不同年份可能被翻成不同的中文名，不同媒体写同一部电影也会有简繁差异。如果不做别名归一化，两个字段内容明明指同一部片子，因为编码或写法的差异会被当成两条完全不同的记录。

针对这种问题，先要统一字符编码，先用apparent_encoding加载页面，再统一转成小写，然后把繁体转简体。如果分析脚本最终还是匹配不上，就考虑维护一个手工别名表，把常见变体映射到标准名上。需要留个心眼：一些评审团设置里会把“法国/日本”这样的多地区合拍放在同一个字段里，若想按地区统计风格，用str.split("/")拆开后再做横向透视会更顺手。

5.4 小心数据泄漏：不要在训练集里混入未来信息

预测项目中最隐蔽的坑就是数据泄漏。测试效果极好，一到真预测就崩，十有八九是这里出了问题。

电影节预测里最容易出现的泄漏有三个位置。把整年数据放在一起做标准化，相当于让模型偷看了未来样本的分布。把当年获奖结果作为特征参与训练，属于直接拿标准答案当输入。把颁奖后才有的媒体讨论热度当成预测前信息，时间线完全错误。

规避办法只有一个：凡是要参与真实预测的特征，必须保证取值时间点早于或等于预测发布日期。评奖前的前哨奖是合理特征，颁奖后的票房和口碑就不是合理特征；预测2025年的获奖结果，训练数据只能用到2024年及以前的全部信息，不能用2025年当年的任何事后统计。

6. 项目迁移和复盘：这套系统还能做什么

6.1 同样一套流程，换个数据源就能继续用

写这个项目最大的体会是，爬虫代码不值钱，值钱的是“流程思维”。电影节入围名单只是其中一个样例，换成年度图书奖、独立游戏奖、体育赛事MVP候选、动漫大赏提名，只要符合“先公布候选名单，再公布最终获奖者”的节奏，整套框架都可以原样迁移。

迁移时只需要改三处：数据源URL和页面解析规则；字段映射配置；判断“入围”和“获奖”的关键字段。模型、清洗流程、CSV导出逻辑几乎可以照搬。这不是偷懒，而是这类评选类数据天然共享同一套逻辑。如果你想扩展场景，还可以考虑把大模型用起来，对评审评语、媒体评论做非结构化文本特征抽取，把“情感倾向”作为新的特征列加入模型中。不过那会引入额外的文本处理模块，属于这个项目的升级版，不在第一版的范围内。

6.2 我对预测这件事的几点真实体会

实际做了几轮回测后，最让我意外的是，复杂的机器学习模型并没有稳稳压过一套精心设计的规则基线。导演历史、前哨奖、发行能力这几个强特征的存在，让模型更像是在验证常识，而不是在发现新规律。经历过几次回测后我反而越来越认同一个观点：在这类社交性极强的评奖场景里，数据分析的目标不是发明一种黑箱来替代评委，而是把历史上可被识别的偏好信号量化出来，辅助人去判断。

我也建议拿到最终预测结果的人，不要只盯着排序第一名的概率。模型输出的概率差距往往很小，第一名和第二名之间可能只差零点几个百分点，这个精度远远达不到“精准预测”的水平。更合理的用法是把预测结果分为三档：高概率档、中概率档、陪跑档，再结合前哨奖的后续变化做动态修正。预测本身就是动态过程，不是提交一次就结束了。

最后分享一个提效小技巧：当页面改版导致原来的解析器失效时，不要急着在代码里补正则，先看一眼改版后的源码是表格还是内嵌JSON。多数电影节官网的改版最后都会走向前后端分离，数据大概率会藏进某个接口或页面JSON里，这时候把解析器改成读JSON，稳定性反而比继续解析HTML高很多。这个经验放到其他爬虫项目里同样适用。