水母 / Jellyfish

Blog 问题挑战！

Fri, 24 Apr 2026 03:00:00 GMT

在 Wiwi 的博客上看到了一个蛮有意思的 Blog 问题挑战，我也来写一个吧！

问题

編號	問題
1	你當初為什麼開始寫部落格？
2	你使用什麼平台來管理你的部落格？為什麼選擇它？
3	你之前有在其他平台上寫過部落格文章嗎？
4	你如何撰寫文章？例如，使用本地編輯工具，還是在部落格的後台／控制面板中編寫？
5	你什麼時候最有寫作靈感？
6	你會在寫完後立即發布，還是會先存成草稿醞釀一下？
7	你部落格上最喜歡的文章是哪一篇？
8	你對部落格有什麼未來計畫嗎？例如重新設計、搬到另一個平台，或是加入新功能？

为什么写博客

其实已经写过好多次了…… 这应该是我坚持最久的一次，每次的原因都不同：

最早，是觉得写博客很酷，也想有一个地方发表自己写在 Obsidian 里面的文章，不想只是烂在电脑里面
后来觉得博客可以作为「在线作品集」，只需要贴出链接给需要的人就好啦（虽然完全没有这种需求）
现在，是在减少社交媒体的使用后，给自己当下的想法找一个出口

我觉得这个转变有一个很重要的内核，就是我逐渐开始接受自己「自然」的表达，而不会斟酌很久导致完美主义症状发作。毕竟好的系统都是逐步构建的嘛！

我用什么平台管理

一直用的都是 GitHub Page 来部署，你可以在这里看到我的代码仓库。GitHub Page 是完全免费的，但只能部署静态页面，不过反正我只是需要一个网页来展示文章而已。默认的网址是 [你的 GitHub ID].github.io，但你也可以改成自己的域名。我的域名是 www.tcli.me，tcli是我的姓名缩写，.me 的一级域名也符合博客的主题，还蛮不错的吧！

博客的前端框架用的是 Astro，页面布局则用的是开源免费的 Dante ，我不是很熟悉前端框架，但在 Codex 的帮助下还是完成了一些自定义工作，比如博客首页的「Latest」部分就是 Vibe Coding 出来的。如果你像我一样有强迫症，希望完全自定义博客页面，推荐你选择自建站点，在 AI 的帮助下应该还是蛮容易的。

有其他平台写文章吗

很少。通常来说，我不会在朋友圈、小红书这样的平台发长篇大论，毕竟算法不青睐这样的内容，而给现实生活中的朋友看到这种程度的自我披露，也让我觉得有些 cringe.

我曾在少数派发过一篇文章讨论如何控制玩手机的欲望，还拿了当年的年度征文，不过总的来说，我一般不会这样长篇大论地写文章。

在某段比较 down 的时期，我也在 bilibili 上频繁发过一些非常意识流、没什么逻辑的文字，但最近也不怎么发了。

我如何写文章

以前会想用 Obsidian 写文和管理，但看习惯 VSCode 后，感觉还是直接在 IDE 里面写，更不容易因为格式和排版问题分心。

虽然 Wiwi 是命令行的鼓吹者（顺带一提，他的鼓吹真的很有用，在他的影响下我已经改变了很多使用电脑的习惯），但我暂时还不打算做到那么 Geek（笑）

我何时有写作灵感

我通常会在每天早上到工位后，趁着早上没有什么活儿把今天的文章写掉。感觉早上的自己脑子最清醒，这样的好时间怎么舍得留给工作 :-P

至于灵感，毕竟博客刚起步嘛，肯定不至于枯竭。我也会在文章里留下一些跳转链接（其实这篇里面就有！），等未来再单独开一篇详细聊一聊。

通常我的灵感会随机产生，遇到了我就记下来，等想起来了再写成完整的文章。

会存草稿吗？

通常不会。说来也巧，我昨天才给博客新增了草稿功能，具体来说，是当我在 front matter 里将 isDraft 字段设为 true 的时候，这篇文章是不会展示在博客上的，只能从后台看见。

写这个功能不是为了攒着慢慢发（虽然也不是不可以），而是难免会遇到文章写一半就下班了的情况，我可以把没写完的文章推到 GitHub 上，然后换个地方继续写。

