從「生成一篇知識點」到「面對面講清一道題」：我用魔珐星雲改造 AI 教育助手的實踐

引言

--

最近一年，我接觸到的很多 AI 應用都在做同一件事：把大模型接進一個輸入框，再把回答展示在聊天視窗裡。這種方式驗證模型能力很快，但當我把它放進教育場景後，問題也很快暴露出來。學生面對的仍然是一大段文字；知識點越完整，閱讀壓力越大；試題解析即使正確，也缺少教師講解時的停頓、強調和回饋。系統能夠「生成內容」，卻還不像一個真正參與教學過程的角色。

這也是我開發當前 AI 教育助手專案時最想解決的問題。

專案基於 Vue 3，能夠按照學科、主題和難度生成知識點，也能生成選擇題、填空題和解答題。為了讓生成結果不只停留在頁面上，我進一步接入了魔珐星雲數位人 SDK，讓大模型生成講解內容，再由數位人即時表達。

魔珐星雲官網地址：官網地址

這篇文章不打算泛泛介紹數位人產業，而是從這個專案的真實改造過程出發，討論五個問題：

1. 現有知識生成方案為什麼仍然像一個內容工具；
2. LLM、TTS 和渲染各自存在什麼限制；
3. 星雲如何打通從模型到數位人的即時鏈路；
4. 一次「二次函數講解」如何從靜態頁面升級為 AI 智慧體應用；

5. 星雲 SDK、API 與專案架構應如何真正落地。

   

一、現有方案的問題：內容生成出來了，教學互動卻沒有發生

當前專案已經具備一條比較完整的 AI 內容生產鏈路。

在知識點生成頁，使用者選擇語文、數學、英文、物理、化學或生物，輸入主題並選擇難度。前端透過相容 OpenAI SDK 的模型介面送出提示詞，請模型輸出 Markdown 內容。

在試題生成頁，使用者還可以指定選擇題、填空題或解答題。系統要求模型只返回 JSON，再將題幹、選項、答案、解析和分值標準化為內部資料結構。

bash 體驗AI代碼助手 代碼解讀複製代碼使用者輸入
  → 學科 / 主題 / 難度 / 題型
  → 大模型生成
  → Pinia 保存上下文
  → Markdown、KaTeX 或結構化試題頁面展示

從功能角度看，這條鏈路已經可以使用；從教學體驗看，它仍然存在四個明顯問題。

1. 頁面展示代替不了教師講解

知識點詳情頁可以正確渲染 Markdown 和數學公式，試題詳情頁也能展示答案與解析，但「內容展示正確」不等於「學生已經理解」。

例如，大模型生成一篇關於二次函數的知識點，頁面裡可能包含定義、圖像、頂點公式和例題。學生仍然需要自己判斷：

• 哪個概念最重要；
• 公式中的參數分別影響什麼；
• 當前例題應該先看條件還是先畫圖；
• 哪一步最容易出錯。

真實教師會透過語氣、停頓和重複組織這些資訊。純文字只能把內容交給使用者，卻無法主動引導使用者的注意力。

2. 普通「文字轉語音」仍然像播放器

一個常見改造思路是把整篇回答交給 TTS，然後在頁面中播放音訊。它確實減少了閱讀負擔，但互動仍然是單向的：生成完整文字 → 合成完整音訊 → 點擊播放

使用者需要等待內容與音訊全部準備完成。播放過程中，系統也很難表達「正在思考」「開始回答」「本輪結束」等會話狀態。它更像給文章增加了朗讀按鈕，而不是建構一個能夠持續回應的 AI 教師。

3. 傳統數位人的核心問題，是高延遲、高成本與低併發

傳統數位人並非只能播放預製影片，很多方案同樣支援問答和即時互動。但真正進入業務場景後，影響體驗的往往不是「能不能互動」，而是互動速度、執行成本和併發能力。

