1. 项目概述：一个能“听懂”你说话的桌面AI助手

最近在GitHub上看到一个挺有意思的项目，叫 jakecyr/chatgpt-voice-assistant 。光看名字，你大概就能猜到它的核心功能：一个结合了语音交互的ChatGPT桌面助手。但如果你以为它只是个简单的“语音输入转文字，再发给ChatGPT”的玩具，那就小看它了。我花了一周时间，从源码分析到本地部署，再到深度定制，发现这个项目实际上是一个相当精巧的、可高度扩展的 桌面级AI语音交互框架 。

简单来说，它让你能像和真人对话一样，通过麦克风向你的电脑提问，然后通过扬声器听到AI的回答。整个过程是实时的、流式的，并且完全在你的本地或你控制的服务器上运行（除了调用大模型API）。这解决了几个核心痛点：首先，它解放了双手，在需要专注屏幕内容（比如写代码、看文档）时，无需频繁切换窗口打字；其次，它提供了更自然的交互方式，尤其适合快速记录灵感、进行头脑风暴或练习外语对话；最后，作为一个开源项目，它给了你完全的掌控权，你可以替换语音引擎、调整唤醒词、集成到其他工作流中，打造一个真正属于你的“贾维斯”。

这个项目适合谁呢？如果你是一名开发者，对AI应用和语音技术感兴趣，想学习如何将多个AI服务（语音识别、大语言模型、语音合成）串联成一个可用的产品，那这个项目是一个绝佳的入门范例。如果你是一名效率工具爱好者，厌倦了在浏览器和聊天窗口间切换，渴望一个常驻后台的智能语音伴侣，那通过简单的配置，你也能快速拥有一个。接下来，我会从设计思路、技术栈拆解、详细部署步骤、深度定制技巧以及我踩过的各种坑，来完整还原这个项目的全貌。

2. 项目整体设计与核心思路拆解

2.1 核心工作流：从声音到智慧的“管道”

这个项目的架构非常清晰，它本质上构建了一条高效、低延迟的音频处理流水线。理解这条流水线，是理解整个项目的基础。其核心工作流可以概括为以下五个步骤：

  1. 语音监听与唤醒 ：程序启动后，会持续监听麦克风的音频输入。它并不是把所有声音都录下来处理，那样效率太低且不隐私。项目内置了一个简单的 语音活动检测（VAD） 模块。只有当检测到有效的人声片段（比如你开始说话）时，才会触发后续流程。更高级的玩法是配置 唤醒词 ，比如“Hey Computer”，只有听到特定词才响应，实现真正的“待机”模式。
  2. 语音转文本（STT） ：捕获到有效语音片段后，程序会将这段音频数据发送给语音识别服务。项目默认支持多个后端，比如OpenAI官方的Whisper API（在线，精度高），或者本地运行的Whisper模型（离线，速度取决于硬件）。这一步将你的声音转化为计算机能理解的文字指令或问题。
  3. 文本理解与生成（LLM） ：得到的文本被送入大型语言模型，也就是ChatGPT（通过OpenAI API）或其它兼容API的模型（如Claude、DeepSeek等）。LLM负责理解你的意图，并生成一段自然、连贯的文本回复。这是整个系统的“大脑”。
  4. 文本转语音（TTS） ：LLM生成的文本回复，需要再转换回声音。项目同样支持多种TTS引擎，例如OpenAI的TTS API、微软Azure的语音服务，或者像 pyttsx3 这样的本地离线引擎。这一步决定了AI“说话”的音色、语调和自然度。
  5. 音频播放与流式处理 ：最后，生成的语音音频流通过你电脑的扬声器播放出来，完成一次交互。为了提升体验，高级模式会采用 流式处理 ：即一边识别语音、一边发送给LLM、一边生成语音并播放，从而大幅降低从你问完到听到回答之间的延迟，感觉更像实时对话。

2.2 技术栈选型背后的逻辑

