我用豆包三个月了。前两个月用得像所有人一样。第三个月效率翻了一倍。

差别不在 prompt 技巧。网上教你怎么写 prompt 的文章已经够多了——"你是一个资深XX专家"、"请按照XX格式输出"、"一步一步思考"——这些有用，但不是瓶颈。瓶颈是你拿到豆包回复之后怎么处理它。

豆包的回复通常很长。这不是缺点——是优势。它不像某些 AI 给你三句话敷衍了事。豆包给你完整的分析、详细的步骤、多角度的建议。但一千五百字的回复出现在屏幕上，你需要花五到八分钟读完它。一天和豆包对话二十次，那就是一百到一百六十分钟的阅读时间。两个多小时。花在读 AI 回复上。

我的第三个月发生了什么？我装了 CastReader。

CastReader 是一个免费的 Chrome 扩展。装上之后，豆包的每条 AI 回复旁边多了一个🔊按钮。点一下，那条回复就开始用 AI 语音朗读。你可以继续做别的事——打开下一个 tab 写文档、回个微信、去倒杯水。耳朵在接收豆包的回复，眼睛在做别的事。一千五百字从五分钟阅读变成了三分钟背景收听。而且你不需要盯着屏幕。

这是第一个技巧，也是最重要的一个：朗读长回复。

第二个技巧：多轮追问比一次性大问题更好。大部分人（包括之前的我）喜欢一次性把所有需求塞进一个 prompt："帮我写一份Q3数据分析报告，包含用户增长、留存、收入、竞品对比、下季度建议"。豆包会给你一个三千字的回答，覆盖所有方面，但每个方面都不够深。更好的做法是分步追问："先看一下Q3的用户增长数据，有什么值得注意的趋势？"等它回复后，针对它提到的某个点继续追问。五轮追问得到的分析深度远超一次性大问题。而且每轮回复只有几百字，用 CastReader 听也更轻松。

第三个技巧：代码讲解边听边看。这个技巧是我一个做前端的同事教我的。他让豆包分析一段 React 代码的性能问题，豆包给了一千二百字的解释——从 useEffect 的依赖数组讲到 memo 的使用场景再到虚拟列表的优化方案。他没有读这一千二百字。他点了 CastReader 的🔊按钮，然后切到 VS Code 看代码。耳朵听分析，眼睛看代码。两个输入通道同时工作。他说这种方式理解代码的速度比"读一段解释、看一段代码、再读一段解释"快了一倍。我试了之后表示同意。

第四个技巧：写完之后听一遍。我让豆包帮我写周报、写邮件、写产品文档。豆包写完之后，我不是直接读一遍确认——我用 CastReader 听一遍。为什么？因为读自己（或 AI）写的文字，眼睛会自动脑补和修正。你看到一个别扭的句子，大脑会自动把它读顺了——你觉得没问题，但别人读起来会觉得奇怪。听的时候不会这样。听觉是线性的、不会跳过的、不会自动修正的。一个重复的用词、一个逻辑不通的过渡、一个前后矛盾的数字——听的时候会特别刺耳。我用这个方法在豆包写的周报里抓到过两次数据不一致，在邮件里抓到过一次语气不对。

第五个技巧：会议纪要提炼。开完会之后把会议纪要丢给豆包："帮我从这份纪要中提取行动项，标注负责人和截止时间。"豆包整理出来之后，用 CastReader 听一遍。三百字的行动项清单，一分钟听完。比你重新打开纪要去翻找快得多。而且听的时候如果发现遗漏，你脑子里还残留着会议的印象，能立刻补充。

这五个技巧的核心逻辑是一样的：减少你盯屏幕读豆包回复的时间。豆包负责思考和生成，CastReader 负责把生成的内容读给你听，你负责判断和决策。三方分工。

CastReader 安装：Chrome 应用商店，搜 CastReader，添加到 Chrome。免费，无限制，不需要注册。打开 www.doubao.com，每条回复旁边就有🔊按钮。

第三个月比前两个月效率翻倍，不是因为我学会了更好的 prompt，是因为我不再用眼睛读回复了。