我讓 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 的人