TTS on KnightLi的博客

計算機術語人話版：TTS、STT、API、RAG、Agent 到底在說什麼

Tue, 12 May 2026 22:15:34 +0800

計算機領域有很多詞，第一次聽會覺得很高級。可一旦翻譯成人話，往往就是日常生活裡很簡單的動作。

比如 AI 能說話，叫 TTS；AI 能聽你說話，叫 STT。聽起來像複雜系統，拆開就是「把文字讀出來」和「把聲音寫下來」。

參考連結：https://www.zhihu.com/question/267978646/answer/2035405228460201515

這篇就從這個角度串講一些常見術語：保留術語本身，但把它們說成人話。

TTS 和 STT：文字和語音互轉

TTS 是 Text-to-Speech，意思是「文本轉語音」。你輸入一段文字，系統把它變成聲音。導航播報、電子書朗讀、AI 客服開口說話，都屬於這個方向。

STT 是 Speech-to-Text，意思是「語音轉文本」。你對手機說一句話，系統先把語音識別成文字，再交給後面的程式處理。語音輸入法、會議轉寫、自動字幕、智慧音箱，都離不開它。

很多語音 AI 產品的流程其實就是：

STT：把你說的話轉成文字。
LLM：根據文字生成回答。
TTS：把回答讀出來。

所以它看起來像在和你自然聊天，底層往往是幾個模組在接力。

OCR：從圖片裡抄字

OCR 是 Optical Character Recognition，中文常說「光學字元識別」。

聽起來很硬核，其實就是從圖片裡把文字抄出來。拍一張發票、掃描一頁書、識別身分證上的姓名和號碼，本質都是 OCR。

以前 OCR 更像「看字形猜文字」，現在會結合深度學習，對複雜背景、傾斜文字、手寫字和低清圖片的容忍度更高。但它解決的核心問題仍然很直接：圖片裡有什麼字？

NLP 和 LLM：讓機器處理人話

NLP 是 Natural Language Processing，自然語言處理。它處理的是人類語言，比如分詞、翻譯、摘要、情感分析、問答、分類。

LLM 是 Large Language Model，大語言模型。它可以理解和生成文字，所以今天很多 NLP 任務都被 LLM 接管了。

人話版理解：

NLP：讓機器處理人說的話、寫的字。
LLM：一個更大的文字模型，能接住很多語言任務。

你讓 AI 總結文章、寫郵件、改標題、解釋程式碼，背後都屬於這個大方向。

API 和 SDK：一個是介面，一個是工具包

API 是 Application Programming Interface，應用程式編程介面。

人話就是：別人把能力開一個入口給你呼叫。比如天氣 API，你傳城市，它返回天氣；支付 API，你傳訂單，它返回支付結果。

SDK 是 Software Development Kit，軟體開發工具包。

人話就是：為了讓你更方便呼叫 API，官方把常用程式碼、類型、範例和工具打包給你。API 像餐廳窗口，SDK 像點餐小程式。你可以直接去窗口說需求，也可以用小程式點得更省事。

CRUD：增刪改查

CRUD 是 Create、Read、Update、Delete。

翻譯成人話就是：新增、查看、修改、刪除。

很多後台系統、管理系統、資料庫操作，本質都在圍繞 CRUD 打轉。使用者管理、文章管理、訂單管理、庫存管理，看起來業務不同，底層經常都是一組表單加一組增刪改查。

這也是為什麼程式員會說「又寫了一個 CRUD」。不是看不起這個工作，而是它確實太常見。

Cache：先放一份，省得每次重算

Cache 是快取。

人話就是：常用的東西先放在手邊，下次直接拿，不要每次都重新找、重新算、重新請求。

網頁載入慢，可以把圖片和腳本快取起來；資料庫查詢慢，可以把熱門結果放進 Redis；模型推理貴，可以快取重複問題的答案。

快取的難點不在「放一份」，而在「什麼時候更新」。資料變了，快取沒變，就會出現舊資料。這就是很多快取問題的根源。