在當前專案中，知識點、題型和講解難度都由使用者臨時指定，每次生成的內容都不同。使用者發起請求後，系統需要依序完成模型內容生成、TTS 語音合成、口型與動作驅動以及畫面輸出。如果等待模型生成完整講稿後再啟動後續流程，各環節的耗時就會不斷疊加，學生很容易在等待中失去耐心。

因此，數位人互動真正需要優化的是整條端到端鏈路：

使用者發起講解 → 模型生成首段內容 → 語音與動作同步驅動 → 數位人開始表達

只有首段內容能夠快速輸出，後續內容再以串流方式持續生成、合成和播放，數位人才會讓使用者產生「正在與我交流」的感覺。同時，它還需要根據會話狀態支援暫停、打斷和結束，而不是必須等待整段內容播放完成。

除此之外，即時語音、動作和畫面驅動還會帶來較高的運算成本。當多個使用者同時發起講解時，如何降低單次互動成本、提升系統併發能力，同樣是數位人真正進入業務必須解決的問題。

二、單點技術的限制：LLM、TTS、渲染都不能獨立完成具身互動

在接入星雲之前，我先拆解了專案中的三個核心技術環節。

1. LLM 擅長組織知識，但沒有表達身體

專案使用 OpenAI JavaScript SDK 呼叫相容介面的模型服務。知識點生成時，我透過系統提示詞約束模型扮演中學、高中教研專家；試題生成時，則要求模型按照嚴格 JSON 輸出。LLM 解決的是「說什麼」：

• 生成知識結構；
• 控制題目難度；
• 給出答案和解析；
• 把書面內容改寫為教師口吻。
  但模型返回的仍然是 Token 流。它不知道頁面裡數位人的初始化狀態，也不知道一段文字何時完成口型驅動，更不能單獨提供視覺上的擬人回饋。

2. TTS 能生成聲音，但聲音不等於互動

如果只接 TTS，需要自己處理文字斷句、音訊流緩衝、播放佇列、中斷恢復以及音畫同步。長文字還要考慮首包等待和後續音訊是否連續。

在教育場景裡，TTS 的問題不只是「能不能讀出來」，還包括：

• 公式應該如何口語化；
• Markdown 標記不能直接朗讀；
• 題目選項之間需要停頓；
• 答案與解析需要不同語氣；
• 使用者暫停後，模型流和音訊佇列是否同時停止。
  這些都屬於對話編排，而不是一個 TTS 介面能夠單獨解決的問題。

3. 傳統雲端影片渲染鏈路偏重

如果每次回答都走完整的影片生成或雲端畫面渲染，成本、等待時間和併發壓力都會比較高。對當前專案這種由使用者即時觸發的講解任務來說，幾秒甚至更長的準備時間會明顯破壞互動感。

魔珐星雲既非傳統影片流方案載體，也不是作業系統，而是具身智慧數位人開放平台。它透過自研端側渲染與參數流架構，把形象渲染放到使用者終端完成，伺服器端傳輸驅動數位人的輕量參數，從而降低傳輸和雲端渲染負擔。

在即時互動方案中，端到端約 500ms 的毫秒級回應是一個關鍵能力目標。對教育專案而言，這意味著模型首段內容到達後，數位人能夠盡快接住並開始表達，而不是等待整篇講稿生成結束。

這套方案關注的不是單獨生成一段音訊或影片，而是低延遲、高併發、低成本、全相容的連續具身互動。

三、解決方案：用星雲打通模型、會話和數位人

與其只停留在「看數位人展示」的階段，不如親自完成一次接入，讓自己的 AI 從只會生成答案，真正升級為能夠表達、互動和服務使用者的具身智慧體。

對具身數位人開發有興趣的開發者，可以前往 魔珐星雲官網 體驗相關能力，也可以進一步查看具身驅動 SDK、影片生成 API 和語音合成 API，嘗試將數位人接入自己的 Agent、應用或業務終端。

接入星雲後，我把系統劃分成四層。

