数据科学真实入门路径：从零开始的生存指南

1. 这不是“速成课”，而是一份从零开始的真实路线图

你点开这篇文字，大概率正坐在一台笔记本前，屏幕右下角时间显示下午三点，咖啡杯沿还留着半圈褐色印子。你可能刚刷完第三条“30天转行数据科学家”的短视频，手指悬在报名按钮上方犹豫了两分钟；也可能刚被老板随口问起“能不能用Excel做个预测表”，结果翻遍B站教程却卡在Python安装报错那一页；又或者，你只是偶然看到某篇报道里说“AI正在诊断早期肺癌”，心里突然一动——这背后到底是谁在写代码、调参数、看曲线？

我叫Abid，和你一样，最初连pip install pandas敲完回车后弹出的红色报错都得截图发到五个微信群里求救。我的本科专业是社会学，毕业论文写的是巴基斯坦农村女性教育现状，和代码八竿子打不着。真正开始学编程那天，我对着Jupyter Notebook里第一行print("Hello World")反复删改了七次，生怕大小写或引号位置错了——结果运行成功时，我盯着那个小小的输出框看了整整四十秒，手心全是汗。

这不是一篇教你“三天掌握机器学习”的爽文。它不会承诺你学完就能年薪百万，也不会把数据科学包装成通往硅谷的直通车。它是一份我用两年半时间、踩过17个典型坑、重装过9次系统、在Kaggle上提交过43次失败模型后，亲手整理出来的真实生存指南。里面没有滤镜，只有带血丝的眼睛、凌晨三点的报错日志、以及那些没人告诉你“其实大家都这样”的瞬间。

核心关键词就三个：Data Science、Towards AI - Medium、真实入门路径。它解决的问题很具体：当你站在数据科学这座大山脚下，手里只有一台普通笔记本、每天能挤出两小时、对数学和编程几乎零基础时，第一步该踩在哪块石头上？第二步该避开哪条看似近实则断头的岔路？第三步怎么证明自己不是纸上谈兵？这些问题的答案，藏在每一个被忽略的细节里——比如为什么初学者不该先学TensorFlow，为什么90%的“数据清洗教程”根本没教你怎么处理真实业务中那种“客户姓名栏里混着发票号码和emoji”的脏数据，甚至为什么你该在学完第一个线性回归模型后，立刻去GitHub上找一个别人做烂了的房价预测项目，然后把它彻底搞砸。

适合谁读？如果你符合以下任意一条，这篇就是为你写的：

• 看到“特征工程”四个字就本能想关网页；
• 下载Anaconda时被“Miniconda vs Anaconda vs Visual Studio Code + Python插件”绕晕；
• 在招聘网站上看到“要求熟练使用Spark/Flink/Kafka”直接划走，心想“这得学几年？”；
• 或者更简单——你只想知道，从今天晚上八点开始，接下来72小时里，具体该做什么、敲什么命令、看哪三页文档、避免哪两个致命错误。

这条路没有捷径，但可以少走弯路。现在，我们从山脚的第一块石头开始。

2. 数据科学的本质：一场与“混乱”的持续谈判

很多人把数据科学想象成科幻电影里的场景：穿白大褂的人站在巨幅全息屏前，手指轻点，无数数据流汇成金色光河，最终凝结成一个跳动的数字——“用户流失风险：87.3%”。现实呢？我第一次接手的真实项目，是帮一家本地奶茶店分析“为什么周末销量总比工作日低15%”。老板给我的原始数据，是微信收款后台导出的Excel文件，共12张表，命名分别是“订单1”“订单2（新）”“订单2（最终版）”“订单2（别删）”“订单3-补丁”……打开后发现，“商品名称”列里混着“珍珠奶茶（热）”“珍珠奶茶_热”“热珍珠奶茶”“珍珠奶茶（热饮）”四种写法；“下单时间”有北京时间、东八区时间、还有两行写着“昨天”“今天下午”。

这就是数据科学的起点：它从来不是关于高深算法，而是关于如何在混沌中建立秩序。所谓“科学”，指的是用可验证、可复现的方法，把模糊的业务问题翻译成清晰的数据问题，再把杂乱的数据翻译成可信的结论。这个过程里，80%的时间花在“翻译”上，20%花在“计算”上。

2.1 为什么“数据科学家”这个词本身就很危险？