最喜欢的文章是哪一篇？

每一篇 :-D

未来计划是？

希望可以每天更新！目前只有一天最忙的时候没有更新。至于其他计划，就走一步看一步好啦，不然又是一个类似「生产力」的伪需求陷阱。

我的「生产力」故事

Thu, 23 Apr 2026 05:30:00 GMT

這是我的「BlogBlog 同樂會 - 2026 年 4 月」的投稿文章。本月主題是「生產力」，由 Wen 主持。如果你有自己的部落格，歡迎一起來參加！

「iPad 真的是我的生产力装备！」

「用了这个 APP，我的生产力提高了 300%！」

在我的互联网生涯里，「生产力」一直是 YouTube、bilibili 等平台上的热门话题。不论是科技数码频道，还是追逐 AI 热点的博主，任何东西只要和「生产力」挂钩，好像就总能吸引大家的目光。

从刚开始的着迷，到排斥任何相关内容，再到现在能够平静地看待它，我对「生产力」的理解走过了三个阶段。

看山是山：生产力太好了！

「生产力」这个词，总给人一种很高效、很靠谱、很有实力的感觉。

我对生产力最着迷的时期，大概是在 M Series 芯片刚装上 iPad 的那阵子。当时铺天盖地的视频和文章都在鼓吹「iPad 是最强生产力工具」。虽然我没有一冲动就去买新的 iPad，因为我很清楚，对我来说，iPad 上的生产力本来就是个伪命题。它一直是我在手机、电脑和平板里使用频率最低的设备，但我还是开始关注起生产力这个话题。

那时我会追求各种据说能提高生产力的软件和工具，比如备忘录、日记软件、记账工具，iOS 和 iPadOS 上的明星 todolist 软件 Things 3 就是那时购入的。68/128 CNY 的价格，对当时还是学生的我不算便宜，毕竟系统自带的 todolist 也不是不能用，但我觉得购入更好的软件能让我提高记录的意愿，还是咬牙买下了。

我承认，这些软件和工具本身都是很好的东西：不仅功能上和其他同类产品相比毫不逊色，设计还很漂亮，交互也符合直觉，用起来让人非常享受。但它们却的确没有、也真的无法给我带来多少生产力提升。拿 todolist 为例，虽然我会把任务拆分，按 project 归类好，再设定循环任务，可问题在于，我根本坚持不下来！不出一个礼拜，那些任务和项目就会永远死在软件里。等到下一次心血来潮，我又会把上次辛辛苦苦整理的内容全部删掉，重新整理一遍，再次循环。

这个 App 的确有助于提升生产力；然而，我所追求的，与其说是实际的效率提升，不如说是一种「正在进步」的心理满足感。

看山不是山：生产力是伪命题吗？

这样循环几次之后，终于有一天，我受不了自己一次次做这种无用功，对社交平台上的「生产力」内容也彻底祛魅了，买过的软件更是懒得再打开。这个状态大概持续了好几年。那段时间我真的一点都不想看到「生产力」这三个字，觉得它们全都是噱头，试图兜售一些华而不实的小玩意罢了，即使对正常的分享也嗤之以鼻。

不过，把注意力从「别人的生产力」上移开后，我不仅把精力省下来给了别的事情，也给「自己的生产力」留出了生长的土壤。

我不再尝试把任何事情都拆解到 todolist 里，但当我遇到容易忘记的琐碎小事，todolist 可以很好地提醒我。
我虽然不再主动搜索「生产力」主题的内容，但当我遇到低效率的场景时，一些曾经看过的技巧会适时地冒出来，为我提供灵感。

这种「由内向外」的转变很关键。工具如果不是为了解决自己的问题而存在，那它就没有价值。当然，这也是一个潜移默化的过程。过去的思考，慢慢促成了我现在处理生产力问题的能力。但说到底，在这件事上，我还是觉得见招拆招比未雨绸缪更「有生产力」一点 :-P

看山是山：生产的自由

第一次读到本月同乐会主题时，我还没搭建起自己的博客，但确实让我再次思考我对生产力的看法。生产力重要吗？当然重要！如何提高效率，几乎是任何领域里都会长期讨论的话题。那我最近有什么特别需要提高生产力的地方吗？一时还真想不起来。