bash 體驗AI代碼助手 代碼解讀複製代碼  業務互動層                                                   
  學科、主題、難度、題型、開始/暫停   
                 ↓
  Agent 編排層                       
  上下文、提示詞、狀態機、分句、佇列   
                 ↓
  模型與知識層                       
  LLM、教材知識、題庫、Markdown/JSON  
                 ↓
  星雲具身表達層                    
  SDK 會話、TTS、參數流、端側渲染      

1. 先把數位人封裝成業務元件

專案在 DigitalHuman.vue 中建立 XmovAvatar 實例。數位人的掛載容器、應用資訊和閘道地址都集中在元件內部，頁面只需要呼叫初始化、說話和斷開三個方法。

bash 體驗AI代碼助手 代碼解讀複製代碼const avatar = new window.XmovAvatar({
  containerId: '#containerId',
  appId,
  appSecret,
  enableDebugger: false,
  gatewayServer
})

await avatar.init({
  onDownloadProgress: progress => {
    console.log(`初始化進度: ${progress}%`)
  },
  onMessage: message => {
    console.log('收到訊息:', message)
  }
})

元件再透過 defineExpose 向講解頁提供統一介面：

bash 體驗AI代碼助手 代碼解讀複製代碼defineExpose({
  initDigitalHuman,
  disconnect,
  speak
})

2. 把書面知識改寫為可說的內容

當前專案中的知識點可能包含 Markdown 標題、列表、程式碼區塊和 LaTeX 公式。這些內容適合頁面閱讀，卻不能直接用於語音輸出。 因此，點擊「開始講解」後，系統會再次呼叫大模型，並要求它以專業教師口吻改寫內容，同時移除 Markdown 語法。

bash 體驗AI代碼助手 代碼解讀複製代碼const messages = [
  {
    role: 'system',
    content: '你是一名熟悉中學和高中課程標準的資深教研專家。'
  },
  {
    role: 'user',
    content: `請以專業教師的口吻講解以下內容，不要包含 Markdown 語法：${content}`
  }
]

這一步很重要。頁面稿和口播稿是兩種不同內容產品。具身 Agent 不應該機械朗讀頁面，而應該對知識重新組織。

3. 讓模型流直接進入數位人鏈路

專案已經使用 stream: true 取得模型增量輸出，並將增量文字交給 speak()：

bash 體驗AI代碼助手 代碼解讀複製代碼const completion = await openai.chat.completions.create({
  messages,
  model,
  stream: true
})

let index = 0

for await (const part of completion) {
  const delta = part.choices[0].delta.content
  if (!delta) continue

  await xmovHuman.value.speak(
    delta,
    index === 0,
    false
  )

  index++
}

這讓系統不必等待完整講稿生成完成。模型產生內容後，數位人鏈路即可開始消費。

不過，當前實作仍然是原型：它直接按照模型增量呼叫 speak()。Token 可能只是單字或半句話，容易造成呼叫過碎。下一步應該增加語義緩衝層。

bash 體驗AI代碼助手 代碼解讀複製代碼let buffer = ''

for await (const part of completion) {
  buffer += part.choices[0].delta.content || ''

  const sentences = splitCompletedSentences(buffer)
  buffer = sentences.rest

  for (const sentence of sentences.completed) {
    speechQueue.enqueue(sentence)
  }
}

分句層可以在句號、問號、驚嘆號處切分，也可以設定最大字元閾值。數位人獲得的是完整短句，聲音和動作會比 Token 級輸入更自然。

4. 用狀態機管理「聽、想、說、停」

當前頁面只使用 isSpeaking 控制按鈕，正式版本應該升級為完整狀態機：

bash 體驗AI代碼助手 代碼解讀複製代碼idle
  → initializing
  → thinking
  → speaking
  → paused
  → completed
  → error

每次狀態切換都要同時控制：

• 模型請求是否繼續；
• 文字緩衝是否接收；
• 數位人播放佇列是否消費；
• 開始和暫停按鈕是否可用；

