我不想戳破你的泡沫，但如果这是第三次发生这种情况，那几乎可以排除 “不是你，是他们"。你的标题说你是因为 "不可或缺 "而被解雇，但除了这是个矛盾的说法，这也不是事实。你被解雇是因为你写出了同事们看不懂的代码，这对于一个程序员来说是一个关键的性能问题。

好的代码是可读的代码，也就是说代码是容易理解的代码，即使是新手也能看懂的代码_。你需要复杂而紧密的代码，而这些代码应该是由真正的专家编写和维护的，这种情况在现在是非常罕见的，而你显然不是在那些类型的公司工作。你所描述的听起来更像是 "花哨 "的代码，这些代码通常过于复杂，充满了高深莫测的编程技巧，并且需要花费大量的时间去琢磨和调试。这对于受过经典训练的人来说是一个常见的失败，一旦进入生产性环境，他们通常会被粗暴地唤醒。

这不是开玩笑的，我不忍心让这种情况发生第四次，这对我的精神上造成了影响。

这句话很重要，因为它表明你觉得是时候改变了。它表明你认识到这是一种模式，并希望这种模式停止。这种愿望可能是解决问题的最重要的部分。要解决这类情况，往往需要改变你自己的思维方式。这是不可能有人为你做的，所以你的改变欲望将是使改变发生的原因之一。

关于一些背景，我以前也曾遇到过类似的 “对我的工作来说，编码技术太好 "的情况，虽然从来没有达到你所描述的程度。我可以用C++中的模板元编程来治疗癌症，但我的许多同事几乎不懂面向对象设计的基础知识。我写的代码滥用了SFINAE，并且直接违背了C++规范的确切措辞，当时我工作的很多项目还在使用过时的、有错误的gcc版本。我的方法就是向他们展示这些工具有多么神奇，以及它能解决的所有问题。我喜欢向人们解释编程的小技巧，他们基本上都很喜欢。

这听起来是不是很耳熟？

"是的，但一个人应该有一个很好的水平来理解[Mik的代码]，因为组件是智能解耦的。”

从风险的角度考虑这句话。你的老板无论如何都需要把事情做下去。如果你离开去追逐一些很棒的工作机会，你的老板仍然要确保代码得到维护。你的同事刚才说的是，如果他们必须要替换你，他们需要找一个非常熟练的程序员，因为没有那么好的人是无法维护的。这是个风险。如果他们找不到足够好的开发人员，或者付不起足够的工资怎么办？

你可能产生了你所谓的 “好代码"，但 "好代码 "的定义非常取决于上下文。什么是 "好的代码"，在Google，他们有最前沿的思维方式，但对于在FAA工作的人来说，可能是非常糟糕的代码，他们主要关注的是可靠性，而不是跟上最前沿的步伐。你的老板对 "好的代码 "的定义包括在各种情况下，包括在没有你的情况下，都能维护好代码。如果你的同事们不愿意维护你的代码，那么你就会突然成为公司的_责任人，因为你生产的产品，如果你决定去其他地方，他们就无法维护。从本能上来说，这似乎是一件好事，但却充满了困难，比如这种基于风险的思维方式，你可能没有想到。

我们有一句话，"本末倒置"。与它相关的许多含义之一就是把你最关心的内容（能够使用你的高级技术）放在了应该推动它前进的力量（你的同事对这些技术的理解）之上。你用这种高级风格写出了代码，然后鼓励其他开发人员 "追赶 "到这种风格。这可能是有效的，但如果在他们 "追赶 "之前，你出了什么事，公司就会突然面临风险，因为没有人可以维护这些代码。

如何才能在未来避免这种情况的发生？

修复这种情况可能是一件非常困难的事情，因为这涉及到以一种与你通常所习惯的不同的方式来处理问题。与其先用这种高级风格写代码，然后教你的同事们如何用这种方式思考问题，不如把它翻转过来。教你的同事们喜欢这种风格的代码，然后开始用这种风格写代码。这可能看起来很落后，但它更稳定。从老板的角度来看，团队学习更好的代码几乎没有什么风险。一旦他们写出更好的代码，你想要开发的风格就会突然减少风险。

与此同时，你将不得不写出的代码，按照你的标准，是 "不那么好的"，但这没关系。你的代码不是你在这里的唯一产品。你的另一个产品是帮助教导其他开发者，其价值很容易超过写出 "完美代码 "的价值。”

