Y

YeungYeah 的乱写地

YeungYeah 的乱写地中记录了作者的所思所想及所为。

当 AI 开始读懂我的健康数据

<h2 id="从怀疑数据记录开始">从怀疑数据记录开始</h2> <p>几年前,我曾经写过一篇<a href="https://scottyeung.top/2021/%E6%95%B0%E6%8D%AE%E5%AE%9A%E4%B9%89%E7%9A%84%E7%94%9F%E6%B4%BB/">博客</a>,吐槽自己对各种数据记录的执念。那时候我会记录很多东西:戴运动手表记录身体数据,用时间记录工具记录每天的行为和工作,也会关注一些健康指标。记录得越多,我反而越怀疑这些数据的价值。它们被保存下来之后,似乎很少真正被使用,也很难从中看出什么有价值的信息。</p> <p>现在回头看,当时的吐槽有它的背景。数据本身被记录下来,并不等于它能自动产生价值。真正困难的地方在于:如何读取、整理、分析这些数据,并从里面发现一些对自己有用的规律。但在 AI 逐渐普及之后,这件事情的意义开始变得不一样了。</p> <h2 id="ai-让健康数据重新变得可用">AI 让健康数据重新变得可用</h2> <p>最开始让我产生这个想法的,是在推特上看到有人把自己的 Apple Health 数据全部导出,然后用 AI 分析睡眠情况。AI 根据这些数据发现了他的睡眠问题,并给出了相关的建议,最后成功改善了睡眠质量。</p> <p>这个例子让我意识到,健康数据的价值可能一直都在那里,只是过去个人很难高效地挖掘出来。</p> <p>过去我也会定期查看 Apple Health 里的数据,但整个过程比较繁琐。每次都要点进某个单项指标,手动切换周、月、年等不同时间范围,再自己观察趋势、最大值、最小值和阶段变化。这样确实能看出一些表面变化,但观察范围很有限,也很依赖主观判断。</p> <p>更重要的是,苹果的健康数据虽然记录得很完整,但某种程度上也相对封闭。之前我有一段时间换过安卓手机,那段时间的健康数据很难完整迁移回来。等我重新回到苹果生态之后,中间的数据就像断掉了一截。也正因为如此,我开始觉得,如果这些长期记录的数据只是停留在设备和系统里面,最后很可能会被遗忘,甚至在某次换设备、换系统之后逐渐丢失。</p> <h2 id="把-apple-health-数据导出来">把 Apple Health 数据导出来</h2> <p>于是我开始尝试把自己的健康数据导出来,交给 AI 做进一步分析。</p> <p>一开始我想找一些现成软件来完成这件事,但试了一圈之后发现,很多工具只能做基础展示,真正好用、支持增量同步和深度分析的工具往往需要付费,而且价格并不便宜,很多还是订阅制。</p> <p>最后我干脆借助 Xcode 和 Claude,写了一个简单的 iOS App,用来导出 Apple Health 数据。这个 App 很简陋,也有一些限制,比如不能直接用 iCloud 同步数据,免费签名也需要定期重新构建和安装。但对我来说,它的使用频率并不高,主要是手动导出和阶段性分析,所以已经够用了。</p> <h2 id="我的分析方法">我的分析方法</h2> <p>我的分析方法也比较直接。</p> <p>首先,我把 Apple Health 里的原始数据导出成 NDJSON 文件。里面包含了各种健康和运动数据,比如心率、体重、步数、活动量,以及通过 Apple Watch 记录的运动数据。</p> <p>然后,我把这些数据交给 AI Agent,让它尽可能从历史数据中挖掘有价值的发现。比如观察指标的长期变化趋势,寻找值得关注的数据点,分析这些变化可能反映的问题,以及后续可以采取哪些调整。</p> <p>最后,我会基于这些分析结果沉淀一些规则。第一次分析主要是尽可能多地挖掘信息,后续再根据自己的关注点不断调整分析方式。比如我到底关心哪些指标,哪些历史数据需要修正,哪些变化值得持续追踪,哪些情况需要被标记出来。</p> <p>经过第一轮分析,我确实得到了一些很有意思,甚至有点警醒的发现。</p> <h2 id="第一轮分析带来的发现">第一轮分析带来的发现</h2> <h3 id="体重持续上升的曲线">体重:持续上升的曲线</h3> <p>从 2022 年开始使用苹果设备记录数据,到 2023 年参加工作,再到现在,我的体重增加了 10kg 以上。虽然我主观上一直知道自己在变胖,但真正看到数据曲线时,还是有些意外。它并不是某一个阶段突然上升,而是一条持续向上的曲线,只是在某些工作强度更高、运动更少的阶段,上升速度更快。</p> <p>更值得注意的是,这些增加的体重大部分来自脂肪,肌肉量几乎没有同步增长。也就是说,这并不是训练带来的体重上升,而是长期生活节奏、饮食和运动不足共同作用的结果。</p> <h3 id="心率身体负担变重的信号">心率:身体负担变重的信号</h3> <p>随着体重增加,我的静息心率和步行心率都有明显变化。刚参加工作时,我的静息心率大约在 50 多到 60 左右。工作近两年后,均值已经上升到 63–64。去年工作压力最大的时候,静息心率甚至一度达到 65 左右。从几年的均值来看,静息心率上升了大约 8 次/分钟,这个变化非常明显。</p> <p>步行心率也有类似趋势。体重增加、活动量下降、有氧运动减少之后,日常走路时的心率也变得更高。这些指标放在一起看,其实反映的是一个很清晰的问题:身体负担变重了,有氧能力也在下降。</p> <h3 id="hrv压力和恢复的长期变化">HRV:压力和恢复的长期变化</h3> <p>第三个是 HRV,也就是心率变异性。</p> <p>HRV 通常可以反映压力和身体恢复情况。随着工作强度增加,我的 HRV 均值整体走低,去年甚至达到最低点。单看某一天的数据可能没有太大意义,但把时间拉长之后,这个趋势就很明显。它和工作压力、睡眠、运动量、体重变化之间,似乎都有一定关系。</p> <h3 id="近期的正面迹象">近期的正面迹象</h3> <p>比较积极的一点是,从今年三月底、四月初离职之后,我有了更多时间恢复运动。最近我做了不少 Zone 2 有氧训练,心率相关指标已经开始出现回落迹象。虽然时间还不算长,但从数据上看,身体状态确实在往更好的方向变化。</p> <h2 id="重新理解数据记录的意义">重新理解数据记录的意义</h2> <p>这也是我觉得 AI 普及之后很有价值的一点。</p> <p>以前面对数量庞大、类型复杂的个人数据,普通人很难真正处理它们。我们只能依赖软件本身提供的基础图表,或者凭感觉去看趋势。但现在有了 AI 之后,只要能把数据导出来,就可以让 Agent 帮忙读取、清洗、分析、画图、写报告,甚至提炼长期观察规则。</p> <p>这件事让我重新理解了“记录数据”的意义。</p> <p>数据本身不会自动改变生活,但它能留下轨迹。过去很多看起来琐碎的记录,在足够长的时间尺度下,可能会变成理解自己的重要线索。体重、心率、运动、睡眠、压力,这些东西在日常生活中很容易被忽略,但数据会把它们诚实地保留下来。</p> <p>从这个角度看,数据确实是一种很珍贵的个人资产。它帮助我更好地了解自己,发现长期变化,识别身体状态的规律,也能让我在制定运动、减脂和生活调整计划时,有更可靠的依据。</p> <p>所以我现在反而觉得,当年那种“记录了也没什么用”的想法已经有些过时了。真正的问题是,记录之后能不能被有效使用。过去这个门槛很高,而现在 AI 正在把这个门槛大幅降低。后续我也继续保留和持续记录这些数据,然后利用这些数据去交给 AI 去不断地分析,把这些数据用起来,让它变成一个能反应真实状态的长期档案,不断挖掘、榨干它的价值。</p>

