我自己其实不太了解 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 太高。则需要在产品体验方面做到极致，让开发者可以更愿意选择自己的产品。
在做软件产品时，我们会无限的追求极致，希望将产品的体验、用法等各个方面全部做到最好，因为软件的交付成本低于硬件的交付成本，我们只需要一个命令，就可以将旧版的软件升级到新版。因此，我们可以通过不断的软件迭代，来将一个不完美的软件，迭代到完美的状态下。 而硬件则不同，硬件涉及到两个问题：
上述两个原因，导致我们永远不可能买到完美的硬件产品。
我以产品经理的角色参加了一个 Hackthon，整体下来体验一般。
我并不是一个一般意义上的产品经理，可以帮助你把产品细节做到极致（毕竟研发出身，满脑子都是代码）。我更擅长的是产品的流程的确定和推进。这些优势在 Hackathon 其实没有用，原因是 Hackathon 对于这个并不在意。
Hackathon 更在意的是产品的创意以及创意最终的实现。前者需要的是创意的提出者，由他来进行进一步的头脑风暴，推广。后者需要项目经理和全体团队的配合，快速推进。
唯独不需要一个单独的产品经理，来进行具体的产品需求策划。
对于很多人来说，工作是被选择，在这种情况下，这篇博客并不适合你，因为没有选择的情况下，这就是你的最优解。
不过，当你有选择的时候，你可以认真想想，你到底想要的是什么？这个可能可以在很多时候解决你的问题。思考自己的长期目标，并将自己的每一份工作安排在长期目标之下，就能更好的工作和过好自己的生活。
对于现在的我们来说，工作不一定是为了赚钱。当然，你可以因为赚钱而选择一家公司，但当你有不止一个选择的时候，你就可以思考，这份工作带给你的愉悦感和能给你带来的经济效益是否匹配。 我自己经历过独立开发者 & Freelancer 的状态，总的来说，作为一个开发者，生存并不困难。在这种情况下，其实可以考虑做自己想做的事情，而不是做自己不想做的事情，颇有一点端起碗吃饭，放下碗骂娘之感。而如果你的工作和你的长期发展方向一致的话，你就会发现，你做每一件事都是很开心的。而且你知道，你所做的每一件事都是为长期发展打基础，何乐而不为？
就像我曾经和一个小学同学一起吃饭的时候说，人这一生，痛苦就痛苦在知行不合一。就像他明明认为现有的人工智能根底在于算力的提升和数据的丰富，却坚持在高校体系内寻求算法的最优解。每天做着自己不认可的事情，是挺痛苦的。
我一直以来，吃饭的时候看的都是 B 站的视频，看一些比较搞笑的视频，快速吃饭。
不过，最近由于我看的几个视频 UP 主都开始更新放缓，我开始没有视频开始看。 所以我就开始在吃饭的时候看一些新闻（真正意义上的新闻，而不是公众号）。看报纸的感觉还不错，相比于短视频，没有那么嘈杂，也不一定要带上耳机去吃饭，一个人安安静静的刷新闻。
似乎明白了，为什么欧美的电视剧中，男主人往往是一边吃饭一边看报纸，现在在手机上看新闻的我，不就是像当年看报纸的他们么。
这么来看，iPad 还真是有一个场景。
总有人认为 Technical Writer 是写营销文档的，这里说明一下， Technical Writer 并不是写「营销文档」的，这是一种误读。
Technical Writer 实际上要负责的东西很多，比如用户文档、产品白皮书、产品设计文档等等，而不仅仅是所谓的「营销文档」。总体来说，Technical Writer 是为了帮助产品更加接近用户的一个角色，他需要能写代码，同时能写文档，能理解读者的需求，做读者和研发之间的润滑剂。
Technical Writer 的出现其实是有效的帮助研发同学降低了写文档的难度和压力的，研发同学可以写一个比较基础的版本，由 Technical Writer 来进行润色和内容的补齐，让用户更好的阅读和使用产品。就像我们去吐槽别人的文档写的烂一样，其他用户可能也会吐槽我们的文档比较烂，在这个中间，就是 Technical Writer 帮我们的文档变得更好。
不应当将二者对立起来，就像我们不应该将产品同学与研发同学对立起来一样。
Reference