最近开发者自荐了 3 个有用的 App

编注： 本期内容为少数派 Matrix 社区应用自荐文章合集。文章代表作者个人观点，作者与文中产品有直接的利益相关（开发者、自家产品等），少数派仅对标题和排版略作修改。

本期目录1️⃣ ego lite ：一个 Agent 能直接的浏览器2️⃣ WinAirCast：让 Windows 也能无缝连接 HomePod3️⃣ 小窗译：从快捷面板到实时翻译窗

ego lite

‍ David在路上 | macOS

我们团队做了一个产品：ego lite，这是一个基于 Chromium 的浏览器，让你和 AI Agent 共用同一套上网环境。

你可以日常用它浏览，AI Agent 则在独立的 Space 里并行处理网页任务，并且复用你已经登录好的状态。目前已经免费推出 macOS 版本可以下载使用。

官网在这里：https://lite.ego.app/

GitHub：citrolabs/ego-lite

这篇文章不仅是想推荐一下我们的产品，也想聊聊我们的一些思考，以及最后做出来的东西。

▍为什么要在 2026 年做一个浏览器？

我们为什么会做这么一个东西，得从自己的日常工作说起。

过去一年，我和团队的大部分时间都花在 Claude Code、Codex 这类 Agent 上。它们现在能做的事早就不止写代码，做调研、对接各种 SaaS 也都行。但这类工作里有不少要在网页上完成：很多服务没有开放 API，信息和功能都还留在 GUI 里，Agent 想把事情做完，就得自己去用浏览器。

麻烦在于，今天的浏览器并不是为这种用法准备的。让 Agent 去操作网页，通常会同时碰上两个问题：它接不上你已经登录好的浏览器，做正事之前先卡在登录和验证码上；而它一旦跑起来，又会接管你的窗口和鼠标，你没办法同时用这台电脑做别的事。

我们想要的是一个很符合直觉的产品：一个你平时就在用、Agent 又能直接接入、接入之后还不跟你互相干扰的浏览器。

ego lite 就是照着这个目标做的。

它基于 Chromium 开发，第一次启动可以把 Chrome 的书签、扩展、Cookie 和登录态一起迁过来，你照常拿它当日常浏览器用。安装时它会把ego-browser这个 skill 写进 Agent 的技能目录，不用额外配置就能驱动。

而 Agent 干活时，它会待在一个独立的 Space 里，复用你已经登录好的状态，不会干扰你正在用的标签页，全程可见、可随时接管。

看看我们有趣的宣传视频，也许能感受到我们想解决的问题：https://www.youtube.com/watch?v=sSfyzeiWN9A

还有一个背景是，最近模型公司的竞争愈演愈烈了，Anthropic 和 OpenAI 为了抢市场，都在大幅压低 token 价格，一份 200 美元的订阅，只用来写代码几乎用不完。把多出来的额度交给 Agent 去跑浏览器里的任务，是更划算的用法。

下面是我们自己用得最多的两个场景。

▍自动化执行长任务

长任务有两个常见的麻烦：中途卡住，以及运行期间一直占用浏览器，影响你做别的事。

Space 这个机制正是为这两点设计的。它不是新开窗口，也不是 Chrome 的多 profile 或 headless 模式，而是浏览器内部隔离出来的一块工作区。Agent 在自己的 Space 中运行，你在自己的标签页里工作，双方互不抢占焦点。如果它在某一步卡在登录或验证码上，你可以进入对应的 Space 帮它完成，然后它继续往下执行。

由于 Agent 是把完整脚本写好后一次执行，而不是逐步试探，长流程的稳定性会更好，token 消耗也更低。原理是将多步骤任务组合成单个输出，而不是陷入 「调用两个命令，查看结果，再调用两个命令」 的循环。与传统的 CLI 方法相比，复杂工作流的完成速度提高了 20% 到 50%，任务成功率更高，每个任务的工具调用次数也大大减少。在与 Vercel 的代理浏览器进行的内部基准测试中也出现了同样的模式：工作流越复杂，差距就越大。

多个任务也可以并行。比如让 Claude Code 在 10 个 Space 里分别整理线索，同时让 Codex 在另外 5 个 Space 里收集竞品页面信息，彼此之间不会互相干扰。我们用四个复杂任务和 Vercel 的 agent-browser 做过对比，最快的一项达到 2.6 倍，任务越复杂，差距越明显。

