靠写作建立影响力的底层原理是啥?

大家好，我卡颂。

最近，有个朋友出了门「前端状态管理」的课程。他的本意是想走我的路：

1. 通过内容（他的课程）积累粉丝

2. 为粉丝提供付费服务作为副业

3. 当副业收入超过主业后就能自由职业了

但课程反响平平，所以来咨询我的建议。

这篇文章是我给这位朋友的回答，同时也适合希望「靠写作建立影响力」的同学阅读。

别人为什么信任你？

上述「靠内容积累影响力，再靠影响力积累粉丝，最后为粉丝提供付费服务」路径的本质是「圈层生意」。

所谓「圈层生意」，就是长期经营一个围绕你的圈子，做好圈友的关系维护。圈友与你产生长期信任关系，基于这层信任关系为你的服务买单。

所以，圈层生意的根基是「信任」。当你活出一种让人向往的状态，其他人因为羡慕你的状态，关注你，靠近你，向你学习，这个过程就会产生信任。

对于程序员（或其他技术人士），如果你能让人产生「这个人在我关注的领域真的很在行」的感觉，就给了他一个关注你、靠近你、向你学习的理由。

很多人认为「在某一领域很在行」意味着你必须在该领域钻研的很深，其实并不是这样的。你只需要做到如下2点就行：

1. 纵向：在目标领域有比受众高一个抽象层级的理解

2. 横向：在其他相关领域有和受众同一抽象层级的理解

即「目标领域追求深一级的理解，相关领域追求广泛（但不深）的理解」，而不是大家通常认为的「只追求在目标领域有深几级的理解」。

举个例子

以我朋友的前端状态管理课举例，他当前的课程内容是：

1. 罗列了市面上流行的状态管理库的特点与实现原理

2. 讲解一些状态管理库的共性问题（比如测试用例怎么写、技术选型怎么做...）

让我们重新规划下课程内容，先看第一点 —— 纵向：在目标领域有比受众高一个抽象层级的理解。

比「状态管理」高一级的抽象是「前端业务开发」，从「前端业务开发」出发，可以从如下角度展开：

1. 前端业务开发模式的变迁对状态管理的影响

比如，从面向过程（用jQuery）到声明式开发（用前端框架）过程中，状态管理为了适应开发模式的变化，是如何变化的？

1. 不同复杂度的前端业务对状态管理的影响

比如，Facebook为了应对自身应用的复杂性，提出了Flux状态管理架构。

Dan发现当应用复杂度进一步提升时，加强单向数据流的约束能简化业务开发模式，于是在Flux基础上提出了Redux状态管理架构。

1. 不同类型的前端业务对状态管理的影响

比如，对于以下三类业务逻辑：

1. 纯UI交互

2. 缓存的更新/失效逻辑

3. 与UI无关的数据流转

虽然他们在前端都表现为状态，但由于各自逻辑不同（比如缓存需要考虑过期时间），需要被区别对待。

综上，我们会发现，当从事物（这里的状态管理）的上一层抽象（这里的前端业务开发）出发来观察事物，会获得更深的洞察。

甚至，有些问题必须从更高的抽象层级出发才能得到答案的。比如「状态管理的技术选型」 —— 业务的技术选型是因，状态管理选型是果，所以这个问题只能从业务层面出发。

再来看第二点 —— 横向：在其他相关领域有和受众同一抽象层级的理解。

和状态管理同抽象层级的事物有很多，比如：

• 具体前端框架（比如Vue、React）的业务开发：可以聊在Vue、React等不同框架中状态管理的区别，以及造成这些区别的原因

• 路由功能：可以聊状态管理理念在路由功能中的体现

• 其他前端相关语言：可以聊CSS中变量的状态管理

发现了么，经由横向、纵向扩展后，「状态管理」不再独立存在，而是延伸出一套知识体系，这套知识体系：

• 纵向看：与前端业务开发连接

• 横向看：与其他具体业务连接

当读者以后遇到与状态管理相关的问题，都能从这套知识体系中寻求答案。

反观之前的课程结构，既然我项目中使用的状态管理库已经够用了，有什么理由再去学其他状态管理库呢？

后记

「靠写作建立影响力的底层原理」可以分为三步：

1. 形成目标领域的体系知识，弥补受众在该领域的体系空缺

2. 以此让受众对你产生“这个人真在行”的感觉

3. 进而靠近你，向你学习

但是，对很多人来说，即使了解上述三个步骤，也无法靠写作构建目标领域的知识体系，因为写作的卡点通常不在于具体的写作技法，而在于：

• 对目标领域了解太少，不知道下一步该咋写
• 对目标领域理解太肤浅，换个命题就不知道答案

所以，「靠写作建立影响力的底层原理」的源头是「知识管理」。这又是个宏大的话题，如果大家感兴趣可以点个赞，赞多的话我再开新的文章聊～