背景與問題
大多數程式學習平台建立在四個從未被明說的假設上：學習者有筆記型電腦、有寬頻網路、能流暢閱讀英文、且付得起訂閱費或隸屬於已付費的機構。InfoQ 上一篇由 Efiwe 創辦人 Chidi Nwaogu 撰寫的工程實錄，正是從打破這些假設開始。Nwaogu 曾經營線上程式學院，親眼看著學生在課程中途消失——追蹤後發現他們幾乎都不是主動離開，而是網路連線撐不完一堂課。某一屆 80 名註冊學生中，只有 6 人畢業。
Efiwe 是為這個現實打造的平台：跑在智慧型手機瀏覽器裡，初次載入後即可離線運作，學生提交的程式碼在裝置本機執行，不需要持續的數據流量。平台已被 160 個國家超過 22,000 名學習者使用，並在奈及利亞的拉各斯與奧貢州、印度北阿坎德邦進行過學校試點。這篇文章的價值不在教學法，而在於它誠實記錄了哪些環節在真實的低階裝置上壞掉——儲存配額、冷啟動、以及失敗路徑設計，這些問題對任何面向受限裝置與間歇性連線的產品都有參考價值。
為什麼是 PWA 而不是原生 App
第一個架構決策是發布管道。原生 Android App 看似理所當然，但團隊基於三個理由放棄：其一是安裝摩擦，一個 APK 在還沒有任何內容前就是數十 MB 的下載量，對必須精打細算數據流量的學習者而言是實質門檻；其二是更新節奏，Service Worker 的更新在下次造訪時自然生效，而商店版本在習慣延遲更新以省流量的市場裡，會留下一大群跑著數月前舊程式碼的客戶端；其三是執行環境，瀏覽器的 WebAssembly 讓 Python、SQL、JavaScript、HTML 能在所有平台用同一套方式本機執行，不需要伺服器。代價是必須繼承瀏覽器的儲存模型與配額行為，而這正是後續最多生產事故的來源。
在裝置上執行程式碼
傳統的程式批改流程是把提交送到伺服器沙箱執行再回傳結果，每次嘗試都要一個網路往返。在奈及利亞伊傑布奧德這類連線不穩、學生一道題可能要試十幾次的教室裡，這個模型根本不可用。Efiwe 改用 sql.js（編譯成 WebAssembly 的 SQLite）處理 SQL，用 Pyodide（編譯成 WebAssembly 的 CPython）處理 Python。兩者都龐大、初始化緩慢，且一旦跑在主執行緒上就會凍結畫面。
團隊定下的規則是：執行環境永遠不在主執行緒初始化，也永遠不提前初始化。課程選定後才以惰性方式啟動 Web Worker，題目畫面的首次繪製不等它；Worker 內部以旗標防止重複初始化，模組優先從快取取得，讓離線一週的裝置仍能啟動，並設有 45 秒的初始化逾時。另一個值得注意的設計是：學生寫錯程式而拋出例外，在這裡是常態流量而非錯誤，執行路徑的每一層都把失敗當成資料回傳，絕不讓它殺掉 Worker。SQL 批改也不比對輸出字串，而是比對結果的欄位結構與資料內容，讓格式、別名或欄位順序不同但邏輯正確的答案也能通過，同時回傳失敗原因欄位，讓系統能告訴學生「欄位對了但篩選條件錯了」，而不只是一句「答錯」。
儲存層的教訓
Efiwe 支援 246 種語言，翻譯後的題目文字會快取在裝置上，讓選擇約魯巴語或印地語的學習者不必每次重新下載，也讓翻譯在離線時存活。團隊一開始把這個快取放在 localStorage，結果同時踩中兩個問題：容量上，localStorage 每個來源通常只有約 5MB，數百道題目乘上幾種語言就會爆量，寫入拋出 QuotaExceededError；更隱蔽的是 localStorage 的同步 API，每一次讀寫都阻塞主執行緒，在入門級 Android 裝置的慢速快閃記憶體與吃緊 CPU 上，啟動時的一次大型同步讀取就是肉眼可見的停頓。
搬移到 IndexedDB 是容易的決定——它是非同步的、配額按可用磁碟比例計算、且能直接存放結構化資料。真正花工夫的是遷移：既有使用者資料還在舊儲存裡，很多人一離線就是好幾天，會在不可預期的時間碰到新版程式碼，硬切換等於默默丟棄他們的快取與進度。團隊採用雙讀窗口策略：先讀新儲存，找不到就回頭讀舊儲存一次，把讀到的資料升級寫入新儲存並刪除舊鍵。兩個細節是關鍵：舊資料的 JSON.parse 必須包起來，因為被中斷的寫入會留下壞值；升級寫入也要單獨包起來，因為在裝置已滿時讀取可能成功而寫入失敗，此時正確的行為是先把內容交給學習者，下次再試。
儲存配額應被視為一等故障模式
文中最值得借鏡的事故發生在奈及利亞試點：部分學生建立帳號、登入成功後，課程頁面卻是一片空白。團隊最初懷疑是低階硬體相容性問題，白白浪費了時間——報告之所以集中在便宜手機上，是相關而非因果，真正原因是便宜手機儲存空間小、容易寫滿。根因是啟動序列中一個 await：系統把課程清單寫入快取後才繼續，在無空間裝置上這個寫入被拒絕、例外未被捕捉，Promise 鏈在呼叫繪製之前就中斷了，UI 沒有當機、沒有錯誤訊息，課程只是從未被要求畫出來。
修正方式是把它改成 fire-and-forget：渲染照常進行，快取寫入失敗只記錄為非致命事件並標記該課程無法離線使用。團隊為此立下一條通用規則：啟動路徑中的持久化呼叫一律不 await、必須附帶明確的 catch；如果渲染依賴一次成功的寫入，那麼每一支儲存空間已滿的手機都是一個等待發生的空白畫面。他們還加入了預檢，用 navigator.storage.estimate() 估算配額與已用量來決定是否預先快取整門課程。需要注意這個 API 基於隱私考量回傳的是經過填充的近似值，只能當規劃訊號，不能當保證。
兩層式 AI 回饋與誠實的降級契約
個人化答錯回饋是實地評價最高的功能——奈及利亞試點中得分 4.3（滿分 5），十位教育者中九位給出 4 或 5 分——但它也最違背離線前提，因為最強的回饋來自 API 背後的託管模型。團隊的解法是兩層架構加上明確契約：有連線且在 4 秒硬逾時內使用託管模型，否則降級到結合確定性分析與本地模型的裝置端路徑。三個設計重點值得注意：本地分析永遠先跑、無條件執行，其結果還作為上下文送進託管請求，讓遠端模型針對已初步診斷的提交作答，輸出更一致、提示詞更小；navigator.onLine 只當快速否定訊號、絕不信任，因為它只代表網路介面存在，在 captive portal 或卡死的行動連線上照樣回報 true，真正保護學習者的是逾時；回應會記錄來自哪一層，不對學習者或自家遙測隱瞞。
回饋本身也經過重新設計。早期版本對打錯字（例如 consolee.log）與根本誤解函式概念的學生給出同樣的「錯了，正確答案如下」，試點教育者明確指出學生拿到這種回饋根本無法自行修正。修正方式是用 Levenshtein 編輯距離衡量提交與正解的接近程度：接近的失誤得到字元級提示（「你多了一個字母 e，刪掉就對了」），結構性差異則升級為概念性解釋。這套判斷完全是確定性的，因此離線時行為一致。
多人共用裝置是架構需求，不是便利功能
奈及利亞試點中十位教育者有八位指出，學生沒有個人裝置是最大障礙——手機在手足間共用、向老師借用、或在課堂上輪流傳遞。原本「一裝置一學習者」的認證模型意味著換人就要登出再登入，在慢速連線上每次來回浪費一分鐘，還可能弄丟未同步的本地進度。平台改為單一裝置最多保存二十個設定檔、一鍵切換不需完整登出；架構上則把每個本地儲存以設定檔 ID 命名空間隔離，進度、翻譯快取、執行狀態各自分區。教訓很直接：如果目標市場存在裝置共用，這個設計要在第一天就內建，事後拆解全域範圍的本地儲存代價高得多。
實地數據與未解問題
兩種試點形態的對比極具價值：北阿坎德邦由四所機構以受管裝置運行，奈及利亞則是十所學校八週內幾乎完全依賴學生個人手機，這讓團隊能把平台問題與情境問題分開。離線可靠性在奈及利亞得分 4.0，所有低分都可追溯到同一個情境——首次快取循環還沒跑完連線就斷了，這不是可靠性失敗而是首次啟動的排序問題，可以用程式修正；裝置取得問題則完全無法用程式解決，假裝可以只是浪費工程時間。最刺痛團隊的發現是語言：支援 246 種語言是平台存在的理由之一，但十位教育者中四位從未試過本地語言介面、一位試了卻找不到——切換按鈕放在頁尾，而學習者從頭到尾沒有理由捲到那裡。功能存在、有文件、 onboarding 也展示過，卻功能性地隱形。團隊如今的出貨前檢查從「告知位置後使用者找不找得到」改成「使用者實際走的路径上會不會遇到」。
文末作者也坦白三個未解問題：WebAssembly 執行環境在最弱裝置上的冷啟動仍不夠好，當模組必須來自快取而非網路時串流編譯只能部分緩解；裝置端模型品質是離線回饋真正的天花板，確定性分析之所以扛得住，只因程式題有可供檢驗的答案，換個領域未必有這種退路；儲存依然是對抗性環境，配額被填充、驅逐行為不透明、persist() 在各瀏覽器的授予標準不一致，目前的防禦姿態只是彌補平台缺口的變通方案，不是解法。作者沒有給出漂亮結尾——選擇假設筆電與寬頻的替代路線，等於排除大多數本可受益的人；工程確實更難，但可觸及的人口多了數十億。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。