TL;DR
- 为什么接口设计要表达清晰明确的语义？
- 为什么一次代码修改（cl/pr/commit）要有唯一明确的意图？
- 工作中为什么要树立自己的人设？
- 如何让 OKR 发挥作用？
- 如何三句话让客户为你的产品花钱？
智人的局限性：
- 每次只能做好一件事，记住一句话。
- 习惯机械地保持言行合一，且善于自我辩护（《影响力》）。
- 面临过多不确定性时难以做出决定（《影响力》）。
这些局限性每天都在影响着我们中的每个人，使得我们：
- 事情多了就容易忘、走神、效果不好。
- 没有明确的目标就会茫然、缺乏动力。
- 面对不了解的事物时缺乏勇气、动力，难以做决定。
相信我，在座的各位，在这些方面，很难不被称为垃圾。
承认这些局限性是我们取得胜利的第一步，第二步则是利用这些局限性驱动自己（或引导他人）做出更有利于我们的行动。
如何利用这些局限性？
- 突出目的，用尽量少的记忆量表达尽量多的信息量，有利于智人们在它们有限的记忆力/专注力范围内做好尽量多的事情。
- 公开表达自己的意图，减少潜在的不确定性，帮助智人们更容易做出决定。
- 公开自己的纲领，并坚持下去，智人们自然会根据它看到的纲领调整自己的姿势并自觉拥护。
总之，把问题简化，对谁都好。
以下讨论的主题从接口设计到公司治理，并没有什么新鲜的结论，只是试图从中归纳出一种统一的方法论。这很符合本文的主旨。
为什么接口设计要表达清晰明确的语义
接口设计要遵循什么原则？“高内聚，低耦合”。
什么叫“高内聚”？不同的元素之间，必要的交互越多，它们的聚合性（或称耦合性）越强。反之，就是“低耦合”。
我们可以把一个程序/系统看作一张图（Graph），每个元素看作一个顶点，元素之间的交互看作一条边。则接口设计、模块分割、微服务化，都在做着同一件事：聚类。我们找到一个元素集合，如果这个集合内部的聚合程序很高，但与外界的交互很少（或很统一），就可以将它视为一个整体，一个新的元素放回到图中。
重复这个过程，元素的粒度由细到粗，从函数，到类，到模块，到服务，等等，图的复杂度越来越低，直到符合智人的脑容量。此时，神奇的事情发生了。每次只能做好一件事，记住一句话的智人，可以不费力地理解一个庞大的系统（想象一下一个分布式的、微服务化的业务系统，如果细化到具体的函数，该有多复杂多庞大）。天哪，这么神奇的吗？
回看整个过程，我们可以找到其中最核心的一个操作（反复扣题），聚类。聚类意味着我们可以将多个元素的行为（或称语义）叠加起来，仍然视为一个元素，且只消耗智人相同量级的记忆量。这就需要我们为这些元素归纳出一个清晰、明确的语义。一句话，让你懂，尽管背后藏着千千万万的细节。
code review 时，有些听起来很 naive、很不高端的问题：
- 提出这个类的目的是什么？它有什么作用？
- 这些参数都是必要的吗？有没有重复的、可以由其它参数推导出来的部分？
- 为什么需要这个接口？
- 考虑到对称性，为什么不增加另一个接口？
是 reviewer 不懂吗？不一定，TA 也许只是为了减少未来读者（包括自己，也包括 1s 后的作者）的理解难度。给定一个类/模块/服务的名字，如果底下某个接口需要额外的解释，这个设计就还有提高的余地；如果每个接口都需要额外的解释，这个设计就是一次失败，会被无数次地用错、吐槽、直到被重构或抛弃掉。
总结：接口设计需要表达清晰明确的语义，争取一句话讲懂，多一句都差评。
为什么一次代码修改（cl/pr/commit）要有唯一明确的意图
- CL：Change List
- PR：Pull Request
- Commit：问 git 去
系统是由一次次代码修改组成的。我们要保证每次修改都可以用一句话描述，就需要它有唯一的、明确的意图。为什么？因为代码修改需要被阅读、被推理、被 review，而这些操作的另一边都是可怜的智人。而这些智人又通常是团队的瓶颈：人数越多，代码修改的生产速度越快；但 reviewer 通常跟不上这种速度。
行数通常是 code review 速度的一项关键因素：
- 一个 50 行的代码修改，通常扫一眼就清楚了；
- 500 行的代码修改就需要随手准备个小本本画一下依赖关系；
- 5000 行的代码修改则必须要拉上作者讲下前因后果，一点点抠了。
然而行数不是唯一因素。一个很长的代码修改，如果意图明确，不会很难读；混杂了多种意图的代码修改，即使并不长，也明显增加了 reviewer 的精力消耗。举几个例子：
- 5000 行的 code format 不怎么消耗 reviewer 精力，看一眼就可以放过。
- 5000 行的 code format，但里面夹杂着一个 bugfix 就要了亲命了，reviewer 需要一行一行仔细阅读。
- 既移动代码又对代码进行微小的功能修改，在现有的鶸 review 工具下，需要 reviewer 自己左右打开两份代码，手动对齐，再一行行对比。要是其中再加个函数拆分，谁爱看谁看，反正我不看。
唯一的代码修改意图（refactor 还是 feature 还是 bugfix）避免了 reviewer 的精力浪费或不该有的忽视，该精读的能精读，该略读的能略读。
接下来，常见的工作流程也要求代码修改的目的要单纯：考虑到 cherry-pick，一个代码修改最好不要包含无关的内容。
最后，唯一的代码修改意图也在展现着作者的能力，我有能力总结出一种意图，且将其具象化为一次代码修改，这不失为一种“太成功了”。顺便，这样也不容易搞出乌龙（如写出低级 bug），在众人面前丢人。
总结：一次代码修改需要唯一的、明确的意图，为他好，也为你好。
类似地，一个项目也要意图明确，三意二心的项目往往半途而废。
工作中为什么要树立自己的人设
瑞·达利欧在《原则》中说，组织架构最好是树状的，每个子树都要有清晰的功能定位。如前所述，这也是一种聚类。现在，我们翻转一下问题，你，作为树中的某个叶子节点，如何获得满意的功能定位？
我的答案是，要有人设。
团队中每个人都有自己的人设。A 技术很 NB 但做事没规划；B 啥都能做，还能为老板抗事儿；C 能力有限，但很细心，总能按时完成；而你，D，没有特点。
你怎么可能没有特点呢？你的野心（或称上进心）在燃烧，你也有自己的得意之处，你每天苦恼英雄无用武之地。但你缺少人设。人设是对一个智人的接口的一句话描述（又扣题了），你的所有内涵、能力、性格，最终也只能被归纳为一句话。这句话，就是别人想起你的第一句话。
相信我，大多数主管不是坏人，他不是不给你好活，只是不知道该给你什么活合适：
- 给需要深度的，怕你不会；
- 给需要审美的，又不了解你；
- 给有时限的，怕你耽误事儿。
于是，最后只能把你归为“其它”，给你别人挑剩下的活。好心的主管给你简单但无关紧要的活，不那么良心的主管就给你谁都不想要的活。
想改变这些，从立人设开始。你总是有擅长之处的，把它表达出来，告诉周围的人，告诉主管，说你想做，而且会做 xxx。立人设也是一种公开承诺。如前所述，智人拥有这种言行一致的倾向，当你立起人设了，你就会有自发的动力去维护它，这反过来会促进你强化这一人设，去学习必要的知识，练习相关的技能。立人设也可以简化主管面临的任务分配：现在的你对于他来说就不那么不确定了，他更容易做出决定。
除了与主管的交互，当你立起人设后，同事之间的交互也会更简单、更顺利。类比良好的接口设计，你建立人设的过程，就是在完善自己对外的接口。这套接口越好用，其他人越乐于使用。
接下来，立人设也不需要担心是否会把自己限制住。随着你的能力积累，其他人归纳你的方式也会变化，粒度越来越粗，从“擅长 xxx 问题”，到“技术大牛”或“项目推进大师”。智人们总是会用一句话来描述你的，别让这句话太无聊。
立人设并不是一劳永逸的，你需要长年累月的积累、坚持，稍不留神还有翻车的风险。但这很值得。
总结：立人设也是一种接口设计；它能简化交互，消除未知，降低主管与同事与你交互的难度；同时它是一种公开承诺，你会更有动力维护你的公开承诺。
如何让 OKR 发挥作用
一个组织需要一个公开的纲领，否则无法保证成员的凝聚力。
这句话是几年前从知乎上看到的，当时有人大概问了这么个问题：为什么一个政党不能隐瞒自己的意图。但现在找不到了。
（涉及政治的部分就略过吧……）一个公司是一个组织，它也需要一个公开的纲领。
工作几年以后，我们往往会把工作视作一种庸俗化的等价交换，你用自己的时间，从老板那里换钱。这种逻辑没错，但对于公司而言，只存在这种等价交换是非常危险的：公司需要员工的一部分超额劳动。
如果工作只是工作，这种超额劳动只能归为一种资本家的压榨。但有趣的是，很多智人会在工作中获得一些满足感，他们可能会把工作视为爱好，视为社交，最终主动地奉献一些超额劳动。很难说这算不算是智人的另一种局限性。我很认同一种观点，不要把工作与生活截然分开，去寻找那些你休息时仍然愿意做的工作。
成功的公司都或多或少意识到了这点，他们会想尽办法用最小的花销最大化提升员工的满足感、参与感，如免费零食、舒适的工作环境、定期的团建（翻车概率大）等。这里我们讨论公司的纲领，也就是 OKR。
OKR 是什么？它是一种方法论，你瞄着一个目标，制定计划，最终将结果拿来和目标对比。一个公司有整体的 OKR，老板会瞄着这个目标，制定自己的计划。顺着组织架构，部门可以瞄着公司的 OKR 制定自己的 OKR，部门总监据此制定自己的计划。接下来是团队、个人。
这个过程是自顶向下的，公司有一个纲领，一个目标，接下来每个部门、团队、个人，都根据自己所在的位置看到的这个目标的样子，制定自己的计划。这个过程中，每一级都只需要、且只能看到自己以上的 OKR，而不需要、也不应该关注自己以下的 OKR。大家都在朝着一个目标，只是因为所处位置不同而产生了不同的计划。这就是我对 OKR 的理解。
相比而言，KPI 则是自底向上的，每一级都盯着自己的下级，将自己的目标分解为下级的目标。这个过程中每个人不需要关心更上一级的目标，只要完成自己的目标，明码标价，童叟无欺，只是没有了那种凝聚力。
为了让 OKR 发挥作用，我们需要：
- 纲领要公开，不要藏着掖着。
- 纲领要明确、简短，让人看一次忘不了。
- 纲领要能坚持不动摇。
- 每一级都要明确地朝着这个目标制定计划，中间一旦掺杂了私货，下面各级都会走偏。
一个公开的纲领就像一座灯塔，可以为整个公司指引方向。这种明确的、唯一的方向的重要性不言而喻。电子的运动方向越集中，电流强度越大。公司的方向越集中，内耗越小，成员之间的协同效应越强烈，整体执行能力越强。这种成功反过来又可以提升众人对纲领本身的认可程度。
公开的纲领的另一个好处是可以筛选掉那些不认可它的员工。大家道不同不相为谋，不是坏事。反倒是不同思想的激烈冲突（或曰内耗）既耽误了员工，又影响了公司。
纲领本身一旦被公司成员所认可，如前所述，智人善于自我辩护，公司成员就会反过来为纲领辩护。这种辩护也是凝聚力的一部分。而凝聚力越强，公司抵御风险的能力越强，越能克服困难，在险恶的环境中生存下来。
如果公司还能将纲领坚持下去，言行一致的本能同样会提升众人对纲领的认可程度。
最后，所有这些的前提是，整个公司都能看到相同的纲领。如果有人将 OKR 替换为局部的等价交换，上述推理链就不复存在了。做个不恰当的类比，一个是“同志们跟着我冲”，一个是“弟兄们给我顶住”。
总结：一家公司需要一个统一的、公开的纲领，它能以低成本的方式增强员工的凝聚力，减少内耗，提升执行能力。
以上内容中，将公司替换为部门、团队仍然有效。
如何三句话让客户为你的产品花钱
最后顺便提一下产品定位。
一款产品，如果不能在几句话中讲清楚它的价值，就离失败不远了。智人那可怜的耐心与脑容量，当面对长达几页纸的产品介绍时，显得那么无助。你有且只有一次机会，用三句话，讲清楚产品的价值所在，接下来趁客户的脑细胞兴奋时，再去灌输那些细节。
这样来说，一款产品也要服务于一个目的。如果定位 TiDB 是一个关系型数据库，那么集成数据湖类的功能就显得很尴尬；而如果定位 TiDB 是一站式的数据处理平台，那么任何可以简化客户数据处理流程的功能都是在服务于这个目的。
一个需要增加一句话来解释的功能，会让这个产品更尴尬，而不是更强大。
总结：P 社加油。