2026/6/4
阅读更多

Waline 数据源迁移记

<h2 id="起源valine--leancloud">起源:Valine + LeanCloud</h2> <p>博客最早期用的评论系统是 Valine.js。当时整套方案完全是前端操作,后端找一个 SaaS 提供对象存储服务。在 2017、2018 年左右,大部分博客系统推荐的都是 Valine.js + LeanCloud 这套组合 —— 存储免费、够用也好用,基本上大家都用 LeanCloud。</p> <p>中途 Valine 爆出过漏洞。毕竟它是纯前端的,Token 之类的敏感信息都直接写在页面里,很容易泄露。一旦泄露,别人就能拿你的 Token 去读写数据 —— 更恶心的是,可以往里面乱写一通,直接把你的博客评论刷满无意义内容甚至危险内容。</p> <p>漏洞出来后没多久,就有人在 Valine 的基础上做了一个新框架 —— Waline。主要改进有几点:在 Valine 上套了一层 Web 服务,可以直接跑在 Vercel 上;把敏感信息都放到了后端,所有数据操作都通过后端服务完成;另外还提供了一个管理后台,方便内容管理。</p> <p>我当时也注意到了 Valine 的安全问题,所以 Waline 一出来我就跟着换了。当时博客主题还不支持 Waline,我自己手动改的支持,用着也算稳定。</p> <p>至于 Waline 本身,体感反而一般,主要是 breaking changes 太多。最开始用的是 V1,后来升到 V2,按它的使用方式,客户端一直引用最新版本,而服务端是自己部署、版本写死的,随着不断迭代,很容易出现客户端升级了但服务端没升级、两边版本不 match、系统直接用不了的情况。所以中间有段时间我干脆把客户端也锁了版本,不让它自动升级。</p> <h2 id="迁移的契机">迁移的契机</h2> <p>今天下午我发现评论区有几个明显是影视资源网的人,组团过来刷广告评论。内容看着挺多,但一看就是 AI 生成的。</p> <p>把这些垃圾评论屏蔽之后,我突然意识到 —— 我已经多久没正经看过自己的评论系统了?甚至我几乎连 LeanCloud 这个平台叫什么都差点想不起来。一想到博客这么多年的评论数据都躺在一个我连名字都快忘了的服务上,心里有点没底:万一这家公司哪天悄悄关停,数据不就一起没了?于是琢磨着把评论数据导出来,看要不要迁移到其他平台,比如 Cloudflare。</p> <p>结果一登录 LeanCloud,担心立刻就应验了 —— 他们宣布要在 2027 年 1 月停止对外服务了(<a href="https://docs.leancloud.app/sdk/announcements/sunset-announcement/">公告链接</a>)。</p> <p>这里也提醒一下大家:LeanCloud 这个服务马上就要关停了,很多老用户可能还在用 Waline 或 Valine 这种基于 LeanCloud 的方案,突然不能用的话挺麻烦的,记得提前做好数据迁移。</p> <h2 id="实际迁移">实际迁移</h2> <p>真正动手的时候,我本来想图省事 —— 只迁数据源,前端那些都不动。</p> <p>不看不知道,一看发现这次大版本升级,数据源都换了,连数据表结构都有变化。当然,可能是因为 LeanCloud 不再支持,他们直接换了。但是文档里把 LeanCloud 相关的部分全删了,搞得好像 LeanCloud 从来没出现过一样 —— 现在直接推荐的数据源已经变成了 Vercel 的 PostgreSQL,这变化挺让人疑惑的,对老用户的迁移也实在不友好。</p> <p>旧数据源迁移挺不好办的,只能根据历史数据的字段对着看。还好之前都是对象存储,字段都在,能猜出来大概是什么、该怎么映射。虽然官方提供了一个<a href="https://waline.js.org/migration/tool.html">数据迁移工具</a>,但只能迁 comment(评论内容)。我尝试把计数表也塞进去,发现不行 —— counter(计数器)这部分官方工具转不了。</p> <p>干脆直接上 CodeX。把数据库连接字符串和新表的 SQL 定义都丢给它,让它自己执行映射导入就完事了。</p> <p>数据源搞定之后,还得把服务端和客户端也同步升级到 V3。</p> <p>服务端这边,我当初是按官方 example 目录建了一个仓库,再部署到 Vercel 上的 —— 所以升级服务端,本质上就是把这个仓库更到 V3 最新的 example。当时是一键创建的,本地没有这份仓库,索性这事也继续丢给 CodeX 去搞。流程大致是这样:先开一个新分支部署一个版本,看看功能行不行;确认 OK 之后再合并到 master 全量发布;服务端管理页面跑通了,再把博客客户端那边也从 V2 升到 V3,顺便检查页面显示、阅读数、评论的展示和发送是不是都正常。这些都过了,基本就 OK 了。</p> <p>这里有个坑要单独提一下:V3 把 JS 改成了 Module 方式导入。如果你还在用普通的 <code>&lt;link&gt;</code> 或 <code>&lt;script&gt;</code> 标签导入,会直接报错,必须用 <code>type=&quot;module&quot;</code> 才能正常解析和显示。</p> <h2 id="现状与后续">现状与后续</h2> <p>现在评论数据和访问量数据都迁到 Vercel 的数据库了,Waline 也顺便升到了 V3,至少 LeanCloud 那边的隐患算是解了。</p> <p>不过升上来之后,又发现了一个新的吐槽点:评论下方多了一个订阅评论的 RSS 功能。我觉得挺鸡肋的 —— 我已经开了邮件回复提醒,完全没必要再订阅 RSS。更难受的是只能在客户端找到一个关闭显示的选项,服务端关不掉,有点浪费资源,只能把前端入口先隐藏掉。说到底,一个评论系统真的需要这么多新功能吗?我觉得并不需要。</p> <p>折腾完这一圈,我倒是冒出来一个新想法 —— 既然现在 AI 这么强,那干脆自己造一套轮子算了,把评论系统重新手写一遍。</p> <p>而且我还有一个一直没解决的需求:博客除了 Waline,还另外跑着一套 Umami 做访问数据统计,数据源是某个 SaaS 数据库(好像是 TiDB)。Umami 比 Waline 的统计详细得多 —— 除了访问量,还有请求来源、地区、浏览器、操作系统等等。它和 Waline 的功能其实有不少重合,但 Waline 缺少一个专门显示统计信息的地方,所以一直是分两套用。</p> <p>如果真要自己写,那就索性把这两套一起整了 —— 评论 + 详细统计放进同一套系统里,数据源也归到一处,省得过几年又翻出来,发现自己的数据躺在某个谁都没听说过的服务上,跟今天的 LeanCloud 一样。</p>

