Flomo 收购了幕布，这是个我难以相信的事情。但仔细想想，其实很合理，也很有价值。
作为幕布的原持有方，字节跳动面临着业务需要收缩，战略需要聚焦的现状，养着一个幕布团队没有太大的意义，只不过是因为之前和用户的协议所迫，不得不继续维护。能过将幕布卖出去，对于字节跳动来说，是利大于弊的。且字节跳动收购产品一般是来收购团队的，而在字节跳动的产品飞书当中，已经实现了类似幕布的能力，对于字节跳动来说，幕布的历史使命已经完成，继续留着只不过是鸡肋，刚好 Flomo 要收购幕布，就可以顺利成章的将其出售出去。
而作为幕布的收购方 Flomo，则更是一个好的选择，Flomo 本身的调性和幕布十分匹配，对于 Flomo 的用户来说是利好，对于幕布的用户来说，也不算差。而对于 Flomo 团队来说，Flomo + 幕布的组合，可以让其在知识管理上进一步拓展，挺好。
一个难得的 Win-Win 的收购。当然，对于我来说还是难以想象的，毕竟，都是字节收购别人家的产品，第一次碰到从字节收购产品的。
少楠厉害！👍。
2022 年，为了保持对自己的压力，我保持了为期一年的高密度更新。回过头去看，我觉得这些更新有价值，将我思维中的碎片都展现出来了。但同样的，这些碎片过于简单和不集中，可能对于绝大多数人来说，其实很难有比较大的帮助。对于我自己来说，也只是将我的思维碎片提前拿出来，而不是在我自己的脑海里发酵一下。
在 2023 年，我对自己的定位是松弛，不再逼自己去做一些事情（即使这些事情的确很好），而是更加随性，不强求，看命，看运。
自 复盘 – ChatGPT-Feishu 项目 之后，我的项目也经历了一些迭代，OpenAI 也将最新的 ChatGPT 所使用的 API 版本进行了开放，对于我们开发者来说，无疑是一场狂欢。
而在这个过程中，ChatGPT-Feishu 也收获到了不少的关注，用户越来越多，在这个时候，我开始思考 Why？
一方面，是 ChatGPT 本来就很热，毕竟是一个 AI 新物种，看起来比过去的各种 NLP 产品都更有意思。再加上各种媒体的渲染， ChatGPT 成功的出圈了。
另一方面，是 ChatGPT 在注册和使用上存在限制，大部分的普通人是无法直接使用的，所以使得 ChatGPT 又有了一些神秘感。这种限制使得我们这些能够将 ChatGPT 的能力提供出来的项目得到了更多的关注。
而最后，则是 ChatGPT 和企业协作场景的契合，如果你将 ChatGPT 接入到企业的聊天工具中（如飞书、企业微信），就可以让一个企业的人用起来 ChatGPT，且可以在不损失企业上下文的场景下使用，可以达到非常好的日常使用的效果。
说起企业协作的场景契合，让我想起了多年前的 ChatOps。我前几天去看，Hubot 项目已经被 Archive 掉了，真的是时代的眼泪💧。
随着 ChatGPT 的逐步推广，我看到了大量基于 OpenAI 的产品出现，如果要将其分层，我认为可以分为三层：
比如我自己做的 ChatGPT-Feishu，其实就是在这个层次，更多是将 ChatGPT 和一些现成的应用进行连接，所以差异性不大，大家大多是在技术上卷一些新的 Feature。
在我看来，这个层次的卷动是非常有限的，因为现成的应用和场景就这些，大部分时候我们能做到的也就是将 ChatGPT 和现有的生态更好的结合，但没有什么本质上的变化。
当我们仔细去看社交网络上的那些 ChatGPT 的用法之后，其实你会发现， 大多数人对于 ChatGPT 的用法是非常简单粗暴的 —— 问一些过去问搜索引擎的问题。ChatGPT 会给你一个看起来还不错的答案。
这个问题背后其实是大部分人是问不出一个精确、明晰、易于理解的好问题的。
而 Prompt Engineering 层的产品则可以实现对于问题的解构，将一个复杂问题拆解为一套模板 + 一些用户可以理解和输入的内容，从而降低提问的难度。
这一层的应用更多是在卷不同的场景以及对于 Prompt 的优化，以实现更加精准和优质的返回内容，从而帮助用户解决问题。
OpenAI 对于模型提供了 Finetune 的能力，开发者可以准备自己的数据集，将其上传至 OpenAI，由 OpenAI 对模型进行微调，后续开发者可以使用经过微调的模型来进行自动的补全。
这个层面大家卷的就是行业领域认知和干净的数据了，就回到了 AI 经典的行业落地场景了：收集行业数据 – 清晰数据 – 训练模型 – 实际应用。只是 OpenAI 将这件事的难度给降低了。对于开发者来说，可以更加低成本完成整个流程。
如果你只是玩票，那我觉得第一层和第二层都是不错的。但如果你打算正经做个事情，那么第二层可能是必备的基础。
我又双叒叕遗失了我的 Kindle Voyage。
上一次遗失，还是我在医院住院时，找不到了我的 Voyage，于是我买了一个 Kindle Oasis 2。但后来出院时又找到了我的 voyage，Oasis 进入吃灰状态。
相比于 Paperwhite、Oasis，Voyage 算是我最喜欢的阅读器了：他的体积刚刚好，可以直接放进口袋里（这也是为什么我总是带着 Voyage，以及为什么这一次 Voyage 会丢掉）。
Voyage 我买于刚上大学的时候，彼时 Kindle Voyage 刚出，我便直接购买了最贵的 Voyage。从 2015 ，到如今的 2023 ，Kindle Voyage 陪伴我了 8 年时间，陪伴我走过了几百本图书的风风雨雨。
感谢 Voyage ！感谢你的陪伴，让我的生命从不孤单。
接下来的日子里，就要让 Kindle Oasis 来陪伴我了（以及微信读书阅读器 2 代）。
ChatGPT 火了一段时间了，我自己也玩了一段时间，但说实话，在 ChatGPT 的官网上使用这个东西实在是不方便，要切换机器，挂代理才能使用，于是，我便起了心念，想着可以做一个简单的飞书机器人，配置一下，这样我就可以在飞书里使用了。于是便写了一个这么个项目。
刚好 ChatGPT 又确实非常火， 于是便考虑把这个项目开源出去，于是便在 2 月 9 日的晚上，吃完饭的我打开电脑，开始了写 ChatGPT-FeiShu 的代码。
在写的过程中，我开了视频的录制，将整个开发的过程记录了下来，顺便，把项目开源出去 & 录制成一个 Vlog ，来作为我自己的记录，挺好。
当我录制完视频，写完代码之后，便将项目发出去睡了。接下来的几天里，我倒是没有太过费心的去研究这个项目，而是等待其自然发酵。直到今天，写下了这个复盘。
我觉得这个项目做的好的有以下几个点：
对于那些已经很擅长开发的人来说，其实我提供这个机器人并没有太大的价值。如果你仔细看我这段代码的话，会发现，这段代码并不复杂，核心就是解析飞书发过来的消息，并发给 OpenAI，然后将 OpenAI 的消息通过飞书返回回去。但他对于降低 ChatGPT 之类的产品的使用门槛有极大的帮助 —— 不再需要了解如何注册 ChatGPT 账号，一个企业只需要一个人配置， 就可以让整个企业的人用起来。
在后续和其他人交流时，大家对于我这个产品最大的感受是“牛，小白也可以用起来”，这个属性让我的项目得到了广泛的传播，被更多的人看到、使用，从而带来了更多后续的反馈。
这也让我更加认清出我的优势 —— 虽然我可能不是最聪明的工程师，但我可能是聪明的工程师里写教程写的最好的。虽然我可能不是写教程写的最好的工程师，但我可能是写过教程，写过代码， 还做过运营和产品的工程师，非常独特。
这个项目发布于 2022 年 2 月 10 日，距离百度指数 ChatGPT 指数级别最高的巅峰相比，稍微晚了一些。但总体来说，也不算太晚，还算是峰值比较高的时候，吃到了一波流量的红利。再加上本身简单易用，得到了不少关注和 Star。
回溯 NESHouse 时期，会发现媒体的介入帮助我快速破圈。而这次我没有寻求媒体的帮助，也让我没能完美的吃到这一波红利。暂且不说能不能帮忙去推广，我没有主动推，就没有了可能，媒体老师也是很忙的。
后续还是要多去找一些媒体老师沟通，这样有了好的项目，也可以让他们帮忙推一下，对于我来说，有更多的好处。对于他们来说，也是更好的。
说实话，这个项目因为没有什么收益的点（我并不打算做一些明确的付费服务），所以我对于项目的推进并不上心，大部分时间还在看书写字，研究自己喜欢的事情。不过得益于这个项目本身难度并不大，再加上上手很容易，还是有不少朋友进来做贡献的。感谢各位朋友参与到项目中贡献 & 在群内帮助解答问题，给我留出来了不少的空间。
后续启动一个新的项目还是要快速做投入，而不是像这次这样慢吞吞的进入，如果我可以更多的投入，或许这个项目还可以更好。
做这个项目本身也只是临时起意，半夜用了一个半小时做的，再加上当时处在十分兴奋的状态，主要还是希望能够在预定时间范围内完成开发。所以其实没有太过仔细的去设计各种 Roadmap。比如，我完全可以上一次 Product Hunt 来推广一下，但当时完全没有做。
后续还是需要提前设计，或许，我应该给自己一个明确的 Checklist 清单。
以下数据均截止于 2023 年 2 月 19 日晚 21 点。
飞书群 733 人，比想象中的要多，好在是群里的大家可以帮忙互相解决问题，降低了我的群内回复的成本。
项目一周多，有接近 400 Star 。
从前一个周期的周安装量 100 + 暴涨到 1600+，可以看得出来，拉量的效果非常不错。
借着 ChatGPT 的热点，这个视频一跃成为我所有视频当中播放量第二的视频。如果从互动数据（点赞收藏投币）来看，应该是第一的视频。
展示量 13 万，参与量和链接转化都很不错。
我在开发 ChatGPT-Feishu 这个项目的时候，并没有选择使用网页版的 chat.openai.com 的服务来进行 Hack。我在社区里看到大量通过 Hack 的方式，来提供了 ChatGPT 的 API 能力。
不可否认，网页版的能力是要比其通过 API 的方式提供的产品能力更强（毕竟模型更新），但对于一个成型的产品而言，稳定是远比能力更强更重要的。能力更强，我们可以通过一些技术手段来实现 — 比如通过数据库来实现多轮对话，可能功能不够强，但确是一个明确可以演进的方向。
Hack 官方未开放的 API ，虽然可以使用，但也带来了极高的维护成本。你可能需要不停的去更新和维护未开放的 API 的实现方式，与官方斗智斗勇。
作为一个 Side Project，没必要做的那么累。
在帮 @MikeyWei 搭建 Beyond-the-World 的网站时，他希望我能够实现 Hexo 自动的部署能力，这样作为一个写作者，他可以只关注于写作（只需要复制粘贴 Markdown）本身，不需要去处理 Hexo 本身的配置问题。所以我便借助 GitHub Action 来实现自动部署，帮助他实现想要的目标。
不过，在执行过程中遇到了一个问题，Github 提示 remote: Permission to xx x denied to github-actions[bot]
但我使用的是 Github 默认的 Secret Token ，并没有手动配置，所以并没有发现有配置权限的地方。而过去同样方式又是可以的，所以可能的问题便是 Github 提供了新的配置，导致这个 Token 默认没有权限了。
仔细研究后发现， Github 的确是新增了一个配置，在项目的 Settings – Actions – General 当中，新增了一个选项 workflow permissions。你可以通过直接修改这个选项，来为你的 Flow 提供默认的读写权限。
不过，由于我不是组织的管理员，所以没办法设置，所以我选择了另外一个方式，在 Action 的 yaml 中添加了 permission 的描述，为这个 Job 新增了写权限，默认的 Token 便拥有了写权限。
ChatGPT 与聊天软件的结合会是一个不错的爆点。因为机器人的出现，可以让你在不丢失上下文的同时，完成你的工作，这样的形态会帮助 ChatGPT 快速的完成拓展。
网页版的 ChatGPT 虽然更强，但终归还是可以通过 API 来体验到的，但集成在各种工作的上下文当中，可以帮助机器人达成更强的能力。
对于 ChatGPT 来说，飞书、Slack、Telegram、Discord、Teams 来说，都有一定的空间可以用来做一些事情。
值得你去进行一定的投入。
独立开发者很大的一个问题是能力范围有限，但有了 ChatGPT，你可以成为一个更强大的独立开发者。
自立的这条 Tweet 给了我灵感。
作为一个独立开发者，我们其实会面临很多不同场景下的需求，比如我们需要写软件的更新日志、写用户教程、做活动推广，这些对于独立开发者来说，都是需要耗费精力才能完成，有了 ChatGPT，我们（可能）可以快速获得一个80分的对应角色的人，我们可以问他们各种需要的能力，从而来提升我们做事的效率。
AI 不会让专业的人失业，但的确可能会让半吊子失去了工作。但对于 AI 的用户来说，真的是科技普惠众生了。