Queue：排隊慢慢處理

Queue 是佇列。

人話就是：事情太多，先排隊，一個一個處理。

比如使用者上傳影片後，不一定馬上轉碼完成。系統可以先把任務放進佇列，背景服務慢慢處理。發簡訊、發郵件、生成報表、處理訂單回調，也經常用佇列。

佇列解決的是「不要所有事情都卡在當前請求裡」。使用者先得到回應，耗時任務放到後面做。

Index：給資料庫做目錄

Index 是索引。

資料庫裡的索引，可以理解成書的目錄。沒有目錄，你要從第一頁翻到最後一頁；有目錄，你可以更快定位到目標內容。

但索引不是越多越好。查詢會變快，寫入和更新可能變慢，因為資料改了，索引也要跟著維護。

所以資料庫最佳化裡常見的一句話是：慢查詢先看索引。但真正做索引時，還要看查詢條件、排序欄位、資料量和寫入頻率。

RPC、REST 和 Webhook：系統之間怎麼說話

RPC 是 Remote Procedure Call，遠端程序呼叫。

人話就是：我像呼叫本地函式一樣，去呼叫另一台機器上的函式。

REST 常見於 Web API。它更像用 URL 和 HTTP 方法來表達資源操作，比如 GET /users 查使用者，POST /orders 建立訂單。

Webhook 則是反過來通知你。你不用一直問「好了沒」，對方處理完後主動回調你的地址。

簡單記：

RPC：像遠端呼叫函式。
REST：用 HTTP 管理資源。
Webhook：事情發生後主動通知你。

CDN 和 Load Balancing：離你近一點，分擔一點

CDN 是 Content Delivery Network，內容分發網路。

人話就是：把靜態資源放到離使用者更近的節點。使用者訪問圖片、影片、CSS、JS 時，不必每次都跑到源站。

Load Balancing 是負載均衡。

人話就是：訪問量太大，不要讓一台伺服器硬扛，把請求分給多台機器。

一個偏「離使用者近」，一個偏「別讓機器累死」。大型網站通常兩個都會用。

Docker、Container 和 Kubernetes：打包、運行、調度

Docker 是常見的容器工具，Container 是容器。

人話就是：把程式和它依賴的環境打包在一起，換一台機器也盡量能一樣運行。這樣可以減少「我電腦上能跑，伺服器上不能跑」的問題。

Kubernetes，常寫作 K8s，是容器編排系統。

人話就是：當容器很多時，幫你安排它們運行在哪裡、掛了怎麼重啟、流量怎麼分、版本怎麼更新。

如果只有一個小服務，Docker 就夠了；如果有很多服務、很多機器、很多副本，才會更需要 K8s。

CI/CD：自動建置、自動發布

CI 是 Continuous Integration，持續整合。

人話就是：程式碼一提交，系統自動拉程式碼、跑測試、建置，盡早發現問題。

CD 可以指 Continuous Delivery 或 Continuous Deployment，持續交付或持續部署。

人話就是：建置通過後，把程式碼更穩定、更自動地送到測試環境或生產環境。

它解決的不是「寫程式碼」，而是「寫完程式碼之後，怎麼少出錯地上線」。

Serialization：把物件打包成可傳輸格式

Serialization 是序列化。

人話就是：把程式裡的物件變成能保存、能傳輸的格式，比如 JSON、XML、Protobuf。

反過來，Deserialization 是反序列化：把這些格式再還原成程式能用的物件。

你在前後端之間傳 JSON，在服務之間傳 Protobuf，本質都離不開序列化。

Token、Embedding、Vector DB：把文字變成模型能處理的形式

Token 在大模型裡通常指文字切分後的基本單位。它不一定等於一個漢字或一個英文單字，更像模型內部處理文字時的顆粒。

Embedding 是嵌入向量。

人話就是：把文字、圖片或其他內容變成一串數字，讓模型可以比較它們之間的相似度。

Vector DB 是向量資料庫。

