「商业模型」与「财务报表」任意拿出其一来讨论，都是极其繁复而艰深的话题。但比起各自学习它们本身的艰辛来讲，以什么样的视角来应用它们、又以什么样的方式来组合它们，可能是更为艰难的事情。

对于专业人士来讲，要么容易过分执着于「财务报表」而变成了狭隘的会计，要么容易过分执着于「商业模型」而成为了产品经理或者 PPT 融资小能手。而对于装 X 人士来讲，念叨几句「商业模型」是用来吹嘘自己可以指点江山的气魄与眼界，而蹦出几个「财务报表」的词汇则是用来彰显自己在细节上的专业，而实则可能两者都不大懂，只是在向外界制造光环效应。似乎很少有人对 “如何真正结合二者，脚踏实地洞察出一些不同的东西” 感兴趣。

完整的商业分析至少要包含两方面：定性分析与定量分析。「定性分析」由「商业模型」所包揽，它相当于战略部署、代码实现前的技术设计，用于确定自己是否在做「正确的」事情，可以划归到「方向性」的范畴。而「定量分析」由「财务报表」包揽，它更多的是在充当被动的 check list，用于检验「商业模型」中提到的各种理念是否得到了切实的实施，而不是充当主观的方向判定、战略判定。

也即是：你不该从「财务报表」中去判定一家公司是否走在了正确的方向上，是否在战略部署上有精巧系统的设计；也不该被公司所宣传的理念与战略部署迷惑双眼，而应该在「财务报表」上搜寻是否有具体的数字来体现和支撑对应的商业逻辑。

这同 developer 调试问题是极为相似的：你不该从「日志」中去寻找代码逻辑和代码模块的组织架......

ByteDance 的偶然与必然》主要分析了 ByteDance 的「今日头条」崛起的原因，而对「抖音」并未做细致的论述。从原理上讲，两者崛起所凭借的方法论都一样：将「增量竞争」暗度陈仓在了「存量竞争」的游戏中。由于原理相同，所以也就在上篇文章中对其一笔带过。但有朋友说还是想看看对「抖音」的梳理，也就有了本文。

虽然「抖音」同「今日头条」的战略方法论有相似之处，但两者所依赖的具体的变革「生产要素」、所凭借的「时势」却并不相同。如果说「今日头条」所处的时间段是「移动互联网」的兴起时期，那么「抖音」出现的时间段则是「移动互联网」开始走向成熟的时期。

相比于「移动互联网」新兴时期的野蛮生长，在走向成熟的时期里攻城略恐怕要更为艰难。面对更加剧烈的行业竞争和更加复杂的竞争格局，选择什么样的产品形态来奠定自己在「移动互联网」时期的坚实地位，则更加考验创始人对时势、方向的判断力。

比起「长视频」来讲，「短视频」领域的增长依赖了更为微妙的变革因素。

首先，在「4G」和「高清手机屏幕」这两个关键性的变革生产要素组合下，其必然会催生的「信息媒介」就是视频。在非 4G、非高清手机的年代，大家只能退而求其次地使用文字、图片来作为承载信息的媒介，无法在手机上流畅地享受视频服务。

而「4G」与「高清手机屏幕」的出现，不得不归功于当时以小米 / OPPO/VIVO 为首的厂商，将物美价廉的高品质手机在全中国疯狂普及。下至最为普通的老百姓，也都能够有条件、有资格享受到「4G」与「高清手机屏幕」的服务。当广大群众的手机同时满足了高网......

ByteDance 的如日中天以及对流量的绝对掌控，会让人产生一切都是自然而然的错觉，以至于会让人忘记去仔细梳理它的过往，特别是曾经那个让它起步、带入大众视野的产品「今日头条」。对 ByteDance 的研究，容易简单地将其归因为人性成瘾的迎合、信息分发效率的提高。ByteDance 对流量神一般的操控光环是如此之绚烂，以至于每每提及「今日头条」早期融资各种受挫时，都只是为了凸显投资人的见识浅薄，而忘记去掰扯其中的细节，忘记去追求天人之际的分界线。

