标签归档:随笔

a person stacking coins on top of a table

Flomo 收购幕布 – Win-Win Game

Flomo 收购了幕布,这是个我难以相信的事情。但仔细想想,其实很合理,也很有价值。

作为幕布的原持有方,字节跳动面临着业务需要收缩,战略需要聚焦的现状,养着一个幕布团队没有太大的意义,只不过是因为之前和用户的协议所迫,不得不继续维护。能过将幕布卖出去,对于字节跳动来说,是利大于弊的。且字节跳动收购产品一般是来收购团队的,而在字节跳动的产品飞书当中,已经实现了类似幕布的能力,对于字节跳动来说,幕布的历史使命已经完成,继续留着只不过是鸡肋,刚好 Flomo 要收购幕布,就可以顺利成章的将其出售出去。

而作为幕布的收购方 Flomo,则更是一个好的选择,Flomo 本身的调性和幕布十分匹配,对于 Flomo 的用户来说是利好,对于幕布的用户来说,也不算差。而对于 Flomo 团队来说,Flomo + 幕布的组合,可以让其在知识管理上进一步拓展,挺好。

一个难得的 Win-Win 的收购。当然,对于我来说还是难以想象的,毕竟,都是字节收购别人家的产品,第一次碰到从字节收购产品的。

少楠厉害!👍。

photo of silhouette photo of man standing on rock

2023, 松弛

2022 年,为了保持对自己的压力,我保持了为期一年的高密度更新。回过头去看,我觉得这些更新有价值,将我思维中的碎片都展现出来了。但同样的,这些碎片过于简单和不集中,可能对于绝大多数人来说,其实很难有比较大的帮助。对于我自己来说,也只是将我的思维碎片提前拿出来,而不是在我自己的脑海里发酵一下。

在 2023 年,我对自己的定位是松弛,不再逼自己去做一些事情(即使这些事情的确很好),而是更加随性,不强求,看命,看运。

MacBook Pro on brown wooden table

OpenAI 的 API 使用的三种层次

随着 ChatGPT 的逐步推广,我看到了大量基于 OpenAI 的产品出现,如果要将其分层,我认为可以分为三层:

Connect 层:只是在使用 OpenAI 的 API ,并没有做太多的功能提升

比如我自己做的 ChatGPT-Feishu,其实就是在这个层次,更多是将 ChatGPT 和一些现成的应用进行连接,所以差异性不大,大家大多是在技术上卷一些新的 Feature。

在我看来,这个层次的卷动是非常有限的,因为现成的应用和场景就这些,大部分时候我们能做到的也就是将 ChatGPT 和现有的生态更好的结合,但没有什么本质上的变化。

Prompt Engineering 层:预制 Prompt,帮助用户问出好问题

当我们仔细去看社交网络上的那些 ChatGPT 的用法之后,其实你会发现, 大多数人对于 ChatGPT 的用法是非常简单粗暴的 —— 问一些过去问搜索引擎的问题。ChatGPT 会给你一个看起来还不错的答案。

这个问题背后其实是大部分人是问不出一个精确、明晰、易于理解的好问题的。

而 Prompt Engineering 层的产品则可以实现对于问题的解构,将一个复杂问题拆解为一套模板 + 一些用户可以理解和输入的内容,从而降低提问的难度。

这一层的应用更多是在卷不同的场景以及对于 Prompt 的优化,以实现更加精准和优质的返回内容,从而帮助用户解决问题。

Finetune 层:对模型进行微调,以符合应用和业务的场景

OpenAI 对于模型提供了 Finetune 的能力,开发者可以准备自己的数据集,将其上传至 OpenAI,由 OpenAI 对模型进行微调,后续开发者可以使用经过微调的模型来进行自动的补全。

这个层面大家卷的就是行业领域认知和干净的数据了,就回到了 AI 经典的行业落地场景了:收集行业数据 – 清晰数据 – 训练模型 – 实际应用。只是 OpenAI 将这件事的难度给降低了。对于开发者来说,可以更加低成本完成整个流程。

如果你只是玩票,那我觉得第一层和第二层都是不错的。但如果你打算正经做个事情,那么第二层可能是必备的基础。

kindle voyage

纪念一下我遗失的 Kindle Voyage

我又双叒叕遗失了我的 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 代)。

man in black jacket sitting on white chair

走正道,可能有点慢,但更安全

我在开发 ChatGPT-Feishu 这个项目的时候,并没有选择使用网页版的 chat.openai.com 的服务来进行 Hack。我在社区里看到大量通过 Hack 的方式,来提供了 ChatGPT 的 API 能力。

不可否认,网页版的能力是要比其通过 API 的方式提供的产品能力更强(毕竟模型更新),但对于一个成型的产品而言,稳定是远比能力更强更重要的。能力更强,我们可以通过一些技术手段来实现 — 比如通过数据库来实现多轮对话,可能功能不够强,但确是一个明确可以演进的方向。

Hack 官方未开放的 API ,虽然可以使用,但也带来了极高的维护成本。你可能需要不停的去更新和维护未开放的 API 的实现方式,与官方斗智斗勇。

作为一个 Side Project,没必要做的那么累。

black and white penguin toy

如何处理 Github Action 报出的 remote: Permission to xx x denied to github-actions[bot] 问题

在帮 @MikeyWei 搭建 Beyond-the-World 的网站时,他希望我能够实现 Hexo 自动的部署能力,这样作为一个写作者,他可以只关注于写作(只需要复制粘贴 Markdown)本身,不需要去处理 Hexo 本身的配置问题。所以我便借助 GitHub Action 来实现自动部署,帮助他实现想要的目标。