• 頁面是否顯示正在思考或正在講解。

  

四、真實場景：一堂「二次函數」講解如何升級為具身 Agent

為了驗證這條鏈路，我選擇了專案預設的數學場景：

bash 體驗AI代碼助手 代碼解讀複製代碼學科：數學
主題：二次函數
難度：中等

第一步：生成可閱讀的知識內容

使用者提交表單後，模型生成包含二次函數定義、圖像特徵、頂點、對稱軸和例題的 Markdown 內容。系統透過 Pinia 保存生成結果，再跳轉到詳情頁。

詳情頁使用 Marked 渲染 Markdown，並在渲染前保護 ......... 與 ......... 公式，最後交給 KaTeX 顯示。 此時，系統已經是一份合格的 AI 學習資料，但還不是 AI 教師。

第二步：從「文章」生成「講稿」

學生點擊數位人講解後，系統讀取同一條知識點上下文，讓大模型把文章改寫為口語化講稿。 例如，頁面上可能寫著：

bash 體驗AI代碼助手 代碼解讀複製代碼二次函數的一般形式為 y = ax² + bx + c，其中 a ≠ 0。

口播稿則可以改寫為：

bash 體驗AI代碼助手 代碼解讀複製代碼我們先抓住二次函數最基本的形式。大家注意，二次項係數 a 不能等於零；
如果 a 等於零，它就會退化成一次函數。

模型負責把知識變成教學語言，數位人負責把教學語言變成可感知的表達。

第三步：數位人邊接收邊講解

模型返回首段內容後，前端立即將文字送入星雲數位人。星雲透過參數流驅動端側數位人渲染，學生在頁面左側看到 AI 講師，右側仍然保留完整知識點。

這種雙通道設計是我認為當前專案最有價值的部分：

• 視覺通道保留公式和結構；
• 聽覺通道負責解釋和強調；
• 數位人形象提供持續的互動回饋；

• 使用者可以暫停講解，再回到原文核對。
  與單純播放 TTS 相比，數位人讓「誰在講」變得明確；與預製影片相比，本次講解內容完全來自使用者剛剛生成的知識點。

  

第四步：把同一套能力復用到試題解析

試題場景不需要重新搭建數位人系統，只需要更換講解策略。選擇題可以按以下順序組織：

題目背景 → 題幹 → 逐項讀出選項 → 公布正確答案 → 解釋錯誤選項與關鍵依據

填空題重點解釋答案來源；解答題則圍繞審題、答題要點和推導過程展開。

當前專案已經為三類題型準備了不同文字結構，但還有一個需要修正的工程細節：generateExplanationText() 是非同步函式，開始講解時必須先 await 取得結果，否則試題分支的播放佇列可能在內容準備完成前就被讀取。

bash 體驗AI代碼助手 代碼解讀複製代碼const explanations = await generateExplanationText()

if (!explanations.length) return

這類問題說明，具身 Agent 的難點不只在模型或數位人 SDK，也在多個非同步系統之間的順序控制。

五、SDK、API 與專案架構的實際落地方式

1. 當前專案技術棧

這次開發使用的主要技術包括：

在實際開發中，AI Coding 工具對這類跨模組專案很有幫助。我使用 Codex 同時檢查了數位人元件、講解頁面、Pinia Store、模型呼叫和詳情頁渲染邏輯，並透過本地建置與瀏覽器檢查驗證修改結果。

但 AI Coding 只能加快閱讀和實作，不能代替對非同步鏈路與業務狀態的判斷。例如，模型流應該如何斷句、暫停時應取消哪些任務、金鑰應該放在哪裡，仍然需要開發者明確系統邊界。

2. SDK 接入應與業務解耦

我把星雲 SDK 放在獨立元件中，而不是直接寫進講解頁面，原因有三點：

1. 統一管理初始化和銷毀；
2. 避免重複建立數位人會話；
3. 方便未來切換不同角色或講解頁面。
   元件卸載時必須主動停止並銷毀實例：

