做个本地语音输入小工具，专门用来对 AI 说话
用 SenseVoice 做的 Windows 本地语音输入工具，纯 CPU 推理，记录选型实测数据和踩过的坑。
Posts
开 BT 全家断网：我家的 IPv4 原来是运营商的内网地址
一开 BT 全屋断网且重启才好，实测发现是运营商内网 IPv4 连接名额被占满。
省 token 的第一个切入点：把累活甩给便宜模型（flash-delegate 实战记录）
编排方（贵模型）只管目标拆解和复核，机械活派给便宜快模型干。记录一次真实闭环、三个踩过的坑、以及什么任务能派、什么不能派。
我写规格，另一个模型去执行：一次真实分工的记录
把想清楚和干出来拆成两个角色，中间靠一份写死了实测事实的规格对接。这是那份规格和执行结果。
把一本英文书变成精读工作站
字幕和漫画翻完就完了，精读不行——它得自带载体。这是第三个本地流水线的不同之处。
漫画自动翻译：五段流水线，和一次不改代码的走查
定位、OCR、翻译、抹字、贴回——五段跑通之后，真正难的是让人愿意用它。
本地字幕流水线：复读机、VAD 和孤儿进程
给视频批量生成中英双语字幕，全程本地跑。记录四个只有真跑起来才会遇到的坑。
D2R Mod 制作通用指南：从改名字到防闪退，踩坑十年留下的铁律
一套面向开发者与 AI 的 D2R 重制版 Mod 制作知识库。聚焦国服特殊性，覆盖文本汉化、loot 染色、UI 面板、防闪退等实战要点。
D2R 多开完整指南：从零搭建一键免登录多账号环境
手把手教你用 D2R Multi 在同一台电脑上同时运行多个暗黑2重制版账号，实现一键切换、免重复登录。
自用 YouTube 下载器：处理 n-sig 问题的一次记录
[!TIP] 受众：对自托管工具感兴趣、需要排查下载失败原因的开发者。 目标：记录一次 YouTube 下载器的整理过程，重点是 n challenge 签名问题、Cookie 同步和日志观测。 问题-方案映射： 登录墙/Cookie $\rightarrow$ Manifest v3 浏览器插件同步 动态签名 (n-sig) $\rightarrow$ Docker 内置 External JS Solver (node) 实时观测 $\rightarrow$ Socket.io 流式转发 stdout 最近在整理自己的下载工具，其中一个刚需就是 YouTube 下载。市面上的工具很多，但随着 YouTube 对 n-sig（一种通过混淆 JS 动态生成的签名）的限制加码，很多开源项目开始在大音轨下载上“翻车”。 作为一个写了 20 年代码的人，我比较在意工具是否可控。于是我把旧方案重新整理了一遍，目标很简单：能跑、能查日志、出了问题知道卡在哪里。 1. 架构：为什么非要搞这么复杂？ 很多人觉得 yt-dlp 一行命令能解决的事，为什么要搞插件、Docker 和后端？ 答案是：骨感现实。 Cookie 维护：手动导 cookies.txt 太脏。我写了一个 Manifest v3 插件，点一下直接同步到云端。 环境隔离：我的开发机是 Windows，但下载器必须部署在 Linux Docker 里，且需要精准控制 ffmpeg 和 yt-dlp 的版本。 这就是我们的“三足鼎立”： 插件 (Bridge)：负责打通浏览器会话。 后端 (Engine)：Node.js + Socket.io，负责进程管理和实时日志。 容器 (Infra)：解决一切环境依赖。 2. 泥地打滚：解决 n-sig 的深层逻辑 前阵子，我的下载器突然报错：n challenge solving failed。这是 YouTube 升级了混淆逻辑，yt-dlp 默认的 Python 模拟器解不动了。 ...