不过,在执行过程中遇到了一个问题,Github 提示 remote: Permission to xx x denied to github-actions[bot]

GitHub 提示

但我使用的是 Github 默认的 Secret Token ,并没有手动配置,所以并没有发现有配置权限的地方。而过去同样方式又是可以的,所以可能的问题便是 Github 提供了新的配置,导致这个 Token 默认没有权限了。

我的配置文件

仔细研究后发现, Github 的确是新增了一个配置,在项目的 Settings – Actions – General 当中,新增了一个选项 workflow permissions。你可以通过直接修改这个选项,来为你的 Flow 提供默认的读写权限。

不过,由于我不是组织的管理员,所以没办法设置,所以我选择了另外一个方式,在 Action 的 yaml 中添加了 permission 的描述,为这个 Job 新增了写权限,默认的 Token 便拥有了写权限。

延展阅读

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token

man in black jacket sitting on white chair

ChatGPT 与聊天软件的结合

ChatGPT 与聊天软件的结合会是一个不错的爆点。因为机器人的出现,可以让你在不丢失上下文的同时,完成你的工作,这样的形态会帮助 ChatGPT 快速的完成拓展。

网页版的 ChatGPT 虽然更强,但终归还是可以通过 API 来体验到的,但集成在各种工作的上下文当中,可以帮助机器人达成更强的能力。

对于 ChatGPT 来说,飞书、Slack、Telegram、Discord、Teams 来说,都有一定的空间可以用来做一些事情。

值得你去进行一定的投入。

living room set with green dumb cane plant

你生活的地方,才是家

自大学以来,我便常年在外,每年回家的时间,不过是过年那七天。其他时间,我大多在一线城市奋斗。

而对于我来说,家也成了一个陌生的词汇 —— 焦作是我家,我在焦作生长,我熟悉我家附近的道路。但焦作也不是我家, 我早已不知道家门口的商铺是什么?他们在卖些什么、他们的生活里都是什么样的日常。

对于我来说,家是我生活的地方,它可能很大,如天津我租的房子一般;它可能很小,如我在深圳住的 10 平米的小隔间。

家是你生活的地方 —— 而不是家乡的地方。你在村里修建再好的房子,可那终究不是你的家 —— 那里只有一座气宇轩昂的房子,却没有你。你在城里住的再落魄,那终究是你的家,因为它有你。

那么,为什么一年只住几天的地方可以是家呢?

person using iMac

使用 Github 作为 Logseq 的数据同步

继之前体验 Obsidian ,如今我在使用 Logseq 作为我的日常信息记录:

  1. 有想法就放在 Journal 当中,并通过大纲的方式,让我的想法逐渐变得丰满。
  2. 使用 TAG 来区分不同的内容分类(比如编程、生活之类的)

在使用 Logseq 的时候,必然会涉及到需要做数据同步的问题 —— 没有同步万一跪了怎么办?

好在是 Logseq 提供了 Git 版本控制的能力,你只需要在设置当中开启 Git Commit 的能力,就可以让其自动使用 Git 来添加版本,从而实现将你的变更通过 Git 本身的能力来记录。

Logseq 自带的 Git 功能

当完成了 Logseq 的 Git 初始化后,自然而然的,我们便会想 —— 我能不能将其上传到 GitHub 上来完成存储?即使不分发协作,也可以很好的用来存储。答案当然是可以的,配置版本控制之后,Logseq 的仓库就是一个标准的 Git 仓库,你直接推送即可。

当发现可以推送之后,也就不担心数据的版本化问题了。那随之而来的便是 —— 我如何做数据同步?如何不让我手动上传数据到 Github 当中?

你可以借助 Git 的 Hooks 机制来完成:Github 上的开发者 CharlesChiuGit 有一个项目 Logseq Git Sync 101,其中介绍了如何实现自动的 Git 同步。

你只需将其仓库中的 Pre-commit 和 Post Commit 两个文件放置在 Logseq 目录下的 .git/hooks 目录中,即可借助 Git 自身的 Hook 能力,实现在 Commit 前主动拉取配置,避免出现数据冲突的问题,并在 Commit 之后自动推送结果,实现数据的及时上 Github。

具体操作也不复杂,只需要在 Logseq 根目录的 .git/hooks 目录下创建 pre-commitpost-commit文件即可;随后,将 Logseq-Git-Sync-101 中的文件内容复制到这两个文件中;最后执行 chmod a+x post-commit pre-commit 来实现给其添加可执行权限,即可实现在 Logseq 当中执行操作提前推送一次更新 & 拉取一次内容。

tree 效果

有了 Git Sync 101 ,我几乎可以不用担心同步数据了 —— 毕竟做研发的人,谁电脑上还能没有个 Git 了?

man in gray shirt sits on cliff

汝之蜜糖,彼之砒霜

不同的人性格是不同的。

以我为例,是一个偏社牛的性格,什么活动总想去凑一下。什么样的事情都希望去了解一下,因此也造就了我什么都知道一点的习惯。对于这样性格的我来说,参与社交活动是一种享受。

而对于社恐来说,我所做的一切,可能都是令他反感的。

而现实生活中可能并不一定能总能如愿,比如可能社牛并不会被邀请到活动当中,而社恐则总是被带到各种不同的场合当中去锻炼。

社牛和社恐都不能如愿,这大概就是社会与个人预期的错配。