1. 项目概述：一个能听懂话、会干活的AI助手

最近我花了不少时间，捣鼓了一个挺有意思的东西：一个能通过语音控制的AI智能体。简单来说，就是你对着麦克风说句话，比如“帮我创建一个叫‘计划.txt’的文件，内容写‘明天开会’”，它就能听懂你的意图，然后真的在你的电脑上把这个文件创建好，并把结果展示给你看。整个过程是实时的，从声音输入到动作执行，再到结果反馈，形成了一个完整的闭环。

这个项目的核心目标，就是打通“语音理解”到“实际执行”这最后一公里。市面上很多语音助手能和你聊天，但让它们真正去操作你的本地系统（比如写文件、运行代码），往往就束手无策了，要么是出于安全考虑被严格限制，要么就是功能非常单一。我这个项目尝试构建一个端到端的系统，把语音识别、大语言模型的理解与决策、以及安全的本地工具执行这几个模块串联起来，做一个真正能“动手”的AI伙伴。它非常适合那些希望用自然语言交互来简化重复性电脑操作的朋友，比如开发者、内容创作者或者任何想提升工作效率的人。

2. 系统架构设计与核心思路

2.1 为什么选择模块化流水线？

整个系统的骨架，我设计成了一个清晰的模块化流水线： 音频输入 -> 语音转文本 -> 意图理解 -> 工具执行 -> 结果展示 。这个结构看起来简单，但背后有几个关键的考量。

首先， 可维护性和可调试性 是首要原则。每个模块只负责一件明确的事情，它们之间通过定义好的接口（比如前一个模块的输出是后一个模块的输入）进行通信。当系统出问题时，我可以快速定位是哪个环节掉了链子。是语音识别没听清？还是大模型理解错了意图？或者是工具执行时权限不够？分而治之，排查效率大大提升。

其次，这种设计带来了极强的 可扩展性 。假设我觉得现在用的语音识别模型不够准，或者出了更快的本地模型，我只需要替换掉“语音转文本”这个模块，而完全不用动其他部分的代码。同样，如果想增加新的能力，比如“发送邮件”或“查询数据库”，我只需要在“工具执行”模块里注册一个新的工具函数，并在“意图理解”模块中教会大模型识别这个新意图即可。这种松耦合的设计，让系统能跟上技术迭代的步伐。

最后，它符合 生产级系统 的常见设计模式。在真实的软件工程中，尤其是AI应用，很少会把所有功能塞进一个巨无霸的模型里。而是倾向于构建“管道”，每个环节使用最适合的技术栈。这样既能保证每个环节的质量，也便于团队分工协作。

2.2 核心组件选型背后的逻辑

确定了架构，接下来就是为每个环节挑选合适的“武器”。我的选型主要围绕三个核心：效果、效率、以及开发便捷性。

1. 语音转文本：从本地挣扎到云端妥协 最初，我铁了心要用本地模型，首选是OpenAI开源的Whisper。它精度高，且离线运行能更好地保护隐私。但在我的开发机（16GB RAM）上跑起来非常吃力，尤其是稍大一点的模型，加载和推理过程几乎吃满内存，导致整个系统卡顿不堪。经过几轮测试，我意识到在有限硬件上追求完全本地化的STT，会牺牲系统的实时性和流畅度，这与项目“实时执行”的目标相悖。 因此，我做出了一个务实的折衷：转向API方案。 我选择了Groq提供的基于Whisper的API。原因有三：一是Groq以其LPU推理引擎闻名，速度极快，能实现近乎实时的转录，满足了“实时”需求；二是作为API，它稳定可靠，我不需要操心模型加载和硬件兼容性问题；三是虽然数据离开了本地，但对于这个侧重功能演示的项目而言，在可控的输入下（比如不涉及敏感信息），这是一个可以接受的权衡。 这里给想复现的朋友提个醒： 如果你对隐私有极高要求，且拥有足够强大的GPU（比如8GB以上显存），可以尝试量化后的Whisper小型模型（如 whisper-tiny.en ）或专门针对边缘设备优化的引擎（如 faster-whisper ），但这需要额外的优化和调试工作。

