模擬原理：預測螢幕變化而非生成文字
傳統大型語言模型通常逐字元追加輸出，這不適用於終端機情境，因為單個按鍵可能導致畫面局部更新或游標移動。WorldTUI 將終端機視為字元網格，輸入為原始位元組序列，輸出則指定需重寫的列與游標位置。
模型使用僅含 333 個 Token 的極小詞彙表，包含 256 個位元組 Token、64 個列 Token 及特殊操作指令。為減少計算量，開發者引入 COPY 操作來處理捲動或清屏等重複性畫面更新，將單次捲動的 Token 消耗從約 3,000 降至每列 3 個。
時間也被視為輸入之一，若無按鍵輸入，模型會接收 WAIT Token 與持續時間，這使得貪吃蛇遊戲等應用能自動推進。
訓練數據生成與自我修正機制
由於缺乏現有的精確按鍵對應螢幕記錄資料集，開發者在 Docker 容器中執行真實指令來生成合成數據。過程包括隨機化使用者名稱、目錄結構及終端機尺寸（主要為 32x96），並模擬人類打字錯誤率約 1.2%。
最終訓練集包含 33.6 萬個片段，對應約 20 億 Token。為了讓模型學會修正自身錯誤，開發者採用類似 DAgger 的方法：讓模型預測後續事件，若結果與真實記錄差異在可接受範圍內，則構造修正數據進行再訓練。
此自我修正機制顯著提升了模型在 PresetBench 測試中的表現，從 int4 量化下的 24/47 提升至 38/47。整個訓練過程在 RTX 4090 上耗時約 75 GPU 小時。
效能優化：平行解碼與模型壓縮
為解決全螢幕重繪導致的高延遲問題，開發者採用平行解碼策略，將每一列視為獨立的批次元素進行生成，僅在最後步驟處理游標位置。這使得大畫面更新的 P95 延遲從 6.7 秒降至 0.87 秒（RTX 4090）。
為確保各列更新的一致性，系統採用投機解碼技術：平行生成的結果作為草稿，再由模型順序驗證並修正不一致之處。在 M4 Mac 瀏覽器環境中，單字輸入延遲約 60ms，較大更新如 man test 需 0.9 秒。
模型從 Qwen2.5-Coder-0.5B（約 4.94 億參數）開始，透過移除大部分嵌入表參數將大小縮減至 3.6 億參數，再經 int4 量化後壓縮至 208 MB。瀏覽器 Demo 使用自訂 JavaScript 實作與 WebGPU 計算著色器執行推理。
測試結果與能力限制
開發者設計了 ShellBench（106 個指令）、PresetBench（47 個腳本案例）及記憶測試（32 個世界，64 次讀取）來評估模型。WorldTUI 在 ShellBench 得分為 80/106，記憶讀取正確率為 9/13，遠高於未微調基座模型的 52/106 與 2/13。
儘管模型能處理 vim、tmux 及簡單 Python REPL 操作，但其一致性仍有限制。例如，執行 echo green >> colors 後再 cat colors，往往無法顯示追加的內容；複雜的巢狀目錄導航也可能導致路徑錯誤。
Python 運算僅限於極簡單單操作，較複雜任務會產生類似 GPT-3 時代的幻覺輸出。由於訓練環境無網路存取，lynx 等依賴網路的工具表現不佳。
蒸餾實驗與記憶體層發現
開發者嘗試透過知識蒸餾減少模型層數以進一步壓縮大小。實驗發現，移除第 7 層雖對下一個 Token 預測準確率影響極小（99.3% 降至 98.9%），卻導致記憶讀取測試完全失敗（64/64 降至 0/64）。
保留關鍵層的 16 層學生模型能通過所有記憶測試，但在 ShellBench 上的表現從教師模型的 78 分降至 65 分。這顯示模型可能在看似正常的輸出下喪失內部狀態追蹤能力。最終開發者放棄了蒸餾方案，維持原始架構以確保功能完整性。