对「今日头条」投资受挫、投资人各种悔恨的最传奇描述，当属对红杉中国沈南鹏、徐小平、周鸿祎的一次访谈。各个投资大佬之间相互比惨，相继叙述自己是如何错过了「今日头条」这只独角兽。

这已是好多年前的事情，但依旧抹不去其传奇的独角兽光环。但如果我们稍微剥开那层非理性的独角兽光环，稍微再理性一些，用心去分析一下当初出这些投资大佬们不看好「头条」的理由，就会发现很多有意思的细节。

如果今天有一个人来告诉你，他要创建一款比微信的功能多得多的聊天 App 来创业，你可能会惊讶不已：还有这样的产品初阶选手吗？将商业简单地归因为技术和功能的多寡，这几乎是 PC 时代......

美团的 VP 王慧文在清华的产品课中，将产品经理（PM）分为两大类：创业型 PM 和业务性 PM。创业型的 PM 主要解决产品本身的生死存亡的问题，解决它为什么而存在的问题。而业务性的 PM 则是在已经解决上述问题之后，如何在局部模块中精雕细琢、甚至是按流程搬砖（提供、设计基本的交互流程、提供流畅的使用体验）。

这样的划分方法，其实同 developer 的划分有很高的相似性。对于初 / 中阶的 developer 来讲，其主要重心是放在对一个函数、一个模块的精准实现，掌握基本的软件工程方法和技巧。而到了高阶阶段，则不再仅仅停留于技术的吸收，而是要解决技术为什么而存在（分为纵向的技术底层知识和横向的业务领域知识）、技术选型对未来的生死存亡的问题。如同一位 developer 所说：” 虽然工程师需要具备一些开发者的技能，比如写代码，但从根本上，工程师的能力，和代码无关。

产品的设计，远远早于其着手开始，是从产品经理作为经济学家的实现者开始就已经决定了的，就像成熟的 developer，其写代码的时间占比或许只有 20%，而开头 80% 的准备工作，才是决胜千里之外的胜负手。很多产品的生死与未来规模，早已在着手设计之前就已经决定。这是创业型 PM 真正的胜负手。

产品是为 business 而存在的：通过「产品」这个媒介为用户交付需要的「效用 / 需求」，以此获得相应的报酬。

那么，这里就存在两个问题

1. 你的产品所服务的 business 盈利前景如何？
2. 你服务的用户的需求（wants/needs）是什么？......

Finance 领域多以绚烂、浮夸的方式呈现在世人面前，它似乎是纸醉金迷的代名词、是不劳而获的捷径、是实现 money easy come easy go 的最佳途径。无数人想要投身其中妄图在名利场中分得一杯羹，也有无数人在里面碰得头破血。它是公开的赌场，又是经济建设的重要杠杆。无数矛盾的名词都在刻画这同一个领域，让人雾里看花。我们不禁要问，它到底是什么。

要弄清楚是什么，就必须追溯到它存在的意义。如果它是为了「赌性」而存在，那为什么国家不直接开设赌场？如果它是为了经济建设而存在，那为什么充斥其中的却又是各种赌徒的喧嚣？为什么让大批的民众在里面任人宰割？

要回答这些矛盾而微妙的问题，需要大量细致的讨论与分析。千里之行始于足下，我们不妨从一个小问题开始。

Q1：如果有人告诉你，他有一个很好的、特别赚钱的项目，但他现在没有钱，想让你先帮他干活，等到项目赚钱了（假设 1 年后），再把薪酬支付给你。那么，你很可能会踹他两脚。那么，有没有方法能够完成这样的 mission impossible 呢？

有的，还不止一种方法

• 最简单粗暴的，莫过于武装压迫，通过武力强迫你付出生产劳力。
• 再来是 imaginary story 的洗脑，通过灌输各种「信念」「信仰」，让人被「使命」所环绕，以大无畏的革命精神来无私地奉献自己。
• 较为微妙的就是 print money 的 paper game 了。例如，通过 cen......