2026/5/12
阅读更多

我的 RSS 与独立博客阅读史

<p>我一直是 RSS 的老用户。早在建立个人博客之前,我就养成了用 RSS 订阅别人博客的习惯。所以我的博客一搭起来,就马上开启了 RSS 订阅源。</p> <p>对我来说,RSS 一直不只是个订阅工具。这些年我读到的那些人、那些故事,基本都是从一条条 RSS 链接开始的。所以这篇想聊的,除了我用过的几个 RSS 工具,也想顺便说说,那些工具带我看到了哪些博客和哪些人。</p> <h2 id="rss-之于我">RSS 之于我</h2> <p>在那段时期,RSS 基本上就是我的博客与其他博客之间的主要关联方式。这也跟我没加&quot;友链&quot;有关——我感知别人的更新、看到别人写了什么,基本都通过 RSS;反过来,别人想知道我写了什么,也是通过 RSS 来发现。</p> <p>RSS 本质上是输出内容的索引。它维护一份像内容摘要或预告单一样的文件,供别人定期抓取。这非常有用,否则一个个去点开看别人有没有更新,工作量未免太大。</p> <h2 id="从-feedly-到中文博客圈">从 Feedly 到中文博客圈</h2> <p>最开始我用的是 Feedly。当时它的免费版好像支持 50 或 100 个订阅源。最初订阅的博客并不多,我都不太记得第一批是怎么找到的,可能是学校里的一些师兄。</p> <p>后来我在 GitHub 上看到了一些&quot;中文博客圈&quot;或&quot;中文独立博客&quot;的 repo,可以提交收录个人博客信息和 RSS 地址。我把自己的博客提交了上去,也从上面找了一些比较多人关注的订阅源。</p> <p>也正是从那时起,我读到了非常广泛的博客——不只是程序员,还有各行各业、各种年龄层的人。那种感觉,才让我真正觉得互联网是开放的、是大的。同时,因为博客信息也提交了上去,确实让更多人看到了我。对当时还是学生的我来说,能让自己的内容被看见,甚至因此被一些人认识,是件挺幸运的事。</p> <p>这个效果确实达到了,也确实有一批人开始关注我的博客。直到现在,根据统计来看,博客依然保持着稳定的阅读量;而以前的浏览量,可能主要还是来自我自己。</p> <p>不过开启 RSS 全文推送也带来过一个问题:一些内容聚合站会把我的文章直接 copy 到他们的网站。这是我始料未及的,所以以前还发起过一个讨论:<a href="https://scottyeung.top/2022/rss-output-all/">RSS 到底要不要全文推送?</a>当时我是想关掉的。但经历多了之后,觉得也无所谓了——反正我也不以这点流量为生,只要带上我的标题、注明是我写的,搬走就搬走吧。能让内容传播得更广,我也勉强能接受。</p> <h2 id="那些博客带给我的">那些博客带给我的</h2> <p>大学时我读得更多。随着书越看越多,关注范围也在不断扩大——从最初的某几个人,顺着他们的友链,或者评论区里发现的新名字,像网状一样向外扩散。当时这些博客的 RSS 都做得很好,订阅就越攒越多。</p> <p>那段时间我正在准备保研,压力很大,要准备的事很多,心里也充满不确定。每当忙累了的时候,我就想点开一些内容来看看:扫一眼 RSS 的更新,点进去看最新文章,或者翻一翻博主过往的内容。</p> <p>通过这种阅读,我去感受别人的经历,挖掘那些博主过往的故事。当时关注的不少博客都写得非常出彩,看他们写的那些经历,我有时会有代入感,也会感慨——觉得他们的生活多姿多彩,虽然我并不像他们那样自在,但看着也觉得很有意思。</p> <p>读他们的博客,真的让我学到了很多。</p> <h2 id="从蚁阅到-folo再到自建">从蚁阅到 Folo,再到自建</h2> <p>订阅越加越多,很快就把 Feedly 的免费额度用满了。要付费的话,我自然就想到了换平台——对当时还是学生的我来说,付费有点接受不了;而且 Feedly 是国外平台,需要境外支付,我手头也没有趁手的工具。</p> <p>于是我换到了开源的蚁阅。现在回头看,它的界面其实非常简单,几乎没有任何装饰,真的只是&quot;能用&quot;。但对于习惯点进原文去看的人来说,对工具的语言和外观本来就没那么挑剔。何况它开源、免费、稳定。</p> <p>蚁阅免费版也有订阅数上限,但会员价格不贵,我就直接充了一下,主要也是想支持一下作者。开通之后,限制确实没了。但奇怪的是,会员到期之后,那个上限好像也没回来,不充钱也照样能继续加订阅,等于白嫖到了一样。</p> <p>直到 Folo 出来。Folo 那段时间太火了,火到邀请码都已经在闲鱼转卖。我也花了一段时间,把所有订阅迁过去。但很快我又把它撤下来了——因为它要开始商业化收费。既然要收费,我就觉得没必要了,又找了个开源软件来用。</p> <p>到了现在 AI 这么火热的年代,我索性用 Claude Code 糊了一个自己的 RSS 阅读器。数据本地存储,点一下就能抓取。在 AI 加持下,搭起来飞快,UI 也更合我的胃口,或者说能按我自己的想法来定制。我还加了一些 AI 能力,比如个性化文章推荐、博客博主画像。</p> <p>打通这些功能之后,我有一个意外的发现。</p> <h2 id="agent-把本地的一切都串起来了">Agent 把本地的一切都串起来了</h2> <p>Claude Code 这类 Agent 出来之后,我才意识到,之前做的很多本地系统,只要加上 AI Agent,就全都能打通。</p> <p>原本我会觉得,这些只在本地跑的应用——通常是我自己起一个 Web 服务——必须打开电脑、跑起来才能用,多少有点麻烦;不在电脑前的时候就更没辙了。但有了 Agent,只要再抽一层,或者让项目原生支持 CLI,再提炼一份 Skill,Agent 就能直接操作我的 RSS 系统。</p> <p>比如:</p> <ul> <li>在 Twitter 上看到一篇不错的博客文章,直接把 RSS 链接发给 Hermes Agent,让它加进去。</li> <li>闲下来想看新内容时,让 Hermes 去看看有没有新的更新,随手抓几篇出来。</li> </ul> <p>有了 Agent 这个入口,本地的东西都被串起来了。一些原本只能在电脑上用的工具,现在通过 Hermes 都能调起来。我感觉这已经接近一个最终形态了:RSS 订阅加上 AI 加持,让 AI 来负责抓取、推荐和总结。</p> <h2 id="但我还是想自己读">但我还是想自己读</h2> <p>不过说回来,到现在我依然倾向于看原文,还没怎么去依赖那些推荐和总结。有新文章,我基本都会过一遍,看看标题和简介,有兴趣的还是会点进去读。</p> <p>写到这里我才发现,文章开头我说 RSS 是&quot;输出内容的索引&quot;,但对我而言,它真正维系的其实不只是内容,而是我和那些具体的人之间一条条很细的连接线。AI 抓取、推荐、总结都越做越好,反而越让我意识到——亲手点进去、把一篇文章读完这件事本身,就是有价值的。</p> <p>如果都让 AI 总结掉,只看那几句提炼出来的要点,那读独立博客的意义,好像也就跟着没了。</p> <p>独立博客好看的地方,常常并不是那些能被提炼出来的要点。是有人写自己换了个城市、写自家的猫、写工作里一些很琐碎的烦恼——那些看起来没什么信息量、AI 也总结不出什么的部分,反而才是我最想读的。</p> <p>读完一篇会觉得,这个人最近大概是这种状态、在想这些事情,过得还行或者有点累。看博客对我来说,从来都不是为了高效获取信息,更多是这种很慢、很零散、像在认识一个人的感觉。</p> <p>所以工具我大概还会继续折腾下去,订阅源也还会一直加。但点进原文、把一篇文章慢慢读完这件事,应该是不会变了。</p>