2. 意图理解与决策：大语言模型作为“大脑” 这是系统的智能核心。我需要一个模型来理解转录后的文本，并判断用户到底想干什么。我直接使用了OpenAI的GPT-3.5/4系列模型作为推理引擎。为什么不训练一个专门的分类模型？因为用户的指令是开放域的，千变万化，传统的意图分类模型需要大量的标注数据，且难以覆盖所有长尾情况。而大语言模型凭借其强大的泛化能力和指令遵循能力，非常适合完成“理解自然语言指令并输出结构化决策”的任务。 我通过设计精心的 系统提示词 来引导它。提示词里明确了系统角色（一个能执行系统命令的助手）、可用的工具列表（创建文件、写代码等）、以及必须输出的格式（例如一个固定的JSON结构，包含 intent 和 parameters ）。这样，模型就变成了一个可控的决策器。

3. 工具执行层：安全与能力的平衡 这是最需要谨慎对待的部分。让AI执行系统命令，无异于赋予它一定的“权限”。我的原则是： 能力可以少，安全不能松。

   • 安全沙箱 ：所有文件操作都被严格限制在一个指定的、项目内的 output 文件夹中。AI绝对无法访问或修改这个文件夹之外的任何系统文件。这是通过在执行工具的代码里进行路径检查和限制来实现的。
   • 操作确认 ：对于创建、删除、写入文件等“危险”操作，系统会通过UI明确询问用户是否确认执行，实现“人在回路”的干预。这给了用户最后一道安全闸。
   • 最小权限 ：工具函数只实现最必要的功能。例如，“写代码”工具并不是让AI直接运行任意代码，而是生成代码片段后，将其保存为文件，由用户决定后续操作。

4. 用户界面：透明化的交互窗口 我选择了Streamlit来构建Web界面。原因很简单：它是用Python快速构建数据应用的神器，几行代码就能拉起一个带有按钮、文本框、音频组件的页面，完美契合这个需要实时显示中间状态（语音转写文本、识别出的意图、执行日志）的项目。Streamlit的会话状态管理也方便我实现对话记忆的功能。

3. 核心模块深度解析与实操要点

3.1 语音处理模块：从声音到文字的可靠转换

这个模块的输入是原始的音频波形，输出是一段干净的文本。虽然我最终用了API，但其内部流程和本地处理是相通的。

实操流程如下：

1. 音频采集与预处理 ：通过Streamlit的 st.audio_input 组件或 pyaudio 库捕获麦克风输入。得到的原始音频通常需要预处理，包括：

   • 降噪 ：使用 librosa 或 noisereduce 库减少环境噪音。
   • 归一化 ：调整音频音量至一个标准水平，避免声音过小导致识别失败。
   • 格式转换 ：确保音频采样率（如16kHz）和格式（如WAV/PCM）符合模型或API的要求。

   注意： 麦克风的质量和录音环境对识别效果影响巨大。实测中，一个安静的环境和清晰的麦克风，能将识别准确率提升30%以上。如果使用API，还需注意音频文件大小可能受限制，过长的音频需要分段处理。

2. 调用转录服务 ：将处理后的音频数据发送给Groq的Whisper API。这里的关键是构造正确的请求。

   import groq
   
   client = groq.Groq(api_key="your_api_key_here")
   
   def transcribe_audio(audio_file_path):
       with open(audio_file_path, "rb") as file:
           transcription = client.audio.transcriptions.create(
               file=file,
               model="whisper-large-v3", # 指定模型版本
               response_format="text",   # 获取纯文本
               language="en"             # 可指定语言以提高精度
           )
       return transcription.text
   

   参数解析 ： language 参数如果明确指定，能显著提升对应语言的识别准确率并减少转录时间。对于中英混杂的场景，可以不指定，让模型自动检测，但准确率可能略有波动。

3. 后处理与纠错 ：API返回的文本可能包含一些无意义的语气词（如“呃”、“嗯”）或标点错误。可以添加一个简单的后处理步骤，利用规则或一个小型语言模型进行润色。例如，将“帮我创建一个文件”纠正为“帮我创建一个文件”。

3.2 意图理解模块：让AI读懂你的心

这是系统的“大脑”，也是最体现AI能力的地方。我的方法不是简单的关键词匹配，而是利用大语言模型进行深度语义理解。

核心实现步骤：