计算机（computer science，CS）领域的学习之难，不同于数学，会在某条逻辑链上逼到极致，给出极其抽象、繁复、艰深的逻辑推导，而在于那些如蝗虫一般密密麻麻向你涌来的各种知识概念（knowledge node）。如果仅仅是数量繁多，那么其实问题不大，只需要按部就班地将它们一一习得即可。但 CS 的困难，在于这些 knowledge node 之间会相互纠缠、相互依赖，对某个 node A 的理解会依赖于好几个别的 node B/C/D，而 node B/C/D 又可能在经历了好几个 node dependency 的关系之后，如依赖到 node R，这个 node R 的理解又会反过来依赖 node A 的理解，即出现循环依赖的问题。这直接导致「仅掌握单个 knowledge node」对学习者毫无实质性用处，不得不在掌握一片 knowledge network 之后，才能有些许实质性的领悟。

相比起来，作为科学的皇冠的数学，它虽然是大部分人学习生涯中的噩梦，常常被诟病为过分抽象、繁复和艰深。但如果从 learning task pattern 的角度讲，数学的知识体系要直观明了得多。如果按照 learning task pattern 的难度等级来划分的话，我会将其划归到最底层：level 1。

Level

之所以将数学放在 level 1，是因为它的每一个 knowledge node，都可以被拆解出一条学习链，顺着这条链能够追溯到一组最简单、最直观、且一定正确」的 knowledge nodes，即：公理、定义。你可以很容易地从这组 root nodes 逻辑推演出整个体系。

在这样的 task pattern 之下，无论其知识有多么繁复，你只需要拆解出一条条相互独立的学习链，对每条 learning chain 一步步地向前追溯它的 root task。找到并学会这组 root task 后，你将不仅能习得这条 learning chain 上的所有 knowledge node，还能将一大片的「相关推论」一网打尽，可谓是性价比最高的学习方式。

所......

评价 / 分析任何一件事情，其基础是要弄清楚：你需要给出「好」与「坏」的标签，在其根本上所依赖的东西是什么。例如，分析数学的一条分支，就需要知道这条分支所依赖的「定义」与「公理」是什么；要评价一款软件的性能，就需要知道在它在计算机的三大支柱（CPU/Memory/IO）上的操作与体现是什么。

那么，如果要评价、分析一门生意，它所依赖的不变基石，应该是什么呢？这就需要我们回到最原始的出发点，即：我为什么需要关注一门生意？

显然，你关注一门生意的根本出发点，是为了能够从中获得收益，即：你投入资源 A，能够通过 business 这样一台神奇的 machine，换回收益 B，并且你期望的是 （B - A) 越大越好。这是你关心生意的根本出发点。你关心一门生意，不是为了寻找伴侣、不是为了绘制 PPT、不是为何制作艰深的会计报表、不是为了吹嘘炫耀，而就是简单的，能够获取最直接的收益：cash flow。

（你当然可以说你不止关注 cash flow，任何「值钱」的东西你都关注。但本质上讲，如果这个「值钱」的东西不能通过自由交易的市场转换为 cash flow，这个「值钱」就只不过是你自己的一厢情愿或者说信仰。这不在本文对客观 business 的讨论范围内。

如此，评价自己对「生意」的分析是否透彻、是否真的懂得这门生意，其标准就是：自己......

mmap（memory mapped file）从字面意思来看，似乎是在节省每次同 disk 做 I/O 的巨额开销（expensive overhead），通过把 main memory 作为 cache 来提升 disk I/O 的效率。

但这样的认知完全是错的，因为OS（operating system）已经为 disk I/O 提供了 page cache 这样的机制，来实现上述基于 main memory 的 cache 优化。

如此，我们不免要进一步地追问，那 mmap 到底为何而存在？它能提供哪些优化？在什么样的场景下，mmap 会为 program 带来更好的性能？而什么情形下引入 mmap 反而会给 program 带来更大的 overhead ？

如上所述，由于 page cache 的存在，mmap 所提供的 cache 功能并不能作为其 performance 由于 disk I/O 的理由。于是，我们需要分别考察这两种机制的 data pipeline。

对于 mmap 来讲，它通过 system calmmap()将 disk partition 映射为某段 virtual memory address。需要注意的是，mmap 采用了 copy-on-write 的 lazy execution 优化机制，并不会在第一次的 mapping 阶段就分配出 physical memory address。它要等到第一次对这段 virtual memory address 的访问时，通过引发 page fault 这样的 system exception，来间接触发 physical memory address 的分配。