作者在技术选型上体现了实用主义和灵活性。我们来看看每个环节的选型考量：

  • 语音识别（STT） ：

    • OpenAI Whisper API ：这是默认且推荐的选择。Whisper在识别精度、多语言支持和抗噪能力上表现顶尖。使用其API省去了部署本地模型的麻烦，延迟低，适合绝大多数用户。代价是会产生API调用费用，且音频数据会发送到OpenAI服务器。
    • 本地Whisper模型 ：项目也支持运行开源的Whisper模型。这提供了完全的离线隐私，但需要较强的CPU/GPU（推荐使用GPU加速），并且首次加载模型时间较长。适合对数据隐私要求极高，且有本地算力的用户。
    • 其他引擎（如Vosk） ：通过项目灵活的配置，可以集成其他STT引擎。例如Vosk是一个轻量级的离线识别库，虽然精度和语言支持不如Whisper，但资源占用极低，适合嵌入式或资源受限的环境。

  • 大语言模型（LLM） ：

    • OpenAI GPT API ：项目的核心设计围绕OpenAI的Chat Completion API。这是目前能力最强、最稳定的选择。项目通过配置API Key和模型名称（如 gpt-4o-mini , gpt-4 ）来调用。
    • API兼容层 ：项目的聪明之处在于，它并非硬编码OpenAI API。通过使用 openai 这个Python库，并正确配置 base_url ，你可以轻松地将其指向任何兼容OpenAI API格式的本地或第三方服务。这意味着你可以使用 Ollama （本地运行Llama、Qwen等模型）、 LM Studio 提供的本地服务器，或是 DeepSeek 、 Groq 等提供的高速API。这极大地扩展了项目的可能性。

  • 语音合成（TTS） ：

    • OpenAI TTS API ：与STT类似，这是默认的优质在线选择。声音自然，有多种音色可选。
    • Edge TTS ：这是一个免费且质量不错的替代方案，它利用了微软Edge浏览器的语音合成能力。虽然需要网络，但不产生额外费用，音质也相当可以。
    • 本地TTS（如pyttsx3, Coqui TTS） ： pyttsx3 调用系统自带的语音引擎（如Windows的SAPI），完全离线，但声音机械感较强。Coqui TTS则能提供更高质量的离线合成，但部署更复杂。选择取决于你对音质、离线能力和复杂度的权衡。

  • 音频处理与流式架构 ：

    • 项目大量使用了 pyaudio 或 sounddevice 进行跨平台的音频采集与播放。
    • 为了实现流式交互，代码中采用了 异步（asyncio） 和 多线程/进程 的设计。例如，在播放AI回答的语音时，就可以同时开始监听你的下一句话，从而减少等待时间。这部分是项目代码的精华，也是性能优化的关键。

注意 ：技术选型没有绝对的好坏，只有是否适合你的场景。如果你追求最佳体验和开发速度，全套OpenAI在线服务是最佳选择。如果你注重隐私和成本，那么“本地Whisper + Ollama本地模型 + Edge TTS”可以搭建一个几乎零成本的离线方案，虽然体验上会有一些妥协。

3. 从零开始：详细部署与配置指南

理论讲完了，我们动手把它跑起来。这里我以macOS/Linux环境为例，Windows用户操作类似，主要区别在部分依赖的安装命令上。

3.1 环境准备与依赖安装

首先确保你的系统有Python 3.8或更高版本。我强烈建议使用 虚拟环境 来管理依赖，避免污染系统环境。

# 1. 克隆项目代码
git clone https://github.com/jakecyr/chatgpt-voice-assistant.git
cd chatgpt-voice-assistant

# 2. 创建并激活虚拟环境（以venv为例）
python -m venv venv
# macOS/Linux:
source venv/bin/activate
# Windows:
# venv\Scripts\activate

# 3. 安装项目依赖
pip install -r requirements.txt

requirements.txt 里包含了核心依赖，如 openai , sounddevice , numpy 等。如果安装过程中遇到关于音频库的错误（比如在Linux上缺少 portaudio ），你需要先安装系统级的开发包。

# Ubuntu/Debian
sudo apt-get install portaudio19-dev python3-dev
# macOS (使用Homebrew)
brew install portaudio
# 安装后可能需要重新安装`pyaudio`
pip install pyaudio --force-reinstall

3.2 核心配置文件解析

项目根目录下通常有一个配置文件示例，比如 .env.example 或 config.yaml.example 。你需要复制一份并填写自己的配置。

# 复制示例配置文件
cp .env.example .env

现在，用文本编辑器打开 .env 文件，我们来逐一配置关键项：

# OpenAI API 配置（LLM和可能的STT/TTS）
OPENAI_API_KEY=sk-your-actual-openai-api-key-here
OPENAI_MODEL=gpt-4o-mini  # 模型选择，平衡速度与成本

# 语音识别（STT）配置 - 使用OpenAI Whisper API
USE_LOCAL_WHISPER=false  # 设为true则使用本地模型
WHISPER_MODEL=base       # 如果本地，模型大小：tiny, base, small, medium, large

