2026-06-04 11:46:30
几年前，我曾经写过一篇博客，吐槽自己对各种数据记录的执念。那时候我会记录很多东西：戴运动手表记录身体数据，用时间记录工具记录每天的行为和工作，也会关注一些健康指标。记录得越多，我反而越怀疑这些数据的价值。它们被保存下来之后，似乎很少真正被使用，也很难从中看出什么有价值的信息。
现在回头看，当时的吐槽有它的背景。数据本身被记录下来，并不等于它能自动产生价值。真正困难的地方在于：如何读取、整理、分析这些数据，并从里面发现一些对自己有用的规律。但在 AI 逐渐普及之后，这件事情的意义开始变得不一样了。
最开始让我产生这个想法的，是在推特上看到有人把自己的 Apple Health 数据全部导出，然后用 AI 分析睡眠情况。AI 根据这些数据发现了他的睡眠问题，并给出了相关的建议，最后成功改善了睡眠质量。
这个例子让我意识到，健康数据的价值可能一直都在那里，只是过去个人很难高效地挖掘出来。
过去我也会定期查看 Apple Health 里的数据，但整个过程比较繁琐。每次都要点进某个单项指标，手动切换周、月、年等不同时间范围，再自己观察趋势、最大值、最小值和阶段变化。这样确实能看出一些表面变化，但观察范围很有限，也很依赖主观判断。
更重要的是，苹果的健康数据虽然记录得很完整，但某种程度上也相对封闭。之前我有一段时间换过安卓手机，那段时间的健康数据很难完整迁移回来。等我重新回到苹果生态之后，中间的数据就像断掉了一截。也正因为如此，我开始觉得，如果这些长期记录的数据只是停留在设备和系统里面，最后很可能会被遗忘，甚至在某次换设备、换系统之后逐渐丢失。
于是我开始尝试把自己的健康数据导出来，交给 AI 做进一步分析。
一开始我想找一些现成软件来完成这件事，但试了一圈之后发现，很多工具只能做基础展示，真正好用、支持增量同步和深度分析的工具往往需要付费，而且价格并不便宜，很多还是订阅制。
最后我干脆借助 Xcode 和 Claude，写了一个简单的 iOS App，用来导出 Apple Health 数据。这个 App 很简陋，也有一些限制，比如不能直接用 iCloud 同步数据，免费签名也需要定期重新构建和安装。但对我来说，它的使用频率并不高，主要是手动导出和阶段性分析，所以已经够用了。
我的分析方法也比较直接。
首先，我把 Apple Health 里的原始数据导出成 NDJSON 文件。里面包含了各种健康和运动数据，比如心率、体重、步数、活动量，以及通过 Apple Watch 记录的运动数据。
然后，我把这些数据交给 AI Agent，让它尽可能从历史数据中挖掘有价值的发现。比如观察指标的长期变化趋势，寻找值得关注的数据点，分析这些变化可能反映的问题，以及后续可以采取哪些调整。
最后，我会基于这些分析结果沉淀一些规则。第一次分析主要是尽可能多地挖掘信息，后续再根据自己的关注点不断调整分析方式。比如我到底关心哪些指标，哪些历史数据需要修正，哪些变化值得持续追踪，哪些情况需要被标记出来。
经过第一轮分析，我确实得到了一些很有意思，甚至有点警醒的发现。
从 2022 年开始使用苹果设备记录数据，到 2023 年参加工作，再到现在，我的体重增加了 10kg 以上。虽然我主观上一直知道自己在变胖，但真正看到数据曲线时，还是有些意外。它并不是某一个阶段突然上升，而是一条持续向上的曲线，只是在某些工作强度更高、运动更少的阶段，上升速度更快。
更值得注意的是，这些增加的体重大部分来自脂肪，肌肉量几乎没有同步增长。也就是说，这并不是训练带来的体重上升，而是长期生活节奏、饮食和运动不足共同作用的结果。
随着体重增加，我的静息心率和步行心率都有明显变化。刚参加工作时，我的静息心率大约在 50 多到 60 左右。工作近两年后，均值已经上升到 63–64。去年工作压力最大的时候，静息心率甚至一度达到 65 左右。从几年的均值来看，静息心率上升了大约 8 次/分钟，这个变化非常明显。
步行心率也有类似趋势。体重增加、活动量下降、有氧运动减少之后，日常走路时的心率也变得更高。这些指标放在一起看，其实反映的是一个很清晰的问题：身体负担变重了，有氧能力也在下降。
第三个是 HRV，也就是心率变异性。
HRV 通常可以反映压力和身体恢复情况。随着工作强度增加，我的 HRV 均值整体走低，去年甚至达到最低点。单看某一天的数据可能没有太大意义，但把时间拉长之后，这个趋势就很明显。它和工作压力、睡眠、运动量、体重变化之间，似乎都有一定关系。
比较积极的一点是，从今年三月底、四月初离职之后，我有了更多时间恢复运动。最近我做了不少 Zone 2 有氧训练，心率相关指标已经开始出现回落迹象。虽然时间还不算长，但从数据上看，身体状态确实在往更好的方向变化。
这也是我觉得 AI 普及之后很有价值的一点。
以前面对数量庞大、类型复杂的个人数据，普通人很难真正处理它们。我们只能依赖软件本身提供的基础图表，或者凭感觉去看趋势。但现在有了 AI 之后，只要能把数据导出来，就可以让 Agent 帮忙读取、清洗、分析、画图、写报告，甚至提炼长期观察规则。
这件事让我重新理解了“记录数据”的意义。
数据本身不会自动改变生活，但它能留下轨迹。过去很多看起来琐碎的记录，在足够长的时间尺度下，可能会变成理解自己的重要线索。体重、心率、运动、睡眠、压力，这些东西在日常生活中很容易被忽略，但数据会把它们诚实地保留下来。
从这个角度看，数据确实是一种很珍贵的个人资产。它帮助我更好地了解自己，发现长期变化，识别身体状态的规律，也能让我在制定运动、减脂和生活调整计划时，有更可靠的依据。
所以我现在反而觉得，当年那种“记录了也没什么用”的想法已经有些过时了。真正的问题是，记录之后能不能被有效使用。过去这个门槛很高，而现在 AI 正在把这个门槛大幅降低。后续我也继续保留和持续记录这些数据，然后利用这些数据去交给 AI 去不断地分析，把这些数据用起来，让它变成一个能反应真实状态的长期档案，不断挖掘、榨干它的价值。
2026-05-12 20:33:20
博客最早期用的评论系统是 Valine.js。当时整套方案完全是前端操作，后端找一个 SaaS 提供对象存储服务。在 2017、2018 年左右，大部分博客系统推荐的都是 Valine.js + LeanCloud 这套组合 —— 存储免费、够用也好用，基本上大家都用 LeanCloud。
中途 Valine 爆出过漏洞。毕竟它是纯前端的，Token 之类的敏感信息都直接写在页面里，很容易泄露。一旦泄露，别人就能拿你的 Token 去读写数据 —— 更恶心的是，可以往里面乱写一通，直接把你的博客评论刷满无意义内容甚至危险内容。
漏洞出来后没多久，就有人在 Valine 的基础上做了一个新框架 —— Waline。主要改进有几点：在 Valine 上套了一层 Web 服务，可以直接跑在 Vercel 上；把敏感信息都放到了后端，所有数据操作都通过后端服务完成；另外还提供了一个管理后台，方便内容管理。
我当时也注意到了 Valine 的安全问题，所以 Waline 一出来我就跟着换了。当时博客主题还不支持 Waline，我自己手动改的支持，用着也算稳定。
至于 Waline 本身，体感反而一般，主要是 breaking changes 太多。最开始用的是 V1，后来升到 V2，按它的使用方式，客户端一直引用最新版本，而服务端是自己部署、版本写死的，随着不断迭代，很容易出现客户端升级了但服务端没升级、两边版本不 match、系统直接用不了的情况。所以中间有段时间我干脆把客户端也锁了版本，不让它自动升级。
今天下午我发现评论区有几个明显是影视资源网的人，组团过来刷广告评论。内容看着挺多，但一看就是 AI 生成的。
把这些垃圾评论屏蔽之后，我突然意识到 —— 我已经多久没正经看过自己的评论系统了？甚至我几乎连 LeanCloud 这个平台叫什么都差点想不起来。一想到博客这么多年的评论数据都躺在一个我连名字都快忘了的服务上，心里有点没底：万一这家公司哪天悄悄关停，数据不就一起没了？于是琢磨着把评论数据导出来，看要不要迁移到其他平台，比如 Cloudflare。
结果一登录 LeanCloud，担心立刻就应验了 —— 他们宣布要在 2027 年 1 月停止对外服务了（公告链接）。
这里也提醒一下大家：LeanCloud 这个服务马上就要关停了，很多老用户可能还在用 Waline 或 Valine 这种基于 LeanCloud 的方案，突然不能用的话挺麻烦的，记得提前做好数据迁移。
真正动手的时候，我本来想图省事 —— 只迁数据源，前端那些都不动。
不看不知道，一看发现这次大版本升级，数据源都换了，连数据表结构都有变化。当然，可能是因为 LeanCloud 不再支持，他们直接换了。但是文档里把 LeanCloud 相关的部分全删了，搞得好像 LeanCloud 从来没出现过一样 —— 现在直接推荐的数据源已经变成了 Vercel 的 PostgreSQL，这变化挺让人疑惑的，对老用户的迁移也实在不友好。
旧数据源迁移挺不好办的，只能根据历史数据的字段对着看。还好之前都是对象存储，字段都在，能猜出来大概是什么、该怎么映射。虽然官方提供了一个数据迁移工具，但只能迁 comment（评论内容）。我尝试把计数表也塞进去，发现不行 —— counter（计数器）这部分官方工具转不了。
干脆直接上 CodeX。把数据库连接字符串和新表的 SQL 定义都丢给它，让它自己执行映射导入就完事了。
数据源搞定之后，还得把服务端和客户端也同步升级到 V3。
服务端这边，我当初是按官方 example 目录建了一个仓库，再部署到 Vercel 上的 —— 所以升级服务端，本质上就是把这个仓库更到 V3 最新的 example。当时是一键创建的，本地没有这份仓库，索性这事也继续丢给 CodeX 去搞。流程大致是这样：先开一个新分支部署一个版本，看看功能行不行；确认 OK 之后再合并到 master 全量发布；服务端管理页面跑通了，再把博客客户端那边也从 V2 升到 V3，顺便检查页面显示、阅读数、评论的展示和发送是不是都正常。这些都过了，基本就 OK 了。
这里有个坑要单独提一下：V3 把 JS 改成了 Module 方式导入。如果你还在用普通的 <link> 或 <script> 标签导入，会直接报错，必须用 type="module" 才能正常解析和显示。
现在评论数据和访问量数据都迁到 Vercel 的数据库了，Waline 也顺便升到了 V3，至少 LeanCloud 那边的隐患算是解了。
不过升上来之后，又发现了一个新的吐槽点：评论下方多了一个订阅评论的 RSS 功能。我觉得挺鸡肋的 —— 我已经开了邮件回复提醒，完全没必要再订阅 RSS。更难受的是只能在客户端找到一个关闭显示的选项，服务端关不掉，有点浪费资源，只能把前端入口先隐藏掉。说到底，一个评论系统真的需要这么多新功能吗？我觉得并不需要。
折腾完这一圈，我倒是冒出来一个新想法 —— 既然现在 AI 这么强，那干脆自己造一套轮子算了，把评论系统重新手写一遍。
而且我还有一个一直没解决的需求：博客除了 Waline，还另外跑着一套 Umami 做访问数据统计，数据源是某个 SaaS 数据库（好像是 TiDB）。Umami 比 Waline 的统计详细得多 —— 除了访问量，还有请求来源、地区、浏览器、操作系统等等。它和 Waline 的功能其实有不少重合，但 Waline 缺少一个专门显示统计信息的地方，所以一直是分两套用。
如果真要自己写，那就索性把这两套一起整了 —— 评论 + 详细统计放进同一套系统里，数据源也归到一处，省得过几年又翻出来，发现自己的数据躺在某个谁都没听说过的服务上，跟今天的 LeanCloud 一样。
2026-05-04 11:00:21
我一直是 RSS 的老用户。早在建立个人博客之前，我就养成了用 RSS 订阅别人博客的习惯。所以我的博客一搭起来，就马上开启了 RSS 订阅源。
对我来说，RSS 一直不只是个订阅工具。这些年我读到的那些人、那些故事，基本都是从一条条 RSS 链接开始的。所以这篇想聊的，除了我用过的几个 RSS 工具，也想顺便说说，那些工具带我看到了哪些博客和哪些人。
在那段时期，RSS 基本上就是我的博客与其他博客之间的主要关联方式。这也跟我没加"友链"有关——我感知别人的更新、看到别人写了什么，基本都通过 RSS；反过来，别人想知道我写了什么，也是通过 RSS 来发现。
RSS 本质上是输出内容的索引。它维护一份像内容摘要或预告单一样的文件，供别人定期抓取。这非常有用，否则一个个去点开看别人有没有更新，工作量未免太大。
最开始我用的是 Feedly。当时它的免费版好像支持 50 或 100 个订阅源。最初订阅的博客并不多，我都不太记得第一批是怎么找到的，可能是学校里的一些师兄。
后来我在 GitHub 上看到了一些"中文博客圈"或"中文独立博客"的 repo，可以提交收录个人博客信息和 RSS 地址。我把自己的博客提交了上去，也从上面找了一些比较多人关注的订阅源。
也正是从那时起，我读到了非常广泛的博客——不只是程序员，还有各行各业、各种年龄层的人。那种感觉，才让我真正觉得互联网是开放的、是大的。同时，因为博客信息也提交了上去，确实让更多人看到了我。对当时还是学生的我来说，能让自己的内容被看见，甚至因此被一些人认识，是件挺幸运的事。
这个效果确实达到了，也确实有一批人开始关注我的博客。直到现在，根据统计来看，博客依然保持着稳定的阅读量；而以前的浏览量，可能主要还是来自我自己。
不过开启 RSS 全文推送也带来过一个问题：一些内容聚合站会把我的文章直接 copy 到他们的网站。这是我始料未及的，所以以前还发起过一个讨论：RSS 到底要不要全文推送？当时我是想关掉的。但经历多了之后，觉得也无所谓了——反正我也不以这点流量为生，只要带上我的标题、注明是我写的，搬走就搬走吧。能让内容传播得更广，我也勉强能接受。
大学时我读得更多。随着书越看越多，关注范围也在不断扩大——从最初的某几个人，顺着他们的友链，或者评论区里发现的新名字，像网状一样向外扩散。当时这些博客的 RSS 都做得很好，订阅就越攒越多。
那段时间我正在准备保研，压力很大，要准备的事很多，心里也充满不确定。每当忙累了的时候，我就想点开一些内容来看看：扫一眼 RSS 的更新，点进去看最新文章，或者翻一翻博主过往的内容。
通过这种阅读，我去感受别人的经历，挖掘那些博主过往的故事。当时关注的不少博客都写得非常出彩，看他们写的那些经历，我有时会有代入感，也会感慨——觉得他们的生活多姿多彩，虽然我并不像他们那样自在，但看着也觉得很有意思。
读他们的博客，真的让我学到了很多。
订阅越加越多，很快就把 Feedly 的免费额度用满了。要付费的话，我自然就想到了换平台——对当时还是学生的我来说，付费有点接受不了；而且 Feedly 是国外平台，需要境外支付，我手头也没有趁手的工具。
于是我换到了开源的蚁阅。现在回头看，它的界面其实非常简单，几乎没有任何装饰，真的只是"能用"。但对于习惯点进原文去看的人来说，对工具的语言和外观本来就没那么挑剔。何况它开源、免费、稳定。
蚁阅免费版也有订阅数上限，但会员价格不贵，我就直接充了一下，主要也是想支持一下作者。开通之后，限制确实没了。但奇怪的是，会员到期之后，那个上限好像也没回来，不充钱也照样能继续加订阅，等于白嫖到了一样。
直到 Folo 出来。Folo 那段时间太火了，火到邀请码都已经在闲鱼转卖。我也花了一段时间，把所有订阅迁过去。但很快我又把它撤下来了——因为它要开始商业化收费。既然要收费，我就觉得没必要了，又找了个开源软件来用。
到了现在 AI 这么火热的年代，我索性用 Claude Code 糊了一个自己的 RSS 阅读器。数据本地存储，点一下就能抓取。在 AI 加持下，搭起来飞快，UI 也更合我的胃口，或者说能按我自己的想法来定制。我还加了一些 AI 能力，比如个性化文章推荐、博客博主画像。
打通这些功能之后，我有一个意外的发现。
Claude Code 这类 Agent 出来之后，我才意识到，之前做的很多本地系统，只要加上 AI Agent，就全都能打通。
原本我会觉得，这些只在本地跑的应用——通常是我自己起一个 Web 服务——必须打开电脑、跑起来才能用，多少有点麻烦；不在电脑前的时候就更没辙了。但有了 Agent，只要再抽一层，或者让项目原生支持 CLI，再提炼一份 Skill，Agent 就能直接操作我的 RSS 系统。
比如：
有了 Agent 这个入口，本地的东西都被串起来了。一些原本只能在电脑上用的工具，现在通过 Hermes 都能调起来。我感觉这已经接近一个最终形态了：RSS 订阅加上 AI 加持，让 AI 来负责抓取、推荐和总结。
不过说回来，到现在我依然倾向于看原文，还没怎么去依赖那些推荐和总结。有新文章，我基本都会过一遍，看看标题和简介，有兴趣的还是会点进去读。
写到这里我才发现，文章开头我说 RSS 是"输出内容的索引"，但对我而言，它真正维系的其实不只是内容，而是我和那些具体的人之间一条条很细的连接线。AI 抓取、推荐、总结都越做越好，反而越让我意识到——亲手点进去、把一篇文章读完这件事本身，就是有价值的。
如果都让 AI 总结掉，只看那几句提炼出来的要点，那读独立博客的意义，好像也就跟着没了。
独立博客好看的地方，常常并不是那些能被提炼出来的要点。是有人写自己换了个城市、写自家的猫、写工作里一些很琐碎的烦恼——那些看起来没什么信息量、AI 也总结不出什么的部分，反而才是我最想读的。
读完一篇会觉得，这个人最近大概是这种状态、在想这些事情，过得还行或者有点累。看博客对我来说，从来都不是为了高效获取信息，更多是这种很慢、很零散、像在认识一个人的感觉。
所以工具我大概还会继续折腾下去，订阅源也还会一直加。但点进原文、把一篇文章慢慢读完这件事，应该是不会变了。
2026-04-19 11:36:25
本文使用古法键盘手搓码字
拥抱语音输入也有一段时间了，进一步深入使用后，还是真的爽，尤其是需要长文输入的场景里面，使用语音输入可以让自己没有拘束地输入大段文字，再加上使用 typeless 这种能够帮忙整理语音输入内容和句式结构的软件，使用体感非常好。
之前提到的一些问题，现在用多了再回头看来，其实也不太算问题了，或者说都有比较好的解法。
比如“需要挑安静环境”这件事，换了一些软件之后我才发现，有些软件其实可以过滤掉背景声音，或者明显和说话者无关的杂音。如果再配一个专门收音的麦克风，那就更不是问题了。
再比如准确率和所谓的 AI “加戏”。如果软件够强、模型够强，准确率其实还是相当不错。哪怕是专有名词或者英语单词，只要比较常用，识别效果也已经可以接受；如果还能维护词典，那体验就更友好了。之前所谓的 AI “加戏”，估计更多还是因为当时用的 LLM 模型还不够强。
最近刚好在准备面试，也会用 AI 来做问答和 mock 面试。在这种场景下，语音输入就更合适了，因为它更接近真实面试时的状态，可以直接一口气输出大段内容来作答。有些时候，在 AI 的润色加持下，一些自己本来答得没那么好的内容，被调整之后反而能串得更顺，补得更完整。
不过，用多了之后，有时候也会想：自己是不是开始产生依赖了？
这种依赖，可能会影响自己的输出能力、打字能力，甚至成文能力。打字就不用说了，语音输入用得多了，打字自然就少了。尤其最近写代码也不怎么敲键盘，连刷题时都常常敲错。
至于成文能力和输出能力，用多了 typeless 之后，因为有 AI 帮忙兜底调整内容的成文性、用词、语句和段落结构，人只需要把自己想说的内容口喷出来就行，可能就越来越不需要主动关注内容到底该怎么组织。只要把要点提到了，意思说到了，哪怕中间夹杂了很多语气词，甚至还有无关或错误的连接词，AI 也能帮忙整理成一段语义明确、结构合理的内容。
在这种情况下，人几乎可以完全不考虑文法，想到什么就说什么，反正 AI 最后都会帮忙改好。有些时候，它整理出来的效果甚至可能比自己原本能组织出来的还要更好，尤其是那种边想边说、开口前根本没有想好结构的内容。
再进一步说，有时候即使 AI 没有把输出处理得特别好，但如果最终接收方本身也是 AI，那 AI 依然能大致理解你在说什么。这样一来，语音输入就会变得更加肆无忌惮，人也可能会慢慢对最终输出的质量变得没那么细心，甚至可能都无所谓了。
毕竟写作这种东西，本来就是会用进废退的。写得少了，自然就会生疏，文字能力也可能随之退化。最近我已经明显感觉到，有些时候需要输出内容时，会不太想动脑子，恨不得直接糊一大坨出去就算了。碰到一些相对结构化的内容时，也会发现自己需要重新想一想，或者写出来之后再一边回头看一边改，明显有种不太适应的感觉。
这样下去还是不太行。个人的写作能力和文字水平，还是得认真保持，也得持续提升。
但再往深一点想，未来是否还真的需要个人亲自写作？上一篇文章里我还在想，在这个时代里，个人到底还需要写些什么。现在又会进一步冒出另一个问题：有内容，是不是就够了？文笔和表达，真的还重要吗？一个人只要先输出一堆内容，不加组织，也不太考虑文笔和表达质量，最后全靠 AI 发挥，照样也能产出一篇看起来还不错的文章。
但问题在于，文笔和结构本身其实也是表达的一部分。你没有认真输出，最后被 AI 补上的那部分，本质上也已经成了 AI 的理解。
我之前看到过一个观点，大意是：在 AI 能力越来越强的未来，个人最重要的能力之一，反而会变成表达能力。表达能力越强，就越能准确、清晰地和 AI 交互，也越能更好地指挥 AI。只有当你自己足够清楚地知道自己想要什么，并且能够准确说出来时，才更有机会真正做到“言出法随”。
这样看下来，真正形成差异化的，可能恰恰就是表达本身。
所以还是得继续练。练文字水平，练输出能力，而且是各方面的输出能力。博客要写，其他平台上的表达也一样要练。还是得继续努力。
2026-04-04 16:00:00
我曾经是一个非常习惯做笔记、写文章的人。学习的时候，总觉得如果只是看了一遍而没有动手做点什么，就好像没有真正学到东西。
对于技术性的内容，可以通过动手实操来掌握；但对于知识型的内容，似乎只能靠输出——做笔记、写总结——来验证自己是否真的有所收获。
不过，“记笔记”这件事其实比较笼统。笔记至少可以分为两种：一种是主观输出型，由自己思考、总结得出，能写出这样的笔记自然没什么问题；另一种是摘录整理型，也是大多数人更常做的——把学到的内容摘录下来，最多做一些结构化整理。
这种摘录式的笔记，记下来似乎没什么意义：记完不过是堆在知识库里，不一定会再翻出来看，顶多是偶尔需要的时候去笔记软件里搜一下。但如果不记，又会有种不安感，好像没有学过一样。尤其是刷网课、看视频的时候，看完不留下点什么，总觉得白看了。这种矛盾感大概很多人都有。
到了 LLM 的时代，再回过头来看这个问题，笔记和博客还有写的意义吗？
先说博客。以前我的博客更多是记录解决问题的过程——遇到一个技术问题，从网上搜集资料，自己整理出一套解法，写下来。比如一些早期的文章里就有这样的内容，那时候可能更喜欢把遇到的问题、学到的东西直接贴出来分享：
但现在，这些内容直接丢给 AI 问一句，基本就能得到答案了。那还有记录下来的必要吗？
这也是为什么我的博客里技术类文章越来越少。写得浅的没什么价值，写得深的又很吃力，而且深度内容往往还在不断迭代，也不太适合直接发出来。
再说笔记。现在让 AI 随手一 gen，它就能结构化、系统化地列出完整的知识内容。以前看到有用的东西会顺手记一下，现在本身就已经在与 AI 的交互中完成了学习，记笔记的动作也变成了让 AI 去读文档、自动总结。再加上 AI 工具已经可以直接对接 Obsidian 这类本地笔记软件，一句话就能把内容写进文档目录，做笔记的过程大大加速了。
但加速之后，这些笔记就一定会去看吗？这些在以前看来更珍贵的知识内容，现在真的更有用吗？也未必。
认真想了一下，还是有些东西值得记录：
知识的大纲与索引：具体的知识细节确实可以交给 AI 来生成，但一套属于自己的大纲、关键词索引或结构化框架，仍然有助于记忆和检索。AI 能给你答案，但你需要知道该问什么问题。
个人经历的过程记录：过程记录本质上是一种叙事（storytelling），它的价值不在于提供技术参考，而在于记录本身。作为一份属于自己的记录，它不需要”有用”，存在即可。
个人的想法与观点：尤其是带有真情实感的表达。这类内容完全属于个人，AI 无法替代生成——或者说，AI 生成的内容代表不了你自己。
归根到底，核心还是要回到“人”上面：写关于人的内容，带有人味，记录人身上真实发生的事情和真实的感受。
话虽如此，实际操作中往往还是会忍不住让 AI 来加工一遍，这样一来，“人味”可能就在加工中被稀释甚至丢掉了。
比如这篇文章，原本是我用语音输入转写的文字。想法是我自己的，内容也全是我说出来的，但它经历了至少两层加工：语音转写时，软件的 AI 模型已经做了一次调整修饰；之后觉得文本还是太口语化、结构也散，又拿去让 AI 再润色一版。
所以，即使内容原本是有“人味”的，经过 AI 的多次加工之后，还能剩下多少呢？说实话我也不确定。但我觉得，只要核心的想法和判断仍然是自己的，这个过程或许也没什么问题——毕竟，工具从来都是为表达服务的。
2026-02-26 11:50:16
最近我大量使用 Claude Code 进行 Vibe Coding，也做了不少自己的小项目和小工具。这些工具在运行时，往往会启动本地服务器来提供 Web 或 API 服务。本地调试确实很方便，但问题在于，用完之后它们并不总能被彻底关闭。
有时即使显式让它退出，进程也未必真的结束；有时直接关闭会话窗口，服务却依然在后台运行。久而久之，系统里就残留了不少 Web 服务进程，占用内存和端口。
这类残留进程会带来几个比较麻烦的问题：
在 AI Coding 场景下，AI 判断服务是否启动，通常只是简单扫描端口是否被占用。
如果某个端口早已被旧项目占用，AI 很可能误以为当前服务已经启动成功，但实际上目标进程根本没有运行。
结果就是：看起来一切正常，实际上什么都没跑起来。
当端口被占用时，AI 需要重新启动服务。但很多项目的端口是写死在配置文件中的，于是它不得不读取文件、修改端口、再运行服务。
由于每次冲突的端口都不一样，几乎每次都要改一遍配置。
这种“改端口—重启—再改端口”的循环，非常影响节奏。
如果让 AI 去“清理端口占用”，问题就更复杂了。
它通常只是扫描占用端口的进程，然后直接终止。
但 AI 并不知道哪些进程是当前项目的，哪些是你正在运行的重要服务。
一刀切式地 kill 掉，很容易误伤无辜。
基于这些困扰，我干脆写了一个小工具，用来手动、快速清理这些遗留的端口进程。
它可以一键列出所有占用端口的进程，让我自行判断并清理。
既然是日常会频繁使用的小工具，那就干脆做成命令行工具，一键调用。
于是我用 Rust 写了一个 TUI（Terminal UI）程序。从开始到完成不到一天时间，就已经开发完成，并发布到了 GitHub 和 Cargo 上。
感兴趣的话可以试试：
👉 https://github.com/yeung66/ccpclean
可以通过 cargo install 安装，或者直接下载二进制文件运行。
程序本身的逻辑非常简单：
通过父进程和命令信息，基本可以判断该服务属于哪个项目。
此外，我加入了一些简单规则，用来判断该进程是否可能由 Claude Code 或其他 AI Agent 启动，并给出一个参考评分，用来辅助判断是否值得清理。
除了默认模式，还提供了一个“宽松模式”。
因为遗留服务不仅发生在 AI 场景中。
很多时候我们在命令行启动一个服务，关闭终端后它依然在后台运行。
宽松模式会列出所有占用端口的服务，方便逐个浏览、筛选和清理。
当然，这些事情完全可以通过原生命令行工具实现，比如：
lsofnetstatsskill但当你需要频繁做这件事时，一个专门的小工具会更高效。
而且，用 Rust 写个 TUI 的体验本身也很不错。
在 AI 的加持下，从想法到可用版本几乎没有门槛。
既然能提效，又几乎不费劲，那为什么不用一个小工具呢？