也即是，每一次对新的 disk part 的映射，都会在它第一......

李录同他的老师 Bruce Greenwald 在「13th Annual Columbia China Business Conference」上做了非常精彩的在线对话，再一次谈到了他的投资哲学以及对当前世界的一些看法。如同李录在谈话中所说，the philosophy is relatively simple. The practice is really hard。虽然其中谈到的 investment philosophy 是老生常谈，但每次谈论这些 philosophy 的视角和示例的不同，都能让人对同样的思想有更为深刻与不同的理解。就像不自欺」是很简单的一句话，但随着岁月的流逝，你会慢慢从「态度」中看到需要培养的「技能」，看到「技能」中需要承载的「反思」。

李录在这次对话中有相当多的真知灼见，我仅摘录我最喜欢的一段，来发表一些个人的 comment。

1/ 李录在这里的论述极为务实，他两次提到，在这漫长的、经年累月的研究中，大部分他「想要弄清楚的问题」都没有答案。于是，他只能继续坚持去学习、去寻找，直到找到为之。找不到，就绝不投资。

这像极了有追求的 developer 对技术细节的探究，不断地在网络上找答案，在各种 blog post 和 paper 间穿梭，找寻有用的只言片语。有时候，甚至还不得......

理性投资」就是运用逻辑、摆事实讲道理，按照事物运行的客观规律来制定投资策略。那么，最直观和基本的结论便是：不懂不投、收益风险比不高不投。

以理工科从业者的视角来看，这样的方法论是如此的直观和显然，为何很大一部分人都是以嘲讽的眼光在看待这样的方法论呢？长久以来，我一直不得其解。但在最近的一些阅读中，我逐渐意识到，这其中的根本分歧，可能就在于「知道自己不懂」。

对大部分人来讲，「不懂不投」是等价于 gambling 的废话。因为对他们来讲，判断自己「懂不懂」、知道什么是自己不懂的，就像「预测情绪」一般，是玄学、是赌博。以这样的视角来看，表面上「不懂不投」似乎特别有道理、符合逻辑，但如果「判断不懂」这件事情本身就是玄妙的，那后续的工作再怎么理性，这整件事也成了非理性的玄学之事，而不会将其当做是 down to earth 破除迷信的科学方法论。

或许，这是理工科（如数学、计算机科学）从业者的幸运之处，他们所在的专业领域给了他们无数多的机会来清晰地分辨：什么是自己懂得的、什么是自己不懂的；什么情境下、什么特征出现时、什么直观建立时，才可以被划归为「I know I do know」，而在什么情形下又只能被划归为「I know I don’t know」。这些训练，是各种「逻辑题目」与「现实反馈」的残酷鞭笞与训练（如数学中挑剔的 p......

Charlie Munger 在谈到如何塑造 rationale、如何构建更好的思维方式时，总会拿出他最喜欢的工具：reverse problem（逆向思考 / 反过来想）。I just reverse the problem 是 Charlie 的口头禅。

Reverse problem 的思考方式可以追述到有名的代数学家 Jacobi，他的名言即是：总是反过来想。事实上，对于习惯了「反证法」的数学家来讲，reverse problem 几乎是自己职业所塑造的第二本能。而其实不仅是数学家，大多数喜欢逻辑推理的理科生都会不由自主地应用 reverse problem 来理解各种命题。

以我自己为例，每当遇到「书本」向我 “推荐” 一个领域的结论 / 命题时，我总是会问自己，“我「凭什么」要按照这种说法去做？” 然后开始尝试「反着干」，开始拼命寻找各种「违背」这个命题的规则、但却依旧可以让命题结论成立的方法。

当我尝试了足够多的「反着干」之后，我便能慢慢理解 “提出这个命题所涉及「规则」” 的必然性，理解每一个条件背后所依赖的 motivation、所依赖的「不得不」。挖出这些命题前提条件的逻......

“中国的历史，没有科学”，这里的「科学」指的不是「技术」或者「技术成果」，甚至不是「科学成果」。这里的「科学」指的是 science 所带来的整套「思维框架」与「思维体系」，指的是作为「个体」对外界事物的一整套「认知体系」和「评判体系」，指的是能够孕育出 “逻辑三段论”、孕育出 “控制单一变量” 作为实验的评判标准、孕育出 “以可证伪” 作为基石的体系。