# 语音合成（TTS）配置 - 使用OpenAI TTS
TTS_PROVIDER=openai
OPENAI_TTS_VOICE=alloy   # 音色：alloy, echo, fable, onyx, nova, shimmer

# 音频设备配置（如果自动检测不到，需要手动指定）
INPUT_DEVICE_ID=  # 留空则自动选择默认麦克风
OUTPUT_DEVICE_ID= # 留空则自动选择默认扬声器

# 高级功能：唤醒词
USE_WAKEWORD=false
WAKEWORD_MODEL_PATH=path/to/your/wakeword/model.pb  # 需要自己训练或下载

配置要点解析：

  • OPENAI_API_KEY ：这是最重要的。去OpenAI平台申请一个API Key。注意保管，不要泄露。
  • OPENAI_MODEL ：对于语音助手场景，响应速度至关重要。 gpt-4o 或 gpt-4o-mini 是目前的最佳选择，它们在保持不错智能的同时，速度比 gpt-4 快得多，成本也更低。不建议用 gpt-3.5-turbo ，虽然便宜但逻辑和指令跟随能力差一截。
  • USE_LOCAL_WHISPER ：如果你没有OpenAI API的额度，或者追求完全离线，可以设置为 true 。但首次运行时会自动下载模型（几百MB到几个GB），且识别速度较慢。对于实时交互，本地 small 或 base 模型是底线， tiny 模型精度损失太大。
  • TTS_PROVIDER ：如果你不想为TTS付费，可以将其改为 edge （使用Edge TTS）。你需要安装额外的包 edge-tts ，并在代码中调整TTS的调用逻辑（项目可能已支持，需查看最新代码）。

3.3 首次运行与基础测试

配置完成后，就可以尝试运行了。通常主程序入口是一个Python脚本，比如 main.py 或 assistant.py 。

python main.py

程序启动后，你应该会在终端看到日志输出，显示音频设备初始化、模型加载（如果使用本地模型）等信息。然后程序会进入监听状态。

进行你的第一次对话：

  1. 对着麦克风清晰地说一句话，比如“你好，介绍一下你自己”。
  2. 说完后停顿一下。VAD检测到语音结束，会开始处理。
  3. 观察终端日志，你会看到识别出的文字，发送给GPT的请求，以及接收到的回复文本。
  4. 稍等片刻，你应该就能从扬声器里听到AI的语音回复了！

常见启动问题排查：

  • “No module named ‘xxx’” ：说明依赖没装全，根据报错信息用 pip install 安装对应模块。
  • “Error opening audio stream” ：音频设备问题。尝试在配置文件中手动指定 INPUT_DEVICE_ID 和 OUTPUT_DEVICE_ID 。你可以运行一个简单的Python脚本来列出所有音频设备： 
    import sounddevice as sd
print(sd.query_devices())
    找到你的麦克风和扬声器对应的ID填入。
  • OpenAI API错误 ：检查API Key是否正确，是否有余额，网络是否能访问 api.openai.com 。

4. 核心功能模块深度解析与定制

让基础版本运行起来只是第一步。这个项目的魅力在于其模块化设计，允许我们对每一个环节进行深度定制和优化。

4.1 语音活动检测（VAD）与唤醒词优化

默认的VAD可能过于敏感（把环境噪音当成人声）或不够敏感（需要很大声说话）。我们可以调整其参数，通常在音频处理模块的初始化部分。

# 在相关代码文件中，你可能会找到类似参数
vad_aggressiveness = 2  # 常见范围1-3，1最不敏感（需要更大声音），3最敏感
frame_duration_ms = 30   # 每帧音频的毫秒数
padding_duration_ms = 300 # 语音前后添加的静音填充，使录音更完整

实操心得 ：在嘈杂的办公室，建议将 vad_aggressiveness 设为2或3，并配合一个简单的能量阈值过滤，可以有效减少误触发。在安静的书房，设为1可以避免自己的呼吸声被录入。

进阶：集成离线唤醒词引擎 内置的VAD只是检测“有人说话”，而唤醒词是检测“说了特定词”。集成像 Porcupine 或 Snowboy 这样的开源唤醒词引擎，可以极大提升体验。你需要：

  1. 选择一个唤醒词（如“Hey Jarvis”）。
  2. 使用引擎提供的工具（通常在线）为这个词训练一个简单的模型文件（ .ppn 或 .pmdl ）。
  3. 修改项目代码，在音频流中持续运行唤醒词检测。只有当检测到特定词后，才开启后续的VAD和STT流程。
  4. 这会让你的助手更像一个随时待命但不会误响应的智能设备。

