即刻App年轻人的同好社区
下载
置顶最近髂骨拉伤，去做运动康复，才知道自己一直以为的“骨盆前倾”，其实更复杂一点：右侧前倾、左侧后旋，连带着右侧吸气不足，右侧支撑也没有左侧稳定。
听到这个结论时，我原本以为自己会有一种“终于找到原因了”的惊喜。毕竟运动中右侧身体那些长期说不清的不稳定，终于有了解释。
但我仔细感受了一下，发现第一反应并不是惊喜，而是懊恼：怎么会这样？为什么我一直都没有发现？
更有趣的是，当我看见这份懊恼的时候，又立刻多了一层无奈：原来那个挑剔自己的声音还是这么快，一不注意，又成了第一反应。
几年前，我第一次真正看见这个严厉的超我时，很讨厌它。因为身体不舒服时，它从不说“你辛苦了”，而是说“你怎么又出问题了”；情绪失控时，它也不问“你是不是委屈了”，而是质问“你怎么又没控制好”。
直到后来有一次发火后，我想了很久都不明白原因，再一点点往回捋，才发现我其实不是在冲着面前的人发火，而是那个场景里的“被挑剔感”，一下子勾出了我积累很久的委屈。
在心里看见那个一边委屈、一边还很努力的小女孩的那一刻，可能是我这几年学习心理学后，最接近“开悟”的瞬间。
我开始把很多事情串联起来：原来自己这些年的许多选择，其实都在指向同一件事——人生的第一目的，正在从“我要做到什么、证明什么、得到什么结果”，慢慢转向“我能不能更支持自己一点”。
选择对自己抱有善意的环境，选择自己对自己多一点好奇，给自己耐心去看见每个情绪背后的需要，也开始学习给自己放松和放空的时间。
这次就很开心的点在于，不只是我终于知道了身体哪里不稳定，而是当那个挑剔的声音再次出现时，我没有立刻被它带走。
我已经开始能看见它，甚至能自嘲一下它，然后试着和它好好相处。
彻底消灭那个严厉的“超我”应该是不可能了，毕竟我今天达到的社会价值也都是它给的礼物。
但只要能在它出现的时候，不再只相信它，就是一件很美好的事啊！
听到这个结论时，我原本以为自己会有一种“终于找到原因了”的惊喜。毕竟运动中右侧身体那些长期说不清的不稳定，终于有了解释。
但我仔细感受了一下，发现第一反应并不是惊喜，而是懊恼：怎么会这样？为什么我一直都没有发现？
更有趣的是，当我看见这份懊恼的时候，又立刻多了一层无奈：原来那个挑剔自己的声音还是这么快，一不注意，又成了第一反应。
几年前，我第一次真正看见这个严厉的超我时，很讨厌它。因为身体不舒服时，它从不说“你辛苦了”，而是说“你怎么又出问题了”；情绪失控时，它也不问“你是不是委屈了”，而是质问“你怎么又没控制好”。
直到后来有一次发火后，我想了很久都不明白原因，再一点点往回捋，才发现我其实不是在冲着面前的人发火，而是那个场景里的“被挑剔感”，一下子勾出了我积累很久的委屈。
在心里看见那个一边委屈、一边还很努力的小女孩的那一刻，可能是我这几年学习心理学后，最接近“开悟”的瞬间。
我开始把很多事情串联起来：原来自己这些年的许多选择，其实都在指向同一件事——人生的第一目的，正在从“我要做到什么、证明什么、得到什么结果”，慢慢转向“我能不能更支持自己一点”。
选择对自己抱有善意的环境，选择自己对自己多一点好奇，给自己耐心去看见每个情绪背后的需要，也开始学习给自己放松和放空的时间。
这次就很开心的点在于，不只是我终于知道了身体哪里不稳定，而是当那个挑剔的声音再次出现时，我没有立刻被它带走。
我已经开始能看见它，甚至能自嘲一下它，然后试着和它好好相处。
彻底消灭那个严厉的“超我”应该是不可能了，毕竟我今天达到的社会价值也都是它给的礼物。
但只要能在它出现的时候，不再只相信它，就是一件很美好的事啊！
14 00
自动化任务真的是个坑🥹表面看每天、每周都是 AI 自己跑，四舍五入等于没工作量，实际上后台任务一个都不能断。
随便挂一个就要排查半天，没报错的时候还会忍不住想：不会哪里偷偷挂了吧？省掉了干活时间，新增了一堆心里负债🥹
直到昨晚把一部分例行任务部署到公司内网，终于不用本地养着一堆定时任务，今早起床才感觉自己又活过来了
每个工作的困难都能让我离入门程序员又进一步🥹
随便挂一个就要排查半天，没报错的时候还会忍不住想：不会哪里偷偷挂了吧？省掉了干活时间，新增了一堆心里负债🥹
直到昨晚把一部分例行任务部署到公司内网，终于不用本地养着一堆定时任务，今早起床才感觉自己又活过来了
每个工作的困难都能让我离入门程序员又进一步🥹
15 00
最近遇到一个让我非常困惑的职场问题：如果一个数据分析师已经满负荷工作了，怎么证明“需求延期不是效率低，而是需求真的超过了一个人的产能”？
我们是个新项目，目前只有我一个数据分析师。
我要同时支持产品、运营、市场和老板，负责产品埋点、日常取数、数据口径、数据问题排查，以及老板希望重点产出的专项分析。
最魔幻的是，我自己对“分析效率”的认知其实已经非常高了。
按照我以前工作的经验，一个比较完整的大型分析项目，全人力投入两周出一个报告很正常；复杂项目持续几周甚至一个月也并不奇怪。
但我现在很多专项分析，基本2～3天就已经交付了。
与此同时，每天还夹杂着大量这样的需求：
“帮我查一下这个数。”
“这个口径是什么？”
“为什么这个数据对不上？”
“这个功能能不能再拆一个维度？”
“这个埋点怎么设计？”
“这个字段存在哪里？”
听起来都是小事。
但真正做数据的人应该知道，一句“帮我查个数”的背后，可能是：
理解需求 → 搞清楚业务方到底想判断什么 → 找表 → 找字段 → 发现数据没存 → 找研发 → 找中台 → 对口径 → 排查历史逻辑 → 写SQL → 校验 → 最后交付。
尤其是在一个新业务、数据基础又不成熟的情况下，最耗时间的经常根本不是写SQL，而是先搞明白：这个数到底有没有？在哪里？口径是什么？以及——这个数到底能不能信？
而这些工作几乎都是隐形的。
甚至很多20分钟、30分钟的小需求，因为太碎了，我连排期都懒得记。
然后某一天，业务方跟老板反馈：“数据交付效率有点低。”我：？？？
这件事让我越来越困惑，因为我感觉它已经不是“再提高一点效率”能够解决的问题了。
一个人一周就是5个人日。
如果这5个人日里同时要求：
深度分析 + 产品分析 + 运营分析 + 市场分析 + 埋点 + 临时取数 + 口径梳理 + 数据治理 + 数据排查 + 需求沟通 + 各种会议……
那似乎已经不是效率问题了，这是一个数学问题。
更麻烦的是，“交付效率”这个指标天然只看得见：
业务什么时候提需求 → 数据什么时候交付。
却看不见一个需求在真正交付之前，可能已经消耗了几个小时甚至几天去理解问题、找数、核口径和排查数据。
所以特别想请教做数据分析、数据BP、产品分析、增长分析，以及带过数据团队的朋友：
1. 到底怎么客观证明一个分析师的效率有没有问题？
是记录每周人日？
统计需求数量和平均交付周期？
按照需求复杂度分级，再分别统计交付周期？
还是把所有工作和预计工时都放进排期，让“需求量”和“可用产能”直接可视化？
我不太想每天记录自己20分钟做了什么、30分钟做了什么，那感觉又增加了一层管理成本。
但如果完全不记录，这些碎片工作又会全部消失。
2. 当需求长期超过一个人的产能时，成熟团队到底是怎么解决的？
我现在是：固定周产能 + 需求分级 + 基础数据自助化 + 插单必须交换优先级。
比如一周只有5个人日，就先把5个人日排满。
如果周三突然来了一个需要1天的P0需求，当然可以做，但同时必须明确：那么原来哪一个1天的需求要延期？
而不是“这个也很急，所以插进来”，但其他所有事情的deadline都保持不变。
3. 一个分析师到底应该支持多少业务方？
按照我以前团队的经验，一个数据分析师大概稳定服务2.5～3个需求方。
而我现在同时面对产品、运营、市场、老板等多个方向，实际对接人数已经好几倍于过去的工作经验。
AI确实已经帮我提高了很多SQL和处理数据的效率，但我现在越来越明显地感觉到：
AI可以缩短“做”的时间，却很难消灭需求沟通、业务理解、口径确认、数据治理和上下文切换的成本。
所以我也很好奇，成熟的数据团队到底是按照什么方式配置分析师人力的。
最近这个问题最让我无奈的，其实不是工作很多。
而是：我已经通过不断提高自己的效率，把很多原本周级的事情压缩到了天级；但只要总需求持续大于产能，最终依然一定会有人觉得“为什么我的需求还没做”。
然后这个产能问题，又很容易被解释成：“数据分析师交付效率不够高。”
所以真的很想听听同行的经验：这种情况下，到底应该怎么证明问题出在产能而不是效率？
以及，一个只有1名分析师、同时服务多个业务团队的项目，应该建立什么样的需求机制，才能避免最后所有压力都落到“你为什么不能更快”上？
这个问题到底应该怎么破？
我们是个新项目，目前只有我一个数据分析师。
我要同时支持产品、运营、市场和老板，负责产品埋点、日常取数、数据口径、数据问题排查，以及老板希望重点产出的专项分析。
最魔幻的是，我自己对“分析效率”的认知其实已经非常高了。
按照我以前工作的经验，一个比较完整的大型分析项目，全人力投入两周出一个报告很正常；复杂项目持续几周甚至一个月也并不奇怪。
但我现在很多专项分析，基本2～3天就已经交付了。
与此同时，每天还夹杂着大量这样的需求：
“帮我查一下这个数。”
“这个口径是什么？”
“为什么这个数据对不上？”
“这个功能能不能再拆一个维度？”
“这个埋点怎么设计？”
“这个字段存在哪里？”
听起来都是小事。
但真正做数据的人应该知道，一句“帮我查个数”的背后，可能是：
理解需求 → 搞清楚业务方到底想判断什么 → 找表 → 找字段 → 发现数据没存 → 找研发 → 找中台 → 对口径 → 排查历史逻辑 → 写SQL → 校验 → 最后交付。
尤其是在一个新业务、数据基础又不成熟的情况下，最耗时间的经常根本不是写SQL，而是先搞明白：这个数到底有没有？在哪里？口径是什么？以及——这个数到底能不能信？
而这些工作几乎都是隐形的。
甚至很多20分钟、30分钟的小需求，因为太碎了，我连排期都懒得记。
然后某一天，业务方跟老板反馈：“数据交付效率有点低。”我：？？？
这件事让我越来越困惑，因为我感觉它已经不是“再提高一点效率”能够解决的问题了。
一个人一周就是5个人日。
如果这5个人日里同时要求：
深度分析 + 产品分析 + 运营分析 + 市场分析 + 埋点 + 临时取数 + 口径梳理 + 数据治理 + 数据排查 + 需求沟通 + 各种会议……
那似乎已经不是效率问题了，这是一个数学问题。
更麻烦的是，“交付效率”这个指标天然只看得见：
业务什么时候提需求 → 数据什么时候交付。
却看不见一个需求在真正交付之前，可能已经消耗了几个小时甚至几天去理解问题、找数、核口径和排查数据。
所以特别想请教做数据分析、数据BP、产品分析、增长分析，以及带过数据团队的朋友：
1. 到底怎么客观证明一个分析师的效率有没有问题？
是记录每周人日？
统计需求数量和平均交付周期？
按照需求复杂度分级，再分别统计交付周期？
还是把所有工作和预计工时都放进排期，让“需求量”和“可用产能”直接可视化？
我不太想每天记录自己20分钟做了什么、30分钟做了什么，那感觉又增加了一层管理成本。
但如果完全不记录，这些碎片工作又会全部消失。
2. 当需求长期超过一个人的产能时，成熟团队到底是怎么解决的？
我现在是：固定周产能 + 需求分级 + 基础数据自助化 + 插单必须交换优先级。
比如一周只有5个人日，就先把5个人日排满。
如果周三突然来了一个需要1天的P0需求，当然可以做，但同时必须明确：那么原来哪一个1天的需求要延期？
而不是“这个也很急，所以插进来”，但其他所有事情的deadline都保持不变。
3. 一个分析师到底应该支持多少业务方？
按照我以前团队的经验，一个数据分析师大概稳定服务2.5～3个需求方。
而我现在同时面对产品、运营、市场、老板等多个方向，实际对接人数已经好几倍于过去的工作经验。
AI确实已经帮我提高了很多SQL和处理数据的效率，但我现在越来越明显地感觉到：
AI可以缩短“做”的时间，却很难消灭需求沟通、业务理解、口径确认、数据治理和上下文切换的成本。
所以我也很好奇，成熟的数据团队到底是按照什么方式配置分析师人力的。
最近这个问题最让我无奈的，其实不是工作很多。
而是：我已经通过不断提高自己的效率，把很多原本周级的事情压缩到了天级；但只要总需求持续大于产能，最终依然一定会有人觉得“为什么我的需求还没做”。
然后这个产能问题，又很容易被解释成：“数据分析师交付效率不够高。”
所以真的很想听听同行的经验：这种情况下，到底应该怎么证明问题出在产能而不是效率？
以及，一个只有1名分析师、同时服务多个业务团队的项目，应该建立什么样的需求机制，才能避免最后所有压力都落到“你为什么不能更快”上？
这个问题到底应该怎么破？
25 2410
如果从每周的生活片段里取一些样本，上瑜伽课可能不是快乐的峰值，却一定是我和自己待在一起最深切的时刻之一。
那些能够抱持自己的瞬间来的太不容易，所以一直在反反复复地记录：
从学习宽容自己，不再追随那个“一定是我哪里没做好”的声音，到慢慢看见那个内化已久的、严厉的超我并不来自本心，再到像婴儿学步一样，一次次确认自己的感受，一点点把自己领回自己身边。
而每当意识到“此刻我正站在自己这一边”，胸腔里都会泛起一阵很深的涟漪。
今天下课后回想这种感受，脑海里甚至浮现出了“口吐莲花”的画面——像有什么积攒了很久的东西终于从身体里涌出来，吐着吐着，竟然开出了一朵花。
每跨出一点点“东亚小孩的出厂设置”，都觉得好温暖，或许温暖就是这样自己给自己的吧！
那些能够抱持自己的瞬间来的太不容易，所以一直在反反复复地记录：
从学习宽容自己，不再追随那个“一定是我哪里没做好”的声音，到慢慢看见那个内化已久的、严厉的超我并不来自本心，再到像婴儿学步一样，一次次确认自己的感受，一点点把自己领回自己身边。
而每当意识到“此刻我正站在自己这一边”，胸腔里都会泛起一阵很深的涟漪。
今天下课后回想这种感受，脑海里甚至浮现出了“口吐莲花”的画面——像有什么积攒了很久的东西终于从身体里涌出来，吐着吐着，竟然开出了一朵花。
每跨出一点点“东亚小孩的出厂设置”，都觉得好温暖，或许温暖就是这样自己给自己的吧！
12 10
最近花了一两天时间，分析用户下载 App 后为什么没有发生核心行为，以及这些用户最后都去了哪里。
因为涉及行为路径的清洗和分簇，数据处理上花了不少时间。结果兜兜转转，最后得出的结论，和分析开始前的业务假设并没有什么不同。
然后我突然想到一句话：为什么要分析没买车的人，为什么不买车啊🥹
因为涉及行为路径的清洗和分簇，数据处理上花了不少时间。结果兜兜转转，最后得出的结论，和分析开始前的业务假设并没有什么不同。
然后我突然想到一句话：为什么要分析没买车的人，为什么不买车啊🥹
10 82
来这个项目之后，我发现自己已经快能干数仓了。今天甚至开始被迫给数仓设计 ODS、DWD、DWS、ADS 的表名和表结构。
听说过数仓、数据分析、商业分析、数据科学、数据挖掘全都干过的人吗？
没错，就是我——一个在💩里淘金前，还要给💩分层的人。
但还是那句话，我依旧感恩可以准时下班的工作🥹
听说过数仓、数据分析、商业分析、数据科学、数据挖掘全都干过的人吗？
没错，就是我——一个在💩里淘金前，还要给💩分层的人。
但还是那句话，我依旧感恩可以准时下班的工作🥹
14 61
像是神神叨叨的人才会说的话——竟然在一开头就审判视角降临了，anyway，但在瑜伽课的练习上，竟然真的进入了一种接近冥想的状态。
当每一个串联动作都变得足够熟悉，在结束时突然意识到，这次在练习中完全没有了对自己的审视，也没有了那个不断追问“为什么做不到”的声音。所有的注意力只被身体当下的感受所占据。
或许内心的平静并不是靠反复练习如何平静得来的，而是在某个瞬间，忘记了自己还在努力追求它。
就很想把这一刻记录下来。
在一次次尝试与当下的感受待在一起时，我听见过太多评判的声音。所以，当那个期待已久的感受真的降临时，有很多欣慰与感动🥹
当每一个串联动作都变得足够熟悉，在结束时突然意识到，这次在练习中完全没有了对自己的审视，也没有了那个不断追问“为什么做不到”的声音。所有的注意力只被身体当下的感受所占据。
或许内心的平静并不是靠反复练习如何平静得来的，而是在某个瞬间，忘记了自己还在努力追求它。
就很想把这一刻记录下来。
在一次次尝试与当下的感受待在一起时，我听见过太多评判的声音。所以，当那个期待已久的感受真的降临时，有很多欣慰与感动🥹
7 00
我昨天以为研发骗我，结果确认完发现，人家几十亿流水的项目数据确实是这么干的。
除了基础订单，只要数据不提需求，所有的配置类数据、业务行为类数据、用户权益资产类数据，关系类数据，服务端除了redis啥也不存。
前几周我还和研发谈笑风生，听他们讲来这个公司后工作量极具减少的轶事，结果一转眼回旋镖直插我脑门…🫠
除了基础订单，只要数据不提需求，所有的配置类数据、业务行为类数据、用户权益资产类数据，关系类数据，服务端除了redis啥也不存。
前几周我还和研发谈笑风生，听他们讲来这个公司后工作量极具减少的轶事，结果一转眼回旋镖直插我脑门…🫠
6 10
前段时间，测试跟我说：“你们做数据的，就是业务的下水道。”
我当时还挺想反驳的。毕竟我一直觉得自己是做业务分析的，简历上写的也都是“驱动业务优化”“支持策略迭代”“通过数据发现增长机会”。
听起来怎么也应该算业务的导航系统吧，再不济也是个仪表盘，怎么就下水道了？
直到今天，我发现他说得对，而且说得非常准确。
事情的起因，还是经典的数据 garbage。
以前我其实没有特别关注数据质量。不是因为不重视，而是因为过去都有比较专业的数仓、研发负责底层质量保障。
结果来到这个新业务以后，我才发现，这里存的数据非常有想法。
很多功能配置类数据，甚至一些涉及流水的数据，不存在 MySQL 里，而是放在 Redis 里，再通过埋点往外吐。
除了中台能保证的少量基础订单数据，其他数据基本都要我从埋点表里捞。
一开始凭借我粗浅的常识，我也知道，数据不应该这么存，埋点可能漏报、错报、重复上报，哪一个都是问题。
但我毕竟不是专业做数仓和服务端的，也不知道这种设计到底能离谱到什么程度。
研发当时还拍着胸脯跟我说：“几十亿流水的业务也是这么做的，从来没出过问题。”
那一刻，他拍胸脯的声音太响了，直接震碎了我的判断力，我居然真的信了。
我当时还认真反思了一下：是不是我专业性不够？是不是人家见过大场面？是不是几十亿流水都这么干，说明这是某种我不懂的先进架构？
现在回头看，我真是太幼稚了。几十亿流水可能确实没出过问题。也可能是出了问题，但没人查出来。
还好现在有 AI。
以前做一次跨表核验，可能要花很久写 SQL、梳理口径、排查链路，现在借助 AI，我能快速把业务结果、订单数据和埋点数据拉出来对账。
然后神奇的事情发生了。
错报有，漏报有，多报也有。数据问题种类齐全，主打一个都不能少。
我现在的心情非常复杂。
一方面，我真的非常懊悔，我又又又又（已经不知道多少个又）一次被别人“拍着胸脯保证”的姿态唬住了。
好像对方只要足够自信，我就会下意识怀疑是不是自己不够专业。
另一方面，我又真的很感谢 AI。
要不是它让我能快速、低成本地验证这些问题，我可能到现在还在拿着一堆乱七八糟的数据。
然后最精彩的部分来了。我把问题反馈之后，对方轻飘飘地说：“埋点本来就会有少报、漏报、多报，一点点误差也可以接受吧。”
我真的当场沉默，不是，之前那个拍着胸脯说“从来没出过问题”的人呢？
怎么一发现问题，口径就从：“绝对没问题。”瞬间变成了：“有点问题也很正常。”
这要是普通数据也忍了，我们是要拿这些数据发奖励金的。
“一点误差可以接受吧。”嗯，确实可以接受。毕竟误差又不从说这句话的人工资里扣。
这时候我终于理解，为什么测试说数据是业务的下水道。
上游的产品逻辑乱了，研发实现歪了，埋点漏了，字段错了，存储随缘了，最后所有脏东西都会顺着管道流到数据这里。
然后数据同学蹲在最下游，一勺一勺地捞，捞完还要负责解释：
为什么这坨数据和那坨数据颜色不一样。所以我不是下水道，谁是下水道？
我不仅是下水道，我还是下水道质检员、下水道修理工、下水道考古学家。
简历下一版我必须加一句，“自动化识别上游排泄物，并在有限条件下维持管道畅通。”
我不如💩坑谁入💩坑？🫠
我当时还挺想反驳的。毕竟我一直觉得自己是做业务分析的，简历上写的也都是“驱动业务优化”“支持策略迭代”“通过数据发现增长机会”。
听起来怎么也应该算业务的导航系统吧，再不济也是个仪表盘，怎么就下水道了？
直到今天，我发现他说得对，而且说得非常准确。
事情的起因，还是经典的数据 garbage。
以前我其实没有特别关注数据质量。不是因为不重视，而是因为过去都有比较专业的数仓、研发负责底层质量保障。
结果来到这个新业务以后，我才发现，这里存的数据非常有想法。
很多功能配置类数据，甚至一些涉及流水的数据，不存在 MySQL 里，而是放在 Redis 里，再通过埋点往外吐。
除了中台能保证的少量基础订单数据，其他数据基本都要我从埋点表里捞。
一开始凭借我粗浅的常识，我也知道，数据不应该这么存，埋点可能漏报、错报、重复上报，哪一个都是问题。
但我毕竟不是专业做数仓和服务端的，也不知道这种设计到底能离谱到什么程度。
研发当时还拍着胸脯跟我说：“几十亿流水的业务也是这么做的，从来没出过问题。”
那一刻，他拍胸脯的声音太响了，直接震碎了我的判断力，我居然真的信了。
我当时还认真反思了一下：是不是我专业性不够？是不是人家见过大场面？是不是几十亿流水都这么干，说明这是某种我不懂的先进架构？
现在回头看，我真是太幼稚了。几十亿流水可能确实没出过问题。也可能是出了问题，但没人查出来。
还好现在有 AI。
以前做一次跨表核验，可能要花很久写 SQL、梳理口径、排查链路，现在借助 AI，我能快速把业务结果、订单数据和埋点数据拉出来对账。
然后神奇的事情发生了。
错报有，漏报有，多报也有。数据问题种类齐全，主打一个都不能少。
我现在的心情非常复杂。
一方面，我真的非常懊悔，我又又又又（已经不知道多少个又）一次被别人“拍着胸脯保证”的姿态唬住了。
好像对方只要足够自信，我就会下意识怀疑是不是自己不够专业。
另一方面，我又真的很感谢 AI。
要不是它让我能快速、低成本地验证这些问题，我可能到现在还在拿着一堆乱七八糟的数据。
然后最精彩的部分来了。我把问题反馈之后，对方轻飘飘地说：“埋点本来就会有少报、漏报、多报，一点点误差也可以接受吧。”
我真的当场沉默，不是，之前那个拍着胸脯说“从来没出过问题”的人呢？
怎么一发现问题，口径就从：“绝对没问题。”瞬间变成了：“有点问题也很正常。”
这要是普通数据也忍了，我们是要拿这些数据发奖励金的。
“一点误差可以接受吧。”嗯，确实可以接受。毕竟误差又不从说这句话的人工资里扣。
这时候我终于理解，为什么测试说数据是业务的下水道。
上游的产品逻辑乱了，研发实现歪了，埋点漏了，字段错了，存储随缘了，最后所有脏东西都会顺着管道流到数据这里。
然后数据同学蹲在最下游，一勺一勺地捞，捞完还要负责解释：
为什么这坨数据和那坨数据颜色不一样。所以我不是下水道，谁是下水道？
我不仅是下水道，我还是下水道质检员、下水道修理工、下水道考古学家。
简历下一版我必须加一句，“自动化识别上游排泄物，并在有限条件下维持管道畅通。”
我不如💩坑谁入💩坑？🫠
23 79
今天都没用fable又喜提新账号被封，再这么杠下去我要去转行干风控了
日区充值+tun全局模式下的全日语会话输入+时区和vpn保持一致在美国+不允许使用地理位置信息还不够。
问题还是出现在它接管了我历史代码项目之后，我历史代码里到底是有啥让它能立马就发现我🥹
日区充值+tun全局模式下的全日语会话输入+时区和vpn保持一致在美国+不允许使用地理位置信息还不够。
问题还是出现在它接管了我历史代码项目之后，我历史代码里到底是有啥让它能立马就发现我🥹
5 90