▍前端 E2E 测试

有了第一版 ego lite 之后，我们团队内部很快就爱上了它。

测试可以直接运行在你那个已经登录好的浏览器里，省去了准备测试账号和登录的环节。

更重要的变化在于 Agent 读取页面的方式。简单的说，它拿到的不是完整 HTML，而是一份从 Chromium 内核生成的语义快照，一整页通常只占两三百 token，过滤掉了样式、脚本和隐藏节点这些噪音，保留下来的是页面上有哪些按钮、输入框、链接，以及它们各自的名称。

我们和 Playwright MCP 做过对比，在复杂场景下大约快两倍。

现在我们团队的前端测试，很多已经简化到非技术的同事也能借助 Agent 自主完成。不用写脚本，也不用懂选择器，把要验证的流程用日常的话描述清楚就行。比如对 Agent 说一句：

/ego-browser 帮我看一下现在的效果是否符合预期，完成所有测试后给我个结果。

Agent 就会在自己的 Space 里打开页面，借用你当前已登录的会话一步步操作，靠快照判断每一步的状态，最后把测试结果、遇到的报错都返回给你。一句话能覆盖多数情况，就不必再让谁去写和维护一份测试脚本。

除了这些，我们还在官网列了不少 ego lite 的使用场景，比如抓取社交媒体上的帖子、自动找合适的工作、租房、订机票酒店、跟踪股票等等，欢迎大家去看看：

▍相比现有的方案如何？

在做 ego lite 之前，我们也用过市面上几类现成的做法，各自都有比较明显的不足：

第一方 AI 浏览器（如 Comet、Atlas）只能由它自己内置的 Agent 驱动，你日常在用的 Codex、Claude Code 接不进去，上下文也共享不了，没办法放进自己的工作流。

桥接 Chrome 的插件或中间层（如 Agent-Browser、browser-use）能用上你的登录态，但登录态时而能继承、时而不能，窗口和标签页经常自行弹出，Agent 运行时还会和你争用同一个浏览器。

Agent 自带的内嵌浏览器（如 Codex、Cursor 里的）是一个裁剪过、并不完整的浏览器，继承不了你的登录态，遇到稍复杂的页面也容易出问题。

它们有一个共同点：都没有把「人和 Agent 共用一个浏览器」当成一个需要认真对待的问题。ego lite 想补齐的正是这一块。

▍下一步计划

作为一个初创团队，我们还在快速迭代中，ego lite 还不够完善。以下是我们目前知道的几个明显限制：

资源占用偏高。它本身是一个完整的 Chromium 分支，再加上多个 Space 并行运行，内存消耗不算低。我们正在做优化。

开发精力有限，我们目前专注于 macOS 版本，并希望以最好的表现来接受市场反馈。在发布后，我们已经收到了不少用户需要 Windows 版本的反馈，后续会尽快推出。

我们还希望在后续版本中加上「经验复用」的能力，设想是把成功执行过的任务沉淀为可复用的技能，让重复任务少走弯路。

▍关于我们

我们是一个还在快速迭代的小团队，伙伴们对于开源社区有极大的热情，我们的 Github 仓库仅仅发布不足 2 个月，上周就拿到了 Github Trending 的好成绩，突破了 5200 stars 并且还在迅猛增长。就在昨天，一个挺奇幻的时刻：Twitter 联合创始人 Jack Dorsey 的新开源项目 Buzz 登上 GitHub Trending 后，他分享了一张榜单截图，而我们也刚好出现在截图里，排名还比 Buzz 高一位。

在开发 ego lite 的同时，持续为 Chromium 贡献着代码和功能，今年还为 Chromium 贡献了 CSS shape () 特性、窗口调整时的动画帧率等诸多功能，并在 Google I/O 2026 开发者大会上被重点介绍。

ego lite 是免费产品，无需注册账号，你只要借助自己的 Agent 就能使用。

我们并不认为它现在已经足够完善，希望踏实地一个版本一个版本打磨，把它做成一个人和 Agent 都用得顺手的浏览器。

如果你也经常用 Claude Code、Codex、Cursor 处理网页任务，欢迎试用，也欢迎直接提出批评，我们很想听到真实的反馈。

官网 ：https://lite.ego.app/

WinAirCast

‍ isayyeah | Windows