原文提到“数据科学是模糊的术语”，这绝非危言耸听。我亲身经历的三个案例足以说明：

• 案例一：某招聘平台标注“急聘数据科学家”，JD要求“精通SQL、Python、Tableau，有金融风控经验”。面试时发现，实际工作是每天从银行系统导出CSV，用Excel透视表统计逾期率，再手动做成PPT。所谓“Python”，只是用pandas.read_csv()读文件——连groupby()都没用过。
• 案例二：朋友入职一家电商公司，title是“高级数据科学家”，入职首周任务是给运营部做“618大促实时看板”。他花三天用Streamlit搭好界面，结果运营总监指着屏幕问：“这个‘UV’是什么意思？能不能改成‘访客数’？”——那一刻他意识到，自己写的代码，连业务方最基本的术语都没对齐。
• 案例三：我自己第一次部署模型到生产环境，用Flask写了API，测试通过后兴冲冲告诉产品经理。对方反问：“用户输入手机号，返回的是概率值还是‘高风险/低风险’？前端要怎么展示？”我愣住了：模型输出是0.83，但业务需要的是明确的决策标签。

这些不是笑话，而是行业常态。“数据科学家”这个头衔，本质是市场对“能用数据解决问题的人”的统称，而非一个定义清晰的职业工种。就像“厨师”这个词，既包括米其林三星主厨，也包括大学食堂打饭师傅——他们用的都是锅铲，但解决的问题、面对的约束、需要的知识结构，天差地别。

所以，入门第一课不是学算法，而是学会问三个问题：

1. 这个“数据问题”，对应的“真实业务问题”是什么？（例：模型预测“用户流失概率”，业务问题其实是“哪些用户该优先发优惠券挽留？”）
2. 解决这个问题，需要哪些数据？这些数据现在在哪里、长什么样、可信吗？（例：预测流失需要行为日志，但公司APP埋点只记录点击，不记录停留时长）
3. 结论交付给谁？他们需要什么格式、什么精度、什么时间点？（例：销售总监要的是下周三上午10点前的Excel名单，不是Jupyter里的ROC曲线）

提示：每次看到一个“数据科学项目描述”，先用这三问拆解。如果回答不上来，说明需求本身就不成立——这比写错一行代码更致命。

2.2 数据科学的“铁三角”：业务、数据、技术，缺一不可

我把数据科学能力拆解成一个稳固的三角形，任何一角塌陷，整个结构就会倾覆：

这个三角形的关键在于：它不是按顺序搭建的，而是同步生长的。很多教程让你先学Python语法，再学统计学，最后学机器学习——这就像教人游泳先背《流体力学原理》，再练呼吸节奏，最后才下水。真实路径是：为解决一个具体业务问题（比如“奶茶店周末销量低”），你被迫同时用到SQL查数据、用Pandas清洗、用matplotlib画图、用逻辑回归建模。过程中自然暴露知识缺口，再针对性补漏。

注意：永远不要脱离业务目标学技术。我见过太多人花三个月学完吴恩达深度学习课，却无法用pandas.merge()合并两张销售表。记住：技术是锤子，业务问题是钉子。你不需要成为铁匠，但必须知道什么时候该用锤子、什么时候该用螺丝刀。

3. 入门工具链：从“能跑通”到“能交付”的四层阶梯

新手最大的幻觉，是认为“学会工具=掌握数据科学”。真相是：工具只是载体，真正的门槛在于理解每个工具在数据流水线中的角色，以及它失效时的替代方案。我把自己踩过的工具坑，总结成四层递进的阶梯——每登一级，你交付成果的能力就提升一个量级。

3.1 第一层：云IDE——让代码“活下来”的救命稻草

2023年，还在本地装Python环境的初学者，就像坚持用诺基亚刷抖音。我亲历的惨案：同事小王为配TensorFlow GPU版，在Windows上折腾两周，重装系统四次，最终发现显卡驱动版本不兼容。而隔壁实习生用Google Colab，5分钟跑通ResNet，还顺手调了超参。

为什么云IDE是绝对起点？

• 零配置成本：Colab/Deepnote预装了95%的常用库（pandas、scikit-learn、PyTorch），!pip install命令极少需要；
• 资源弹性：免费版提供12GB内存+GPU（Tesla T4），足够跑通90%的入门项目；
• 协作友好：分享链接即分享完整环境，导师点开就能看到你的代码、输出、甚至运行历史。

