跟着 DoorDash 配送预测项目走一遍，我终于搞懂作品集为啥没人看

跟着 DoorDash 配送预测项目走一遍，我终于搞懂作品集为啥没人看

很多转行做数据科学的朋友都有个困惑：GitHub 上项目挂了一堆，简历也写了，怎么面试就是没下文？最近 KDNuggets 上有篇文章把这事讲透了——能帮你拿到 offer 的项目，跟教程里跑通的项目，根本不是一回事。

好项目的起点，是业务问题不是算法

文章拿 DoorDash 外卖配送时长预测这个免费项目举例。同样是预测配送时间，项目标题写成「Delivery Time Prediction」和「XGBoost Regression Demo」，招聘经理看到的完全是两个东西：前者告诉他「这个人能帮公司解决问题」，后者告诉他「这人跟着教程敲过代码」。方向选错，后面全白搭。

真正的项目应该从业务问题出发，到业务建议收尾，中间每一步都摆出来给人看。从原始数据到部署上线，这一整套过程才是简历证明不了、notebook 也装不出来的东西。

九步走完，项目才完整

文章把完整项目拆成了九个阶段：定义业务问题、用 SQL 取数、Python 清洗、探索性分析、特征工程、建模、评估，最后部署成 API 和仪表盘，给出可落地的建议。每一步都是一章故事，招聘经理能自己看、自己验证。

几个细节值得划重点：

第一，取数别偷懒。真实公司里数据都躺在数据库里，你得自己写 SQL 把表 join 出来，而不是默默 load 一个 CSV。把「我用了什么查询、过滤了什么脏数据、怎么聚合的」写清楚，这本身就是亮点。

第二，清洗是重头戏。文章直言，数据清洗占了真实数据科学工作 60% 到 80% 的时间，跳过这步是最明显的「新手信号」。DoorDash 项目里，计算目标变量（配送时长=送达时间-下单时间）、修正类型、处理缺失值和不可能值，每一步都值得展示。

第三，收尾要有「人话」。模型跑完不是终点，得把它部署成能用的东西，最后落到一句业务建议上。比如「雨天高峰期把骑手调度前置 15 分钟，预计能压多少超时单」——这种结论才是业务方愿意买单的东西。

一个模板，套所有项目

这篇文章最有价值的点，是它给了一个可以反复套用的模板：不管你做的是用户流失预测、风控反欺诈还是库存预测，都可以按这九步走一遍。框架是死的，但每走一步你都得想清楚「这一步在解决什么业务问题」，项目自然就有了灵魂。

说到底，面试官想看的不是你会不会调参，而是你能不能把一个模糊的业务问题，拆成一条能落地、能验证、能讲清楚的数据链路。作品集里放三个这样的完整项目，比挂三十个半成品有用得多。