2025-06-23 08:00:00
萌生出做这个 App 的念头源于一个非常朴素的需求:我想在干活时,放一些舒服的背景音乐。这个需求有很多现成的解决方案,但没有太满意的。我希望它是
论曲库的话,YouTube 是最全的,Lofi、钢琴曲、Jazz 等等,只要愿意花点时间,总能找到满意的,听腻了的话,也很容易找到新的。但我不想打开 YouTube,一个是不够方便,另外就是干扰因素太多,还容易被推荐视频吸引而掉进兔子洞。
于是我就想,不如做一个可以播放 YouTube Playlist 的 Mac App 吧,这就是 LimTube 这个 Mac App 的创作初衷。
既然能添加 Playlist 了,我也会顺手把 YouTube 上感兴趣的 List 加进来,省的每次都要打开 YouTube。那既然 Playlist 可以添加,Channels 不加好像也说不过去,于是就变成了这样。
自己用了一段时间,感觉还是挺方便的,如果你也有类似的需求,欢迎使用和反馈。
2025-06-23 08:00:00
昨晚在看特雷弗·诺亚的《天生有罪》,开篇的一段话是这样的:
其中最明显的裂隙存在于南非两大主要的部落之间,祖鲁和科萨。祖鲁人是公认的战士。他们很骄傲,会拼尽全力去战斗。殖民者的军队入侵时,祖鲁人拿着长矛与盾牌就冲上了战场,和对面拿着枪支弹药的敌人血拼。上千名祖鲁人死在了战场上,但是他们从未停止过战斗。和祖鲁人截然不同的是,科萨人一直以头脑灵活而自豪。我的母亲是科萨人。纳尔逊·曼德拉也是科萨人。科萨人也与白人进行了漫长的战争,但是在对手武器装备遥遥领先的情况下,科萨人感受到了武力战争的徒劳,于是一些科萨首领采取了一种更机智的手段。‘不论我们喜不喜欢,这些白人都已经在这儿了,’他们说,‘我们来看看他们都有什么长处是我们可以用得上的。与其抵抗他们的语言,不如我们来学学英语。这样我们就能明白他们在说什么,然后迫使他们与我们谈判。’
我忽然想到,这段历史的镜像,还挺像我们与「智能手机」的关系。智能手机,就像当年那些无法阻挡的「白人」一样,携带着压倒性的技术优势,闯入了我们的生活。它强大、迷人,以「便利」和「连接」为名,迅速重塑了世界的样貌。
起初,我们都曾为之兴奋和着迷。它打破了信息壁垒,延展了我们的感官,赋予了我们前所未有的可能性。但慢慢的,我们也感受到了「被殖民」的代价:注意力被无情收割,时间被碎片化,深度思考的能力逐渐退化,真实的人际关系被虚拟互动所稀释。 我们开始焦虑、疲惫,发现自己非但没有成为生活的主人,反而沦为了算法的奴隶。
面对这种困境,我不自觉地成为了「祖鲁人」:感受到了威胁,于是选择了直接对抗。这种对抗体现在行为上,是尝试各种「数字极简主义」,卸载App,甚至想换回功能机;体现在心态上,则是对智能手机持一种否定和批判的态度,视其为洪水猛兽,认为它是一切问题的根源。这种「战斗」的姿态虽然悲壮,但收效甚微,因为它违背了我们生活于世的现实。更重要的是,这种全然的抵抗,也让我关闭了探索其正面潜能的大门,比如,我因此失去了在它上面开发App、创造价值的兴趣。
科萨人的智慧给了我新的启示。当物理上的抗争显得徒劳,他们没有选择玉石俱焚,而是转向了一种更高级的策略:理解、学习、为我所用,最终与之「谈判」。
现在,我想成为一名数字时代的「科萨人」。这意味着我需要从根本上转变我的 Mindset:
接受现实,放弃幻想: 首先,坦然承认智能手机已经成为我们社会和生活的基础设施,它不会消失,只会在形态和功能上不断进化。指望通过彻底的「断舍离」来一劳永逸地解决问题,是一种不切实际的幻想。
「学习它的语言」: 「科萨人」选择学习英语,我们则需要去理解智能手机背后的运行逻辑。这不只是学习如何操作App,更是要去了解推荐算法如何工作,通知系统如何设计来吸引你的注意力,商业模式如何依赖你的使用时长。只有理解了它的「语法」,才能识破那些让你无意识沉迷的「圈套」,从被动的接受者,转变为清醒的观察者。
利用它的长处: 智能手机并非纯粹的「恶」。它是极其强大的工具,关键在于为谁所用。我们可以用它来学习新知识、管理健康、高效工作、进行深度创作、维系远方的亲情。关键在于,你要主动定义你使用它的目的,而不是被它预设的功能所定义。 这需要我们从「消费内容」的心态,转向「运用工具」的心态。
划定边界,与之「谈判」: 接受不等于放任。「科萨策略」是用对方的规则来与之周旋,为自己争取最大的利益。我们可以主动设计自己的数字环境:关闭非必要通知,设定App的使用时限,规划固定的「无手机时间」,策划能带来真实满足感的线下活动等等。这不是在「抵抗」手机,而是在与它「谈判」,重新夺回生活的主导权。
这里最重要的转变在于责任归属。如果一个人因为饮食过量而损害了健康,我们会认为是这个人的自制力出了问题,而不是食物的错。同样,如果一个人因为过度使用手机而让自己偏离了理想的人生轨道,这终究是Ta需要面对和解决的个人课题,而非手机的原罪。
成为数字时代的「科萨人」,意味着不再将自己置于科技的对立面,进行一场注定失败的消耗战。相反,选择直面这个强大的「新物种」,理解它、驯化它,最终让它服务于我们真正渴望成为的那个「更好的自己」。这,或许才是我们在这个时代,与科技共存的最佳路径。
2025-06-21 08:00:00
前几天浏览Sivers博客的 Now 页面时,发现这位我长期关注的博主因为被上海吸引而开始学习中文。作为读者,我试着发了封邮件:先是表达欣赏,继而提议成为他的中文学习伙伴。没想到很快就收到回信——他详细说明了学习进度,还分享了自己的中文名字。随后的邮件往来中,我们交换了更多个人信息。
这个简单的举动,让我与千里之外的人建立了真实连接。在社交网络触手可及的时代,这看似平常,但电子邮件带来的体验还是不太一样:没有信息洪流,没有算法干预,没有无止境的推送诱惑。就像在数字丛林中意外发现的一条幽静小径,这条由最原始通信协议铺就的道路上,文字在发件箱与收件箱间静静流淌,每个字节都承载着明确意图。
当光标在邮件正文框规律闪烁时,你能清晰听见自己的思考节奏——宛如钢笔在信纸上沙沙作响的往昔。这种交流自带庄严的仪式感:点击发送后,你不会焦虑地刷新收件箱,而是像投递老式邮筒般,任由时间在对话间自然发酵。
电子邮件则像 一壶需要静待滴滤的手冲咖啡,虽然节奏迥异,却各自诠释着数字时代的沟通美学。。当世界将人际关系简化为「点赞」,「转发」的标准化货币时,一封邮件的抵达,依然如同中世纪商船运来的香料,让收件人嗅到遥远大陆的真实气息。
如果你也向往这种纯粹的文字交流,欢迎来信。每封邮件我都会认真阅读和回复。我的邮箱地址是: [email protected]
2025-06-13 08:00:00
断断续续从不同渠道听说过洗冷水澡,以及带来的好处,并没太在意:热水澡那么舒服,为什么要折磨自己呢。直到有一次心血来潮试了一下:打开冷水,不给自己思考时间,迎上去。头 1 分钟会有点挑战,3 分钟后,基本就适应了。后来又发现一个小技巧,可以帮助克服最开始的不适应:洗头。一方面可以避免冷水全部浇在身上,另一方面也可以分散注意力,等头洗完后,身体也差不多适应了。
我自己洗完冷水澡的感受是头脑更清醒了,身体会微微发热还蛮舒服的(更具体的洗冷水澡的好处,可以问下大语言模型)。如果把冷水澡比做「难而正确的事情」,热水澡比做「容易但无长期收益的事情」,生活中的很多选择都如同在冷热水之间徘徊。热水澡是即刻的温柔乡,让人沉溺于熟悉的舒适区;而冷水澡则是清醒剂,用短暂的刺痛换来长久的活力。
很多时候,我们知道哪些事情应该多做,哪些事情应该少做,如果能借助「啥也不想,先来个 5 分钟」的劲儿,或许能多做一些正确的事,成为更好的自己。
PS:相比热水澡,冷水澡的搓灰体验差了一大截···
2025-06-12 08:00:00
前些日子尝试借助 Cursor(主要是 claude-sonnet-4) 写一个五子棋 Web App,想着这是一个挺成熟的项目,应该不太需要干预,直接 Vibe Coding(依靠 LLM 生成代码) 应该就能搞定。一开始挺顺利的,界面经过几轮 Prompt 后,基本符合需求,也可以下棋,但在优化五子棋智能时遇到了严重的问题。我扮演 QA 的角色,不断地下棋,然后反馈五子棋算法的错误落子,AI Code Assistant(以下简称 ACA) 收到反馈后,总是会回复:我找到问题了!我解决问题了!完美!诸如此类,我还真就信了。在尝试了大约 50 次后,我发现事情不对,它好像没有真正地解决问题,只是解决了我那次报给它的问题,而且代码也变得异常臃肿,根本没法维护。
后来我就换了一个思路,先实现一个最最基础的五子棋策略,然后询问多个 AI,把代码发给它们,让它们提供优化思路,再把这些 AI 提到的共通点收集起来,让 ACA 每次只针对其中的一点进行优化,并且让它写对应的测试。如此经过几轮迭代下来,才终于慢慢地提升了五子棋的智能,代码也有了可维护性。
本以为一天可以搞定的需求,结果花了近四天,才基本完工,这其中走了不少弯路,正好总结下自己对于 AI-Assisted Coding(AI 辅助编程,以下简称 AAC) 的思考。
先说结论,我认为:
AAC 的本质是:提供了一个以完成当前任务为最高优先级的初级程序员。这里的 trick 就在于「当前任务」,假设你有一个机器人,然后跟它说:房间太乱了,打扫干净。它可能会:
ACA 也一样,它没有长期目标,也没有「代码质量」、「可维护性」等内在驱动力,它只关心如何最直接地满足当前 Prompt。针对一个任务它可能会:
if
判断,或引入 Magic Number,看起来好像解决了问题,但其实是在堆积技术债。这个倾向在写测试时体现的淋漓尽致。如果你的 prompt 是:为本次代码改动编写测试。那么它很可能会写好几个测试,结果也都通过了,但测试本身非常敷衍。正是因为这些特性,ACA 的表现看起来像是初级程序员。它们缺少创造性思考和大局观,能生成「看起来合理」的代码,但逻辑正确性、架构合理性、长期可维护性需要人工把关。所以ACA 不是一个完全独立的开发者,它是一个高级工具。如果你只是提需求和报 Bug,会发现它可能会为了解决 Bug 而引入新的 Bug,或者为了实现某个功能而增加不必要的复杂度。AI 并不真正理解代码,它只是模拟理解,如果你告诉它错了,它会立刻道歉并尝试给出另一个答案,但这不代表它真的理解了错误。
但我们可以利用它「以完成当前任务为最高优先级」的这个特点,来发挥它的价值。这就需要我们的 prompt 指令清晰,目标明确,且足够小。比如「实现登录功能」,这个 prompt 太大,太模糊。把它分解成:
然后按顺序提交给 ACA,效果会好得多。这个是 Cloudflare 的工程师通过 Cluade 写的代码,可以看下他们给 Claude 的 prompt:
prompt: Please write tests for this library using vitest. The tests should use a mock or fake KV namespace for storage. Be sure to study README.md and storage-schema.md in addition to oauth-provider.ts to fully understand the functionality. Try to cover all the important logic.
Claude initially wrote a separate mock library.
prompt: Let's just put the whole test including mocks in one file.
Claude spent several minutes thinking and produced the test. It failed immediately due to `cloudflare:workers` not being available.
prompt: Looks like for this test to run under node, we need to mock out the `cloudflare:workers` module. We just need to define the `WorkerEntrypoint` class. Can you do that?
Claude did this. Yay.
Several tests are still failing, but they do run. Will debug in separate commits.
由此可见,prompt 要明确:
必要的话,再提供一些示例。通常需要几轮迭代才能完成一个小 feature 或修复一个 bug。每一轮 prompt,ACA 都会输出它的思考和对应的代码,不要在这个期间切换到社交媒体上刷新闻,这样不仅不容易进入 Flow 状态,也容易忽略 AI 犯的错。如果发现 ACA 无法正确地执行任务,要找到其中的原因或提供自己的思考,反馈给它,这样才能打开思路,避免进入死胡同。一个好的实践是,在把 Prompt 给 ACA 之前,自己先思考下:如果是我来做,大概会怎么实现,然后跟 ACA 的输出做对比。
有了 Prompt 的最佳实践后,接下来要做的就是如何生成这些 Prompt,这个就需要用到高阶程序员的技能了:架构设计、良好的编程习惯、定位问题和目标分解。一个好的架构是基础,它让每个模块职责清晰、数据可以顺畅流转、便于新增 Feature、便于定位 Bug。好的编程习惯可以让代码更容易维护。好的目标分解能力和定位问题能力,可以将产品经理的 Feature、QA 发现的 Bug、技术需求等转化为高质量的 Prompt,借助 ACA 的能力,得到最终想要的结果。
有了高质量的 Prompt 还不够,因为 ACA 依旧可能犯错,因此代码 Review 必不可少。值得考虑的点有:
所以,有了 ACA 并不意味着学习编程基础知识变得不那么重要,程序员的经验变得无足轻重,或者程序员的技能会被 AI 完全取代,恰恰相反,它需要你掌握高阶的编程技能,善于与 ACA 沟通,才能让开发效率事半功倍。
采用 AAC 后,开发范式会发生转变,开发者的角色从以「写代码」为主,慢慢转向「设计架构、分解任务、优化 Prompt、Review 代码」。越早适应这种转变,强迫自己提升对应的能力,越能取得优势。
One More Thing:精通市面上最强的 ACA(如 Cursor),结合最强的 AI 模型,可以大幅提升开发效率。
2025-03-15 08:00:00
理论上,一个平台包揽文本内容的创作、分发和消费应该会很高效,就像早期的 Twitter。但这种模式存在着根本性的弊端:不可控性。这种不可控体现在多个方面:
正因为这些潜在的风险,我对新兴的类 Twitter 平台始终保持警惕。即使它们目前看起来符合你的需求,但这些不可控因素就像悬在头上的达摩克利斯之剑,随时可能落下(Twitter 到 X 的转变就是一个例子)。
既然不能完全依赖于某个平台,那么将创作、分发和消费环节拆解开来,或许是更理想的方案。
文本内容创作主要指以文字为主,富媒体为辅的形式,例如写博客、发微博等。在工具选择上,可以考虑以下几种方案:
对于有编程基础、有文本内容创作需求、追求高度自由的用户,搭建独立博客是一个不错的选择。市面上有很多优秀的开源博客工具可供选择。在托管方面,可以选择 VPS(虚拟专用服务器)或类似 Vercel 这样的 Serverless 平台。
如果你想要一个独立的博客主页,希望有一定的可定制性,能够方便地撰写文本内容,但又不想花费太多精力在代码和服务器维护上,那么付费博客工具是理想的选择。以下是一些值得考虑的服务:
免费博客的自由度相对较低,但对于只需要简单记录和分享的用户来说,也是一个不错的选择。BearBlog 和 Write.as 都是值得信赖的选择,它们功能有限,界面简洁,但能够满足基本的写作需求。
现在内容分散在不同的博客平台上,如果想要方便地了解这些内容的更新,逐个访问网页效率太低。如果有一个工具可以将这些内容聚合起来,并在有更新时及时推送,将会非常方便。这样的工具确实存在,例如 NetNewsWire。使用者甚至不需要了解 RSS 的原理,只需将网页地址添加到订阅源即可。如果博客提供了全文输出,用户甚至可以直接在 NetNewsWire 中阅读完整内容。
这听起来很完美,但实际使用中仍然存在一些问题。
并非所有网站都提供 RSS 支持(如果对 RSS 不熟悉,可以点击此处了解)。例如,X 平台就不提供 RSS 输出。原本这可以通过解析网页内容来解决,但一些大型平台出于数据保护等原因,开始限制匿名访问,例如要求登录后才能查看内容。此外,一些 App 弱化了 Web 功能,将重心放在移动端,也增加了 RSS 获取的难度。
我们往往没有足够的时间和精力去主动发现和管理自己感兴趣的内容。如果没有良好的发现机制,就可能错过有价值的信息。这并非 RSS 的职责,而是各个平台推荐系统所擅长的。然而,正是因为意识到信息发现的重要性,我们常常沉迷于无休止的 “刷” 内容,导致 “发现” 本身成为了目的,而忽略了 “发现” 之后的行动。
RSS 只负责抓取最新的内容,不提供互动功能。如果想要给作者留言,需要跳转到对应的网站。但并非所有博客都提供评论功能,即使提供,想要了解作者是否回复,也需要专门访问该网站。这使得互动体验不够便捷。
因此,一旦你决定跳出集创作、分发和消费于一体的平台,就会发现,在内容分发和消费方面,现有的工具支持仍然不够完善。曾经有一款产品能够较好地解决这些问题,那就是 Google Reader(点击此处大致了解 Google Reader)。Google Reader 在 RSS 工具的基础上,支持关注用户、分享 NewsItem 、对 NewsItem 进行评论,同时又足够简洁。这些功能恰好解决了信息源闭塞和互动不足的问题。尽管已经过去了十多年,我仍然认为 Google Reader 是一款非常棒的产品,而目前还没有完美的替代方案。