Solarex从项目标题开始理解，Datawhale的组队学习在开源社区里已经是老牌活动了，每次报名都要拼手速。这期Easy Vibe课程的主线是情感分析，Task 02是整个项目里承上启下的关键一环。这篇文章我按自己的实际参与过程来写，把任务拆解、代码实现、踩坑记录都整理出来，给后面参加组队学习的朋友一份能直接参考的实操笔记。
1. Easy Vibe Task 02在整条学习链路里的位置
1.1 为什么Task 02这么重要
Datawhale的组队学习课程喜欢把完整项目拆成多个Task，每个Task都对应一条明确的学习主线。Easy Vibe这期课程的目标是带大家从零完成一次文本情感分析项目，Task 01自然是环境配置和数据集的初步认识，到了Task 02，才真正进入“动手干活”的阶段——数据清洗、探索性分析和特征工程。
很多初学者会低估数据预处理和特征工程的分量，觉得建模才是核心。但恰恰相反，在文本情感分析这类任务里，模型能取得什么效果，很大程度上取决于喂给它的特征长什么样。Task 02做得好不好，直接决定了Task 03建模时你是顺风顺水还是被各种古怪报错折磨。
这期Easy Vibe课程选用的数据集是典型的影评评论数据，包含评论文本和对应的情感标签。Task 02要完成的就是把原始文本从“人能读懂的句子”转换成“模型能学习的矩阵”，中间涉及的所有步骤都要自己动手过一遍。
1.2 任务交付物与评价标准
组队学习的特点是每个Task都有明确的产出要求。Task 02的交付物通常包含三样东西：一份清洗后的数据集、一份探索性分析的可视化图表、一个可以直接喂给模型的TF-IDF特征矩阵。这还不算完，每个参与者还需要把自己的思路和代码整理成一篇学习笔记公开发布。
评价标准方面，不以模型精度论英雄，而是看你对数据的理解是否到位——你是否发现了类别不平衡问题、是否注意到了评论文本长度分布的异常、是否在特征工程时避免了数据泄漏。这些看似零散的细节，才是Task 02真正想让你掌握的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的准备：环境、数据与团队协作约定
2.1 基础环境搭建的注意事项
我在Task 01已经完成了Python环境的安装，但Task 02会额外用到几个库：nltk用于文本清洗、scikit-learn用于特征提取、matplotlib和wordcloud用于可视化。建议直接用requirements.txt锁定版本，避免队友之间因为版本不一致出现“在我电脑上没问题”的尴尬。
bash复制pandas==2.1.4
numpy==1.26.3
scikit-learn==1.4.0
nltk==3.8.1
matplotlib==3.8.2
wordcloud==1.9.3
装完之后记得验证一下nltk的数据包是否完整。我第一次跑nltk.download('stopwords')时网络超时，导致后面停用词过滤那一步一直报错，后来换了镜像源才解决。这个坑后面细说。
2.2 数据集的加载与初步认知
这期Easy Vibe课程的影评数据分成训练集和测试集两份。训练集里每条样本包含评论文本和情感标签（正面/负面），测试集只给文本，需要你自己预测标签。Task 02阶段不要求预测，只需要把训练集处理好。
加载数据的代码很简单，但有几个初看容易忽略的细节：
python复制import pandas as pd
train_df = pd.read_csv('train.csv', encoding='utf-8')
print(train_df.shape)
print(train_df.head())
print(train_df.info())
info()会告诉你每列的非空值数量，如果发现文本列有空值，后续清洗时就要专门处理。我这次的数据集还算干净，只有个别空值，但处理逻辑一定要写，因为真实场景里脏数据才是常态。
2.3 组队学习的协作方式直接影响效率
Datawhale组队学习通常以5-8人为一组，配有组长和助教。Task 02开始前，我们组先在群里对齐了三个问题：代码以什么形式存放、笔记用哪个平台发布、每周什么时候集中讨论。
结论是代码统一推送到团队的GitHub仓库，笔记发布到各自的技术博客。集中讨论安排在周六晚上，这种方式的好处是：每周都有明确的交付压力，队友之间可以互相审查代码，发现问题能及时反馈，而不是一个人闷头写到半夜然后发现方向全错。
3. 核心实操：Task 02完整流程记录
3.1 文本清洗：从原始句子到干净词序列
文本清洗是NLP项目里最琐碎但最不能省的环节。原始的影评文本里混杂着HTML标签、标点符号、数字、大写字母等，这些内容对情感判断没有直接帮助，还可能增加特征维度，所以要统一处理。
我的清洗流程分四步：去HTML标签、去非字母字符、统一小写、去停用词和词形还原。完整代码如下：
python复制import re
import nltk
from nltk.corpus import stopwords
from nltk.stem import WordNetLemmatizer
nltk.download('stopwords')
nltk.download('wordnet')
nltk.download('omw-1.4')
stop_words = set(stopwords.words('english'))
lemmatizer = WordNetLemmatizer()
def clean_text(text):
if isinstance(text, str):
# 去掉HTML标签
text = re.sub(r'<[^>]+>', ' ', text)
# 只保留字母，其他字符替换为空格
text = re.sub(r'[^a-zA-Z]', ' ', text)
# 统一小写
text = text.lower()
# 分词
words = text.split()
# 去停用词和长度小于2的词
words = [w for w in words if w not in stop_words and len(w) > 2]
# 词形还原
words = [lemmatizer.lemmatize(w) for w in words]
return ' '.join(words)
else:
return ''
这里有个小细节：len(w) > 2 会滤掉“OK”这类短词，但也会误伤“good”这种长度为4的单词吗？不会，这个条件只是去掉长度为1和2的噪声词，实际效果是维度降低了大概5%-10%，对模型精度基本没影响。
清洗完成后，把处理结果保存到新列里：
python复制train_df['cleaned_text'] = train_df['review'].apply(clean_text)
跑完看一眼前几条数据，确认处理效果。如果发现清洗后出现了大量空字符串，说明原始文本里可能有全数字或特殊字符的样本，这时候可以用train_df['cleaned_text'].str.len() == 0筛出来单独处理。
3.2 探索性分析：用图表把数据“看透”
EDA这部分是我个人最喜欢的环节。常有人说“运营商的KPI是先看数据再看模型”，做项目也同理，不把数据分布摸清楚就急着建模，结果往往很惨。
我做了四个维度的探索：类别分布、评论长度分布、高频词统计、词云可视化。
类别分布用value_counts快速确认是否平衡：
python复制print(train_df['sentiment'].value_counts())
我这次的数据集正负样本接近1:1，类别平衡意味着后面建模时Accuracy可以直接作为评估指标，不用太过担心不平衡问题。但如果你拿到的是不平衡数据，就要考虑F1-score或者加权指标，这个意识要在Task 02就建立起来。
评论长度分布是很多人会忽略的维度。我画了清洗前后的评论词数分布直方图：
python复制import matplotlib.pyplot as plt
train_df['word_count_before'] = train_df['review'].apply(lambda x: len(str(x).split()))
train_df['word_count_after'] = train_df['cleaned_text'].apply(lambda x: len(x.split()))
plt.figure(figsize=(12, 5))
plt.subplot(1, 2, 1)
train_df['word_count_before'].hist(bins=50, color='skyblue', edgecolor='black')
plt.title('Word Count Before Cleaning')
plt.subplot(1, 2, 2)
train_df['word_count_after'].hist(bins=50, color='lightcoral', edgecolor='black')
plt.title('Word Count After Cleaning')
plt.show()
观察下来发现两个信息：大部分评论长度集中在50-150个词之间，但存在极少数超长评论；清洗后词数明显下降，因为停用词占了不少比例。这个分布会直接影响后面TF-IDF特征提取时的max_features参数设置——如果大多数文本都很短，设置太高的特征数只会带来稀疏和噪音。
高频词统计我用Counter来做：
python复制from collections import Counter
all_words = ' '.join(train_df['cleaned_text']).split()
word_freq = Counter(all_words).most_common(20)
print(word_freq)
这个结果对理解数据的主题很有帮助。比如我这里的影评数据，高频词基本都是“film”“movie”“story”“character”这类电影领域专有词，情感词像“good”“great”也在前列。这说明数据有效信息充足，分类器是有得学的。
词云图就是锦上添花的部分了，虽然对建模没有直接帮助，但用来做学习笔记展示效果很好：
python复制from wordcloud import WordCloud
wordcloud = WordCloud(width=800, height=400, background_color='white').generate(' '.join(all_words))
plt.figure(figsize=(10, 5))
plt.imshow(wordcloud, interpolation='bilinear')
plt.axis('off')
plt.show()
3.3 特征工程：把文本变成模型能懂的矩阵
这是Task 02的重头戏。要从“文本”变“特征”，最经典的方法是词袋模型和TF-IDF。这期课程要求两种方法都实现一遍，然后对比效果差异。
先说词袋模型（CountVectorizer）。它的核心逻辑是把每一篇文本变成一个向量，向量的每个维度对应一个词，值是这个词在文本中出现的次数。代码实现：
python复制from sklearn.feature_extraction.text import CountVectorizer
count_vec = CountVectorizer(max_features=5000)
X_count = count_vec.fit_transform(train_df['cleaned_text'])
print(X_count.shape)
这里设置max_features=5000是经验值，意思是只保留词频最高的5000个词作为特征维度。我测试过不加限制的话，特征维度会膨胀到几万甚至十几万，训练时间长、内存占用大，效果还不一定更好。
再说TF-IDF（TfidfVectorizer）。TF-IDF比词袋多了一层加权逻辑：一个词在一篇评论里出现次数多（TF大），但在所有评论里很少出现（IDF大），说明它对区分这篇评论的类别很有价值。反之，“film”“movie”这种每个评论都有的词，IDF会很低，自然就被降权了。
python复制from sklearn.feature_extraction.text import TfidfVectorizer
tfidf_vec = TfidfVectorizer(max_features=5000)
X_tfidf = tfidf_vec.fit_transform(train_df['cleaned_text'])
print(X_tfidf.shape)
两个矩阵形状一样，但含义不同。CountVectorizer得到的是词频统计，TfidfVectorizer得到的是加权后的重要性。后面Task 03建模时，你可以分别用这两组特征训练同一个模型来对比，通常TF-IDF在情感分类任务上表现更好，因为能抑制高频无意义词的干扰。
这里有一个关键的实操心得：fit_transform里的fit是在学习训练集上的词表或IDF值，transform才是真正做转换。Task 03的测试集预测阶段，你只能用训练好的vectorizer去transform测试集，绝对不能重新fit，否则会改变特征空间，导致维度对不上而且泄漏测试集信息。
3.4 数据集划分与保存
Task 02的最后一个环节是把处理好的数据保存下来，供Task 03使用。这里的数据划分方式很重要，正确做法是先划分再提取特征，或者至少先把train_test_split的结果保存好：
python复制from sklearn.model_selection import train_test_split
X_train, X_val, y_train, y_val = train_test_split(
X_tfidf, train_df['sentiment'], test_size=0.2, random_state=42, stratify=train_df['sentiment']
)
print(X_train.shape, X_val.shape)
stratify=train_df['sentiment']的意思是按标签比例分层抽样，保证训练集和验证集里的正负样本比例一致。如果不加这个参数，运气不好时验证集可能全是正面评价，模型评估直接失真。
最后把特征矩阵保存为npz格式，标签保存为csv，这样Task 03就能直接读取：
python复制from scipy import sparse
import numpy as np
sparse.save_npz('X_train_tfidf.npz', X_train)
sparse.save_npz('X_val_tfidf.npz', X_val)
np.save('y_train.npy', y_train)
np.save('y_val.npy', y_val)
注意：保存的是划分后的训练/验证集，不是整个训练集的特征矩阵。很多新手在这里图省事把全量特征保存下来，到了Task 03又重新划分一次，这样不仅重复劳动，还容易在划分时引入数据泄漏。
4. 踩坑记录与排查思路
4.1 Index错位：合并数据时的经典事故
Task 02里我有一次差点翻车：做完文本清洗后，我把清洗结果和原始DataFrame拼接，用的方式是pd.concat([train_df, cleaned_series], axis=1)，结果因为索引没有对齐，出现了大量NaN。
原因是pandas的concat按照索引对齐，如果cleaned_series的索引和被concat的DataFrame不一致，就会产生错位。排查方法很简单——先reset_index(drop=True)再操作：
python复制train_df = train_df.reset_index(drop=True)
cleaned_series = cleaned_series.reset_index(drop=True)
train_df['cleaned_text'] = cleaned_series
经验之谈：所有涉及DataFrame拼接或合并的操作，先重置索引再操作，能规避90%的错位问题。
4.2 先fit再split导致的数据泄漏
群里有个同学犯过这个错：他先对整个训练集做了CountVectorizer.fit_transform，再train_test_split。这看起来没问题，但实际上会让验证集的信息在拟合词表时就被模型“看到”了。
虽然对于词袋模型来说，这种泄漏的影响不如标准化或PCA那么明显，因为它只是词频统计，不包含标签信息，但原则性的错误无论如何要避免。正确的顺序是先划分文本数据，再对训练集部分fit_transform，验证集部分只用transform：
python复制train_text, val_text, y_train, y_val = train_test_split(
train_df['cleaned_text'], train_df['sentiment'], test_size=0.2, random_state=42, stratify=train_df['sentiment']
)
vectorizer = TfidfVectorizer(max_features=5000)
X_train = vectorizer.fit_transform(train_text)
X_val = vectorizer.transform(val_text)
这样验证集的特征分布完全不受训练集拟合过程影响，评估结果才真实可信。
4.3 nltk停用词下载失败的解决办法
前面提到我跑nltk.download('stopwords')时遇到网络问题，具体表现是卡在进度条不动，最后报超时错误。解决方案有两种：
- 手动下载数据包放到nltk_data目录，或者直接从其他源下载后解压
- 更省事的方案是换用
scikit-learn自带的英文停用词表，不需要额外下载：
python复制from sklearn.feature_extraction.text import ENGLISH_STOP_WORDS
不过两个停用词表有细微差异，如果你前面用了nltk的清洗结果，后面做特征时也保持一致就好，否则会有微小的度量不一致。这个问题不大，但会让人困惑为什么换了个环境结果变了。
4.4 队友环境不一致导致的“在我这能跑”
组队学习最经典的场景：队友A的代码在GitHub上推送后，队友B拉下来运行报错ModuleNotFoundError: No module named 'wordcloud'。这种问题几乎每次组队都会遇到。
建议在项目开始时就统一用同一个虚拟环境管理方案，在仓库里放requirements.txt之外，最好再加一个环境安装脚本。我们组后来约定：每周代码合并前，由组长在干净环境里跑一遍全部代码，发现问题当场解决。这个习惯让后半程的协作顺畅了很多。
5. 组队学习模式下Task 02的高效完成技巧
5.1 合理分工，但每个人必须独立跑完全流程
Datawhale组队学习的初心是“一起学习”，而不是“一起完成一个项目然后各自复制”。我们组在Task 02之前讨论过是否要分工——有人负责清洗，有人负责EDA，有人负责特征抽取，然后合并。但后来助教提醒我们：如果只负责其中一环，你学到的只是局部，出了这个项目还是不会独立做。
所以最终的决定是：每个人独立跑完全流程，但可以互相Review代码、交流思路。每周六的讨论会上，大家展示自己的EDA图表和特征选择理由，彼此提建议。这种方式学习效率非常高，因为你会看到别人是怎么处理的——比如队友发现我清洗时没有处理“don't”这类缩写，导致“don”“t”被拆成两个词，这个细节我完全没注意到。
5.2 每周打卡怎么打才有价值
Datawhale组队学习有日常打卡机制，很多同学把这个当成形式主义，随便打个卡就完事。但我的经验是，打卡内容恰恰是你整理问题的最好时机。
我会在打卡时记录三件事：这周完成了什么、卡在哪里、下周准备怎么解决。卡住的地方往往就是你的知识盲区，写下来再去看别人的笔记和代码，比自己硬磨效率高得多。Task 02期间我在打卡里记录的一个问题就是超长评论的处理策略——最终在队友的讨论帖里找到答案：可以截断至固定长度，也可以保留并缩短，具体看后续模型输入的要求。
5.3 什么时候应该主动“偷看”别人的代码
这不是鼓励抄袭。组队学习最方便的查错方式就是看队友的代码。但有个度：如果你已经独立写完整个流程，再看别人的实现来对比差异，这叫学习；如果你一行代码都没写，直接复制粘贴，那整个Task 02就白做了。
我自己的做法是：完整跑通一遍后，再去看两三个队友的仓库，重点关注几个差异点：他们有没有做词形还原、max_features是怎么选的、EDA时有没有发现我忽略的分布异常。这些差异背后的思考比代码本身值钱得多。
6. 关于Task 02我最后想说的
实际上，Task 02做出来的特征矩阵直接决定了后面模型的性能上限。我见过不少同学在Task 03发现模型精度怎么调都上不去，回头检查才发现是Task 02特征提取的参数设置有问题——比如max_features设太大导致维度爆炸，用了默认的分析器导致表情符号被拆掉等。
所以做Task 02时，我给自己定的标准不是“跑通就行”，而是“每一步都知道为什么这么做”。清洗时知道为什么去HTML标签、EDA时知道为什么看长度分布、特征提取时知道为什么用TF-IDF而不是词袋。当你能用自己的话把这些讲清楚，这个Task才算真正学透了。
另一个实际经验是：Task 02产出的所有文件命名要规范。我见过保存文件叫X_train.npz，后来覆盖了其他Task生成的文件，不得不重跑一遍整个流程。建议加上数据集版本和特征类型的后缀命名，比如train_df_v1.csv、X_train_tfidf_v1.npz，养成好习惯能为后面节省大量时间。
如果你正准备参加Datawhale的组队学习，或者刚开始做情感分析类的项目，Task 02值得你静下心来慢慢做，每一步都亲自实践一遍。把这块地基打牢，后面所有环节都会顺畅。