普通视图

发现新文章,点击刷新页面。
昨天以前Randy's Blog

让 AI 戴着镣铐跳舞

2025年12月27日 08:00

最近临时在帮朋友做一些外包,基本上代码都是 AI 写的,我想如果不是有 AI, 我大概不会帮这个忙,因为即使这些活不难,我还是要写很多代码。但现在,我可以一个人同时做 2-3 个项目。

在这个过程中,更加让我确定了对于程序员来说,软件开发的范式已经彻底彻底改变了。生成代码再也不是程序员「应该」做的事情,而是应该被放手给 AI 做的事。

这也让我对判断一个程序员的能力从代码能力转变成了使用 AI 的能力,我想,如果我现在要为团队招程序员,我会在面试时着重了解这个人如何使用 AI 完成一个需求。

对于程序员来说,「使用 AI 的能力」包含很多维度,这些维度综合起来,才决定 AI 是否真正能成为程序员的杠杆:

对业务的理解

软件是为解决用户的需求而生的,对业务充分理解,才能给 AI 足够的业务场景上下文,才能让 AI 写出覆盖边界条件的代码。

对业务的理解同时决定了程序员是否可以做好数据库建模。在接我朋友的外包项目时,我发现我人工干预最多的就是数据库建模。只要我思考好建模,AI 就能基于这个数据库模型编写任何接口。

对技术栈的理解

如果能让 AI 限定在特定的技术栈中,你会发现 AI 更能稳定发挥,更可控。让 AI 「带着镣铐跳舞」。无论用什么技术栈,重点都是给 AI 一条稳定的轨道。比如我在所有项目的 AGENT.md 中都会列出非常细节的选型,例如 CC Mate 的 https://github.com/djyde/ccmate/blob/main/CLAUDE.md

当 AI 知道技术栈后,通过 context7 这样的 MCP, 它能在生成代码时,找到对应的文档作为上下文,生成出更不容易出错的代码。换句话说,确定好技术栈,让 AI 成为这个技术栈的专家为你编写代码。

因此,在这个层面,程序员的「使用 AI 的能力」意味着,这个程序员知道什么样的场景适合什么样的技术栈,也侧面反映了这个程序员对技术社区是否保持敏锐的嗅觉。这是我认为 AI 时代程序员的一种硬实力。

对架构的理解

在《代码之外》听友线下见面会中,有听友提问,在 vibe coding 的时候,AI 只能做些一次性的软件,多次迭代后就会变成灾难。我的回答是,这是因为没有给 AI 提供一个你设计好的工程架构,让他在这个架构中行动。在这个新的时代,程序员应该以架构师的角度来工作。

我在 AI coding 一个项目前,我的脑海里会大概有一个工程架构的设计,比如,通用工具应该被统一放到一个什么文件,前端页面应该如何组织,接口应该遵循什么样的规范,错误处理应该怎么做等等。只要架构设计好,写在 AGENT.md 中,AI 自然会按照你的设计去做,而不是让 AI 天马行空地发挥。

不仅是在启动这个项目前要做好架构的思考,在维护的过程中,你指挥 AI 完成一个新的需求时,就应该思考完成这个需求的时候,将会有什么代码被写在哪一个地方。这个场景也适合使用各个 AI coding agent 的 Plan Mode 来完成,当 AI 告诉你它将要如何行动时,适当二次确认它要如何组织新的代码。

做到以上三个理解,我相信程序员可以游刃有余地使用 AI. 但我曾经在很多场合接触一些在一线写代码的程序员,发现他们对 AI 的接受程度是如此地低。很大程度上,我认为是一个缺乏以上三个理解的程序员,很难对 AI 建立信任关系,合作关系。

和我合作的一位程序员,在共同完成一个需求的时候,我在他旁边观察了一下他如何使用 AI, 结果只是非常浅地使用 auto complete. 我问他,为什么不尝试让 AI 完整地完成这个需求,他表示他认为 AI 不能胜任这个任务。

我说:

  1. 我的后端接口已经写好了,而且有了 openapi 的 YAML 文件(AI 生成的)
  2. 你知道这个需求涉及前端的哪个页面,在前端项目中,也有对数据请求层进行封装(AI 一定能知道怎么写数据请求)

满足了这两个条件,你只需要把接口文档给 AI, 然后告诉 AI 这次的需求,再告诉 AI 一点提示,大概是在哪个文件中修改。以现在旗舰模型的能力,AI 大概率能一次性完成。

他将信将疑,我直接在他电脑上给他演示这个操作,果然,AI 直接完美地完成了这个需求,不到 2 分钟。

而同时我也在思考,到底 AI 时代是否还需要程序员,或说需要怎样的程序员,好像渐渐有了答案。

在 Claude Code 中使用 GLM 4.6 的体验

2025年10月8日 08:00

最近我在编程上一个很大的变化是把持续月付了将近 1 年的 Cursor 换成了 Claude Code. 之前一直不用 Claude Code 原因有二:

  1. Claude Code 在中国使用非常困难,我已经算是比较愿意折腾的人了,也折腾不动它。在 Cursor 中使用 Claude 模型则非常方便。
  2. 我不是很喜欢完全在 CLI 中 AI 编程,因为我使用 AI 编程的方式比较像 Copilot 而不是结对编程的形式。也就是说我喜欢在像 Cursor 这样的编辑器中,精确告诉 AI 要改动什么文件,或要针对哪几行的 code 进行改写。我认为在 Claude Code 中要做到这种「指哪打哪」非常困难。

这次转变的契机在于,上个月我竟然把 $20 的 cursor pro 额度花光了(我日常使用的是 Claude Sonnet 4),只能用 Auto Mode, 这使我的生产力断崖式地下降。这时候,恰好智谱推出了「编码畅玩套餐」(并非广告,智谱看到的话可以联系我打钱),推出了兼容 Claude Code 的接口,价格还相当便宜。于是我开始再次尝试 Claude Code.

Claude Code 使用体验

最初我还是非常不习惯不在 editor 里操作 AI, 因为觉得这样很没有安全感。不过在慢慢磨合之后感觉没有我想象中那么糟糕。

在 Claude Code 中可以使用 /ide 连接 IDE, 连接后 Claude Code 可以识别出当前 IDE 打开的文件是什么,这样能达到 Cursor 类似的效果。所以 Claude Code 也能得知我希望的是结合指定文件作为改动基准。

在 Cursor 中我还会手动 @ 不同的文件指定 AI 修改的文件,出乎我意料的是在 Claude Code 中 @ 文件的体验也相当不错,所以在体验方面,Claude Code 基本可以对齐我使用 Cursor 时的习惯。

另外一个常用的场景是我会选择具体的代码行让 AI 改动,这一点在 Cursor 做得很好。Claude Code 连接了 IDE 后也能识别到。

ide connect  不过我感觉实际 Claude Code 并没有很「在意」我选的行,它经常会失控多改些东西,我不确定这是模型还是 Claude Code 的调校问题,我认为 Cursor 在这个场景是有做专门的 prompt 调校的。

Cursor 做得非常好的其中一个体验是它的 Restore, 你可以随时在 AI 改动的点撤销改动,也可以直接 Undo all 撤销整个会话的改动。这一点 Claude Code 还是逊色不少,现在我不得不在下一次改动前 git commit 我当前的改动。

Claude Code 2.0 之后新增了 /rewind 命令,也可以基于对话历史进行回撤,但远不如 Cursor 在 GUI 上做得好。而且如果你关闭了当前的对话后,也无法再进行回撤了。

在 Claude Code 中使用 MCP 一开始让我相当困惑。当我在项目路径通过 claude mcp add 安装 MCP 后,我发现在其它项目中并没有这个 MCP, 后来我才知道,需要指定安装的 scope, 默认是项目范围,如果要安装全局跨项目的 MCP, 需要加一个 --scope user 参数:

claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic

我使用的 MCP 只有 exacontext7, 这两个 MCP 都是用于查找文档的。我在 Cursor 中从来不用,因为 Cursor 可以直接在设置中输入文档地址进行索引,对话时用 @docs 就能把文档加到上下文中。这一块我还是喜欢 Cursor 的体验,当然 context7 和 exa 也能完成任务。

Claude Code 让我比较喜欢的是 Plan Mode. 对 AI 描述要做的事情,它先给你输出一份它的行动计划,我 review 完觉得 ok 才开始做,不 ok 就进一步沟通,直到满意为止。

GLM 4.6 的体验

说实话在使用 GLM 之前,我对它的质量持怀疑态度。经过一个月深度使用后,我认为它远超了我的预期,并且个人感觉非常非常接近 Claude Sonnet 4 的水平(我用 Sonnet 4.5 还不多,所以无法对比)。

在此之前,我一直用的是 Sonnet 4, 可以说 Sonnet 4 和我磨合得已经相当好了,它就像跟了我一年的 engineer, 我对它的能力和做事风格相当地熟悉,所以能很好地彼此配合完成任务。因此在接触 GLM 4.6 的期间,我认为我是很有话语权把它们两个进行对比的。

首先是速度,GLM 4.6 在速度和质量取得了很好的平衡,平均速度我认为比 sonnet 4 更快一点点,偶尔抽风会特别慢。

质量上,我认为从 bug 的数量上来看,和 sonnet 4 没有我能感知到的差别。我的代码主要以前端 TypeScript 和 Rust 为主,在生成 Rust 代码时,GLM 和 sonnet 4 基本一样一气呵成,偶尔会有错误,但把错误日志再输入给它时,就能修好。

无论是前端还是后端还是什么语言,对于这两个模型,我的经验认为,只要你能给到足够的文档作为上下文(例如使用 exa, context7), 效果都会非常好。因为生成功能性的代码主要需要的能力是按照文档进行推理,对于目前旗舰级的模型来说已经不是特别难的事。

claude code

而我认为最能体现一个模型真正的编程智能的任务是重构。因为模型 agent 需要自己对整个 codebase 进行理解、搜索、规划重构方案的流程不是照着文档抄那么简单。我特意使用了 GLM 对某个项目进行了技术栈的重构,比如在一个充满 useEffect 的 React 应用,我让它用 @tanstack/react-query 进行重构,GLM 十分出色地完成了任务,而且速度相当快,准确率很高,偶尔出错时,它自动参考 lint error 重新修改也能完成任务。

用一个比喻来总结 GLM 4.6 和 Sonnet 的对比,我认为如果说 Sonnet 是 P7 级别的工程师,那么 GLM 4.6 是 P6+ 级别的。有时候 GLM 完成的任务,你需要再提醒多那么一句,它才能达到完美。

但考虑到这是一个只需要 40 人民币一个月(首月 20)的模型,我觉得完全可以接受了。

如何配置 Claude Code 使用 GLM

顺便分享一下如果要在 Claude Code 中使用 GLM 需要怎么配置。

使用 CC Mate

最简单的方法是使用我最近做的 CC Mate 这个小工具。安装好 Claude Code 后,在 CC Mate 填一下 API Key, 所有的配置都会帮你处理好,这时打开 Claude Code 就已经是在使用 GLM 了。

CC Mate

CC Mate 支持多个配置随意切换,所以如果你想用 Kimi 也可以创建一个 Kimi 的配置。

另外 CC Mate 还有管理全局 MCP 的功能,你可以一键把我文中提到的 context7 和 exa 安装到全局 MCP 当中。

MCP

注意:安装完 MCP 后,需要在 Claude Code 中使用 /mcp 给它们登录授权。

手动配置

首先购买「编码畅玩套餐」, 然后新建一个 API key.

然后手动修改配置文件 ~/.claude/settings.json 如下:

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "your-api-key",
    "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "GLM-4.5-Air",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "GLM-4.6",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "GLM-4.6",
    "ANTHROPIC_MODEL": "GLM-4.6"
  }
}

配置后,你能正常使用 Claude Code, 但你会发现,如果你使用 Claude Code 的 VS Code 插件,你是进不去的,它强制要求你先登录 Claude 账号。所以你需要再添加一个文件 ~/.claude/config.json:

{
  "primaryApiKey": "xxx"
}

xxx 只是一个占位符,什么内容都无所谓。

这时你就可以正常使用 Claude Code 的 VS Code 插件了 (这个配置在 CC Mate 中也已经帮你做好了)。

P.S. CC Mate 的开发过程完全使用 Claude Code + GLM 4.6, 基本 80% 的代码都是 AI 编写的,我只作为架构设计以及 UI 设计。

我们高估了智力的重要性

2025年4月1日 08:00

在 AI 越来越强大的这段时间里,我思考得比较多的一个问题是,我们是否高估了智力的重要性。

引起这个思考的原因有很多,一是大语言模型的进化程度让我感受到,语言模型在智能(推理、学习速度、知识广度等)方面已经远远超越人类,而这样的智能是每个人都能运用的。也就是说,人类完全可以把需要智能的行动交给 AI 处理,人类更多地是负责决策层面的工作。

二是因为我自己就是一个智力平平的人,小学当我学到除法的时候,我花了很长时间才理解除法是什么。我在开始学 JavaScript 的时候,也花了很长时间理解什么是 callback, 为什么函数能作为参数被传递和调用。

但我这个智力平平的人还是得到了算是不错的成果。我总是对别人说,我不是一个很聪明的人,我只是 13 岁就开始学编程,笨鸟先飞罢了,很多人大学学一年就能超过我的水平。所以我才更深刻地体会到,正常水平的技术,往往通过时间可以弥补,在这条水平线,不需要很高的智力。

不过,即使通过时间可以弥补智力的不足,但不是很多人能在这段时间里坚持下去。这也引出了我认为智力被高估的同时显现出来了另一个问题 —— 自我效能 (self-efficacy) 的重要性被远远低估了。

所谓的自我效能,是指相信自己有能力成功完成特定任务或应对特定情况的信心。很多复杂的因素决定了一个人自我效能的高低,这并非天生的。成长过程中长辈的态度、通过对他人的观察、个体与环境互动等等都影响一个人的自我效能水平。

