前文：

回忆：我与我的高中

23年1月13日 14:31

42191

前提

经历苦难是为了以后不再经历苦难，而不是为了逞能去承受更多的苦难。

明白了这个道理，从大学一开始我就极力避免陷入二次内耗。但是我失算了，我陷入了一个巨大的圈套中。这个B学校，上至领导、辅导员、班主任，下至各种活动各种推送，无一例外都在给学生灌输着唯绩点论的谎言。学校教的，和我真正需要学的东西是割裂的，高中如此，这个大学亦是如此。可惜我如果能早点明白这个道理，就不用为那些繁杂课程苦苦挣扎了。

幸运的是，这样的内耗只持续了大一下一学期，最后以两科重修，技术停滞结尾。内耗的结果注定是精神痛苦和一事无成，以及埋下更多的内耗隐患。但好在大二上（也就是22年8月底，水波萌也是在这时重建的），开始不断学习技术，现在心里也算有点底了，不至于落入能力的自我怀疑中。

于是我又陷入了另一个陷阱——技术陷阱。

这篇文章也是从两万字大文章拆出来的，但是没有啥情感波动，就不放歌了，自己找歌听去吧。

我认为的技术陷阱

技术陷阱，本意是说技术的进步并不总是能带来好的结果。比如生产方式升级解放了人的双手，但会导致大量的失业。失业的痛落到百姓身上，可能会影响很长的一段时间。技术的进步，也会相对地减小特定人群劳动的价值。例如大机器的本意是为了服务生产，从而最终服务人类。但因为机器比人力昂贵，就会出现“人服侍机器”的现象。技术进步不一定会影响全人类，但很容易让相近领域产生翻天覆地的变化，越是小的领域越容易如此。如近年AI绘画的兴起，一定程度上冲击了头像定制的服务。即使未经允许直接使用别人的画当头像，法律上也属于合理使用的范畴，使用者自然也不用在乎AI产出的画作是否侵权。AI配音的发展也是同理。

同时，技术的进步迫使人做出相应的改变。例如移动设备的本意在于让人更方便地收发信息，结果你在电脑上看个网页还强制你手机扫码登录，或者干脆必须跳转到手机上观看。越来越多的事务可以在手机上处理，这固然是技术进步的结果，但也加重了人的日常生活对手机的依赖。虽然使用手机本身不是什么坏事，但它却在事实上让不使用手机的人越来越不方便，从而迫使人们终日携带、关注手机。好比扫码点餐比排队点餐先取，好比出入扫核酸码（现在没有了，但也会有只有扫码才能得到的服务，比如自动售货机，共享单车、充电宝等），好比学校/公司要求使用QQ/微信/钉钉交流，你想扔掉手机出门一天都不方便，去有些地方还要手机预约。

对于个人而言，一个人花费大量时间，终于掌握了大部分某个技术的知识，然后技术进步了。如果他不跟进学习，就要面临被淘汰的局面。在现代这个周期被缩减至三至五年，也就是说一个人每三至五年就要更新一波知识。然而在深入研究一个技术以后，想要主动去放弃原来的认知是痛苦的。例如让一个使用面向过程思想工作十年以上的人，去学习并接受面向对象思想，可能比让初学者做要难得多。这就像是逼迫一个人承认，他所做的努力（包括对知识的记忆，和对思想的改变等）大部分都是徒劳的。而他视若珍宝的知识，可能也不过是后人介绍技术进步史上不起眼的寥寥几笔。

我认为，个人会落入技术陷阱，很大一部分上来自于——先学技术，再找地方用它。特别是在信息爆炸的年代，动辄上百上千小时的教程，收藏即吃灰的时候。一个人穷尽一生也只能学到全人类极小一部分的知识，为了不可预知的未来，不浅尝辄止，想要学会一切，最终只会落得精疲力竭。

例如互联网，每三到五年就要迭代一波技术。然而经常能看到自称从业十几二十年的某某架构师/项目经理/认证XX，用着二十年前的上课方式，讲着十年前的技术，教给今年的人（其实不少大学课程也是如此，像我的虚拟仿真设计课，就是用本世纪初的教学方式，讲着2012版的3ds max给2021年的学生听）。

以Unity的资源管理（这里专指运行时，不考虑Assetdatabase）为例，说明技术迭代对初学者的影响。官方最新的方案是2018年稳定的Addressable Asset System，也就是AA。但是都2023年了，大部分项目还在用2014年就已成熟的Assetbundle，也就是打ab包。一方面是升级的性价比不高，因为编辑器版本限制，对于公司来说，要把整个工作流都重新适配到2018及以上的LTS版本中，所需要的时间精力是相当巨大的。另外，对于旧的技术，公司内部都有自己的技术沉淀，如建立在ab包上的热更新框架，资源规范等，已经足够满足需求。另一方面是学习资源限制，对于个人而言，目前能接触到的公开学习教程中，使用ab的比例是要明显多于使用aa的，甚至还有不少教程在讲解更古老的Resources方案。尽管官方明确建议不要使用Resources，奈何它实在是太容易上手了，很多教程里因为没有高需求（一般教程也不做中大型项目，或者单纯为了简化）就直接用Resources或者在上面写个简单框架教给学生，学生看到也就照着学了。

