通知设置 新通知
其他职业越老越值钱，程序员越老越贬值？
科技创新 • 小小鸟a 发表了文章 • 0 个评论 • 63 次浏览 • 2021-04-16 14:47
前言
今天一早，看到NBA交易消息中提到：小加索尔与洛杉矶湖人队签下两年老将底薪合同。业界评论一致认为湖人这次在中锋这个位置进行了补强，甚至有人认为湖人是捡了个大便宜。
小加索尔作为一个85年出生的球员，在NBA赛场上已经是处于职业生涯晚期的球员，为什么还这么受关注呢？其实每年NBA交易期都会有这样类似的情况，一些早已功成名就的老将，不在意薪水的多少，只想加入一只有争冠实力的球队，并且往往他们的经验会让球队受益匪浅，关键时刻往往会帮助球队获得胜利。正如我们华夏民族一直流转的那句“家有一老，如有一宝”。
每一个职业每一个行当，一代代的经验传承，造就了中华民族五千年的文化荟萃，但是现在似乎程序员这个职业有些另类，别的职业都是越老越值钱，唯独程序员，在众人的眼中越老越容易失业？越老越贬值？
那究竟是什么原因造成了这个现象呢？让我们一起看看知友们都是怎么说的吧
做程序员这些年，我一直在思考一个问题，就是：
就互联网公司而言，对于公司好的发展逻辑其实是跟对于个人来说好的发展逻辑似乎是有冲突的。
对于一个大公司来说，一个新员工进来，首先要做的是什么？
学习遵守公司的流程规范，让自己的工作内容和工作方式都以一种标准化的方式进行。
哪怕你做了某个很好用的工具，或者发现了做这件事的更高效的方法。
那么在得到上级认可之后，你要干什么？
把这个东西整理成标准的流程，文档，以提高后面新入职的同事的工作效率。
为的是什么？
为的是哪怕有一天你不在这个公司了，你所做的这一部分工作也能很快地找到另外一个人来代替。
当然，然后还有进行项目开发时对于代码和文档的各种规范和要求，越是大公司，在这方面的要求越是严格。
为的是什么？
为的是哪怕你作为这个项目的核心开发者，但是如果有一天你主动离职了，或者年龄大了被公司裁了，这个项目依旧可以正常地运行迭代下去。
这确实是对于公司发展来说最好的逻辑。
但是问题是，这对我们作为员工的个人来说，可能并不是一个好的逻辑。
如果一个公司想要做大，想要走的远，那么他们就需要通过标准化，规范化的流程来把个人因素变动所带来的的影响降到最低。
而在里面作为的螺丝钉的程序员，除了写代码完成业务功能以外，还要把代码写的尽量让大家都能看懂，让后来人能轻易接手。
但这也为他后续被更年轻，更能996的程序员取而代之，埋下了伏笔。
而在某些传统行业，则不是这样的。
尤其是有些老一辈的手艺人，确实是越老越吃香，甚至是一个匠人到了六七十岁，还有人愿意把自家孩子送到这个匠人门下当学徒，学习手艺。
难道是因为这个行业真的有什么常人难以学会的知识或是技能，哪怕钻研了五六十年，还是有着很大的提升空间。
以至于研究了50年的手艺人，就真的比研究了30年的，要高好几个档次，所以大家才都青睐那个更老的手艺人吗？
也不一定。
也有可能是人家只是有几个压箱底的绝活，但是这个绝活，在这个手艺人临终之前，都不会轻易地交给自己的徒弟，更不要说是新入行的同事了。
毕竟人家是打算靠这点绝活，吃一辈子饭的，如果随随便便就交给徒弟，那师傅不就饿死了吗？
所以说，明白了吗？
为什么有些职业是越老越吃香，而程序员不是越老越吃香？
因为互联网公司的逻辑是：”虽然我需要程序员来帮我开发软件，但是我更需要的是这个软件离了他之后，依然可以好好地运行，所以说我会竭尽全力地来保证流程的规范化，代码的可读性以及业务逻辑的文档化。“
这样一来，即使程序员开发出了某个发展很好的项目，但是在这个项目进入稳定生产之后，也跟他没有太大关系了。
他并不能靠对着某个项目的理解，而吃一辈子饭，因为公司的规范要求他把所有有关这个项目的理解，都整理成文档，模型，和代码注释。
他要么抓住某个机会成为管理层，拿到公司股份，要么不断跟进学习日新月异的新兴技术，要么，就只能等自己老了，精力和体力都比不过年轻人的时候，被更加年轻的程序员所取代。
从这个角度上看，公司和程序更像是一个生命，而前赴后继的程序员们，只是不断往这个生命里面注入动力的干电池而已。
自由飞的想法
大部分的中国企业，就没把程序员当做“脑力劳动者”，而是当做“体力劳动者”在用！
996是福报啊！过了35岁，搬不动砖了，996都没你的份。
我以前看报道，说“中国航天”深化改革啥啥啥的，其中一个成果就是“队伍平均年龄28.6（大概吧，总之很年轻）岁”，然后今年火箭已经炸了三次了。——这事我就随口一说，究竟什么原因炸的，炸得好不好，应该不应该，我不是行内人士，大家不用给我上课，实打实的说，我也不关心。
但以我一个快40的老码农而言，不说别人，就说我自己，我非常肯定确定以及一定：
我的能力从来没有贬值。恰恰相反，随着经验的积累，我的能力与日俱增。
我相信，就算不是全部，但很多老码农都会有这种感觉。
新东西学不动，那是懒得学！工作中用不到的，我学他干嘛？真要学的时候，分分钟捡起来，比你刚入行的菜鸟不知道快多少倍。
而且会倒腾个新技术就算有能力了？呵呵，
除了高质量代码生成以外，还有很多其他需要日积月累的技能，譬如全面审查需求，妥善安排进度，快速bug fix……
但是，企业关心这些么？
不过是搬砖的而已，能把砖搬过去就完事了，还管你怎么搬？
外包单位就不说了，卖出去一个是一个，关键是挣差价，你的工资是成本，当然越低越好。
互联网公司，钱烧得霍霍的，产品急着上线呢！还管你代码质量，只管你能加班不？！屎一样的代码糊上去再说，美其名曰“及时反馈快速迭代”……
软件公司……等等，中国有软件公司么？反正除了屈指可数的那几家，目之所及真能赚钱的都是骗补贴的！
明白了吧，这就是你问的为什么。
老程序员本身没有贬值，所谓贬值，是因为人力市场的需求。
怎么办？凉拌！
唉，希望未来能有更多脚踏实地的、以产品质量取胜的软件公司涌现出来吧！
invalid s的表述
古话说的好：“飞鸟尽，良弓藏；狡兔死，走狗烹”。
不光程序员越老越容易失业，国内一切技术行当不都这样吗？
身为技术人员，在自身职业前景上，必然要遭遇两个问题。
第一个问题是他自己能控制的：你，究竟掌握了多高的技术？
是面向搜索引擎编程、只会CRUD呢；还是能够编写更高质量的代码、解决日常问题？
或者，是有充分的大中型项目设计、实施经验，甚至能够主持有一定难度的项目开发？
或者是，你能否掌握“核心科技”，挑战业界大佬？比如和思科比比网络调度算法、和Linus比比OS开发、写个数据库挑战Oracle、搞个Hadoop挑战yahoo甚至google？
可想而知，当你只会面向搜索引擎编程、只会CRUD时，你当然就是个一次性消耗品。用到三四十岁差不多也该用坏了，找个借口扔掉就是。
比赛“跑不死就往死里跑”的话，你怎么可能比得上二十来岁的小年轻呢？
想要“越老越值钱”，你就不能在年轻人的优势领域停留，你就必须不断提升自己、拓宽眼界、抬高上限——你猜Linus担心不担心失业？你猜yahoo里面编写/维护hadoop的、google里面优化big table page rank map-reduce的，他们担心不担心失业？
你究竟学会了多少，就决定了你的命运。
当你只能拼996007时，你那二十岁的身体还的确能支撑你扛大包；但到了三四十岁，哪怕没有落下一身职业病，你，还能像年轻人那样“昨天摔了一跤整条腿都紫了今天打个绷带照样活蹦乱跳”吗？
所以你失业了。那些挤走你、顶替你的，也会像你一样，在被人超负荷使用十年、落下一身病痛后滚蛋。
这就是第一个问题：你不为将来打算，急功近利透支身体996/007，所以你越老越容易失业。
你不光越老越容易失业，你还会落下一身病痛。三四十的身体甚至比不上那些会保养的、六七十的老人。你不得不掏出大量金钱来维持自己的基本生存。
如果你压根就不是什么“良弓”，凭什么阻止别人把你像垃圾一样踢开？
人无远虑，必有近忧。
技术人员必将遭遇的第二个问题并不是他们能控制的。
那就是：你把自己修炼成了全世界顶尖的超高精度复合弓；但你的国家压根就没有射箭比赛。
是的，你懂操作系统内核；但中国有哪家公司在开发自己的OS？
是的，你懂数据库算法编译器优化；但中国有哪家公司能做数据库能写编译器？
如果整个社会都只能追逐那么几只半死不活的残疾兔子；你，身手矫健又有何用？
人山人海，哪里见得到兔子。
结果你还想吃多点，否则……都不够维持你的一身肌肉。
相信我。用不了多久，你也会饿成一条病恹恹的瘦狗。
那么，这就是国内醉心于技术者面对的窘境：我们压根就没有能插手基础性、支柱性软件项目的公司。唯一会的就是互联网，就是想尽办法薅用户羊毛的终端软件。
对大多所谓的“互联网公司”来说，写这种软件，“面向搜索引擎编程”“调库专家”基本够用。更高的，他们根本不敢想。
正是这种现状，使得一些缺乏眼界者压根不敢想“需要熟练使用链表算法的工作”；相反，他们会告诉你，会调库足矣、照搬互联网上搜到的代码就够用了——甚至还有在我的回答下言之凿凿、说“专家”说了，能搜到现成的代码就千万不要自己写，自己写的质量太差……
但事实是，哪怕在中国，照样有不算太少的中高端职位；这些职位的基本要求就是“不准抄网上代码”。
这是因为写出这些代码的人水平良莠不齐、写的时候也未必是按工业化/商业化标准精益求精（经常就是为了让初学者明白，所以省略了很多很多东西）——对这类中高端职位所要求的、业界top5%、top0.5%、top0.05%的、较为正规的程序员来说，这种东西说好听点叫粗制滥造，说难听点就是垃圾。
当这些人崇拜的“专家”都在顶礼膜拜网上的劣质代码时，他们的水平也就可想而知了。
眼界所限，他们完全不可能知道那些中等以上水平的程序员在做什么；在他们看来，一行代码出一堆错误是必须的——我说自己一口气写几千行不出错，他们就破口大骂：追着骂、单独开贴骂；直白的骂、阴阳怪气的骂……
这种情况，在过去是不可想象的。
在当时，别说垃圾到这种程度了，任何问题只要简单到用搜索引擎搜一搜就能解决，你敢问，就会被老手怼回去。很多论坛把“提问前应该做到什么”置顶；“STFG（Search The Fucking Goolge）”是被人普遍接受的、对小白问题的标准回复。
但现在，连网上苦口婆心的解释都读不懂、只能逐字逐句照搬现成的代码的小白敢“组团围剿”那些敢说自己能写程序的“吹牛者”。
可想而知，这种劣质码农的声音淹没一切时，这个行业会变成什么样子。
别说开拓新的市场、新的疆域了，就连抄，他们都不敢抄热乎的。
这反过来强化了劣质码农们的认知——没错，中国啊，它本来就不需要高于“面向搜索引擎编程”的装B犯。反正你们学了也没用，大家一起996，欢乐的卷起来吧。
业界整体的低水平，使得你除非在校时就憋着一口气、玩命的往世界一流水平赶；否则一旦开始工作，庸人们很快就会把你拖进自己的节奏，然后干净利落的打败——这工作你能做我也能做，我见经理满脸堆笑，你呢？书呆子。什么叫你一周抵我们一年？谁看见了？
中国技术人员地位低，原因就在于此。
一方面，因为对未来的预期过低，因此从一开始就没学到东西，就是一劣质码农；另一方面，行业整体上限不高，绝大多数人还在一门心思的拉低下限。
如此一来，未来哪还有好？
但是，这并不是全部。
事实上，正常的市场竞争下，谁落后，谁死。
因此，报社的程序员可以写出django，车库里的穷小子能折腾出google。
技术是需要积累的。只要学进去了，你的积累就绝不会是无用功。
因此，虽然按比例算，也许99.99的程序员果然是年纪大了就得滚蛋；但这不正是他们为自己做的规划吗？起初就什么都没学到、入职了也只会996没有任何技术积累——美其名曰“你需要掌握的东西，入职一个月内就能学到”。
呵呵，真这么简单全世界的大学都在坑钱不成？一个月就能学完的东西，非要把你拘禁起来教上本科四年硕士两年博士N年都还不让毕业？
你把自己当一次性用品培养，就别怪别人用旧了把你一脚踢开。
相反，那些真正知道四年本科要教你什么、知道你和世界先进水平还有多大差距的人，他们会抓住一切机会，不间断的前进，前进，继续前进。
我大一就自学到了中断服务程序、可以直接写端口命令字绕开OS/BIOS直接控制硬件；也知道动画、音频、视频、3D图形等等的基本原理；当时同学间流行一个打字游戏，但我觉得那个东西写的不好，于是花了一周不到就写了个更好的。
因此，我可以毫不含糊的吐槽——绝大多数本科生，四年连个大一水平都没学到。
比我强的车载斗量。
那么，本科四年我都甩开某些人四年，之后工作了，盯着那些比我强的紧赶慢赶，都不过勉强维持个“看得到别人尾灯”的局面；那么，一毕业就比我慢了四年、还以为一个月就学会了一生所需的全部知识的他们，有可能看见我车尾的扬尘吗？
不光我不担心自己学的东西没人要；那些比我强的没边的，照样不担心自己学的东西没人要。
甚至可以说，越是不顾那些庸人的眼光、我行我素学的精深的，越是不怕失业。因为人家的就业市场是全世界。
不是程序员这个职业越老越不值钱，而是现在的程序员处于工业革命早期煤矿工人所处的境地。
新的世界刚出现一个雏形，现在的程序员只是在用自己的血肉去充当地基和铁轨，铸造锅炉并充当点燃第一把火的燃料。
表面上看起来相对农民阶级（传统制造业），工业革命初期的产业工人收入待遇提高了很多，但是那是以压缩劳动寿命来实现的。
他们确实代表着先进生产力的发展方向（并且就像煤炭行业至今仍然是采矿和机械制造业最先进技术的集中展示平台一样），但是悲哀的是，他们自身却不是先进生产力。
程序员，都是内卷之王！
科技创新 • 大兴 发表了文章 • 0 个评论 • 71 次浏览 • 2021-04-16 14:47
前言
最近看到这个问题被谈得很多。铺天盖地的35岁、内卷化、996。这里也想谈谈自己的想法。
内卷化的形成
内卷为什么会形成呢？从公司内部的角度来说，同事之间做的事情也缺少独特性。那么既然每个人都差不多，那么与其招一个工作十年的人，还不如招个应届生。虽然说从代码的产出和质量来说，工作十年的工程师比应届生理论上来说应该是好很多， 但是如果工作十年的人缺少积累，缺少系统性的理解，那么跟应届生比较可能多了一些广度（因为换过工作）。但是深度上来说并没有本质上的区别。那么这个时候就会发生内卷了，公司不停的把老员工换成新员工，老员工也不停的跳槽导致缺乏积累，长此以往公司很难得到优质的员工，员工也很难得到深入的知识和技能的积累。
如果把这个发到公司之间，那么很多公司间的竞争也是重复性的，你做个朋友圈，那么我就做个拼圈，如果你做个金融服务，那么我也做一个。公司的产品决策并不完全是跟公司本身的基因和方向决定，而是因为什么方向火而赶鸭子上架。公司在做决策的时候考虑的是最少的投资和最快的回报，而不是靠着自己的特性而做长久的、独特的产品发展。在做这样重复建设的时候，公司可能会在竞争对手那里挖上那么几个牛人，然后其他的（包括UI）都照抄就好。长此以往，用户、客户很难用到更好的产品，而公司也很难积累出做出好的产品的能力。
从内卷到996
既然公司间都内卷了，公司做的产品跟别人的产品差不多，那么拼的就是手速了。如果竞争对手和你拿的投资差不多，那么招的人数也接近，如果竞争对手都996了，那么你955岂不是输在了起跑线上？同理，大一点的公司内部，团队之间也没有太多壁垒和界限，如果说你团队的输出能够替代另一个团队，那么让自己的团队拼一拼，把地盘占好，年底涨工资也是一个很美滋滋的事情。但是如果你这样做，别的团队也这样做，长此以往就没人不996了，最后你996也不够，只能007了。
我如何看待996
我今年工作刚好十年。我刚毕业第一年在阿里工作，团队的任务还是比较重，但是我一周也就两天会在公司吃晚饭。周末和晚上我也会花时间学习感兴趣的东西（当时是机器学习，还写了不少博客），真正晚上工作的时间不是很多。后来去了一个外企，基本上每天5点公司就没人了，我晚上就看看开源的项目，有时间贡献一下。过了两年我去了美国，第一年公司IPO前还比较忙，有时候晚上要在公司吃饭加个班啥的，后面IPO后公司也没人加班了，我周末和晚上不少时间都花在开源里面。最近这几年带团队，白天的会比较早，一周晚上也有那么几天有晚上的会，除了陪陪家人以外，有时间我还是会继续弄弄开源，看看论文和书。
我对于公司、团队级别的强制996是反对的，因为工程师做的事情应该是在更轻松的氛围里面创新，而不是被按在工位前出活。有些工作是需要很多的思考，特别是架构设计，还有职责划分之类的。996会让人缺少了思考的空间，对于那些资深的工程师或者架构师来讲，缺少思考的空间会导致最后出来的架构不是最优的，因为好的设计应该是想出来的而不是堆出来的，如果架构设计都出问题了，后面的工程部分会跟着错。对于管理方向的人也一样，如果缺少了思考的空间，管理者会更难为他人着想，更难思考团队到底需要和达到什么的目标，怎么做能够让公司受益等等。当你的时间都困在了工作中，长期来讲会产生工作的倦怠(burn out),对于身心、家庭、还有公司都不是什么好事。
但是另一方面我对于弹性的工作时间和短期的加班是可以接受的，比如说产品要发布了，或者客户有什么问题了，哪怕是周末或者晚上，我觉得也应该能够尽力帮忙，但是这样的加班节奏不应该是长期的、持续的、强制的。公司（或者管理者）不应该告诉员工这个时候加班，我的态度是，如果员工有一段时间特别忙，加班比较多，我会让他们去休个假，或者轻松一段时间。
我自己也一样，如果忙了一段时间，也需要从工作中脱离一下。因为忙碌的时间太久想要从中恢复很累，而且加班太多，导致心情不好的时候也会让家庭不开心，并且影响工作本身的效率。
工程师怎么避免内卷化
第一我觉得工程师要打好基础：不管是科班毕业还是转行。当你做上程序员的时候，就一定要打好自己的基础，基础包括：
-编程本身的技能：一定要写一手好程序，有好的编程习惯。
-写作、沟通的技能：能够写好的文档，做出清晰的沟通。
在工作的前几年，就要开始建立自己的社交圈，有一些值得信赖，互相学习、找工作可以互相内推的朋友，这样可以避免走很多的弯路。
在自己工作的范围内，看得比较深：因为你对于某一样东西有深入的理解后，学习浅一些的东西会很容易。比如说你做的是互联网的后台开发，那么深入理解一个或者几个分布式的系统很重要，如果做IOS app，那么对手机系统的内部工作应该是要很懂。
多阅读，多看看系统的知识，还有好的论文（比如说Google的论文）：这里我并不推荐付费的网课，相对网课，看看那些原创的书，比如说DAIA，算法导论之类的。会比只是教你刷刷LeetCode要好得多。当然LeetCode也是可以做做，不过不应该把它作为人生的追求。也建议看看管理、商业类的书，比如说硅谷之火，创新者的窘境之类的。
我建议这些能力在工作的3年内培养。
3年后，在有了这些基础后，对于业界和行业的发展应该会看得更清楚，而不至于走错大方向，比如说大家都在做SaaS的时候，你不应该花时间去学习太多windows 桌面的软件开发；选择一条发展更快的技术路线应该是避免内卷化的一个很重要的选择，如果方向都选错了那么避免内卷也很难。
另外跳槽的时候应该注意积累，每次跳槽应该是能够有更加深入的技能，而不是看钱跳槽（钱会自然来的）。如果每次跳槽都是换个方向平移重来，可能会导致工作十年跟工作3年的输出类似。
关于技术方向选型的一些建议
我个人觉得未来的后端软件发展逃脱不了两样东西：第一是云，第二是开源。在大部分的时候是两者结合起来的，因为云本身也用了很多开源的软件。相比自己造轮子，使用开源，并且贡献开源（重点）应该是第一选择。把开源软件folk出来，自己搞一套我觉得并不是很可取。因为这样跟做闭源的区别也不是很大（当然你至少会对那个开源软件有深入的了解）。你的第一选择是，能否把一些贡献给反馈回开源的社区。
如果你选择贡献开源，最好选择贡献有社区的开源软件，其中以Apache或者CNCF为代表。因为有社区的开源软件会走得更长、也往往会更成功，作为一个这样（成功的）项目贡献者你的价值就会越大。
如果你刚毕业、或者工作时间还很短，建议选择更新一点的方向，比如说你现在想要做后端软件开发，Go/Rust会比Java更好，Java比C++也会更好。（我这里这样说不是为了搞语言之争，我也知道C++ ver.17 有很多新的特性，也本来就有很多市场）。
如果两个差不多的工作机会，做云上的软件开发（比如说一个给餐饮行业做管理的SaaS），会比做传统行业软件开发（比如给餐饮行业做桌面软件）要来得更好。因为一个发展更快，空间更大的行业的内卷化就会越少。
管理者：如何避免团队内卷化
作为管理者而言，在做好公司的任务之外，也需要尽力避免团队的内卷化。
首先说说加班，虽然说短时间的996会给团队带来（不少的）产出，不过从长时间来看，团队会因为倦怠和缺少进步而缺乏后劲。长时间的加班会让团队心情不好，钱给够是一个方面，但是钱很难买来长期的快乐（我的经验是涨工资的时候很开心，涨完了过段时间就平静了）。相对用钱去刺激加班（给1.5倍的工资，干两个人的活），我觉得更重要的是让团队成员真正能够得到发展，能够喜欢自己的工作，这样的效果很正向：公司能够得到工程师尽心尽力的产品，而工程师也能获得发展，并且过程很开心。作为管理者而言，你自己可以加班，但是不要要求团队总是和你一起加班，偶尔一次可以，总是这样的话，团队会变得低效和士气低落。
跟加班类似的，管理者也不应该认为员工的所有时间都属于公司的，应该尊重别人的休假、陪家人、生病等等的时间。
那么怎么能够让工程师更好的发展呢？管理者应该和工程师多沟通，多1-1，了解到别人的需求和想法，然后根据情况给出不同的机会（比如说承担某个重要的功能开发、在某个meetup上面讲一场技术专题、做一个更好的设计文档）。作为团队的管理者，不应该假设“给你做这个功能你就可以进步和开心了”。
其次，在面试的时候也不要有很多不恰当的要求，比如说觉得35岁以上、或者怀孕的人就不应该要之类的，在我看来35岁的程序员可以有非常厉害的输出，对这样的程序员的歧视首先是非常的没意义，其次也会加速内卷、社会更加不公平和完全不必要的焦虑（35岁焦虑）。对于公司而言应该是看大格局（怎么打造一个别人更喜欢的产品），而不是纠结于比较low的地方（如果招了一个刚结婚的人，未来一两年可能需要休几个月的产假；或者35岁的人有娃，需要花时间陪娃、接娃上下课）。
草草写一点想法抛转引玉一下。
转载于公众号“码个蛋”
曾经风光无限的铁饭碗没了…网友评论：996卷走了955的他们…
科技创新 • 大兴 发表了文章 • 0 个评论 • 59 次浏览 • 2021-04-16 14:47
作为一个程序员，你刚毕业时候的梦想是去哪里呢？是BAT这些大厂？是自己马上就开始创业？
相信有很多一部分人，尤其是80后，最初的梦想是想进一个外企工作，微软、谷歌、甲骨文、IBM、HP等等等等。
可以说80后那一代，见证了外企在国内最辉煌的一段岁月，当时如果身边有哪个同学拿到了一个外企的offer，绝对是要被人羡慕半天的，尤其是那些大公司，真是挤破头皮都想进去，当时每个人都说外企的福利有多好、外企的管理多人性化，相比起现在国内IT公司追求的996标配，外企仅仅在加班费一项上足以傲视群雄。
但是再辉煌的君王也有落寞的一天，曾经那些个习惯了穿西装打领带喝咖啡讲英文的外企员工不得不承认，外企风光不再，可以说外企的黄金时代已经过去了。
这不，前几天有消息传来，巨头IBM的中国研究院（IBM CRL）已经全面关闭，关闭的悄无声息，在举国讨伐郑姓女戏子的热点追逐下，更是显得苍白无力、无人知晓。
IBM，作为大家熟知的行业龙头企业，有着一百多年的历史，哪怕IBM研究院，也可以追溯到上世纪40年代，比新中国成立的时间还早。
IBM中国研究院则是在1995年成立于中国北京，位于北京上地信息产业基地的西北角，坐落在中关村软件园内。当时绝对是一件轰动国内IT界的事情。
到了2008年，IBM中国研究院上海分院成立。
自从建立以来，据不完全统计，有过上千名研究人员在该研究院工作过或正在工作，其中绝大多数拥有中国乃至世界一流大学的博士和硕士学位。因为IBM基本不招本科生，当时硕士能进IBMCDL就已经很不错了，能进CRL的大多数都是博士。
说起IBM中国研究院的重点研究领域共有四个，分别是
行业解决方案行业解决方案，是指运用前沿技术解决行业的关键问题，这里指的关键问题是环境治理、电力与能源、物流与供应链、医疗、金融服务等各领域相互相成的一系列复杂方案，并非单单局限于某个狭隘角度。而是更加关注类似大气污染防治、可再生能源高效利用和企业节能这种关乎人类可持续发展的命运话题，往往一个研究计划就以十数年为周期。
认知计算最为知名的就是在2011年发明的沃森，它以IBM创始人Thomas J. Watson名字命名。作为一个自然语言问答系统，沃森甚至在美国的著名电视智力竞赛节目《Jeopardy!》中击败了该竞赛最长优胜纪录的保持者Kenneth Jennings，从此被世人熟知。
运算即服务IBM中国研究院主要从事物联网云计算、云计算基础设施与云服务、平台即服务(PaaS)的开发与研究。
物联网IBM中国研究院在高性能无线专用物联网通信系统、大规模物联网数据处理中间件平台等领域取得了诸多技术上的突破，并在2014年提出过物联网3.0的概念。
当年的IBM就像现在的BAT，聚集了国内最能干的一帮青年才俊，20年光阴转瞬即逝，当年的意气奋发现在亦早已成了40不惑，甚至50知天命。曾经的雄心壮志，还在吗？
现在的年轻人或许只知道击败了众多围棋高手的人工智能阿尔法狗，但实际上早在1997年，IBM研发的计算机深蓝（Deep Blue）就战胜了国际象棋冠军卡斯帕罗夫。当时的深蓝就是今天的阿尔法狗，当时的IBM就是行业的领先者。
而在深蓝的基础上，进一步通过机器学习，复杂算法和大规模数据库进化出来的就是后来的沃森，现如今沃森在金融领域的理财管理，保险业理赔，商业领域的社交媒体分析，医疗领域的慢性疾病控制，跨行业的呼叫中心服务都有着广泛的运用。
但是一个沃森掩盖不了IBM的日益老态，作为曾经的巨人，IBM已经连续十季度营收下降，仿佛预示着一个时代的落幕，更是一代在华外企的落幕。
其实早在前几年，就不断有曾经的巨头外国企业逐渐离开中国市场：
2015年3月19日，雅虎宣布退出中国市场，雅虎北京研发中心宣布关闭。
2019年，亚马逊宣布退出中国。
甲骨文，在受到了云计算的冲击后，曾经不可一世的甲骨文正式关闭在中国的研发中心，并裁减员工约900人。
尤其是近年来BAT、华为等国内大厂的崛起，习惯了996的程序员让加班成本无比高昂的外企更加不适。毕竟，再杰出的才华，在努力面前还是会被超越！
退出，其实是早晚的事情。告别，也是情理之中。
融云im小程序集成初体验
IM即时通讯 • 大神庵 发表了文章 • 0 个评论 • 131 次浏览 • 2021-04-15 15:15
最近领导让做一个小程序端的聊天功能，基于多方考虑，最终选择了融云的im来实现，那就先写个demo体验下吧。
首先呢，当然是查看官方文档，文档地址如下: https://docs.rongcloud.cn/v4/views/im/noui/guide/private/setting/include/mini.html
需要注意要在管理后台的小程序服务下将小程序的开关打开，否则会报错，相关的demo也可从后端下载到。
拿到sdk了，我们就可以上手集成了，嘻嘻……
由于是demo，暂时先把appkey和token配置写死了，放在了config.js中，appkey和token可以从管理后台获取到。
其次呢，我们需要把im引入，可以整一个公用的js文件，在此引入im sdk，初始化一个全局的im对象（在此呢需要注意im对象一定是全局的，不能赋值给小程序里面的data值，之前我就犯了错，赋值给了data，导致页面只要一调用setData方法就一直报Converting string to Json的错误，大家可以在集成过程中避雷呢）。
引入代码如下：
const RongIMLib = require("./RongIMLib-3.0.7-dev.js");
const config = require("../public/config");
const imInstance = RongIMLib.init({ appkey: config.appkey});
export {
RongIMLib,
config,
imInstance
}接着我们创建一个主页面，在这个页面中我们可以建立融云的连接以及获取会话列表。
connect() {
if (this.data.isConnect) {
this.data.im.disconnect();
}
imInstance.connect({ token: config.token }).then(user => {
this.isConnect = true;
this.getConversationList();
console.log('链接成功, 链接用户 id 为: ', user);
}).catch(error => {
console.log('链接失败: ', error);
});
},注意事项：在此需要注意安全域名问题，要不会报错，导致连接不上融云的服务。
1． 开发环境的话，可以在右上角的详情中的本地设置中将不校验合法域名的地方打上对勾。
2． 生产环境的话，可以参考如下地址设置： https://docs.rongcloud.cn/v4/views/im/noui/guide/private/setting/include/mini.html
这样的话就可以连接成功了，哈哈，第一步总算是跨出去了。
接下来我们可以在连接成功后获取会话列表，代码如下：
imInstance.Conversation.getList().then(list => {
this.setData({
conversationList: list
})
}).catch(error => {
console.log('获取会话列表失败: ', error);
});点击详情跳转到聊天页面,在此需要注意如果要获取历史记录的话是要开通im商业版-单群聊云存储的。开通后按照api使用说明获取就可以了，代码如下:
getHistory(conversation) {
const option = {
timestrap: +new Date(),
count: 10
};
conversation.getMessages(option).then((result) => {
var hasMore = result.hasMore; // 是否还有历史消息可以获取
this.setData({
messageList: result.list
})
});
}接下来发送消息等其他接口，正常调用就可以了，和web端sdk基本是一致的，参考官方文档即可，整个集成过程花了两三天吧，还算顺利。有不足之处还望大家多多指教，多多交流……
融云官网地址：https://www.rongcloud.cn/
融云开发文档地址：https://docs.rongcloud.cn/v4/
对抗疫情，让我们来一场酷酷的在线考试
WebRTC • 徐凤年 发表了文章 • 0 个评论 • 94 次浏览 • 2021-04-15 15:15
随着移动互联网的迅速发展，手机已经成为了中青年人身体的一部分，他们从起床到睡觉前的最后一分钟都不会离开手。最近几个月，受疫情影响，在线学习和在线考试再次成为互联网上的热门话题。
那问题来了，在线学习和考试如何保证学生的学习和考试的质量呢？慢慢的各大网络机构出了各种线上教学线上考试的功能，国家也推出来听课不停学的政策。作为一个 web 端的开发还是很好奇音视频这块功能的。选择了融云做音视频的三方，开启了我的探测路程。
功能构想
（1）学生端做直播 ，1 个学生三个视图（ 摄像头采集，屏幕共享，手机端采集）通过融云后台转码合图后推到 CDN ； （2）老师同时订阅并播放多个学生的直播画面，也可查看学生端采集视频的截图或前几分钟录像 ； （3）当老师发现某个学生需要警告或答疑时，老师可以进入单个学生所在房间 ，与学生连麦进行实时通讯。
学生端实现
（1）学生的角色我使用的是“主播”；在多机位拍摄时，需要两个设备，一般是一个 pc，一个移动端；两个端登录应用用一个账号，但是加入融云音视频房间时用两个 uid（此处有些小坑调试了很久才弄明白，pc 端创建并加入直播间，进行音视频推流；之后移动端加入相应的房间，也发送音视频流；（可以关闭麦克风 ，看业务场景需求）；调试完毕后 可以正常进行考试。
此处参考的是主播流程文档：https://docs.rongcloud.cn/v3/views/rtc/livevideo/guide/quick/anchor/web.html
（2）学生端在 pc 上通过浏览器登录考试系统；
（3）登录后电脑摄像头采集学生正面实时图像，学生还可以发出屏幕共享 ，手机端登录应用加入相同的考场，摆放在学生身后来捕捉考生整体视图；
（4）学生端应用可以调用融云提供的截图接口随时截图，以便给图像识别模块进行是否作弊的检测；
（5）学生端上传的面部头像，全身图像，屏幕共享图像；会在融云服务器上合成一个流。
教师端实现
（1） 老师的角色是“观众”；订阅多个学生输出的图像整体；观众观看参考的接口文档 ：https://docs.rongcloud.cn/v3/views/rtc/livevideo/guide/quick/audience/web.html
（2）当老师发现问题时可以查看指定学生直播流的前几分钟回放，需要开通实时录制，录制在 cdn 处。
（3）当需要警告或答疑时，老师可以进入单个学生所在房间，与学生做实时通讯。加入时可以只发音频。老师警告答疑参考文档：https://docs.rongcloud.cn/v3/views/rtc/livevideo/guide/joinManage/join/web.html
录制留存
（1）可以用融云云端录制；每个学生上传的所有视频流可以合图录制，以满足审查人员在考试后检查学生考试全过程有无作弊等情况。融云云端录制 ，可以上传多家对象存储，可以按需求选择音视频格式参考文档 https://docs.rongcloud.cn/v3/views/rtc/record/intro/guide.html
上图
成为主播的必备神器
WebRTC • 徐凤年 发表了文章 • 0 个评论 • 82 次浏览 • 2021-04-15 15:15
前言
本人是一个游戏爱好者，经常会在斗鱼或者虎牙看游戏主播的精彩操作，特别是近几年直播的火速崛起，各个平台都打着人人都可以成为主播的口号来获取直播流量，所以我就在想直播门槛这么低的吗！这个疑问直到我看到 融云的低延迟直播 SDK 才打消了。
那么这个低延迟直播 SDK 是什么呢？
工欲善其事，必先利其器！那么这个低延迟直播就是成为主播之路的神器。下面是介绍：
低延迟直播 SDK 可以满足 1 个或多个主播与百万观众实时互动，避免延迟带来的距离感，增加用户活跃，支持主播推流，观众拉流，连麦互动等功能，为方便开发者集成降低集成难度，直播场景和会议场景都用 RongRTCLib SDK ，可在 SDK 调用时用参数加以区分集成场景
也就是说通过集成 低延迟直播 SDK 我们可以自己实现一个主播平台，集成的方式也非常简单，快速集成分三个步骤：
1、首先您需要了解集成的前置条件：https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/quick/premise/web.html
2、完成前置条件后，开始实现主播端发布音视频流的操作：https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/quick/anchor/web.html
3、有了主播后，咋们也不能忘记观众端，观众端就比较简单了，只需要订阅主播端发布成功的音视频资源就可以了：https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/quick/audience/web.html
完成上面三个步骤后，您就已经初步集成完 低延迟直播 SDK 了，主播和观众就可以互通了，是不是很简单！如果您觉得集成比较麻烦，OK ！还有一个 Web 在线集成体验的示例，体验完后还可以直接拿到 demo ，跳转地址：https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/demo/web.html
如果您还想进阶更高级一点的，需要好好研究一下文档当中的其他功能，比如：
发布文件资源：Web 可以通过拿到本地音频、视频文件资源，进行发布。代码示例：
// 通过 video 标签播放本地音视频资源。
let videoNode = document.querySelector('#target');
let mediaStream = videoNode.captureStream();
let user = {
id: '请填写用户 ID',
stream: {
tag: 'custom',
type: StreamType.AUDIO_AND_VIDEO,
mediaStream: mediaStream
}
};
stream.publish(user).then(() => {
console.log('发布成功');
}, error => {
console.log(error);
});
发布屏幕共享资源：Web 可以通过 stream.get 方法获取屏幕媒体流。 仅支持 Chrome 获取屏幕共享资源。代码示例：
var config = {
height:480,
width:640,
frameRate:15,
screen: true,
desktopStreamId: 'desktopStreamId',
}
stream.get(config).then(function ({ mediaStream }) {
let user = {
id: '请填写用户 ID',
stream: {
tag: 'screen',
type: StreamType.AUDIO_AND_VIDEO,
mediaStream: mediaStream
}
}
stream.publish(user).then(() => {
console.log('发布成功');
}, error => {
console.log(error);
});
}, error => {
console.error(error);
});等等······还有好多扩展功能等您来发现！授人以鱼，不如授人以渔，哈哈哈，我们不仅能自己成为主播，还能创造主播，还等什么呢，赶紧试一下吧
融云发送文件和图片消息
IM即时通讯 • 赵炳东 发表了文章 • 0 个评论 • 103 次浏览 • 2021-04-15 15:15
前段时间集成了web端融云的聊天功能，但是只能发送普通消息，最近产品经理出了新需求，需要把文件发送和图片发送加上，那就撸起袖子走一遍。
官方文档说明地址如下： https://docs.rongcloud.cn/v4/views/im/noui/guide/group/msgmanage/msgsend/web.html
看过文档之后，才发现发送文件和图片消息是分两步的，首先要实现文件和图片的上传，然后拿到数据后发送消息。融云默认是存储到七牛服务器的，其实也可以上传到自己的服务器，由于是个demo，我暂时就存储到七牛啦。
文件和图片上传
demo地址：https://github.com/rongcloud/rongcloud-web-im-upload，用到的文件可以从以上demo地址中拿到。
上传暂时还不支持npm的引如方式，需要在html中引入上截图中的三个文件，顺序如下：
<script src = "./send-data.js"></script>
<script src = "../upload.js"></script>
<script src="./init.js"></script>
然后在input的change事件中，触发以下方法：
fileChange(evt, type) {
this.currentType = type === 'img' ? RongIMLib.FileType.IMAGE : RongIMLib.FileType.FILE;
const file = evt.target.files[0];
console.log('file', file);
if (type === 'img') {
UploadClient.initImage(this.config, (uploadFile) => { // 上传文件为: UploadClient.initFile
uploadFile.upload(file, this.uploadCallbacks);
});
} else {
UploadClient.initFile(this.config, (uploadFile) => {
uploadFile.upload(file, this.uploadCallbacks);
});
}
},config配置如下：
config() {
return {
domain: 'http://upload.qiniu.com',
fileType: this.currentType,
getToken: (callback) => {
this.rongIMClient.getFileToken(this.currentType , {
onSuccess: (data) => {
callback(data.token);
},
onError: () => {
console.error('get file token error', error);
}
});
}
}
},成功回调配置如下：
uploadCallbacks() {
return {
onProgress: (loaded, total) => {
const percent = Math.floor(loaded / total * 100);
console.log('已上传: ', percent);
},
onCompleted: (data) => {
this.currentFile = data;
this.getFileUrl(data);
},
onError: (error) => {
console.error('上传失败', error);
}
}
},注:如果是图片的话在onCompleted里面通过data.thumbnail是可以拿到图片的缩略图的。 接下来是获取文件或者图片的url，也需要在onComplete回调中获取，代码如下：
getFileUrl(data) {
if (data.thumbnail) {
this.currentFile.base64 = `data:image/jpg;base64,${data.thumbnail`;
}
this.rongIMClient.getFileUrl(this.currentType, data.filename, data.name, {
onSuccess: (data) => {
this.currentFile = Object.assign(this.currentFile, data);
this.sendFileMessage(this.currentType);
console.log('文件 url 为: ', data);
},
onError: function(error) {
console.log('get file url error', error);
}
})
},拿到文件或者图片的url之后就可以发送图片或者文件消息了。
文件和图片消息发送
发消息代码如下：
sendFileMessage(type) {
let msg = {};
if (type === RongIMLib.FileType.IMAGE) {
msg = new RongIMLib.ImageMessage({content: this.currentFile.base64, imageUri: this.currentFile.downloadUrl});
} else {
msg = new RongIMLib.FileMessage({name: this.currentFile.name, size: this.currentFile.size, type: this.currentFile.type, fileUrl: this.currentFile.downloadUrl});
}
var conversationType = this.targetUser.conversationType;
var targetId = this.targetUser.id; // 目标 Id
var callback = {
onSuccess: (message) => {
this.handleMessage(message);
},
onError: (errorCode) => {
}
};
this.rongIMClient.sendMessage(conversationType, targetId, msg, callback);
},至此，发送图片和文件消息完成，整体算是顺利……
融云官网地址：https://www.rongcloud.cn/
集成融云即时通讯碰到的一些问题
IM即时通讯 • 赵炳东 发表了文章 • 0 个评论 • 101 次浏览 • 2021-04-15 15:15
前言
公司产品需要新增即时通讯的模块，经过调研后使用融云的即时通讯 SDK 由于以前没有做过相关聊天类的项目，在开发的时候碰到了很多坑，下面会将碰到的问题和解决方案记录下来以做备份和学习交流
融云官网：https://www.rongcloud.cn/ 开发文档：https://docs.rongcloud.cn/v4/
问题列表
1、如何获取历史消息
解决方案： 因为 Web 端没有本地存储，不提供本地获取方法，只能从远端获取 使用获取历史消息方法需要在开发者后台开启 IM 商用版 - 单群聊云存储 服务，服务开通后 30 分钟左右生效 每次最多只能获取 20 条历史消息，通过改变参数 timestrap 来获取其他时间段的历史消息
2、删除会话后还有会话
解决方案： 1、删除会话. 正常来说只要没有收发消息, 会话就不会再生成了 2、如果您有清除 localStorage 的操作, 则 SDK 内部会重新拉取离线消息. 而会话列表是根据收发消息生成的. 则会再次产生会话. 所以建议您检查下是否有清除 localStorage 的操作. 如果有, 建议您只清除自己业务相关的 key 3、如果您换端登录, 则会再次收离线消息, 如果希望此时依然不显示删除的消息. 可以在您删除消息后发一条自定义消息比如: (1). 删除会话 A (2). 发送自定义消息, 标识删除了会话 A (3). 换端登录, 重复收之前已收到过的消息 (4). 收消息时收到了步骤 (2) 中发送的删除标识消息, 根据此自定义消息, 再次调用删除会话方法删除会话
3、怎样才能获取到加入群组之前的聊天记录
解决方案： 加入群组，融云默认是获取不到之前的历史消息，如果想获取到之前的历史消息，需要在开发者后台 -- 免费基础功能 中开通 “新用户获取加入群组前历史消息” 服务，服务开通后 30 分钟左右生效
4、消息中的接收方和发送方 ID 为什么是相同的
解决方案： 如果在接收方来查看消息的话，接收方 id 和 发送方 id 是相同的。 消息体中 targetId 表示会话 id （接收方），senderUserId 表示发送方 id ，messageDirection 表示消息方向，发送: 1，接收: 2 如果 A 给 B 发送一条消息，那么在 B 的角度看的话 targetId 为 A，senderUserId 也是 A，只是 messageDirection 为 2 表示接收 在 A 的角度看的话， targetId 为 B，senderUserId 是 A，只是 messageDirection 为 1 表示发送
5、删除历史消息时，参数与文档描述一致，但是结果却返回 33007 表示：未开通历史消息服务，但是开发者后台早已经开通了
解决方案： 因传入了比融云服务器时间还要大的时间, 所以服务返回了此错误码. 如果要保证删除成功, 建议传入会话最后一条消息的 sentTime (发送时间)
6、接收 emoji 显示不出来
解决方案： 1、Web SDK 接收消息后，消息体内的原生 Emoji 字符会被解码为对应 Unicode 码，需调用转化方法才能正确显示 2、不同浏览器, 不同设备, 展示的原生 Emoji 表情都不同 3、如需多端展示 Emoji 一致, 需使用 emojiToHTML 转化为 HTML 后再展示(此方法为以图片形式展示) 4、emojiToHTML 和 symbolToHTML 仅支持默认的 128 个 emoji. 展示更多, 需自行扩展 详情参考：https://docs.rongcloud.cn/v4/views/im/noui/guide/private/msgmanage/msgsend/web.html#emoji
暂时先记录这些，后续还有的话会继续添加进去，也欢迎大家进行补充，一起学习一下，笔芯 ♥️ ♥️ ♥️ ！！！
H5 如何实现直播
WebRTC • 徐凤年 发表了文章 • 0 个评论 • 93 次浏览 • 2021-04-15 15:15
目前直播大火，在看直播后突然想自己做个直播软件。想了想想自己做下，开始在网上各种找资源。直播嘛，那必然有主播端和观众端。经过一系列的考察后后来找到了融云，使用了他们的 SDK，一共用了无 UI IM 和低延时直播两个 SDK。
IM 用了连接和发送消息，选择的是融云的聊天室场景。
低延时直播分了主播端和观众端。使用 H5 作为观众端进行观看，使用 web 端作为主播端进行了直播。
功能点介绍
主播端
按照文档的思路，主播端用的 web 界面，使用的 chrome 浏览器。 涉及到的功能点：
主播分享视频
查看观众发的消息
回复消息
观众端
观众端用的 H5 实现，涉及到的功能点：
观看主播分享的视频
发消息
点赞
额，就是为了体验功能做的简单了些，没有弄那些礼物什么的有些麻烦。
实现思路
主播端
需要先初始化连接 IM，RTC 两个融云的 SDK，此处参考的快速集成 https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/quick/premise/web.html。
加入到房间中 https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/anchorManage/room/web.html#newroom。
发布视频资源供观众查看 https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/anchorManage/resource/web.html#publish
配置直播 CDN 推流地址 https://docs.rongcloud.cn/v4/views/rtc/livevideo/guide/manager/pushcdn/web.html
完成
此处仅给了我认为关键的几个接口，如果大家感兴趣可以自己细看下文档。有些高级的接口这边没有测试，不过看介绍可以设置直播视频的样式。感兴趣的小伙伴按照文档自行研究下吧。
观众端
观众端就很简单了，H5 的观众端仅需要订阅 CDN 推流的地址就可以看到主播的视频流，很方便。
总结
整体做下来大概零零散散用了两三天，UI 也没怎么最求在网上找了个大致的样式做了下。不过整体还好最起码基本的功能实现了。也算是自己做的第一个直播的小 Demo，还是很欣喜的。喜欢的大家可以体验下。
融云im撤回消息
IM即时通讯 • 赵炳东 发表了文章 • 0 个评论 • 85 次浏览 • 2021-04-15 15:15
由于疫情原因，公司基于融云做了个在线的聊天室，之前增加了一些聊天室的基础功能，最近呢由于需求补充，需要把消息撤回加上。 官方文档说明地址： https://docs.rongcloud.cn/v4/views/im/noui/guide/chatroom/msgmanage/msgrecall/web.html
撤回消息代码如下：
recall() {
const conversation = this.im.Conversation.get({
targetId: this.targetUser.id,
type: this.targetUser.conversationType
});
conversation.recall({
messageUId: this.currentMsg.messageUId,
sentTime: this.currentMsg.sentTime
}).then((message) => {
this.$message.success('撤回成功');
const msg = Object.assign({extra: {nickname: this.currentUser.nickname}}, message);
this.handleMessage(msg, false);
});
},在此要注意，撤回成功之后是不会触发会话的监听的，需要自己在成功的回调里面处理撤回的消息。撤回消息处理代码如下：
if (message.messageType === 'RC:RcCmd') {
const msg = Object.assign({tip: `${isSelef ? '您': nickname}撤回了一条消息`}, message);
if (messageIds.includes(message.content.messageUId)) {
const index = messageIds.indexOf(message.content.messageUId);
this.messageList.splice(index, 1, msg);
} else {
this.messageList.push(message);
}
} else {
this.messageList.push(message);
}当对方在消息监听中收到上述的消息时，也可以调用上述的方法进行撤回消息处理。
撤回消息现在是没有时间限制的，如果要加上时间限制，可以根据消息的sentTime处理。
至此，消息撤回已成功集成。集成中发现了一个问题，撤回的消息在会话列表中还存在，已经给融云提交工单，看后续能不能处理。
融云官网地址：https://www.rongcloud.cn/
融云开发文档地址：https://docs.rongcloud.cn/v4/
