我是一个比较反感“反问”的人。
总的来说，是因为我对于反问的感观不太好，特别是反问背后所表现出的挑战（这可能源自我是一个不那么自信的人）。反问带给我的感受更多的是“不认可”、“不信任”，从而激起我的反抗。反问，拥有一定的攻击性。
而疑问，则是一个更好的选择，特别是在人多、鱼龙混杂的时候，能够更好的隐藏自己的意图，将自己保护起来。反问则会更加暴露出你的倾向，并不适合自我保护，过于锋芒毕露。
提醒自己，不要做一个总是”反问“的人。
疑问，是更好的提问方式
发表评论
分类目录归档：随笔
大部分中国人没有信仰
大部分中国人是没有信仰的。
你可能会问，中国人不是也去寺庙去拜佛，也到教堂去做礼拜。为什么说中国人没有信仰呢？
在维基百科中，对于信仰的定义是“人事物或概念的坚定信念或信任。”，但对于那些去寺庙拜佛、去教堂礼拜的人来说，他们可能并不坚定的认为这些“神”的存在的，他们关注的也不是自己对于“神”的信仰，而是关注神到底能为自己解决多少问题？
这也是为什么我们发现，财神庙总是香火最旺。
推荐一个最近发现的好东西 — Save To Notion
这个工具是我在研究别人的的 Notion 工作流时发现的，一个支持从网页中提取核心数据的 Notion Saver 插件 —— Save To Notion（官网）
和绝大多数 Notion Saver 类似，Save To Notion 也支持直接存储一个书签到 Notion 当中，对于平时需要大量阅读的人来说，这是一个和其他产品无法形成差异化的 Feature。
但 Save To Notion 一个非常厉害的功能，是你可以在你的保存表单中，设置从网页中提取数据，它应该是采用了 XPath 来实现这个 Feature，你可以根据自己的需求，从页面中选择数据来提取，从而可以基于 Notion 完全实现一套自己的数据库。相比于其他 Saver，多了一步解析数据的能力，而这个能力，可以帮助你节约许多的时间。
Just Use IT！
Flomo 收购幕布 – Win-Win Game
Flomo 收购了幕布，这是个我难以相信的事情。但仔细想想，其实很合理，也很有价值。
作为幕布的原持有方，字节跳动面临着业务需要收缩，战略需要聚焦的现状，养着一个幕布团队没有太大的意义，只不过是因为之前和用户的协议所迫，不得不继续维护。能过将幕布卖出去，对于字节跳动来说，是利大于弊的。且字节跳动收购产品一般是来收购团队的，而在字节跳动的产品飞书当中，已经实现了类似幕布的能力，对于字节跳动来说，幕布的历史使命已经完成，继续留着只不过是鸡肋，刚好 Flomo 要收购幕布，就可以顺利成章的将其出售出去。
而作为幕布的收购方 Flomo，则更是一个好的选择，Flomo 本身的调性和幕布十分匹配，对于 Flomo 的用户来说是利好，对于幕布的用户来说，也不算差。而对于 Flomo 团队来说，Flomo + 幕布的组合，可以让其在知识管理上进一步拓展，挺好。
一个难得的 Win-Win 的收购。当然，对于我来说还是难以想象的，毕竟，都是字节收购别人家的产品，第一次碰到从字节收购产品的。
少楠厉害！👍。
2023, 松弛
2022 年，为了保持对自己的压力，我保持了为期一年的高密度更新。回过头去看，我觉得这些更新有价值，将我思维中的碎片都展现出来了。但同样的，这些碎片过于简单和不集中，可能对于绝大多数人来说，其实很难有比较大的帮助。对于我自己来说，也只是将我的思维碎片提前拿出来，而不是在我自己的脑海里发酵一下。
在 2023 年，我对自己的定位是松弛，不再逼自己去做一些事情（即使这些事情的确很好），而是更加随性，不强求，看命，看运。
ChatGPT-FeiShu 为什么能火？
自 复盘 – ChatGPT-Feishu 项目 之后，我的项目也经历了一些迭代，OpenAI 也将最新的 ChatGPT 所使用的 API 版本进行了开放，对于我们开发者来说，无疑是一场狂欢。
而在这个过程中，ChatGPT-Feishu 也收获到了不少的关注，用户越来越多，在这个时候，我开始思考 Why？
一方面，是 ChatGPT 本来就很热，毕竟是一个 AI 新物种，看起来比过去的各种 NLP 产品都更有意思。再加上各种媒体的渲染， ChatGPT 成功的出圈了。
另一方面，是 ChatGPT 在注册和使用上存在限制，大部分的普通人是无法直接使用的，所以使得 ChatGPT 又有了一些神秘感。这种限制使得我们这些能够将 ChatGPT 的能力提供出来的项目得到了更多的关注。
而最后，则是 ChatGPT 和企业协作场景的契合，如果你将 ChatGPT 接入到企业的聊天工具中（如飞书、企业微信），就可以让一个企业的人用起来 ChatGPT，且可以在不损失企业上下文的场景下使用，可以达到非常好的日常使用的效果。
说起企业协作的场景契合，让我想起了多年前的 ChatOps。我前几天去看，Hubot 项目已经被 Archive 掉了，真的是时代的眼泪💧。
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。
上一次遗失，还是我在医院住院时，找不到了我的 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-Feishu 这个项目的时候，并没有选择使用网页版的 chat.openai.com 的服务来进行 Hack。我在社区里看到大量通过 Hack 的方式，来提供了 ChatGPT 的 API 能力。
不可否认，网页版的能力是要比其通过 API 的方式提供的产品能力更强（毕竟模型更新），但对于一个成型的产品而言，稳定是远比能力更强更重要的。能力更强，我们可以通过一些技术手段来实现 — 比如通过数据库来实现多轮对话，可能功能不够强，但确是一个明确可以演进的方向。
Hack 官方未开放的 API ，虽然可以使用，但也带来了极高的维护成本。你可能需要不停的去更新和维护未开放的 API 的实现方式，与官方斗智斗勇。
作为一个 Side Project，没必要做的那么累。
如何处理 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 默认的 Secret Token ，并没有手动配置，所以并没有发现有配置权限的地方。而过去同样方式又是可以的，所以可能的问题便是 Github 提供了新的配置，导致这个 Token 默认没有权限了。
仔细研究后发现， Github 的确是新增了一个配置，在项目的 Settings – Actions – General 当中，新增了一个选项 workflow permissions。你可以通过直接修改这个选项，来为你的 Flow 提供默认的读写权限。
不过，由于我不是组织的管理员，所以没办法设置，所以我选择了另外一个方式，在 Action 的 yaml 中添加了 permission 的描述，为这个 Job 新增了写权限，默认的 Token 便拥有了写权限。