在同样面对一个问题,自我效能低的人,看到的往往全是问题,最终放弃。而自我效能高的人,有强大的信念认为可以解决问题。前者也许在智力上比后者更高,但后者可以通过这种信念一直前进,超越前者。

图由 gpt-4o 生成

尤其是在 AI 时代,智力变成了一种更容易弥补的差距。我认为智力是边际效益递减的,除非超过了某个阈值。但这永远是很小一部分的人。像我这样智力平平的人是多数,我们只是站在了巨人的肩膀上。就像 Dijkstra 只有一个,这个世界也需要他这样的天才,但我们还是可以享受他给我们带来的成果。

这不是反智,而是我认为,智力水平有一个临界点,对于临界点以下的人,智力的重要性被高估了,因为智能越来越不稀缺,稀缺的是自我效能,是主动利用智能的人。

自我效能是完全可以通过后天训练的。自我效能是心理学家 Albert Bandura 提出的概念。他总结了影响自我效能的四种因素:

掌控经验 (Mastery Experiences)

个体通过亲身成功完成任务的经验来建立自信。反复的成功会增强自我效能,而失败(尤其是早期或没有应对策略时的失败)则会削弱它。

我觉得这里指的「成功」并非大成功,而是细微的成功。例如在我学习编程的早期,我通过写出各种各样的小程序获得这种成功感,对我建立技术自信有很大的帮助。

替代经验 (Vicarious Experiences / Modeling)

观察与自己相似的人成功完成任务,会提升观察者对自己也能做到的信念。看到别人能行,会觉得“我也许也可以”。

对我来说,小时候读的名人(科技精英)传记就是一种 Modeling, 尤其是李开复的《世界因你不同》,这些「洗脑」式的输入,会让我越来越希望自己能成为这样的人。

乔布斯有一句广为流传的话,他说

Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you.

一旦你认识到一个简单的事实——你周围那些你称之为“生活”的东西,都是由并不比你聪明的人创造出来的——你的人生就会变得更为广阔。

乔布斯从更极端的思路获得高度的自我效能感 —— 通过对比别人不行,觉得自己可以。

社会说服 (Social Persuasion):

受到他人的鼓励和积极评价可以增强自我效能感。而负面评价则会削弱它。

这个条件比较被动,这里不谈。

生理与情绪状态 (Physiological and Emotional States)

个体在面对任务时的生理反应和情绪状态会被解读为自身能力的信号。如果将紧张解读为“我不行”的证据,自我效能会降低;如果解读为“兴奋”或“迎接挑战”,则可能不会降低甚至会提升。

在这个方面,我面对舞台的经验可以充分论证。记得第一次面对众人做技术分享和第一次上台唱歌,我紧张得不行,表现都很糟糕。随着不断地强迫自己上台,我发现自信完全取决于自己的念头,我学会在上台前欺骗自己是一个有很多粉丝的人,台下的人对我非常崇拜,或很喜欢听我唱歌,这样的念头让我在台上的表现有很大很大的改进。

人是事件的反应器,通过刻意训练,是可以掌控自己的反应的。

以上是我对 AI 时代的到来的其中一点思考,希望能鼓励到和我一样智力平平的人。

我如何使用 Apple Notes 做笔记

2025年2月9日 08:00

我从两年前开始放弃了所有笔记软件,换用 Apple Notes 记录我的所有笔记。这个举动缘于我读了 Tiago Forte 的一本书 The PARA method.

the para method

可能大家比较熟悉他的另一本书 Build The Second Brain, 是关于如何使用笔记软件构建自己的「第二大脑」。这本书也有提到他的 PARA 理论(我在我之前的文章也有提到过我如何应用这个理论管理我的笔记)。两本书都读过以后,我认为 The PARA Method 这本书更偏向实操,我从中收获了更多的方法论。如果你只想读一本,那么我推荐读这一本。

读完这本书后,我立即在 Apple Notes 中基于 PARA 方法建立起了笔记组织的形式,这一套组织形式一直用到了两年后的今天都没有改变过。也就是说,这两年来,在做笔记时我再也没有花过时间去想应该如何组织我的笔记,光从这一点,就让我受益颇深,我可以没有任何心智负担地迅速记下我需要的东西,不用担心我应该怎么记,一切都是那么的简单。

这篇文章就是想和你分享我如何在 Apple Notes 记笔记,我在 PARA 的基础上根据我自己的实际场景做了一点小小的改良。希望对你也有所启发。

为什么是 Apple Notes

在分享方法论之前,我想先解释为什么我选择了 Apple Notes. 我认为 Apple Notes 有很多优点。

  1. 它是系统自带的,我在手机、电脑上可以直接使用,不需要安装额外的 App
  2. 它天然是支持同步的,不需要注册账号,不需要把资料上传到别人的服务器上。It just work.
  3. 你可以直接在 Apple Notes 中粘贴文件、图片、音频,没有限额(严格地说这也占用你的 iCloud 存储,但我本身已经买了存储,这变成了边际成本)。
  4. Apple Notes 打开的速度很快。

当然 Apple Notes 也有缺点,但两年使用下来,我没有因为这些缺点感到被限制,比如:

Apple Notes 支持的格式有限,只有最基本的列表、标题、加粗等等的文字样式格式。但我用下来发现,我根本不需要使用什么高级的格式。有人问我 Apple Notes 不支持代码块,你是怎么记代码相关的笔记的?我说我基本不会把代码片段作为笔记来记。比较多的场景是一些 JSON 格式的片段,我只会直接粘贴到笔记里,不加任何的格式。

我找到了两条比较经典的笔记:

可以看到,里面不仅有 JSON, 还有 toml, 还有命令行。甚至还会有 spell check 的红线让它显示得很丑。但是我一点也不在意。因为它们是拿来用的,不是拿来看的,我不在乎它好不好看,只要我需要用到的时候能找到拿来用就好了。

也就是说,「美观」在我记笔记的需求里排不上什么优先级,我的最高优先级是能快速打开,快速记录,让我记东西的摩擦力降到最低。能帮我当下的想法、要处理的事情相关的信息记下来才是最重要的。所以我看过很多人把 Notion 模板做得很漂亮,也不为所动,因为对我来说这不是我需要的东西。不可否认,美观的笔记系统能给人情绪价值,它没有对错之分,只要合适自己就好。所以最重要的是知道自己是否需要,如果你认为这对你来说不是很重要,就回归简单吧。

Apple Notes 也没有「双链」功能,这是现代流行的笔记软件中很重要的功能,我在用 Logseq 的时候也被这个功能打动,因为它能把相关的笔记自然地关联到一起,带来额外的启发。最初用 Apple Notes 时我也担心会不会因此失去了这个优势,但用下来才发现,我并不是那么的需要它,即使没有,也没有让我感觉因为没有了他而失去了灵感。

Apple Notes 的标签功能也很弱,但我不使用标签。

PARA 是什么

虽然在之前的博客也提到过 PARA, 但我还是想在这里简短地解释一下我所理解的 PARA 是什么。

PARA 的全称是 Project, Area, Resource, Archive. 翻译成中文就是「项目」「领域」「资源」「归档」。它代表了一个笔记应该放在什么地方以及一个笔记的流动过程。

PARA

没错,在 PARA 的方法论中,笔记是可以「流动」的,它有时候在 Project, 当项目结束后,它不再被需要,就会流动到 Archive. 如果它在以后有利用价值,它可能会流动到 Area 或者 Resource.

  • Project 指的是你现在正在进行的项目,比如你正在构思的一篇文章,你正在做的一个项目等等
  • Area 指的是和你有关的领域,比如如果你是设计师,那么设计就是一个你的领域。
  • Resource 指的是你会用到的资源,个人理解它和 Area 是一样的,只是优先级的不同。假如你是设计师,你偶尔会了解数字货币,但它在你生活中的优先级比较低,那么数字货币相关的笔记应该归类为 Resource
  • Archive 指的是不再需要的笔记。通过我会把 Project 中完成的或者难产的项目拖动到 Archive.

理解 PARA 的关键是理解 PARA 的哲学:你记下的笔记应该要服务于你的行动

也就是说,在 PARA 的系统里,当你想要把东西记下来时,你的 mindset 应该是,这条笔记和我接下来的行动有什么关系?如果没有关系,那么它应该放在 Area 还是 Resource?

在 The PARA Method 一书中,开篇的一句话能解释这个哲学:


Every word in this book is designed to do one thing: propel you forward into taking action

这本书中的每一个词都是为了一个目的:推动你付诸行动。

Apple Notes 中的 PARA

简单了解了 PARA 后,看看我如何在 Apple Notes 中使用 PARA.

我在 Apple Notes 中会单独建立一个 PARA 目录:

PARA 目录

里面有基本的 Projects, Areas, Resources, Archived 文件夹。在这个基础上,我有两个改良,第一个是添加了一个 Drafts 文件夹,用于记录我日常的零碎想法:

这些想法一般是在手机上记录下来,在有空的时候进行深度思考和研究,有些会最终成为一篇推文,或者基于想法变成一篇博客文章。

第二个改良是增加了一个 Inbox 文件夹,用来存放打算做的项目,这些项目还没进行深入的思考,不确定是否立项来做。如果想清楚要做,我会把它拖动到 Projects 中。否则直接拖到 Archive 归档。

Projects 目录是我最常用的,因为里面都是当前正在进行的项目:

比如,当我决定要写一篇长文,就会在 Projects 中新建一个文件夹,比如现在这篇文章,就是在 Apple Notes 里写的。有了这个文件夹后,当我看到任何和这个项目相关的信息,就会把它记在这个文件夹当中:

也就是说,当我看到任何关于 Note taking 主题的值得记下来的东西时,我很清楚要把它放在哪里,因为它和我正在进行的项目有关系。

这也解决了一个很普遍的问题,很多人想记笔记,想有「第二大脑」,却不知道应该记什么,或者记下来很多,最后都只是放在自己的笔记软件里,发挥不出任何作用。而在 PARA 的系统中,你清楚地知道你应该记什么笔记,因为你知道哪些信息和你正在做的事情有关系。这些笔记才是真正能发挥作用的

比如我即将写一篇在我 30 岁时发布的博客文章,虽然还没开始写,但它是我的一个 Project, 那么当我读到和这个主题相关的信息,就会把它记在这个 Project 里,当我真正写这篇文章的时候,能直接参考它们,对于我来说,这才是有用的笔记:

Projects 不仅仅是项目,它还可以是即将到来的一个事件(Event),也可以是你正在研究的一个课题。比如你约了一个重要的人,你需要记下来这次约会需要准备点什么。约会结束后,就把它拖动到 Archive.

再举一个例子,比如你正在开发一个软件,可能需要记一些技术相关的笔记。在以往,可能你会把这些笔记按主题记下来,比如 React, Vue, Rust, 前端, 后端之类的分类。但在 PARA 中,你应该为你正在开发的软件创建一个 Project,无论你想记下来的技术笔记是什么分类,都放到这个 Project 当中。这样记下来的笔记才是真正有价值的,因为它真实地服务于你正在开发的项目,你在开发时可以反复在一个地方参考。

项目结束后,你可以将整个 Project 拖到 Archive, 不需要再管它。如果你认为 Project 中的一些笔记有复用的价值,就把它拖到 Areas 或 Resources 当中。Apple Notes 的拖动十分方便。但按照我的经验,一般来说直接 Archive 整个 Project 也没什么问题,因为它不是被删了,你还是能通过搜索重新找到它。这时 Archive 的笔记又会「流动」到 Project 当中。

我自己的 Areas 和 Resources 其实很少碰,基本只在 Projects 和 Archive 中活跃:

使用 PARA 的另一个好处在于,只要展开我的 Projects 目录,我能一目了然我正在做的事情。我不再需要单独的 Todo 工具,因为 Projects 就是我的 Todo, 而且 Apple Notes 也有 checklist 功能。这也是 The PARA Method 中所说的:

You will gain greater focus on what matters most: You will have greater clarity about what’s important so you can intentionally move your life into alignment with your interests and goals.

你将更加专注于最重要的事情:你会更清晰地了解什么是重要的,从而有意识地将你的生活与自身兴趣和目标协调一致。

常见问题

没有双链,如何找回笔记

善用搜索。虽然只是关键字查询,但按照我的经验来看,这就足够了。比如我在 Apple Notes 记过我常用的 API key, 我只要搜索 azure 这个词,我就能立刻找到,我甚至都不知道它被我放在哪里了:

怎么把旧的笔记迁移过来

不需要迁移。在新的工具重新开始,需要用到的时候才在旧的工具重新找回,有必要时再复制过来。反正没人要求你用新的工具就把旧的数据都删掉。而且,我相信你最后会发现,你并不怎么需要找回你的旧数据 😂 这两年我就没打开过我以前一直用的 Logseq, 也没有做任何迁移。

结论

以上的分享不一定适合所有人,但它非常适合我,我也从这套系统中得到了很大的解放。你甚至可以什么系统都不用,在同一个文件夹记下来所有东西,最后你会意识到,重要的不是把笔记放在哪里,而是感谢自己当初记了下来。这就是为什么降低记录的摩擦力是如此地重要。

PARA 是一个方法,你不一定要用 Apple Notes, 你可以在所有的工具用它。不要让工具阻碍了自己最重要的事 —— take action. 真正有用的笔记是帮助你 take action 的笔记。

P.S. 这篇文章在 Apple Notes 写成:

新 MacBook 的设置和软件

2025年2月8日 08:00

趁着国补,把手头用了 5 年的 MacBook Air M1 换成了 MacBook Pro 14 寸 M4. 顺便手动重新配置新电脑,在此记录一下每次设置新电脑时我会做的一些设置和必装的软件。

设置

把点按切换成轻点:

点按切换成轻点

我不喜欢用触摸板点按拖动来移动窗口,觉得有点费力,所以我会调整为三指拖移。旧版本的 OS X 可以直接在系统设置中调整,新版本的 macOS 竟然把它归类到辅助功能里了:

