YeungYeah修改

2026-02-26 11:50:16

最近我大量使用 Claude Code 进行 Vibe Coding，也做了不少自己的小项目和小工具。这些工具在运行时，往往会启动本地服务器来提供 Web 或 API 服务。本地调试确实很方便，但问题在于，用完之后它们并不总能被彻底关闭。

有时即使显式让它退出，进程也未必真的结束；有时直接关闭会话窗口，服务却依然在后台运行。久而久之，系统里就残留了不少 Web 服务进程，占用内存和端口。

这类残留进程会带来几个比较麻烦的问题：

1. AI 误判服务状态

在 AI Coding 场景下，AI 判断服务是否启动，通常只是简单扫描端口是否被占用。
如果某个端口早已被旧项目占用，AI 很可能误以为当前服务已经启动成功，但实际上目标进程根本没有运行。

结果就是：看起来一切正常，实际上什么都没跑起来。

2. 端口冲突导致反复修改配置

当端口被占用时，AI 需要重新启动服务。但很多项目的端口是写死在配置文件中的，于是它不得不读取文件、修改端口、再运行服务。

由于每次冲突的端口都不一样，几乎每次都要改一遍配置。
这种“改端口—重启—再改端口”的循环，非常影响节奏。

3. 自动关闭进程容易误杀

如果让 AI 去“清理端口占用”，问题就更复杂了。
它通常只是扫描占用端口的进程，然后直接终止。

但 AI 并不知道哪些进程是当前项目的，哪些是你正在运行的重要服务。
一刀切式地 kill 掉，很容易误伤无辜。

基于这些困扰，我干脆写了一个小工具，用来手动、快速清理这些遗留的端口进程。

它可以一键列出所有占用端口的进程，让我自行判断并清理。

既然是日常会频繁使用的小工具，那就干脆做成命令行工具，一键调用。
于是我用 Rust 写了一个 TUI（Terminal UI）程序。从开始到完成不到一天时间，就已经开发完成，并发布到了 GitHub 和 Cargo 上。

感兴趣的话可以试试：

👉 https://github.com/yeung66/ccpclean
可以通过 cargo install 安装，或者直接下载二进制文件运行。

核心逻辑

程序本身的逻辑非常简单：

• 扫描当前系统进程
• 找出所有占用端口的进程
• 展示相关信息，包括：
  • 执行命令
  • 父进程信息
• 支持手动选择并终止进程

通过父进程和命令信息，基本可以判断该服务属于哪个项目。

此外，我加入了一些简单规则，用来判断该进程是否可能由 Claude Code 或其他 AI Agent 启动，并给出一个参考评分，用来辅助判断是否值得清理。

宽松模式

除了默认模式，还提供了一个“宽松模式”。

因为遗留服务不仅发生在 AI 场景中。
很多时候我们在命令行启动一个服务，关闭终端后它依然在后台运行。

宽松模式会列出所有占用端口的服务，方便逐个浏览、筛选和清理。

当然，这些事情完全可以通过原生命令行工具实现，比如：

• lsof
• netstat
• ss
• kill

但当你需要频繁做这件事时，一个专门的小工具会更高效。

而且，用 Rust 写个 TUI 的体验本身也很不错。
在 AI 的加持下，从想法到可用版本几乎没有门槛。

既然能提效，又几乎不费劲，那为什么不用一个小工具呢？

2026-02-24 15:52:18

春节假期刷了不少关于语音输入的帖子，这颗安利我吃下了，决定更进一步拥抱 AI，看看能不能把效率和生产力拉满。

于是，我开始试用各种语音输入软件，强迫自己将日常输入场景切换到“动嘴”模式。目前的这套工作流主要是：使用 “闪电说” 配合 “豆包” 或 “通义千问” 的流式语音模型进行识别转写。

针对不同的输出需求，我的处理方式如下：

• 大段文字：我在 Gemini 中自定义了一个 Gem，将转写后的“生肉”扔给它，让它帮忙去除口语废话、修正错词。之后，我会再人工过一遍。
• 短句/碎片想法：通常直接手动修改。