对于同时使用 Windows PC 和苹果设备的用户来说，将电脑的声音无线串流到 HomePod 一直是个常见的痛点，因为 Windows 原生并不支持 AirPlay 协议。

很多用户不得不去寻找第三方的音频串流软件（例如 TuneBlade 或 AirParrot）。但在实际体验中，这些老牌软件往往存在一些明显的短板：

高延迟：传统的缓冲机制导致看视频时容易出现声画不同步。

系统兼容性差：像 TuneBlade 这样停止维护多年的软件，缺乏对 Windows 11 等新系统、新架构的适配与优化，运行时容易出现闪退，甚至引发底层内核报错。

设备支持滞后：面对采用全新同步机制的 AirPlay 2 设备（如新一代 HomePod），旧软件连接成功率较低，也无法将多台音响组成立体声同步播放。

为了给 Windows 用户提供一个更现代、更稳定的解决方案，我们使用 Rust 语言从零重写了底层协议栈，推出了一款原生支持 AirPlay 2、向下兼容 AirPlay 1 的低延迟音频串流工具 ——WinAirCast。

今天，我们就来详细介绍一下这款产品，看看它能为你的桌面音频体验带来哪些改变。

▍1. 所有接收器集中管理：简洁直观的主界面

打开 WinAirCast，网络中的全部 AirPlay 接收器（无论是 HomePod、Apple TV，还是支持 AirPlay 1 的早期 AirPort Express）都会集中呈现在同一个设备列表中。

每个音箱的连接状态、当前编解码器、实时延迟以及独立的音量滑块都一目了然。你无需经历繁琐的设置流程，即可一键将桌面音频推送至目标设备。

▍2. 桌面悬浮小窗：随时掌控播放状态

除了完整的控制主窗口，WinAirCast 还设计了轻量级的桌面悬浮小窗。

你可以将小窗置顶放置在桌面任意位置。在进行日常工作、浏览网页或游玩游戏时，无需切出主界面，直接通过悬浮窗就能快速调整音量、查看连接状态或一键断开 / 连接音箱，将对桌面的干扰降到最低。

▍3. 桌面设备停靠栏：吸附边缘，随用随点

针对极简桌面党，WinAirCast 独创了 「桌面设备停靠栏（Device Dock）」。

停靠栏可以自动吸附在屏幕边缘，视觉风格与 Windows 11 Fluent Design 完美融合。当你需要控制音箱时，只需将鼠标轻点屏幕边缘，设备列表和胶囊音量条就会顺滑展开；不用时则隐匿于边缘，给你如同操作系统原生功能一般的沉浸式交互。

▍4. 按设备调整推流参数：45ms 低延迟与发烧级编码

延迟与稳定性是无线音频串流的核心指标。WinAirCast 完整支持了 AirPlay 2 的 PTP（精确时间协议）微秒级时钟同步，不仅连接稳定，更实现了多台音响真正的立体声或多房间分组同步播放。同时，底层协议栈向下兼容 AirPlay 1（RAOP），老设备也能稳定使用。

WinAirCast 允许用户按设备独立配置推流参数：在局域网条件良好时，开启 「实时流媒体」 模式可以将延迟极限压至45ms左右，有效解决看视频不同步的问题。除了标准的ALAC（无损压缩）编码外，软件还开放了PCM（未压缩 L16）模式，跳过编解码开销，保留更完整的音频细节。

在底层调度上，WinAirCast 引入了 WindowsMMCSSPro Audio（专业音频）调度服务，为推流线程赋予最高优先级，即使电脑后台高负载满载渲染，也能有效防止爆音与卡顿。

▍5. 图形均衡器与预设：内置 10 段专业调音

受限于房间声学环境，HomePod 的默认调音未必适合所有人，而 Windows 自带的音频设置又比较简陋。

我们在软件内集成了一套高精度的10 段图形均衡器（EQ）与前级余量（Pre-amp）控制器。底层的 DSP 算法加入了防削波处理，你可以精确调整每个频段的声音，并将满意的参数保存为预设，方便在不同音响设备间一键切换复用。

▍6. 灵活的捕获方式与静音待机：单应用隔离与 DRM 穿透

传统的全局录音方式在多任务处理时往往不够用。WinAirCast 提供了更强大的音频路由选项：

单应用捕获：指定仅将 Spotify 、播放器或浏览器的声音推送到 HomePod，而游戏和系统通知声依然保留在电脑本地耳机里，互不打扰。