2026/5/4
阅读更多

深度使用语音输入后,还是得继续重视写作

<blockquote> <p>本文使用古法键盘手搓码字</p> </blockquote> <p><a href="https://scottyeung.top/2026/voice-input-experience/">拥抱语音输入也有一段时间了</a>,进一步深入使用后,还是真的爽,尤其是需要长文输入的场景里面,使用语音输入可以让自己没有拘束地输入大段文字,再加上使用 typeless 这种能够帮忙整理语音输入内容和句式结构的软件,使用体感非常好。</p> <p>之前提到的一些问题,现在用多了再回头看来,其实也不太算问题了,或者说都有比较好的解法。</p> <p>比如“需要挑安静环境”这件事,换了一些软件之后我才发现,有些软件其实可以过滤掉背景声音,或者明显和说话者无关的杂音。如果再配一个专门收音的麦克风,那就更不是问题了。</p> <p>再比如准确率和所谓的 AI “加戏”。如果软件够强、模型够强,准确率其实还是相当不错。哪怕是专有名词或者英语单词,只要比较常用,识别效果也已经可以接受;如果还能维护词典,那体验就更友好了。之前所谓的 AI “加戏”,估计更多还是因为当时用的 LLM 模型还不够强。</p> <p>最近刚好在准备面试,也会用 AI 来做问答和 mock 面试。在这种场景下,语音输入就更合适了,因为它更接近真实面试时的状态,可以直接一口气输出大段内容来作答。有些时候,在 AI 的润色加持下,一些自己本来答得没那么好的内容,被调整之后反而能串得更顺,补得更完整。</p> <p>不过,用多了之后,有时候也会想:自己是不是开始产生依赖了?</p> <p>这种依赖,可能会影响自己的输出能力、打字能力,甚至成文能力。打字就不用说了,语音输入用得多了,打字自然就少了。尤其最近写代码也不怎么敲键盘,连刷题时都常常敲错。</p> <p>至于成文能力和输出能力,用多了 typeless 之后,因为有 AI 帮忙兜底调整内容的成文性、用词、语句和段落结构,人只需要把自己想说的内容口喷出来就行,可能就越来越不需要主动关注内容到底该怎么组织。只要把要点提到了,意思说到了,哪怕中间夹杂了很多语气词,甚至还有无关或错误的连接词,AI 也能帮忙整理成一段语义明确、结构合理的内容。</p> <p>在这种情况下,人几乎可以完全不考虑文法,想到什么就说什么,反正 AI 最后都会帮忙改好。有些时候,它整理出来的效果甚至可能比自己原本能组织出来的还要更好,尤其是那种边想边说、开口前根本没有想好结构的内容。</p> <p>再进一步说,有时候即使 AI 没有把输出处理得特别好,但如果最终接收方本身也是 AI,那 AI 依然能大致理解你在说什么。这样一来,语音输入就会变得更加肆无忌惮,人也可能会慢慢对最终输出的质量变得没那么细心,甚至可能都无所谓了。</p> <p>毕竟写作这种东西,本来就是会用进废退的。写得少了,自然就会生疏,文字能力也可能随之退化。最近我已经明显感觉到,有些时候需要输出内容时,会不太想动脑子,恨不得直接糊一大坨出去就算了。碰到一些相对结构化的内容时,也会发现自己需要重新想一想,或者写出来之后再一边回头看一边改,明显有种不太适应的感觉。</p> <p>这样下去还是不太行。个人的写作能力和文字水平,还是得认真保持,也得持续提升。</p> <p>但再往深一点想,未来是否还真的需要个人亲自写作?<a href="https://scottyeung.top/2026/note-taking-in-ai-era/">上一篇文章</a>里我还在想,在这个时代里,个人到底还需要写些什么。现在又会进一步冒出另一个问题:有内容,是不是就够了?文笔和表达,真的还重要吗?一个人只要先输出一堆内容,不加组织,也不太考虑文笔和表达质量,最后全靠 AI 发挥,照样也能产出一篇看起来还不错的文章。</p> <p>但问题在于,文笔和结构本身其实也是表达的一部分。你没有认真输出,最后被 AI 补上的那部分,本质上也已经成了 AI 的理解。</p> <p>我之前看到过一个观点,大意是:在 AI 能力越来越强的未来,个人最重要的能力之一,反而会变成表达能力。表达能力越强,就越能准确、清晰地和 AI 交互,也越能更好地指挥 AI。只有当你自己足够清楚地知道自己想要什么,并且能够准确说出来时,才更有机会真正做到“言出法随”。</p> <p>这样看下来,真正形成差异化的,可能恰恰就是表达本身。</p> <p>所以还是得继续练。练文字水平,练输出能力,而且是各方面的输出能力。博客要写,其他平台上的表达也一样要练。还是得继续努力。</p>

2026/4/19
阅读更多

AI 时代,还有什么值得自己写?