bash 體驗AI代碼助手 代碼解讀複製代碼const disconnect = () => {
  const avatar = instance.value
  if (!avatar) return

  try { avatar.destroy?.() } catch {}

  instance.value = null
}

如果不清理，路由切換後可能殘留連線、音訊或渲染資源。

3. 生產環境不能把憑證寫在瀏覽器裡

當前專案是展示原型，模型金鑰和數位人應用憑證直接出現在前端程式碼中，並啟用了 dangerouslyAllowBrowser。這種方式便於快速驗證，但不適合正式部署。

生產架構應該調整為：

瀏覽器 → 請求業務後端 → 後端持有長期金鑰 → 後端呼叫模型或簽發短期數位人會話憑證 → 瀏覽器只獲得最小權限的臨時 Token

同時應增加使用者驗證、呼叫頻率限制、日誌去識別化和憑證輪替。

4. 為約 500ms 端到端回應設計整條鏈路

星雲的毫秒級即時互動能力不能只靠前端呼叫一個 speak() 方法實現。若希望接近端到端約 500ms 的回應體驗，整條鏈路都需要圍繞低延遲設計：

• 模型使用串流輸出，減少首字等待；
• 提示詞避免生成冗長前言；
• 語義緩衝控制在短句級別；
• 數位人會話提前初始化；
• 播放佇列持續消費，不等待全文；
• 暫停時同時取消模型流和數位人佇列；
• 網路異常時提供重連與降級方案。
  星雲自研端側渲染與參數流架構降低了畫面傳輸負擔，也更適合高併發場景。但專案最終體驗仍取決於模型首包、業務後端、網路和佇列排程，不能只看某個單點介面耗時。

5. 下一階段架構

當前專案的下一階段不應該只是增加更多頁面，而應補齊 Agent 能力：

bash 體驗AI代碼助手 代碼解讀複製代碼麥克風輸入
  → ASR
  → 多輪會話與意圖識別
  → 教材 RAG / 題庫工具
  → LLM 推理
  → 內容安全與事實校驗
  → 語義分句
  → 星雲數位人

這樣，學生才能在講解過程中追問「為什麼 a 大於零時開口向上」，數位人也能結合當前知識點繼續回答，而不是只能播放預先生成的一輪講稿。

結語：我的實際體驗

完成這次接入後，我對數位人的判斷發生了變化。

一開始，我把數位人理解為 AI 內容的展示元件：模型負責生成，數位人負責播放。真正把專案跑通後，我發現這種理解太淺。數位人是否自然，取決於模型首包、內容改寫、語義分句、播放佇列、狀態機、端側渲染和使用者控制是否共同工作。

魔珐星雲在這個專案裡的價值，是讓我能夠把大模型生成的臨時教學內容直接交給一個可即時表達的數位人，而不必為每一篇知識點提前生產影片。

從實際效果看，專案也不再只是「輸入二次函數，得到一篇文章」。使用者面對的是一個能夠生成知識、展示公式、組織講稿並即時開口講解的 AI 教師雛形。

當然，當前版本仍然需要繼續完善：前端憑證要遷移到伺服器端，Token 級輸入要升級為語義短句佇列，暫停邏輯要與模型取消聯動，單輪講解還要擴展為支援語音追問的多輪會話。

但這次實踐至少驗證了一件事：當 LLM 的知識能力與星雲的即時具身表達能力真正進入同一條業務鏈路後，數位人才不再是頁面旁邊的裝飾，而開始成為 Agent 與使用者之間的互動主體。

資源連結

如果你想動手試試這套方案,以下是相關資源:

魔珐星雲開發者文件與 SDK:xingyun3d.com/developers/…

魔珐星雲官網: xingyun3d.com?utm_campaign=daily&utm_source=jixinghuiKoc156&utm_medium=&utm_term=&utm_content=

原文出處：https://juejin.cn/post/7651268339474202643