靠写作建立影响力的底层原理是啥？
大家好，我卡颂。
最近，有个朋友出了门「前端状态管理」的课程。他的本意是想走我的路：
- 通过内容（他的课程）积累粉丝
- 为粉丝提供付费服务作为副业
- 当副业收入超过主业后就能自由职业了
但课程反响平平，所以来咨询我的建议。
这篇文章是我给这位朋友的回答，同时也适合希望「靠写作建立影响力」的同学阅读。
别人为什么信任你？
上述「靠内容积累影响力，再靠影响力积累粉丝，最后为粉丝提供付费服务」路径的本质是「圈层生意」。
所谓「圈层生意」，就是长期经营一个围绕你的圈子，做好圈友的关系维护。圈友与你产生长期信任关系，基于这层信任关系为你的服务买单。
所以，圈层生意的根基是「信任」。当你活出一种让人向往的状态，其他人因为羡慕你的状态，关注你，靠近你，向你学习，这个过程就会产生信任。
对于程序员（或其他技术人士），如果你能让人产生「这个人在我关注的领域真的很在行」的感觉，就给了他一个关注你、靠近你、向你学习的理由。
很多人认为「在某一领域很在行」意味着你必须在该领域钻研的很深，其实并不是这样的。你只需要做到如下2点就行：
- 纵向：在目标领域有比受众
高一个抽象层级的理解 - 横向：在其他相关领域有和受众
同一抽象层级的理解
即「目标领域追求深一级的理解，相关领域追求广泛（但不深）的理解」，而不是大家通常认为的「只追求在目标领域有深几级的理解」。
举个例子
以我朋友的前端状态管理课举例，他当前的课程内容是：
- 罗列了市面上流行的状态管理库的特点与实现原理
- 讲解一些状态管理库的共性问题（比如测试用例怎么写、技术选型怎么做...）
让我们重新规划下课程内容，先看第一点 —— 纵向：在目标领域有比受众高一个抽象层级的理解。
比「状态管理」高一级的抽象是「前端业务开发」，从「前端业务开发」出发，可以从如下角度展开：
- 前端业务开发模式的变迁对状态管理的影响
比如，从面向过程（用jQuery）到声明式开发（用前端框架）过程中，状态管理为了适应开发模式的变化，是如何变化的？
- 不同复杂度的前端业务对状态管理的影响
比如，Facebook为了应对自身应用的复杂性，提出了Flux状态管理架构。
Dan发现当应用复杂度进一步提升时，加强单向数据流的约束能简化业务开发模式，于是在Flux基础上提出了Redux状态管理架构。
- 不同类型的前端业务对状态管理的影响
比如，对于以下三类业务逻辑：
- 纯UI交互
- 缓存的更新/失效逻辑
- 与UI无关的数据流转
虽然他们在前端都表现为状态，但由于各自逻辑不同（比如缓存需要考虑过期时间），需要被区别对待。
综上，我们会发现，当从事物（这里的状态管理）的上一层抽象（这里的前端业务开发）出发来观察事物，会获得更深的洞察。
甚至，有些问题必须从更高的抽象层级出发才能得到答案的。比如「状态管理的技术选型」 —— 业务的技术选型是因，状态管理选型是果，所以这个问题只能从业务层面出发。
再来看第二点 —— 横向：在其他相关领域有和受众同一抽象层级的理解。
和状态管理同抽象层级的事物有很多，比如：
- 具体前端框架（比如
Vue、React）的业务开发：可以聊在Vue、React等不同框架中状态管理的区别，以及造成这些区别的原因 - 路由功能：可以聊状态管理理念在路由功能中的体现
- 其他前端相关语言：可以聊
CSS中变量的状态管理
发现了么，经由横向、纵向扩展后，「状态管理」不再独立存在，而是延伸出一套知识体系，这套知识体系：
- 纵向看：与前端业务开发连接
- 横向看：与其他具体业务连接
当读者以后遇到与状态管理相关的问题，都能从这套知识体系中寻求答案。
反观之前的课程结构，既然我项目中使用的状态管理库已经够用了，有什么理由再去学其他状态管理库呢？
后记
「靠写作建立影响力的底层原理」可以分为三步：
- 形成目标领域的体系知识，弥补受众在该领域的体系空缺
- 以此让受众对你产生“这个人真在行”的感觉
- 进而靠近你，向你学习
但是，对很多人来说，即使了解上述三个步骤，也无法靠写作构建目标领域的知识体系，因为写作的卡点通常不在于具体的写作技法，而在于：
- 对目标领域了解太少，不知道下一步该咋写
- 对目标领域理解太肤浅，换个命题就不知道答案
所以，「靠写作建立影响力的底层原理」的源头是「知识管理」。这又是个宏大的话题，如果大家感兴趣可以点个赞，赞多的话我再开新的文章聊～