4.2 大语言模型（LLM）的提示词工程与上下文管理

助手“聪不聪明”，很大程度上取决于你如何与LLM对话（即 系统提示词 ）。项目里会有一个地方设置初始的 system_message 。

system_prompt = """
你是一个高效的桌面AI语音助手。请遵守以下规则：
1. 回复尽可能简洁、口语化，适合用语音播报出来。
2. 一次只专注于一个任务或问题。
3. 如果用户的问题需要长篇幅回答，先给出核心结论，再询问是否需要展开。
4. 不要在你的回复前加上“嗯”、“啊”、“这个”等语气词。
"""

关键技巧：

  • 角色设定 ：你可以把它设定成“专业的技术顾问”、“风趣的聊天伙伴”或“严格的英语老师”，这会让交互风格完全不同。
  • 输出限制 ：明确要求“用一句话回答”或“总结成三点”，可以控制语音回复的长度。
  • 上下文管理 ：默认情况下，每次对话可能都是独立的。为了实现多轮对话记忆，项目需要维护一个 对话历史列表 。每次将新的用户问题 append 进去，并将整个历史发送给GPT。但要注意，GPT有token长度限制，历史太长需要截断或总结。一个常见策略是只保留最近5-10轮对话。

切换LLM后端（以使用Ollama本地模型为例）：

  1. 本地安装并运行Ollama，拉取一个模型如 llama3.2 ： ollama run llama3.2
  2. Ollama会在 localhost:11434 提供一个兼容OpenAI API的端点。
  3. 修改你的 .env 或代码中的OpenAI客户端配置： 
    from openai import OpenAI
# 指向Ollama本地服务
client = OpenAI(
    base_url='http://localhost:11434/v1',
    api_key='ollama', # Ollama不需要真key，但字段必填
)
# 然后在调用时，使用Ollama中的模型名
response = client.chat.completions.create(
    model='llama3.2', # Ollama中的模型名
    messages=[...]
)
    这样，你就拥有了一个完全离线的、私有的语音助手大脑。虽然本地小模型的能力不如GPT-4，但对于日常问答、文本摘要等任务已足够可用。

4.3 文本转语音（TTS）的音色与流式播放优化

TTS是体验的最后一环，也是塑造助手“人格”的关键。

  • OpenAI TTS ：音质好，选择多。 nova 和 shimmer 的音色听起来更自然、更有活力。你可以在配置中切换体验。
  • Edge TTS ：免费是最大优势。通过 edge-tts 库，你可以选择不同的语音和语言。音质稍逊于OpenAI，但完全够用。集成时需要修改TTS调用部分的代码。 
    # 示例：使用Edge TTS替换
import asyncio
from edge_tts import Communicate

async def edge_tts_speak(text, voice="zh-CN-XiaoxiaoNeural"):
    communicate = Communicate(text, voice)
    # 将音频流写入文件或直接播放
    # ... 需要适配项目的音频播放器 ...
  • 流式播放 ：为了做到“边生成边播放”，降低延迟，需要将TTS生成的音频流进行分块。OpenAI的TTS API支持返回音频流。你需要一个能够播放未完整音频块的播放器，并处理好音频流的接收和播放之间的同步，避免卡顿或破音。这涉及到更底层的音频队列管理。

4.4 状态提示与用户反馈优化

一个优秀的交互设计需要给用户明确的反馈。当前项目可能只在终端打印日志，这对于桌面助手来说不够直观。

  • 视觉反馈 ：可以集成一个简单的系统托盘图标或桌面悬浮窗。当监听时图标显示为“待机”（如蓝色），录音时变为“录音中”（红色），思考时变为“处理中”（黄色），说话时变为“播放中”（绿色）。这可以通过 pystray 等库实现。
  • 音频反馈 ：在唤醒成功、开始录音、结束思考等关键节点，播放一个简短的提示音（例如“嘀”一声），能让用户明确知道当前状态。
  • 转录显示 ：在屏幕上实时显示识别出的文字和AI回复的文字，这对于有听力障碍的用户或是在嘈杂环境中非常有用。可以创建一个简单的GUI窗口来展示。

5. 实战进阶：打造个性化智能工作流

基础功能稳定后，我们可以思考如何让它从“玩具”变成真正提升生产力的“工具”。

5.1 集成系统操作与自动化

