## 菜鸡才看对错 每个微信群里总会有几个月经问题，比如摄影群里的等效光圈，天文摄影群里的长曝光好还是短曝光好。这些争论往往会引起很多人参与互相拍砖，甚至发展到人身攻击。但其实这些争论都有一个共同点：他们都是关于对错或者说correctness的争论。然而我觉得对错是一个非常不重要、没有价值的东西。我不是想讨论高手只看利益，或者主观题没有对错之类的抖机灵，而是真的觉得哪怕对于自然科学，对于工程来说，对错也是很不重要的事。 原因有三点： 1. 正确这个东西很难被定义，而且很容易被推翻。这个世界纷繁复杂，一个结论的正确与否非常依赖于它的各种前提假设。比如摄影群里大家吵来吵去的等效光圈，归根结底就是不同的人的前提假设不同，因而会导致不同的结果。而两边都觉得自己是对的，而且确实也都是对的，就会吵起来。而这种争论归根结底只是一种定义上的争论，就算没有到人身攻击的地步，最好的结果就是两边意识到自己的前提不同，并没有更深层的insights。 2. 正确是一个非常廉价的东西。比如哪怕我原来真的不知道一个知识，然后现在你在群里跟我讲了，那我就知道了。对于非原创的知识，它的获取本身并不需要长时间的积累，而只需要一个告知就可以解决。 3. 而且很多时候对正确性的追求是有代价的，这个代价就是叠甲。所有的结论都是能找到反例的。你说太阳从东边出来，我就说金星上面太阳是从西边出来的，你说错了。你说牛顿三大定律，我就说光速运动的时候牛顿定律不成立，你说错了。这些反例，你不能说它是错的，但它对于理解问题的本质、解决实际问题的价值是相当低的。金星上面的事情关我屁事。被杠多了自然就会开始叠甲。但叠甲会干扰我们的表达和理解。很多时候明明一两句话就能讲清楚的东西，因为叠甲要解释我不是这个意思，承认这里有反例等等。叠多了以后，想表达的东西反而藏在最里面，讲了半天大家也不知所云。这可能是对正确的追求带来的最大负面影响。 所以从这三个角度来说，正确的东西又难以定义，又容易被推翻，又廉价。很多时候还是distraction，实在不是一个非常好的追求的目标。因为别人说的东西不正确，而花时间在上面争论，甚至去大肆嘲讽，是没有意义甚至有害的行为。毕竟大多数时候，我们为社会创造的价值，不是说我们编了一个绝对正确的词典或者四库全书，而是我们真的把一个东西给做出来了。不是因为我们事无巨细照顾到了所有情况的方方面面、边边角角，而是因为我们抓住了最主要的核心目标、主流市场，因而获得了大家的认可。 ### 对错交给AI 而最近[AI和人类竞争工作岗位](/ai-it-impact.html)的讨论，也可以为对错的价值提供另一种视角。一个有意思的观察是，如果一个岗位的主要职责是确保一些东西是正确的，或者它做出来的东西的评价标准是对和错，那它往往就很容易被AI取代。一个例子是注册会计师，它的主要职责是做好compliance，产生一个正确合规的税务报告。对于简单的情形来说，TurboTax等报税软件已经可以很好的代替注册会计师了。另一个例子是低级程序员，这些程序员的职责是把一个非常明确的需求翻译成电脑能看懂的语言，也就是编程语言。现在电脑在简单的没有歧义的编程任务上也可以做得非常好，也可以变相替代低级程序员了。类似的，翻译和字幕组这种岗位也已经逐渐完全被AI取代。甚至，很多时候当我们想要去确保我们查找的资料是正确的时候，我们已经不会去问人，而会直接使用搜索引擎来搜索了。因此正确性或者说对错，不论是从人的角度来看，还是容易被AI代替的角度来看，都不是一个特别重要的东西。 ## 正确性不重要，那我去学错的？ 那一个很自然的问题就是，那如果我们说正确性不是一个重要的东西的话，那什么东西才重要呢？毕竟我们受到的教育非常强调，学习要记忆和理解正确的观点。考试也主要去考察我们的理解正确与否。然后你现在突然说正确性其实不重要，那对于我们学习一个东西而言，到底什么东西是重要的呢？总不能我们去学习错误的东西吧。 这里我觉得有三个东西是真正见功力的地方。Priority（纲举目张），Connection（举一反三）和Verification（知行合一）。 ### Prioritization 纲举目张 第一个是Prioritization，中文叫纲举目张。它的意思是要搞清楚什么东西重要，什么东西不重要。抓住主要矛盾，然后把主要的精力花在解决主要矛盾上。举个最简单的例子，我们电脑的硬盘满了，所以需要删一些文件来把硬盘空间腾出来。这个时候能找到最占用空间的那些大文件是最重要的。因为如果我们只是随机或者盲目地删除文件的话，哪怕删了十万个小文件，可能都没有一个巨大的临时文件有用。换言之在这里有两种解决问题的方法： 1. 拍脑袋想这个文件能删那个文件可以删，然后把它们都删掉，再看看有没有解决问题。 2. 明确这个问题的核心在于找到最大的文件，然后通过一些工具去真的找到它，找到以后把它删掉，这件事就很简单了。 而决定我们解决这个问题的效果和效率的关键就在于知道整个问题不同步骤哪个重要哪个不重要。只要明确了纲领，再往里面填写各种细节就比较简单了，这就是纲举目张。 而且在这里有一个小细节是，上面我提到问题的关键是在于找到最大的那个文件，以及如果我们盲目地删文件，可能删十万个小文件都顶不上那个大文件。这句话技术上是不正确的，它是可以找到反例的——有可能你删了十万个小文件真的就比那个最大的文件更大。但是如果我们过分强调正确的话，它就会让整个讨论走向叠甲的思路上去。比如在这里我可能就要去叠一个甲来说，问题的关键在于找到最大的文件或者文件夹，在某些情况下删除十万个小文件确实可能比删除最大的文件要更划算，但是它需要花费的时间跟精力更长。而这种叠甲一方面会打断我思考和表达的思路，另外一方面也会干扰你们对这个核心概念的理解，导致你们被distract。所以这是一个非常现成的，对正确性的追求反而妨碍了我们对问题本质的理解的例子。 ### Connection 举一反三 第二个重要的因素是connection，或者叫举一反三。它跟创新是很相关的。一个关于创新或者说科研的广泛的误解是，原来大家都没有注意到某个领域，比如说量子计算，比如说用AI来打游戏。然后有一天，一个英雄式的科研组或者是大公司注意到了这个领域，做了一个东西出来，石破天惊，重大突破，把人类的科技边界向前推进了一大步。 但实际上创新的过程不是这样的。在任何领域，都是很多人同时在做着不同方向的探索。然后他们彼此借鉴，一点一点把科技的边界向前推进。换言之，绝大多数的创新不是突变式的，没有一个英雄也没有史诗感，而是在一点一点的小步快跑中逐渐达到实用的程度。 如果你真的去看这些创新的论文的思路的话，你会发现其中一个非常核心的思路是把两样看起来好像没关系的东西给联系起来，然后用其中一个领域的现成的技术去启发另一个领域。最直观的例子就是仿生学。人类通过从各种动物和植物的形态和原理中获得启发，来设计自己的机械结构。在机器学习中间也充斥着来自统计学等所谓上流学科舶来的启发。所以我们也有个玩笑，说这种学科上下游就类似学科人体蜈蚣。在理论数学上有了一个新的想法，它就会先传到应用数学，然后传到统计学，然后传到机器学习，然后传到机器视觉，然后再传到更下游的学科，比如机器人学等等。而很多十几二十年前非常流行的科研领域，比如说Dictionary Learning，最近你又可以在Anthropic和OpenAI最新的研究中间找到它的身影，把这个非常老套或者说经典的idea和LLM一结合，又是一个非常好的论文。这个没有任何问题，不是说灌水，科学发展的客观规律就是这样的。 我最近在工程上也有了一些类似的感悟。我在做一个Machine Learning Project，训练一个模型来解决一个实际问题：看一个司机的视频，判断他有没有犯困。这个问题的特点是它的标注要求非常细致，牵扯到很多细节。即使是人类来看，往往也会觉得很难。因此，我就主导了一个项目去系统性地测量和改进我们的标注员对这个问题的标注质量。不测不知道，一测吓一跳，发现质量特别差。然后再分析和改进我们进行标注的方法，从而大幅提升了标注的质量，也大幅提升了模型的质量。 在这里，我知道整个项目的关键在于数据的质量，这个就是前面所说的prioritization，是纲举目张中间的纲。这比我知道这个模型里面每一层的数学推导，要有价值很多。而从另一个角度来说，我之所以知道这个东西很重要，其实不是拍脑袋想的，也不是说我经过了严谨的论证，科学的思考，完全独立地突然得到了这个结论。实际的原因非常简单，因为我在以前的工作中被同一个问题坑过，所以我知道这里是一个非常可能犯错误，从而导致我们模型效果不好的地方。这就是一个connection的典型例子。因为我有相关的经验，并且把现在面临的问题在一个抽象的层面上和以前的相关经验联系了起来，所以能够推断出整个项目的瓶颈在数据质量，并且和数据科学家合作来解决这个问题。在不同的领域建立connection，从而得出正确的priority，这是我在项目中间的核心价值。而不是因为我比人家写代码写得快，或者人家推公式都推得不对，我能推得对，才让我能领导这个项目。 ### Verification 知行合一 第三个真正有价值的东西是Verification，或者叫[知行合一](/be-an-observer.html)。它的最浅显的理解是我们不论有了多么优美的理论、多么复杂的Design Pattern、多么完备的管理思想、多么花哨的商业计划，都必须要经过实践的检验。换言之，No business plan could survive the first customer。不管是黑猫白猫，能抓到老鼠的就是好猫。 但是知行合一其实比这个要更复杂。问题的核心在于当我们面临的问题非常简单的时候，Verification是一个相当简单的事情。比如说你做一道LeetCode的编程练习题，只要一跑测试用例，对的就是对的，错的就是错的。但比如你做了一个比较大的网站出来。现在网站挂了，然后你有了一个假设说这个问题是因为X系统坏了导致的，怎么去验证这个假设是正确的，其实相对就比较困难。因为它牵扯到很多不同的组件之间的相互作用。即使你把X修好了，这个网站还是没好。这也不能立刻推断出不是X的原因。因为有可能只是因为这个更改需要一段时间传播出去，有个时间上的滞后性。或者是X系统挂了这件事把Y系统又搞挂了。你真的把X系统修好了解决了问题的根本原因，但是因为Y系统还挂着，所以导致你没有观察到整个网站恢复运转。也就是空间上的依赖性。这些时间和空间上的因素相互交织，就让Verification变成一个本身就变成一个非常复杂的问题。 而且现在我们所说的还都是各种机器之间的交互和依赖，还没有牵扯到人类。加了人类以后，里面有各种人，他们的利益和立场是不一样的。我们可以设计一些机制和政策来管理人类，但人类又会犯错，那整个问题就变得更加复杂。比如我们实际遇到的问题可能是我的这个广告推荐算法准确率确实提升了，但用户的engagement反而下降了，到底是为什么？就算我们有一些假设，比如因为我们降低了clickbait广告的展示几率，如何去设计实验来验证这一点也是非常复杂的，充满了不确定性。 所以要想做好Verification，尤其是复杂系统的Verification，牵扯到如何把大的问题分解成相对独立的小的模块，如何设计实验来最高效地归因找到问题的根源，如何设计验证的计划来让我们做的更改所产生的impact能最直接最有效地被观察到。这些都是非常复杂和充满门道的。总的来说，Verification的目标是即使是对于一个有多个因素相互交织作用的复杂系统，我们也能在时间跟空间两个维度上步步为营，频繁地验证我们的想法到底对不对，从而让我们有机会能修正未来的方向。 所以回到我们刚才的话题，如果正确性不是一个很重要的东西的话，那在我们的学习和工作中间，什么东西是重要的呢？我的答案就是这三点：Prioritization, Connection and Verification。用中文就是：纲举目张，举一反三，和知行合一。这个答案远远不是一个完整的framework，不是说你只要照着这三点走就一定能成功或者怎么样，但它是一个提纲挈领的价值观，它本身就是纲举目张里面的纲。所以我还是觉得这个观点是非常重要的，也是为什么我写了这么长的文章把它分享出来的原因。 ## 职场上高级职位也就高级在这三方面 而且，这个往往可以解决我们在职场上的很多困惑。比如，很多非常厉害的junior engineer会有疑惑：你看我老板，他一天到晚啥事不干，就会开会打嘴炮。他写代码也没有我快，文档写的也不咋地，红黑树都不知道怎么翻转，凭什么当我老板？这个时候就要用前面的思路想一想。其实写代码是不是正确，写代码是不是快，这些其实都是价值不高的东西。真正价值高的东西要看老板在指方向的时候，选project的时候，知不知道哪些是重要的，哪些是不重要的（prioritization）。通过别的组或者他自己以前的经验，能找到project里面的坑（connection），不管是技术上需要避免要提早解决的难点，还是组织上可能的陷阱，还是"这玩意根本就做不出来，快跑！" 然后在整个执行的过程中，老板要通过频繁的实验来微调整个项目的技术路线（verification），这些才是真正有价值的东西。 至少在工程方面，如果你去看[整个career framework](/senior-ic-thoughts.html)的话，会发现越高级的职位往往就越强调这三方面。如果用这些角度去观察公司里的engineering leader的话，往往更能够理解他们创造的价值到底在哪里。当你理解了他们创造价值以后，其实最重要的一步已经完成了，如何成为他们其实是相对更简单的一步。就类似提出正确的问题比对一个已有的问题给出正确的答案要难很多，也要重要很多一样。 但很遗憾的是，虽然正确本身是廉价的，是很容易获得的。但是我们上面说的三个真正重要的东西，要想获得它们是很难的。换言之，你在微信群里跟人拍砖，可能以前一个观点是错误的，被拍了以后，你就知道了正确观点是什么，你下次就记住，也可以去把它用起来。但比如说，我现在告诉你在机器学习里面，数据比模型要重要很多，你也不知道怎么用，因为它需要大量的项目背景，需要复杂的推理分析，还有长时间的经验积累才能真正做到理解这个东西。换言之，它是只能身教不能言传的东西，一定要Learning by Doing，要跟着一块做，在很多细节上不断地纠正和培养，才能获取到一个技能。 所以从这个角度来说，这三样东西对于把项目落地非常有价值，但对于讨论，尤其是在线讨论来说，价值相当有限。因为我就算把压箱底的一个Multi-Million Dollar Insight给说出来，你们也不信，而且我也很难在短时间内说清楚这个东西为什么是正确的。如果真的想要学的话，可能得一方面做一两个小时的1-1深度讨论，另外一方面真的带着去做一个项目，用比较长时间的传帮带才能够真正学会。 以上就是我想分享的主要内容。以后在网上拍砖，别再因为一个东西正确不正确跟人撕了，而需要更加关注别人对于Prioritization, Connection和Verification的思考。尤其是你佩服的人，看看他们对这些方面有什么观点和方法论，对于未来的成长很有好处。