我还是会被算法推荐生产力相关的内容，但不会再照单全收。能解决我当下痛点的，或者能泛化到其他场景的，我会试试看；如果它最后真能融入我的工作流，我也会很开心地接受。

时代也在变。AI 发展日新月异，如今最新、最潮流的「生产力」内容，几乎已经等同于「模型 benchmark」内容。网络上铺天盖地的，都是教你如何用 OpenClaw、用 Agent 完成日常工作流。

讽刺的是，作为 AI 从业者，我的本职工作就是研究如何利用 AI 提高效率，可我似乎反而越来越重视那些看起来低效的工作：梳理人工工作流、理解系统流程和卡点、不全盘相信 AI 的结果、不追 AI 圈热点发社交媒体，慢慢手敲几乎没人看的博客…… 这一切看起来，好像一点都不够有「生产力」。

但就像 data science 里 80% 的工作可能都在做数据预处理，或像 Harness Engineering 正变得越来越受重视一样，对个人来说，「生产力」不仅仅是做得快、做得好的问题。它更应该建立在识别自己需求的基础上，针对高频痛点，寻找简单直接的解决办法，并自在地继续下去。

也许像现在这样，一时想不起自己哪里需要提高，就是挺好的状态呢～

还有一件事……

准备投稿给 Wen 时，突然想起来我几年前还写过一篇关于如何戒手机的文章，还拿到了当年的年度征文，超级自豪！感觉这篇的主题也蛮贴合「生产力」的，就一并贴上来好啦！

养成新习惯好难

Tue, 21 Apr 2026 02:30:00 GMT

最近有点胖得不像话了，正在通过控制食量、增加锻炼的方式来控制一下体重。

昨晚下班后照例去健身房锻炼一会，我现在一般会按「胸-背-腿」的循环来练，中间加入手臂、肩膀、躯干等小肌群的训练。虽然还没练出什么名堂，但至少节奏开始慢慢稳定下来了。

目前我还处在新手期，只有诸如卧推、哑铃划船等几个动作做得比较熟练，其他的还在摸索中。每次练到不熟的动作时，都需要做一段时间后才能慢慢做到正确发力。Anyway，昨天的状态非常好，熟悉的动作很快就找到了感觉，还学了一个新动作，总共做了 5 个不同的动作。

练完还忍住没吃夜宵，就喝了一杯蛋白粉！（其实根本没有想要吃夜宵啦，朋友问我时我才发现「今天竟然没有想吃夜宵」）而且昨晚只吃了一碗炒面，没有胡吃海塞吃很多，所以整个人是蛮舒服的状态。

破戒了……

那么故事进行到这里，不出意外的话应该要出意外了。

早上来到公司，看到今天食堂有卖煎饺，想了想最近（其实只有昨天）吃得还蛮健康的，于是决定要在食堂吃个早饭。我好久没在食堂吃早饭了，可能最近一周都是买两个鸡蛋就直接去到工位上吃，早上都没有吃碳水，所以一看到有煎饺吃马上就馋了。

我心说昨晚练完，今天早上可以名正言顺地吃点碳水，不管从哪个角度看起来都是比较健康的饮食，于是心安理得地拿上餐盘排起队来。但我忘了一件事：我最近还在尝试 14+10 轻断食（fasting）！

14+10 轻断食的意思是，把进食时间的窗口控制在连续的10小时内，接下来的14小时内则只能喝水或咖啡之类的液体，不能吃东西。虽然我没觉得这样多有效，但反正也没什么损失，姑且[尝试一下](/TODO /blog/try-everything)。

因为晚上下班时间不确定，所以我会把早饭时间向后推迟一点。我通常 8 点多到公司，但我会在 10 点吃早饭。这也是为什么我有一周都没在食堂吃饭了，因为食堂 9 点就赶人出来准备午饭了。

于是当我美美享受早饭，剥着鸡蛋时，猛然想起来到底为什么自己的 gut 会产生「不要在食堂吃早饭」的想法，但已经晚了 T T

倒也没那么严重