如同「数学」并非是「计算」，而指的是由原始的「抽象定义 / 公理」所构筑的公理体系，在中国的历史上，有无数的璀璨绚烂的计算经验材料，如《九章算术》《孙子算经》《缀术》。但，中国的历史没有「数学」，有的只是「计算」，因为无法从各种具体场景的计算剥离出抽象的概念，并以此作为基石来构筑一套抽象的公理体系。

西方的「科学」、「数学」、「逻辑」的根本基石，在于「抽象」、在于能够用符号来谈论「抽象之物」。

那难道中国就没有「符号」？

中国当然有符号，中国最引以为傲的符号，当然就是自己的象形文字：汉字。象形文字，常被作为中华历史繁荣文明的象征。因为我们的符号与文字，不像 “蛮夷之地”，只能用一些看不懂的奇怪符号来表征，我们的象形文字，每一个都是一副缩略图，代表了「智人」的文明繁荣。

但，成也「象形」，败也「象形」。

维特根斯坦说：语言的边界就是世界的边界。人类高明于动物的地方，在于我们有一套基于「语言」和「文字」的高等「信息交换体系」。如果把这套「信息交换体系」从人类身上拿掉，那么人类的精细与大规模的协作将无法......

看到黄峥（Colin Huang）在2021股东信中宣布辞任 pdd 董事长的职务，又一次惊讶、感慨到不行。虽然从理性上讲，他的这个决定一点也没有超出他的做事风格和价值观，但将其做成既定事实的那一刻，还是不免让人惊讶、叹服。

大部分的人想要成功、拼了命、挤破了头也要成功。而成功之后，则是拼了命地要守护、要保护好自己得到的「成果」，在权力和派系的相互对抗中，过完自己的后半生。

而 Colin 的确是得到了段永平的真传，只能用佛学中的一句「去来自由」来形容（去来自由，心体无滞，即是般若）。财富之于他，不是主人、而是他利用的工具。他不会被财富、名利、地位所裹挟，而是「去来自由」地做自己所认同的事情、做自己手头上的事情。

纵观 pdd 的发展历程，竟然是以大部分商业精英都不屑于看一眼的农业起步，并把它当做公共机构、当做改变市场运行规则、改变供需关系的大事来做。甚至，Colin 在这次的股东信所阐释的自己的”退休生活“，也是在农业/生物方面更进一步的深入探索，为 pdd 十年后的发展摸索前行的方向。

作为 leader 来讲，他做了最应该做的事情：为公司找方向，而不是留恋于手头的权力、财富。作为个人来讲......

当我们向非 developer 的普通人解释 Windows 系统和 Linux 系统的不同时，我们可能会下意识地将这两个操作系统（operating system，OS）之间「不同」解释为：Windows 系统更注重「图形界面」的交互，以降低普通人的使用门槛；而 Linux 系统更多的则是面向 developer，更注重如何方便 developer 编写 script、调用系统 API（application programming Interface），如何更便捷地组织各种 batch task、构建自动化的环境。

从普通人的角度来看，这个解释似乎是合理的，因为一提到使用 Linux 操作系统，就会不由自主地浮现出那块令人畏惧的冷冰冰的黑色屏幕。很难想象，除了为专业 developer 提供支持外，会有哪个普通人对它产生莫名的好感。但即便如此，这个解释却依然是有问题的！因为仔细推敲起来，这样的解释，阐明的不是 OS 之间的差别，而是 GUI（graphical user Interface）和 shell 之间的差别

而对 OS 来讲，GUI 和 shell 都是通过 OS 自身提供......

乐观不等同于幼稚的鸡汤，悲观不意味着正确的理性

当人们寻求励志的鸡汤与正能量时，其潜意识的目标在于能够「成事」、能够通过”被鼓励“来实现现实世界的成就：一番卓越的事业、一款划时代的产品、一项他人不可能企及的任务/使命。

于是，要讨论「励志」就必须讨论它潜在的目标所指「成事」，而要讨论「成事」就必须讨它本身的性质、发生的充分/必要条件、发生与发展的各种条件制约（另：这里所说的「成事」，只可以通过理性的努力、付出、训练而习得的可见、可测量的事件，而不是完全依靠随机波动的纯赌博事件）。