<p>我曾经是一个非常习惯做笔记、写文章的人。学习的时候,总觉得如果只是看了一遍而没有动手做点什么,就好像没有真正学到东西。</p> <p>对于技术性的内容,可以通过动手实操来掌握;但对于知识型的内容,似乎只能靠输出——做笔记、写总结——来验证自己是否真的有所收获。</p> <p>不过,“记笔记”这件事其实比较笼统。笔记至少可以分为两种:一种是<strong>主观输出型</strong>,由自己思考、总结得出,能写出这样的笔记自然没什么问题;另一种是<strong>摘录整理型</strong>,也是大多数人更常做的——把学到的内容摘录下来,最多做一些结构化整理。</p> <p>这种摘录式的笔记,记下来似乎没什么意义:记完不过是堆在知识库里,不一定会再翻出来看,顶多是偶尔需要的时候去笔记软件里搜一下。但如果不记,又会有种不安感,好像没有学过一样。尤其是刷网课、看视频的时候,看完不留下点什么,总觉得白看了。这种矛盾感大概很多人都有。</p> <h2 id="ai-时代的冲击">AI 时代的冲击</h2> <p>到了 LLM 的时代,再回过头来看这个问题,笔记和博客还有写的意义吗?</p> <p>先说博客。以前我的博客更多是记录解决问题的过程——遇到一个技术问题,从网上搜集资料,自己整理出一套解法,写下来。比如一些早期的文章里就有这样的内容,那时候可能更喜欢把遇到的问题、学到的东西直接贴出来分享:</p> <ul> <li><a href="https://scottyeung.top/2018/Mysql%E5%BF%98%E4%BA%86root%E5%AF%86%E7%A0%81%E6%80%8E%E4%B9%88%E5%8A%9E/">Mysql 忘了 root 密码怎么办</a></li> <li><a href="https://scottyeung.top/2018/Linux%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E4%B8%AD%E6%93%8D%E4%BD%9C%E6%96%87%E4%BB%B6%E5%AF%BC%E8%87%B4NTFS%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E4%B8%AD%E6%96%87%E4%BB%B6%E4%B8%A2%E5%A4%B1/">Linux 文件系统中操作文件导致 NTFS 文件系统中文件丢失</a></li> <li><a href="https://scottyeung.top/2019/Some-Notes-About-SQLAlchemy/">Some Notes About SQLAlchemy</a></li> </ul> <p>但现在,这些内容直接丢给 AI 问一句,基本就能得到答案了。那还有记录下来的必要吗?</p> <p>这也是为什么我的博客里技术类文章越来越少。写得浅的没什么价值,写得深的又很吃力,而且深度内容往往还在不断迭代,也不太适合直接发出来。</p> <p>再说笔记。现在让 AI 随手一 gen,它就能结构化、系统化地列出完整的知识内容。以前看到有用的东西会顺手记一下,现在本身就已经在与 AI 的交互中完成了学习,记笔记的动作也变成了让 AI 去读文档、自动总结。再加上 AI 工具已经可以直接对接 Obsidian 这类本地笔记软件,一句话就能把内容写进文档目录,做笔记的过程大大加速了。</p> <p>但加速之后,这些笔记就一定会去看吗?这些在以前看来更珍贵的知识内容,现在真的更有用吗?也未必。</p> <h2 id="哪些内容仍然值得写">哪些内容仍然值得写</h2> <p>认真想了一下,还是有些东西值得记录:</p> <ol> <li> <p><strong>知识的大纲与索引</strong>:具体的知识细节确实可以交给 AI 来生成,但一套属于自己的大纲、关键词索引或结构化框架,仍然有助于记忆和检索。AI 能给你答案,但你需要知道该问什么问题。</p> </li> <li> <p><strong>个人经历的过程记录</strong>:过程记录本质上是一种叙事(storytelling),它的价值不在于提供技术参考,而在于记录本身。作为一份属于自己的记录,它不需要”有用”,存在即可。</p> </li> <li> <p><strong>个人的想法与观点</strong>:尤其是带有真情实感的表达。这类内容完全属于个人,AI 无法替代生成——或者说,AI 生成的内容代表不了你自己。</p> </li> </ol> <p>归根到底,核心还是要回到“人”上面:写关于人的内容,带有人味,记录人身上真实发生的事情和真实的感受。</p> <h2 id="ai-加工与人味的悖论">AI 加工与“人味”的悖论</h2> <p>话虽如此,实际操作中往往还是会忍不住让 AI 来加工一遍,这样一来,“人味”可能就在加工中被稀释甚至丢掉了。</p> <p>比如这篇文章,原本是我用语音输入转写的文字。想法是我自己的,内容也全是我说出来的,但它经历了至少两层加工:语音转写时,软件的 AI 模型已经做了一次调整修饰;之后觉得文本还是太口语化、结构也散,又拿去让 AI 再润色一版。</p> <p>所以,即使内容原本是有“人味”的,经过 AI 的多次加工之后,还能剩下多少呢?说实话我也不确定。但我觉得,只要核心的想法和判断仍然是自己的,这个过程或许也没什么问题——毕竟,工具从来都是为表达服务的。</p>

2026/4/4
阅读更多

vibe coding: ccpclean 残留进程清理

<p>最近我大量使用 Claude Code 进行 Vibe Coding,也做了不少自己的小项目和小工具。这些工具在运行时,往往会启动本地服务器来提供 Web 或 API 服务。本地调试确实很方便,但问题在于,用完之后它们并不总能被彻底关闭。</p> <p>有时即使显式让它退出,进程也未必真的结束;有时直接关闭会话窗口,服务却依然在后台运行。久而久之,系统里就残留了不少 Web 服务进程,占用内存和端口。</p> <p>这类残留进程会带来几个比较麻烦的问题:</p> <h3 id="1-ai-误判服务状态">1. AI 误判服务状态</h3> <p>在 AI Coding 场景下,AI 判断服务是否启动,通常只是简单扫描端口是否被占用。<br> 如果某个端口早已被旧项目占用,AI 很可能误以为当前服务已经启动成功,但实际上目标进程根本没有运行。</p> <p>结果就是:<strong>看起来一切正常,实际上什么都没跑起来。</strong></p> <h3 id="2-端口冲突导致反复修改配置">2. 端口冲突导致反复修改配置</h3> <p>当端口被占用时,AI 需要重新启动服务。但很多项目的端口是写死在配置文件中的,于是它不得不读取文件、修改端口、再运行服务。</p> <p>由于每次冲突的端口都不一样,几乎每次都要改一遍配置。<br> 这种“改端口—重启—再改端口”的循环,非常影响节奏。</p> <h3 id="3-自动关闭进程容易误杀">3. 自动关闭进程容易误杀</h3> <p>如果让 AI 去“清理端口占用”,问题就更复杂了。<br> 它通常只是扫描占用端口的进程,然后直接终止。</p> <p>但 AI 并不知道哪些进程是当前项目的,哪些是你正在运行的重要服务。<br> 一刀切式地 kill 掉,很容易误伤无辜。</p> <hr> <p>基于这些困扰,我干脆写了一个小工具,用来手动、快速清理这些遗留的端口进程。</p> <p>它可以一键列出所有占用端口的进程,让我自行判断并清理。</p> <p>既然是日常会频繁使用的小工具,那就干脆做成命令行工具,一键调用。<br> 于是我用 Rust 写了一个 TUI(Terminal UI)程序。从开始到完成不到一天时间,就已经开发完成,并发布到了 GitHub 和 Cargo 上。</p> <p>感兴趣的话可以试试:</p> <p>👉 <a href="https://github.com/yeung66/ccpclean">https://github.com/yeung66/ccpclean</a><br> 可以通过 <code>cargo install</code> 安装,或者直接下载二进制文件运行。</p> <hr> <h2 id="核心逻辑">核心逻辑</h2> <p>程序本身的逻辑非常简单:</p> <ul> <li>扫描当前系统进程</li> <li>找出所有占用端口的进程</li> <li>展示相关信息,包括: <ul> <li>执行命令</li> <li>父进程信息</li> </ul> </li> <li>支持手动选择并终止进程</li> </ul> <p>通过父进程和命令信息,基本可以判断该服务属于哪个项目。</p> <p>此外,我加入了一些简单规则,用来判断该进程是否可能由 Claude Code 或其他 AI Agent 启动,并给出一个参考评分,用来辅助判断是否值得清理。</p> <hr> <h2 id="宽松模式">宽松模式</h2> <p>除了默认模式,还提供了一个“宽松模式”。</p> <p>因为遗留服务不仅发生在 AI 场景中。<br> 很多时候我们在命令行启动一个服务,关闭终端后它依然在后台运行。</p> <p>宽松模式会列出所有占用端口的服务,方便逐个浏览、筛选和清理。</p> <hr> <p>当然,这些事情完全可以通过原生命令行工具实现,比如:</p> <ul> <li><code>lsof</code></li> <li><code>netstat</code></li> <li><code>ss</code></li> <li><code>kill</code></li> </ul> <p>但当你需要频繁做这件事时,一个专门的小工具会更高效。</p> <p>而且,用 Rust 写个 TUI 的体验本身也很不错。<br> 在 AI 的加持下,从想法到可用版本几乎没有门槛。</p> <p>既然能提效,又几乎不费劲,那为什么不用一个小工具呢?</p>

