我让豆包帮我写季度汇报，它写了 3000 字。我决定听完它。

不是不感激。豆包写得确实好。结构清晰，数据翔实，连"本季度核心成果"和"下季度展望"的过渡都比我自己写的流畅。问题在于，三千字的季度汇报出现在下午四点的屏幕上，而我已经盯了一天的文档、邮件和企微群聊。我的眼睛在抗议。

我试着从头读。读了大概六百字，也就是第二段结束的位置，我发现自己在滚动鼠标但没有在处理信息。字在视网膜上滑过，但大脑没接收。这种体验你一定有过——不是内容不好，是眼睛和大脑之间的通道堵了。

那天我装了 CastReader。一个免费的 Chrome 扩展。装完之后回到豆包页面，每条 AI 回复的旁边多了一个小喇叭图标。点一下，豆包的三千字季度汇报就开始读出来了。

声音不是那种一字一顿的机械音。是有节奏的、带停顿的、接近真人播报的 AI 语音。不完美，偶尔能听出合成感，但完全不影响理解。更关键的是，它读的时候屏幕上对应的段落会高亮，跟着朗读进度走。你可以闭眼听，也可以睁眼跟着看——两种模式都可以。

我选择了闭眼。靠在椅背上，耳机里传来我的季度汇报。三千字，大概七分钟。我在第三分钟的时候发现了一个数据错误——豆包引用了 Q2 的数字而不是 Q3 的。如果我是用眼睛扫过去的，我百分百会漏掉。但听的时候，大脑对数字的敏感度反而更高，因为它没有被视觉疲劳拖累。

从那天起我几乎每天都在豆包上用 CastReader。

豆包是我主力 AI 工具。写邮件找它，分析数据找它，翻译文档找它，debug 代码也找它。它的回复普遍比较长——不是废话多，是信息量大。一个"帮我对比 MySQL 和 PostgreSQL 的优缺点"的问题，它能给你 1800 字，涵盖性能、扩展性、生态、社区、许可协议和具体场景建议。如果你有时间有精力坐下来读，每一段都有价值。但谁有那么多时间坐下来读呢？

CastReader 解决的就是这个问题。一键朗读，该段落高亮，听完自动下一段。我现在的使用模式是：问豆包一个复杂问题，等它回复完，点喇叭，然后去倒杯水、站起来走一走、或者切到另一个窗口处理别的事。耳朵在接收信息，眼睛在休息或者干别的。两个通道分开用，效率反而更高。

有个场景特别适合：代码解释。我让豆包帮我分析一段 Python 代码的性能问题，它给了一千多字的分析，包括瓶颈定位、优化建议和重写示例。如果我同时看代码和看解释，两个屏幕来回切换，大脑在两种模式之间反复跳跃，很累。但如果我听解释、看代码——耳朵听分析，眼睛看代码——就顺畅多了。一个输入通道给自然语言，一个给代码。这不是什么新发现，但之前没有好用的工具做到这一点。

技术上有个细节值得一提。豆包的网页不是标准的 HTML 结构。它的页面元素用的是动态生成的 class 名，段落不是用 <p> 标签，而是用自定义的 div 容器。普通的网页朗读工具遇到这种页面结构会直接抓瞎——要么读出一堆按钮文字和界面元素，要么什么都读不出来。CastReader 有一个专门针对豆包的提取器，能准确识别哪些是 AI 回复内容、哪些是界面元素，只读回复，不读杂音。

安装只需要一步：打开 Chrome 应用商店，搜 CastReader，添加到 Chrome。不需要注册账号，不需要填邮箱，不需要付费。免费，真的免费，不是"前 500 字免费"那种免费。装好之后打开豆包，开始对话，AI 回复出来之后点旁边的🔊按钮。就这样。

CastReader 也支持其他 AI 平台——ChatGPT、Kimi、DeepSeek、Claude、Gemini。每个平台都有专门的提取器。但我用得最多的还是豆包，因为豆包是我用得最频繁的 AI，也是回复最长的那个。

那份季度汇报后来改了数据错误，提交了，老板说写得不错。她不知道这是豆包写的。她更不知道，我连自己交上去的汇报都没完整"读"过——但我听完了每一个字。