「成事」本身受制于现实的约束条件，如事物所在领域的特定发展规律，个人学习的认知规律，个体对理性的充分掌握而引导出的反思、总结与推演。技能与知识的学习与掌握，可能是这个方向上最典型案例：通过按部就班的踏实累积，通过将新知不断地拆解与抽象、将其勾连到自己的已有认知体系，来循序渐进地掌握与巩固知识/技能。

例如，对于 developer 来讲，他必须经过两三年的基本操作的熟悉，才能逐步真正开始对相关理论严肃而落地的学习。然后在一本又一本的经典著作的阅读和代码的撰写中，逐步掌握 programming 的精义。任何妄图跳过基本操作的熟悉的初阶 developer 都会走火入魔，而任何妄图省略理论基础学习的多年码农搬运工，都会因此而被限制在低阶的细节中，无法通过理论高屋建瓴的总结与梳理，进入工程师的高阶领域。

对数学研究者来讲，通用的代数、几何、分析、拓扑都是打底的入门材料。自己所在领域的经典著作、paper也是必不可少的阅读材料。在这些厚实的材料下，还必须保持高频的习题练习，才能在岁月的反复积淀下，逐渐看出盘根错节中的脉络......

当我们谈论「产品」的时候，到底在谈论什么？是它所展现的漂亮外观或界面吗？还是它提供的特定功能，或者这些特定功能模块的特定组合呢？是它牵连的类似于标题党一般的噱头追风吗？还是它反复不断的营销洗脑呢？

而要回答这个问题，就必须要回溯到它存在的意义，即：它为什么而存在？

「产品」本身无法单独存在，它必须服务于「交易」这项活动。如果不存在「交易」，那事件中所涉及的物品/服务，也就无法被称之为「产品」。这里的「交易」是指广义的交易，而非狭隘的必须涉及金钱交换的交易。一切行为的决策，都可以被看作为「交易」，你付出了时间、精力、注意力、心血，用来交换一次界面点击、一声问候、一次步行。

「交易」是产品存在的基石，也是一切做产品的手段所服务的对象。所以一切对产品设计的某篇布局，都应该是围绕「交易」这根主干而开展的。

从这个意义上讲，「产品经理」是落地经济学概念/规律的、工程师形态的「经济学家」，每一位合格的产品经理的体内，都住着一位老练的经济学家。就像每一位优秀的建筑设计师，其内心都住着一位老练的物理学家。不懂经济学、无法将经济学吃透的产品经理，是只会修剪枝枝蔓蔓、不懂浇水施肥为主干服务的拙劣园丁，只知其表不知......

好的产品经理（product manager, PM），对「整理信息」的极端诉求，几乎是其职业素养的自然推论。作为 PM，「用户调研」虽不是做产品的全部工作，却是绝对绕不开的一项基本功。「用户调研」做不好，根基便不牢实，后面的工作也就无法展开。任你如何做交互设计、运营管理，都起不了大作用。

要做好「用户调研」，其中的一项核心技能便是能够从大量的问卷信息、行为信息、评论信息中，归纳总结出其趋势。这个数量级基本上在三位数，从数字上讲当然远远不及 developer 动则处理上百万的数据量来得吓人。

但 developer 所处理的数量虽然巨大，但一次只会在头脑中维护几个或者几十个（即一到两位数的量级）概念/目标来编写代码，通过代码去分析和归纳数据的模式。

而 PM 不同的地方在于，虽然只有三位数的量级，但这三位数的量级都不得不维护在自己的头脑中，进而总结归纳出其内在的规律和趋势。

如此，虽然 developer 处理的数据量是最多的，但反而他在头脑中所需要处理的数据量反而是最少的。进而成了最不擅长运用头脑，来做统计归纳的人。

产品界的大牛「纯银」曾经写过一篇文章，论述如何入门产品经理

1、把AppS......