写这篇博客的时候我又想到，只要提前今晚吃饭的时间，倒也不算破戒。这样一想，事情一下子就没那么戏剧化了。

「没那么严重」的事情还有很多：

这顿吃多了，下顿就少吃点，或者多爬半小时坡。
出门旅游没时间锻炼，就当是休息日了，不过得少吃点。

办法总比困难多嘛，总会有变通的方法的！很多时候真正危险的不是一次偏离，而是因为偏离了就干脆全部放弃、破罐子破摔。

养成新习惯好难

我忘了是在哪里看到的，养成新习惯就是给大脑建立默认路径，一旦遇到某个触发条件，就跟随一系列特定的行动。说白了，就是让一些原本需要提醒自己的事，慢慢变成不用想也会去做的事。

所以新习惯建立的过程就需要大脑积极参与，改写从前的旧路径。这个过程可不容易，因为通常旧习惯都更有诱惑力，不然怎么会成为你的「习惯」呢？而且旧路径往往很省力，新路径却处处都要留意。

想把事情全部记在脑子里难免会有疏漏，要么某段时间只培养一个或几个习惯，等到习惯固化后再培养新的；要么就写在备忘录里面，这样可以释放一些大脑的内存，把精力省下来用在该用的地方。

那么问题又来了，「先看备忘录」的习惯要怎么养成呢？😆

小技巧｜在 Mac 上如何卸载程序

Mon, 20 Apr 2026 02:30:00 GMT

前阵子我尝试用本地 LLM 自动补全代码，于是在 VSCode 里装了 Continue 插件。这个插件会通过 Ollama 拉起模型。之前我就因为觉得它不太好用卸载过一次，结果后来重新安装时，发现上次留下的用户配置还在。那时候我就有点不爽，心说 Mac 上删东西这件事好像也没想象的那么省心。

这次又要卸载，我就顺手研究了一下怎么才能删得更干净，也整理成这篇文章，顺便分享几种常见的卸载方式。

如果是从 App Store 安装

这种方式和 iOS 很像，直接在启动台里长按图标删除就可以了。

如果是从 Homebrew 安装

Homebrew 是 Mac 上非常流行的包管理工具，我的 Python、uv 都是通过 brew 安装的。

用 brew 安装的软件，卸载起来也比较简单，在控制台里直接执行下面的指令就可以。

brew uninstall XXX

最后再顺手清理一下残留内容。

brew cleanup

如果是从官网安装

这种情况通常最麻烦，也是我这次真正遇到的问题。下面就以 Ollama 为例，演示一下怎么把它删干净。

0. 先把程序关掉

这一步可以在 Dock 里右键退出，也可以打开控制台（Terminal），执行下面这行命令。

pkill -f ollama

顺带一提，如果你不太熟悉控制台，可以把它理解成一种用文本指令操控电脑的方式。和鼠标点来点去相比，很多时候它反而更快。

1. 删除本体

这一步可以在 Finder 左侧的 Applications 中找到对应 App，然后把它拖进垃圾桶；当然，也可以直接执行下面的指令。

sudo rm -rf /Applications/ollama.app

2. 删除用户数据（可能在这些地方）

接下来可以手动检查一下这些文件夹，看看里面有没有包含 ollama 的文件；如果有，就一并删掉。

~/Library/Application Support/
~/Library/Caches/
~/Library/Preferences/
~/Library/Logs/
~/Library/Saved Application State/

3. 删除隐藏文件夹

如果要在 Finder 里显示隐藏文件，快捷键是 Cmd + Shift + .。然后到 Home 目录下找到 .ollama 文件夹并删除，或者直接执行下面的指令。

rm -rf ~/.ollama

4. 删除 CLI (Command Line Interface) 工具（如果有的话）

在控制台输入下面这条命令，看看这个软件有没有安装命令行工具。

which ollama

如果输出了类似下面这样的路径，就说明它确实装了 CLI。

/usr/local/bin/ollama

接着执行下面这行命令删掉它就可以了。

sudo rm /usr/local/bin/ollama

5. 清理 Launch Agent

Launch Agent 可以简单理解成 Mac 登录或启动时会自动运行的一类配置。这一步的作用，就是把 App 从开机自动启动的相关配置里清掉。

