生活当中，疫情当下，我们很容易会在生活中当中遭遇一些意外事故，这个时候，我们为自己构建一套应急处理系统，可以帮助我们快速走出困境。

看个例子

以「小区被封控，但家里没电了，手机也马上就要没电怎么办？」为例，

我们可以从这句话拆解出三个问题：

1. 小区被封控，导致我不能如常处理问题。
2. 家里没电，导致我没办法正常生活，也没办法给手机充电。
3. 手机没电，这意味着我可能与外界断联，无法处理任何事情。

当我们拆解出问题后，我们要做的就是给这些事情排列出优先级，并按顺序解决：

上面这些问题当中，手机没电是最严重的，因为手机没电会导致我和外界失联，失去解决其他问题的可能性。

其次，比较严重的是家里没电。这个是影响了我后续生活质量的问题。

至于小区被封控，这是我不可控的因素，因此，不考虑解决它，而是试图在这个大背景下寻求解决方案。

而从优先级来看，我们则需要按顺序处理这些事情：

1. 手机没电：可以去邻居家/物业充个电，先解决自己会失联的问题。
2. 家里没电：在物业咨询，在当下，是否有方案可以为家里交上电费。

拆解方法论

从例子中拆解方法论的话，我们应该处理问题的策略是：

1. 找到我们的问题都有哪些？很多时候，导致我们陷入困境的问题不是一个，而是多个问题交织在一起（一个问题往往直接解决就好了）
2. 为问题排出重要、紧急的优先级：我们需要为问题设定优先级，根据一个事情发生的最坏后果、是否有可替代方案等方式排序，找到最重要最紧急的问题。
3. 按照优先级解决问题：当我们排出问题的优先级，下一步要做的就是解决问题。

总结

在生活中，我们常常会 get into troubles，这个时候，静下心来，梳理问题，寻求解决方案，而不是停留在原地，任由恐慌的情绪如潮水般涌上心头才是一个更好的方案。

这篇文章算是为什么选择品牌广告而不是联盟广告的一个延伸。

和一般博客主来说，我的选择显得与众不同，我没有选择一个广告联盟来达成自己的收益的目标。

主要有以下几个原因：

1. 品牌广告更可控，调性更稳定

作为一个技术 & 生活博主，我的读者要么是纯粹来看我的生活的，要么是看我的技术文章的，要么是先看技术文章再来看我的生活碎碎念的。虽然大家来看的理由不一定相同，但至少大家是有基本的辨别能力和素养的。

对于这样的读者而言，你推送诸如 XX蓝月的广告，可能意义不大，甚至会影响阅读体验。因此，从这个角度而言，我并不希望我的读者来到我的博客会看到一些不符合我博客调性内容的广告。

2. 品牌广告可筛选，有效筛选出无效产品

对我来说，虽然有钱赚挺好的，但不代表着我一定会接受某家的广告。品牌广告是一个双选的过程，我可以和我喜欢的品牌商去探讨赞助的费用和收益。当我们达成一致以后再进行投放。

这样，我就可以为我的读者筛选出我自己真正在使用的产品。对于我的读者更好。

3. 品牌广告相比于联盟广告，可以更容易达成共赢

品牌广告的内容是经过我洽谈、使用过的产品，因此在产品质量上有保障。这对于读者来说，他们接收到的信息不是粗制滥造的产品，对他们来说不算一件坏事；对于我来说，我的文章阅读体验没有太多的下降，因此也算一个可以接受的结果。而对于品牌方来说，他的广告投放是有明确的筛选的，定向投放，也会更好。

从上面的这些角度来看，品牌广告的优势还是大于联盟广告的。不过，品牌广告也有自己的问题

1. 你需要自己维护客户：品牌广告和联盟广告不同，没有人帮你洽谈广告，很有可能今年他投了广告，明年他就不投了。这时你就需要自己去洽谈新的客户。
2. 收入不稳定，存在空窗期：品牌广告存在洽谈和商讨的过程，就很容易出现广告的空窗期。空窗期意味这段时间没有收入。对于一些站点来说，是不可接受的。
3. 对小站点不友好：我的博客写了 8 年，有据可查的就有 6 年，对于很多刚刚开始的小站点而言，他们是很难接受到品牌广告的。所以这些也是一些限制。

总结

品牌广告是一个共赢的事情，而联盟广告在未经筛选的情况下，是一个很难做到共赢的事情。对于博客主来说，很难说某一个选择就是最好的。放在 6 年后，我选择品牌广告，但放在写博客的第二年，我可能就会选择联盟广告。

根据自己的需求选择你的广告方案，并坚持的执行下去。

本文主要是用于有上门的客户找到我时，方便说明我的计费模式和思路。

TL；DR

我的计费模式为按时间计费，我会使用 Clockify 为你的项目进行时间记录，并由 Clockify 来完成费用的计算。我目前的每小时的单价是 $300/h（按时价折合人民币）。

