作为一个创作者，我对于自己的要求不算高，但也不算低 —— 我希望我能持续有输出。
但我也深知，我是一个普通人，我无法让自己永远有的写，永远有的说。为了解决这个问题，我给自己提供的解决办法是 —— 让自己沉浸在足够的信息当中。
我的逻辑是 —— 我写的文章大多并不是完全创新的（技术的除外），这些文章的灵感来自于我每天的所思所想，而所思所想来自于我的摄入。如果希望有足够的输出，足够的摄入是不可或缺的。
基于上述的逻辑，我得出了我应该做的事情 —— 尽可能多的订阅播客/Blog/微信公众号，收集到尽可能多的信息，然后从这些信息中筛选出我自己所需要的，并与其产生互动（比如诞生一个新的灵感）。
从某种意义上来说，我能够有这么多的文章灵感、软件的灵感，都来自于我的这些海量的输入。
当然，这些海量的输入也为我带来一些不爽的点 —— 比如，信息量太大了，我往往是无法看完所有的信息（当然，我也不太强求自己能看完所有的信息），也在追寻更好的信息摄入的方法，希望自己可以更加轻松的处理这些信息。
昨天和一个朋友聊，这个朋友在现有的公司做的不开心，觉得现有的公司已经脱离了他早期加入公司时的样子，想要离开现在的公司，寻求 Web3 公司的机会。
对我来说，我给到的建议自然是肯定的。
这个朋友在开源社区呆了很久，也有了自己的影响力和人脉，在我看来，他已经脱离了求生存的阶段，已经不会因为离开当前的公司就完全无法生存，他完全可以找到一份适合自己的工作。既然如此，为什么不选择一个能够让自己开心的同时，还能赚到钱的工作？
对于 90 后这一代人而言，我们当中的有些人还在奋斗的途中，但也确实有他这样的，其实家境还可以（不需要他奋斗脱贫），上一代人打下来良好的基础，让我们可以选择去做自己喜欢的事情，就没必要完全浪费自己的生命和时间在一些自己不喜欢的事情上。
勇敢的走出现在，去做你想做的事情吧。
生活当中，疫情当下，我们很容易会在生活中当中遭遇一些意外事故，这个时候，我们为自己构建一套应急处理系统，可以帮助我们快速走出困境。
以「小区被封控，但家里没电了，手机也马上就要没电怎么办？」为例，
我们可以从这句话拆解出三个问题：
当我们拆解出问题后，我们要做的就是给这些事情排列出优先级，并按顺序解决：
上面这些问题当中，手机没电是最严重的，因为手机没电会导致我和外界失联，失去解决其他问题的可能性。
其次，比较严重的是家里没电。这个是影响了我后续生活质量的问题。
至于小区被封控，这是我不可控的因素，因此，不考虑解决它，而是试图在这个大背景下寻求解决方案。
而从优先级来看，我们则需要按顺序处理这些事情：
从例子中拆解方法论的话，我们应该处理问题的策略是：
在生活中，我们常常会 get into troubles，这个时候，静下心来，梳理问题，寻求解决方案，而不是停留在原地，任由恐慌的情绪如潮水般涌上心头才是一个更好的方案。
这篇文章算是为什么选择品牌广告而不是联盟广告的一个延伸。
和一般博客主来说，我的选择显得与众不同，我没有选择一个广告联盟来达成自己的收益的目标。
主要有以下几个原因：
作为一个技术 & 生活博主，我的读者要么是纯粹来看我的生活的，要么是看我的技术文章的，要么是先看技术文章再来看我的生活碎碎念的。虽然大家来看的理由不一定相同，但至少大家是有基本的辨别能力和素养的。
对于这样的读者而言，你推送诸如 XX蓝月的广告，可能意义不大，甚至会影响阅读体验。因此，从这个角度而言，我并不希望我的读者来到我的博客会看到一些不符合我博客调性内容的广告。
对我来说，虽然有钱赚挺好的，但不代表着我一定会接受某家的广告。品牌广告是一个双选的过程，我可以和我喜欢的品牌商去探讨赞助的费用和收益。当我们达成一致以后再进行投放。
这样，我就可以为我的读者筛选出我自己真正在使用的产品。对于我的读者更好。
品牌广告的内容是经过我洽谈、使用过的产品，因此在产品质量上有保障。这对于读者来说，他们接收到的信息不是粗制滥造的产品，对他们来说不算一件坏事；对于我来说，我的文章阅读体验没有太多的下降，因此也算一个可以接受的结果。而对于品牌方来说，他的广告投放是有明确的筛选的，定向投放，也会更好。
从上面的这些角度来看，品牌广告的优势还是大于联盟广告的。不过，品牌广告也有自己的问题
品牌广告是一个共赢的事情，而联盟广告在未经筛选的情况下，是一个很难做到共赢的事情。对于博客主来说，很难说某一个选择就是最好的。放在 6 年后，我选择品牌广告，但放在写博客的第二年，我可能就会选择联盟广告。
根据自己的需求选择你的广告方案，并坚持的执行下去。
我自己其实不太了解 ASoul，也没有特别的关注，毕竟作为一个社牛，不太会通过虚拟人来获取情绪价值。但我确实之前听说过 VTuber，在我的下意识以为，VTuber 的声音应该是由 AI 来完成生成，工程师建模，PM/运营来负责脚本的产出（类似微软小冰）。
不过，现实可能是 ASoul 这样的项目其实是由中之人来完成声音的录制，更接近于传统的声优的角色。对于资本来说，中之人就是一个耗材，但对于喜爱 VTuber 的人来说，中之人是非常重要的。
当一个 VTuber 之后是一个独立的人的时候，其实能贡献的当然不只是声音的问题，还可以贡献出更多的情绪价值。而这些情绪价值，正是一个 VTuber 的独特的价值。
这些东西是完全无法通过 AI 生成的么？可能是可以生成的，但暂时可能无法生成。随着技术的进步，逐步拆解出人的各种情绪和诉求，再由 AI 来完成生成，实现真正意义上的 VTuber
我的博客能够保持日更，主要来说，是有两方面因素：
很多时候，我的写作都是要先取悦自己。所以我对于一篇博客的要求没有那么高，达到最低标准，300 字即可（这个也是微信公众号原创文章的要求），所以我不会有太多的心理压力，担心一篇文章是否足够完美。
我每天会看到大量的文章内容，这些文章内容可以激发我自己思考，并产生出新的灵感，通过这些新的摄入诞生的很多灵感都不够深刻，但确实可以写下我对这个问题的思考，并在后续的时间沉淀下，不断的重新思考、再次思考。
我常用的信息输入的平台：
如果你发现自己没有灵感，不妨试一试。
最近重读《番茄工作法》和《番茄工作法图解》，有一种预感，大家可能都用错了。大部分人用番茄工作法关注的是 25 分钟工作 5 分钟休息。但在我看来，这个可能是整个番茄工作法中最不重要的了，不同的人不同。你应该根据自己的实际情况来调整你的工作时长和休息时长。倒是背后的几张表格可能更重要。
番茄工作法中，包括三张表：「今日待办」、「活动清单」、「记录表」。
今日待办记录了今天要做的事情和突发的紧急事项，用于指导你在一天中的工作；活动清单则类似于 GTD 当中的 Inbox，收集了所有要做的事情；记录表则是存储了任务的元数据，可以用来对自己进行分析和指导。目前市面上大部分的工具都集中在如何做好定时器。对于记录表、今日待办和活动清单都没有做的特别好。 Session 算是比较好的，对于这些任务的数据有了展示。但在我看来，这个依然不够有效。主要是这里的数据其实是最基础的，对于形成反馈优化我们的时间和工作没有太多的帮助。
在我看来，番茄钟的基础是 25 + 5 的模式，来让你集中 & 放松。但想要保证 25 ，是需要「今日待办」中的「计划外和紧急活动」来保障的。不然待来的结果是要么 25 分钟费了，中间干别的了；要么是你 25 分钟倒是用好了，但计划外事项和紧急活动丢了。
至于活动清单，倒是相对简单一些，是 Inbox 以及进行任务的预估。Inbox 无需多说。任务的预估对于构建番茄钟的系统来说非常重要，你的精力是有限的，将精力用在有限的事情上需要你明确自己的精力状态和能做的事情，以及对要做的事情有明确的预估，才不会出现大面积 Delay 的情况。
记录表则用来追踪这些原始数据，并搭配着「今日待办」和「活动清单」一起来构建一个反馈系统，得出优化的结论。
上述的这些是现在的番茄钟工具大多没有关注到的。这些工具更加关注 25 分钟这个时间，但其实这是最没用的。
这也是为什么我现在又回到了纸笔的方式来使用番茄钟。不过我的做法可能过于原教旨主义了。明明这些事情用工具可以更好的解决，但我确实找不到更好的工具了。所以回归纸笔了。
答案是「否」，钉钉账号表面上是你自己的账号，但在企业的逻辑当中，这是「企业授权给你使用的」，本质上，这些都是企业的资产，企业是有权处置这些资源的。你所说的、所看的、所做的，都是企业提供的资产，企业可以根据自己的需求来调整这些资源的所在位置。
这是钉钉的不同的一点，在钉钉当中，任何一个账号，都是有对应的租户的（除了你的个人租户）。租户才是资源的所有者，我们只不过是使用者。 而我们使用的微信、QQ 其实也不是我们的，在微信的用户协议当中写明了，我们所拥有的不过是微信账号的使用权。只不过，因为腾讯离我们很远，我们可以认为不会对我们执行任何操作（当然，实际上如果你发一些不和谐的内容，也会被设置为内容自见），但在钉钉中，租户的管理员可能就是我们身边的同事，在这种情况会更有「隐私」和企业所有的对比。
7.1.2 微信帐号的所有权归腾讯公司所有，用户完成申请注册手续后，仅获得微信帐号的使用权，且该使用权仅属于初始申请注册人。同时，初始申请注册人不得赠与、借用、租用、转让或售卖微信帐号或者以其他方式许可非初始申请注册人使用微信帐号。非初始申请注册人不得通过受赠、继承、承租、受让或者其他任何方式使用微信帐号。
综上所述，你的账号，并不属于你。
一直以来，创业圈都有 To B 和 To C 的两个赛道。而对于我目前所从事的事情来说，我愿意将之称之为 To Dev 业务（简称 To D）。
为什么是 To D？
在过去，很多时候企业的产品要么是针对 C 端用户，直接卖用户给广告商，我们称之为 To C；也有很多企业是通过为其他企业提供资源，来获取收益，我们称之为 To B 。
To Dev 的业务本质上都是 To B 的生意，因为 To Dev 本质上是在要求开发者背后的企业来进行相应的费用支付。
但 To B 往往会让人误以为这个场景很大，所以我常说 To Dev（或者是 To 小B）。
To B 走的是上层建设的路线，产品往往是由上层确认，下发至业务团队，业务团队直接使用。举个例子来说，小米使用的是阿里云，原因是从集团层面看到阿里云很好用，所以我们批量采购，大家直接使用。
To Dev（To 小B）则是一个相反的路线，走的是农村包围城市。通过提供优质的产品，来促使开发者使用产品、离不开产品、为产品付费。
为什么会是这个路线？
过去，我们看到大量的大企业在使用 To B 产品。但随着 To B 时长的不断发展，越来越多的企业已经完成了 To B 的业务的采购，在这个时候，再想通过 To B 的方式来完成资源的购买，是十分困难的，因为已经被占位了。
在这种情况下，我们就要开始去观察那些还在成长的市场，比如初创团队、新产品团队。对于这些团队来说，他们一方面依然可以采用之前采购的资源。但同时，之前采购的资源可能有着这样或者那样的问题，让团队成员困扰。而新的解决方案可以更加简单的解决问题之时，这样的团队便有动力去试用这样的产品。
而这样的团队注定是如繁星一遍，遍布各个地区，传统 To B 场景下的销售就不适用了， ROI 太高。则需要在产品体验方面做到极致，让开发者可以更愿意选择自己的产品。
在做软件产品时，我们会无限的追求极致，希望将产品的体验、用法等各个方面全部做到最好，因为软件的交付成本低于硬件的交付成本，我们只需要一个命令，就可以将旧版的软件升级到新版。因此，我们可以通过不断的软件迭代，来将一个不完美的软件，迭代到完美的状态下。 而硬件则不同，硬件涉及到两个问题：
上述两个原因，导致我们永远不可能买到完美的硬件产品。