让助手不仅能回答问题，还能帮你操作电脑。这需要调用系统命令或API。

  • 思路 ：在LLM的回复中，如果检测到特定的指令模式（例如“打开浏览器”、“查询天气”），则不进行TTS回复，而是触发一个对应的函数。
  • 示例：实现“打开应用”指令
    1. 在代码中定义一个函数字典，映射指令到操作。
    import subprocess
import webbrowser

def open_app(app_name):
    # macOS
    subprocess.run(["open", "-a", app_name])
    # Windows: subprocess.run(["start", app_name], shell=True)
    # Linux: subprocess.run([app_name])

def search_web(query):
    webbrowser.open(f"https://www.google.com/search?q={query}")

command_handlers = {
    "open browser": lambda: webbrowser.open("https://www.google.com"),
    "open notepad": lambda: open_app("TextEdit"), # macOS
    "search for": search_web,
}
    1. 在LLM生成回复后，先检查文本是否包含这些指令关键词。如果包含，则执行对应操作，并生成一个执行结果的语音反馈（如“已为您打开浏览器”）。

警告 ：赋予AI系统操作权限存在安全风险。务必严格限制可执行的命令范围，避免解析用户输入直接拼接成系统命令（防止命令注入攻击）。最好使用一个预先定义好的、安全的命令白名单。

5.2 实现连续对话与上下文感知

默认的单轮对话很机械。实现连续对话需要：

  1. 维护对话历史 ：用一个列表在内存中保存用户和AI的对话轮次。 
    conversation_history = [
    {"role": "system", "content": system_prompt},
    {"role": "user", "content": "今天天气怎么样？"},
    {"role": "assistant", "content": "我无法访问实时天气数据，但你可以告诉我你的城市，我帮你查询。"},
]
  2. 智能截断 ：GPT有token限制。当历史对话太长时，需要截断。简单的做法是只保留最近的N轮。更高级的做法是使用LLM本身对早期历史进行总结，然后将总结作为新的系统消息的一部分，从而保留长期记忆的精华。
  3. 对话状态管理 ：对于多轮任务（如订餐、安排会议），需要维护一个简单的状态机或记忆字典，记录当前对话的“槽位”（如日期、时间、地点），直到所有必要信息收集完毕才触发最终动作。

5.3 性能监控与日志分析

为了长期使用和调试，需要建立简单的监控。

  • 记录日志 ：将每次交互的耗时（STT时间、LLM响应时间、TTS时间）、token使用量、API调用是否成功记录到文件或数据库中。
  • 分析瓶颈 ：通过日志分析，如果发现STT时间过长，可能是网络延迟或本地模型太大；如果LLM响应慢，考虑换用更快模型或检查网络；如果整体延迟高，可能是流式处理环节有阻塞。
  • 成本控制 ：如果你使用付费API，记录每次调用的token数，可以估算每日/每月成本，设置用量告警。

6. 避坑指南与常见问题实录

在实际部署和调试过程中，我遇到了不少问题，这里把典型问题和解决方案记录下来，希望能帮你节省时间。

6.1 音频相关问题

问题1：录音有巨大回声或啸叫。

  • 原因 ：扬声器播放的声音又被麦克风收录，形成反馈循环。
  • 解决 ：
    1. 使用耳机 ：这是最根本的解决方法。
    2. 调整音频设置 ：在系统设置中降低麦克风增益，或启用系统的回声消除功能（如果驱动支持）。
    3. 软件端处理 ：在代码中启用 声学回声消除（AEC） 。这需要复杂的音频信号处理算法，可以集成 speex 或 webrtc 的AEC模块，但实现难度较高。对于开源项目，戴耳机是最实用的建议。

问题2：语音识别精度差，尤其是中文。

  • 原因 ：默认的Whisper API模型可能未针对中文优化配置，或者环境噪音大，用户口音重。
  • 解决 ：
    1. 明确指定语言 ：在调用Whisper时，如果确定是说中文，传入参数 language="zh" ，可以提升识别准确率和速度。
    2. 使用更好的麦克风 ：外接一个USB麦克风通常比笔记本内置麦克风效果好得多。
    3. 本地模型微调 ：如果使用本地Whisper，且你有大量特定领域（如医疗、法律）的音频数据，可以对Whisper模型进行微调，但这需要较强的机器学习背景和计算资源。