当然，用你想写的风格写出的代码，可能很难说是安全的。如果很容易分辨，你现在肯定已经想通了! 你可以使用的一个强大的技巧是让别人去推动高级编码风格，而不是自己去推动。教别人学习继承和构成的区别是一回事。教给他们足够好，让他们主张改变你现有的代码库，让他们更清楚地知道什么时候使用它们，那是完全不同的事情。后一种情况真的让你知道，他们不仅明白了这个概念。但真正的拥抱它。

教学这种概念的一个理想是什么都不教。让学生们发现一些东西，然后你给他们指出这个发现可以去的方向。也许他们中的一个人发现了一些关于继承的整齐的东西，你可以根据他们发现的东西给他们指出Visitor的设计模式。不要只是给他们提供Visitor，而是给他们一个方向感，让他们自己去寻找Visitor。

这是一个更难的方法，你当然要在这和你现在的方法之间找到一个满意的中间，但这可能是非常有收获的。更重要的是对你的答案，它可以在没有风险的情况下为公司提供价值。如果你能为公司提供价值，而不给公司带来风险，你几乎不会被解雇。而在极少数的情况下，你仍然可以被裁掉的情况下，管理层会给出一个理由（比如经济不景气，或者公司方向转变）。如果你做得很好的话，你会发现管理层会开始塑造你的发展方向，就像你塑造你的同事一样，你会发现一个奇怪的趋势，那就是你在他们最需要的时候，学会了_正确的技能。

总是有原因的，

以前的一个老板和我的一个同事做过这样的事情。他的技术水平远远超过了我们的技术水平。 他不协作 3. 他没有按照车间的标准 4. 虽然他交付的东西比需要的多，但这不是一件好事 5.需要的是简单的，而不是复杂的解决方案

这几乎是老生常谈，但你必须成为团队的 “好伙伴”

编码只是其中的一部分。你必须要有人格魅力，善于沟通，谦逊到一定程度，在需要的时候要有傲慢的态度，遵守车间的标准，与同事相处，平易近人，在需要的时候能迅速提供帮助。

好的代码是很容易理解的，即使是对差劲的工程师来说也是如此。我经常收到的一个建议是 “如果会维护你的代码的人是个平庸的程序员，是个危险的精神病患者，知道你住在哪里，那就像编程。”

而这句话是真的。太聪明的编程是不好的，因为维护的时间比较长当你不懂代码的时候。在维护中，你经常会火的到处都是火，成千上万的客户被堵住了，而一个更聪明更有效的解决方案，很可能会比一个充满了重复的哑巴脚本般的代码，让维护者卡得更久。

当然，完全哑巴的代码也不好。在愚蠢和天才之间有一个很好的平衡点：既要高效，又要有可读性。这更像是一门艺术，而不是一门科学。这就是为什么聪明的概念，比如多重继承通常不建议使用。

你必须考虑到上下文。如果你在一家只雇用最优秀的小公司工作，你很可能能买得起一些异国情调的东西。如果你在一家法式银行工作，只依赖质量随机的顾问（有时他们很幸运，有时没有），而且每个顾问都有几百万LOC的领域需要维护，那么尽一切可能让平庸者一眼就能看懂，简单到让人一看就懂。不需要指针，不需要多重继承，不需要巧妙的技巧，等等。

你被开除的可能性不大，因为你太优秀了。我想这只是一个借口。

更有可能是行为问题，或者老板只是不喜欢你的原因，他不能告诉你，而不给你制造诉讼的理由。也有可能你是最贵的，他们相信FTE（即每个员工都是一样的），也有可能你是最贵的，

如果你真的那么厉害，你可以用好的方式让自己成为不可或缺的人：

–指导初级程序员。告诉他们不同方法的好处和缺点，让他们犯错，而不是告诉他们应该采取哪种方法。

–写出好的代码，让其他人很容易维护。

–以提高生产力的方式倡导最佳实践，而不是货物崇拜最佳实践，这些方法在纸面上听起来很好，但却会扼杀生产力。

解雇不可缺少的人实际上是一种合理的管理策略。当你的公司依赖一个人继续做他们的工作，而公司里没有人拥有他们的知识和/或能力，这就造成了一个巨大的责任：如果这个人被公交车撞死了，或者干脆选择离开公司去接受新的挑战，那该怎么办？现在，你的公司就陷入了一个_可怕的情况，因为没有人可以立即替换这个不可或缺的员工，而你又无法控制时间！