三指拖移

把 Control 键和 Caps Lock 键互换。因为我需要频繁使用 Control 键,Caps Lock 的位置是最合适的,这也是 HHKB 的默认布局:

Control 和 Caps Lock 互换

取消 Spotlight 的所有索引,因为我用 Raycast, Spotlight 的索引会浪费计算资源:

取消 Spotlight 的所有索引

软件

  • Microsoft Edge: 用了很多年的主力浏览器
  • 清歌五笔输入法: 最好用的五笔输入法
  • Raycast: 不必多说
  • Cursor: 目前主力 IDE, 也是 Cursor 长期的订阅用户
  • CleanShotX: 最好用的截图软件,除了截图还有很多好用的小功能(比如 OCR, 录屏)
  • 1Password: 密码管理
  • Warp: 主力 Terminal Emulator, 已经离不开通过 AI 写复杂的命令
  • iStat Menus: 在 Menu bar 显示系统信息,我用来实时看到网络传输速度和内存使用情况

「代码艺术家」不会被 AI 取代

2024年8月10日 08:00

最近大量地使用 Cursor 替代了 VS Code, 开始习惯直接在编辑器里告诉 AI 我的需求,让它来代替我写出代码段。

请注意,我用了「代码段」这个词,而不是「代码」,因为我想做一个区分 —— 按照我目前的经验来看,生成式 AI 非常擅长生成一段内聚的代码,而不是一整个应用程序。

在没有 AI 生成代码前,我写代码也是这样的一个流程:

  1. 思考整个应用的架构、模块
  2. 选择适合的技术栈
  3. 开始写代码,设计目录结构、抽象
  4. 真正开始实现实现

AI 也许能为第 1 和第 2 点提出建议,但我目前不需要。第 3 点我认为对于稍微复杂一点的生产级应用, AI 还做不到把这一块也做到。可能很多人看到现在 Claude 直接能写出一个全功能的 Todo List 就惊叹 AI 要取代程序员了,我觉得真正写过一个完整的给用户使用的「应用」的朋友对此都会很淡定。

对于我来说,只有在第 4 步(实现) 的阶段才真正能杠杆 AI 的能力。我会尽可能地描述清楚我的需求,让 AI 能理解我要做的任务,让它来生成满足我的抽象的代码,或修改现有的代码。

这里我提到的描述清楚我的需求是用 AI 生成代码中最重要的一点。所谓的「需求」不仅仅是描述这个函数需要做什么事情,还需要包含这个函数应该接收什么参数,返回的是什么数据结构。

例如,我在做的一个应用,其中我需要一个上传文件到 S3 的函数。在这个需求中,如果我单纯告诉 AI它要做什么,那我很有可能得到一个可以实现功能但不适合我调用的函数,因为 AI 没有上下文去确定我可以传哪些参数给它。

![cursor 截图]../../../images/telegram-cloud-photo-size-5-6168067452672523878-y.jpg

在深度和 AI 「结对编程」后,我对于「AI 是否能取代程序员」这个问题有了更深刻的思考。

有了 AI, 我现在写代码花的精力主要是在「设计」上,例如思考这个应用的交互设计,例如整个应用的架构设计。所谓的架构设计,一部分的工作是决定这个系统里要有什么模块,一部分的工作是决定这些模块如何串联在一起。而这些设计工作恰恰是我写代码的时候最喜欢做的,对我来说,写代码就应该是一个设计的过程,设计出优雅、易用、易扩展的接口是一件很有成就感的事。这也是我当初看 Head First Design Patter 这本书时的感受。
 如果写软件变成了一个只需要花精力在设计而不是实现上的过程,那么写软件的人就是「代码艺术家」了。我觉得「代码艺术家」是不会被 AI 取代的,因为设计的起点和终点都是人类,AI 可以给你 100 个设计上的答案,但只有人类最终能感知到现实和当下的环境和信息,创造出能触动另一群人类的产品。

如果你从现在开始,开始把 AI 当作是你的员工,就像某一天你突然只需要 $20 一个月就能招无数多愿意帮你打工的人,你很快就会发现,你最终会面临两种局面:

局面1:你将手足无措,你突然发现如果你不是实现函数的那个人,你就不知道你应该做什么了。从前你沾沾自喜的手写快排,手写红黑树突然变得一文不值,无处施展。

局面2:你将如虎添翼,你突然发现你曾经有很多想法没有精力和时间去实现,现在突然有这么多廉价劳动力将不厌其烦地帮你写代码,而你要做的只是设计好整个系统的结构,把具体实现外包给 AI. 然后把产品推出市场,去碰壁,去失败,去成功。显然,AI 不能替代你去碰壁,去失败,去成功,但真正让你变得强大的不是你手写快排有多烂熟于心,而是去碰壁之后学习到的东西

AI 不会替代「代码艺术家」,因为 AI 是「代码艺术家」的喷射机

读到这里,可能有人要说,Randy, 你飘了,你开始技术虚无主义了。在这里我要申明,这篇文章我是写给有一定经验的程序员看的。对于没有什么经验的程序员,多写点代码总是好的(至少目前来看)。AI 能力的上限是由用的人的上限决定的。无论是任何行业,充分掌握领域知识后配合 AI 才是最好的做法。

就像下面这个例子,我只要说一句 add tanstack query provider 就能让 AI 帮我把 @tanstack/query 加到我的程序里。我自己会写,但我自己写可能要花一两分钟,但 AI 一下子就好了。

![cursor 截图]../../../images/telegram-cloud-photo-size-5-6165685253356765301-y.jpg

但如果你没有任何代码经验,你连 tanstack query 是什么都不知道,也不知道要放在程序的哪个地方,那用 AI 还是有点困难。

写下这篇文章是因为最近用 Cursor 有感,加上刚好看到 Daniel Nguyen 发了一篇 Software is Art, 有感而发,不吐不快。在此粗浅翻译(非 GPT),作为结尾:

I realize the reason I like building is not just because I’m a builder.

我意识到我一直喜欢创造点东西的原因不只是因为我就是个创造者.

It’s because software products are how I express my creativity.

而是因为写软件产品是我表达我的创意的一种方式

It’s like a poem to a poet, a song to a songwriter, a painting to a painter…

就像诗人的诗,歌手的歌,画家的画

Software is my art form, my medium of expression.

软件是属于我的一种艺术形式,是我表达(创造力)的媒介。

不上班的第一年

2024年5月14日 08:00

2023 年的 5 月,我离开了微软,开始了自己做产品的旅程。到现在刚好满了一年,这一年发生了不少事情,有些在 2023 年终总结里提到过,这一篇我想更详细地列出在这一年我具体做了什么、对自由职业的思考、对做产品的一些思考等等。

首先是我的产出,这一年我的产出主要是两个产品、一个播客。

两个产品

Notepal

离职后第一个认真做的产品是 Notepal, 这是一个用于把微信读书笔记同步到各个笔记应用的插件。我在这篇文章详细写过这个产品的起源和在做这个产品的时候的一些思考。我在做这个产品的时候完全没有想到,这个只卖 50 块的插件,在这一年帮我付了我一整年的房租。

EpubKit

epubkit

EpubKit 是另外一个我投入比较多的产品。这是一个把网页转成 ePub 电子书的工具。正式上线不到一个月,收获了几十个付费用户。

一个播客

刚好今年的 5 月份也是我和 GeekPlux 一起做的播客节目《代码之外》 的一周年。起初我们只是玩票性地做闲聊节目,后来因为有了听众来信的栏目,我们慢慢会讲更多职业发展方向的主题,这些主题意外地无形中对很多听众有不少的帮助。后来还邀请我刚工作就很欣赏的前辈勾股作为来信栏目的常驻嘉宾,为节目带来了很多很好的观点。今年在参加一些线下活动时,有些听众会跟我说从节目中得到了启发。从统计数字上看,我们好像的确是做了一件影响力不算小的事:

  • 小宇宙订阅数 6000+, 总播放量 11万+
  • Bilibili 粉丝 6000+,总播放量 13万+
  • YouTube 订阅数 2500+, 总播放量 3万+

在这一年,我对于做产品和生活都有了很多思考。对于不上班这件事,有人羡慕,有人好奇,刚好在这篇总结里,我想跟大家分享不上班的好处和缺点。

不上班的好处

时间自由

不上班的好处对我来说最明显的是时间自由。我是一个喜欢晚睡晚起的人,所以对我来说,准时上班是一件很难的事。不上班可以让我睡到自然醒,有充足的睡眠时间。

认识不同的人

上班的时候基本只能认识职场环境里面的同事朋友,或者在网络上交流的朋友。但是在自己做产品后,我开始认识一些同样是在做产品的朋友,和这些朋友可以聊得更深入。这些人往往对很多事情都有自己独特的思考。我从他们身上学习到非常多。我经常觉得如果我只是和以前一样在公司上班,业余写写博客和开源,我可能很难和这些朋友有共同话题,最多也只是互相点赞之交。

赤裸地直面市场

不上班后只能完全依靠自己赚钱,这代表我需要很赤裸地直面市场。

第一层赤裸,指的是脱离公司,作为一个个体,我可以给消费者提供什么他们认为值得为我付费的价值?

第二层赤裸,指的是一个产品如果脱离大公司本来就有的入口红利,我靠什么给我的产品带来自然流量?

这些都是很难的问题,但一旦开始学习,收获都是巨大的,而且都是属于自己的。在公司里最可怕的地方在于,我们很容易把公司给的平台误以为是自己的能力,很容易把流量看成是理所当然会有的。

也正因为如此,在这个过程中,我可以学习到很多以前不会主动学习的技能。

学习到更多技能

自己做产品的时候,没有公司平台给的入口,首先需要学习的就是如何做 marketing. 也是只有在自己做产品的时候,才会发现要别人发现你的产品是一件多么难的事。回想以前在阿里做业务,我们写一个营销活动页面,只要把入口放到某个栏位,基本不需要担心没有流量。

为了获客,我学会了研究 SEO, 学会了怎么做小红书,读了很多关于 marketing 的书。这让我学习了很多技术之外的知识,我觉得这些知识是终生受用的,而且它们不仅可以在互联网行业受用。

不上班的缺点

没有固定收入

不上班最大的缺点就是没有固定收入,这是很现实的问题。坦率地说,我以前买东西基本不看价格,只要觉得有价值,我就会买。没有固定收入之后,我买东西变得更加谨慎了。比如最近我很想买一台 Studio Display, 换作以前,无需多想,直接下单。但是现在,我会想我要卖多少份软件才能 cover 这台显示器,想想还是算了。

有时候我的朋友说羡慕我不用上班,我就跟他们说我这一年的收入还没有你们一个月赚得多,他们心理也就平衡了🤣。

孤独

可能有些人就是喜欢不用和别人交流,但对我来说,我是喜欢社交的,我在适当的社交中可以获取能量。不上班的时候,大部份的时间都是在家里写代码,看书,在网上和朋友聊天。有时候一整天都不需要开口说一句话。到后来我有点受不了,开始到外面的咖啡厅办公,只要能见到旁边有活人,就能有所缓解这种孤独感。

不确定性

上班有上班的不确定性要面对,不上班也有不上班的不确定性要面对。你无法确定这种生活可以维持多久,你的产品是否能卖得出去,就算卖得出去,它是否能养活自己,这些都是要面对的问题。

这些就是我体会到的不上班的一些优缺点,接下来,我想讲讲这一年在做产品的过程中我的一些思考和感受。

思考和感受

独立开发?

「独立开发」这个词在这一年非常火,用来标签像我这样自己做产品的开发者。其实我一直不称自己为「独立开发者」,因为我根本不想「独立」开发。我想做 scope 更大的事情,只是现在还没有条件。如果可以,我更愿意和两三个志同道合的人一起做产品。就像 61 的谜底科技,像少楠的 flomo.

而且自己做产品这一年,让我深刻地意识到,真正要做「独立」开发是很难的,因为没有人能擅长所有技能

没有人擅长所有技能

曾经我觉得只要我愿意去学,我就能做好。比如设计。我很注重产品的 UI/UX 设计,但我一直没有经过认真的设计学习和训练。我读了些关于 UI/UX 的书,以为就可以成为一个设计还不错的程序员。后来发现我错了,理论和实践之间原来有一条很大的鸿沟我虽然知道很多设计和用户体验的理论,但是一旦真正动手做页面,这些理论完全无法转换成实际的设计。

这是因为设计和写代码一样,是需要长期积累的。优秀的设计师可能有审美天赋,但他们一定也是每天都观察大量的设计,在自己的脑中内化了很多设计的模式(我不知道有没有专业的术语来形容),这些积累使他们可以面对一个新的需求的时候,根据自己内化的东西产生新的设计,这是我这种只读过一些理论的人无法做到的。正如会写代码的设计师,可能可以写一点能跑的代码,但缺乏多年的代码实践经验,是不可能像真正的专业程序员一样根据经验做好技术选型和想应该用什么设计模式(design pattern)的。

不过,我还是学会了在看到一些设计的时候,比以往更深入地去思考这个设计,这些元素为什么会这么摆放,颜色是怎么运用的,等等。

人的时间和精力是有限的

Notepal 和 EpubKit 同时做,让我更能体会到人的时间和精力是有限的。把时间放在一个产品 4 小时,那么另外一个产品投入的时间就永远少了 4 小时。而且上下文切换(context switch)是非常耗精力的。比如你正在修产品 A 的 bug, 这时用户报了产品 B 的 bug, 要从产品 A 跳转到产品 B 的开发,是很难一下子切换过来的。

所以不是自己一个人做产品就不需要项目管理,还是得学会充当自己的 manager 管理自己。给项目列好 roadmap, 排好需求优先级。

关于这个问题我还专门请教了图拉鼎,他告诉我要把自己当成不同的角色来用,比如规定上午作为客服,专门处理用户反馈,下午是程序员,专注写代码。这个方法也让我很受用。