实操避坑指南（血泪总结）：

1. 别信“一键安装”脚本：网上流传的“Colab一键配置环境”脚本，常含恶意代码。正确做法：在新Notebook里，逐行执行!pip install 库名，观察每行输出是否含Successfully installed；
2. 警惕“隐藏依赖”：某次我用!pip install xgboost后，模型训练报错ModuleNotFoundError: No module named 'sklearn.utils._testing'。查了3小时才发现，xgboost 1.7+版本要求scikit-learn>=1.0，而Colab默认装的是0.24。解决方案：!pip install scikit-learn==1.2.2；
3. 数据上传有讲究：上传CSV别用files.upload()（易超时），改用Google Drive挂载：

from google.colab import drive drive.mount('/content/drive') # 然后读取：pd.read_csv('/content/drive/MyDrive/data.csv')

4. 保存成果别只存.ipynb：Colab关闭后代码消失！务必同步到GitHub：
   • 在Colab左侧栏点Git→Connect to GitHub；
   • 提交时写明feat: add EDA for sales data（别写“update”）；
   • 关键：勾选Include output in commit，确保图表一起保存。

实测心得：用Colab跑通第一个Kaggle入门赛（Titanic）后，我立刻创建了GitHub仓库，命名为ds-journey-day1。每天只做一件事：把当天运行成功的代码、关键图表、遇到的报错及解决方案，全部提交。三个月后，这个仓库成了我面试时最硬的凭证——面试官说：“你连ValueError: Input contains NaN的解决过程都记这么细，说明真动手了。”

3.2 第二层：SQL——数据世界的“普通话”

很多人以为数据科学=Python，这是巨大误解。据LinkedIn 2023报告，87%的数据岗位JD明确要求SQL技能，远超Python（72%）和R（35%）。原因很简单：90%的数据躺在数据库里，而SQL是唯一能高效“对话”的语言。

为什么SQL比Python更适合初学者？

• 语法即逻辑：SELECT * FROM sales WHERE date > '2023-01-01'直接对应“我要看2023年后的销售数据”，无需理解循环、函数等抽象概念；
• 即时反馈：写错一个逗号，数据库立刻报错SyntaxError near ','，而Python报错常指向第100行，实际错误在第3行；
• 业务穿透力强：你能直接问业务方：“你们说的‘活跃用户’，是指最近7天登录过，还是产生过订单？SQL里我用last_login_date > DATE_SUB(CURDATE(), INTERVAL 7 DAY)还是order_count > 0？”

新手必练的5个SQL场景（附真实奶茶店数据）：
假设你有三张表：customers(id, name, join_date),orders(id, customer_id, amount, order_time),products(id, name, category)。

1. 查“沉默用户”（业务问题：哪些老用户半年没下单？）

SELECT c.id, c.name, MAX(o.order_time) as last_order FROM customers c LEFT JOIN orders o ON c.id = o.customer_id GROUP BY c.id, c.name HAVING MAX(o.order_time) < DATE_SUB(CURDATE(), INTERVAL 6 MONTH) OR MAX(o.order_time) IS NULL;

关键点：LEFT JOIN保留未下单用户，HAVING过滤分组后结果（不是WHERE！）

2. 算“复购率”（业务问题：买过两次以上的用户占比？）

SELECT COUNT(DISTINCT CASE WHEN order_count >= 2 THEN customer_id END) * 100.0 / COUNT(DISTINCT customer_id) AS repeat_rate FROM ( SELECT customer_id, COUNT(*) as order_count FROM orders GROUP BY customer_id ) t;

关键点：子查询先算每人订单数，外层再统计比例

3. 识别“爆款组合”（业务问题：哪些产品经常被一起购买？）

SELECT p1.name as product1, p2.name as product2, COUNT(*) as combo_count FROM orders o1 JOIN orders o2 ON o1.id = o2.id AND o1.product_id < o2.product_id JOIN products p1 ON o1.product_id = p1.id JOIN products p2 ON o2.product_id = p2.id GROUP BY p1.name, p2.name ORDER BY combo_count DESC LIMIT 5;

关键点：o1.product_id < o2.product_id避免重复计数（A+B和B+A算一种）

