北京
96%的开发者不信任AI生成的代码，但48%的人懒得检查——这是Sonar最新报告里的数据。信任危机和懒惰并存，像极了我们面对屏幕阅读器时的矛盾：想要方便，又不愿意把数据交给云端。
一位叫paradisecy的开发者干脆自己动手。他用两个开源模型搭了一套本地流水线：屏幕截图→文字识别→语音播报，全程不上传任何数据。没有API密钥，没有订阅费，连显卡用的都是AMD。
从"眼累"到"手懒"：一个产品经理的自救
paradisecy的身份很典型：产品经理出身，每天在各种文档和界面之间切换。他的痛点不是"看不见"，而是"看累了"——长时间盯着屏幕，眼睛酸胀，但又不想错过信息。
市面上的解决方案要么贵，要么危险。云端TTS（文本转语音）服务按字符计费，读一本电子书可能花掉几十块；更麻烦的是隐私——你把屏幕内容传给别人，相当于把工作内容、邮件、甚至密码都交了出去。
他的解法很直接：所有计算本地化。OCR（光学字符识别）用LightOnOCR-2-1B，TTS用Kokoro-82M，两个模型都从HuggingFace自动下载，第一次运行后就不再依赖外部网络。AMD显卡通过ROCm 6.3跑OCR，CPU跑语音合成，延迟控制在100毫秒左右。
这套配置的消费级门槛很低：一块能跑ROCm的AMD显卡，加上任意现代CPU。
像素级偷懒：diff检测省下的算力
真正让这套系统"可用"的不是模型精度，而是一个工程细节：像素差异检测。
paradisecy在流水线里加了一步——每次截图后，先和上一帧做像素级对比。如果变化率低于1%，直接跳过OCR和TTS。读静态页面时完全静音，新内容加载才触发播报。
这个设计暴露了产品经理的思维惯性：不是"更快"，而是"更省"。算力是本地资源，能省则省；用户的注意力也是资源，不必要的播报就是噪音。
命令行参数很直白：
uv run python capture.py --diff-threshold 1.0
阈值可调。看小说设低一点，盯盘设高一点，避免股价小数点变动就触发播报。
自动翻页：一个被忽视的"杀手功能"
工具开源后，GitHub上的讨论集中在技术实现：ROCm兼容性、PyTorch版本、模型量化。但paradisecy自己最喜欢的功能被低估了——自动翻页。
用户可以画两个矩形：一个框住阅读区域，一个框住"下一页"按钮。TTS播报完成后，如果屏幕静止超过设定时间，系统自动点击翻页。配合Kindle for PC，能完整读完一本书，全程不用碰鼠标。
这个设计的微妙之处在于时序控制：不是"播完就点"，而是"播完且静止才点"。防止页面还没加载完就误触，也避免用户手动暂停时被干扰。
命令同样简洁：
uv run python capture.py --next-btn -i 2
-i 2表示检测间隔2秒，给页面加载留缓冲。
谁在用：从无障碍到"摸鱼"
paradisecy列了五个使用场景，优先级很有意思。第一个是"免提电子书阅读"，第二个是"金融仪表盘实时播报"，第三个才是"无障碍工具"——为那些本身不支持屏幕阅读器的应用补位。
这个排序透露了目标用户画像：不是视障群体（他们有更成熟的NVDA、JAWS），而是视力正常但想"解放眼睛"的人。终端日志播报、网页朗读，都是程序员场景。
一个意外的反馈来自交易员群体。有人用它盯盘，OCR识别价格变动，TTS播报关键阈值，diff检测避免频繁骚扰。本地运行的优势在这里被放大：延迟稳定，不会因为网络抖动错过信号。
安装依赖也尽量轻量化：slop负责画矩形选区，xdotool模拟鼠标点击，portaudio和libsndfile处理音频。Ubuntu/Debian系一条命令搞定，其他发行版稍作调整。
开源模型的"拼图游戏"
LightOnOCR-2-1B和Kokoro-82M都不是为"屏幕阅读"设计的。前者是通用OCR，后者是多语言TTS。paradisecy的工作是把它们串成流水线，补上工程细节。
这个模式正在变得普遍。HuggingFace上有大量"半成品"模型：能力足够，但缺少最后一公里。开发者像拼乐高一样组合它们，用几百行Python胶水代码解决特定问题。
Kokoro-82M尤其值得关注。82M参数，CPU实时运行，音质接近云端服务。它的训练数据和方法论没有公开，但权重文件随便下载。这种"开放权重、封闭训练"的灰色地带，正在重塑AI应用的开发成本。
paradisecy没有优化模型本身，他的贡献是"让它跑在AMD显卡上"。ROCm的生态位很尴尬：NVIDIA垄断了CUDA，AMD用户长期被忽视。一个能跑通ROCm的OCR流水线，本身就是稀缺文档。
项目开源一周，Star数没过千，但Issues很活跃。有人在问M系列Mac的支持，有人在折腾NVIDIA的适配，还有人想加Whisper做实时字幕。典型的开源项目早期状态：核心功能稳定，边缘需求爆炸。
如果屏幕阅读器能"看"任何界面、读任何文字、点任何按钮，我们还需要为每个应用单独做无障碍适配吗？还是说，这种"外挂式"方案反而会让开发者更偷懒——既然用户能自己解决，官方支持就不紧急了？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