自己做产品,同时要充当开发、marketing、客服、产品设计,我觉得这是「独立」开发的最大挑战。

学会专注

开发完 Notepal 后,我曾经陷入了很长时间的 burnout. 眼下赚的钱也不多,但又不知道应该做什么。期间有一些零星的 idea, 开发完后也不了了之。后来开发了第一版 EpubKit, 有了一些用户,之后又 burnout 了,因为开始觉得它做得不好,也很小众,渐渐又想放弃,想做点别的试试。

后来一些朋友「批评」我说我不够专注,我也开始反思,其实自己做的东西不算很糟糕,只是自己太着急,没有把它们都做得极致就失去耐性。经过反思,我决定好好打磨自己现有的产品,才有了现在这一版自己比较满意的 EpubKit.

乔布斯说专注不是指只做最好的,而是对其它也很好的东西 say no.

另外,缺乏专注很有可能会消耗用户对你的信任。

警惕「快速试错」

「快速试错」、「快速验证想法」是很多人做产品的信条,我相信快速验证想法是重要的,但是更重要的是交给用户的这个产品不应该是一个半成品,它最好是一个 Finished software. 也就是说,即使你不再维护这个产品,它还依旧是个可用的软件。

我曾经也「快速试错」,发布了一些产品,最终不再维护,甚至还有几个用户付费了。我对这种「试错」是愧疚的,因为这很有可能伤害支持你的用户。因此我现在反而发布新产品会更加谨慎,要把用户的感受放在第一位。

这篇文章很好地表达了这个观点。

总结

以上就是不上班的一年我对自己的一些思考的总结,希望对读到的朋友有帮助。这一年我其实算是比较幸运的,虽然收入微薄,但做产品也算是能卖出去,能解决很多人的需求。但同时我还是处于迷茫的阶段,认为自己做的产品还是小打小闹,scope 太小。我还是希望将来能做出满足更大众需求的产品,覆盖面能更广。

我的这些观点不一定对,但也能让读者感受到一个程序员脱离公司的其中一种可能性。

在 Electron 中使用 SQLite 的最好方式

2024年4月22日 08:00

上周刚刚发布了一个用 Electron 的应用 EpubKit. EpubKit 是一个把网页制作成电子书的工具。在 EpubKit 里,我需要一个数据库来存储内容,最好的选择是 SQLite.

但是,由于 Electron 有 renderer 和 main 区分开的机制,所以在 Electron 中使用 SQLite 会非常麻烦 —— SQLite 的执行要在 Main process, 但调用要在 Renderer process. 在 Electron 里,Renderer 和 Main process 之间的通信是通过 IPC (Inter-Process Communication) 实现的。也就是说,我可能需要把每一个有关数据库操作的业务逻辑单独写成一个 IPC 通信的事件,然后在 Renderer 里调用这些事件。

我想要做到的是,我在 Renderer process 中直接调用 ORM, 但实际的执行是在 Main process 中。这样一来我就不需要单独地写很多个 IPC 事件了。

例如:

万幸的是 drizzle 居然有一个 HTTP Proxy 的机制。这个机制能让你所有的 ORM 操作都流到一个地方,在这个地方你能拿到最终生成的 sql 语句,然后你可以自己决定怎么执行这个 sql 语句。

也就是说,我可以在这个 proxy 里,把 sql 语句通过 IPC 发送到 Main process, 然后在 Main process 里执行这个 sql 语句。

接下来我会简单描述一下我在 EpubKit 里是怎么做的。

编写 Schema

在你的项目里找一个地方,把 drizzle schema 写下来:

import { int, sqliteTable, text } from "drizzle-orm/sqlite-core";

export const posts = sqliteTable('posts', {
  id: int("id").primaryKey().default(0),
  title: text("title").notNull().default(""),
})

在 Renderer 里创建一个 drizzle database 实例

根据 文档, 在创建 drizzle db 实例的时候,可以传入一个函数,这就是 proxy 的本体。我们要做的是在这个 proxy 里,拿到 ORM 最终生成的 sql 语句、执行方法、变量,然后通过 IPC 发送到 Main process.

export const database = drizzle(async (...args) => {
  try {
    // 通过 IPC 把 SQL 发送到 Main process
    const result = await window.api.execute(...args)
    return {rows: result}
  } catch (e: any) {
    console.error('Error from sqlite proxy server: ', e.response.data)
    return { rows: [] }
  }
}, {
  schema: schema
})

这里有一个 window.api.execute(), 是怎么来的呢?其实是在 preload 进程里面定义然后暴露的, 它的作用就是通过 IPC 发送 sql 语句到 Main process:

// preload.ts

const api = {
  execute: (...args) => ipcRenderer.invoke('db:execute', ...args),
}

也就是说,实际上我们以上做的事情就是,通过 proxy, 把 SQL 语句通过 Main process 里的 db:execute handler 最终执行。

Main process

在 Main process, 我们创建一个 IPC handler:

// main.ts
ipcMain.handle('db:execute', execute)

这里的 execute 就是 Main process 里最终执行 SQL 语句的函数。

import { drizzle } from 'drizzle-orm/better-sqlite3'
import Database from 'better-sqlite3'
import { migrate } from 'drizzle-orm/better-sqlite3/migrator'
import * as schema from '../renderer/src/db/schema'
import fs from 'fs'
import { app } from 'electron'
import path from 'path'

// 初始化 sqlite
const dbPath = '../databse.db'

fs.mkdirSync(path.dirname(dbPath), { recursive: true })

const sqlite = new Database(
  dbPath
)

// 创建 drizzle 实例
export const db = drizzle(sqlite, { schema })

// 这里是 execute 方法
export const execute = async (e, sqlstr, params, method) => {
  // 得到执行需要的参数后,用 better-sqlite3 执行
  const result = sqlite.prepare(sqlstr)
  const ret = result[method](...params)
  return toDrizzleResult(ret)
}

function toDrizzleResult(row: Record<string, any>)
function toDrizzleResult(rows: Record<string, any> | Array<Record<string, any>>) {
   if (!rows) {
    return []
  }
  if (Array.isArray(rows)) {
    return rows.map((row) => {
      return Object.keys(row).map((key) => row[key])
    })
  } else {
    return Object.keys(rows).map((key) => rows[key])
  }
}

在上面的代码中,我额外实现了一个 toDrizzleResult 的方法,是为了把 better-sqlite3 的返回值按照 drizzle 需要的结构返回。

到这里,你就已经可以在 Renderer process 里直接用 drizzle 了:

function App(): JSX.Element {

  const [postList, setPosts] = useState([] as any[])

  useEffect(() => {
    database.query.posts.findMany().then(result => {
      setPosts(result)
    })
  }, [])

  return (
    <div>
      <div>
        <form onSubmit={async e => {
          e.preventDefault()

          const formData = new FormData(e.target as HTMLFormElement)
          const title = formData.get('title') as string
          if (title) {
            await database.insert(posts).values({
              id: Math.floor(Math.random() * 1000),
              title
            })

            // refetch
            const result = await database.query.posts.findMany()
            setPosts(result)
          }
        }}>
          <input name="title" type="text" placeholder="title" />
          <button>add</button>
        </form>
      </div>
      {postList.map(post => {
        return (
          <div key={post.id}>
            {post.title}
          </div>
        )
      })}
    </div>
  )
}

export default App

但这时候执行,会报错。原因是我们还没有初始化数据库。我们需要在 Main process 里初始化数据库。

首先需要用 drizzle-kit 生成 migration 文件。在 drizzle.config.ts 中指定了 migration 文件的地址:

// drizzle.config.ts
import type { Config } from 'drizzle-kit'

export default {
  schema: './src/db/schema.ts',
  out: './drizzle',
  driver: 'better-sqlite'
} satisfies Config

然后写一个 runMigrations 方法,用来初始化数据库:

export const runMigrate = async () => {
  migrate(db, {
    // 在 drizzle.config.ts 里指定的路径
    migrationsFolder: path.join(__dirname, '../../drizzle')
  })
}

这个方法需要在 Main process 启动时执行的:

async function createWindow() {
  // ...

  await runMigrate()
  createWindow()

  //...
}

实例源码

你可以在 这里 找到这个示例的完整源码。

特别感谢 EGOIST 提供灵感。

2023 年终总结: 和自己对话

2023年12月22日 08:00

可在小宇宙收听本文音频版

变化

2023 年初,持续了 3 年的疫情封控结束了,整个社会迎来了一个转变的开端,没人知道会变好还是变更糟糕。随后 3 月,我决定离开微软,我自己也迎来了一个转变的开端,我也不知道会变好还是更糟糕。

我财务自由了吗?如果财务自由有一个绝对值,那么无论是多少,我肯定都没有达到。离职后有很多朋友问过我这个问题,现在刚好可以在博客也跟我的博客读者分享:当我在考虑不工作时,我在思考什么?

1. 如果继续现在的状态,那么 3-5 年内我会有什么不同?

这是我在考虑是否入职微软之前用的同一个方法,是我朋友教我的。当年我觉得如果不入职微软见识见识,我一定会后悔,留在原来的公司也不会有太大的变化。今天即使我已经离职了,但我很感谢我有选择微软,我的收获非常多。所以我运用同一种决策方式来思考,即使我在微软继续工作 10 年,很大可能我得到的只是 title 和薪水的不同,这和我的目标背道而驰。这也引出了我的第二层思考:

2. 我正在做的事和我的长远目标是否对齐?

过去我会担忧和焦虑我达不到目标,后来我醒悟:没有人可以控制结果,只要我正在做的事是朝向我的长远目标就可以了。继续工作显然不是。

3. 没有固定收入怎么生活?

我有一点积蓄,虽然不多。很多人存了钱,买了房子。而我用我的积蓄买一段可以不工作的时间,我觉得还是很值得的。而且我不工作也不是天天躺着什么都不做,只要朝着我的目标在努力,这也算是一笔投资。

幸福之道

离开公司后,我的心情很复杂。我觉得我一直想寻找一个答案,但实际上我连问题是什么都不知道。我想起了年轻时读的《刀锋》,应该像书中的拉里一样去寻找,于是 7 月份我去了泰国,得到了一段出乎意料的佛教哲学之旅

创造

今年的输出比我预期的要更丰富一些。

视频创作

继 2022 年的 Logseq 分享视频,今年又做出了一个超 50,000 播放量的视频《我如何做笔记》

《代码之外 Beyond Code》播客

今年终于和 GeekPlux 一起把盘算了多年的项目真正做了出来,意外地得到了很不错的反响。甚至能在线下聚会的时候听到一些我们的听众表达的感谢。

其实节目的制作形式受到了很多我喜欢的不同的播客节目,我由此也更深刻地感觉到,一个人能做出什么样的东西,很大程度上取决于其接触、输入的东西。只有吸收优秀的东西,才有机会做出优秀的东西。

这跟做产品也很像,如果一个人从来没有体验过真正优秀的产品,那就很难做出优秀的产品。所以我总是鼓励一些朋友,不要因为一个产品要花钱所以不去用它,就算只买一个月,也要去体验一下。

Randynamic Studio

离职后我就计划把我之后做的所有小工具统一到 Randynamic Studio 的名下. 很幸运,它的真正意义上的第一个产品 Notepal 算是非常成功。它没有为我赚巨额的钱,但它解决了很多人的需求,并且这些人愿意为它付费,这是我写在博客首页很多年的一个目标,在今年终于实现了。

多年来我把 Y Combinator 的 slogan 一直放在心中,有很长一段时间我每天睡醒后心里就会自动播放这句话:

Make something people want.

很幸运我朝着这一个目标又迈进了一步。

线下聚会

解除封控后,终于可以参加一些技术圈子的线下聚会了,也有机会见到一些相识多年但从未谋面的网友。

先是参加了佐玩开发者交流会,见到了很多很年轻的后辈,更惊喜的是很多是《代码之外》的听众,他们都说在节目中收获到了很多。在那一瞬间我觉得我做的很多事情都是有意义的。

然后我到杭州找了图拉鼎,见识了数字游民的聚合地「玉鸟集」。在那里还认识了非常多的独立开发者和做产品的人,大家都很有自己的想法,对自己做的事情有自己的理解,有自己的观点,自己的品味。这种类型的朋友是很难在工作的时候遇到的。

总结

2023 是我和自已对话的一年,我开始了解自己想要的是什么,了解自己的情绪,了解自己擅长的是什么,不擅长的是什么,了解自己追求的是什么,等等。在清迈,我学会了倾听内心的声音,我也意识到,在真正了解自己的情况下,做决定似乎没有那么难了。

展望

我其实很希望在 2024 年能做一些 scope 更大的事情,同时也需要找到和我有相同 passion 的人。我一直不称自己为「独立开发者」,一是我觉得我还没达到,二是这也不是我的目标。我的目标一直是两三个有同样追求的人组成一个小 team 做一个美且在商业上可行的产品。

希望自己能往目标再迈进一大步。

开发一个浏览器插件在第三天卖出 1000 元

2023年7月30日 08:00

写下这篇文章是我的插件 Notepal 发布的第三天,目前收获了几十名付费用户,在这短短几天已经有 5000 多条微信读书笔记被同步到 Readwise, flomo 或 Obsidian 中。

(28 号没有数据是因为那天出了事故,日志没有进来。)

很感谢点进这篇文章的你没有因为 1000 元是个小数目所以选择无视,这个数目确实很小,它甚至没有很多程序员坐在办公室待一天赚得多,但「有人愿意购买」的意义远比数目的大小对目前的我来说意义更大,而且我在开发和上线整个过程中学习到了不少,也实践了不少我读的一些关于 start a business 的书,我发现在亲身经历了这个过程后,再重读这些书,体会更加深刻,所以我很想在这篇文章和大家分享我学到的,以及我所采用的一些方法论。

最初的需求

