在我看来主要有三点
中心化答案排序机制
多层次，有效的传播机制
早期极为优秀的运营
中心化答案排序机制
提到知乎，我们脑中首先出现的概念就是“问答网站”。但大部分人其实并不理解“问答”这个形式对知乎的重要性。问答不是另一种论坛，而是全新的玩法，是知乎的心脏。它一方面带给优秀答主正反馈，激励他们源源不断地输出；同时限制了另一部分人能获得的正反馈，缓解了社区的毒化。
由于答案排序机制的存在，加上对算法持续不断的微调，知乎成功使他的用户相信，答案质量高 = 排名靠前。在刚混知乎没多久的时候，我写过一篇文章《漫谈Quora，知乎和StackOverflow》，里面描述了被点赞带来的那种成就感。这种成就感，相信非三零用户都体会过。如果不考虑机器人刷赞、恶意抱团踩答案、管理员删除&折叠答案等特殊情况，排序确实能在很大程度上反映答案质量。那些肚子里有货，能写出好答案（我们暂且不深究“好”的定义）的用户容易拿赞，容易排在上面，受此激励，他们更喜欢回答问题。这些答主源源不断地生产优质内容，构成了知乎的基础。
答案排序机制还有不那么为人所知另一面。咪蒙曾是公众号界呼风唤雨的女王，她在知乎却并不活跃。假设咪蒙拿出同样的劲头经营知乎，是否能取得一样的成绩呢？我认为不能。不光咪蒙不能，很多别的 KOL 也不能。为什么？这就涉及到答案排序的另外一个特性：它限制了那些观点不符合社区“主流审美”的用户。
首先我们必须搞清楚，知乎的主流审美是什么。虽然知乎上的话题范围很广，但观察那些排名靠前的答案和粉丝众多的答主，我们不难发现某种共性的存在。我把知乎社区的审美总结为四点：专业、理性、真实、幽默。限于篇幅，这里就不一一展开了。总之，知乎是不是“985遍地走”我不知道，但社区的整体审美确实是精英化的，毕竟这几点都非常符合大众对精英的印象。社区审美的建立并非一朝一日。知乎在早期首先通过邀请制和运营培养出了萌芽，之后随着社区氛围的确立，越来越多喜好相似的用户加入进来。当然，我们不能把知乎这家公司、知乎用户同知乎社区混为一谈。我这里并没有说知乎公司，或者知乎用户如何，而只是说，社区形成了这种文化。
说回咪蒙。咪蒙粉丝众多，只要一出手就是 10w+。这在微信里玩得转，在知乎就行不通了。想当知乎大V，必然要参与一些全站热点话题的讨论，并至少拿下若干个高票答案。这种情况下，一个答案会被知乎用户集体审阅。一旦用户达到一定规模，他们的赞和踩在统计上总是会呈现之前所说的倾向。尤其是知乎中“踩”的权重很大，经常能看到一些高赞答案排名靠后，多半就是被很多人踩的缘故。因此，你能讨好多少粉丝不重要，关键在于不可惹怒大众。你得能写出符合社区主流审美的答案，而这一点咪蒙就做不到。实际上，咪蒙的文章恰恰是反着来的：不专业，情绪化，编故事，不幽默。她的文章或许读起来很爽，在小圈子内极易引起共鸣。但若是放在一个更加大众化的社区里，这类文章只会带来无休止的口水和战争，并且会分散用户对更有价值话题的关注。然而这一切并没有发生，因为答案排名机制限制了小圈子的存在，使得成百上千个潜在的咪蒙要么离开知乎，要么在知乎默默无闻。当然，我们不能说所有不符合社区主流审美的答主都是毒瘤，这显然过于武断。但我认为这些用户无法获得足够的影响力，的确延缓了知乎的毒化。事实上，即使知乎落到今天这般田地，我认为社区也始终保持着极强的自净能力——衰落更多的是由大环境导致，这里我们就不展开了。
总结起来，知乎的问答 + 排序机制，即是红细胞，又是白细胞。它一方面给社区带来了优质的内容，另一方面有效阻止了社区的毒化。知乎并不是一个恰好成功了的问答网站，问答正是它成功的核心。
多层次，有效的传播机制
NND 打了一大段 Typora 给我退出了。反正知乎能用很多方法让你看到一个答案就对了。
这里还想从答案曝光度的角度说一句。现在很多论坛，比如虎扑，也提供了某种帖子排名机制。虎扑中，被“亮”（基本等同于赞）得越多的帖子排名越靠前。然而，一个高赞答案的曝光度远比一个虎扑亮帖要多，因为在知乎，每一次点赞都是一次传播——一个万粉大V的点赞会把这个答案发到其关注者的时间线上，往往能间接带来几十几百个点赞。这种滚雪球般效应给优秀答案带来了可怕的曝光量，传统论坛无论如何也模仿不来。排名 + 传播，给优秀答主的正反馈是非常足的，也在一定程度上导致了知乎的马太效应。不过不要紧，虽然开头比较难，只要你有一个答案火了，一般能涨到千粉。随后不管你写什么，至少传播上的阻碍已经没有了。因此知乎虽然不会专门推荐新人，但新人只要有能力，起步并不算难。归根到底还是看一个人能不能输出符合知乎社区喜好的答案，这就又回到前一节说的审美问题了。
早期极为优秀的运营
虽然我并不是早期用户，但对知乎在起步阶段的运营也有所耳闻。优秀的运营带来的影响是非常深远的，像之前说的社区主流审美，想想也知道绝不可能自然形成。我们暂且不把知乎和更娱乐化的平台比如微博抖音对比，就说在很多人心目中高大上的 Quora。Quora 的运营在我看来不如知乎。一个很简单的观察是，Quora 上极少极少见到长答案——这里说的长，是指那种占几屏，几乎像一篇小论文一样的答案。长答案就一定优秀吗？未必。但长答案包含的内容往往更加丰富，更关键的是，写一个长答案付出的心力可能是短答案的几十倍。对于快节奏下的现代人来说，发微博写 tweet 才是符合人性的，花几个小时查资料写大段文字是反人性的。而知乎能够做到在 2011 年起步，花不长的时间就打造了一个大家乐于写长答案的社区，运营绝对居功至伟。实际上，我压根想不到除了知乎外，还有哪一个社区能看到如此多大段的文字。额，或许只有 Medium？然而 Medium 本身就是博客平台。
关于知乎的成功大概就说这么多。最后还是想感叹一句，纵然知乎已如此优秀，在时代的洪流面前，依然显得那么不堪一击。这就和人一样，能决定自己命运的，往往不是自己。
P. S. 前段时间写了一个项目，欢迎尝试。
本来是打算写这么一篇文章的，然而预估了一下耗时，发现可能要花一整天。算了，还是录一期播客吧。
这是录音提纲，实际上我们不止聊了这些。录播客还是比写文章方便多了：）
非技术能力
- 软技能和技术能力的关系
- 及时和老板表达想法
- 异步工作模式，沟通先行
- 开会要准备（会议的背景、有哪些内容是“你”一定要在会上和别人沟通清楚的，有哪些是可以线下再说的）
- 一切讨论、想法都要有记录（为什么邮件比聊天工具更适合工作）
- 返工是最耽误进度的，宁愿先花时间想清楚
- 一定要和（潜在）客户聊天
技术能力
- 设计文档要怎么写：重点描述不确定性最大的部分，实现细节不需要写。
- 大的思考方向：Usability and scalability
这些想法在我脑中已经酝酿了一段时间。之所以讲出来，倒不是想教别人什么东西，而是为了记录自己想法的变化。人的想法会变，这不要紧，但人往往只意识得到自己“当前”的想法。因为人脑无法做 snapshot，所以过去的想法要么随着时间被遗忘，要么演化成了当前的想法。然而即使处于同一演化链条，过去和现在的想法总有些许不同——我们却没办法注意到。Snapshot 存在的意义就在于你可以 diff，可以 blame，可以对当前的想法溯源，可以发现过去的自己错在哪里，有哪些地方没有想到。有了这些认识，你就能更加准确地评估当前想法的正确性，这在我看来是十分有意义的。
There has been many criticisms on design patterns over the years. Generally speaking, people think those patterns are not that useful(or even, harmful), and can be simplified or eliminated if some features are directly supported by the programming language itself. However, I have yet to see any criticism on "design patterns", I mean, the name. So here's what I think:
"Design patterns" is a really bad name.
"Design patterns" are not pattern
This is a pattern —— the leaves on the carved woodwork repeat in a predictable manner. Normally, you would observe things and find a pattern.
"Design patterns" are not. It may originally come from observing the commonalities in existing code, but it has now become (at least that's what believed by most people) the guidelines people should follow when writing new code. See the difference here? A pattern is the outcome of an observation, they are not, and never meant to be the guidelines for creating new things. Why would you write code like others, just because they wrote it in a certain way? Are you solving the same problem? Do you know the requirements of your program? Do you know the requirements of their programs?
The root cause here, is the word "pattern". We often say "follow a pattern", but that does not mean that "we should follow a pattern when writing new code", in contrast, it is describing a feature of old code, and the program you are about to write is NOT part of it. The word and the phrase are so misleading, it has caused so many programmers (especially Java programers) to believe from the start, that these "patterns" are the law of god, and they will be punished if they ever disobey them.
"Design patterns" are not about "design"
In Google, we write design docs for projects & features that we believe will take longer than a few weeks to accomplish. I've written and read many design docs, but I have not seen any design doc saying "we should use Singleton/Adapter/Proxy... in this project", not even once. Why? Because it is not part of the design. You should define how components communicate with each other, that's design, but nobody cares about whether it is using a singleton. I'm not saying singleton is a bad idea, it may or may not be, but that is what code review is there for, not design.
Again, the word "design" misled so many people, just like "pattern". The authors of GoF are truly geniuses, as I write this, I realized that there couldn't be a better name than "design patterns" that would made the concepts more popular and well accepted than it has ever become today. Let's imagine your friends, who knows nothing about programming, looking at this magical word. What would they think? I actually asked two friends, one thought it's the principles to design a product, the other said it's probably a math model, or a mental model to help you think about a problem. This is quite like what I expected. Like everyone, we understand words by examining their literal meaning. No one is a born programmer, therefore when seeing the word for the first time, we got the impression that it's "about design", it's "how we should model a problem". But actually, it's not, it's implementation details.
With that false impression in mind, some programmers (especially Java programers) tend to decide which design patterns to use before writing the first line of code. What's even worse is that, not many people have the habit of writing design docs, but they still believe they are doing the "designing" work, because they try very hard to pick what design patterns to use! Great job, GoF 👏👏
What "design patterns" really are
"Design patterns" are just coding techniques. That's all. They are by no means more "advanced" or "higher-level" than other techniques, like short-circuiting.
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
So, my final conclusion is, "design patterns" could either be a terrible name, or a brilliant name, depending on how you look at it.