1. 设计系统提示词 ：这是控制模型行为的关键。一个优秀的提示词需要清晰定义任务、约束和输出格式。

   system_prompt = """
   你是一个能够理解用户指令并执行相应操作的AI助手。请分析用户的输入，判断其意图，并按要求输出JSON。
   
   可识别的意图包括：
   - create_file: 用户请求创建一个新文件。参数需包含 filename（文件名）和 content（文件内容）。
   - write_code: 用户请求编写一段代码。参数需包含 language（编程语言）和 task（代码任务描述）。
   - summarize_text: 用户请求总结一段文本。参数需包含 text（待总结的文本）。
   - general_chat: 用户在进行一般性对话或询问无法执行的问题。
   
   输出必须为严格的JSON格式，且只包含以下两个字段：
   {
       "intent": "上述意图之一",
       "parameters": { } // 对应意图所需的参数字典，如果意图是general_chat，此字段可为空字典{}
   }
   
   请仅输出JSON，不要有任何其他解释。
   用户输入：{user_input}
   """
   

2. 调用大语言模型 ：将拼接好的提示词发送给GPT。

   from openai import OpenAI
   
   client = OpenAI(api_key="your_openai_key")
   
   def parse_intent(user_text):
       prompt = system_prompt.format(user_input=user_text)
       response = client.chat.completions.create(
           model="gpt-3.5-turbo", # 或 gpt-4
           messages=[{"role": "system", "content": prompt}],
           temperature=0.1, # 低温度保证输出稳定，更倾向于遵循指令
           max_tokens=150
       )
       return response.choices[0].message.content
   

   关键参数解读 ：

   • temperature ：设置为较低值（如0.1-0.3），是为了让模型的输出更加确定和可预测，减少在意图分类这种需要精确输出的任务上的随机性。
   • max_tokens ：限制输出长度，防止模型“废话连篇”，因为我们只期望一个简短的JSON。

3. 解析与规则兜底 ：模型返回的是一个JSON字符串，需要用 json.loads() 解析成Python字典。 这里有一个非常重要的增强技巧：规则覆盖。 我发现对于某些非常明确、固定的指令模式（比如以“写一个Python函数计算斐波那契数列”开头的），大模型偶尔也会抽风。因此，我增加了一个简单的规则层，在将文本送入大模型前，先用正则表达式匹配一些高置信度的模式，如果匹配成功，则直接返回对应的意图和参数，不再调用昂贵的模型。这既提高了响应速度，也提升了特定场景下的准确率。

3.3 工具执行模块：安全地将想法变为现实

得到结构化的意图和参数后，就进入了执行阶段。每个意图都对应一个具体的工具函数。

工具函数设计示例：

1. 创建文件工具 ：

   import os
   from pathlib import Path
   
   OUTPUT_DIR = Path("./safe_output") # 定义安全输出目录
   OUTPUT_DIR.mkdir(exist_ok=True) # 确保目录存在
   
   def create_file(filename, content):
       # 1. 安全检查：防止路径穿越攻击
       safe_path = (OUTPUT_DIR / filename).resolve()
       if not str(safe_path).startswith(str(OUTPUT_DIR.resolve())):
           return {"status": "error", "message": "非法文件路径！"}
       
       # 2. 写入文件
       try:
           safe_path.write_text(content, encoding='utf-8')
           return {"status": "success", "message": f"文件 '{filename}' 创建成功", "path": str(safe_path)}
       except Exception as e:
           return {"status": "error", "message": f"文件创建失败: {str(e)}"}
   

   安全要点 ： resolve() 方法用于获取文件的绝对路径，然后检查这个绝对路径是否仍然在我们规定的安全目录 OUTPUT_DIR 之下。这有效防止了用户通过输入 ../../../etc/passwd 这样的文件名进行路径穿越攻击。