我在差不多半年前因为想把微信读书的笔记同步到笔记软件 Readwise, 所以写了一个很简单的网站(Notepal 的前身),可以把微信读书 App 里复制出来的笔记,解析成自定义的格式,也可以解析成 Readwise 能实别的 csv 格式。

虽然这种方式还是有点繁琐,而且 csv 格式其实很不稳定,很容易被笔记里的一些字符导致导入失败,但在此之前我想基本没有人可以这么「自动化」地做到这件事了。

我把它发布到了 V2EX, 写了点介绍,并且代码是开源的。

但是,在当时,我隐约觉得这个需求会有人愿意买单,因为我相信绝对不止我一个微信读书和 Readwise 的共同用户有这个需求。但我当时刚好在读 Sahil Lavingia 的 The minimalist entrepreneur 这本书(在接下来的内容我会多次提起这本书),里面有一个让我感触很大的观点—— start with community, 创业从社区开始。

什么意思呢,如果你觉得你能解决一个很多人都有的需求,首先要做的不是急着做软件做产品,而是先找到这群人,在这个群体里帮助他们。

所以当我隐约认为我能解决一部分人的需求且他们有可能为此付费时,我做了一件和开发完全没有关系的事——建用户群,然后放到网站上,我希望把有这个需求的人先聚集起来,等有一天我把这个工具做得比较稳定的时候,有一个卖出去的机会。

后来加进群的一共 50 多个人,这些人其实也没怎么说过话,有些人提了一些使用问题,然后群就基本死了。

大部份的人反馈的问题都是 csv 出问题,这个问题很难解决,我觉得如果要稳定,必须通过调用微信读书的接口,拿到 json 格式的笔记,然后通过 API 同步到 readwise. 所以我一直想把这个需求用浏览器插件来解决,我在群里也提了一句「我准备写一个浏览器插件」,但是也没人理。

于是我就把开发插件的事情搁置了。

转折,冷启动

从这个工具发布一直过了半年,突然有位推友发了一条推,对我这个工具表达了感谢:

这不足以让我惊讶,最让我惊讶的是这条推的数据:113 转推6 引用373 喜欢次数237 书签。

这让我有了动力去把我曾经想实现的插件写出来,我决定先快速做一个 MVP, 只要实现在微信读书页面展示有笔记的书,并且用 Readwsie 的 API 一键同步笔记,最后展示同步到 Readwise 后的笔记。

为什么要这么做?因为我需要做一个「半冷启动」,我知道把插件打磨到可以上线并收费的工作量不算小,但我需要做一个流畅的视频,来展现这个 idea, 并且是一个真实的实现。把这颗小石头抛出来,看能引起多大的水花。

把视频发出来后,引起了不少的回复:

这时我决定要做出来一个真正值得被这些人购买的产品,解决他们的需求,让他们心甘情愿地因为产品解决的问题和体验而买单。

从冷启动到正式上线

在写正式的产品前,我问自己一个问题,做到什么程度可以发布第一个版本。我心中的答案是这样的:

  1. 为了尽快上线,只做同步到 Readwise 的功能
  2. 上线 day one 就要开始收费,可以提供免费试用,但一定要有收费入口
  3. 体验一定要最直接——填 API token -> 选书 -> 同步 -> 查看同步到 Readwise 的笔记,一气呵成
  4. 要记录一些非隐私日志,例如同步笔记的量,错误日志

尽快发布

第一点,很多人肯定会觉得,Readwise 这么小众,同时用微信读书和 Readwise 的更小众,会不会太少人用了。这是正确的判断,但是我认为我的当务之急是把产品 ship 出来,解决我能真实看到的那不到 10 个人的需求,看能不能从如此利基(niche)的圈子赚到钱,再谈扩张用户量(而且我很快在后面的版本支持了 flomo 和 obsidian)。

Day One 就要收费

第二点,有人会说,这么小众的需求,真的能赚到钱吗?我认为,可以,但看你是想赚大钱还是小钱,小众需求难赚大钱,但越小众的人越愿意付费。我已经对这个产品有了预期——我不认为这是能赚大钱的产品,我对这个产品的目标是:解决小部分人的需求,让他们为产品提供的价值付费。

为什么要赚钱?其实我大可以免费发布,我也完全不能靠这个产品吃饭。但和多年前的我不一样,我现在觉得「用户掏钱买你的产品」是验证你的产品价值最有用的方法,无论是便宜还是贵,即使是 1 块钱,就和免费完全有不同的意义。就像打德州扑克,用你真实的钱打和用游戏币打完全是两回事

既然要收费,就有两个问题:一是收多少,二是怎么收。

收多少的问题,首先有两个选择,一次性买断和订阅制。不过像这样的产品,我觉得理智的人都不会觉得适合订阅制。谁会为了一个低频需求订阅一个插件?

如果是买断,多少钱合适呢?我没有做什么调研,就拍脑袋觉得 30 块是个不高也不低的价格,而且是一次性收费。如果用户觉得好用,还是比较大概率选择购买的。

最难的问题其实是怎么收,尤其是这个产品面向的是国内的用户。众所周知,国内的付费渠道接入门槛是相当高的。可能做这个插件也就几天的事,但接入收费渠道就要几周。这是不能接受的。就像 Paul Garahm 说的:Do things that don't scale.

为此我想了很久,于是想出了一个办法。这也是在 The minimalist entrepreneur 这本书受到 Sahil Lavingia 的启发,他说 Gumroad 第一个版本是他自己每个月手动给 creator 发钱的。

我大受震撼,我想到,我这个产品,能不能卖得出还是个问题,即使能卖,也不可能卖很多,很频繁地交易,我何不像路边滩一样挂个收款码解决呢,只是我把收款码放到一个「购买页面」而已。

于是有了这个购买页面

但是,即使我能通过收款码收钱,那如何和我的插件联动,在用户付钱后解锁功能呢。我想到最传统的软件售卖方式——卖激活码,用户通过付款码值钱备注邮箱,当我收到款后,往他邮箱发送激活码,就完成了。

流程有了,但激活码怎么来?没有办法,这个还是要自己写点代码。我花了半个小时,用 Next.js + PostgreSQL 写了一个最简单的激活码生成和验证的 API service.

激活码机制也有了,但手动发激活码还是麻烦。所以我用写了一个「快捷指令」,只要填邮箱发到我的激活码 API service, 就会自动完成从创建激活码到发送邮件一整个步骤。虽然还是手动,但我的工作就变成了收到钱,运行「快捷指令」填邮箱。

读到这里,读者应该可以深刻地体会到,Paul Garahm 所说的 Do things that don't scale 是什么意思了。我觉得在做产品的时候,一定要瞄准最重要的事情——你给客户提供的价值是什么,而不要在其它地方花太多的精力,在这些地方甚至可以先手动做一些事情,在成功了之后再把他自动化,而不是一开始就自动化。

读者应该看过一个 meme 图,一个 ATM 机,其实背后是一个人手工把钱塞出来。这个图有点搞笑,但这是一个完美的 Do things don't scale 的例子,客户需要的是拿钱,用户并不关心你背后是多简单或多复杂的流程。新产品上线,最重要的是解决客户的问题,而不是怎么解决得比较优雅。很多工程师很容易陷入一种「自动化」的诱惑,想把一切都做得最自动化,然后忽略了真正在解决的是什么问题。

自动化可以做也必须做,但不是从 day one 就开始做。

用户体验

对于体验,我在上文从冷启动的视频到上线版本都强调了「查看同步到 Readwise」的笔记,很多人可能觉得这是一个可做可不做的功能,而且这是一个从技术上来说非常简单的功能。但我觉得这是整个产品最重要的 aha moment, 我要让用户能看到笔记一键就被放到了笔记软件里面的样子,而不是只是提示同步成功,让他自己去笔记软件查。这个体验,做和不做在技术上没多大区别,但对于体验来说是有天壤之别的。

记录日志

记录日志也相当重要,尤其是错误日志,在上线以后,有一些我自己的场景没有 cover 到的 case, 都通过用户反馈然后我看错误日志成功解决了。另外,行为日志也蛮重要,可以看到自己的产品有没有被使用,使用的量有多大,从而帮助自己做一些产品决策,也是一种对自己的激励。

上线,卖出去

如果是以前的我,我一定会有一种迷思,认为产品发布上线后,就等着她被传播,如果运气好,被大 v 传播,就有流量,就能变现,如果运气不好,可能就是没人有这个需求,这个产品就失败了。

但读完 The minimalist entrepreneur (我又提到这本书了),我对销售有了很不一样的理解。书里提到,大部分的产品,头 100 个付费用户是一个一个谈来的,只有用户足够多以后,才会出现口口相传的情况。而且广告是没用的(如果不是一个以流量为核心的产品)。

Eventually strangers will buy your product, but mostly because your customers are spreading the gospel of your business and product, not because they saw an ad. But it will take time to get there. It’s not something you hit on day one.

所以我这次上线没有被动地等待,而是主动出击,在互联网上搜索关键词,找到和我有一样需求的人,评论和私信他们,告诉他们我也有一样的需求,并且做了一个十分方便的插件,请他们试一试。

刚开始这样做的时候,我还是有点羞耻,觉得自己是在互联网上发布垃圾广告,但客观来说,我是作为有同样需求的人,分享我自己做出来的可以解决他们需求的工具,好像也不算垃圾广告。而且让我惊喜的是,很多人回复都很友善,并且感谢或最终购买了我做的产品。

这也让我想到,做产品,首先要想的不是怎么做,而是卖给谁。这是最重要的问题。如果连自己都不知道目标用户,又谈何 marketing 呢?

总结

一口气写了很多,从发布上线到现在其实也才三天,其中有一天还发生了一些事故,但还是给我自己上了很重要的一课,相信我分享出来的这些也能给大家一些启发。

虽然赚的不是什么大钱,但这对我来说是非常有意义的一次体验。就像我在博客的首页写的,小时候我的理想是改变世界,现在长大了,发现能做出用户愿意付费的有为用户提供价值的产品已经很不容易了。这是我第一个发布的付费产品,而且还收获了愿意付费的一些用户。我读了很多关于创业、产品、用户体验、营销的书,等这一刻已经等了很久了。

第一次听到到账 30 元的通知的那种激动,我想会是一辈子都不会忘记的。在厂里拿 30k, 代表我面试表现还不错,也能写出公司愿意付钱的代码,但卖产品拿 30 块,代表我洞悉了需求、直面了市场(这是说出来简单,但做的时候很难的事)、为付费用户解决了问题。

非常感谢这些用户,这对我来说是很大的激励。谨以此文作为我对大家的回报。

复读和命运

2023年6月10日 08:00

冯大辉 Fenng 发了一条 Tweet

对于各位高考过来人,如果成绩只能上二本,要不要复读?

以下是我的想法。

我当时考到的是二本,除了学费贵一点之外,我觉得都挺好的。我个人的浅见是,命运是没有人能预测的,复读和不复读是两个不同的分支。当然这说了等于没说。所以我来试试纸上谈兵一下:

我们假设复读一定能考上一本,那么我们可以把问题简单化为一个博弈:是否用人生的一年时间去换这个一本学历?

我有一个高中同学选择了复读,最后考到了比不复读更好的学校,但是在我对他的理解和我的个人认知里,他复读和不复读,并不会有很大的区别。

在我有限的经验观察里,人和人的距离,一本和二本的差距只占了非常非常小的部分,最重要的是人本身,他是否能客观地认知自己,自己的目标在哪里,想要的生活是什么,追求的东西是哪些。再以此为前提,是否能为了目标去努力地寻找资源,运用自己的主观能动性,去趋向自己的目标。然后在运气来临的时候抓住它。

就像有些人对我的评价,我「只不过是每次赶上了末班车」。我觉得这个评价很正确。我原本是 2018 年的大学毕业生,但我 2015 年就退学了。没有人知道我退学之后是好还是坏,我也不知道,但我们马后炮地回看,当时的时间点退学,让我赶上了互联网发展的「末班车」,如果我等到毕业,在这鼓浪潮开始退去的时候,我这个二本学生,不一定能混到我现在的状态,这辆「末班车」早就跑了。

我的例子不值得效仿,能不能坐上「末班车」,除了时机,还有我早就付出过的那些别人不一定看得到的努力。但我想表达的是,在做选择的时候,不能轻视了「时间」这个非常重要的因素。早一年和晚一年,会认识不同的人(这决定了人脉),会影响你身处在浪潮哪个位置,等等等等。

这个世界就是一连串随机事件的结果,它没有好坏之分,好坏都是靠自己的努力去定义的。如果这位朋友对自己的目标并不明确,那么早一年晚一年,好像也不会有什么本质上的区别,只要自己复读的一年里心理状态可以保持得很好,那复读也不是一个坏选择。

只有在「有目标 + 肯努力」的状态下,才能把人生这张彩票玩成一场能拿一手烂牌打赢的德州扑克。

我的笔记管理法

2023年5月13日 08:00

本文视频版:

作为一个程序员,我每天都会消化大量的信息。我以前总是会担心我花了这么多时间读各种各样感兴趣的内容但最后都派不上用场,或者不知道怎么找到想要的东西。所以我喜欢学习一些关于知识管理的方法论,然后结合自己的情况慢慢摸索出一套比较适合自己的笔记方法。在这个影片我就要给大家分享一下我从浏览信息到记录笔记再到输出的整个过程是怎么样的,我是怎么在我的笔记工具里整理我的笔记的。

其实与其说是在「记笔记」,我觉得更贴切的说法是我们在构建我们自己的「第二大脑」。我们本身的大脑的长处不是记东西,而是思考和创造。所以我们需要借助计算机创造一个我们的「第二大脑」,把我们见过的有价值的东西一直记住,等我们需要的时候再从里面找出来用。

当新的一天开始,信息就会不断地进入我们的大脑。如果我们想把我们接收的信息和知识好好地进行管理,我们必须先想清楚我们的信息来源到底有哪些。

