想问问佬们有没有推荐开源的管理网关的项目，就是用来管理自己做的一些接口加上网关，生成key提供给别人用的这种项目，感谢佬们 5 个帖子 - 3 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 之前的帖子 简要介绍 牛子小助手(DickHelper) 是一个开源自慰数据管理工具，意在通过记录的方式合理量化打胶/挖矿的次数，帮助每个佬友科学地管理自己的身体健康数据。 相信每位佬友都遇到过这样的问题： 昨天好像才打过，今天打不打？ 今天打的速度貌似有点快，我是不是相比以前退步了？ 这段时间感觉比以前持久了，但是没有数据支撑 牛子小助手就是为这些而生的，我们甚至提供了专属的Github同款 热力图 ，增加你的成就感。 隐私至上 对于这样一款App，隐私无疑至关重要，牛子小助手将所有的数据存储在本地，无隐私担忧。 重写 在牛子小助手出生初期，获得了许多佬友的好评，但是，由于当时Vibe的过于仓促加上没有时间，牛子小助手在很长的一段时间内被迫停更。如今，牛子小助手已经完成2.0版本重写，迁移到了目前跨平台最成熟的TypeScript+Electron技术栈，美中不足的是，移动端被我们暂时放弃了——不过别担心，后续我们会考虑设计移动端的。 几张图片仅供佬友参考，具体欢迎下载使用。 友情提示： 直接点击关闭按钮并不会关闭牛子小助手，它会藏在任务栏！这是为了方便各位佬友计时使用。 最后提一嘴，由于项目刚刚迁移完毕，难免有小Bug和做的不好的地方，还请提出建议，感谢各位的谅解。 开源地址： GitHub - zzzdajb/DickHelper: A simple and easy-to-use masturbation management tool · GitHub 24 个帖子 - 18 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出（放置文章末尾） 项目地址： GitHub - mydubai7794/opencode-led · GitHub 起因 不知道大伙儿有没有 AI 焦虑——就是项目交给 AI 跑了以后，隔一会儿就得切回终端看一眼：它是不是在问我要权限？需求跑完了没有？还是在哪个环节卡住了？ 市面上有一些消息提醒工具，能在 AI 需要操作时推送通知到手机或桌面，但似乎还没有人做跟 硬件联动 的方案。我的想法很简单： 在桌面上放一盏小灯，AI 的状态直接映射成灯效，扫一眼就知道它在干什么。 它能做什么 核心思路是把 AI 编程助手的实时状态映射到桌面 LED 灯效： AI 状态 灯效 含义 思考/执行中 黄色跑马灯旋转 AI 正在工作中 需要授权 红灯常亮 AI 在问你要权限，赶紧去看看 任务完成 绿灯常亮 活儿干完了 空闲待机 蓝灯呼吸 闲着，等你发指令 出错 红灯慢闪 挂了，去看看 实现方式是在 OpenCode 的插件钩子中捕获事件（AI 输出、工具执行、权限请求、任务完成等），然后通过 MQTT 消息推送到 ESP32，ESP32 根据收到的状态切换灯效。 具体来说，插件监听了以下 OpenCode 事件： message.part.delta — AI 正在输出内容，触发「思考中」黄灯 tool.execute.before/after — AI 在执行工具（读写文件、运行命令等），同样黄灯 permission.asked — AI 需要用户授权，切换红灯常亮，提醒你赶紧去处理 session.idle — 会话空闲，说明活干完了，切绿灯 session.error — 出错了，红灯闪烁 还有一个比较实用的特性—— 多项目协调 。如果你同时开了好几个项目在跑 AI，插件会自动取优先级最高的状态来显示。比如项目 A 在思考（黄灯），项目 B 突然需要授权（红灯），灯会自动切到红灯，因为「需要授权」优先级更高。优先级规则： error(10) > auth_required(8) > thinking(5) > done(3) > idle(0) 架构 支持两种模式： 本地模式（默认） ：插件内嵌了一个 MQTT Broker，ESP32 和电脑在同一局域网就能通信，零配置。 你的电脑（OpenCode + 插件）→ 内嵌 MQTT Broker → WiFi 局域网 → ESP32 + LED 远程模式 ：如果你有公网服务器，可以部署 Mosquitto Broker，ESP32 通过互联网连接，不受局域网限制。 你的电脑 → 远程 MQTT Broker（公网）→ 互联网 → ESP32 + LED 成本：约 15 块钱 是的，只要十五块。物料清单： 部件 型号 参考价格 主控 ESP32-C3 Super Mini ~¥8 LED WS2812B 灯带（60颗/米） ~¥5/米（只需截 3 颗） USB-C 数据线 ~¥2 合计 ~¥15 接线也非常简单，三根线： ESP32-C3 WS2812B 灯带(3颗) GPIO 8 → DIN（数据输入） 5V → VCC GND → GND 如果你手上有 ESP8266，也支持，用 PWM 方式驱动三色 LED。 烧录 & 配网 提供了三种烧录方式，按需选择： Web 烧录器（最省事） — Chrome/Edge 浏览器直接烧录，零安装，插上 USB 就能刷 arduino-cli 命令行 — 适合批量部署 Arduino IDE — 经典方式，不多解释 配网也很方便：ESP32 首次启动会开一个 WiFi 热点，手机连上去打开浏览器，填入你家 WiFi 密码就行，不用把配置写死在代码里。 3D 外壳 3D 建模我也是门外汉，外壳模型来自拓竹 MakerWorld 上 Leroyd 的作品，打印出来效果不错，刚好能塞进 ESP32-C3 和灯带。 安装 两条命令搞定： Linux / macOS： git clone https://github.com/mydubai7794/opencode-led.git cd opencode-led && bash install.sh Windows： git clone https://github.com/mydubai7794/opencode-led.git cd opencode-led && install.bat 重启 OpenCode 就能看到蓝灯呼吸了。 最后 这个项目的出发点很小——就是想少切几次终端窗口，用一盏灯来告诉自己 AI 在干什么。但做下来发现还挺实用的，尤其是红灯亮起来的时候，真的能做到「不打断工作流但又不漏掉权限请求」。 项目完全开源，欢迎各位佬友试试，有建议或者想加功能欢迎提 Issue / PR。 项目地址： GitHub - mydubai7794/opencode-led · GitHub AI润色部分：正文由我给AI提供了大致的思路，排版和指令由AI精简README后得出，截图如下： 1 个帖子 - 1 位参与者 阅读完整话题
想搞一些outlook邮箱，有没有注册机之类的开源项目呢 3 个帖子 - 3 位参与者 阅读完整话题
技术栈是 tauri 之前一直用 uTools ，也写过 uTools 的插件，但是后来 uTools 限制插件数量了，于是就有了自己写一个的想法，于是就有了 Onin GitHub: https://github.com/Onin-app/Onin 官网: https://onin-app.github.io/Onin/
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 之前一直有个愿望,就是从0到1 完整的开发一个博客,个人内容管理的网站,现在终于完成了,自己从ui设计,前端开发,后端开发,到运维部署,现在终于开发出了第一版,开源出来 github地址如下: GitHub地址 项目部署很简单, docker 部署,几行命令即可部署成功~ 求Stars~~~~~ 佬友们, 让我感受下 star的快乐 ~ 么么哒~ 当然,还是有些瑕疵,后续会一直迭代,毕竟是第一个从0到1的项目~ 努力美化为最美博客 内容网站! 一下是相关介绍和截图: 演示地址: 部署成功示例: 这个项目 也做了一个 agetn skill 来管理项目,佬友们也可以使用试试~ 项目截图 web首页: 登录页(纯粹是为了炫页面,不登录也可以使用~): 后台首页: 文章详情页: 7 个帖子 - 6 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 最近kiro不是复活了吗，kirors我参考 https://github.com/M-JYuan/kiro.rs的项目增加了开启超额、凭证级代理、单独测活、优化opus-4-7-thinking、模型列表、余额缓存持久化、假缓存优化等功能。 github： Foxfishc/kiro.rs: A Kiro Client in Rust 图片如下 觉得好用可以给个star~~ 8 个帖子 - 6 位参与者 阅读完整话题
最近我们把自己做实时数字人过程中的一套工程框架整理了一下，开源出来了，项目叫 OpenTalking 。 Github 传送门是： https://github.com/datascale-ai/opentalking 演示视频: https://www.bilibili.com/video/BV1CsLz6WEF9/?vd_source=4820076c616e58ceb357c528a571ff11 它不是一个单纯的 talking head 模型，也不是只跑一段视频生成 demo 的脚本，而是一个更偏“实时对话数字人产线”的开源框架。简单来说，我们希望它能把 LLM 、TTS 、STT 、WebRTC 、字幕事件、角色音色、用户打断、前端交互和数字人视频驱动模型这些东西串起来，让一个数字人真正可以进行实时对话。 我自己在做这个方向的时候，一个很强烈的感受是：数字人 demo 和数字人产品之间，其实隔着一大段工程距离。 如果只是让一张脸动起来，或者让一段音频驱动口型，这件事现在已经有不少开源模型可以做了，比如 Wav2Lip 、MuseTalk 、LivePortrait 、FlashTalk 这些路线。它们各自解决了数字人链路里的某一个关键环节，有的偏口型同步，有的偏头像驱动，有的偏高质量视频生成。但是当你真的想把它做成一个可以和用户连续对话、可以部署、可以切换模型、可以接入真实业务的系统时，问题就会变复杂很多。 用户说一句话之后，系统要先做语音识别；识别出来的文本要交给 LLM ； LLM 最好是流式生成，不然等待时间会很长；生成的文本要交给 TTS ； TTS 产生音频之后，还要同步驱动数字人视频；前端要低延迟播放音视频；字幕要和语音尽量对齐；用户中途打断时，LLM 、TTS 、视频流和字幕都要一起停掉，然后进入下一轮对话。 这些环节单独拿出来看，好像每一步都有现成工具。但真正串在一起之后，就会发现大量时间都花在“胶水层”上：状态管理、事件同步、模型服务适配、前后端通信、WebRTC 播放、配置管理、错误恢复、延迟控制、不同后端切换等等。 OpenTalking 想解决的就是这部分问题。 我们不希望它只绑定某一个具体的视频生成模型，而是希望它成为一个相对通用的实时数字人对话框架。你可以先用 Mock 模式把整条链路跑通，也可以在本地接入轻量模型做单机部署，还可以通过远端推理服务接入更高质量的数字人生成后端。对于开发者来说，这样的好处是：你不需要一上来就把所有组件都搭完，而是可以分阶段验证。 比如你刚开始只是想看看实时数字人产品的完整流程，那么可以直接用 Mock 模式。这个模式下不需要下载模型权重，也不需要准备复杂的视频推理环境，主要用来验证前端、后端、LLM 、TTS 、字幕和对话状态是否能跑通。 如果你想进一步在消费级显卡上跑一个真实的数字人，可以尝试本地推理路线，比如 QuickTalk 或 Wav2Lip 这类方案。它们更适合单机验证和轻量部署，适合开发者在自己的机器上做实验。 如果你对画质、稳定性和吞吐要求更高，可以走远端推理服务的路线，比如通过 OmniRT 接入 FlashTalk 这类后端。这样 OpenTalking 本身负责对话编排和前端交互，真正重的推理部分可以放在更合适的机器上。 我觉得这也是现在实时数字人领域很重要的一个趋势：模型本身当然重要，但系统工程同样重要。一个数字人是否“可用”，不只是看它单帧画质有多好，还要看端到端延迟是否足够低，音画是否同步，用户打断是否自然，多轮对话是否稳定，角色配置是否方便，部署和调试是否简单。 很多时候，用户感知到的体验并不是“这帧脸部细节提升了多少”，而是“它是不是能像一个实时存在的人一样响应我”。这就要求我们把 LLM 、语音、视频和前端交互放在一个统一系统里一起优化。 OpenTalking 目前已经包含了 WebUI 前端、后端 API 、会话编排、多种模型后端模式、角色配置、字幕事件和基础的实时对话链路。前端里可以配置数字人角色、音色、LLM 、TTS 、STT 和数字人驱动模型，也可以查看模型连接状态，并进行完整的对话演示。后端则主要负责编排一次对话中发生的各种事件，包括用户输入、模型回复、语音合成、字幕生成、视频播放和打断控制。 目前项目里支持的路线包括 Mock 、Local 、OmniRT 和 Direct WebSocket 。Mock 适合快速跑通； Local 适合本地部署； OmniRT 适合接入远端推理服务； Direct WebSocket 则方便开发者对接自己的模型服务。 我们后面还会继续完善几个方向。一个是接入更多数字人模型后端，让不同 talking head 、portrait animation 、audio-to-video 模型都能更方便地挂进来。另一个是继续优化低延迟交互，包括流式 LLM 、流式 TTS 、字幕事件同步和用户打断。还有一个方向是角色资产管理，比如角色形象、音色、人设 prompt 、静默视频、默认开场白、表情风格等，未来都应该可以更系统地配置和复用。 我个人比较看好实时数字人在几个场景里的应用，比如 AI 新闻主播、在线客服、教育讲解、企业知识库问答、电商讲解、虚拟 IP 和本地化陪伴类应用。尤其是现在 LLM 、TTS 和 STT 已经比较成熟，接下来真正决定体验的，可能就是谁能把整条链路做得更稳定、更低延迟、更容易部署。 当然，OpenTalking 现在还处在比较早期的阶段，很多地方还不够完善。我们把它开源出来，一方面是希望给做数字人的开发者一个可以直接上手的工程起点，另一方面也希望和更多对实时数字人感兴趣的人一起讨论：数字人到底应该怎么从一个演示视频，走向一个真正可用的交互产品。 如果你也在关注实时数字人、Talking Head 、LLM Agent 、TTS/STT 、WebRTC 或私有化部署，可以看看这个项目。 GitHub： https://github.com/datascale-ai/opentalking 欢迎 Star 、提 issue ，也欢迎一起交流这个方向。
大家好，最近开源了一个自己做的本地字幕工具 Fast Sub 。 GitHub： https://github.com/ryviuszero/Fast-Sub 项目主要是给视频 / 音频生成字幕，也支持字幕翻译、双语字幕和字幕烧录。现在 Windows 和 macOS 都已经打包好了。 目前主要功能大概是： 本地视频 / 音频生成 SRT 字幕 支持 Faster Whisper / whisper.cpp 支持字幕翻译、双语字幕 支持字幕烧录 支持本地模型和 OpenAI-compatible API 默认本地处理，远程 API / Web provider 需要显式选择 转录质量方面，Whisper large-v3 / v3 turbo 这一代已经很不错了，普通播客、课程、视频内容基本够用。 翻译这块我做了一些 benchmark 。CLI 里现在有 bench 和 bench-translate ，转录主要看 WER / CER ，翻译主要看 BLEU / chrF ，同时也记录 exact match 。实际结果是：NLLB 本地翻译可用，但会有一点生硬；本地 Qwen3 4B 的字幕翻译效果挺惊喜，在我的测试样本里已经比较接近 Google 翻译。 第一版桌面端为了收敛范围，先把 benchmark 图形界面砍掉了；目前质量对比主要还是通过 CLI 跑。 项目地址： https://github.com/ryviuszero/Fast-Sub 另外我也写了一篇比较长的复盘，主要不是介绍功能，而是记录这三周用 Codex 做完整项目的一些经验： https://ryviuszero.github.io/zh/posts/codex-complex-project-development/ 这次最大的感受是，Codex 用来做真实项目，和“一句话生成 demo”完全不是一回事。 我自己比较有体会的几点： 先写 MVP 文档，比直接写代码重要 一开始先把项目的最小版本写清楚：做什么、不做什么、默认行为、隐私边界、错误码、输出格式。后面 Codex 每次接着做，都有一个明确边界，不容易越做越散。 用一轮一轮的方式推进 我没有让 Codex 一次性做完整桌面应用，而是从 CLI 、模型管理、provider 、benchmark 、Go daemon 、Electron UI 、打包发布这样一轮一轮推进。每轮都有目标、非目标和验收命令。 文档就是长期上下文 聊天记录不适合当项目记忆。所以项目里放了产品文档、架构文档、开发规范、spec 、tracker 、QA 表、release smoke 。后面每次让 Codex 继续做，都是先读这些文档。 重构不能省 AI 很容易快速堆功能，但项目很快会变复杂。中间我专门做过一轮 Python 分层重构，把 CLI 、service 、provider 、worker 、model store 、benchmark 这些边界拆开。后面迁移 Go 、接 Electron 、做打包都明显轻松很多。 UI 最好 mock-first Electron 一开始没有直接接真实后端，而是先用 mock client 跑通页面、状态、失败、取消、结果展示。UI 状态稳定后，再切到真实 Go daemon 。这样调试成本低很多。 QA 和发布要尽早进入流程 桌面应用不是 build 通过就完了，还要测 installer 、portable 、macOS dmg 、模型下载、中文路径、进程退出、secret redaction 、真实 provider 、截图 baseline 等。这个过程也很适合交给 Codex 做清单和回归。 总的来说，Codex 对我最大的帮助不是“生成一段代码”，而是可以持续协作：写计划、拆任务、改代码、补测试、重构、更新文档、做 release checklist 。 但前提是要给它足够清楚的上下文和验收标准，不然项目大一点之后也会失控。 项目还比较早期，如果大家对本地字幕工具、字幕翻译、本地模型，或者 Codex 做项目的流程感兴趣，欢迎看看，也欢迎提建议。
大家好，最近开源了一个自己做的本地字幕工具 Fast Sub 。 GitHub： https://github.com/ryviuszero/Fast-Sub 项目主要是给视频 / 音频生成字幕，也支持字幕翻译、双语字幕和字幕烧录。现在 Windows 和 macOS 都已经打包好了。 目前主要功能大概是： 本地视频 / 音频生成 SRT 字幕 支持 Faster Whisper / whisper.cpp 支持字幕翻译、双语字幕 支持字幕烧录 支持本地模型和 OpenAI-compatible API 默认本地处理，远程 API / Web provider 需要显式选择 转录质量方面，Whisper large-v3 / v3 turbo 这一代已经很不错了，普通播客、课程、视频内容基本够用。 翻译这块我做了一些 benchmark 。CLI 里现在有 bench 和 bench-translate ，转录主要看 WER / CER ，翻译主要看 BLEU / chrF ，同时也记录 exact match 。实际结果是：NLLB 本地翻译可用，但会有一点生硬；本地 Qwen3 4B 的字幕翻译效果挺惊喜，在我的测试样本里已经比较接近 Google 翻译。 第一版桌面端为了收敛范围，先把 benchmark 图形界面砍掉了；目前质量对比主要还是通过 CLI 跑。 项目地址： https://github.com/ryviuszero/Fast-Sub 另外我也写了一篇比较长的复盘，主要不是介绍功能，而是记录这三周用 Codex 做完整项目的一些经验： https://ryviuszero.github.io/zh/posts/codex-complex-project-development/ 这次最大的感受是，Codex 用来做真实项目，和“一句话生成 demo”完全不是一回事。 我自己比较有体会的几点： 先写 MVP 文档，比直接写代码重要 一开始先把项目的最小版本写清楚：做什么、不做什么、默认行为、隐私边界、错误码、输出格式。后面 Codex 每次接着做，都有一个明确边界，不容易越做越散。 用一轮一轮的方式推进 我没有让 Codex 一次性做完整桌面应用，而是从 CLI 、模型管理、provider 、benchmark 、Go daemon 、Electron UI 、打包发布这样一轮一轮推进。每轮都有目标、非目标和验收命令。 文档就是长期上下文 聊天记录不适合当项目记忆。所以项目里放了产品文档、架构文档、开发规范、spec 、tracker 、QA 表、release smoke 。后面每次让 Codex 继续做，都是先读这些文档。 重构不能省 AI 很容易快速堆功能，但项目很快会变复杂。中间我专门做过一轮 Python 分层重构，把 CLI 、service 、provider 、worker 、model store 、benchmark 这些边界拆开。后面迁移 Go 、接 Electron 、做打包都明显轻松很多。 UI 最好 mock-first Electron 一开始没有直接接真实后端，而是先用 mock client 跑通页面、状态、失败、取消、结果展示。UI 状态稳定后，再切到真实 Go daemon 。这样调试成本低很多。 QA 和发布要尽早进入流程 桌面应用不是 build 通过就完了，还要测 installer 、portable 、macOS dmg 、模型下载、中文路径、进程退出、secret redaction 、真实 provider 、截图 baseline 等。这个过程也很适合交给 Codex 做清单和回归。 总的来说，Codex 对我最大的帮助不是“生成一段代码”，而是可以持续协作：写计划、拆任务、改代码、补测试、重构、更新文档、做 release checklist 。 但前提是要给它足够清楚的上下文和验收标准，不然项目大一点之后也会失控。 项目还比较早期，如果大家对本地字幕工具、字幕翻译、本地模型，或者 Codex 做项目的流程感兴趣，欢迎看看，也欢迎提建议。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 佬友们，我最近基于OpenSpec和Superpowers做了一个开源Skills 开源链接如下 Comet: OpenSpec + Superpowers 双星开发工作流 — 从创意到归档，一条命令 另外还有B站视频介绍~ 开源！Comet: 基于OpenSpec和Superpowers怎么做出更好用的自动Spec Skills 核心主要是解决OpenSpec执行能力不够强，Superpowers对Spec全生命周期管理能力不够强的问题，只组合这两个Skill做串联流程 在这个项目可以学到： 嵌套Skill如何稳定触发，比如项目里面依赖的OpenSpec和Superpowers，本质不会对他们进行修改 轻量化状态机机制、长程任务断点恢复(省token版) 如何让组合Skill多阶段自动触发，而不是靠人工介入(因为现阶段想要组合两个Spec功能，还得靠自己手动敲斜杠命令，怪麻烦的) 等等内容 希望佬们多多点赞star，欢迎参与一起贡献~，学AI，上L站! 2 个帖子 - 1 位参与者 阅读完整话题
大家好，最近开源了一个自己做的本地字幕工具 Fast Sub 。 GitHub： https://github.com/ryviuszero/Fast-Sub 项目主要是给视频 / 音频生成字幕，也支持字幕翻译、双语字幕和字幕烧录。现在 Windows 和 macOS 都已经打包好了。 目前主要功能大概是： 本地视频 / 音频生成 SRT 字幕 支持 Faster Whisper / whisper.cpp 支持字幕翻译、双语字幕 支持字幕烧录 支持本地模型和 OpenAI-compatible API 默认本地处理，远程 API / Web provider 需要显式选择 转录质量方面，Whisper large-v3 / v3 turbo 这一代已经很不错了，普通播客、课程、视频内容基本够用。 翻译这块我做了一些 benchmark 。CLI 里现在有 bench 和 bench-translate ，转录主要看 WER / CER ，翻译主要看 BLEU / chrF ，同时也记录 exact match 。实际结果是：NLLB 本地翻译可用，但会有一点生硬；本地 Qwen3 4B 的字幕翻译效果挺惊喜，在我的测试样本里已经比较接近 Google 翻译。 第一版桌面端为了收敛范围，先把 benchmark 图形界面砍掉了；目前质量对比主要还是通过 CLI 跑。 项目地址： https://github.com/ryviuszero/Fast-Sub 另外我也写了一篇比较长的复盘，主要不是介绍功能，而是记录这三周用 Codex 做完整项目的一些经验： https://ryviuszero.github.io/zh/posts/codex-complex-project-development/ 这次最大的感受是，Codex 用来做真实项目，和“一句话生成 demo”完全不是一回事。 我自己比较有体会的几点： 先写 MVP 文档，比直接写代码重要 一开始先把项目的最小版本写清楚：做什么、不做什么、默认行为、隐私边界、错误码、输出格式。后面 Codex 每次接着做，都有一个明确边界，不容易越做越散。 用一轮一轮的方式推进 我没有让 Codex 一次性做完整桌面应用，而是从 CLI 、模型管理、provider 、benchmark 、Go daemon 、Electron UI 、打包发布这样一轮一轮推进。每轮都有目标、非目标和验收命令。 文档就是长期上下文 聊天记录不适合当项目记忆。所以项目里放了产品文档、架构文档、开发规范、spec 、tracker 、QA 表、release smoke 。后面每次让 Codex 继续做，都是先读这些文档。 重构不能省 AI 很容易快速堆功能，但项目很快会变复杂。中间我专门做过一轮 Python 分层重构，把 CLI 、service 、provider 、worker 、model store 、benchmark 这些边界拆开。后面迁移 Go 、接 Electron 、做打包都明显轻松很多。 UI 最好 mock-first Electron 一开始没有直接接真实后端，而是先用 mock client 跑通页面、状态、失败、取消、结果展示。UI 状态稳定后，再切到真实 Go daemon 。这样调试成本低很多。 QA 和发布要尽早进入流程 桌面应用不是 build 通过就完了，还要测 installer 、portable 、macOS dmg 、模型下载、中文路径、进程退出、secret redaction 、真实 provider 、截图 baseline 等。这个过程也很适合交给 Codex 做清单和回归。 总的来说，Codex 对我最大的帮助不是“生成一段代码”，而是可以持续协作：写计划、拆任务、改代码、补测试、重构、更新文档、做 release checklist 。 但前提是要给它足够清楚的上下文和验收标准，不然项目大一点之后也会失控。 项目还比较早期，如果大家对本地字幕工具、字幕翻译、本地模型，或者 Codex 做项目的流程感兴趣，欢迎看看，也欢迎提建议。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 CZ600/AutoDocxProofread: A software based on large language models for document proofreading, formatting, and reducing AI-generated content rate.. 基于大模型的文档校对、格式调整与降低ai率软件 针对论文写作的最后环节，特别是文字错误校对、格式调整和ai率检测的问题，开发了一款集成了大模型格式校对、降低ai率和文档批量格式调整的软件。软件主要主要支持大模型文档校对，校对结果预览和一键应用导出修改的功能。在降低ai率方面， 使用了这个帖子的思路： 分享一个论文降ai率的prompt，实测维普6% - 开发调优 - LINUX DO ，先将文档分块，然后批量优化并替换原文。格式调整方面，可以导出参考文档的标题和正文格式，一键应用到需要修改的文档上。 以下是效果展示部分： 降低AI率，操作过程中会自动跳过参考文献、标题等部分： 格式克隆，从参考文档中提取格式样式并应用到目标文档，并且在格式套用时还能微调参数： 可以设置校对的错误类型、严格程度和文本背景，也可以自行设置提示 应用中可以自行设置api，兼容满足openai规范的api接口，并提供多家服务商的预设信息： 3 个帖子 - 3 位参与者 阅读完整话题
小红书似乎要出上传skills的功能了，但是怎么感觉怪怪的。这要是收费的话，一堆人花钱买开源的资源？ 如何保护原创呢？ 2 个帖子 - 2 位参与者 阅读完整话题
handsets —— 用 Rust 写的 Android 高性能自动化 CLI 。 设计 客户端 Rust 单二进制 daemon 是一个 ~几百 KB 的 jar ，通过 adb forward 跑在设备 shell UID 下，无需 root 也无需装 APK 通信走长度前缀的二进制帧 性能 handsets adb shell uiautomator2 Appium 单次调用延迟 2-7ms 40-700ms 30-100ms 100-500ms adb shell input tap 之所以慢且不稳定，是因为它走 injectInputEvent(ev, sync=true) ，sync 模式会阻塞到 InputDispatcher 处理完事件 —— 当 UI 线程在做动画或 layout 的时候，sync 排在队尾等。实测最长 tap 尖峰 2.3 秒。 handsets 默认走 AccessibilityNodeInfo.ACTION_CLICK ，绕开 InputDispatcher ，直接触发 widget 的 OnClickListener ，p99 ~50ms 。OnTouchListener-only 的自定义 View 会 fallback 到 gesture path 。 hs ui 的输出格式 不是 XML accessibility dump ，而是 verb-led 表格： tap ImageButton "返回" #back_btn 98,243 fill EditText "邮箱" #email_et 540,540 fill EditText "密码" #pwd_et 540,640 [password] tap Button "登录" #login_btn 540,860 每行给出建议动词、selector 、坐标、flag 。LLM agent 直接读这张表就能下一步，token 占用比 XML 少一个数量级。 登录流程示例 hs use # 连设备、起 daemon hs ui # 看一眼当前屏幕 hs fill 邮箱 user@example.com # 自动匹配邮箱 EditText hs fill 密码 hunter2 hs tap 登录 # 走 ACTION_CLICK hs wait 欢迎 # 阻塞至目标文本出现 Python 绑定（ pip install handsets ）： from handsets import Session with Session.use() as s: s.fill("邮箱", "user@example.com") s.fill("密码", "hunter2") s.tap("登录") s.wait("欢迎") selector 兼容 CSS + Playwright 风格： hs find 'Button:has-text("Sign in")' hs find 'EditText:below(TextView[text=Email])' hs find 'Button:near(ImageView, 200)' 链接 GitHub: https://github.com/elliotgao2/handsets 文档: https://elliotgao2.github.io/handsets/
AV2 作为 AV1 的后继者，已经研发多年，一直定位为开放源代码、免版税的视频编码标准。 原计划在 2025 年底前正式发布，但最终未能如期推出，如今多项最新迹象表明，其正式亮相时间已经锁定在下周。 近日，VideoLAN 公布了名为 Dav2d 的开源 AV2 解码器项目，延续了此前 AV1 解码器 Dav1d 的路线，这被视为 AV2 进入落地阶段的重要信号之一。 与此同时，更关键的进展来自开放媒体联盟（Alliance for Open Media，AOMedia）的参考软件实现——AOM Video Model（AVM）。 在 AVM 的最新代码提交中，项目版本号及 AV2 的共享库版本号被同步提升至 1.0.0，被视为“正式发布版”的典型标志。 更具指向性的是，变更日志的发布日期被预先标注为 2026 年 5 月 29 日，并明确写明这是 AV2 的首个正式发布版本。 多重信号叠加，使得业界普遍预期 AV2 将在 5 月 29 日正式发布。 从时间节点上看，此前 Dav2d 解码器刚刚推送，加之外界普遍判断 AV2 规范已接近定稿，这一发布时间点与技术准备节奏高度吻合。 值得注意的是，发布时间恰好落在台北国际电脑展（Computex）召开前夕，为相关软硬件厂商在展会上展示与 AV2 相关的新技术、新产品提供了良好契机。 对芯片、浏览器、流媒体平台等产业链参与者而言，AV2 的正式发布意味着可以更明确地围绕新规范展开优化和宣传。 根据此前公开的信息，AV2 自今年 1 月起一直处于草案状态，在 AV1 的基础上进一步提升压缩效率，并在多项技术细节上进行了改进。 这些改进有望在同等画质下显著降低码率，或在相同码率下提供更高画质，从而进一步降低视频分发与存储成本。 随着规范趋于稳定、参考实现进入 1.0.0 版本并预定发布日期，外界预计在 5 月 29 日之后，将有更多关于 AV2 技术细节、性能优势以及生态支持计划的消息陆续释出。 在开源、免版税的视频编码阵营中，AV2 的到来有望成为继 AV1 之后的又一重要里程碑。 查看评论
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 项目地址： GitHub - peterich-rs/fire: Fire 是面向 Linux.do 社区的非官方第三方原生iOS Android客户端 · GitHub 下面是一些实际运行的效果图 部分细节可能有变化 以实际效果为准： 2 个帖子 - 2 位参与者 阅读完整话题
每次跑 claude 前自动检查三项： DNS 解析、 出口 IP 是否在封锁地区（ CN/RU/IR 等）、 TCP 连通性含延迟和丢包率。 结果 🟢🟡🔴 一目了然，黄红两档会提示 Continue / Retry / Quit 让你决定要不要继续。 git clone https://github.com/Laotree/verify-networking-plugin cd verify-networking-plugin && ./install.sh 装完之后对 claude 命令完全透明，不影响正常使用。
每次跑 claude 前自动检查三项： DNS 解析、 出口 IP 是否在封锁地区（ CN/RU/IR 等）、 TCP 连通性含延迟和丢包率。 结果 🟢🟡🔴 一目了然，黄红两档会提示 Continue / Retry / Quit 让你决定要不要继续。 git clone https://github.com/Laotree/verify-networking-plugin cd verify-networking-plugin && ./install.sh 装完之后对 claude 命令完全透明，不影响正常使用。
每次跑 claude 前自动检查三项： DNS 解析、 出口 IP 是否在封锁地区（ CN/RU/IR 等）、 TCP 连通性含延迟和丢包率。 结果 🟢🟡🔴 一目了然，黄红两档会提示 Continue / Retry / Quit 让你决定要不要继续。 git clone https://github.com/Laotree/verify-networking-plugin cd verify-networking-plugin && ./install.sh 装完之后对 claude 命令完全透明，不影响正常使用。