虚拟音频与 DRM 穿透：播放受 DRM 加密保护的流媒体（如 Netflix、Apple Music）时，常规全局录音通常只能捕获到静音。WinAirCast 支持直接捕获第三方虚拟声卡（如 VB-Cable），将加密音频转接至虚拟设备即可完美实现无损串流。

静音自动待机：当电脑停止播放音频一段时间后，软件会自动暂停推流并让音箱进入待机状态，省电的同时减少网络占用。

▍产品功能横向对比

为了让大家更直观地了解 WinAirCast 的产品定位，我们整理了一份与同类软件的功能对比表：

▍总结

打破生态壁垒，让好的设备发挥出它应有的价值，这就是我们开发 WinAirCast 的初衷。我们希望为 Windows 用户提供一款稳定、低延迟且现代化的音频串流工具。

目前，WinAirCast 已在 Microsoft Store 正式上架。软件采用一次买断制（全球定价 $2.99，特定地区有价格优惠），无订阅费用。我们提供了长达 15 天的免费完整功能试用（无需绑定支付方式），方便你在购买前充分测试自己的网络和设备兼容性。

如果你希望在 Windows PC 上获得优秀的 HomePod 连接体验，欢迎下载试用！

官网下载：https://winaircast.com/

小窗译

‍ 大熊bear | macOS

我不是因为看不懂英文，才做了小窗译。恰恰相反，大多数时候我已经看懂了七八成。为了弄懂剩下那两三成，我却总要在原页面、翻译工具和 AI 之间来回切换。

为了效率和体验，我选择自己打造一个翻译工具。

读英文文章时，真正让我停下来的，常常是一句来回看了两遍、每个词都认识，却仍拿不准作者到底在说什么的长句。我会把它复制到 AI 里，先看一遍翻译；如果还是不确定，就把前后文一起放进去再问一次。等再回到文章，那句话虽然弄明白了，原本顺着往下读的节奏也断了。

轮到自己写，麻烦又换了一种。我通常知道自己想说什么，也能写出一个意思大致正确的版本，却很难判断它读起来是不是太书面、太生硬，或者比原意更冷淡。于是我又把草稿交给 AI，说明这是一条社交媒体回复，再让它 「自然一点」「别太正式」。有时来回改了两三轮，最后真正采用的，可能只是其中一个词。

说到底，我的需求很简单：读的时候把意思弄明白，写的时候把话说得地道。麻烦在于，每次都要把原文、上下文和草稿搬到另一个工具里，处理完再搬回来。

后来我问了身边几位朋友，发现大家多少都有类似的经历：有人读到长句会顺手打开翻译工具，有人写完之后总要再找 AI 确认一遍。

于是我开始做小窗译。

它最初面对的不是 「还缺哪一种翻译功能」，而是：能不能让翻译离正在发生的事情近一点，让人看懂以后，马上接着做原来的事？

▍第一个问题：功能越多，快捷键越不像快捷键

真正开始做以后，我遇到的第一个问题甚至不是翻译质量，而是用户应该怎样使用这些功能。

最直觉的做法，是为每一种翻译方式分配一组快捷键：划词翻译一个，剪切板翻译一个，截图翻译再来一个；以后增加输入翻译和实时翻译窗，就继续往下加。

从程序的角度看，这套方案很整齐。每个模式都有自己的入口，熟练以后也能一步直达。但我很快发现，开发者眼里的 「清楚」，不一定等于使用者手上的 「顺手」。

小窗译提供的快捷键（ ⌘+E 可以快速唤起划词翻译）

划词翻译足够高频，用过几次就能形成习惯。截图翻译却可能几天才遇到一次。真正碰到一块无法复制的文字时，我往往知道小窗译里有这个功能，却想不起当初给它设置了哪组按键。

一个快捷键只有在记得住的时候，才算快捷。如果还要先打开设置确认，再回到刚才的页面，那么所谓 「快速调用」，反而制造了新的中断。

这件事让我改变了思路：与其要求用户记住软件里的所有模式，不如让软件替用户记住。

于是，小窗译默认只保留两个需要形成肌肉记忆的入口：⌘E 用于最高频的划词翻译，⌘J 用于打开快捷面板。

按下 ⌘J，所有翻译方式都会摆在面板里，我不用再回设置里确认快捷键。用得多了，字母又会变成第二段操作：比如 ⌘J → P，直接进入截图翻译。