信息输入

以我为例,信息来源主要来自:

  • 脑子里突然出现的想法、灵感。
  • 我关注的社交媒体的信息流。
  • 读书、听播客。

想法、灵感

对于脑子里突然出现的想法和灵感,如果我在用电脑,我会写在 Logseq 的 Journal 里;如果我在外面,我会立刻用手机写下来。我自己用的是 Drafts 这个 App, 因为我觉得它的 tag 比 Apple Notes 的要好用。但是你可以用任何自己喜欢的 App, 可以是自带的 Apple Notes, 可以是 flomo 等等。无论是什么 App, 最重要的是找一个你能点开就开始写的 App.

至于记下来之后要怎么处理它,在后面我会在讲组织笔记的方法时详细说明。现阶段你要知道的就是,你必须找一个点开就能写的工具帮助你抓住那一刹那的灵感。

关注的信息流

我每天起床洗漱完开始打开电脑后,都会开始进入我的「快速浏览」模式,这个过程的主要目的是从我固定的一些信息获取渠道快速地了解有什么事情正在发生。

比如我每天会固定浏览这几个信息来源:

  • Twitter
  • HackerNews
  • YouTube

我在 Twitter 上主要是关注了很多国内外的程序员、设计师、产品经理、独立开发者,还有像 Paul Graham, Naval 这样的神级人物。我每天可以从里面看到我关注的这些我很欣赏的人他们在关注什么事情,有什么最新的技术,有什么最新的观点,他们在读什么书等等。

另外一个是 HackerNews, 应该算得上是世界上最大的程序员社区了,在上面可以让我发现技术圈目前最被关注的事件是什么,当然还会有很多技术之外的好文章。

还有就是 YouTube, 我在 YouTube 除了关注一些娱乐的内容之外,还会关注一些关于生产效率、技术等等的一些偏严肃的内容。我只会在晚上睡前刷 YouTube, 早上一般来说不会主动打开 YouTube.

「快速浏览」的关键在于要把重点放在「发现」而不是「吸收」上面。因为前者花的时间很短,而后者会很长,最有效率的做法是,看到你感兴趣的,就把他扔在一个统一的地方,然后忘掉,去看发现下一个。等刷完你的时间线后,再开始「吸收」刚刚扔进来的一堆信息。这有点像你在 shopping, 把你想要的都放在购物车上,然后回家再把这一车的东西吸收整理。

快速浏览的流程

应该统一放在什么地方呢?我个人在不同的情况下会用不同的工具。我感兴趣的内容一般会有以下几种:

  • 新的语言、框架、库
  • 我感兴趣的文章、视频
  • 新的产品

对于我感兴趣的文章和视频,我会首先打开它们快速地略读,如果确定我有兴趣深入地读,我就会把他保存到 Readwise Reader 这个稍后读工具里。无论是文章还是视频,我在浏览器只要点一下就可以收藏。

这里要注意的是,很多人用稍后读工具,就是点一下保存之后就把页面关掉。而我会做得更多一些,我会根据这篇文章的内容打一些 tag, 这样等到将来我需要写关于某个主题的文章时,可以在 Readwise Reader 里通过标签直接找到关于这个主题的文章。

我还会在这篇文章加上注释 —— 为什么我想读这篇文章?我想从这篇文章里得到什么?我会强迫自己添加一篇稍后读的文章的时候思考这个问题,并且用十几个字简单地描述。这样当我在之后读这篇文章的时候,我可以带着我的问题去阅读,这样会更有效率。

如果看到的是新的产品,新的技术,新的开源库之类的,我会点进去快速地了解一下这个东西,如果我觉得可能在日后我会用到它,我就会把它保存到 Raindrop 这个书签管理服务。首先是给这个东西打上合适的 tag. 然后如果我觉得我需要更深入地学习这个技术,我会把它存到一个叫作 Inbox 的文件夹,我会在「消化」内容的阶段检查我的 Inbox 文件夹。

总的来说,第一个阶段就是快速地把我感兴趣的内容捕捉下来,根据不同的内容类型分别存到 Readwise Reader 和 Raindrop 里面。

Raindrop

读书笔记

我近一年最主要的读书渠道就是微信读书,我会在书里面直接划线和写想法。可惜微信读书没办法同步到 Readwise, 所以我写了个叫 NotePal 的工具帮我把微信读书的笔记转换到 Readwise 的格式,然后我会在读完一本书之后手动地同步到 Readwise.

NotePal 界面

内容消化

我一般会在晚上下班后的闲暇时间开始我的「内容消化」阶段。这个阶段主要的任务是把我在「快速浏览」时捕捉到的东西认真地消化。所谓的「消化」,其实指的是我试图从这些内容里面:

  • 学到新的东西
  • 得到新的灵感、想法
  • 得知新的工具,将来解决某些问题的时候可以搜到。

在 Readwise Reader 里,我会在读到让我有所收获的句子下面划线,然后打 tag, 有时候还会写下我的想法。我比较喜欢用 Readwise Reader 是因为他还包含了 RSS 订阅,我可以直接把它当作 RSS 阅读器读到我订阅的博客,然后直接在上面做笔记。而且如果保存了一个 YouTube 视频,它会把字幕显示出来,可以直接在字幕上划线做笔记。这些笔记会自动同步到我的 Logseq 里面。

Readwise Reader 界面

Readwise Reader 阅读视频

Readwise 自动同步到 Logseq

稍后读的内容过完了之后,我就会检查 Raindrop 的 Inbox, 如果我被某个产品或者技术启发出来了新的想法,我会直接记在 Logseq 里。

笔记组织

把东西记在笔记软件里只是第一步,更重要的一步是怎么去组织这些笔记。组织笔记的目的不是为了满足强迫症,而是尽可能地让我记下来的笔记更容易在我需要的时候被我发现。我一般是在把笔记写进 Logseq 的同时做好组织的,因为在 Logseq 组织笔记的形式无非在关键词里加上双向链接,或者打上合适的 tag.

但我后来发现如何打好 tag 是一个学问。在 Building a Second Brain 这本书里,Tiago Frante 对如何组织笔记提出了一个框架,叫 P.A.R.A. 也就是 Projects, Areas, Resources, Archives. 这个框架主张把笔记分这四种不同的类型存放。

PARA

  • Projects 指的是正在做的项目,比如正在学习的某一门课,正在开发的某个产品。
  • Areas 指的是你感兴趣的领域,比如理财、编程、职业规划、商业等等。
  • Resources 指的是在未来可能会有用途的东西,我的理解是那些你可能会用到的,将来可以立刻作为参考的东西。比如最近我会看到很多关于 Prompt Engineering 的东西,虽然这不是我的领域,但我觉得将来会有用,所以我的 Logseq 里会有 Resources/Prompt Engineering 这个页面,跟 prompt 相关的笔记都会带上这个 tag.
  • Archives 指的是你已经完成的项目。

我觉得 P.A.R.A 这个框架给了我很大的启发,我在 Logseq 里实践了这个框架,并且根据我自己的情况,我对这个框架进行了一些适用于我的改造。

  1. 我基本不需要 Projects 这个分类,因为我有用其它任务追踪工具。
  2. 同样地,我不需要 Archives.

因此我只保留 P.A.R.A 里面的 Areas 和 Resources 两个分类。

另外,在 Building a Second Brain 这本书里有提到关于物理学家费曼的一个故事。很多人问费曼是如何做到在这么多领域都能获得成就的,费曼分享了他的一个技巧:他说他会在心中记住十几个他很感兴趣的问题,即使这些问题他不会主动拿出来钻研,但当他每次看到一些新的发现,新的研究成果的时候,都会把这些研究发现去匹配他心中的那些问题,看这些新的发现能不能解决那些问题。

You have to keep a dozen of your favorite problems constantly present in your mind, although by and large they will lay in a dormant state. Every time you hear or read a new trick or a new result, test it against each of your twelve problems to see whether it helps. Every once in a while there will be a hit, and people will say, “How did he do it? He must be a genius!

读到这个故事的时候我非常受启发,我觉得的确是要把做的笔记也归纳到自己在思考的问题那里。这样日积月累,我的问题下面的笔记就会越来越多,多个笔记串起来会对我的问题更有帮助。

所以除了 Areas 和 Resources 这两个分类,我还建立了 Questions 这个分类,我把一直在困扰我的一些问题都建起了相应的页面,当我在记笔记时,如果觉得这个笔记和我的某个问题有关,就会链接过去。

Question, 如何做决策

Area

Resources, Prompt Engineering

无论是哪种组织框架,我觉得最重要的是让记下的笔记尽量容易被找到。当我对自己关注的 Areas 和 Resources 有一个大概的梳理后,我对之后记的笔记最后应该流向哪里也有了更清晰的认知。

检索输出

当我开始想要就某主题开始写作的时候,我就会打开 Typora 和 Logseq, 在 Typora 大概列出提纲,然后针对这个主题在 Logseq, Raindrop, Readwise Reader 里面检索相关的资料。

Typora

得益于双向链接,我在 Logseq 检索自己想要的东西的时候还算方便,因为只要你的双向链接和 tag 打得够好,在后期检索的时候你能看到很多不同的笔记互相关联。至于怎么在 Logseq 里面灵活地跳转,不属于这次要讲的范围。之后可能会单独做影片再讲讲。

总结

这就是我最近自己摸索出来的管理我的笔记的方法。你不一定和我用一样的工具,我觉得我想传达的最核心的观点的:列出你自己每天接收信息的来源。找出一个你认为最方便的方法把你从这些信息源读到的有价值的内容保存下来,然后想清楚它最终应该流向什么地方,可能是某个 tag, 可能是 P.A.R.A 里面其中的一个类型,或者是你自己的组织方法。当你有了自己的一套熟悉的方法论,你就会更清楚日后应该怎么找到你想要的东西。

28 岁,我还想生猛下去

2023年3月25日 08:00

今天是我的 28 岁生日。

在 2016 年的生日,我在博客写下了一篇《21 岁我想说的》,那年我进入了「大厂」,获得了世俗意义的「成功」,于是写下了这篇充满雄心壮志的文章。我觉得我离自己想要的「成功」越来越接近,我终于要用技术让别人刮目相看,用技术做点有意义的事情,帮助公司的业务 move fast. 我 13 岁就梦想的事情,在那一年成真了。

很感谢当年的自己写下了那篇文章,记录下来我的年少轻狂。就像王小波在《黄金时代》里所说的:

那一天我二十一岁,在我一生的黄金时代。我有好多奢望。我想爱,想吃,还想在一瞬间变成天上半明半暗的云。

但是直到今天我 28 岁,我才深刻地理解这段话的下半段:

后来我才知道,生活就是个缓慢受锤的过程,人一天天老下去,奢望也一天天消失,最后变得像挨了锤的牛一样。可是我过二十一岁生日时没有预见到这一点。我觉得自己会永远生猛下去,什么也锤不了我。

回想我的 18 岁,2013 年,高二。我很迷茫,课桌边上的《JavaScript 高级程序设计》已经被我翻了不知道多少次。后来某次技术大会,我有幸和译者曹力一起吃了个饭,我说我是看你翻译的书长大的。我们一笑而过。但他应该不明白这本书对我的意义有多大。

周末不能回家,我就去网吧写代码,写开源库,妄想可以在社区做出一点什么。那时我觉得没人懂我的抱负,身边的同学不知道 JavaScript 是什么,他们只知道我成绩不好,不爱学习。这真是冤枉,我比大多数人都爱学习。

我迷茫是因为我不知道我的路应该怎么走。我因为学编程耽误了课业,但我真的有机会靠编程吃饭吗?是我太幼稚、太理想主义了吗?我会不会到最后,课业和编程都做不好?

在那些迷茫的时光,读书和写作拯救了我。我一有空就去学校图书馆看书,读了很多现代作品(钱钟书,胡适,王小波,阿城,等等)。还读到了毛姆,那本《刀锋》改变了我很多。

每次语文考试我都很开心,因为可以写作文。我喜欢借题发挥,格子都不够用。我根本不在意因为离题被打低分,我想表达,我想在文字中创造美。那时的语文老师很懂我,是当时为数不多让我感受到被理解的人,我很感谢他。

但我还是迷茫,有时我宁愿可以像那些「好学生」一样,心无旁骛,家长开心,老师安心。但我做不到。

19 岁那年,2014,我高考。学校照例开「成人礼」,在大堂给大家打鸡血,奋战高考。我觉得可笑,但又觉得没资格,我只是一个连高中课程都应付不来的自以为是的可怜虫。

高三一整年我恶补了我落下了课业,我像自学编程一样自学高一高二的课本,我把整个课本一字不落地读,因为我发现很多考点都出在书本里一些很隐秘的角落。我像在做一个试验,用最有效率的方法尽量提升我的成绩。于是我买了历年高考真题,认真研究每一年的规律,哪些东西一定会考,题的难度是什么样的变化,基于这些规律去定制我的备考策略。

高考完以后,我感受到了一股自由的气息。窗外在木棉树上叫的鸟,对于还在上学的人来说,多美都和她毫无关系,而对于高考完的我来说,我就是那只鸟,我想叫就叫,我想飞就飞。

很幸运,我的备考策略算是成功了。大家都觉得我考不上本科,但我最终还是考上了一所不怎么样的本科。

我不想再回顾我的大学,我在博客说得已经够多了。但有一件事很有趣,我在博客也提到过:

这是一封 2014 年我写给未来的自己的信。当时在上大一,是上职业规划课时老师布置给我们的一个作业,写完我们就交给老师保存,他会在我们大学毕业后返还。

老师通过微信联系我说有封信在他那里,并拍了这张照片。我早已忘掉我曾写过这封信,看完后我就全记起来了。

记起来刚上大学时对未知的憧憬,记起来在教室听无聊的网页设计课,记起来退学那天给宿舍阿姨还了钥匙后坐上中巴回广州市区的时候听的那首《一路向北》。