人話就是：專門存這些向量，並且能快速找出「意思相近」的內容。

比如你問「怎麼重置路由器」，系統可能去向量庫裡找「恢復出廠設定」「忘記 Wi-Fi 密碼」「後台登入失敗」等相近內容，再拿回來給模型參考。

RAG：先查資料，再回答

RAG 是 Retrieval-Augmented Generation，檢索增強生成。

人話就是：模型回答前，先去資料庫查相關內容，再帶著資料回答。

它解決的是大模型容易「憑記憶瞎說」的問題。把企業文檔、知識庫、產品手冊、程式碼片段接進來，模型就不只是靠訓練時的記憶，而是能參考你給它的最新資料。

典型流程是：

使用者提問。
系統把問題轉成 Embedding。
去 Vector DB 裡找相關文檔。
把文檔片段和問題一起交給 LLM。
模型生成回答。

所以 RAG 聽起來高級，本質是「先翻資料，再組織語言」。

Agent：會自己拆任務的自動化流程

Agent 在 AI 語境裡經常被翻譯成智能體。

人話就是：它不只是回答一句話，而是能根據目標拆步驟、呼叫工具、觀察結果，再決定下一步。

比如你讓它「幫我分析這個倉庫為什麼測試失敗」，普通聊天模型可能只給建議；Agent 則可能會讀檔案、運行測試、看報錯、改程式碼、再跑測試。

當然，Agent 不等於一定可靠。它只是把「模型 + 工具呼叫 + 狀態循環」串起來。真正好不好用，還要看工具權限、任務邊界、錯誤處理和人工確認機制。

小結

很多計算機術語之所以顯得高級，是因為它們被英文縮寫、架構圖和產品文案包了一層殼。拆開之後，大多是在描述很樸素的動作：

TTS：把文字讀出來。
STT：把聲音寫下來。
OCR：從圖片裡抄字。
API：開放一個呼叫入口。
SDK：把呼叫工具打包好。
CRUD：增刪改查。
Cache：常用結果先存一份。
Queue：任務排隊慢慢處理。
Index：給資料做目錄。
CDN：把內容放近一點。
Load Balancing：把請求分散一點。
Docker：把運行環境打包。
CI/CD：讓測試和發布自動化。
Embedding：把內容變成數字向量。
RAG：先查資料，再回答。
Agent：讓模型帶著工具分步做事。

術語要保留，因為它們方便搜尋、溝通和查文檔。但理解時不用被它們嚇住。先翻譯成人話，再回到技術細節裡看，很多概念會清楚得多。

參考

知乎回答：https://www.zhihu.com/question/267978646/answer/2035405228460201515

Pixelle-Video：一句主題生成短影片的開源 AI 引擎

Thu, 07 May 2026 20:25:17 +0800

Pixelle-Video 是 AIDC-AI 開源的全自動短影片生成引擎。它的目標很直白：使用者輸入一個主題，系統自動完成影片文案、AI 配圖或影片、語音解說、背景音樂和最終合成。

這類工具適合短影片批量創作、知識科普、口播內容、小說解說、歷史文化類影片和自媒體素材實驗。它不是單一的「文生影片模型」，而是把多種 AI 能力接成一條生產流水線。

它能自動做什麼

Pixelle-Video 的預設流程可以概括為：

輸入主題或固定文案；
由大型語言模型生成解說詞；
根據分鏡規劃生成配圖或影片素材；
使用 TTS 生成語音解說；
添加背景音樂；
套用影片模板並合成最終成片。

README 中給出的流程是「文案生成 → 配圖規劃 → 逐幀處理 → 影片合成」。這種模組化設計的好處是清晰：每一步都可以替換模型、調整參數或改用自訂工作流。

功能亮點

專案支援的能力相當完整：