目前的结论是：输入准确率尚可，但距离真正的“生产力自由”还有很长的路要走。 甚至在很多场景下，它处于“不可用”或“不好用”的状态。当然，这可能是我用的工具还不够强，或者我的姿势不对。

试用至今，我有以下几点比较强烈的“劝退”体验：

1. 场景洁癖：不仅挑环境，还挑人

语音输入非常“娇气”。如果环境嘈杂，或者背景里有视频播放的声音，它会把所有杂音一股脑收录进去，直接导致识别翻车。

此外，社交尴尬症也是一大障碍。在户外或公共场合对着手机自言自语，既涉及隐私，又容易打扰别人。相比之下，默默打字才是最得体的选择。目前看来，语音输入几乎只能限制在“独自在家”或“私人房间”这种绝对无人干扰的舒适区。

2. 识别准确率：离“所想即所得”还差口气

即便接入了强大的大模型，识别率依然没能达到让我完全放心的程度。

• 中英混输是重灾区。
• 专有名词（人名、地名）经常张冠李戴。

这意味着即使“输入”快了，我后期还得花大量时间去用 AI 二次加工，或者手动“捉虫”确认，省下的时间又被消耗掉了。

3. “废话文学”与 AI 的过度加戏

语音输入的本质决定了它带有浓重的口语特征。说话时的思考停顿、逻辑跳跃、口误，软件都会照单全收。不像打字时，我们在落指前脑子里已经过了一遍逻辑。

虽然可以用大模型来“洗稿”，但这本身也是个折腾过程。以“闪电说”为例，它提供了一个基于大模型的原生文本润色功能。但在实际体验中，这个 AI 表现得 **“过分积极”**了。

举个例子：

我原本只是想转写一句：“我想让你做某些事情，排查某个问题。” 结果 AI 自作主张，帮我把“具体的排查步骤”全给脑补并写出来了！

这种“无中生有”的幻觉让我无法接受。

• 后来我尝试修改提示词（Prompt），强调“绝对不能添加或删减内容”，虽然有好转，但它依然无法 100% 忠实于原话。
• 更由于是封装好的功能，我无法看到它到底改了哪里（没有 Diff 对比），也无法微调参数，导致这个功能显得十分鸡肋。

4. 缺乏“流式”的安全感

尽管底层的模型是流式的，但软件交互却不支持流式上屏。 这导致我必须说完一大段话，才能看到最终结果。这过程就像 “开盲盒”——如果开头就识别错了，我无法像打字那样及时发现并纠正，只能硬着头皮说完，最后面对一堆乱码更是崩溃。

总结：痛并快乐着

尽管吐槽了这么多，但必须承认：在特定条件下，效率提升是碾压级的。

今天我尝试用 OneNote 记录春节复盘，输出了 1000 多字。如果是手打，至少需要 30-40 分钟，但通过语音口述，仅仅用了十来分钟。这种速度上的快感，确实让人欲罢不能。

上述问题中：

• 识别、交互、过度加工：本质上是软件和模型不够成熟，未来随着技术迭代，理论上都能解决（比如声纹识别技术成熟后，就能只听主人的声音，过滤背景音）。
• 环境限制：这是物理规律，就像发微信语音一样，得看场合。

在这个大模型时代，我越来越觉得 “内容”本身比“输入的完美度”更重要。 只要能把核心想法快速抛出来，语法、错字、润色完全可以交给 AI 兜底。特别是在写日记、周记这种不需要高强度逻辑构建的场景下，语音输入简直是神器。

未来一段时间，我预计还会继续“死磕”这套工作流。如果大家有更好的方案，或者正在用什么顺手的语音输入神器，欢迎在评论区给我种草！

2026-02-18 00:42:07

在使用 Claude Code 的过程中，superpowers 提供的 Skills 套件实在太好用了，尤其是其中的 Brainstorming、Writing-plans 和 Executing-plans。用上这些技能后，明显能感觉到 AI 干起活来更有章法，逻辑性提升显著。