不熟悉时看着选，熟悉以后顺着按键继续操作。

快捷面板并不是又增加了一个入口。恰恰相反，它是在把入口收回来：偶尔使用时，面板负责提醒；频繁使用以后，手指自然会找到更短的路径。至于程序内部把它们分成多少种模式，不应该成为使用者的负担。

快捷面板解决的是怎样来到翻译前。可窗口出现以后，它究竟应该给我多少东西？

▍一个结果究竟够不够

Bob 将多个翻译引擎并排呈现做成了一种很有辨识度的体验。面对一句拿不准的表达时，把几个结果放在一起比较，确实很有价值。

最初思考结果窗口时，我也很容易沿着 「更多就是更好」 的方向走：既然能同时拿到几个答案，为什么不一次都摆出来？

但回到真实的阅读过程，大多数时候，我并不是面对一句完全无法理解的英文。更多情况是，整段内容已经看懂了七八成，只是某个从句关系不够确定，或者一个词放在当前语境里拿不准。

我需要的不是重新学习这段话，而是补上缺少的那一小块信息，然后继续往下读。如果每次划词后都同时出现三四个答案，原本只需要一次确认的问题，反而会变成一道选择题：哪个更准确？为什么这里用了不同的词？我要不要再比较一下？

答案更多，不一定意味着阅读更快。于是，小窗译的划词翻译默认先给出一个结果，窗口尽量保持简洁，不主动把更多选择推到眼前。

先补上影响理解的那一小块信息，再继续往下读。

如果这个结果不够自然，或者某个表达仍然让我拿不准，再点开 「对比结果」，把其他翻译引擎的答案放到一起。

需要斟酌时，再展开其他引擎的结果。

先给一个结果，不等于拒绝比较，只是把比较留到真正需要的时候。这个原则对句子很有效，却很快遇到了一个明显的例外：单词。

拿 pitch 举例。一个普通翻译结果可能告诉我它是 「推销」。答案本身没有错，但 pitch 也可能指音高、球场，或者一次产品提案。离开上下文，只返回其中一个中文词，很可能只是给出了一次正确但无用的回答。

整句翻译和单词查询，表面上都叫翻译，背后的问题却不一样。翻译句子时，我通常已经知道它在讨论什么，只需要补齐完整含义；查询单词时，我很可能真的不知道它是什么意思，也无法提前判断哪个义项符合眼前的场景。

所以，我没有把单词当成一句更短的句子，而是单独做了词典模式：把常见义项、它们之间的差别，以及帮助理解的解释和例子放在一起，再让用户结合上下文判断。

最重要的是，它还用英文提供了词义的解释，就像柯林斯词典一样，英英词典对理解词义的帮助非常大。

查询单词时，自动进入词典模式

我并不想再做一部包罗万象的词典。词典模式要解决的，仍然是阅读停住的那一刻：先把最影响理解的歧义摊开，让人尽快回到原来的句子里。

到这里，所有设计其实都依赖一个没有说出口的前提：文字必须能够被选中。

▍当文字无法被选中

截图翻译最容易想到的实现方式，是先用 OCR 提取文字，再把识别结果送去翻译。最早思考这个功能时，我也把它理解成一条很直接的流水线：截图、识别、翻译、显示正文。

对于排版规整的文章，这条路通常没有太大问题。但截图里的内容并不总是从上到下排列的正文。

它可能是一张信息图，几段文字分别对应不同图标；也可能是一张聊天截图，双方的消息左右交错；还可能是一个软件界面，按钮、标题和说明散落在不同区域。

这时会出现一种很奇怪的失败：OCR 把字认对了，翻译也没有明显错误，我却还是看不懂这张图。因为文字一旦被抽出来拼成连续正文，标题、按钮和说明原本的对应关系也一起消失了。

我后来意识到，对图片来说，文字所在的位置本身也是信息。这时我想到微信图片翻译带来的那种体验：与其把文字从图片里抽走，不如把译文放回它原来的位置。

于是，我没有再把 OCR 识别出的文字单独抽出来，而是让译文回到对应的区域。这样保留下来的不仅是句子的意思，还有它在画面里的位置。

截图翻译功能

如果只是想看懂截图，可以直接阅读译后的图片；需要继续分享或整理时，原文和译图也应当能方便地从这里带走，而不是再做一轮截图和抄录。