完成一个项目或项目累计时间超过 10 个小时后，我会想你发送计费清单（计费清单参考下方文件），你需要按照计费清单支付我的费用（如果计费清单中的某一项你任务有问题，我们可以重新讨论 & 评估）

为什么不做计件计费？

计件计费的好处是项目从开始的时候，预算就是明确的，你的支出是明确的。但在我看来，计件计费的问题是将你我放在了一个对立面。

可以简单思考，如果某个项目按计时制是 10 小时，那么按计件计费的情况下会出现三种情况：

1. 我预估时报了超出 10 小时的计件报价：这个时候你会觉得我是不是在咋唬你，这个事情为什么会这么贵。而对于我来说，时间超出，剩下的都是赚的。你不满意，我满意。
2. 我预估时报了刚好 10 小时的计价报价：这个时候是最完美的情况，你不会觉得我白嫖，对我来说，没有多花时间， 也可以接受。你满意，我满意。
3. 我预估时报了不足 10 小时的计价报价：这个时候对于你来说是划算的，但对于我来说，我会觉得自己亏了。这个时候可能会在一些可有可无的细节上选择干脆不搞。或随便搞搞就行。你觉得你赚了？但你真的赚了么？你满意，我不满意。

可以看到，按计价计费的时候，有三分之一的概率让你我双方都满意。三分之二的概率让你我中有一方不满意。

此外，这里还有两个隐含的前提 ：

1. 项目的需求不做改动。但不做改动并不是一件好事，如果我们在项目开发过程中发现前期的需求设计有问题，需要加功能，做就要另外加钱，不做，产品无法满足要求。
2. 项目的时间预估十分准确：项目的时间预估是需要配合着一个非常完善的 PRD 来进行的。但你应该不是那种十分完善的 PRD （完善是指考虑到所有可能的情况，一个 PRD 可能十几二十页 PDF 的那种）。在 PRD 不完善的情况下，预估时间是无法做到准确的。只能按照超出项目时间来评估（延展阅读：侯世达定律）。

计时计费对你我的好处

前面说了计件计费的劣势，那我们来聊聊计时计费对你我的好处：

1. 计费透明：我在做每一项工作的时候，都会记录在 Clockify 当中，让你明确每一个步骤我在哪一天花费了多少时间。你可以根据我所花费的时间来支付费用，而不是支付一个固定的价格。对于你、我来说，都不是一件坏事。
2. 为项目好的方向进发：因为我们不再是对立面，那么我们可以向着项目最优解的方向进发。如果某个细节可以让你的产品得到更好的体验，我就会选择帮你加上这个细节。让你的项目体验做到最好。

当然，计时计费也有坏处：

1. 预算不明确：计时计费只是给出一个大致的预算，实际计费是按照所消耗的时间来计费的，因此，对于强预算需求的项目来说，这可能是个问题。

总结

如果你希望计件计费，那可以不用受累联系我，对于计件计费的项目，我一概是拒绝的。而如果是计时计费，且可以接受我的报价，那么欢迎你通过微信、邮箱等方式联系我。

我自己其实不太了解 ASoul，也没有特别的关注，毕竟作为一个社牛，不太会通过虚拟人来获取情绪价值。但我确实之前听说过 VTuber，在我的下意识以为，VTuber 的声音应该是由 AI 来完成生成，工程师建模，PM/运营来负责脚本的产出（类似微软小冰）。

不过，现实可能是 ASoul 这样的项目其实是由中之人来完成声音的录制，更接近于传统的声优的角色。对于资本来说，中之人就是一个耗材，但对于喜爱 VTuber 的人来说，中之人是非常重要的。

当一个 VTuber 之后是一个独立的人的时候，其实能贡献的当然不只是声音的问题，还可以贡献出更多的情绪价值。而这些情绪价值，正是一个 VTuber 的独特的价值。

这些东西是完全无法通过 AI 生成的么？可能是可以生成的，但暂时可能无法生成。随着技术的进步，逐步拆解出人的各种情绪和诉求，再由 AI 来完成生成，实现真正意义上的 VTuber

钉钉账号是个人所有的么？

答案是「否」，钉钉账号表面上是你自己的账号，但在企业的逻辑当中，这是「企业授权给你使用的」，本质上，这些都是企业的资产，企业是有权处置这些资源的。你所说的、所看的、所做的，都是企业提供的资产，企业可以根据自己的需求来调整这些资源的所在位置。

为什么钉钉和我们使用的微信、QQ 不同？

这是钉钉的不同的一点，在钉钉当中，任何一个账号，都是有对应的租户的（除了你的个人租户）。租户才是资源的所有者，我们只不过是使用者。 而我们使用的微信、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 太高。则需要在产品体验方面做到极致，让开发者可以更愿意选择自己的产品。