高中英語口說及寫作遊戲開發與推廣計畫，第二期自 2024 年 5 月起籌備啟動， 歷經四個階段的開發與驗收，目前持續維運中。 這一頁用四張架構圖，加上點對點的問答，說明這套系統目前的組成與運作方式。
先看圖。四張圖由上而下，從整體到細節：第一張是全案的樣貌， 第二張是主機內部，第三、四張分別是兩部遊戲。每張圖下方有幾行「看這張圖的重點」。
再看問答。後半段是常見問題的直接回答， 包含幾個容易產生理解落差的地方。
圖為向量格式，可自由放大縮小。每張圖下方都有「另開大圖」連結。
這四張圖是本計畫架構文件的核心，依實際的程式碼與部署設定繪製。 由整體逐層向內展開。
從使用者的角度看，這個計畫由哪些部分組成。除了教育部主機上的服務， 還包含外部的登入機制、幾項線上資源，以及共用的協作試算表。
主機內部怎麼運作。所有請求先經過一個反向代理程式， 它依照網址路徑把請求送到四個不同的落點，圖上標示為 001 至 004。
以 Unity 遊戲引擎製作、可在瀏覽器直接執行的互動遊戲。 後端同時負責登入收口、學習紀錄、排行榜與兌換碼。
以 React 製作的 SDGs 主題學習網站，內容涵蓋課程地圖、AI 對話、寫作、 學習歷程與多人房間，並另有一套獨立的管理後台。
以下是接觸這套系統時最常出現的問題，逐題直接回答。 其中幾題標示為「關鍵理解」，是理解本案架構的分水嶺。
整套系統跑在幾台主機上？
一台。位於教育部機房的 Linux 虛擬主機。兩部遊戲的前端與後端都在這台上，以容器方式各自運行。
使用者看到的網址屬於誰？
教育部因材網（adl.edu.tw）。本計畫的服務掛載在該網域底下的路徑，透過因材網對外提供。 使用者不會直接連到主機本身。
除了主機，計畫還包含哪些東西？
操作說明網站、遊戲手冊、問題回報表單、教學影音，以及共用的協作試算表。 這些不在主機上，但都是計畫實際運作的一部分。
看主機只看得到一半。要完整掌握這個計畫，需要同時涵蓋主機上的服務， 以及主機之外的這些線上資源。
為什麼第一部和第二部的技術完全不一樣？
這是計畫跨期程演進的結果。第一部以 Unity 遊戲引擎製作， 適合沉浸式的互動遊戲體驗；第二部以 React 製作， 適合網站型的學習內容、學習歷程與後台管理需求。
兩者面對的產品目標不同，技術選擇也隨之不同。過程中系統持續進行版本升級， 兩部之間的差異是階段性演進累積下來的樣貌。
兩部的資料儲存方式為什麼不同？
第一部採檔案儲存——每位使用者一組獨立的資料檔； 第二部採 MongoDB 資料庫。
這是最容易產生落差的一點。若以「資料表結構」的角度詢問第一部， 會發現找不到對應的答案——因為它的設計本來就不是資料表。 第一部要看的是檔案怎麼擺、每個欄位代表什麼； 第二部才適用資料庫結構的問法。
兩部遊戲之間有沒有關聯？
有一條。使用者從第一部進入第二部時，第一部會為其換發第二部的通行證， 因此不需要重新登入。這是兩部之間唯一的直接連結。
有沒有一張表可以快速對照兩部？
| 第一部 | 第二部 | |
|---|---|---|
| 技術 | Unity 遊戲引擎 | React |
| 執行位置 | 整包載入瀏覽器端執行 | 一般網站，邊看邊取資料 |
| 資料儲存 | 檔案儲存 | MongoDB 資料庫 |
| 即時互動 | 由後端處理 | Redis ＋ WebSocket |
| 內容維護 | Google 試算表 | 管理後台上稿 |
| 管理後台 | 無獨立後台 | 有，獨立網站 |
| 備份方式 | 每日打包壓縮檔 | 交接文件中說明 |
學生怎麼登入？
一律使用教育部因材網帳號。系統本身不另設帳號密碼。 進入遊戲時會自動導向因材網登入，通過後才進入遊戲內容。
管理者從哪裡進後台？
第二部設有獨立的管理後台，網址在主站之後加上後台路徑， 是一套與主站分開打包的網站，功能涵蓋內容上稿、機器人管理、語音預先產製與報表。
遊戲的題目和關卡在哪裡維護？
第一部的關卡、劇情、題目與兌換碼放在 Google 試算表， 後端直接讀取，因此調整內容不需要修改程式或重新部署。 第二部則透過管理後台上稿。
這代表「內容」與「程式」是分開的。 要完整掌握第一部的運作，除了程式碼，也需要一併取得這些試算表—— 它們不會出現在任何程式碼或資料庫備份裡。
資料怎麼備份？
第一部每日將使用者資料打包成壓縮檔存放於主機。 第二部的備份機制列入交接文件的說明範圍。
原始碼的狀況？
已於 2025 年 12 月提供正式版本予委託單位。 2026 年 8 月至 10 月將依進度陸續提供更新版本，涵蓋兩部遊戲的前端與後端。
系統用到哪些外部服務？
第一部：發音評分、語音辨識、語言模型， 以及作為內容來源的 Google 試算表。
第二部：語言模型、語音合成、語音辨識、影像生成， 分屬不同供應商。
這些服務以帳號方式介接，屬於持續性資源。 系統的 AI 相關功能依賴這些服務運作， 因此在盤點與規劃時需要把它們視為系統的一部分。
例行的維運工作有哪些？
每日：向因材網上傳介接進度。
每月：填報因材網使用數據。
定期：更新共用的數據填報表。
三項皆以人工方式執行，透過共用的協作試算表進行。
問題回報怎麼走？
計畫共用一份協作試算表作為工單通道， 問題回報、討論與進度追蹤都在這份表上進行，是目前既有的溝通慣例。
這些例行工作會怎麼交接？
因為是人工作業，這些步驟需要以文件方式完整記錄。 維運移轉計畫書會逐項寫出：資料從哪裡取得、如何整理、 填入哪張表的哪個分頁、格式為何、所需時間。
並就每項工作錄製一次實際操作的螢幕錄影，隨文件一併提供。
這些圖是怎麼來的？
全景圖依計畫的實務盤點繪製；三張細部圖依實際的程式碼、部署腳本與設定檔繪製。
四張圖之間是什麼關係？
全景圖呈現計畫的整體組成，包含主機上的服務與主機之外的資源； 三張細部圖則分別展開主機內部、第一部與第二部。
全景圖中以單一方塊表示的部分，可在對應的細部圖中看到完整內容—— 例如全景圖的「教育部主機」，展開後即為圖 2。
還有沒有其他的圖？
登入流程圖（因材網單一登入的完整動線）已完成繪製，將併入架構文件。
以下網址為公開頁面，不需要特殊權限，可直接開啟查看目前的實際樣貌。 進入遊戲內容時會導向因材網登入。