为了防止这种情况的发生，公司有两个选择。要么尝试着传播知识和/或提高不可或缺的人的同事的能力，或者在自己选择的时间将不可或缺的人开除，然后在准备好的时候，将其解雇，一举拿下创可贴，从失去的员工中恢复过来。

由于弥补知识尤其是能力上的巨大差距并不总是实际可行，因此解雇他们可能是比较合理的选择。与同事们分享你的知识，确保你不在的时候，有人能胜任你的工作。确保你的做法适合于你的公司中拥有平均水平的工人。如果你觉得平均水平太低，就和管理层一起努力提高这个水平。确保你所创造的任何东西都有足够的文件记录，而且这些文件的水平足够高，你的任何同事都可以用它来继续你的工作。

如果这三种情况中唯一的共同点就是你，那么你需要考虑的是你的某些行为有问题，

你有没有和你以前的同事交流过，请他们批评你？不是批评你的准则，而是批评你在办公室的行为。你和同事的沟通方式，你和老板的沟通方式，你做文件的方式，你在会议上的表现等等

你有没有设身处地的为你的上司着想？真的想过他们要做什么，他们的责任是什么，是什么让他们在关了办公室的灯回家的时候感觉很好？有很多很多的例子，有人站在其他软件工程师的角度写出了惊人的代码_，但公司却失败了。

我看了你的资料，上面写着 “你的代码应该比你自己更干净"。另外从你的评论中，你 "花了很多时间解释概念"，"批评是我作为工程师的工作的一部分”……

这可能是因为你说的是什么，也可能是你说的方式，很可能是两者中的一部分。如果你不能与团队相处，你会被解雇。这是你的问题，而不是（你想象的那样）你的代码太好。你的代码可能真的很好，但更可能是性格上的冲突问题。低下头来，停止告诉别人怎么写代码，跟着方向走，和别人一起工作，写出可维护的代码。这样你就不会被炒鱿鱼了。

我还饶有兴趣地注意到你的经理的这句话：

“但真的像他假装的那样好吗？”

这句话告诉你的是你的经理不信任你，你的经理认为你不真诚，认为你傲慢和/或对自己的能力比你实际的能力高。人际关系是靠信任来生存的。在这里请注意，你的问题_不是技术问题。你的问题与你的代码质量关系不大。你的问题是你与你的同事和你的经理的关系方式的问题。

人们并不经常因为不可或缺而被解雇为什么人们会被解雇)；这是一个荒谬的断言。你所引用的那篇文章明确地说明，"解雇 “不一定是让他们走，而是让他们不再是不可或缺的人（通过调动他们，强迫他们不参与某个项目，等等）

虽然过度合格有时不会让你被录用–但也很少会让你被解雇。好的员工是很难找到的；没有一个合理的公司会因为他们太优秀而解雇他们(除非你只是为一个白痴工作–那他们是在帮你一个忙)。

如果你在和一群本地人一起搭桥，当其他人在系绳子的时候，你可能更聪明或更有教养，但你已经成为团队的害群之马，问题就出在你身上。

作为一个经常参与招聘过程的人，我宁愿选择一个好的、有人格魅力的人，也不愿意选择一个伟大的、潜在的癌症。

每一个程序都是与两个受众沟通：一个是让程序执行的编译器或解释器，以及一些读懂了的人类。你可能与编译器沟通得非常好，但仍然写出了糟糕的代码，因为它不容易被其他人类理解。

通常情况下，一个编程团队有一套语言、框架、技术等，团队中的每个人都知道。

使用这套之外的东西对雇主来说是有代价的。比如说，假设你是团队中唯一熟悉框架X的程序员，而其他人都熟悉一个旧的框架Y，这个框架用于一些现有的代码，而且几乎和X一样好。

使用框架X是一个错误，除非它比Y好得多，以至于管理层同意使用它的技术收益足以证明培训工作的重要性，让每个人都熟悉X。看看他们要问的内容是什么，然后考虑一下你如何重写这些部分，让他们更清楚。你越是把不理解你的代码作为代码中的缺陷而不是读者的缺陷，你得到的反馈就越好。

