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 值得试用和拆解。