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 的加持下，从想法到可用版本几乎没有门槛。
既然能提效，又几乎不费劲，那为什么不用一个小工具呢？
2026-02-24 15:52:18
春节假期刷了不少关于语音输入的帖子，这颗安利我吃下了，决定更进一步拥抱 AI，看看能不能把效率和生产力拉满。
于是，我开始试用各种语音输入软件，强迫自己将日常输入场景切换到“动嘴”模式。目前的这套工作流主要是：使用 “闪电说” 配合 “豆包” 或 “通义千问” 的流式语音模型进行识别转写。
针对不同的输出需求，我的处理方式如下：
目前的结论是：输入准确率尚可，但距离真正的“生产力自由”还有很长的路要走。 甚至在很多场景下，它处于“不可用”或“不好用”的状态。当然，这可能是我用的工具还不够强，或者我的姿势不对。
试用至今，我有以下几点比较强烈的“劝退”体验：
语音输入非常“娇气”。如果环境嘈杂，或者背景里有视频播放的声音，它会把所有杂音一股脑收录进去，直接导致识别翻车。
此外，社交尴尬症也是一大障碍。在户外或公共场合对着手机自言自语，既涉及隐私，又容易打扰别人。相比之下，默默打字才是最得体的选择。目前看来，语音输入几乎只能限制在“独自在家”或“私人房间”这种绝对无人干扰的舒适区。
即便接入了强大的大模型，识别率依然没能达到让我完全放心的程度。
这意味着即使“输入”快了，我后期还得花大量时间去用 AI 二次加工，或者手动“捉虫”确认，省下的时间又被消耗掉了。
语音输入的本质决定了它带有浓重的口语特征。说话时的思考停顿、逻辑跳跃、口误，软件都会照单全收。不像打字时，我们在落指前脑子里已经过了一遍逻辑。
虽然可以用大模型来“洗稿”，但这本身也是个折腾过程。以“闪电说”为例，它提供了一个基于大模型的原生文本润色功能。但在实际体验中，这个 AI 表现得 “过分积极” 了。
举个例子：
我原本只是想转写一句：“我想让你做某些事情，排查某个问题。” 结果 AI 自作主张，帮我把“具体的排查步骤”全给脑补并写出来了！
这种“无中生有”的幻觉让我无法接受。
尽管底层的模型是流式的，但软件交互却不支持流式上屏。 这导致我必须说完一大段话，才能看到最终结果。这过程就像 “开盲盒”——如果开头就识别错了，我无法像打字那样及时发现并纠正，只能硬着头皮说完，最后面对一堆乱码更是崩溃。
尽管吐槽了这么多，但必须承认：在特定条件下，效率提升是碾压级的。
今天我尝试用 OneNote 记录春节复盘，输出了 1000 多字。如果是手打，至少需要 30-40 分钟，但通过语音口述，仅仅用了十来分钟。这种速度上的快感，确实让人欲罢不能。
上述问题中：
在这个大模型时代，我越来越觉得 “内容”本身比“输入的完美度”更重要。 只要能把核心想法快速抛出来，语法、错字、润色完全可以交给 AI 兜底。特别是在写日记、周记这种不需要高强度逻辑构建的场景下，语音输入简直是神器。
未来一段时间，我预计还会继续“死磕”这套工作流。如果大家有更好的方案，或者正在用什么顺手的语音输入神器，欢迎在评论区给我种草！