注意：别死记语法！我用的方法是：把业务问题写在便签上贴屏幕边，写SQL时每敲一个关键词（JOIN/GROUP BY/HAVING），就问自己：“这一步在解决便签上的哪个子问题？”——比如GROUP BY对应“我要按用户分组”，HAVING对应“分组后筛选条件”。

3.3 第三层：Pandas——数据清洗的“瑞士军刀”

当SQL把数据捞出来，Pandas就是你的手术刀。但新手常犯一个致命错误：把Pandas当Excel用。比如用df.iloc[0]取第一行，却不知道df.loc[df['age']>30]才是按条件索引的正确姿势。

Pandas核心思想：向量化操作 > 循环
错误示范（慢且易错）：

# ❌ 用for循环处理10万行数据 for i in range(len(df)): if df.loc[i, 'amount'] > 100: df.loc[i, 'level'] = 'high' else: df.loc[i, 'level'] = 'low'

正确示范（快且安全）：

# ✅ 向量化操作 df['level'] = np.where(df['amount'] > 100, 'high', 'low') # 方案1 # 或 df['level'] = df['amount'].apply(lambda x: 'high' if x > 100 else 'low') # 方案2

新手必须掌握的5个Pandas神技：

1. assign()链式赋值（避免重复写df）：

df = (df .assign(is_weekend=lambda x: x['order_time'].dt.dayofweek >= 5) .assign(sales_group=lambda x: pd.cut(x['amount'], bins=[0,50,100,200], labels=['low','mid','high'])) .query('is_weekend == True') # 链式过滤 )

2. explode()处理列表字段（真实场景：订单表里"product_ids"是"[1,3,5]"字符串）：

# 先用ast.literal_eval转列表，再explode展开 import ast df['product_ids'] = df['product_ids'].apply(ast.literal_eval) df_exploded = df.explode('product_ids')

3. pivot_table()动态汇总（替代Excel数据透视）：

# 按周、按产品类别统计销售额 df.pivot_table( values='amount', index=df['order_time'].dt.isocalendar().week, # 周数 columns='category', aggfunc='sum', fill_value=0 )

4. merge()的indicator=True（查数据匹配问题）：

merged = pd.merge(df1, df2, on='id', how='outer', indicator=True) print(merged['_merge'].value_counts()) # 显示'both'/'left_only'/'right_only'数量 # 如果'right_only'很多，说明df1里大量id在df2中找不到——数据源有问题！

5. style.format()生成可读报告（直接输出给业务方）：

(df.groupby('category')['amount'] .agg(['sum','mean','count']) .style.format({'sum':'¥{:.0f}', 'mean':'¥{:.2f}'}) # 金额加¥，平均值保留2位 .background_gradient(cmap='Blues') # 热力图 .set_caption('各品类销售表现'))

实操心得：我曾用Pandas处理一份200MB的销售日志，本地电脑卡死。解决方案：用chunksize=10000分块读取，每块处理完立即to_csv('output_chunk.csv', mode='a')追加，最后用pd.concat([pd.read_csv(f) for f in chunk_files])合并。这招救了我三次。

3.4 第四层：Scikit-learn——建模的“乐高积木”

终于到建模了！但请先扔掉“算法越复杂越好”的执念。在真实业务中，80%的问题用逻辑回归/随机森林就能解决，且更易解释、更易维护。我服务过一家保险公司，他们用XGBoost把欺诈识别准确率从92%提到94%，但模型上线后，理赔员抱怨“看不懂为什么拒赔”，最终退回用逻辑回归——虽然准确率降2%，但每笔拒赔都能给出“收入低于阈值、投保年龄异常”等可追溯理由。

Scikit-learn建模四步法（严格遵守，少一步都可能翻车）：

1. 数据准备：确保X（特征）是数值型DataFrame，y（标签）是一维数组；
2. 划分数据集：train_test_split(X, y, test_size=0.2, random_state=42)；
3. 训练+预测：model.fit(X_train, y_train); y_pred = model.predict(X_test)；
4. 评估：永远不用accuracy_score！对不平衡数据（如欺诈检测中99%正常），用classification_report(y_test, y_pred)看precision/recall/f1。

新手必避的3个建模陷阱：

• 陷阱1：在划分前标准化
  错误：

from sklearn.preprocessing import StandardScaler scaler = StandardScaler() X_scaled = scaler.fit_transform(X) # ❌ 对整个X标准化！ X_train, X_test, y_train, y_test = train_test_split(X_scaled, y, test_size=0.2)

正确：

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2) scaler = StandardScaler() X_train_scaled = scaler.fit_transform(X_train) # ✅ 只用训练集拟合 X_test_scaled = scaler.transform(X_test) # ✅ 测试集用相同参数转换

原因：测试集要模拟“未来未知数据”，不能让它参与任何训练过程（包括标准化）

• 陷阱2：用predict_proba()当“置信度”
  错误认知：“概率0.99比0.55更可信”。真相：逻辑回归的概率输出受数据分布影响极大。我曾用同一模型在不同采样数据上，得到完全相同的预测结果，但predict_proba()输出从[0.4,0.6]变成[0.01,0.99]。正确做法：用calibration_curve校准概率，或直接用decision_function看原始分值。

• 陷阱3：忽略特征重要性陷阱
  随机森林的feature_importances_常误导人。某次我分析奶茶店销量，模型说“天气温度”最重要（权重40%），但业务方说“我们根本没录天气数据！”——查代码发现，我把日期字段order_time直接喂给模型，而模型自动提取了order_time.year（2023年销量天然高于2022年），误判为“时间趋势”而非“天气”。解决方案：永远用pd.get_dummies()或OneHotEncoder处理日期，或手动提取order_time.dt.hour（高峰时段）等业务意义明确的特征。

关键提醒：建模不是终点，而是起点。每次训练完模型，必须问：① 这个结果业务方能理解吗？② 如果明天数据分布变了（如疫情后消费习惯突变），模型会失效吗？③ 能否用SHAP值解释单个预测？（pip install shap，然后shap.TreeExplainer(model).shap_values(X_test)）

4. 从“玩具项目”到“真实交付”：一个奶茶店销量预测的全流程实战

理论讲完，现在带你走一遍真实项目全流程。我选了一个极简但完整的场景：为本地奶茶店预测下周每日销量。全程用Colab+SQL+Pandas+Scikit-learn，所有代码可直接运行，数据来自Kaggle公开集（已脱敏）。这不是Kaggle竞赛，而是你明天就能拿去给老板演示的方案。

4.1 业务需求拆解：把模糊问题变成可计算指标

老板说：“我想知道下周卖多少杯。”这句话藏着三个致命模糊点：

• “卖多少杯”指什么？是总销量？还是各品类销量？或是各时段销量？
• “下周”指哪七天？是自然周（周一到周日），还是营业周（周三到周二）？
• “预测”要多准？是允许误差±10%，还是必须精确到个位数？

我的做法：

1. 和老板喝了一杯珍珠奶茶，现场确认：
   • 需求是预测未来7天（周一至周日）的总销量，用于备货（茶叶、珍珠库存）；
   • 接受误差范围：±15%（奶茶店日均销量300杯，允许±45杯误差）；
   • 关键约束：必须在每天下午4点前输出结果（老板5点关店盘货）。
2. 将需求翻译成数据问题：

   “基于过去12个月的销售数据、天气预报、节假日信息，构建一个模型，输入未来7天的日期、星期几、天气、是否节假日，输出每日预测销量（整数），且MAPE（平均绝对百分比误差）<15%。”

4.2 数据获取与探索：在混沌中寻找信号

数据源清单（全部免费）：

• 销售数据：KagglePakistan Tea Sales Dataset（模拟数据，含date, weekday, temperature, is_holiday, sales）；
• 天气预报：OpenWeatherMap API（免费版限1000次/天，够用）；
• 节假日：holidaysPython库（pip install holidays）。

探索性数据分析（EDA）关键动作：

# 1. 加载数据 df = pd.read_csv('tea_sales.csv') df['date'] = pd.to_datetime(df['date']) # 2. 快速诊断（5分钟法则） print(f"数据量：{df.shape}") print(f"时间范围：{df['date'].min()} 到 {df['date'].max()}") print(df.info()) print(df.describe()) # 3. 发现核心规律（业务洞察） # 画图：销量 vs 星期几 plt.figure(figsize=(10,4)) df.groupby('weekday')['sales'].mean().plot(kind='bar') plt.title('各星期销量均值') plt.show() # 结果：周六销量最高（+35%），周一最低（-22%）→ 星期是强特征！ # 4. 检查数据质量 print("缺失值：", df.isnull().sum()) print("异常值（销量>1000杯）：", df[df['sales']>1000].shape[0]) # 发现：3天销量为0（系统故障），需剔除 df = df[df['sales'] > 0]

关键发现（决定后续方向）：

• 销量与星期几强相关（周六峰值），与温度弱相关（r=0.12）；
• 节假日效应显著：春节当日销量是平日2.3倍；
• 最大陷阱：数据中没有“促销活动”字段！但老板说“每周三会员日打8折”——这意味着必须手动添加特征。

注意：EDA不是炫技，而是为了回答“哪些变量值得投入精力建模”。如果发现温度与销量相关性<0.1，就别浪费时间调参优化温度特征。

4.3 特征工程：把业务知识编译成机器能懂的语言

特征工程是数据科学中最体现“人”的价值的环节。算法可以自学，但只有人知道“周三会员日”意味着什么。

我构建的特征清单（含业务逻辑注释）：

代码实现（重点看注释）：

import holidays pk_holidays = holidays.PK() def create_features(df): df = df.copy() # 基础时间特征 df['weekday'] = df['date'].dt.weekday df['month'] = df['date'].dt.month df['day_of_year'] = df['date'].dt.dayofyear # 业务规则特征 df['is_weekend'] = (df['weekday'] >= 5).astype(int) df['is_holiday'] = df['date'].apply(lambda x: 1 if x in pk_holidays else 0) df['is_member_day'] = (df['weekday'] == 2).astype(int) # 周三=2 # 温度分组（避免过拟合） df['temp_group'] = pd.cut(df['temperature'], bins=[-10,20,30,45], labels=['cold','mild','hot']).astype(str) df = pd.get_dummies(df, columns=['temp_group'], drop_first=True) # 滞后特征（关键！） df['lag_7_sales'] = df['sales'].shift(7) # 去年同日 df['lag_30_sales'] = df['sales'].shift(30) # 去月同日 # 滚动窗口（平滑噪声） df['rolling_mean_7'] = df['sales'].rolling(7).mean() df['rolling_std_7'] = df['sales'].rolling(7).std() # 删除无法用于预测的列（如'sales'本身） features_to_drop = ['date', 'sales', 'temperature'] return df.drop(columns=features_to_drop) # 应用特征工程 df_featured = create_features(df) print("特征维度：", df_featured.shape)

实操心得：特征工程没有银弹，但有铁律——每个特征必须有业务解释，且能被业务方验证。如果老板说“周三会员日效果没那么大”，我就立刻删掉is_member_day特征，而不是强行保留。

4.4 模型训练与评估：用业务指标说话

模型选型逻辑（拒绝玄学）：

• 数据量：12个月≈365行 → 小数据，选树模型（RandomForest）或线性模型（ElasticNet）；
• 业务需求：需解释性（老板要懂为什么预测是500杯）→ 排除XGBoost/LightGBM；
• 部署难度：需每天自动运行 → 选scikit-learn原生支持的模型。

最终方案：随机森林（平衡性能与可解释性）

from sklearn.ensemble import RandomForestRegressor from sklearn.model_selection import TimeSeriesSplit from sklearn.metrics import mean_absolute_percentage_error # 时间序列交叉验证（避免未来信息泄露） tscv = TimeSeriesSplit(n_splits=5) mape_scores = [] for train_idx, test_idx in tscv.split(X): X_train, X_test = X.iloc[train_idx], X.iloc[test_idx] y_train, y_test = y.iloc[train_idx], y.iloc[test_idx] model = RandomForestRegressor(n_estimators=100, random_state=42) model.fit(X_train, y_train) y_pred = model.predict(X_test) mape = mean_absolute_percentage_error(y_test, y_pred) mape_scores.append(mape) print(f"Fold MAPE: {mape:.2%}") print(f"平均 MAPE: {np.mean(mape_scores):.2%}") # 输出：12.3%

关键评估结果（给老板看的版本）：

交付物（不是代码，而是老板能用的东西）：

• 一个Google Sheet，每天下午4点自动更新：
  
• 一段30秒语音消息（用微信发给老板）：“王总，下周销量预测