我让 deckedit.com 上的 OCR 中断了约 24 小时。对不起。
如果您在 2026 年 4 月 19 或 20 日尝试转换幻灯片但失败或卡住，以下是事情的经过、我为何没能更早发现，以及我做了什么改变，避免相同情况再次发生。
发生了什么
在 2026 年 4 月 19–20 日的约 24 小时期间，deckedit.com 上的幻灯片识别步骤对大部分用户失效。上传要么报错，要么看起来卡住。网站本身正常加载；坏掉的是读取幻灯片文字的部分。
我的数据有风险吗？
没有。DeckEdit 完全在您的浏览器中运行，您的文件从未上传到任何地方。这次失效是浏览器内部引擎的启动错误 — 没有任何数据送到服务器，因为这套架构本来就不会这么做。
原因是什么
GPU 加速的 OCR 自 2026 年 1 月起就一直在正式网站上运行，已经稳定运行数月。昨天，我花了大约十一个小时，专门让引擎的错误信息变得更诚实 — 出问题时给出更清楚的说明、提供一键切换到 CPU 模式的按钮，并移除了一些可能掩盖真实错误的重试逻辑。这些改动本身做到了我希望它们做到的事，但也带来了我没预料到的后果：当「掩盖」被拆掉之后，引擎的「后台辅助线程启动模式」与正式网站从 1 月起一直依赖的一小段支持性代码之间，一个潜在的冲突就被暴露了出来。这个冲突其实三个月以来一直安静地存在，从未以用户看得见的方式浮出水面。是我为了诚实而做的这些改动，把它的藏身之处拆掉了。网站本身正常加载，但引擎无法完成启动，识别也因此失败。
我为何 24 小时没注意到
我在开发预览中测试了这项改动，它确实能用。问题是：那段牵涉到此次冲突的支持性代码，在预览环境中是被刻意跳过的 — 从一月起就一直如此，目的是让开发更快。所以我的预览跑的是一条结构上比正式网站更简单的启动流程，根本不会走到失败的那条路径上。「在预览中能用」这件事是真的，但对这次的改动完全没有参考价值。这是我的责任。
已经修复了什么
我让浏览器内的引擎，在正式网站上也使用比较简单的主线程启动流程 — 也就是我预览环境中一直成功运行的那一套。GPU OCR 已恢复正常:在支持 GPU 的设备上,每张幻灯片只需数秒。页面刚加载后处理的第一张幻灯片,可能会出现一到三秒的卡顿,那是 GPU 在编译着色器；之后每一张都是全速。在不支持 GPU 的设备上,OCR 会退回到用 CPU 跑、速度较慢 — 这是硬件本身的限制,不是软件层面能解决的。
我做了什么改变以避免相同情况再次发生
未来任何涉及浏览器内引擎启动方式的改动 — 包括启动模式、GPU 初始化,或是那段在预览中被刻意跳过的支持性代码相关的任何部分 — 都必须在正式网站(deckedit.com)上实际验证,才能算完成。对这类改动而言,「在预览中能用」已经不能再算作有效的验证。我已将这条规则写入我自己的工作笔记,提醒自己不要再忘记。
谢谢您
如果您今天回来再试了一次，并且成功了，谢谢您给的第二次机会。如果您在 4 月 19 或 20 日放弃了 — 我理解，并且抱歉。这个工具是免费的，但您的时间不是，而我浪费了您一些时间。
— Keith Li，构建 DeckEdit 的人