rm -rf ~/Library/LaunchAgents/com.ollama.*

最后，检查一下是否清理干净

最后全局搜索一下包含 App 名称的文件和文件夹，确认它真的已经被删干净。

find ~ -iname "*ollama*" 2>/dev/null

好累啊

今天才发觉，原来想把一个软件卸载干净要花这么大力气。相比之下，安装软件简直轻松太多了！

可能对抗熵增的过程就是这么费劲吧。为了一个干净的环境，也只能慢慢收拾咯 😮‍💨

慢一点，会比较快

Sun, 19 Apr 2026 08:00:00 GMT

最近越来越觉得我们需要有耐心一点，

刚玩星际拓荒时超级想看攻略，很想一口气把剧情全部看完，但自己慢慢玩、慢慢发掘信息的乐趣更大；
与之相反，有时候通宵追剧、或看那种「一口气看完XX剧」，看到后半段脑子几乎完全吃不下那么大的信息量了，第二天醒来完全记不得剧情的细节；
学新知识的时候，想要一口气吃个胖子就容易畏难然后放弃，反而从很基础的简单内容开始更容易坚持下去，会走得更远；
感到焦虑的时候，通常都是有太多的事情压过来，伴随着紧张的deadline，却完全找不到入手点，但通常来说事情都可以解决，这种时候就要缓一缓，找到优先级最高的事情
好的系统（不管是文章、音乐，还是其他的作品），都是从一个鲁莽、朴素、简陋的原型慢慢演化而来的，不会一开始就变成最终的样子。在创作时，也要避免“一口气做完”的强迫症，允许作品慢慢修改和完善，过程中也许会产生新的灵感呢。
与之相反，有时候混音做入迷了，很想一口气直接做完，却因为听太久导致耳朵疲劳，反而需要花更多时间修改，还自我怀疑“是不是我技术不行？”

不过，对工作或项目来说，「慢下来」也不是完全不前进。我觉得最好的状态是从「这看起来很简单，半小时就搞定了」的事情开始入手，在过程里慢慢调整方向，同时拓宽已有的知识。

当你忘记 Progress 时，Progress 自然会出现。

这是我曾写在笔记里的感悟，好像还蛮应景的！

我对AI的看法

Fri, 17 Apr 2026 16:00:00 GMT

在这个AI能瞬间生成一切的时代，“亲手制作”反而成了一种奢侈。

最近一年，我写代码的场景大概是“描述需求—AI生成—验证&修改”。在最近工作的项目中用这种方法跑demo后，遇到了一些问题：

我写的代码，自己都不太愿意看，因为“反正AI可以马上生成，费那个劲看做什么？功能需要更改就再生成一版好了。”
即使需要看，时间成本也很高，因为我得通过阅读代码来理解函数调用逻辑，读不同函数的注释再拼凑起整体功能，就像玩魂游拼凑剧情一样烧脑。
看完之后，可能想要的实现方式和AI写的不一样，需要大改动。

在这些原因背后，其实有一个本质问题：工程级别的代码架构不是“一拍脑袋”就能 vibe code 出来的东西。AI生成的内容，存在需求确认和理解上的鸿沟，也缺乏对未来拓展性的考量。因此，一旦需求变更或需要修改，就像是在一个地基都没打好的矮楼上叠高层，最后造出来的东西一定经不起推敲，未来的开发只会越来越麻烦。

我为了这个项目代码可靠，做了什么？

首先我去看了官方文档。从理论层面来说，我缺乏RAG流程的基本认知；而具体到“如何实现”，我也缺乏对llamaindex框架的了解。通过官方提供的简单demo，我在理论上了解到RAG大致可以分为两个部分：Data Ingestion 和 Retriever。再往下，数据如何预处理、如何分块、如何打标签（metadata）并向量化，以及有哪些不同的检索方法……这些可以在了解完基础框架后慢慢补充。

在跟着demo一步步操作时，因为代码量很少，我对其中每行代码都可以无痛地查阅文档来理解它的含义。我觉得“无痛”在这里很重要，因为它可以用一种低负担的方式启动，毕竟只需要应付少量的代码，不会给自己太大压力。当真的开始阅读后，哪怕遇到新的问题，也不会产生“我需要理解好多东西”的畏难感受了。