2. 编写代码工具 ：

   def write_code(language, task):
       # 1. 构造给大模型的提示词，让它生成代码
       code_prompt = f"请用{language}编写代码，实现以下功能：{task}。只输出代码，不要有任何解释。"
       
       # 2. 调用大模型生成代码
       code_response = client.chat.completions.create(
           model="gpt-3.5-turbo",
           messages=[{"role": "user", "content": code_prompt}],
           temperature=0.2
       )
       generated_code = code_response.choices[0].message.content
       
       # 3. 将生成的代码保存为文件
       filename = f"generated_code_{hash(task)}.{language}" # 简单生成唯一文件名
       return create_file(filename, generated_code) # 复用安全的创建文件函数
   

   经验之谈 ：让大模型“只输出代码”的指令并不总是被完美遵守。生成的代码前后有时会带有Markdown代码块的标记（```）或自然语言解释。你需要在保存前做一个简单的清洗，用正则表达式去除这些多余内容。

3. 总结文本工具 ：这个相对简单，直接调用大模型的总结能力即可，结果可以显示在UI上，也可以选择保存为文件。

“人在回路”机制 ：在调用 create_file 或 write_code 这类有副作用的工具前，系统会暂停，并在Streamlit界面上弹出一个确认按钮，显示即将执行的操作详情（如“即将创建文件：plan.txt”）。只有用户点击确认后，才会真正执行。这是一个至关重要的安全与信任设计。

3.4 会话记忆与上下文管理

为了让对话更自然，系统需要记住之前说过的话。例如，用户说“创建一个文件”，然后说“内容写上‘你好世界’”，系统需要知道第二句话是接着第一句的“创建文件”意图来的。

我利用Streamlit的会话状态来实现简单的短期记忆。

import streamlit as st

# 初始化会话状态
if 'conversation_history' not in st.session_state:
    st.session_state.conversation_history = []

def chat_with_memory(user_input):
    # 将历史对话和当前输入一起送给模型
    messages_for_llm = [
        {"role": "system", "content": "你是一个助手，这是之前的对话历史。"}
    ]
    for msg in st.session_state.conversation_history[-5:]: # 只保留最近5轮，防止上下文过长
        messages_for_llm.append(msg)
    messages_for_llm.append({"role": "user", "content": user_input})
    
    # ... 调用模型 ...
    response = get_llm_response(messages_for_llm)
    
    # 更新历史
    st.session_state.conversation_history.append({"role": "user", "content": user_input})
    st.session_state.conversation_history.append({"role": "assistant", "content": response})
    
    return response

注意事项 ：大模型有上下文长度限制。无限制地保存所有历史记录会很快耗尽Token，导致API调用失败或响应变慢。因此，需要设计一个策略，比如只保留最近N轮对话，或者当历史记录超过一定长度时，尝试用大模型自己来总结之前的对话摘要，然后用摘要代替详细历史。

4. 前端集成与完整工作流实现

4.1 使用Streamlit构建交互界面

Streamlit让构建这样一个实时交互应用变得异常简单。整个UI的逻辑围绕一个主循环展开。

核心UI组件与布局：

import streamlit as st
import audio_processing # 自定义的音频处理模块
import intent_parser   # 自定义的意图解析模块
import tool_executor   # 自定义的工具执行模块

st.title("🎤 语音控制AI执行助手")

# 1. 音频输入区域
st.header("第一步：说话")
audio_bytes = st.audio_input("点击麦克风开始录音", key="audio_input")

# 2. 处理流程展示区域
if audio_bytes:
    with st.spinner("正在处理您的语音..."):
        # 步骤1: 保存并转录音频
        audio_file = "temp_audio.wav"
        with open(audio_file, "wb") as f:
            f.write(audio_bytes)
        
        transcribed_text = audio_processing.transcribe_audio(audio_file)
        st.subheader("📝 识别出的文本")
        st.write(transcribed_text)
        
        # 步骤2: 解析意图
        intent_result = intent_parser.parse_intent(transcribed_text)
        st.subheader("🧠 解析出的意图")
        st.json(intent_result) # 以JSON格式美观地显示
        
        # 步骤3: 执行与确认
        st.subheader("⚙️ 执行操作")
        if intent_result["intent"] in ["create_file", "write_code"]:
            # 危险操作，需要确认
            st.warning("⚠️ 即将执行以下操作：")
            st.write(f"类型：{intent_result['intent']}")
            st.write(f"参数：{intent_result['parameters']}")
            if st.button("✅ 确认执行", key="confirm_exec"):
                with st.spinner("执行中..."):
                    exec_result = tool_executor.execute_tool(intent_result)
                    st.success(exec_result["message"])
        else:
            # 安全操作（如聊天、总结），直接执行
            exec_result = tool_executor.execute_tool(intent_result)
            st.info(exec_result["message"])

# 3. 会话历史侧边栏
with st.sidebar:
    st.header("💬 对话历史")
    if st.session_state.conversation_history:
        for msg in st.session_state.conversation_history[-5:]:
            with st.chat_message(msg["role"]):
                st.write(msg["content"])
    else:
        st.write("暂无历史记录")

4.2 状态管理与错误处理

一个健壮的应用必须优雅地处理各种异常。

1. 网络错误 ：调用Groq或OpenAI API时可能失败。需要使用 try...except 包裹，并在前端给出友好提示。

   try:
       transcribed_text = audio_processing.transcribe_audio(audio_file)
   except Exception as e:
       st.error(f"语音识别服务暂时不可用: {e}")
       transcribed_text = None
       # 可以在这里设置一个重试机制，或者使用备用的本地轻量模型
   

2. 模型输出格式错误 ：大模型可能不按约定的JSON格式输出。解析时需要用 try...except json.JSONDecodeError 捕获，并触发一个修正流程（例如，让模型重新生成）。

   import json
   try:
       intent_dict = json.loads(model_raw_output)
   except json.JSONDecodeError:
       st.warning("AI回复格式异常，正在尝试修复...")
       # 发送一个修正请求给模型
       fix_prompt = f"你之前的回复不是有效的JSON。请严格按以下格式重新输出：{system_prompt}"
       # ... 重新调用模型 ...
   

3. 工具执行错误 ：文件已存在、权限不足、磁盘已满等。工具函数本身应返回包含状态信息的字典（如 {"status": "error", "message": "..."} ），前端根据状态码显示不同信息。

5. 部署考量与性能优化实战

5.1 本地部署与生产化思考

虽然开发时我们用Streamlit的 run 命令很方便，但要真正让别人能用，需要考虑部署。

• Streamlit Cloud / Hugging Face Spaces ：最简单的部署方式。将代码推送到GitHub，然后在这些平台上关联仓库即可。它们免费套餐对于演示项目通常够用。 注意 ：你需要将API密钥设置为这些平台的“Secrets”，而不是硬编码在代码里。
• Docker容器化 ：更专业和可移植的方式。创建一个Dockerfile，定义Python环境、安装依赖、复制代码、暴露端口。这样可以在任何支持Docker的机器或云服务上运行。

  FROM python:3.10-slim
  WORKDIR /app
  COPY requirements.txt .
  RUN pip install --no-cache-dir -r requirements.txt
  COPY . .
  EXPOSE 8501
  CMD ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"]
  

• API密钥管理 ：绝对不要将密钥提交到Git！使用环境变量或 .env 文件管理。

  import os
  from dotenv import load_dotenv
  load_dotenv() # 加载 .env 文件中的变量
  api_key = os.getenv("GROQ_API_KEY")
  

5.2 性能瓶颈分析与优化技巧

在开发和测试中，我遇到了几个主要的性能瓶颈及应对策略：

1. 端到端延迟 ：从说话到看到结果，时间可能较长。主要耗时点在语音识别API调用和大模型API调用。

   • 优化策略 ：
     • 并行化 ：如果流程允许，可以让语音识别和大模型意图解析并行进行？但在这个线性管道中不太可行。一个可行的优化是，在用户说话时就开始上传音频，而不是等录音完全结束。
     • 模型选型 ：使用更快的模型。例如，Groq的Whisper API本身已经极快。对于意图解析，如果任务简单，可以降级使用 gpt-3.5-turbo 而不是 gpt-4 ，速度会快很多，成本也更低。
     • 缓存 ：对于常见的、固定的查询（如“你好”、“今天天气怎么样”），可以设置一个简单的缓存，直接返回结果，避免调用模型。

2. 大模型上下文过长 ：随着对话历史增长，每次发送给模型的Token数增加，导致响应变慢、成本升高。

   • 优化策略 ：如前所述，实现一个“滑动窗口”记忆，只保留最近N轮对话。或者更高级一点，定期用大模型将长篇历史总结成一段简短的摘要，然后用摘要作为后续对话的上下文。

3. 前端响应性 ：长时间的操作会阻塞Streamlit界面，让用户以为卡死了。

   • 优化策略 ：充分利用Streamlit的 st.spinner() 、 st.progress() 和状态提示（ st.success / st.error ），给用户明确的反馈。对于极其耗时的操作，可以考虑引入后台任务队列（如Celery），但这会大大增加架构复杂度，对于轻量级应用可能得不偿失。

6. 常见问题排查与实用技巧实录

在实际搭建和运行过程中，你几乎一定会遇到下面这些问题。这里是我踩过坑后总结的排查清单和解决方法。

问题现象	可能原因	排查步骤与解决方案
录音没有反应，收不到音频	1. 浏览器未授予麦克风权限。 2. Streamlit的音频组件兼容性问题。 3. 后端音频处理库（如PyAudio）未安装或配置错误。	1. 检查浏览器地址栏的麦克风图标，确保权限已开启。尝试在隐身模式下运行，排除插件干扰。 2. 尝试使用 streamlit-webrtc 等更先进的音频组件，兼容性更好。 3. 如果使用PyAudio，在Windows上可能需要安装 PortAudio ，在Linux上可能需要 libasound2-dev 。使用 pip install pyaudio 看错误信息。
语音识别结果全是乱码或错误	1. 音频质量差（噪音大、音量小）。 2. 音频格式或采样率与API要求不符。 3. 语言设置不匹配。	1. 增加音频预处理步骤：降噪、增益标准化。确保在安静环境下测试。 2. 确认API支持的格式（如WAV, MP3, 采样率16kHz）。使用 librosa 或 pydub 统一转换格式。 3. 如果用户说中文，但API默认识别英文，结果会不准。在调用API时明确指定 language="zh" 。
大模型返回的意图总是 general_chat	1. 系统提示词设计不清晰，未能有效引导模型。 2. 用户指令过于模糊或复杂，超出预设意图范围。 3. 模型温度参数过高，输出不稳定。	1. 优化提示词。在提示词中提供更具体的例子（Few-shot Learning），例如：“用户说‘创建文件’，意图是create_file；用户说‘写个Python爬虫’，意图是write_code”。 2. 在UI上引导用户，给出示例指令格式。 3. 将 temperature 参数调低至0.1或0.2。
工具执行失败，报权限错误	1. 程序运行时用户权限不足。 2. 指定的安全输出目录不存在或路径错误。 3. 试图在安全目录之外创建文件（路径穿越攻击防护生效）。	1. 确保运行程序的用户对当前目录有读写权限。 2. 在代码开头使用 os.makedirs(OUTPUT_DIR, exist_ok=True) 确保目录存在。 3. 检查你的路径安全检查逻辑。打印出 safe_path 和 OUTPUT_DIR 的解析后路径，确认它们的关系。
Streamlit应用运行后，界面刷新异常或状态丢失	1. 脚本被重复执行（Streamlit的特性）。 2. 会话状态未正确初始化或使用。	1. 将所有初始化代码（如创建目录、初始化API客户端）放在检查 st.session_state 的if语句后面，或使用 @st.cache_resource 装饰器。 2. 所有需要跨“重载”保持的变量，都必须存入 st.session_state ，而不是普通的Python变量。
API调用超时或频率受限	1. 网络连接不稳定。 2. 免费API有速率限制。 3. 请求的Token数超限。	1. 增加请求的超时设置，并添加重试逻辑（使用 tenacity 库）。 2. 查看所用API服务的文档，了解速率限制。在代码中添加延迟（ time.sleep ）或使用异步请求。 3. 监控每次请求的Token使用量，对于长文本输入，考虑先进行截断或总结。

最后分享几个提升体验的小技巧：

1. 给AI“声音” ：执行完成后，除了在界面显示文字，还可以用文本转语音技术（如 pyttsx3 本地库或Edge TTS API）将结果读出来，体验更沉浸。
2. 支持文件上传 ：扩展“总结文本”功能，允许用户上传PDF、Word文档，先用工具提取文本，再进行总结。
3. 意图扩展实战 ：添加“执行系统命令”工具时要极度小心。可以限定只能执行一个预定义的白名单命令（如 ls , pwd , date ）。绝对不要直接将用户输入拼接成命令执行，这等同于开放了一个远程Shell，极其危险。任何执行外部命令的操作，都必须经过严格的过滤和确认。
4. 离线化的可能 ：如果硬件允许，可以探索完全离线的方案。语音识别用 faster-whisper ，语言模型用量化后的 Llama 3.2 或 Qwen 2.5 小尺寸版本，通过 ollama 或 llama.cpp 本地部署。这能彻底解决隐私和网络依赖问题，但需要较强的本地算力。