最近我也在研究 Claude Code 以外的代码 Agent CLI 工具。既然开了 Gemini 的会员，就顺手试了试 Google 官方提供的 CLI 工具。虽然 Gemini CLI 也支持 Agent Skills，但在命令格式和规则细节上与 Claude 存在一些差异。目前官方的 superpowers 尚未正式支持 Gemini（尽管我在 Issue 列表中看到似乎有相关分支正在开发中）。

与其被动等待，不如自己动手。于是我决定以 Claude Code 为蓝本，动手迁移并复刻一个 Gemini 版的 superpowers。

项目仓库现已开源：gemini-superpowers

如果你也想体验，可以通过以下命令快速安装：

1

gemini skills install https://github.com/yeung66/gemini-superpowers.git --path skills

迁移核心内容

这次迁移主要涉及两部分工作：一是工具名称（Tools）的对齐，二是核心术语（Terminology）的映射，以确保 Gemini 能够正确理解和执行原有的 Agent 逻辑。

1. 工具名称映射 (Tools Mapping)

我们需要将 Claude Code 的工具指令转换为 Gemini CLI 能够识别的等效指令：

2. 术语映射 (Terminology Mapping)

为了让 Prompt 更符合 Gemini 的上下文，部分名词也做了相应的本地化调整：

使用效果

迁移完成后，在 Gemini CLI 中已经可以完美加载这些 Skills。在实际对话中，Gemini 能够准确识别我的开发意图，并自动调用相应的工具来辅助工作，体验与 Claude Code 上的 superpowers 基本一致。

如果你也是 Gemini 用户，欢迎尝试并提出反馈！

2026-02-13 09:33:45

之前在网络上冲浪的身份一直是 YeungYeah，这个名字的来源是姓氏杨的粤语拼音 + 英文 Yeah，连起来读实际上是“杨爷”的发音。杨爷这个称呼，还得来源于中学时期比较狂傲时自取的名号了，实际上后面也比较少人这样叫我，现在回过来看只觉得中二。然后博客的名字，最开始叫做 Scott Yeung's 的博客，后面为了更加突出个人的标识，改成了全网使用的网络身份，然后也是带点中二的自嘲，随笔随心写写，干脆就叫乱写地，都是乱写的，写得怎样都行，现在回过头看，也显得很中二。

于是乎，我考虑改名字了，身份标识回归此前的 Scott Yeung，英文名 + 姓氏，正式一点，稍微不那么正式点的，也可以叫我斯科特。

考虑到 SEO （搜索 Scott Yeung 前面的都不是我），最终身份标识还是用回 YeungYeah🤣，名字也相应地调整了.

博客的名字，通过和 AI 多轮沟通后，最终选择了 YeungYeah's Context。

这就对了！Context（上下文/语境）是一个非常绝妙的词，尤其对于程序员来说，它既是技术术语（Spring Context, Go Context, Execution Context），又是生活哲学的隐喻（所有的思考和行为都离不开当时当下的环境与背景）。

呼应标签：你的标签里有大量的 coding、coding 记录、notes、summary。这些本质上就是在保存 Context。

代码需要上下文才能运行，人生也是。

这里没有标准答案，只有关于技术、阅读与生活感悟的真实上下文。

—— Gemini

在和 Gemini 讨论博客名字的时候，把我博客文章所使用的标签和出现频率都喂给他（通过截图 tag cloud），来了解我博客的内容。Gemini 给我的几个标签是：Coding, Payment, 内家拳和投资。其中内家拳其实已经比较久没有写过相关的内容，个人也已经很久没有练过拳了，甚至还记得多少都不好说。但是当时读研的那两三年对于内家拳和太极真的是比较着迷，一周可以练几天，然后看不少相关的内容，也在社团中跟不少人打交道和学习。因此有段时间内家拳确实在我的博客里出现过几次（当然可能写的内容也不一定是主要讲拳，可能只是提了一下）。