在理解了RAG的步骤，以及llamaindex提供了什么方法实现之后，根据我的输入数据的特点，我重新设计了一版RAG流程，包含了数据预处理、Data Ingestion和Retriever查询。我首先建立好了代码框架的层级，拆分出公共模块（比如data loader作为统一的读文件入口，以应对未来输入数据类型的增加），再按功能将不同的步骤放在独立的文件夹内。对于每个文件，我在里面写好了会用到的方法，包括方法名、输入输出和方法的描述。到这里，都是我用自己的脑子在操作，只让AI做一些简单的问答和代码解释。

# 举个例子
def get_weather(city:str -> weather:str):
    """查询城市的天气。（功能描述由我来写）"""

    # 这里就交给AI来写！
    pass

到了这一步，我才放心让AI帮我写代码。我让Claude帮我实现每个方法，再由我自己进行测试（顺便学习了一下怎么用vscode给python代码写测试）。我可以确保在每个方法写完时，我能理解AI写了什么、它的功能是否是我想要的，并且在出问题时，我能明确知道该改哪里、怎么改。

我学会了什么

这次经历再一次印证了“问题分解”的强大力量。

AI写的内容不可靠，那就由人工拆分成更小的问题让它解决；
一次吃不透太多的内容（理论/代码），那就从更简单的问题入手来学习；
从基础的原型入手，确保拓展性，在未来逐步完善。

真是一条至理名言啊！

目前我对AI的印象和一年多前一样：模型还没进化到（或者说Harness还没进化到）能够轻易处理复杂架构，因此在该动脑子的时候还得动脑子。但如果能靠AI提高速度/效率/质量，也要放心大胆地去用。总之，多尝试，才能知道适不适合。

这也引出了下一个感悟：时刻保持自己的脑子清醒，毕竟我才是Harness的驾驶员啊！懂得越多，越知道何时应该用AI、何时不能用AI，更重要的是，怎么用AI。

最后：慢下来，会比较快。当你忘记progress的时候，progress也许会以最快的方式出现，甚至快到你意想不到。

“亲手制作”的奢侈

我和朋友也聊起过这件事情，但他只是觉得“我的代码能跑就行啊，哪里出了问题就让AI debug就好了”。但我觉得还是很不一样！

我坚定地认为，随着代码规模扩大，AI写的代码一定会遇到问题，或迟或早。而由我（与AI一起）来设计，一定程度上能规避这种问题，至少不会像纯vibe coding的东西那样不可靠；
最重要的是，自己写东西会！很！爽！

我其实是加班写的代码，但完全没有人催我，是我自己想写。那天是周六，我中午12点多到公司，一直写到晚上9点，完全没有感觉到时间流逝，只是沉浸在“我要如何设计代码框架，才能在面临未来新功能变更的时候，我可以改动最少的代码”之类的问题里。

晚上回去的时候，也感觉浑身轻松，解决了一件大事情，并且做得还蛮不错的！换成用AI写代码，哪怕实现了相同的结果、甚至更好，也不会给我这样的爽感。

可为什么这是一种奢侈呢？

首先，花时间找资料、学习、理解需求、设计，要花很多时间和脑细胞，完全没有“给我做XXX”然后拿到一份代码来得快；
我需要更多的前置知识（例如python语法、设计模式）来“知道我在做什么”。这些知识是我过去的教育积累起来的，甚至无法像第一点一样仅仅用时间来衡量成本差异。对一个没有接受过编码教育的人来说，甚至不会考虑到这些问题；
老板可能根本不在乎你用什么方式实现、代码的可维护性是否好，只希望看到成果。这也不难理解为什么会有那么多草台班子的“💩山”代码了。
加速！用AI就是要加速！在“3秒钟做出一个APP”、“我用AI赚了100万”刷屏时，还鼓吹要自己手写代码，也太慢、太不合群、太不够刺激了。

所以我也完全能理解朋友的观点了，但谁说享受“老式”编程的快感、在维护旧代码时可以不用翻“💩山”，不算一种奢侈呢？也许下个月他就会羡慕我咯～