假设存在一个目的不明确的Unity新人：他也不清楚学Unity是为了拓展视野学一下玩玩，是为了找相关岗位的工作，还是要创业打出下一个米哈游，又或者是想做出心中独一无二的游戏来满足表达欲……那么他就无从得知自己要学习哪些内容，以及要学到什么程度。也就是说，他在没有做项目的情况下，想要先学技术，再找地方用它。

第一层陷阱

问题来了，如果这个新人想要学习资源管理，他难道要把Resources，ab，aa全部学习一遍吗？答案为是，他别无选择。

首先要面对的是，他根本就不明白这些知识各自有什么特点。如果他从没做过稍大点的完整项目，或者没有从业者指导，就算他去看别人分析出来的各种方案的优缺点和不同，他能理解吗？比如他搜到一篇文章里说，Resources虽然好用，但会把所有资源打包进去，延长启动时间，常驻内存，且没法增量更新。那我估计他可能会想：“啥叫全部打包进去？有啥影响么？延长启动时间有啥问题，我看我启动挺快的啊？再说一般游戏打开之后不都要启动不少时间么？常驻内存又有啥影响，我看这内存占用也不大啊？再说现在内存都16gb起步了，那些3a都很少说内存不够啊。增量更新又是啥？是说没法更新吗，还是说和联网有关？对我做单机游戏会有影响吗？”

更重要的是，他不清楚自己的开发需求，无法根据需求去选择性学习。如果他想开发小微型游戏试水，或者他是大学生，准备以后用Unity制作课设大作业，诸如此类对资源管理需求不明显的情况，读取直接用Load+路径甚至Inspector面板手拖就足够了，在设计上完全没必要使用新技术。这也是技术进步不得不面对的一个问题：更好用，但更难上手，特别是对新人而言；但是，如果他是为了当年的入职做准备，就需要重点学习ab技术，并掌握aa使用（也看公司而定）；如果他要做一个体量稍大的独立游戏，首选是更加人性化的aa。说句题外话，虽然不推荐新人直接上手比较大的项目，但也并非毫无益处，这样能让他提前认识到一些平时很难在意的东西。比如数据表现分离、性能优化、规范等（当然，这里的几条不只是程序，其他方向也有涉及）。

综上，他不得不把大部分内容都学个遍，但这样做明显会浪费不少时间精力，于是他掉入了第一层陷阱。

先学技术，再找事干的最大问题就在于，你不知道未来解决某个具体问题需要学习哪些知识，所以你只能把这个领域里所有知识都学一遍，且因为缺少实践很难深入理解部分知识——为什么是这样的，有什么不同，有什么用处，它重要吗？

所以我更倾向于项目式学习（PBL），也就是在做具体项目时，需要什么学什么。我的具体做法是：总览知识，在项目中发现需求，找到并学习知识，运用知识解决需求，如此循环。打个比方，一个人想要做一款最原始的打砖块游戏，他在制作前了解到游戏中一般有动画、物理、音频、交互几个模块，以及每个模块大致的作用（总览绝对花不了多长时间）。那么在做木板“击打”弹球功能的时候，他很快就能想到这属于物理模块。然后再去总览物体模块，得知他需要使用刚体和碰撞器。学习刚体，总览碰撞器（就是把名字看一遍），选出碰撞器。成功实现功能，问题解决。相比一般的做法，我加入了总览知识这一步，这一步其实非常重要。如果没有总览知识，他解决问题的过程很可能是这样的：搜索怎么让物体反弹/打砖块反弹怎么做，然后教程告诉他要加上一个叫Rigidbody的东西和一个叫Collider的东西，他学了一下这两个东西是什么，然后问题解决。这也是项目式学习很容易出现的问题，就是学到的知识太零散，甚至可能啥实质的东西都没学到——极端情况下，当遇到某个问题时，找到的解决方法是：添加一个叫做XX的组件，勾选第X个按钮，问题解决。这能叫知识吗？这只能叫经验，还是临时的那种，只允许出现在与开发内容关系不大的一次性问题上（比如用不了部分C#语法，去unity设置里切换.net。如果还没有解决，最多也就关注下unity和c#版本对应关系，然后升级unity版本）。

对于前文提到的Unity新人而言，最好的做法是：使用项目式学习，参与完成具体的游戏项目。在具体的项目需求面前，不同方案的差别将自然变得清晰而明显。在项目需求较低的时候，使用最简单的Resources或者手拖，但不需要在此基础上更进一步，例如钻研底层的api和写相关框架；在项目需求较高的时候，再使用AA并以AA为基础改进。如此，短期来看，他不用学习所有的资源管理知识；长期来看，他不用学习许多与实际开发联系不大的知识。只要他没有在Unity具体的某些技术学习上浪费多少时间精力，就避开了第一层陷阱。

