YeungYeah修改

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

我曾经是一个非常习惯做笔记、写文章的人。学习的时候，总觉得如果只是看了一遍而没有动手做点什么，就好像没有真正学到东西。

对于技术性的内容，可以通过动手实操来掌握；但对于知识型的内容，似乎只能靠输出——做笔记、写总结——来验证自己是否真的有所收获。

不过，“记笔记”这件事其实比较笼统。笔记至少可以分为两种：一种是主观输出型，由自己思考、总结得出，能写出这样的笔记自然没什么问题；另一种是摘录整理型，也是大多数人更常做的——把学到的内容摘录下来，最多做一些结构化整理。

这种摘录式的笔记，记下来似乎没什么意义：记完不过是堆在知识库里，不一定会再翻出来看，顶多是偶尔需要的时候去笔记软件里搜一下。但如果不记，又会有种不安感，好像没有学过一样。尤其是刷网课、看视频的时候，看完不留下点什么，总觉得白看了。这种矛盾感大概很多人都有。

AI 时代的冲击

到了 LLM 的时代，再回过头来看这个问题，笔记和博客还有写的意义吗？

先说博客。以前我的博客更多是记录解决问题的过程——遇到一个技术问题，从网上搜集资料，自己整理出一套解法，写下来。比如一些早期的文章里就有这样的内容，那时候可能更喜欢把遇到的问题、学到的东西直接贴出来分享：

• Mysql 忘了 root 密码怎么办
• Linux 文件系统中操作文件导致 NTFS 文件系统中文件丢失
• Some Notes About SQLAlchemy

但现在，这些内容直接丢给 AI 问一句，基本就能得到答案了。那还有记录下来的必要吗？

这也是为什么我的博客里技术类文章越来越少。写得浅的没什么价值，写得深的又很吃力，而且深度内容往往还在不断迭代，也不太适合直接发出来。

再说笔记。现在让 AI 随手一 gen，它就能结构化、系统化地列出完整的知识内容。以前看到有用的东西会顺手记一下，现在本身就已经在与 AI 的交互中完成了学习，记笔记的动作也变成了让 AI 去读文档、自动总结。再加上 AI 工具已经可以直接对接 Obsidian 这类本地笔记软件，一句话就能把内容写进文档目录，做笔记的过程大大加速了。

但加速之后，这些笔记就一定会去看吗？这些在以前看来更珍贵的知识内容，现在真的更有用吗？也未必。

哪些内容仍然值得写

认真想了一下，还是有些东西值得记录：

1. 知识的大纲与索引：具体的知识细节确实可以交给 AI 来生成，但一套属于自己的大纲、关键词索引或结构化框架，仍然有助于记忆和检索。AI 能给你答案，但你需要知道该问什么问题。

2. 个人经历的过程记录：过程记录本质上是一种叙事（storytelling），它的价值不在于提供技术参考，而在于记录本身。作为一份属于自己的记录，它不需要”有用”，存在即可。

3. 个人的想法与观点：尤其是带有真情实感的表达。这类内容完全属于个人，AI 无法替代生成——或者说，AI 生成的内容代表不了你自己。

归根到底，核心还是要回到“人”上面：写关于人的内容，带有人味，记录人身上真实发生的事情和真实的感受。

AI 加工与“人味”的悖论

话虽如此，实际操作中往往还是会忍不住让 AI 来加工一遍，这样一来，“人味”可能就在加工中被稀释甚至丢掉了。

比如这篇文章，原本是我用语音输入转写的文字。想法是我自己的，内容也全是我说出来的，但它经历了至少两层加工：语音转写时，软件的 AI 模型已经做了一次调整修饰；之后觉得文本还是太口语化、结构也散，又拿去让 AI 再润色一版。

所以，即使内容原本是有“人味”的，经过 AI 的多次加工之后，还能剩下多少呢？说实话我也不确定。但我觉得，只要核心的想法和判断仍然是自己的，这个过程或许也没什么问题——毕竟，工具从来都是为表达服务的。

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
• 简介：

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