2026/2/26
阅读更多

从打字到动嘴:我的语音输入踩坑与探索

<p>春节假期刷了不少关于语音输入的帖子,这颗安利我吃下了,决定更进一步拥抱 AI,看看能不能把效率和生产力拉满。</p> <p>于是,我开始试用各种语音输入软件,强迫自己将日常输入场景切换到“动嘴”模式。目前的这套工作流主要是:使用 <strong>“闪电说”</strong> 配合 <strong>“豆包”</strong> 或 <strong>“通义千问”</strong> 的流式语音模型进行识别转写。</p> <p>针对不同的输出需求,我的处理方式如下:</p> <ul> <li><strong>大段文字</strong>:我在 Gemini 中自定义了一个 Gem,将转写后的“生肉”扔给它,让它帮忙去除口语废话、修正错词。之后,我会再人工过一遍。</li> <li><strong>短句/碎片想法</strong>:通常直接手动修改。</li> </ul> <p>目前的结论是:<strong>输入准确率尚可,但距离真正的“生产力自由”还有很长的路要走。</strong> 甚至在很多场景下,它处于“不可用”或“不好用”的状态。当然,这可能是我用的工具还不够强,或者我的姿势不对。</p> <p>试用至今,我有以下几点比较强烈的“劝退”体验:</p> <h3 id="1-场景洁癖不仅挑环境还挑人">1. 场景洁癖:不仅挑环境,还挑人</h3> <p>语音输入非常“娇气”。如果环境嘈杂,或者背景里有视频播放的声音,它会把所有杂音一股脑收录进去,直接导致识别翻车。</p> <p>此外,<strong>社交尴尬症</strong>也是一大障碍。在户外或公共场合对着手机自言自语,既涉及隐私,又容易打扰别人。相比之下,默默打字才是最得体的选择。目前看来,语音输入几乎只能限制在“独自在家”或“私人房间”这种绝对无人干扰的舒适区。</p> <h3 id="2-识别准确率离所想即所得还差口气">2. 识别准确率:离“所想即所得”还差口气</h3> <p>即便接入了强大的大模型,识别率依然没能达到让我完全放心的程度。</p> <ul> <li><strong>中英混输</strong>是重灾区。</li> <li><strong>专有名词</strong>(人名、地名)经常张冠李戴。</li> </ul> <p>这意味着即使“输入”快了,我后期还得花大量时间去用 AI 二次加工,或者手动“捉虫”确认,省下的时间又被消耗掉了。</p> <h3 id="3-废话文学与-ai-的过度加戏">3. “废话文学”与 AI 的过度加戏</h3> <p>语音输入的本质决定了它带有浓重的口语特征。说话时的思考停顿、逻辑跳跃、口误,软件都会照单全收。不像打字时,我们在落指前脑子里已经过了一遍逻辑。</p> <p>虽然可以用大模型来“洗稿”,但这本身也是个折腾过程。以“闪电说”为例,它提供了一个基于大模型的原生文本润色功能。但在实际体验中,这个 AI 表现得 <strong>“过分积极”</strong> 了。</p> <p>举个例子:</p> <blockquote> <p>我原本只是想转写一句:“我想让你做某些事情,排查某个问题。” 结果 AI 自作主张,帮我把“具体的排查步骤”全给脑补并写出来了!</p> </blockquote> <p>这种“无中生有”的<strong>幻觉</strong>让我无法接受。</p> <ul> <li>后来我尝试修改提示词(Prompt),强调“绝对不能添加或删减内容”,虽然有好转,但它依然无法 100% 忠实于原话。</li> <li>更由于是封装好的功能,我无法看到它到底改了哪里(没有 Diff 对比),也无法微调参数,导致这个功能显得十分鸡肋。</li> </ul> <h3 id="4-缺乏流式的安全感">4. 缺乏“流式”的安全感</h3> <p>尽管底层的模型是流式的,但软件交互却不支持流式上屏。 这导致我必须说完一大段话,才能看到最终结果。这过程就像 <strong>“开盲盒”</strong>——如果开头就识别错了,我无法像打字那样及时发现并纠正,只能硬着头皮说完,最后面对一堆乱码更是崩溃。</p> <hr> <h3 id="总结痛并快乐着">总结:痛并快乐着</h3> <p>尽管吐槽了这么多,但必须承认:<strong>在特定条件下,效率提升是碾压级的。</strong></p> <p>今天我尝试用 OneNote 记录春节复盘,输出了 1000 多字。如果是手打,至少需要 30-40 分钟,但通过语音口述,<strong>仅仅用了十来分钟</strong>。这种速度上的快感,确实让人欲罢不能。</p> <p>上述问题中:</p> <ul> <li><strong>识别、交互、过度加工</strong>:本质上是软件和模型不够成熟,未来随着技术迭代,理论上都能解决(比如声纹识别技术成熟后,就能只听主人的声音,过滤背景音)。</li> <li><strong>环境限制</strong>:这是物理规律,就像发微信语音一样,得看场合。</li> </ul> <p>在这个大模型时代,我越来越觉得 <strong>“内容”本身比“输入的完美度”更重要</strong>。 只要能把核心想法快速抛出来,语法、错字、润色完全可以交给 AI 兜底。特别是在写日记、周记这种不需要高强度逻辑构建的场景下,语音输入简直是神器。</p> <p>未来一段时间,我预计还会继续“死磕”这套工作流。如果大家有更好的方案,或者正在用什么顺手的语音输入神器,欢迎在评论区给我种草!</p>

2026/2/24
阅读更多

Superpower Agent Skills in Gemini