问题3：TTS播放声音卡顿、不连贯。

  • 原因 ：音频流播放缓冲区处理不当，或者系统音频驱动有问题。
  • 解决 ：
    1. 调整缓冲区大小 ：在音频播放代码中，找到缓冲区大小（ chunksize 或 blocksize ）参数。适当调大（如从1024调到2048）可以增加稳定性，但会增加延迟；调小则相反。需要根据你的硬件找到一个平衡点。
    2. 检查后台进程 ：关闭其他大量占用CPU或磁盘的应用程序，确保音频线程能获得足够的计算资源。
    3. 尝试不同的音频后端 ： pyaudio 在某些系统上可能不如 sounddevice 稳定。可以尝试在代码中切换音频库。

6.2 网络与API相关问题

问题4：OpenAI API请求超时或连接错误。

  • 原因 ：网络连接不稳定，或者API Key无效、额度不足。
  • 解决 ：
    1. 设置超时和重试 ：在OpenAI客户端初始化时，配置一个合理的超时时间，并实现简单的重试逻辑（例如，最多重试3次，每次间隔递增）。 
      from openai import OpenAI
client = OpenAI(
    api_key=api_key,
    timeout=30.0,  # 设置30秒超时
    max_retries=2,  # 最多重试2次
)
    2. 使用代理 ：在某些网络环境下，需要配置代理才能访问OpenAI。这可以通过设置环境变量 HTTP_PROXY / HTTPS_PROXY ，或在OpenAI客户端中指定 http_client 参数来实现。 （注意：此处仅讨论技术实现原理，具体代理配置需用户根据自身合法合规的网络环境自行处理）
    3. 检查账单 ：登录OpenAI平台，确认API Key有效且有剩余额度。

问题5：使用本地模型（Ollama）时响应速度极慢。

  • 原因 ：模型太大，硬件（特别是GPU）性能不足，或者没有启用GPU加速。
  • 解决 ：
    1. 选择更小的模型 ：在Ollama中尝试 phi3 、 qwen2.5:3b 等更小的模型，它们在CPU上也能有不错的速度。
    2. 确保GPU加速 ：运行 ollama run llama3.2 时，观察输出日志是否显示使用了 CUDA 或 Metal （macOS）。确保你的显卡驱动和CUDA环境（对于NVIDIA GPU）已正确安装。
    3. 调整参数 ：在Ollama运行命令中，可以添加参数限制最大输出token数（ --num-predict 256 ）来加快响应。

6.3 功能与体验问题

问题6：误触发频繁，环境噪音也会启动录音。

  • 原因 ：VAD灵敏度设置过高，或没有使用唤醒词。
  • 解决 ：
    1. 降低VAD灵敏度 ：如前所述，调整 vad_aggressiveness 到更低的级别（如1）。
    2. 增加能量阈值 ：在代码中，计算音频帧的能量（音量），只有超过某个阈值的帧才交给VAD判断。这能过滤掉键盘声、鼠标点击等轻微噪音。
    3. 必须使用唤醒词 ：这是解决误触发最有效的方法。投入时间集成Porcupine等唤醒词引擎，体验会有质的提升。

问题7：多轮对话中，AI忘记之前说过的话。

  • 原因 ：没有正确维护和传递对话历史上下文。
  • 解决 ：
    1. 检查代码逻辑 ：确保每次请求API时，都将完整的 conversation_history 列表作为 messages 参数发送。
    2. 管理上下文长度 ：当历史对话的token总数接近模型上限（如GPT-4o是128k）时，需要移除最早的一些对话轮次。可以采用“滑动窗口”法，只保留最近10轮。
    3. 实现上下文总结 ：对于超长对话，可以调用一次GPT，让它用一段话总结之前的对话重点，然后用这个总结替换掉大部分旧历史，只保留最近几轮。这样既能保留长期记忆，又不超限。

经过以上从原理到实践，从部署到定制的完整梳理，这个 chatgpt-voice-assistant 项目就不再是一个黑盒，而是一个你可以完全掌控并塑造成任何你想要的样子的智能交互核心。它就像一副骨架，而你的想象力和技术能力是为其注入血肉和灵魂的关键。无论是打造一个个人效率助手，还是作为一个更复杂智能项目的语音交互模块，这个项目都提供了一个坚实而灵活的起点。

# 语音识别
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

AI动态简报之算力基建篇

avatar DeepSeek技术社区
cover

端侧小模型 vs 云端大模型双轨部署：规则分流还是训练路由器的工程选择

avatar DeepSeek技术社区
cover

Agent 工具权限爆炸？最小权限原则与 DeepSeek 多租户隔离实践

avatar DeepSeek技术社区