有些学习，像在夜里搬砖。
你很努力，屏幕很亮，浏览器标签开了十几个。SQL 题刷了一页又一页，Python 教程看了一套又一套，最近还补了 RAG、Agent、Eval。到了改简历的时候，手停在键盘上，还是只能写：熟悉 SQL，了解 Python，参与过数据分析项目。
这就有点像做了一桌菜，最后端上来一盘菜单。
我昨天写了一篇学习体检表，讲数据人到底该补 SQL、业务、AI，还是项目。那篇文章的重点是先诊断方向。今天想往下走一步：诊断完以后，怎么把学习变成项目证据。
因为数据人最常见的浪费，不是没有学习，而是学完之后，没有留下任何能被别人看见、问得住、说得清的东西。
项目证据不是“我做过什么”
很多人说自己有项目经验，其实只是有项目经历。
这两个词差一个字，面试里差很多钱。
项目经历是：我参与过用户增长分析，我做过销售报表，我接过一个画像需求，我用过 Spark 处理日志。
项目证据是：当时业务遇到了什么问题，为什么值得解决，你用了哪些数据，做过什么判断，中间遇到什么限制，最后怎么验证结果，以及这件事对业务、团队或个人工作方式产生了什么变化。
前者像签到表，证明你到过现场。后者像现场记录，证明你真的干过活。
我见过一些简历，技能栏写得像年货大街：SQL、Python、Tableau、Power BI、Spark、Flink、Airflow、dbt、LangChain、向量数据库、A/B 测试。热闹是热闹，可是往项目里一看，只有三句话：负责数据提取，完成指标看板，支持业务决策。
面试官不是庙会游客，不会因为摊位多就掏钱。他真正想知道的是：你到底解决过什么问题？
为什么学了很多，还是没有证据
第一个原因，是很多学习没有场景。
比如刷 SQL。你刷了窗口函数、递归查询、复杂 join，这当然有用。但如果它没有落到一个业务问题里，面试时就很难讲出价值。你只能说“我会写”，很难说“我用它解决了什么”。
会写 SQL 是能力。用 SQL 找出复购下降的原因，才是证据。
第二个原因，是很多学习只有动作，没有判断。
数据工作最容易被低估的地方，不是取数，而是判断。口径要不要改？异常值要不要剔除？样本期选 7 天还是 30 天？这个指标下降，是渠道变化、季节波动，还是埋点出问题？
如果你只记录“我做了报表”，那报表就只是交付物。如果你记录了这些判断，项目才开始有了你的影子。
第三个原因，是很多学习没有结果验证。
有些同学做项目，最后一句总喜欢写“支持业务决策”。这句话很安全，也很空。它像一把万能钥匙，什么门都能插一下，但哪扇门也打不开。
更好的写法，是说清楚决策之后发生了什么：业务是否调整了策略？看板是否减少了人工对账？异常监控是否提前发现了问题？哪怕结果没有变好，也可以写你如何排除了一个错误假设。
项目证据不一定都要写成“提升了 30%”。很多真实工作没那么漂亮。可是你至少要说清楚：这件事最后如何被验证。
第四个原因，是做完就散了。
很多数据人像厨房里的临时工，今天切土豆，明天洗锅，后天端盘子。忙得满头汗，但没有留下菜谱。
项目结束以后，如果不复盘，不整理，不把过程写成材料，它很快就会变成一句含糊的“我以前做过类似的”。等到面试官追问细节，你只能在记忆里翻箱倒柜，翻出一堆灰。
一个项目，至少要留下 5 类证据
如果你现在想补项目证据，可以先别急着再买课。拿出一个你已经做过的项目，按下面 5 类重新整理。
第一类，是问题证据。
它回答：为什么要做这件事？
比如“销售看板开发”这个说法太薄。你可以改成：销售团队每周手工合并 4 个渠道的数据，口径不一致，管理层无法在周会上判断区域库存和动销情况，所以需要统一指标口径和看板。
这么一写，项目就从“我做了一个看板”，变成了“我解决了一个信息不一致的问题”。
第二类，是数据证据。
它回答：你用的是什么数据，数据有什么问题？
数据人不能只说“我取了数据”。你要能说清楚数据源、字段、口径、更新频率、缺失情况、异常处理。哪怕项目很小，只要你说得清楚，别人就知道你不是只会复制 SQL。
第三类，是判断证据。
它回答：过程中你做过什么取舍？
比如指标口径怎么定，时间窗口怎么选，异常值怎么处理，维度为什么这样拆。很多人觉得这些太细，不值得写。其实恰恰相反，这些地方最能体现一个数据人的工作质量。
因为工具会越来越便宜，判断不会。
第四类，是结果证据。
它回答：最后怎么证明这件事有用？
结果可以是业务指标变化，也可以是效率变化、风险降低、流程减少、问题定位更快。不要硬编漂亮数字。如果没有量化结果，也可以写“从每周人工汇总，改为每日自动更新；业务会议从看数据变成讨论行动”。
真实，比漂亮重要。
第五类，是表达证据。
它回答：你能不能把这件事讲给别人听？
一个项目如果只能写在简历上，不能在 3 分钟内讲清楚，还不算真正属于你。你需要准备一个短版本、一个长版本、一个追问版本。
短版本讲问题和结果。长版本讲过程和取舍。追问版本讲细节和反思。
这三版准备好了，面试时心就会稳很多。不是因为你背熟了，而是因为你真的把事情想过一遍。
把学习改造成项目证据
如果你手里暂时没有大项目，也不用太慌。很多项目证据可以从小场景长出来。
关键不是项目有多大，而是它是否完整。
你学 SQL，就别只刷题。可以找一个公开数据集，设计一个真实问题：用户留存为什么下降？销售额波动来自哪个品类？某个活动到底有没有带来新增？
你学 Python，就别只跟着教程画图。可以做一个自动化分析脚本：读取原始数据，清洗字段，生成异常检查，输出一页分析结果。
你学 AI Agent，就别只做一个聊天 Demo。可以让它完成一个具体的数据工作流：读取业务口径文档，生成 SQL 草稿，检查指标解释，再用一组样例问题做评估。
你学数据建模，就别只背星型模型和雪花模型。可以拿一个订单业务，画出事实表、维度表、指标口径，再说明为什么这样拆。
每学一个东西，都问 5 个问题：
- 它解决什么业务问题？
- 输入数据从哪来？
- 中间做了什么关键判断？
- 结果怎么验证？
- 最后能沉淀成什么材料？
这 5 个问题答完，学习就不再是“我看过”，而开始变成“我做过”。
简历上应该怎么写
我们拿一个很常见的写法举例。
原来是：
负责销售数据看板开发，支持业务决策。
这句话没有错，但太像白开水。你可以改成：
针对销售团队多渠道数据口径不一致的问题，梳理订单、库存、渠道 3 类数据源，统一 12 个核心指标口径，搭建每日更新的销售分析看板，帮助区域负责人在周会前定位库存异常和动销变化。
这就好多了。
它不一定完美，但至少出现了问题、数据、动作、结果。面试官可以顺着问：12 个指标是什么？口径怎么定？库存异常怎么识别？看板上线后谁在用？
能被追问，不是坏事。怕的是连追问入口都没有。
再比如，原来是：
使用 Python 完成数据清洗和可视化。
可以改成：
为减少人工整理招聘数据的时间，使用 Python 编写清洗脚本，对岗位名称、城市、薪资区间和技能词进行标准化处理，并输出岗位技能分布图，用于比较数据分析师和数据工程师的能力要求差异。
这句话里的 Python 只是工具，真正的价值是“减少人工整理”和“比较岗位能力要求”。
数据人的简历，不要只写工具名。工具名是刀，项目证据是切出来的菜。
如果你今天只做一件事
我建议你别急着打开新课程。
先打开自己的简历，挑一个最重要的项目，按这张表补一遍：
| 证据类型 | 你要回答的问题 | 简历或面试里的呈现 |
|---|---|---|
| 问题证据 | 为什么要做？ | 业务背景、痛点、目标 |
| 数据证据 | 用了什么数据？ | 数据源、字段、口径、质量问题 |
| 判断证据 | 做过什么取舍？ | 指标定义、异常处理、分析路径 |
| 结果证据 | 如何证明有用？ | 效率、风险、指标、流程变化 |
| 表达证据 | 能不能讲清楚？ | 3 分钟版本、追问版本、复盘版本 |
写完以后，你会发现一个有意思的现象：有些你以为很普通的项目，其实能讲出价值；有些你以为很高级的技术词，反而没有多少证据。
这就是复盘的意义。
不是给自己贴金，而是把散落在日常工作里的判断，一粒一粒拾起来。
学习不是为了显得努力
数据行业有一种隐秘的焦虑：大家都觉得自己还不够。
不够懂 AI，不够懂工程，不够懂业务，不够懂算法。于是我们不停往收藏夹里塞资料，像冬天囤白菜。白菜囤多了当然安心，可它不会自己变成一顿饭。
学习也是一样。
真正能改变你处境的，不是“我又学了一门课”，而是“我能拿出一件说得清、问不倒、有结果的东西”。
如果你想继续补课，我建议你先从项目证据开始。因为它连接了学习、简历、面试、晋升和谈薪。SQL、Python、AI、数据建模，最后都要落到一件事上：你能不能解决真实问题，并把这个过程讲清楚。
我在拾穗数据知识库里，也会继续把数据人的项目复盘模板、简历改写模板、面试表达模板整理出来。不是为了让大家把简历写得更热闹，而是让真正做过的事，不再被三句空话埋掉。
如果你现在正在改简历，可以先做一个小动作：找出一个项目，把它从“我做过什么”，改写成“我解决了什么”。
这一步很小。
但很多人的职业变化，就是从这一步开始的。
如果你正在整理项目经历，也可以直接加我微信聊聊。微信号：shisuidata，加的时候备注一下「项目证据」。