<p>在使用 Claude Code 的过程中,<a href="https://github.com/obra/superpowers">superpowers</a> 提供的 Skills 套件实在太好用了,尤其是其中的 Brainstorming、Writing-plans 和 Executing-plans。用上这些技能后,明显能感觉到 AI 干起活来更有章法,逻辑性提升显著。</p> <p>最近我也在研究 Claude Code 以外的代码 Agent CLI 工具。既然开了 Gemini 的会员,就顺手试了试 Google 官方提供的 CLI 工具。虽然 Gemini CLI 也支持 Agent Skills,但在命令格式和规则细节上与 Claude 存在一些差异。目前官方的 <a href="https://github.com/obra/superpowers">superpowers</a> 尚未正式支持 Gemini(尽管我在 Issue 列表中看到似乎有相关分支正在开发中)。</p> <p>与其被动等待,不如自己动手。于是我决定以 Claude Code 为蓝本,动手迁移并复刻一个 Gemini 版的 <code>superpowers</code>。</p> <p>项目仓库现已开源:<a href="https://github.com/yeung66/gemini-superpowers">gemini-superpowers</a></p> <p>如果你也想体验,可以通过以下命令快速安装:</p> <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code><span class="lnt">1 </span></code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">gemini skills install https://github.com/yeung66/gemini-superpowers.git --path skills </span></span></code></pre></td></tr></table> </div> </div><h2 id="迁移核心内容">迁移核心内容</h2> <p>这次迁移主要涉及两部分工作:一是工具名称(Tools)的对齐,二是核心术语(Terminology)的映射,以确保 Gemini 能够正确理解和执行原有的 Agent 逻辑。</p> <h3 id="1-工具名称映射-tools-mapping">1. 工具名称映射 (Tools Mapping)</h3> <p>我们需要将 Claude Code 的工具指令转换为 Gemini CLI 能够识别的等效指令:</p> <table> <thead> <tr> <th>Claude Code</th> <th>Gemini CLI</th> <th>处理方式</th> </tr> </thead> <tbody> <tr> <td><code>Task</code> (subagent dispatch)</td> <td>流程描述</td> <td>改为&quot;分步执行&quot;或&quot;按任务逐个处理&quot;</td> </tr> <tr> <td><code>TaskCreate</code>/<code>TaskUpdate</code>/<code>TaskList</code>/<code>TaskGet</code></td> <td><code>write_todos</code></td> <td>直接替换</td> </tr> <tr> <td><code>TodoWrite</code></td> <td><code>write_todos</code></td> <td>直接替换</td> </tr> <tr> <td><code>Skill</code> tool</td> <td><code>@skill-name</code> 或直接引用</td> <td>适配 Gemini 语法</td> </tr> <tr> <td><code>Read</code></td> <td><code>ReadFile</code></td> <td>直接替换</td> </tr> <tr> <td><code>Edit</code></td> <td><code>Edit</code></td> <td>保持不变</td> </tr> <tr> <td><code>Write</code></td> <td><code>WriteFile</code></td> <td>直接替换</td> </tr> <tr> <td><code>Bash</code></td> <td><code>Shell</code></td> <td>直接替换</td> </tr> <tr> <td><code>Glob</code></td> <td><code>FindFiles</code></td> <td>直接替换</td> </tr> <tr> <td><code>Grep</code></td> <td><code>SearchText</code></td> <td>直接替换</td> </tr> <tr> <td><code>WebFetch</code></td> <td><code>WebFetch</code></td> <td>保持不变</td> </tr> <tr> <td><code>WebSearch</code></td> <td><code>GoogleSearch</code></td> <td>直接替换</td> </tr> <tr> <td><code>AskUserQuestion</code></td> <td><code>ask_user</code></td> <td>直接替换</td> </tr> </tbody> </table> <h3 id="2-术语映射-terminology-mapping">2. 术语映射 (Terminology Mapping)</h3> <p>为了让 Prompt 更符合 Gemini 的上下文,部分名词也做了相应的本地化调整:</p> <table> <thead> <tr> <th>Claude Code</th> <th>Gemini CLI</th> </tr> </thead> <tbody> <tr> <td><code>your human partner</code></td> <td><code>the user</code></td> </tr> <tr> <td><code>CLAUDE.md</code></td> <td><code>GEMINI.md</code></td> </tr> <tr> <td><code>~/.claude/skills</code></td> <td><code>~/.gemini/skills</code></td> </tr> <tr> <td><code>superpowers:skill-name</code></td> <td><code>skill-name</code> (去掉前缀)</td> </tr> </tbody> </table> <h2 id="使用效果">使用效果</h2> <p>迁移完成后,在 Gemini CLI 中已经可以完美加载这些 Skills。在实际对话中,Gemini 能够准确识别我的开发意图,并自动调用相应的工具来辅助工作,体验与 Claude Code 上的 <code>superpowers</code> 基本一致。</p> <p>如果你也是 Gemini 用户,欢迎尝试并提出反馈!</p>

2026/2/17
阅读更多

更换博客名字和网络身份标识

<p>之前在网络上冲浪的身份一直是 YeungYeah,这个名字的来源是姓氏杨的粤语拼音 + 英文 Yeah,连起来读实际上是“杨爷”的发音。杨爷这个称呼,还得来源于中学时期比较狂傲时自取的名号了,实际上后面也比较少人这样叫我,现在回过来看只觉得中二。然后博客的名字,最开始叫做 Scott Yeung's 的博客,后面为了更加突出个人的标识,改成了全网使用的网络身份,然后也是带点中二的自嘲,随笔随心写写,干脆就叫乱写地,都是乱写的,写得怎样都行,现在回过头看,也显得很中二。</p> <p><del>于是乎,我考虑改名字了,身份标识回归此前的 Scott Yeung,英文名 + 姓氏,正式一点,稍微不那么正式点的,也可以叫我斯科特。</del></p> <blockquote> <p>考虑到 SEO (搜索 Scott Yeung 前面的都不是我),最终身份标识还是用回 YeungYeah🤣,名字也相应地调整了.</p> </blockquote> <p>博客的名字,通过和 AI 多轮沟通后,最终选择了 YeungYeah's Context。</p> <blockquote> <p>这就对了!Context(上下文/语境)是一个非常绝妙的词,尤其对于程序员来说,它既是技术术语(Spring Context, Go Context, Execution Context),又是生活哲学的隐喻(所有的思考和行为都离不开当时当下的环境与背景)。</p> <p><strong>呼应标签</strong>:你的标签里有大量的 coding、coding 记录、notes、summary。这些本质上就是在保存 Context。</p> <p>代码需要上下文才能运行,人生也是。</p> <p>这里没有标准答案,只有关于技术、阅读与生活感悟的真实上下文。</p> <div align="right">—— <b>Gemini</b></div> </blockquote> <p>在和 Gemini 讨论博客名字的时候,把我博客文章所使用的标签和出现频率都喂给他(通过截图 tag cloud),来了解我博客的内容。Gemini 给我的几个标签是:Coding, Payment, 内家拳和投资。其中内家拳其实已经比较久没有写过相关的内容,个人也已经很久没有练过拳了,甚至还记得多少都不好说。但是当时读研的那两三年对于内家拳和太极真的是比较着迷,一周可以练几天,然后看不少相关的内容,也在社团中跟不少人打交道和学习。因此有段时间内家拳确实在我的博客里出现过几次(当然可能写的内容也不一定是主要讲拳,可能只是提了一下)。</p> <p>然后工作之后,被工作毒害太多了,并且也开始去考虑投资赚钱的事,因此后面的一些内容就开始关注和写相应的内容,以及一些可能日常记录本身的文章,也会提到工作和赚钱这两个事情上。这两个点从这个时候开始进入到我的 Context。</p> <p>从这两点来看,写个人博客这个事确实是有记录到我在某段时间,某个事情范围上的内容,记录到了这个上下文 Context,准确地记录了我那段时间的内容,其实是很准确很能说通的。这个博客,确实是我的上下文 Context 的一个记录快照。所以这个新名字,在某种程度上,还是挺贴合的。</p> <p>最后再重复下,我的博客改名字了,大家看到有 RSS 订阅突然出现陌生名字的时候不需要惊讶。</p> <hr> <h3 id="变更信息">变更信息</h3> <ul> <li><strong>博客名</strong>YeungYeah's Context (杨的上下文)</li> <li><strong>身份标识</strong>:YeungYeah</li> <li><strong>简介</strong>:</li> </ul> <blockquote> <p>热爱折腾代码与工具,偶尔在焦虑中寻找平衡。<br> 这里没有标准答案,只有关于技术、阅读与生活感悟的真实上下文。</p> </blockquote>