AI 智慧文案：根據主題自動生成影片解說詞；
AI 配圖：為每句話或每個分鏡生成插圖；
AI 影片生成：支援接入 WAN 2.1 等影片生成模型；
TTS 語音：支援 Edge-TTS、Index-TTS 等方案；
背景音樂：可以使用內建 BGM，也可以放入自訂音樂；
多尺寸輸出：支援直式、橫式等不同影片比例；
多模型選擇：可接入 GPT、通義千問、DeepSeek、Ollama 等；
ComfyUI 工作流：可以使用預置工作流，也可以替換生圖、TTS、影片生成等環節。

最近更新裡還提到動作遷移、數位人口播、圖生影片、多語言 TTS 音色、RunningHub 支援、Windows 一鍵整合包等內容。這說明專案已經不只是一個腳本，而是在往完整創作工具方向發展。

安裝和啟動方式

Windows 使用者可以優先看官方提供的一鍵整合包。它的定位是降低安裝門檻，不需要手動準備 Python、uv 或 ffmpeg，解壓後執行 start.bat，再在瀏覽器裡打開 Web 介面配置 API 和圖像生成服務。

如果從源碼啟動，README 給出的基本方式是：

1
2
3

git clone https://github.com/AIDC-AI/Pixelle-Video.git
cd Pixelle-Video
uv run streamlit run web/app.py

源碼方式適合 macOS、Linux 使用者，也適合需要修改模板、工作流或服務配置的人。前置依賴主要是 uv 和 ffmpeg。

配置重點

第一次使用時，關鍵不是先點「生成」，而是把幾個外部能力接好。

LLM 配置決定文案品質。你可以選擇通義千問、GPT、DeepSeek、Ollama 等模型，並填寫對應的 API Key、Base URL 和模型名。如果想盡量降低成本，本地 Ollama 是一個方向；如果追求穩定效果，雲端模型會更省心。

圖像和影片生成配置決定畫面品質。專案支援本地 ComfyUI，也支援 RunningHub。懂 ComfyUI 的使用者可以把自己的工作流放進 workflows/ 目錄，用來替換預設生圖、影片或 TTS 流程。

模板配置決定最終成片的視覺形態。專案用 templates/ 目錄組織影片模板，靜態模板、圖片模板和影片模板按命名規則區分。對內容創作者來說，這比只生成一段素材更實用，因為最終交付物是可以直接預覽和下載的影片。

適合什麼人

Pixelle-Video 比較適合三類使用者：

短影片創作者：想快速把選題變成可發布的草稿影片；
AIGC 工具玩家：想把 LLM、ComfyUI、TTS 和影片合成串起來；
開發者和自動化使用者：想基於開源專案改模板、改工作流，甚至接入自己的素材和模型。

如果你只想偶爾做一支高品質精品影片，它未必能直接替代人工剪輯；但如果你想批量生成結構一致的解釋類、口播類、科普類內容，它的流水線思路很有價值。

需要注意的地方

這類工具的上限由多個環節共同決定。文案模型不好，內容會空；配圖模型不好，畫面會散；TTS 不自然，影片會顯得粗糙；模板不合適，最終成片也會缺少辨識度。

所以使用 Pixelle-Video 時，建議先從一個固定場景開始調試，比如「60 秒知識科普直式影片」。把 LLM、畫面風格、TTS 音色、BGM 和模板固定下來，再逐步擴大到其他主題。

另外，專案雖然支援本地免費方案，但本地方案通常需要顯卡、ComfyUI 配置和模型檔案。沒有本地推理環境的使用者，可以用雲端 LLM 加 RunningHub 的方式降低部署難度，但要留意呼叫成本。

簡短判斷

Pixelle-Video 的看點不只是「輸入一句話生成影片」，而是它把短影片生產拆成可替換的模組：文案、畫面、語音、音樂、模板和合成。對普通使用者，它是一個低門檻 AI 影片工具；對開發者，它更像一個可改造的短影片自動化框架。

如果你正在研究 AI 短影片流水線，或者想把 ComfyUI、TTS、LLM 和模板合成串成一個可用產品，Pixelle-Video 值得試用和拆解。