退学后我正式加入了一家创业公司,严格来说是从退学前的 part time 最后决定了退学做 full time. 没有人给我意见,应该说没有人能给我意见。选择是困难的,因为没有人知道选择的结果一定是什么。我在那一刻意识到我是一个成年人了,不像考试时的题,人生给你出的题是没有固定答案的。选择的意义,是在选择后你做的事赋予的。

那是一段艰难又快乐的日子。

快乐是因为我觉得整个世界的大门为我敞开了,写代码从此不是我「不务正业」的事,我终于来到了我的主场。

艰难是因为我没有钱。我在珠江新城上班,在地铁沿线的番禺大石租了一个 600 块一个月的城中村房子。房子在二楼,没有光线,窗外是墙壁。自来水是有异味的,我只能买桶装水洗漱。出门上班要戴口罩,因为外面路过的都是货车,沙尘滚滚。

只要 600 块的房子,因为要押二付一,刚从学校出来,我付不起。我向老板提前出了下个月的薪水才租下。

那时我开始听《IT 公论》,播客的声音让我觉得,即使我在这昏天黑地的小房子里,我和他们一样,都在这互联网的浪潮里参与其中,我已经不是被困在学校里的人了,我要在其中大展拳脚。

拿到阿里的 offer 完全出于我的意料之外,即使我很喜欢当时的创业公司,以及两位创始人,但在这样的机会面前,我还是选择了「大厂」。

我记得当天面试了几轮,最后跟 HR 见面聊了一下期望,我说了一个数。回家的路上,觉得自己是不是开得有点高了,会不会因为开高了让我错失了这个机会?在我刚坐到家附近的地铁站,竟然通知我有 offer 了。

在之后,我开始面对别人附加给我的光环 —— 年轻、辍学、年少有为。我一点也不以此为荣,我只感到害怕。我不是年少有为,我只是笨鸟先飞了,我在别人还在读大二的时候,我就提前进入了社会。我总是想,我的同学都很聪明,等他们毕业了,也许只要一年,就能学到我提前学到的东西了。

我很享受这样的工作,因为编程就是我的生活,我享受她。当年的我甚至很奇怪,为什么竟然有人不想上班?上班写代码是我最开心的事,她给我带来了成就感,我在用我的能力创造价值。

这鼓热血,真是充满魅力。

时过境迁,那鼓热血已经花光在最该花的年纪了。热血退去,我才明白,编程是我真正想要追求的东西里最表面的一层。我在意的是,我用代码实现了什么,给用户带来了什么价值。我想用我的品味和价值观,创造一些美好的东西解决实际问题,并且做成一种可持续的商业模式,又或者创造一种商业模式。

商业是一种艺术,赚钱的方式也有千万种。我想用体面和美在这个世界上生存以及留下一点什么。

希望我自己会永远生猛下去,什么也锤不了我。

你看,迦摩罗,如果你将一粒石子投入水中,石子会沿着最短的路径沉入水底。恰如悉达多有了目标并下定决心。悉达多什么都不做,他等待、思考、斋戒。他穿行于尘世万物间正如石子飞入水底—— 不必费力,无需挣扎;他自会被指引,他任凭自己沉落。目标会指引他,因为他禁止任何干扰目标的事情进入他的灵魂。这是悉达多做沙门时学到的。愚人们称其为魔法。愚人以为此乃魔鬼所为。其实,魔鬼无所作为,魔鬼并不存在。每个人都能施展法术。每个人都能实现目标,如果他会思考、等待、斋戒。

—— 赫尔曼·黑塞《悉达多》

2022 年终总结

2023年1月9日 08:00

今年的年终总结写得有点晚,2021 年觉得自己一事无成,迟迟没有动笔。如今 2022 年也已经过去了,虽然同样觉得自己在今年一事无成,但转念又想自己应该给自己一个回顾的机会,终于还是动笔了。

琐碎的生活变化

2022 年因为工作的变化,主要都生活在苏州。苏州是一个很「慢」的城市,我算不上特别喜欢,但我很喜欢苏州的湖。我在 ByteTalk 的这期播客节目 里提到过一些我对苏州的看法。

东方之门

苏州的一些区域可以骑摩托车上路,我喜欢摩托,所以买了一辆摩托通勤,周末偶尔也会到不同的湖边溜溜车,还认识了一些摩友。

我的摩托车

意外的插曲

我从多年前开始受情绪问题的困扰,在 2021 年开始变得更严重,到了 2022 年,它变得更加凶猛。

那根一直在紧绷的弦,最终还是断了。我在年中因为焦虑导致了惊恐发作, 这是一种焦虑的躯体化症状。由于没有相关经验,发作时我误以为心脏出现了问题,于是拨打了 120. 这也是我第一次坐上救护车。那一周我住进了医院,做了身体检查,排除了器官问题。

我的情绪问题导致了我在 2021 和 2022 都没有写什么工作以外的代码,我的内心一直在希望自己放松和希望自己多做点事情两者之间不断摇摆。我曾经认为自己是一个很清楚自己想要什么,也很有目标的人,但最近两年,我越来越不知道自己在做什么,要做什么。

零碎的产出

Logseq 分享

我在一个晚上非常即兴地录了一个关于我如何使用 Logseq 的视频,没想到会有这么多的播放量,在 YouTube 上也收到了不少的感谢和鼓励。

CodeSpeedy

发布了一个我自己个人在用的 Code snippet 管理工具 CodeSpeedy. 是我第一个发布的用 Tauri 写的程序。

AMAzingTalk

因为看到 Twitter 上有不少人提供付费咨询服务,所以做了一个页面收录了一些不错的提供咨询的人。目前只是一个简单的静态网页,但我有计划把它做成一个产品。

《兰迪和他的朋友们》

我身边有不少不同领域的有意思的朋友,很想通过访谈和交流的形式把他们各自领域的哲学分享给更多人。于是我开了一个不定期更新的 podcast 《兰迪和他的朋友们》。目前只出了两期,分别是和我的健身教练聊了健身,还有和我的同事兼攀岩岩友聊了攀岩。

新的一年我还计划做一个和香港流行音乐相关的节目,感兴趣的朋友欢迎 Email 和我交流。

攀岩

今年在我的同事 sixian 的带领下接触了攀岩,我也意外地爱上了这个运动。喜欢和岩友一起交流线路的不同爬法和技巧,喜欢用出优雅的脚法的感觉,喜欢到不同的城市拜访当地的岩馆 —— 例如我和 sixian 到 上海攀岩工厂探店 (Bilibili).

攀岩

攀岩是一个力量和技巧结合的运动,我因为有力量训练的基础,让我入门这个运动非常快。但我喜欢学习和应用技巧的部分,我对攀岩的兴趣很大程度上来自于观看了 Jain Kim 的优雅脚法.

感染 Omicron

在 2022 年的尾声感染了 Omicron, 反复发烧 2 天多,咳嗽了近一周。我在开放了一周后才打了第一针科兴。我的症状比较轻,没有失去味觉和嗅觉,也没有所谓的「刀片噪」,只有轻微的扁桃体发炎类似的感觉。

最后

2023 年我就 28 岁了,有时候填表格看到年龄的一项写着 27, 会让我有些感觉陌生。我总是觉得自己距离踏出学校的那天还不是很远,在写做了 6 年程序员,我学到的 10 条经验 时我才发现自己已经工作了 6 年多了。我也偶尔看回 我 21 生日时写的博客, 很多问题在我内心缠绕:我还能做些什么?我想要的到底是什么?我的价值是什么?我接受了自己只是个普通人吗?

我没有答案。

读《九宫格写作法》

2022年8月20日 08:00

九宫格写作法封面

倪爽Twitter 推荐了这本书,对于喜欢写作的我来说很吸引,花了很短时间就把这本书读完了。在这里推荐给大家。这本书主要给认为写不出来文章的人提供一些指南,书的前半部分是方法论,后半部分是写作套路(或者说写作框架)。

九宫格指的是在写作之前,从文章的中心,可以扩散出 8 个方格,填写和这个中心有关的信息,型成一个写作九宫格。九宫格的作用是在写作前迫使你先对文章中心进行思考、提出问题,然后进行填充。是一种帮助你在写作前收集信息的辅助手段。

所以通俗地讲,九宫格写作法的核心在于训练你在写作前的信息收集习惯。书中有一个比较确切的例子:如果你准备一场旅行,打算旅行过后写一篇游记。你就应该在旅行之前就画好一个九宫格,填上这篇游记你想要写所有的要点:

写作九宫格

然后在你旅行的时候,才有目标进行相关信息的采集,然后填充到九宫格里面,这样当旅行结束,你已经收集到了足够的信息,把它们整理成为一篇完整的游记。而不是到了当地漫无目的地游玩,然后回来只能追溯一下往事,已经忘了可以写一些什么,最终写出来的只不过是一些浅显的感受。

九宫格写作法实际上并不要求你只能有九个格子,你可以任意地扩张。所以这个写作方法,中心的思想就是:在写作之前,列出你对于这个写作主题的所有想要讨论的问题,然后再动笔。在列出九宫格的同时,整个文章的结构就自然而然地形成了。

九宫格写作法突出了写作前信息收集对于轻松写出一篇有价值的长文的重要性,这也是为什么作为一个有意向写作的人来说,平时做笔记那么重要。只有平时在信息输入的时候有意识地把价值输入作为笔记存到你的第二大脑(笔记工具)里,将来才可以基于平时的笔记轻松地写出一篇文章。这个过程也叫作「信息内化」。九宫格写作法辅助了你的「信息内化」能力。

这就是创作过程的核心: 在你选择你要写的东西之前,你必须下功夫研究并积累。理想情况下,你应该在创作开始之前就开始研究,这样一旦你决定了一个话题,你就有数周、数月甚至数年的丰富资料可以利用。这就是为什么你要把信息放在「第二大脑」如此重要的原因。

—— 真正的思考技术

我以前也常常觉得很难下笔,就是因为平时即使输入了很多信息,但没有把他们内化成自己的信息。陷入了「写作就是从一张白纸开始」的迷思。几年前机缘巧合下开始使用 Roam Research 并且读了 How to take smart note, 开始把平时摄取的有价值的输入记在了我的笔记工具里,通过双向链接,使我很容易在构思一篇文章的时候得到足够的素材。所以在读这本书的时候我很有共鸣,也对我的写作模式提供了一个更系统的方法论支持。

书的后半部分基本是一些写作的套路(框架),对我来说这部分意义不大。因为我从小就通过在学校的写作和平时写博客中得到了很多实践积累,对于写作的内容(例如哪些应该是文章重点、在文章中如何表达有价值的主观感受等等)我自己已经有了较多的体会。所以这部分我只进行了略读。对于缺少实践的读者来说,这部分也可以细读。

再谈辍学

2021年10月20日 08:00

我在退学的那一年写了一篇《你根本用不着退学》来告诫想退学的人慎重选择退学这种方式。今年是写完这篇博客的第五年,我想结合五年来作为一个辍学生遇到的经历,再谈谈退学。

我第一次感受到辍学给我带来的副作用是刚辍学不久的时候,曾经给一些「大厂」投过简历,在 HR 筛选简历的一轮就被筛选掉了。我当时对进「大厂」的心理预期本来就很低,所以这对我来说根本影响不了我的心情,被筛选掉反而是正常结果。我很幸运,阿里的其中一个部门鬼使神差地给我了一个机会,我最终顺利通过了面试。

我辍学后在别人眼里过得一帆风顺,是因为我受到了运气的眷顾。我很幸运,我出生在一个小康家庭,可以让我从小就能接触到我往后一生都热爱的计算机和互联网;我很幸运,在辍学前遇到了李秉骏先生(他们现在在做无人机空间数据应用平台),让我即使辍学了,还可以在一家创业公司尽情发挥自己的技术;我很幸运,阿里的 HR 对我的简历手下留情,也许只不过是当时的团队刚好非常缺人,我刚好投了简历,所以我通过了。但如果我说这只是单纯的幸运,那未免有点虚伪。我很清楚,即使我得到了这样的运气,我也需要有足够的实力和其它同样有运气的人比较胜出。所以这是运气和实力结合的结果,但没有运气,这一切都不会发生。

打过德州扑克的都知道,没有人可以靠运气一直取胜。

在这五年,我就是别人口中「幸存者偏差」的那个「幸存者」。但我从来没有因为我的辍学光环感到一点骄傲。相反,我在退学一年后遇到了严重的抑郁和焦虑症状而不得不求医。除了求医,我还天真地坚信只要我保持旺盛的精力去 "make something", 去不断写代码,去不断地学习,我就能战胜我的情绪病。

但很遗憾,情绪问题是个复杂的问题。我不能说辍学是我情绪病的来源,但它在其中参与了很大的比重。而且这种比重是随着时间的流逝线性增长的。在最严重的时候,我甚至完全无法沉下心做我这辈子最热爱的事 —— 写代码。说出来有点好笑,我甚至会因为在面试的时候分不清 JavaScript 里 class A extends class B 中,A.prototype 和 B.prototype 的关系而陷入严重的自我怀疑。

这是辍学给我带来最大的副作用。它让人把一切成功归因于运气,然后让人从不甘平庸变成不能平庸。

辍学在「幸存者」身上是没用的光环,在不幸的人身上就是噩梦。我能在 V2EX 找到很多这样的例子:

https://www.v2ex.com/t/808601

18 年大学差 5 学分没修完,结业了。 做了两家创业公司,现在 2021 年 10 月份了,想跳槽。

面试了华为、绿盟、建信金科,面试全部通过,全部因为学历拒发 offer 。 中间尝试联系 Boss 上专科要求的岗位,也拒绝了我。。。

https://www.v2ex.com/t/700608

但是技术在当前领域有一定优势。最近开始面试。卡在学历了

在 BOSS/拉钩 /找内推 /猎头 基本上都过不了 HR,基本看到我简历上教育背景后,确认没有双证后直接表示可能不太行。