我对这个问题的解读是，你从入职的第一天起，就注定了你的这种待遇。你说你被录用是因为你拥有公司里其他人没有的技能（TypeScript、Node）。而现在，你费尽心思制作了一个优雅的、专家级的、复杂的解决方案，独自一人，没有人理解你所做的一切，因此你被管理层视为一个累赘。

如果这些都是真的，那就真的没有其他的办法了。

在我看来，问题是结构性的，而不是个人的问题，因此，问题的责任在于情境和过程，而不是人：

–组织雇用了一个人，他的技能与其他人完全不同，而且是在这些技能的高级水平上，来执行一个关键的职能。这就保证了，如果你表现出色，你将是唯一一个理解代码的人，这对组织的任务至关重要。(指望一个高级别的资源能让一个不懂代码的人立刻就能理解的代码是完全不合理的) –组织没有定期对你进行代码审查。如果他们有的话，你的代码会被拒绝，直到你的代码符合他们的可读性标准。因为你是代码的唯一贡献者，有自己的风格，并且使用不同的技术栈，所以几乎可以保证随着时间的推移，代码会越来越不容易被其他人理解。要防止这种情况的发生，你唯一的办法就是在流程之外，不断地要求别人进行代码审查，可能会引来别人的指责，浪费别人的时间。这样一来，缺乏代码审核流程，就会让你陷入失败的境地。

我的背景中也有类似的经历。有一次我被录用，是为了填补一个技能上的空缺。当时公司里没有人有突然需要的技能。我的工作做得很好，几个月后，冲突就开始了。我是唯一一个能在应用的某些组件上工作的人。我成了一个瓶颈，因为工作堆积如山，只有我自己能做。有一天，公司决定用全新的代码替换掉我所制作的一切，按照他们的方式来做，我被排挤了。当时我的自尊心受到了伤害，但现在回想起来，这对公司来说是个正确的决定。在那里多待了一段时间后，是时候让我继续前进了，而我做到了。

如果这听起来很熟悉，也许是时候让你继续前进了。也许管理层甚至会把你重新分配到其他的事情，如果他们继续重视你的技能。或者，如果你能忍受的话，也许你可以帮助重写你在企业标准技术栈中所做的一切。如果不可能，那就直接离开。不管是哪种方式，你的代码很可能就会被送进垃圾桶。这大概是他们应该做的正确的事情，如果没有人理解的话。而且不管怎么说，这是他们选择的自然结果。

确保在你的下一份工作中，你的团队中的其他人都在应用和你基本相同的技能，尤其是他们有一个代码审查的过程。当他们要求你以某种方式改变你的代码时，就去做。在代码通过代码评审之前，不要认为代码已经交付，你的同行会告诉管理层（如果被问到的话），是的，这个代码很好。然后就没有问题了。在技术面试中，问一些类似这样的问题是完全可以的；我已经问过很多次了。希望这个研究过你的代码的其他开发人员能给你一个很好的参考。

作为一个注脚，如果你至少要对你一个人工作的情况负责，没有得到其他团队成员的买通，那么你至少也应该对结果承担一部分责任。(当别人想使用其他东西时，你是否推动使用TypeScript / Node？你是否使用了最新的、最酷的库或技术，即使更基本的东西也会做得很好？我也有过一两次这样的经历。) 如果是的话，一定要从这个结果中吸取教训。但如果不是，那就把这个经验带到你的下一个岗位上，昂首挺胸地去做。

大部分的回答都是从你的代码是否可读性或是否像你说的那么好的角度来对待你的帖子的。但这种情况在各行各业都有可能也确实发生过。我曾在拉斯维加斯大道上做过一份21号贩子和浮民的工作。我的技术和速度远远领先于他们的其他人员，以至于被派来监视我的人无法跟上。换句话说，他们无法听从我的决定。由于大额的资金在几分钟内就完成了交易，他们经常感到困惑，会向他们的上级报告我，说我犯了错误。我总是会为自己的行为向那个人平反，但他们对我的不信任态度越来越深。我被解雇了，失去了一个非常好的职位。

教训很简单，你必须把自己降低到别人的水平。如果他们每小时只出15只手，而你出100只手，那你就不是在激发赞美。你是在激发别人的嫉妒，甚至是仇恨。如果你的自尊心做不到这一点，那你就要找其他的谋生之道，因为所有的地方本质上都是一样的。人就是人，你无法改变他们。我最终还是安身于其他行当，我也是平庸的，因此没有脱颖而出。希望你能理清这个问题，对你有利。

