一直以来，我其实对于人工智能赋能于个人十分关注。
信息流算法帮助我们获取到了更多的信息。但在体验信息流算法的时候， 也看到了算法推荐的另一个反面 —— 我们被算法控制，算法让我们相信它希望我们相信的东西。
为此，我开始抗拒算法推荐，开始使用一些更加传统的方式来完成我的信息获取 —— 使用 RSS 来阅读新闻；使用 Apple Music 来收听信息。实际上，近几年的 Newsletter 的复兴，也是一种对于算法推荐的对抗。
但这不过是我在时代的洪流之下的微弱的抵抗，并不能从根本上解决信息茧房的问题。也很难让自己得到满意的结果。究其原因，是因为现有的算法代表的是企业的利益，而不是个人的利益。现有的算法推荐都是由企业定义的，而非个人定义的。所以无法让算法真正意义上为个人服务。
我们的算法和 AI ，还需要更加的普适。
最近在 V2ex 上看到一个「8 万变80 万」的帖子，描述了作者作为独立开发者，希望借助独立开发获得自由，但最终负债累累的故事。我将作者的犯下的错，进行了梳理，得到了以下的结果，将其分享给你，帮助你来梳理自己在做的事情。
在你读下面的内容之前，我建议你先读一读作者的两个帖子，这样让你对于作者有更多的理解。
做外包开发和做独立开发是不一样的，独立开发你没有甲方帮你托底，你所面对的需求也是不明确的。而在这样的一个大背景之下，在尚未完成产品的原型和需求验证的情况下，投入数年来开发一个产品，可以说是非常愚蠢了。当然，我知道很多研发同学出来做东西都是这个问题。切忌不可闭门造车。有些东西没人做不是因为只有你慧眼识珠，也可能是你碰上了一个假需求。
ALL IN 如果成了，固然很漂亮。但 ALL IN 在绝大多数的时候是在悬崖上走钢丝。现实生活中并没有那么多故事给你听。很多时候为什么一些创业者去找 VC 投资？还不是为了给自己增加一些保护，不要让自己的创业影响到自己的生活。ALL IN 对于独立开发者而言，不可取。
前期没有现金流的情况下，低成本运作，小步快跑。
作者在一开始就学了 WordPress、Angular、Unity 等一系列技术，严重的分散了其精力。
任何人进入新的领域都应该做的是专攻一门，快速建立自己的能力和影响力，站稳再研究另外的领域。
短板的问题短期可以通过外包来解决。特别是发现自己耗费很长的时间都不能做好一件事，这个时候就应该花钱让别人来解决这个问题。不然只会让自己的时间一直浪费下去，失去了重要的机会。
在作者的另外一个帖子你会发现，很早就上了杠杆。而且是在没有现金流的情况下上杠杆，那除了利滚利，还有其他的选择？
杠杆适合放大你的收益，而不是放大你的错误。
在作者的两个帖子里你可以发现，他有不少的精力都放在了注册美国公司，办理相关的事情上了。一方面，信息差让他以为只能这么干。另一方面，推出一个产品的时候并不一定需要先有收款选项。
用户如果真的需要你的产品，他会比你还想要付款给你，因为怕你死了。
Milestone 是给自己的一个压力。此外，也是给自己一个休止符。如果时间足够，我们总是能发现自己还有各种 Bug 和 Feature，但是无休止的开发会让你失去自己的状态，也可能会让你在错误的道路上越走越远。
产品还没有 release 就开始「微服务」，典型的被技术公众号和大厂忽悠瘸了。你什么业务规模啊，就上微服务。微服务的好处和代价思考过适合你么？
资本不仅仅能帮助你提供金钱的支撑，还可以给你提供更多的视角，比如你这个业务是否值得做？你的这个业务的发展是否还有别的点是你没关注到的？资本公司
就像我们说，跳槽不是为了从当前的火坑逃出去，而应该是看到了更好的机会。
他创业的原因是看不惯现有的工作单位。初心不对，意味着全凭运气。初心不对，心态不对，一旦遇到问题，可能就会给自己造成很大的压力。
首先，在文章的开始，我先要强调，我并不是绝对不使用社会化读书软件（如：微信读书），但我使用微信读书有自己的方式。
接下来是具体的观点内容
在各种购买推荐的时候，你都会发现，所有针对 Kindle 的推荐都会提到 「无打扰」，这同样是我推荐你看纸质书/Kindle的原因。
作为手机不离身的一代人，我们现在已经习惯了「被打扰」，但不意味着这是对的，不断的被打扰，让我们无法集中精力去做应该做的事情。当我们不断被打断，我们就更应该去寻找稀缺的集中。
而在这件事上，无论是纸质书还是 Kindle ，都可以实现类似的效果。你可以沏一杯茶（或者是煮一壶咖啡），将手机关静音，放在另外的房间里，拿着一本书，或者是你的 Kindle ，在桌前仔细的阅读。
你可能会担心自己看不到消息。但这世界上有多少事情是「你一个小时不看手机」就会产生问题的。
借助一个和通讯设备分类的工具，我们可以很好的实现想要的「宁静」、「专注」的效果。
但这些，社会化读书软件是无法实现的。
几乎所有的企业都希望开发出一款拥有「网络效应」的应用。
网络外部性（network externality），又称网络效应（network effect）或需求方规模经济（demand-side economies of scale），指在经济学或商业中，消费者选用某项商品或服务，其所获得的效用与“使用该商品或服务的其他用户人数”具有相关性时，此商品或服务即被称为具有网络外部性。 最常见的例子是电话或社交网络服务：采用某一种社交媒体的用户人数越多，每一位用户获得越高的使用价值。
对于企业来说，网络效应是一个很好的工具，可以帮助留下用户，但对于用户来说，一方面它的工具性随着网络效应而获得提升，但另一方面，我们也会因为网络效应而被限制在应用当中。
微信读书等一系列社会化软件会通过产品功能的设计，让你不断的被触发，不断接入其中，让你读书也不会那么的纯粹和集中。评论、弹幕，都不断的把你从阅读中拉扯出来，进入到一个社会化的环境当中。
包括从某种角度来看，我在 B 站/ Youtube 上看视频的时候，也很少会开启弹幕（除非我看的内容本来就是很无厘头的内容），我会希望能够静下心来安安静静的欣赏一个作品，而不是不断被拖走，不断的被打断。
我在前面提到过，我其实并不是完全不使用微信读书。我自己使用微信读书的场景是这样的：
我最近开始日更博客，开始逐渐捡起我的写作的习惯，并尝试以此维持生计。
不过，我自己写文章有个坏毛病，比较意识流，这使得我的文章当中会出现很多的错别字。由于心流作用的存在，写作时我自己无法发现这些问题。
所以，我会在写完文章后，将其复制到微信公众号后台，并使用微信公众号后台自带的语法检查工具，来完成中文的基本信息的检查，降低我的错误率。
当然，除了微信公众号，你还可以有很多选择，比如 飞书文档、石墨文档等。
只是我为了让自己能够用的更爽，自己做了个插件 —— https://wordpress.org/plugins/wpstoreapp-spellcheck/
在大型企业当中，往往会有各种各样的 CI & CD 工作流来完成项目的部署，而对于我自己的项目而言，我也希望能够有这样顺畅的交付体验，因此，我也为自己的业务加上了类似的方案，以实现顺滑的开发体验。
不过，我没有做的那么重，没有上 Ansible，也没有封装 Docker，就是标准的 LNMP 环境。只不过，我在标准的环境上加入了 Laravel Envoy — 一个快速部署工具。
Envoy 是 Laravel 团队开发的一个在远程服务器上执行某些命令的工具，因为他同样使用 Blade 语法，因此在 Laravel 项目中接入非常方便。
Envoy 有多种使用方式，一种是跟随项目的使用方式，即使用 composer require laravel/envoy --dev 来安装，并使用 php vendor/bin/envoy 的方式来运作，这样的好处是你无需污染顶级目录，只在项目层面使用 Envoy 来进行部署。
不过我因为有很多项目，所以我会更加倾向于直接在全局安装 envoy，执行 composer global requre laravel/envoy 实现在全局安装 Enovy。全局安装完成后，当你需要执行命令，只需要执行 envoy run deploy，就能执行当前目录下所定义的命令。
除了全局安装，你也可以考虑使用 Bash alias 来实现类似的效果，将
envoyalias 给php vendor/bin/envoy就可以实现即使没有全局安装，也可以实现不需要手动输入前缀的特性。
当你需要配置时，你要做的很简单，只需要执行 envoy init 服务器地址/昵称就可以获得一个 Envoy.blade.php 文件，你可以通过修改这个文件的内容，来实现定义不同的工作。同样的，你可以将这个文件纳入到版本控制系统当中，从而实现部署脚本的跟踪和定义，对于后续的持续维护比较有帮助。
因为 Envoy.blade.php 也是采用了 Blade 的后缀，所以也同样适用了 Blade 引擎，你可以通过一个语意更加友好的方式来定义你的脚本。
@servers(['web' => '127.0.0.1'])
@task('deploy')
cd /path/to/site
git pull origin master
@endtask
Code language: PHP (php)比如，上面的脚本就是一个最基础的脚本，首先定义了这个脚本的命令会在名为 web 的服务器上执行，而这个服务器的地址是 127.0.0.1；并定义了一个任务 deploy。
当你完成代码的编写，并提交了 Git 之后。执行命令 envoy run deploy ，就会自动的在 web 这个服务器上执行在 deploy 当中执行的命令。
deploy 的命令只要是正常的 bash 命令即可。
因为 Envoy 使用 Blade 语法来编写，你也可以使用 Blade 语法中的命令来引入其他文件的中的任务。因此，你可以将自己常用的命令定义出来，并将其通过 Packagist 发布出去，并在实际应用过程中，引入对应的文件来使用。
@import('vendor/package/Envoy.blade.php')
Code language: JavaScript (javascript)Envoy 支持定义多个服务器以及并行执行，对于架构相对复杂的业务，你可以定义不同的 servers ，并在对应的 task 当中来设定需要在哪些 Server 上执行。定义任务时，如果你传入了 parallel 参数，则可以控制命令同时在多个服务器上并行（该属性为 false 时则是串行（
@servers(['web-1' => '192.168.1.1', 'web-2' => '192.168.1.2'])
@task('deploy', ['on' => ['web-1', 'web-2'], 'parallel' => true])
cd /home/user/example.com
git pull origin {{ $branch }}
php artisan migrate --force
@endtask
Code language: PHP (php)你可以在 Envoy.blade.php 中加入 @setup 来完成变量的定义，并在后续的代码中使用。
@setup
$now = new DateTime;
@endsetup
Code language: CSS (css)也可以直接使用 @include 来引入文件
@include('vendor/autoload.php')
@task('restart-queues')
# ...
@endtask
Code language: PHP (php)在启动时，如果你使用诸如 --param=value这样的参数来调用，则可以在你的代码中直接读取对应的变量，从而实现执行时带入不同的参数。
Envoy 当中还有更多的用法，这里不再一一列举，如果你感兴趣，可以直接参考其官方文档，了解如何使用 Envoy 达成你的部署目标。
在你不是很着急使用 Ansible 或 更重的部署工具的时候， Envoy 是一个不错的选择。特别是你使用 Laravel 进行开发时，Envoy 就是一个有效的工具。
多年来，我一直是 PHP 的拥趸，不论中间我写过多少编程语言，但我始终觉得，PHP 能从 2000 年活到现在，是有其意义和价值的。
而到了现在，我终于可以回答这个价值和意义到底是什么 —— 什么样的业务，使用什么样的架构。
作为技术创业者，我们最常遇见的问题，便是过度设计技术方案：我的项目是不是应该做个数据库主从备份？我的项目是不是应该做 Kuberentes 集群来处理弹性？
但实际上，对于绝大多数的业务而言，这些问题都是根本不重要的 —— 如果没有 Kubernetes，我们能否保证我们的业务的稳定性？如果没有主动备份，我们能否保障我们的业务可以平稳运转？
技术在绝大多数的业务中，都是一个成本中心，是一个保障业务正常运转的基石。他应该被重视，但不应该被过度重视。一个创业公司可能会因为业务不够稳定而失去用户，但绝不会因为业务非常稳定而留住用户。用户在乎的是你为用户解决了什么样的问题，而不是用了什么样的架构。
过度（提前）优化是万恶之源。
今天在和 @bobo 聊天的时候，讨论起了摊销这个话题，我觉得很有价值，因此记录下来。
事情的前提是出于控制开支的目的，我在 2022 年为自己定下了 10000 元的数码设备采购预算，这个预算是考虑到我不需要在 2022 年更换手机（ 2021 年刚换了 iPhone 13 ，我的预期是用到 2024 年），我不需要在 2022 年购买新的相机（我已经有了 6400、ZV1、G7X3，主要的几个需求都满足了，唯一希望买的是 GR3/GR3X，但不是特别急），唯一想要买的就是 采用了 M2 的 Macbook Air（32G 内存，512 GB ～ 1TB 的 硬盘），但我不确定新的 Macbook Air 能够在我的预算内解决，所以其实一直比较忐忑是否能买。
不过，今晚和bobo聊的时候，他提出了一个方案，或许可以解决我的问题 —— 摊销。
虽然我今年给自己定的数码设备的预算是有可能无法满足我的采购诉求，但我可以借助于信用卡本身的 24 期分期付款的方式，来实现需要单次支出的成本被摊销到接下来的 24 个月里，这样虽然我支付的钱没有变少，但却将整体的记账周期拉长，从而实现了我在今年的预算不会超出预期。
通过摊销，我超期消费了明年的预算，解决了今年的问题，确实是一个很好的解决方案（当然，也是信用卡分期的意义）。不过，这也反过来让我思考企业的预算和摊销体系，可能作为一个员工，我们会认为思考预算是有点奇怪的，业务随时可能增长，预算必然被打破，但换个角度来看，如果我们的预算在可控范围内进行增长，就可以在享受到摊销带来的价值的同时，不至于过度消费未来。
我近几年一直在用 MoneyWiz 在记账，之前也写过一些关于关于 MoneyWiz 的文章
得益于 Moneyiwz 的预定功能，摊销也可以以一个十分轻量的方式来完成，现在，我更期待今年的发布会了！。
在农历生日的时候，我为自己写下了「写在 26 岁」，而今天，是我的阳历 26 岁。
在上一篇文章当中，写的很丧气，我自己都很焦虑。在这一篇文章，希望能给自己打打气。
26岁在人生漫长的八十多年里，并不能算得上特殊。不过，自己选择的路线确实会让这一年显得特殊一些。新的一年，祝你能够心想事成。在做的事情能够有一个好的结果。
如果可以的话，今年做一个大胆的选择，去试一试过去可能没试过的东西，体验一个不一样的生活。
别浪费了自己的 26 岁。
最近观察到一个现象，我认为一个非常「理性」，拥有着「理工科思维」的前辈，他的配偶却显得「贪小利」、「情绪不稳定」，这似乎是很奇怪的事情。难道「理工科思维」、「沉稳」的前辈不应该是找一个很稳重的配偶么？
但随时时间的流逝，我又有了新的看法。
作为一个普通人，当我们掌握了「理工科思维」和使用理性指导生活的方式和方法后，我们的生活可以非常容易走上正轨。我们在做各种选择会比依靠「情绪」来指导我们的生活的人会更加稳健、更加轻松、更加富有确定性。
但理工科思维未免过于范式固定，在这种情况下，我们的生活可能是一成不变的，朝着一个确定的目标上走着，在一个明确的轨道上行驶。
一个不那么稳定的配偶，可以为他的生活中添加一些变量和变化，让生活变得不那么枯燥。从这个角度来说，也挺好的。
这篇文章也是在试图用理性的逻辑来分析一个现实生活中的问题。但可能我说的全都是错的。
最近在读《如何成为顶级记者》，总体来说，不同的记者有不同的切入视角，但如果要找一个能够综述所有人的关键点就是 —— 「离事情发生的地点足够近」。无论是通过自己的数据分析找到真正的事情发生点，还是和当事人建立更加友好、更加深入的联系，都是为了达成「离事情发生的地点足够近」这个诉求。
而当我总结到这里时，我突然在思考一个问题：我的问题真的是如何成为一个顶级记者么？
显然不是，我必然是会在编程和工程师的路上越走越远的，我的目的其实是：「如何录制好一档访谈类型的播客」，而这个问题如果细化的话，其实真正的问题应该是「如何提出一个正确的问题」。
当我明确了正确的问题之后，那就知道正确的 Action 应该是什么 —— 「学习提出正确的问题」。
回到这个事情本身，我其实在初期也进行了思考：从做一个好的访谈播客出发，推导出我需要具备优秀的访谈能力，而优秀的访谈能力往往出现在优秀的主持人和优秀的记者身上，因此我推导出了需要去学习顶级记者的思路。但是，问题的思考还不够深入，如果进一步推导和抽象，才能得到正确的答案 — 「提出一个正确的问题」。