然后工作之后，被工作毒害太多了，并且也开始去考虑投资赚钱的事，因此后面的一些内容就开始关注和写相应的内容，以及一些可能日常记录本身的文章，也会提到工作和赚钱这两个事情上。这两个点从这个时候开始进入到我的 Context。

从这两点来看，写个人博客这个事确实是有记录到我在某段时间，某个事情范围上的内容，记录到了这个上下文 Context，准确地记录了我那段时间的内容，其实是很准确很能说通的。这个博客，确实是我的上下文 Context 的一个记录快照。所以这个新名字，在某种程度上，还是挺贴合的。

最后再重复下，我的博客改名字了，大家看到有 RSS 订阅突然出现陌生名字的时候不需要惊讶。

变更信息

• 博客名YeungYeah's Context (杨的上下文)
• 身份标识：YeungYeah
• 简介：

热爱折腾代码与工具，偶尔在焦虑中寻找平衡。
这里没有标准答案，只有关于技术、阅读与生活感悟的真实上下文。

2026-02-01 12:18:02

最近想聊聊账号的事。

这东西本来只是个身份标识，但在当下的网络环境里，硬生生把我们逼成了"狡兔三窟"。

作为中国大陆用户，早些年为了下一些国区没有的 App，大概率都会备一个 HK 地区的 Apple ID。那时候觉得 HK ID 挺完美的，中文界面，支付方便（绑个 Alipay HK 或者港卡），大部分该有的服务也都有。

但这两年 AI 时代来了，局面又变了。很多 AI 服务（比如 Claude、ChatGPT 的 iOS 客户端）不仅锁国区，连 HK 区也被划到了"不受支持"的范畴。没办法，为了跟上时代的步伐，只能再硬着头皮去搞一个 US 地区的 Apple ID。

这事儿还不止发生在 iOS 上，安卓那边也没好到哪去。

原本以为 Google 账号有一个港区的也就够用了，Play Store 内容全，支付也没障碍。结果 Google 亲儿子 Gemini 一出来，直接对地区设限。为了能顺利用上 Gemini，我又被迫新注册了一个美区的 Google 账号来开通会员。

于是现在的局面变得非常魔幻：

• iOS 端：CN ID 存照片，HK ID 下游戏，US ID 用来供着那些傲娇的 AI App。
• Android 端：HK 账号下日常应用和使用 Google 家各种服务，US 账号专门伺候 Gemini。

日常使用起来那叫一个精神分裂。在 iPhone 上为了更个 App 要切账号，输密码输到手软；在安卓上虽然切换稍微方便点，但为了不同服务的权限切来切去，经常搞不清现在自己到底身在"哪国"。

IP 地址这茬事儿，比账号还玄学

有了美区账号不代表能用美区服务。

你的网络环境必须得"纯净"。这就逼着我们必须给特定的服务设置专门的代理规则。以前可能一个节点走天下，现在不行了：这个服务要求美国原生 IP，那个流媒体限制必须是家庭宽带 IP，另一个 AI 服务又屏蔽了常见的机房 IP 段……

稍微手抖一下，分流规则没写对，或者节点抽风飘到了被风控的网段，轻则服务不可用，重则直接触发风控系统。最惨的情况是，因为 IP 变动过于频繁或者位置异常，连带着你辛辛苦苦注册的账号也一起被封禁。

每次打开这些 App 前，都得战战兢兢地确认一眼代理状态，生怕一脚踩空，号就没了。

Apple ID 注册避坑指北

Google 账号注册相对还算宽容，但美区 Apple ID 的注册流程现在简直是"修罗场"。

首先是邮箱问题。Apple ID 强绑定邮箱，三个 ID 就得占三个坑。好不容易翻出个冷门邮箱去注册，填完一堆资料，最后一步直接弹窗提示：

"此时无法创建你的账户。"

没有任何错误代码，没有任何具体原因，就是告诉你"不行"。

不死心换个时间、换个 IP、换个浏览器，大概率还是这句话。上网搜了一圈，发现这几乎是通病，大概率是触发了苹果某种玄学的风控机制。