决定将我的评论升级为答案：

**很好地记录你的代码。

有可能你根本没有你想象中的那么好，但为了礼貌起见，我会假设你知道如何写出正确的复杂代码，以降低整个代码库的复杂度和时间要求，减少一个数量级。事实上，这甚至是可能的，这让很多白痴感到惊讶。他们认为这是一个令人难以置信的命题，而说服他们的唯一方法就是向他们展示。

但这需要技巧、勇气和自我控制。你需要把重点放在三件事情上，然后才是最重要的：证明自己不是威胁，让白痴们看起来很聪明，永远不要让一个白痴知道你是个白痴。如果你不能带着自己去做这三件事，你就会失败，而且是你的错。务实是必须的，不能有任何骄傲的余地。

虽然我不能向所有人推荐这种方法，但对我来说，一直以来对我有效的做法是，有时不理会敌对的白痴告诉我的事情，我就会不去理会。相反，我想办法去做我想做的事情，在很短的时间内制作出他们中的许多人都看过的最好的软件的代码，然后我以这样的方式呈现出来，让他们的老板们用光辉的赞美来奖励他们。即使他们没有参与创造它。甚至在他们积极反对的时候，

对吗？难道我的工作不应该得到全额奖励吗？难道我真的要在大家的情绪中跳舞吗？无关紧要。这就是现实。如果我不适应，那我就是白痴。

有很多聪明人认为高技能的开发人员是不可替代的，这就是为什么你do想要他们。但你也看到了你问题的其他答案—-大多数管理者不想处理一个技能水平参差不齐的团队的问题，也没有选择走纯粹的高技能。他们也不一定是错的，问题是真实存在的，高素质的代码超出了大多数人的能力范围，他们所能雇佣的人的利益就会大打折扣。

如果你的能力哪怕是和你说的差不多，那么你的工作就不匹配。

如果你因为这个原因失去了几份工作，那么在HR、招聘人员和经理看来，你会很难看。

最后，我必须补充一点，你应该尽力去诚实地评估你的技术水平是否真的有那么高。听起来好像是有证据证明是这样的，但大多数人都认为自己的技术水平比自己高。另外，很多开发者会经历一个阶段，即他们在某一种方法上变得非常优秀，但还不一定能把所有的东西都拼成一个全局最优的方案，仍然缺乏灵活性。比如说，有时候，如果你知道你所拥有的人无法维护一个更复杂的方案，也不可能雇佣其他能维护的人，那么你可能会选择一个劣质的方案。

针对这个问题，

以后怎样才能避免这种情况的发生呢？

–找一个当地的演讲会分会，积极参加，并赚取成就。一些看起来很明显的东西，就像反馈一样，有望成为你最有价值的技能之一。