中国古人会将「立志」作为人生大事，甚至直接说“志不立，天下无可成之事”。但奇怪的又是，古人又从来不推崇将“升官发财”作为人生志向，总是将一些貌似玄妙、空洞的「做圣人」「家国天下」「求真求实」作为立志的备选项。最经典的志向范本，莫过于张载的「横渠四句」：为天地立心，为生民立命，为往圣继绝学，为万世开太平。

一个问题便是，把这样的东西作为志向，是否太过形而上、太过矫情而不切实际？这又是不是统治阶层的洗脑工具，以便更加轻松地鱼肉百姓？

或许，这都有吧。

但有意思的是，如果我们以极端务实和功利的角度再去考察这样的「立志」行为，却又会发现它可能又是最为精深的现实算计。

「立志」之所以重要，是因为你所定义的「志向」直接决定了你人生的成就感、幸福感来自何处。围绕「志向」是否被满足，你便会收获到「幸福」或「挫败」，「欣喜」或「沮丧」，「充实」或「虚妄」。

如果将「志向」定义为「名」或者「利」，那么这块人生基石一定是脆弱的。首先，这两样东西不像学问，可以通过按部就班的方式，按照确定性的方式来实现。在「认知/眼光+运气+资产」的组合下，你常常会面对两种巨大的挫败情形

• 自己长年累月的付出，无法换回任何实质性的财富或者权力的增长。......

说明：这里所讨论的「不二」的学问，并非是“不要犯二”的学问，而是“不二法门”中不要用“一分为二”（即“分别心”）来看待世界的学问。

由备忘录：数学、玄学与科学》的讨论可知，科学解决的是「可证伪」的问题，数学解决的是形式逻辑问题。剩下的问题大致可分为两类，一类是关于头脑中的精神问题，另一类是现象不可重复、但结果可被观测的社会科学问题。每一类问题，都产生了各自独有的学科和方法论工具。

片面地否定其它领域工具的存在性，或是偏执地使用一个领域的工具去解决其它领域的问题，都不是明智之举。对症下药、因地制宜、不拿着锤子把世界当做钉子的 open mind，才是理性与智慧的身体力行。

精神世界的问题，无法像科学所处理的问题：可观测、可重复再现。它们停留于每个个体的脑海中，无法被证伪，但却可感知。如此，直接使用“是否可被论证”的方式来评判精神领域的学科，是不恰当的。但同样因为这个特性，这些精神学科的东西，很容易被参杂进统治阶级的私货，把用于禁锢民众头脑的法条参杂其中，让你在“时而智慧、时而不解”的模糊中被统治。

考察“精神世界”的工具，其合适的标准在于它是否提供了一个独特的视角，来帮助你化解内心的纠葛。并且，这个作用并非一定需要适用于每一个人，只要它能够对你起到作用就行。

如果这件精神工具不起作用呢？那无非是这项工具不大适合你的头脑，再换其他的精神工具即可。这就像篮球这样需要身高的运动并不适合每一个人，但这并不妨碍你选择其他运动来作为强身健体的工具。通......

软件工程中对代码质量常用的两条考察规则是：高内聚、低耦合。很多人会不由自主地使用这两条规则来反思自己的代码、评判他人的代码。

如果稍微做一点认真的思考，其实会疑惑这两个标准的矛盾性：既然要“内聚”，就必然会有耦合。而让其低耦合，则必然无法实现高内聚。

如此，岂不是两条矛盾的说辞在相互博弈？也即是，似乎它们是矛盾的？

解开这个矛盾的诀窍在于：让应该耦合的耦合，让应该独立的独立。

「应该耦合」多用于维护数据、状态、处理方法、规范的一致性，不让这些本该来自于同一源头的 resource 各自独立、分散到不同的地方。让本该「同一」的地方分散，只会造成工程上的难以维护，无法做到：“只改一处，别处自改”的优雅管理。

其具体的表现方法是：「继承」、单一的数据源。

「继承」从语法层级上将子类与父类牢牢绑定，父类的任何变动都会自动地反应到所有的子类上。于是，父类特别适用于制定业务流程规范。又考虑到「规范」的通用性，抽象类通常是最佳选择：既限定了必然的规范流程，又为每个流程的步骤细节提供了最大的灵活性。

单一数据源，通常使用配置文件来替代分散在代码各处的 data string。使用配置文件或常数变量文件，能从语法层级......