折腾了一下午没结果，后来在某个角落看到个偏方：用微信小程序注册。

抱着死马当活马医的心态试了一下，居然一次过了！路径大概是：在微信里搜 Apple 的官方小程序（或者相关服务入口），走里面的账户创建流程。这里的风控似乎比网页端和手机设置里要宽松得多，没有任何报错，丝滑通过。

地区切换的坑

小程序注册出来的 ID，默认地区还是中国大陆。

我想着这好办，去 Apple ID 网页版改个地区不就行了？结果又撞墙了——在网页版里修改地区，选好美国，填好资料，点击保存，报错。依然是不给原因的错误。

这时候只能祭出"硬改"大法：直接在手机的 App Store 里登录这个新账号。系统会提示你这个账号从未使用过，需要检查。点击检查后，在这个界面里选择地区为 United States，同意条款。神奇的事情发生了，这里居然没有任何阻碍，直接让你进入下一步填写地址。

到了填地址这一步，千万别瞎填。虽然不验证真实居住权，但邮编和州得对应上。

两个 Tips：

1. 善用生成器：Google 一下"US Address Generator"，一抓一大把，能生成包含街道、电话、邮编的全套信息。
2. 选免税州：这一步非常关键。如果你以后打算买 App 或者订阅服务，一定要选**免税州（Tax-Free States）**的地址。比如 Oregon (OR)、Delaware (DE)、Montana (MT) 等。不然你买个 $19.99 的软件，还得额外多交一笔税。虽然钱不多，但心里膈应。

折腾完这一圈，看着手机里那几个不同地区的账号，长舒一口气。

在这个数字时代，想要获取一点本来就该有的便利（比如用个 Gemini，下个 ChatGPT），往往需要付出不成比例的时间成本。手里攥着的四五个账号，还有那一堆复杂的网络规则，大概就是我们这代网民最真实的写照了。

有时候会想，这些本该是最基本的服务，为什么要搞得这么复杂呢？但想归想，该折腾的还是得折腾。毕竟在这个时代，不折腾，就意味着落后。

2026-01-26 22:28:54

之前给博客设了一个英语版（过程可见 开设我的英语博客 By Hugo），会把一些文章通过 AI 翻译成英语来发布。当时的工作流是写好了一篇文章，会丢进大模型的 Chat 窗口，通过固定的 prompt 来将其翻译成英语，并且保持一样的 md 格式直接输出。然后将其复制到英文内容的相同目录下，创建一个新的文件。这样每次都复制粘贴几次，还要手动创建新文件，快是也挺快，但是现在接触到 Claude Code 后，就想到能不能再便捷一点。

于是选择使用 Claude Skills。

Claude Skill 是什么? Skill(技能)是一种模块化、独立的扩展包,用于扩展 Claude 的能力,提供专业化的知识、工作流程和工具。可以把它们理解为特定领域或任务的"入职指南"——它们将 Claude 从通用型智能体转变为配备了程序性知识的专业化智能体。

通过定义一个 SKILL.md 的文档，可以创建一个技能，通过描述执行的指令步骤，以及可以参考的外部可执行代码和可参考的材料。通过可以通过一个命令，就让 Claude Code 执行相应的操作。以翻译博客为例，我在项目的 ./claude/skills/translate-post 目录下新建了一个 SKILL.md 文件，然后输入下面的内容

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

---
name: translate-post
description: transalte post's content from Chinese into English
disable-model-invocation: true
---

transalte the specific post file $ARGUMENTS content into English

1. read file $ARGUMENTS all text content
2. translate all content into English. cannot drop any content
3. create a text file in content_en directory but with the same path with original file in content

非常简单的指令，读文件内容，翻译成英语，在指定目录下创建文件。这里 $ARGUMENTS 是输入的参数。实际运行的时候，只需要输入命令/translate-post @content/posts/2026/post.md，Claude Code 就可以自动在 content_en/posts/2026/ 下创建同名的文件，并且里面的内容是翻译好的。