更惨点的是面试都过了,两级直属领导当面明确表示希望我入职,然后被 HR 用规章制度否了。

https://www.v2ex.com/t/708542

根据招聘网站透漏的信息,HR 筛选候选人的最常用选项的顺序是,学历、年龄、性别、工作年限 哦,忘了说,内推我也试过了,找朋友内推也被挂学历了,一种是他们有硬性要求,二个是能力也没有到无视学历的地步

心里的无助真的很难受,加上心里不断的胡思乱想,真的是有偷偷哭过,甚至一度有人生从来的想法

在这之后的求职经历里,我有因为辍学遭遇到不公吗?我只能说,一个正常的面试官或者 HR, 是一定不会在面试的时候明显地表现出对我学历的顾虑的。但从交流之中就可以感受到,那些对我的学历和辍学经历的「好奇」,其中一定是掺杂着担忧的,至少这它一定不是一个加分项。

程序员是少有可以靠技术发声的群体,也许靠所谓的实力可以在职场混得还不错,但人的一生除了工作,还有太多的事情不是靠技术就能解决那么单纯的。也许是政策上的,也许是流程上的,也许只是别人的偏见。这些都是需要有预期去承受的。你准备好了吗?

就像我五年前写的一样,退学只是一种选择,没有人知道它是好的还是坏的。但它必定附带了很多随之而来的巨大的副作用。不是每一个人都有运气和实力和这些副作用抗衡。这个社会在一定程度上有少数派生存的空间,但社会的很多规则是设计给多数人的。抗衡需要勇气和付出比多数人多得多得多的心血。你准备好了吗?

每个人在漫长的人生中都会面临很多不同选择是否成为那个少数派。可能是辍学,可能是性少数,可能是不婚,可能是丁克。衷心希望在作出了这样的选择之后的人,一定要努力成为那个别人口中的「幸存者」。之所以这么说,是因为这五年来,我见过身边太多有运气但不努力的人,也见过太多既很努力又有运气的人。这让我能感受到,「事在人为」和「何不食肉糜」之间并不能划上等号。用自己的力量去给偏见打一个沉重的巴掌吧。

我给自己设立了每月 $20 的开源捐赠预算

2021年5月12日 08:00

Babel 官方最近发布了一篇博客 称 Babel 团队的 funding 已经不够了。一直以来我零碎地捐赠过一些开源项目和个人,在卖贴纸和 T 恤的时候也把大部分的利润捐赠给了 Vue. Babel 这件事让我有了固定每月捐赠一些开源项目的想法。

目前设定的是每月至少 $20 (约 130 多元人民币) 的预算,这样平均至少可以捐赠 4 个不同的项目。我可以在这个预算内根据我的技术栈灵活地选择我对哪些项目进行捐赠。

我个人会选择一些这样的项目进行捐赠:

  • 我在做 side-project 的时候经常会用的项目
  • 项目没有融资背景(例如我非常喜欢 Prisma, 可是它已经有了 $12M 的 A 轮融资)
  • 做了一些我用到的工具的个人开发者

目前我捐赠的项目和个人

  • EGOIST 在全职做开源的好朋友
  • chakra-ui 我用 React 写 side-project 必用的 UI component 库
  • dayjs 我经常会用的 moment.js alternative
  • react-query 我经常会用的 React 请求库
  • next-auth 非常好用的 Next.js OAuth 库
  • Logseq 开源的 Roam Research alternative

你可以在 OpenCollectiveGitHub Sponsor 看到我对哪些项目和个人进行了捐赠。

国内用户捐赠的方法

国内用户捐赠只要具有以下其中一个条件即可:

  • 注册 Paypal 账号和国内银行卡绑定
  • 持有一张 Visa 信用卡

OpenCollective 支持 Paypal 和信用卡,甚至支持银联的信用卡,因此一般国内用户都能很容易通过 OpenCollective 进行捐赠。GitHub sponsor 不支持 Paypal, 需要 Visa.

除了每月固定的捐助,还可以选择一次性的捐助。

我对开源的看法

我从开放的源代码学到了非常宝贵的知识,这些知识帮助我成为了更好的程序员。功利一些来说,我通过使用这些开源项目得到了可以谋生的岗位,这些开源项目竟然是开放和免费的。

有些人认为,做了一个成功开源项目,即使没有钱,也收获了名气。对我个人来说,我确实也通过做开源项目得到了非常多的机会,但是正是自己做过开源项目,才深知维护一个开源项目的成本不是靠「名气」就可以支撑起来的。

关于这个话题,强烈建议收听牛油果烤面包的这一集 Podcast: 《#70. 和Vue.js的创造者尤雨溪聊开源软件》

也可以读一读这本 Working in Public: The Making and Maintenance of Open Source Software, 里面有很多开源软件维护者面临的问题。

我们可以为开源做什么?

  • 根据自己的经济情况,设立一个捐赠预算($1 也很不错),给自己生活中、工作中用到的开源工具进行捐赠。
  • 和我一样写一篇文章介绍你对哪些项目进行了捐赠,鼓励更多的开发者对开源项目捐赠。
  • 贡献有意义的 PR,即使只是文案的修改。

Svelte 的异步更新实现原理

2021年4月11日 08:00

我对 Svelte 的看法 一文里,我分析了 Svelte 在编译时实现 Reactive 的原理。在这篇文章,我将分析在 Svelte 里更新一个状态 (state) 值后更新到 UI 的这一过程。

阅读本文前,你应该至少:

原理分析

为了保持简单,先从一个和 Svelte 无关的例子讲起:

// 假设我们正在实现一个 counter, 只有一个 state,就是 count, 它是一个 number:
let count = 0

// 我们可以实现一个 setCount, 来改变 count 的值,顺便执行更新 UI:
function setCount(newVal) {
  count = newVal
  updateUI()
}

function updateUI() {
  console.log("update ui with count:", count)
}

setCount(1) //=> update ui with count: 1
setCount(2) //=> update ui with count: 2
setCount(3) //=> update ui with count: 3

这样实现很简单,但是有一个严重的问题:连续的状态更新会连续触发 updateUI, 性能会非常糟糕。解决这个问题的方法是:把同一个事件循环里的所有状态更新造成的 UI 更新统一合并(batch)到一个 microtask 里统一执行。

// 基于 Promise 实现一个把函数放到 microtask 里的函数
function createMicroTask(fn) {
  Promise.resovle().then(fn);
}

let updateScheduled = false;
function scheduleUpdate() {
  if (!updateScheduled) {
    // 当首次 schedule 时,把 updateUI 放到 microtask 中
    createMicroTask(updateUI)
    updateScheduled = true;
  }
}

function updateUI() {
  updateScheduled = false
  console.log("update ui with count:", count)
}

// 在 setCount 时,不再直接触发 updateUI, 而是 schedule 一个 update
function setCount(newVal) {
  count = newVal
	scheduleUpdate()
}

setCount(1)
setCount(2)
setCount(3)
//=> update ui with count: 3

这样,在同一个事件循环里,多个状态更新只会触发一次 UI 更新。

现在假设页面上有一个 h1, updateUI 中会更新它:

let count = 0
const h1 = document.querySelector('h1')

function updateUI() {
  updateScheduled = false
	h1.innerHTML = `${count}`
}

setCount(1)
setCount(2)
setCount(3)
//=> update ui with count: 3 

So far so good. 但是相信不少人年轻的时候曾经写过这样的代码:

setCount(1)
setCount(2)
setCount(3)
console.log(h1.innerHTML) //=> 0

setCount(3) 后, h1.innerHTML 竟不是预期中的 3. 仔细一想,当然了,updateUI 是在同步代码执行完后,开始执行 microtask 队列的时候才触发的啊。

为了可以在 setCount 后拿到更新后正确的值,我们可以把关于 UI 的操作也放到下一个 microtask 才执行。为了方便,我们可以写一个 tick 函数:

function tick() {
  return new Promise.resolve()
}

async () => {
  setCount(1)
  setCount(2)
  setCount(3)
  await tick()
  console.log(h1.innerHTML) //=> 3
}

Svelte 的实际做法

回到 Svelte:

<script>
    let count = 0
</script>

<div>
    <span>{count}</span>
    <button on:click={() => count++}>+</button>
    <button on:click={() => count--}>-</button>
</div>

这个组件会被编译成一个 fragment (你不需要读懂下面的代码):

function create_fragment(ctx) {
	let div;
	let span;
	let t0;
	let t1;
	let button0;
	let t3;
	let button1;
	let mounted;
	let dispose;

	return {
		c() {
			div = element("div");
			span = element("span");
			t0 = text(/*count*/ ctx[0]);
			t1 = space();
			button0 = element("button");
			button0.textContent = "+";
			t3 = space();
			button1 = element("button");
			button1.textContent = "-";
		},
		m(target, anchor) {
			insert(target, div, anchor);
			append(div, span);
			append(span, t0);
			append(div, t1);
			append(div, button0);
			append(div, t3);
			append(div, button1);

			if (!mounted) {
				dispose = [
					listen(button0, "click", /*click_handler*/ ctx[1]),
					listen(button1, "click", /*click_handler_1*/ ctx[2])
				];

				mounted = true;
			}
		},
		p(ctx, [dirty]) {
			if (dirty & /*count*/ 1) set_data(t0, /*count*/ ctx[0]);
		},
		i: noop,
		o: noop,
		d(detaching) {
			if (detaching) detach(div);
			mounted = false;
			run_all(dispose);
		}
	};
}

function instance($$self, $$props, $$invalidate) {
	let count = 0;
	const click_handler = () => $$invalidate(0, count++, count);
	const click_handler_1 = () => $$invalidate(0, count--, count);
	return [count, click_handler, click_handler_1];
}

不要被吓到,一个 Svelte Fragment 实际上是一个函数返回几个必要的方法:

function createFragment(ctx) {
  return {
    // 创建 DOM 的方法
    c(): {},
    // 把 DOM mount 到节点的方法,以及事件绑定
    m(): {},
    // DOM 节点更新的方法
    p(): {},
		// unmount 的方法
    d() {}
  }
}

这里的 p(), 就是类似上文提到的 updateUI.

instance 则是 <script> 之中定义的变量和一些 event handlers. $$invalidate(0, count--, count) 类似上文提到的 setCount. 在真实的 Svelte 中整个状态更新的流程简单地来说就是:

  1. 用户点击 button, 触发 $$invalidate(0, count--, count)
  2. 触发 schedule_update(), 通知框架这个 fragment 需要被更新(make_dirty()),框架会维护一个 dirty_components 的数组
  3. 同步代码执行完后,开始执行 microtask, 触发更新(flush),遍历 dirty_components, 触发每一个 component 的 p()

读《蒂姆·库克传》

2021年3月14日 08:00

书封面

购买链接

我对 Apple 的钦佩除了是因为产品本身的设计和体验,还有 Apple 作为商业巨头,对个人隐私、环保、无障碍等等这些「人文关怀」有着并非门面功夫的执着。读这本书之前我没有想到这些执着其实大部分来自于 Tim Cook.

2014年5月,美国国家公共政策研究中心保守派智囊团的一名成员逼迫库克衡量可持续发展项目会给苹果带来的利益损失,库克拒绝了,他说:“当我们付出努力,为了让盲人也可以使用我们的设备时,我是不会考虑该死的ROI(投资回报率)的。苹果在发起环保倡议、保护员工安全和其他政策时也是如此。“如果你让我做事的时候,唯一关心的就是投资回报率,那我希望你马上抛出苹果的股票!”库克向这位保守投资者吼道。

谈到慈善这件事,乔布斯是出了名的不感兴趣,他说他能做的最大的慈善,就是提升苹果的市值,这样股东们就会有更多的钱投入他们选择的事业里。

《纽约时报》还发表了一份有关富士康工作条件的调查报告,这份报告后来还获得了普利策奖。一向性格谦和的库克对此大发雷霆,在跟员工们分享看法时,他表达出了与乔布斯迥然不同的态度——乔布斯曾被指责在此事上表现冷漠。在一封内部邮件中,库克说看到这份报告后很“气恼”,甚至“火冒三丈”。他开诚布公地写道:“我们的供应链遍及全球,我们关心其中的每一位员工。任何一起事故都令人深感不安,任何有关工作环境的问题都值得关注。任何认为我们对员工漠不关心的想法都完全错误,并且令人反感。你们是最了解真相的人,这种指责与我们的价值观相悖。苹果完全不是这样的。”库克再三强调苹果正在改善成千上万名工人的工作条件,他决心要纠正大众的误解。

这本所谓的「传」实际上是作者把 Tim Cook 的公开言说和资料以及一些他身边的好友的回忆整理在一起,还原出了 Tim Cook 的人生和事业轨迹。相当于是加长版的 Tim Cook 维基百科页。

从 Steve Jobs 重返 Apple 不久开始,Tim Cook 就已经在苹果发挥了很大的价值,解决了苹果在供应链上的问题,这对当时的 Apple 而言是很至关重要的。可是解决供应链问题不像做产品那么 cool, 作为局外人的消费者,很难看到 Tim Cook 的价值所在。「只有当供应链出现了问题的时候,人们才会发现供应链的问题」。从 Tim Cook 解决问题的方式可以看出来,他和 Steve Jobs 一样能做到 Think Different.

书中还记录了很多 Tim Cook 关于人文关怀的事例。我猜测他的这些执着是来源于他从小遇见过的种族主义者,还有他本身作为社会中的少数派(同性恋),让他把尊重多元社会视为己任。有趣的是他在读大学的时候还修过一门「道德课」:

库克在杜克大学读书的时候,修了一门道德课,这门课对他日后产生了深远的影响。一名工程师学习道德课程,这并不常见,但是库克希望拓宽自己的视野,希望自己对工程学和商业有全球化的视角。在职业生涯的早期,库克就在思索,公司可以成为一股向善的力量以推动世界的改变。

购买链接

❌
❌