提取翻译内容

把译文放回原图，保住了文字之间的位置关系。但这个办法仍然有一条边界：画面必须停下来。

看英文课程、产品发布会或者没有中文字幕的视频时，截图翻译可以应急，却不适合连续使用。截一次图，等待结果，看完，再截下一张。内容还在播放，翻译过程本身却不断迫使人暂停。

当截图开始重复，我意识到需要解决的已经不是 「怎样更快地截下一张」，而是能不能让翻译留在这块不断变化的画面旁边。这也是实时翻译窗出现的原因。

打开实时翻译窗以后，可以把它放在屏幕上的一块区域。它更像一个能够移动和缩放的透明取景框：框内画面发生变化，就继续识别其中的文字，并把译文放回对应位置。

对于位置相对固定的视频字幕、在线课程和软件演示，不必再一张张截图，也不必把视线搬到另一个翻译页面。翻译跟着内容一起变化，原来的画面仍然是阅读的主体。

像透镜一样，放到哪里，就能翻译哪里的内容

实时翻译窗真正改变的不是识别频率，而是我终于不用为了理解下一句，反复离开正在看的画面。

到这里，小窗译解决的主要还是开头提到的第一种情况：别人写的。可我最初想解决的，还有另一半 —— 那些我准备发出去的话。

▍从看懂，到把话说准确

阅读和表达看起来都依赖翻译，衡量结果的标准却不一样。

阅读时，我关心的是能不能迅速理解意思。只要译文准确到足以消除疑问，我就可以继续往下看。写作时，我还会关心一句话听起来像什么。

同一句中文，可以被译成礼貌而正式的英文，也可以更简短、更像社交媒体上的口语。有些表达逐字翻译没有错误，读起来却会显得生硬；有些词意思相近，放进具体语境后，传递出的态度可能完全不同。

这也重新解释了前面那个问题：为什么小窗译默认只显示一个结果，却依然保留多引擎对照？

阅读时，一个结果是在帮我尽快离开翻译；表达时，几个结果则是在帮我判断究竟想怎么说。

例如回复海外社交媒体上的帖子时，我不只想确认 「这句话能不能被看懂」，还会在意它会不会太郑重、太冷淡，或者带上一层原本没有的语气。这时，我可以先看一个英文结果；如果仍然拿不准，再把几个引擎的答案放到一起。

几个结果不是等待投票的 「正确答案」，而是让我看见同一句话在措辞和语气上的几种走向，再决定哪一种更接近自己原本想说的话。

但当输入从公开帖子变成未发布的文案、内部资料或客户沟通，语气之外又多了一条边界：这些文字会被发送到哪里？

在线翻译引擎和大模型提供了很好的质量，也是我日常使用的重要选择。但面对尚未发布的产品资料、内部沟通内容，或者只是自己还没有整理好的草稿，我有时会在按下发送前犹豫一下。

所以，小窗译也提供本地离线模型。模型准备好以后，翻译可以直接在电脑上完成。对于那些不想离开本机的内容，不必在 「要不要翻译」 和 「要不要上传」 之间二选一。

支持自定义翻译服务和模型，提供两个本地翻译模型

本地和在线并不是谁取代谁。阅读公开内容、希望得到更多表达选择时，可以使用在线引擎；面对不想离开本机的文字时，可以切换到本地模型。速度、质量和隐私之间没有唯一答案，我更愿意把选择留给使用者。

▍把注意力还给原来的事情

回头看，小窗译并不是从一张完整的功能清单里长出来的。每解决一次中断，下一层问题才显出来：记不住的快捷键、被 OCR 拆散的画面、来不及截下来的字幕，以及那些不想发送出去的文字。它们最后都指向同一件事 —— 翻译本身不应该成为新的中断。

我每天仍然会遇到那两种情况：别人写的，以及我准备发出去的。小窗译不会替我读完文章，也不会替我决定一句回复应该是什么语气。它真正应该做的，是在我停住的那一刻补上缺少的信息，然后把我送回刚才那句话、那个画面，以及那条还没有发出的回复。

小窗译可以从 translatewindow.app 下载。免费版可满足绝大多数日常需求，如需购买 Pro 版，少数派用户输入优惠码SSPAI，可获得 15% 优惠折扣。

下载 ：https://translatewindow.app/

/欢迎投稿/

/产品推荐/