• 练习成为学生而不是专家。你看过【这个Jon Skeet的基础知识讲座】(https://youtu.be/jGUoF-uByGg)吗？你能想象一下，如果我们所有人都做这样的文档，会让大家都受益匪浅，在团队的各个层面上都会受益匪浅！

• 一个团队不是一个人。你的团队会在集体中成长和提高。你必须要帮忙。如果每个成员都是一个细胞，朝着不同的方向发展，那就不是一个团队（例如，你的水平更高，而最新的成员停滞不前）。2小时的会议是一个好的开始。我想在此基础上，再加上N天的配对轮换。这是1:1的时间，你赠予你的队友****和他们赠予你。在你的情况下，向着导航员的角色倾斜，让你的伙伴开车。练习不写代码，听起来很奇怪。

• 在当地的Meetup和Hack-a-thons上做志愿者。它可以迫使你提炼出你的代码，因为目的是为了合作，而不是建立一个容错的能源公用事业网，对吧？

–在每一个练习中，尝试一下这个概念：通过服务来领导。你如何去做一个任务或完成一件事，帮助另一个团队成员的需求？

–正如所指出的那样，为开源项目做出贡献，以获得更多关于你的代码的角度。他们可能会确认你的才华，但也可能会强化你从你现在的老板那里听到的建议。充其量，一些审查会给你一个新的想法。

–找一个比你更优秀的工程师。要想成为房间里最聪明的人，并不是提高自己。有一句话（我的googling是在Olgivy/Ford/Sorkin之间分裂的）解析为："如果你的周围都是不好的人才，你就无法学到更多的东西"。

我想假设你所描述的情况和你说的一样。我不能说我有过这种确切的经历，但有些方面我很熟悉。我不知道在法国的情况如何，但通常大公司并不重视内部开发人员的技能，尤其是当他们不是以技术为中心的公司时。我把这主要归因于这样的公司的经理们往往不是技术背景的，或者因为他们从来都不擅长开发，所以才离开了开发。即使你的团队没有使用这些可怕的东西，也有可能是公司的管理层对开发团队灌输了一种反智的观念。实际上，我曾经有一个经理当着我的面告诉我说，我很聪明，可以做一个给定的解决方案，但后来没有人能够维护它，所以我们需要购买一些东西（架子软件），所以我相信这种情况会发生。一个重视高技能的开发人员的公司。不过，你可能要面对不是最好的开发者的问题。如果你是一个有抱负的厨师，你可能会不高兴在麦当劳工作。他们不需要厨师，他们需要的不是厨师。他们需要的是遵循食谱的人。你可能是厨师的材料，而这家公司（和其他类似的公司）就是麦当劳。你需要问自己的问题是，为什么你还没有做到这一点。

不要和任何人合作，除非你合理地保证他们的编码标准与你的编码标准相匹配。这意味着拒绝任何工作，如果有以下****的情况，就拒绝任何工作：

• 他们在面试过程中问你编程问题
• 他们有同行的编程练习
• 他们要求你提供代码样本，并且可以接受
• 你可以看到他们制作的一些代码

我如何避免这种情况在目前？

这一点已经在其他答案中提到了。我第一次管理一个实习生的时候，我几乎把他制作的代码全部抹掉了。当我看到已经犯了什么罪的时候，我简直是怒不可遏(幸好我没有目击者:P)。

你需要鼓励同行编程，代码评审。和另一个程序员坐在一起，试着一起写2、3个小时的代码。丢掉那些可能太难解释的概念（比如说Java 8的新的高级功能），解释那些比较容易的概念（继承）。

有些时候，在和别人聊天的时候，你要 “哑巴"，这样才不会得罪人。特别是如果你的水平远远高于你的同事，当你讲到一些他们可能应该知道但不知道的技巧和事实时，他们很可能会反感。你甚至可能需要在评论中 "证明 "你为什么选择了这种编码方法而不是另一种编码方法。你可能是最好的编码员，但如果你是团队内部的，你必须作为一个团队来工作。

如果作为一个团队工作的意思是背着你的一只手工作，（我这里的意思是按照他们的编码偏好），那就去做吧。

几乎你所到的任何地方，只要你是团队中的一员，他们都会对你的编码方式有一定的指导，而你需要遵循这些指导。

我们不能长期依赖他

这才是最主要的问题。他们不愿意依赖你，但你被录用是因为他们实际上是在依赖你，

你可以用：

• 反正你也没想过去别的地方，所以他们可以长期依赖你，

我觉得我是在挑战问题，让我的技能得到发挥，所以我觉得我终于找到了一个可以长期享受的工作场所

• 你愿意为其他团队成员提供培训，为团队提供进一步的价值。

我发现别人的代码并没有真正跟上最前沿的软件开发技术，这不是问题，我可以完全停止使用这些技术，但是如果大家都开始逐步使用这些技术来提高团队的绩效，那将是有益的。我可以帮忙。

• 你被要求实现XY的功能，在时间内完成这些功能需要你的技能，这些东西可以用不同的方式来完成，但需要更多的时间和额外的bug的风险。我真的很努力地把事情做得很好，我做到了，但我担心不是每个人都能理解，相反，我想花一些时间来让别人理解。总之，团队里至少有2个人了解你的工作。你和你的同事。而且以后有可能会有更多的人理解你的工作。基本上你不是团队的瓶颈，他们担心你以后会成为瓶颈，然而。反正他们应该投入一些时间去培训。

阅读【马车、黑鸟和萨博】(https://CJSHayward.com/blackbird)**。_应该会引起你的共鸣。

我过去也有过类似的问题；我也学会了一些应对的方法，但我们都是用拖把和水桶来尝试清理消防水带的输出。你也可以阅读【外星思维理论】(https://CJSHayward/theory-of-alien-minds)**。