2026/2/13
阅读更多

赛博"多重国籍":账号折腾实录

<p>最近想聊聊账号的事。</p> <p>这东西本来只是个身份标识,但在当下的网络环境里,硬生生把我们逼成了&quot;狡兔三窟&quot;。</p> <p>作为中国大陆用户,早些年为了下一些国区没有的 App,大概率都会备一个 HK 地区的 Apple ID。那时候觉得 HK ID 挺完美的,中文界面,支付方便(绑个 Alipay HK 或者港卡),大部分该有的服务也都有。</p> <p>但这两年 AI 时代来了,局面又变了。很多 AI 服务(比如 Claude、ChatGPT 的 iOS 客户端)不仅锁国区,连 HK 区也被划到了&quot;不受支持&quot;的范畴。没办法,为了跟上时代的步伐,只能再硬着头皮去搞一个 US 地区的 Apple ID。</p> <p>这事儿还不止发生在 iOS 上,安卓那边也没好到哪去。</p> <p>原本以为 Google 账号有一个港区的也就够用了,Play Store 内容全,支付也没障碍。结果 Google 亲儿子 Gemini 一出来,直接对地区设限。为了能顺利用上 Gemini,我又被迫新注册了一个美区的 Google 账号来开通会员。</p> <p>于是现在的局面变得非常魔幻:</p> <ul> <li><strong>iOS 端</strong>:CN ID 存照片,HK ID 下游戏,US ID 用来供着那些傲娇的 AI App。</li> <li><strong>Android 端</strong>:HK 账号下日常应用和使用 Google 家各种服务,US 账号专门伺候 Gemini。</li> </ul> <p>日常使用起来那叫一个精神分裂。在 iPhone 上为了更个 App 要切账号,输密码输到手软;在安卓上虽然切换稍微方便点,但为了不同服务的权限切来切去,经常搞不清现在自己到底身在&quot;哪国&quot;。</p> <h3 id="ip-地址这茬事儿比账号还玄学">IP 地址这茬事儿,比账号还玄学</h3> <p>有了美区账号不代表能用美区服务。</p> <p>你的网络环境必须得&quot;纯净&quot;。这就逼着我们必须给特定的服务设置专门的代理规则。以前可能一个节点走天下,现在不行了:这个服务要求美国原生 IP,那个流媒体限制必须是家庭宽带 IP,另一个 AI 服务又屏蔽了常见的机房 IP 段……</p> <p>稍微手抖一下,分流规则没写对,或者节点抽风飘到了被风控的网段,轻则服务不可用,重则直接触发风控系统。最惨的情况是,因为 IP 变动过于频繁或者位置异常,连带着你辛辛苦苦注册的账号也一起被封禁。</p> <p>每次打开这些 App 前,都得战战兢兢地确认一眼代理状态,生怕一脚踩空,号就没了。</p> <h3 id="apple-id-注册避坑指北">Apple ID 注册避坑指北</h3> <p>Google 账号注册相对还算宽容,但美区 Apple ID 的注册流程现在简直是&quot;修罗场&quot;。</p> <p>首先是邮箱问题。Apple ID 强绑定邮箱,三个 ID 就得占三个坑。好不容易翻出个冷门邮箱去注册,填完一堆资料,最后一步直接弹窗提示:</p> <blockquote> <p><strong>&quot;此时无法创建你的账户。&quot;</strong></p> </blockquote> <p>没有任何错误代码,没有任何具体原因,就是告诉你&quot;不行&quot;。</p> <p>不死心换个时间、换个 IP、换个浏览器,大概率还是这句话。上网搜了一圈,发现这几乎是通病,大概率是触发了苹果某种玄学的风控机制。</p> <p>折腾了一下午没结果,后来在某个角落看到个偏方:<strong>用微信小程序注册</strong>。</p> <p>抱着死马当活马医的心态试了一下,居然一次过了!路径大概是:在微信里搜 Apple 的官方小程序(或者相关服务入口),走里面的账户创建流程。这里的风控似乎比网页端和手机设置里要宽松得多,没有任何报错,丝滑通过。</p> <h4 id="地区切换的坑">地区切换的坑</h4> <p>小程序注册出来的 ID,默认地区还是<strong>中国大陆</strong>。</p> <p>我想着这好办,去 Apple ID 网页版改个地区不就行了?结果又撞墙了——在网页版里修改地区,选好美国,填好资料,点击保存,报错。依然是不给原因的错误。</p> <p>这时候只能祭出&quot;硬改&quot;大法:<strong>直接在手机的 App Store 里登录这个新账号</strong>。系统会提示你这个账号从未使用过,需要检查。点击检查后,在这个界面里选择地区为 United States,同意条款。神奇的事情发生了,这里居然没有任何阻碍,直接让你进入下一步填写地址。</p> <p>到了填地址这一步,千万别瞎填。虽然不验证真实居住权,但邮编和州得对应上。</p> <p>两个 Tips:</p> <ol> <li><strong>善用生成器</strong>:Google 一下&quot;US Address Generator&quot;,一抓一大把,能生成包含街道、电话、邮编的全套信息。</li> <li><strong>选免税州</strong>:这一步非常关键。如果你以后打算买 App 或者订阅服务,一定要选**免税州(Tax-Free States)**的地址。比如 <strong>Oregon (OR)</strong>、<strong>Delaware (DE)</strong>、<strong>Montana (MT)</strong> 等。不然你买个 $19.99 的软件,还得额外多交一笔税。虽然钱不多,但心里膈应。</li> </ol> <h3 id="heading"></h3> <p>折腾完这一圈,看着手机里那几个不同地区的账号,长舒一口气。</p> <p>在这个数字时代,想要获取一点本来就该有的便利(比如用个 Gemini,下个 ChatGPT),往往需要付出不成比例的时间成本。手里攥着的四五个账号,还有那一堆复杂的网络规则,大概就是我们这代网民最真实的写照了。</p> <p>有时候会想,这些本该是最基本的服务,为什么要搞得这么复杂呢?但想归想,该折腾的还是得折腾。毕竟在这个时代,不折腾,就意味着落后。</p>

2026/2/1
阅读更多