第二层陷阱

还记得一开始提到的，这个新人学习Unity的目标不明确吗？第二层陷阱的可怕之处，正在于大部分人对眼前短暂的决策，比对长期的规划更加敏感。

如果他不能判断自己需要学习哪种资源管理方案，那他凭什么能认定自己需要学习Unity这门技术？如果他会因为自己学了aa却用不上而懊恼，那他凭什么会觉得学了Unity却用不上也算艺多不压身？学习一门技术本身，可能就是对时间精力的浪费，这是第二层陷阱。

兴趣爱好和工作终究是要分开的。如果把Unity视为就业岗位的就职需要（JD），那么深入研究就是合理，高回报的。如果把Unity创作视为爱好，那么就不能把大部分精力都投入其中，更不能想着深入研究，然后以此寻找工作。把爱好当成工作，除非你是水平足够高的独立制作人或者家里有矿，不然都只会是一种精神折磨，是对爱好的一种糟蹋（我2022-11-12的随想有提到过为什么）。如果它连爱好都不是，纯粹是对这方面有点感兴趣，那么就更不应该花多少时间在上面了。此时它就和一篇新闻，一场分享会一样只是用来拓宽眼界，用之即弃的东西。当然，也可以从感兴趣升级到爱好，从爱好升级到工作，但在下定决心，做好长期规划（学了这个会对我的生活产生什么影响？应该怎样规划未来以配合这项技能？）之前不要过早地投入更多进去。指望先学一项技能，然后再想办法找点事情来体现其价值，很容易就会陷入什么都想学，什么都会一点，又什么都做不强的困境。

要避开第二层也很简单，就是把绝大部分时间精力集中到一项已知用得上的技术上，从而避免学习用不上的技能造成时间精力浪费。然而，问题并没有到此就结束。把绝大部分时间精力集中到一项技术上，如果没有做好规划，很容易会落入第三层陷阱中。一二层陷阱都只是浪费了人的一部分时间精力，而第三层陷阱，则会影响人的人生路径选择。

第三层陷阱

古话说，“艺多不压身”。然而它指的是身上技术再多也不嫌累，到哪都能混口饭吃，不至于饿死。但现代人的精力是有限的，追求却不只是能混口饭吃。在我看来，先学技术，再找事做的最大危害就在于，它加重了技术在决策中的地位分量，从而削弱了人对自我发展和对未来走向的控制。一旦一个人在目标不明确的情况下学会了一门技术，那么他的决策，不管和技术有没有关系，都会有意无意地向技术靠拢，因为他学技术就是为了找机会用上，技术已经是他的沉没成本了。于是，技术并不会让他向着想成为的人更进一步，而是让他想成为的人，被迫沾上越来越多技术的气息。

换言之，对于落入了第三层陷阱的人来说，从来不是人在支配技术，而是技术在支配着人。如果能反应过来，这是一个很可怕的问题。

我也是最近才想明白，自己落入了第三层陷阱中。我是一个表达欲很强的人，如果不是为了更好的生活条件所考虑，我的首选是做一名独立的插画师/CG艺术家。从初中开始，我学习编程的初衷就是为了做游戏，我想实现自己想要的功能效果。我并不喜欢钻研代码本身，我也并不喜欢去钻研什么底层的什么逻辑什么特性，这些东西交给喜欢这些的人做就好，我的一切努力本意上都是为了我的实际使用服务。

但是与代码常年累月的接触麻痹了我，导致在事实上，我绘画/创作音乐或者在其他艺术表达方面的投入远小于在代码的投入。编程这项技能也直接影响了我选择计算机专业，直接影响了我的就业和人生方向，让我离艺术表达越来越远，这是与我本意相悖的。如果我把几年间投入到代码的精力都投入到绘画上（当然，必须是系统性的学习，空中楼阁式的学习我已经批判过了），那么我的自我实现就已经实现一半了，剩下一半是实现财富自由。那么现在的我应该会快乐得多，也就不用现在还在这里写长篇大段的废话了。

第三层陷阱是极难避免的。只要还有一天，学的技术是为了找机会用上，那么它就一定会影响决策。反之，学了技术却故意压制它不用，这是很难做到的事情，即使做到了也只不过是跳到第二层陷阱里。

总结

任何东西都是有利有弊的，技术当然也不例外。只不过没人或者很少人说学技术的坏处，所以技术的弊端就这样潜移默化地影响一个人，等他发现时已经晚了。所幸我发现的还不晚，还是有很多时间精力去弥补的。

另外，你不难发现，要彻底避免技术陷阱，要么就不学习除工作外的任何技能，要么就只有从根本上改变——先明确目的，再学习技能。比如在学习音乐前，就明确音乐是自己的感兴趣/爱好/工作，从而投入相应多的资源，而不是抱着“先学了再说，能学多少学多少，反正只有好处没有坏处”这样的想法，以免陷入无底洞。