尧图网站建设 
最近和汽车行业的朋友交流时总绕不开一个问题国产大模型迭代这么快是不是又要让车企和供应商更“卷”我的观点其实很明确大模型即使发展再快也不应该被简单当作“压成本、拼话术、堆演示”的内卷工具。真正的价值是把过去依赖老师傅经验、需要反复翻手册、跨系统查询才能完成的业务改造成“人机协同”的新工作流。这篇文章不聊宏大叙事而是从工程视角出发用一套可复现的汽车售后知识助手示例把国产大模型接入业务系统的完整链路拆开模型选型、RAG 检索增强、Function Calling 工具调用、API 服务封装、生产部署建议。目标是让读者既能理解概念也能拿到代码跑通一个最小可用案例并知道如何避开常见工程坑。1. 为什么国产大模型的终点不是“内卷工具”1.1 技术繁荣带来的机会与误区国产大模型确实处在快速迭代阶段。Qwen 系列开源模型、DeepSeek、智谱、百川等都有很强的通用对话和推理能力同时各个云厂商也提供了兼容 OpenAI 格式的 API。这种局面让企业可以用很低的上手成本做 AI 应用开发。但机会越多误区也越明显。很多团队拿到大模型后第一反应是“用它写周报、写话术、做客服自动回复”然后把响应速度、上下文长度、参数规模当作竞争指标。这些动作也许能带来短期的新鲜感但很难沉淀成真正的业务壁垒。尤其在汽车产业里一个错误回答可能会导致维修动作出错一次无依据的“自动诊断”可能带来售后责任风险。所以大模型落地不能只看“能不能生成”还要看“依据是什么、谁来做最终确认”。1.2 更值得落地的方向是长尾场景汽车产业真正值得投入的方向是信息找人、经验复制的长尾场景。比如新车上市后售后技师遇到一个没见过的故障码过去需要翻维修手册、查内部知识库、在工单系统里翻历史案例运气不好还要打电话问总部专家。如果系统能把维修手册、技术通报、历史工单统一接入大模型通过检索增强生成和 AI Agent 把信息快速汇总给技师再由技师判断执行这个效率提升是非常直观的。这种场景不是“替代人”而是“辅助人”。它不追求让 AI 独立做出维修决定而是缩短人获取正确信息的时间减少重复劳动。这也是本文示例要选“售后知识助手”的原因业务边界清晰、知识库相对封闭、价值容易量化。1.3 案例目标本文要实现的示例是一个汽车售后问答 API。它包含三个能力根据维修手册片段回答保养和故障排查问题。当用户询问故障码时通过 Function Calling 调用本地故障码查询函数。回答必须引用检索到的资料资料不足时明确提示“转人工处理”不允许编造。这样一个案例麻雀虽小却已经覆盖了大模型应用开发、AI 工程实践和模型部署的大部分关键知识点。2. 汽车产业 AI 应用的核心技术拆解2.1 RAG 为什么是业务落地的第一站RAGRetrieval-Augmented Generation检索增强生成是目前大模型进入企业业务系统最稳妥的路径。原因是企业真正有价值的知识往往不在通用大模型的训练数据里而是散落在维修手册、设计文档、历史工单、实验报告中。如果不做 RAG直接让大模型凭训练知识回答很容易出现“一本正经地胡说八道”。做了 RAG 之后系统会先从知识库里检索出和用户问题最相关的片段再把片段拼到 Prompt 中让大模型基于这些片段回答。这里要理解一个关键点RAG 并不是把整个知识库发给模型而是“先检索、后生成”。检索质量直接决定了回答质量。很多人以为 Prompt 写得越长效果越好其实当相关片段被淹没在大量噪声中时模型反而更容易答偏。2.2 AI Agent 与 Function Calling 的作用光有 RAG 还不够。有些业务问题无法通过知识库检索解决而是需要调用已有系统。比如用户问“帮我查一下 P0073 故障码”这个故障码的解释可能存在售后系统中而不是维修手册里。这时候就需要让大模型具备“工具调用”能力。在 OpenAI 兼容接口中这个能力通常叫 Function Calling 或 Tool Calling。大模型负责理解用户意图把问题转换成结构化的函数参数然后由业务系统去执行真实查询最后再把查询结果交给大模型组织成自然语言回复。在 AI Agent 架构里这只是一个很小的循环模型决定调用什么工具系统执行工具模型拿到工具结果后继续回答。真实项目中 Agent 可能会包含多轮工具调用、状态记忆、人工审批节点但底层机制是一样的。2.3 为什么仍然需要人机协同无论是 RAG 还是 Function Calling本质都是“降低人获取信息的成本”而不是“替代人的责任”。汽车维修涉及安全、保修、责任认定完全由模型自动输出处理建议并直接执行风险非常高。因此工程上要设计人工审核节点。模型可以生成维修建议、整理工单摘要、推荐检查步骤但最终是否执行、是否下单、是否通知客户必须由有资质的人员确认。这也是为什么我说大模型不应该成为“内卷工具”如果把它用于压减人工审核环节短期看省了人力长期看可能把风险成倍放大。3. 环境准备与模型选型3.1 运行环境本文示例代码使用 Python 编写这样能最直观地展示 embedding、检索、Function Calling 的完整链路。你本地需要准备Python 3.10 或更高版本。一个可用的国产大模型 API Key推荐阿里云百炼 DashScope或者 DeepSeek 开放平台。一个支持 OpenAI 兼容协议的 SDK本文使用openaiPython SDK。FastAPI 与 Uvicorn 用于暴露 HTTP 接口。如果你更习惯 Java 技术栈后文也会给出 Spring AI 接入国产大模型的配置参考但完整示例以 Python 为主。版本方面不同框架迭代很快不建议照抄过旧或过新的版本号。建议安装以下库的最新稳定版pip install openai fastapi uvicorn[standard] python-dotenv numpy如果你的网络环境下载缓慢可以临时切换为镜像源但要注意镜像源的同步时间。3.2 模型服务选择国产大模型 API 普遍提供两个关键能力文本生成和文本向量化。本文在示例中选择 DashScope 的 OpenAI 兼容模式对话模型qwen-plus适合日常问答与工具调用。向量模型text-embedding-v3用于把维修手册切分后的片段向量化。如果你使用 DeepSeek通常只需要修改LLM_BASE_URL为 DeepSeek 的接口地址并把CHAT_MODEL换成 DeepSeek 的模型名。但要注意不同平台的向量模型能力不一样如果你的平台没有提供 embedding 接口可以继续使用 DashScope 或其他兼容平台做向量化也可以在后续工程化阶段替换为本地部署的 BGE 系列模型。下面是.env环境变量文件的示例LLM_API_KEYsk-你的密钥 LLM_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 CHAT_MODELqwen-plus EMBEDDING_MODELtext-embedding-v3需要注意密钥不要提交到 Git 仓库。生产环境建议使用密钥管理服务或 CI/CD 的 Secret 变量。3.3 项目结构创建一个干净的实验目录完整结构如下car_rag_demo/ ├── .env ├── requirements.txt ├── manual.txt └── app.py其中manual.txt是模拟的维修手册app.py是完整的 FastAPI 应用和 RAG 逻辑。下面我们一步步实现。4. 完整实战基于国产大模型构建汽车售后知识助手4.1 需求分析与流程设计这个知识助手需要服务两类问题。第一类是“知识查询”例如“空调不制冷应该先检查什么”。系统先从维修手册知识库中检索相关段落再把段落发送给大模型让模型基于资料回答。第二类是“工具查询”例如“帮我查一下 P0073 故障码”。系统需要识别用户意图调用query_fault_code函数然后再把查询结果整理成回答。完整业务流程可以拆成四步用户输入问题。系统对问题做向量化并在本地索引中检索 top_k 条相关知识片段。把知识片段、工具定义、用户问题一起发送给大模型。如果大模型返回工具调用指令则执行本地函数并把结果回传给大模型否则直接返回回答。之所以先检索再发送是为了控制 Token 消耗也为了让模型聚焦于与当前问题最相关的信息。4.2 准备维修手册数据我们先准备模拟的维修手册数据。为了演示简单这里只放两份文档。# 车内空调无法制冷排查手册 适用车型示例车型 X5 EV 故障现象出风口风量正常但制冷效果差。 排查步骤 1. 检查空调压缩机是否启动。 2. 检查制冷剂压力静态压力低时补充制冷剂。 3. 检查冷凝器表面是否堵塞。 4. 使用诊断仪读取空调控制模块故障码。 # 制动异响排查手册 适用车型示例车型 X5 EV 故障现象低速轻踩制动时有尖锐异响。 排查步骤 1. 检查刹车片厚度。 2. 检查刹车盘表面是否有沟槽。 3. 检查制动卡钳回位是否正常。 4. 若刹车片磨损到极限需要更换刹车片。实际项目中这些内容应该来自企业文档系统、售后知识库或技术通报。数据导入前最好做清洗去除重复章节、把扫描 PDF 转成文本、统一术语表述。如果知识库文件特别多需要先做任务拆分例如按车型、按系统、按故障类型建立独立索引。4.3 编写向量检索模块下面开始写核心代码。新建app.py先把依赖加载进去import json import os from pathlib import Path import numpy as np from dotenv import load_dotenv from fastapi import FastAPI from openai import OpenAI from pydantic import BaseModel load_dotenv() API_KEY os.getenv(LLM_API_KEY) BASE_URL os.getenv(LLM_BASE_URL, https://dashscope.aliyuncs.com/compatible-mode/v1) CHAT_MODEL os.getenv(CHAT_MODEL, qwen-plus) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-v3) if not API_KEY: raise RuntimeError(请在 .env 文件中配置 LLM_API_KEY) client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) app FastAPI(title汽车售后知识助手)接下来定义知识库类。这个类负责读取文档、切分文本、调用向量模型构建索引并提供相似度检索方法。class KnowledgeBase: def __init__(self, doc_path: str, chunk_size: int 300, overlap: int 30): self.doc_path Path(doc_path) self.chunk_size chunk_size self.overlap overlap self.chunks [] self.vectors np.array([]) def load_and_split(self): raw_text self.doc_path.read_text(encodingutf-8) sections [s.strip() for s in raw_text.split(\n\n) if s.strip()] chunks [] for section in sections: if len(section) self.chunk_size: chunks.append(section) else: start 0 while start len(section): end start self.chunk_size chunks.append(section[start:end]) start end - self.overlap self.chunks chunks def build_index(self): if not self.chunks: raise RuntimeError(请先调用 load_and_split) vectors [] batch_size 10 for i in range(0, len(self.chunks), batch_size): batch self.chunks[i:i batch_size] resp client.embeddings.create( modelEMBEDDING_MODEL, inputbatch ) vectors.extend([item.embedding for item in resp.data]) self.vectors np.array(vectors, dtypefloat32) def search(self, query: str, top_k: int 2): if self.vectors.size 0: raise RuntimeError(请先调用 build_index) resp client.embeddings.create( modelEMBEDDING_MODEL, input[query] ) query_vec np.array(resp.data[0].embedding, dtypefloat32) def _cosine(a, b): return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-8)) scores [_cosine(query_vec, vec) for vec in self.vectors] top_idx np.argsort(scores)[-top_k:][::-1] return [{text: self.chunks[i], score: scores[i]} for i in top_idx]这里需要解释几个细节。第一文档按段落切分而不是按空格切分这样能保留语义完整性。chunk_size表示最大字符数overlap是相邻片段的重叠长度。重叠字符可以避免一个完整句子被切断后丢失上下文。第二向量化时把多个文本片段组成 batch 发送可以减少网络请求次数提升索引构建速度。这里 batch 大小取 10真实项目中要根据 embedding 服务限制调整通常可以在 16 到 64 之间。第三相似度计算使用余弦相似度。对 embedding 向量先做归一化在工业实现中可以直接用内积代替余弦相似度速度会更快。但为了可读性这里保留完整计算过程。4.4 实现故障码工具调用接着定义模拟的故障码数据库和查询函数。真实项目中这个函数会去调用 DMS 售后系统、诊断仪数据平台或配件目录服务。FAULT_CODE_DB { P0073: { name: 环境温度传感器电路高, advice: 检查环境温度传感器及线束连接必要时更换传感器。, }, C0501: { name: 空调压缩机控制电路故障, advice: 检查压缩机继电器、保险丝与线束重新上电后再次读取故障码。, }, } def query_fault_code(fault_code: str) - str: fault_code fault_code.strip().upper() if fault_code not in FAULT_CODE_DB: return f暂未收录故障码 {fault_code}请转人工查询。 item FAULT_CODE_DB[fault_code] return f故障码{fault_code}含义{item[name]}建议{item[advice]}接下来定义 Function Calling 需要的工具描述。这个描述会被发送给大模型大模型根据用户问题决定是否调用TOOLS [ { type: function, function: { name: query_fault_code, description: 查询车辆故障码的含义与维修建议, parameters: { type: object, properties: { fault_code: { type: string, description: 整车故障码例如 P0073 } }, required: [fault_code] } } } ]工具描述必须足够清晰尤其是description和参数描述。很多模型不触发 Function Calling并不是模型不行而是函数名和参数含义写得模糊。例如“含义与维修建议”比“查询”更能帮助模型判断什么时候调用。4.5 编写对话处理逻辑接下来实现核心对话逻辑。这一段负责拼接 Prompt、调用大模型、处理 Function Calling 中间结果。def ask(question: str): docs kb.search(question, top_k2) context \n\n.join( f[来源{i 1}]\n{d[text]} for i, d in enumerate(docs) ) messages [ { role: system, content: ( 你是一名汽车售后技术支持助手。 请优先根据维修手册资料回答不要编造资料中没有的信息。 如果问题涉及故障码请调用 query_fault_code 获取结果。 如果资料不足请明确回复资料未覆盖请转人工处理。 f\n\n 维修手册检索结果 \n{context} ) }, { role: user, content: question } ] response client.chat.completions.create( modelCHAT_MODEL, messagesmessages, toolsTOOLS, temperature0.2, ) message response.choices[0].message if message.tool_calls: messages.append({ role: assistant, content: message.content, tool_calls: [ { id: tool_call.id, type: function, function: { name: tool_call.function.name, arguments: tool_call.function.arguments, }, } for tool_call in message.tool_calls ], }) for tool_call in message.tool_calls: tool_name tool_call.function.name args json.loads(tool_call.function.arguments or {}) if tool_name query_fault_code: tool_result query_fault_code(args.get(fault_code, )) else: tool_result f未知工具{tool_name} messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result, }) response client.chat.completions.create( modelCHAT_MODEL, messagesmessages, temperature0.2, ) message response.choices[0].message return { answer: message.content, references: [d[text] for d in docs], meta: { chat_model: CHAT_MODEL, embedding_model: EMBEDDING_MODEL, top_k: len(docs), }, }这段代码有几个容易出错的地方。第一如果有 Tool Call必须先把 assistant 的角色消息追加到 messages再追加 tool 消息。否则 API 会报错因为 tool 消息必须对应一个已经存在的 assistant Tool Call。第二tool_call.function.arguments是 JSON 字符串需要先解析成字典。解析失败时要做好异常处理实测中偶尔会出现参数格式不规范的情况。第三第二轮调用时不需要再带tools也可以。但为了保险建议继续携带tools这样模型如果还需要查其他故障码依然可以继续调用。在实际项目里应该用循环限制最多调用 2 到 3 次避免 Agent 陷入死循环。4.6 封装 FastAPI 接口最后加上两个 Pydantic 模型和 HTTP 路由。class ChatRequestBody(BaseModel): question: str class ChatResponseBody(BaseModel): answer: str references: list[str] [] meta: dict {} app.post(/chat, response_modelChatResponseBody) def chat(req: ChatRequestBody): if not req.question.strip(): return ChatResponseBody(answer问题不能为空) result ask(req.question) return ChatResponseBody( answerresult[answer], referencesresult[references], metaresult[meta], ) kb KnowledgeBase(manual.txt) kb.load_and_split() kb.build_index()这里把索引初始化放在了模块加载阶段简单直接适合演示。但在生产环境中最好把知识库索引放在独立服务中例如 FAISS、Milvus 或 PgVector并通过监听文档更新事件触发重新索引。4.7 运行与验证在项目目录下创建.env文件然后启动服务uvicorn app:app --reload --host 0.0.0.0 --port 8000启动成功后可以先测试知识问答curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {question: 空调不制冷应该先检查什么}预期回答会引用检索到的手册片段内容大致是先检查空调压缩机是否启动再检查制冷剂压力等。接着测试故障码查询curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {question: 帮我查一下 P0073 故障码}如果 Function Calling 链路正常模型会先调用query_fault_code(P0073)然后根据返回结果生成一段自然语言回答。返回的references字段里可能没有与故障码相关的知识片段这是正常的因为故障码数据来自工具调用而不是维修手册。5. 从 Demo 到可上线模型部署与工程化建议5.1 从 API 调用到私有化部署Demo 阶段使用云厂商大模型 API 很合适方便快速验证效果。但很多车企对数据安全要求较高不愿意把维修手册、车辆 VIN、故障数据发送到外部 API这时候就需要私有化部署开源模型。以 Qwen2.5 系列开源模型为例常见的推理部署方案是 vLLM。它支持高并发推理并提供 OpenAI 兼容的/v1/chat/completions接口。假设你有一台带 GPU 的 Linux 服务器可以先安装 vLLM然后执行vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen2.5-7b-instruct启动后调用方只需要修改LLM_BASE_URL为http://your-server:8000/v1CHAT_MODEL改为qwen2.5-7b-instruct代码无需大改即可切换。这也是早期选择“OpenAI 兼容协议”的好处。embedding 模型同样可以本地化部署。比如部署本地 BGE-M3 服务再将EMBEDDING_MODEL和调用地址指到本地服务从而实现全链路数据不出内网。5.2 Java Spring AI 接入方式参考如果团队技术栈是 Java 后端可以考虑使用 Spring AI。它是一个将 AI 模型能力抽象成 Spring Boot Starter 的框架可以让我们用比较熟悉的配置方式接入 OpenAI 兼容接口。下面给出参考配置spring.ai.openai.api-key${DASHSCOPE_API_KEY} spring.ai.openai.base-urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 spring.ai.openai.chat.options.modelqwen-plus注意Spring AI 版本迭代比较快不同版本的配置前缀和ChatClientAPI 可能存在差异。建议以当前使用的 Spring AI 官方文档为准。代码层面可以封装一个 ControllerRestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); } }这个例子只覆盖最基本的对话功能。要在 Java 服务里实现 RAG 和 Function Calling还需要把向量化、向量检索、工具函数等逻辑整合进去。工程上建议先通过 Python 快速验证效果再在 Java 侧做正式重构不要一上来就在 Java 里堆代码。5.3 评测、监控与降级上线前最容易被忽略的是评测。没有评测集就没有办法回答“这次换 Prompt 后效果是变好还是变坏”。可以整理 100 到 500 条真实售后问题分成几类可以在维修手册中找到答案的问题。需要调用故障码工具的问题。知识库覆盖不到、应该拒绝回答的问题。需要多轮上下文才能回答的问题。然后对每个问题预先写好标准答案和关键检查点形成回归评测集。每次修改 Prompt、调整检索参数、更换模型后都跑一遍评测集。重点看三个指标答案准确率、引用覆盖率、拒答准确率。答案准确率衡量回答内容是否与标准答案一致引用覆盖率衡量模型是否正确使用了检索到的资料拒答准确率衡量模型能否在资料不足时主动说“不知道”。生产链路还必须加监控和降级。如果大模型 API 超时或者向量数据库不可用接口不应该直接报错而应该降级为“搜索模式”只返回检索到的知识片段或者提示用户稍后重试。每次请求的模型、Prompt 版本、知识库版本、Token 消耗、响应延迟、人工修改结果都应该记录到日志或数据库中否则后续很难排查线上问题。6. 常见问题与排查思路问题现象常见原因解决思路调用 API 返回 401API Key 错误或没有对应模型权限检查.env中的密钥、服务所在区域、模型是否开通返回内容与知识库无关RAG 检索结果不相关或 Prompt 约束不足提高 top_k检查文档切分质量降低温度参数模型回答编造资料外内容Prompt 没有明确拒绝或知识库检索为空在 System Prompt 中要求“资料未覆盖必须转人工”并设置兜底逻辑Function Calling 不触发工具描述不清晰或模型不支持该格式精简函数描述增加示例参数尝试换更强模型报错 tool 消息没有对应 assistant未把 assistant Tool Call 记录追加到 messages在追加 tool 消息前先追加包含 tool_calls 的 assistant 消息embedding 模型不能调用当前平台没有提供向量模型改用 DashScope text-embedding-v3或本地部署 BGE 系列模型知识库更新后回答仍是旧内容索引没有重建建立文档变更监听触发重新切分、重新 embedding 并更新索引检索结果返回空文档切分后为空或 embedding 维度不一致检查知识库文件编码建议统一为 UTF-8Spring AI 配置不生效版本不同导致配置前缀变化检查依赖版本以官方文档对应章节为准接口响应太慢向量检索全量扫描或模型推理耗时长生产环境使用向量数据库对模型推理做缓存和超时控制这里的核心思路是先区分问题出在检索链路、模型链路还是系统链路。检索链路问题看召回内容模型链路问题看 Prompt 和模型参数系统链路问题看日志、超时和熔断配置。7. 最佳实践让 AI 成为“助手”而非“内卷工具”7.1 以业务指标作为验收标准在汽车产业做大模型应用不应该用“上线了多少 AI 功能”来验收而应该用“每张工单平均查询时间下降了多少”“首次修复率是否提升”“技师培训周期是否缩短”来衡量。如果某个 AI 功能上线后只是让系统多了一个聊天框但业务人员根本不用那它本质上就是内卷。反过来如果系统能让新技师在遇到陌生故障时少花一半时间找到维修资料这个 AI 应用就有明确价值。所以在做任何一个方向之前先问一个问题这个功能让谁的工作更简单了7.2 权限、安全与数据合规汽车行业涉及的数据敏感度高车型配置、维修记录、客户信息、供应链信息都不能随意输入外部大模型。建议遵循最小权限原则普通账号只能查询与自己工作相关的知识库。涉及客户隐私数据的字段在进入大模型之前先脱敏。系统日志中不记录完整 Prompt 和完整回复只记录关键统计信息。私有化部署时做好模型服务的网络隔离和账号审计。外部 API 调用前由安全团队审核数据流向。如果未来要让 AI 自动写维修工单或自动下单必须增加人工审批节点。AI 可以起草内容但“确认”这个动作必须由人完成。7.3 长期维护与 Prompt 版本管理很多团队把 Prompt 当成“写一次就永久有效”的配置这是错误想法。业务知识在变、模型版本在变、用户提问方式在变Prompt 和知识库都需要持续维护。工程上可以这样管理每一个 Prompt 都有一个版本号例如aftersale_qa_v23。每次修改 Prompt 都要在评测集上跑一遍记录效果变化。知识库文档更新时记录来源、更新时间、负责人。线上调用时在日志中记录 Prompt 版本方便问题回溯。大模型 API 升级模型版本前先在预发环境跑评测集再决定是否切换。这听起来像传统软件的版本管理但确实是大模型应用稳定运行的关键。不要相信“Prompt 看起来差不多所以不用测试”很多线上效果下降都是因为检索到的知识片段变了而不是模型变笨了。7.4 落地节奏建议如果今天要启动一个汽车产业大模型项目我建议按这样的节奏推进第一步选一个明确的小场景例如“售后故障码查询辅助”不要一上来就做全公司知识中台。第二步用本文示例快速跑通完整链路确认 API、模型、向量检索都可行。第三步整理 50 条真实问题设计简单的评测集记录当前效果基线。第四步逐步接入真实知识库和业务系统每接入一个数据源就重新跑评测。第五步设计人工审核和反馈收集机制让一线人员可以在页面上标记“回答有用”或“回答错误”。当积累了一定量的真实反馈后你会发现系统改进方向不再是“换更大的模型”而是“把知识库组织得更好把工具调用设计得更稳把人机协作流程打磨得更顺”。这才是国产大模型在汽车产业里更有意义的路径不是造一个内卷工具而是造一个能放大一线工程师、技师和客服人员能力的助手。如果你正在做类似的大模型应用开发希望这篇文章能帮你少走弯路。代码只是一个起点真正有价值的是你对业务场景的理解、对评测体系的坚持以及对“人机协同边界”的清醒认识。 国产大模型应用开发实战：构建汽车售后RAG知识助手
最近和汽车行业的朋友交流时总绕不开一个问题国产大模型迭代这么快是不是又要让车企和供应商更“卷”我的观点其实很明确大模型即使发展再快也不应该被简单当作“压成本、拼话术、堆演示”的内卷工具。真正的价值是把过去依赖老师傅经验、需要反复翻手册、跨系统查询才能完成的业务改造成“人机协同”的新工作流。这篇文章不聊宏大叙事而是从工程视角出发用一套可复现的汽车售后知识助手示例把国产大模型接入业务系统的完整链路拆开模型选型、RAG 检索增强、Function Calling 工具调用、API 服务封装、生产部署建议。目标是让读者既能理解概念也能拿到代码跑通一个最小可用案例并知道如何避开常见工程坑。1. 为什么国产大模型的终点不是“内卷工具”1.1 技术繁荣带来的机会与误区国产大模型确实处在快速迭代阶段。Qwen 系列开源模型、DeepSeek、智谱、百川等都有很强的通用对话和推理能力同时各个云厂商也提供了兼容 OpenAI 格式的 API。这种局面让企业可以用很低的上手成本做 AI 应用开发。但机会越多误区也越明显。很多团队拿到大模型后第一反应是“用它写周报、写话术、做客服自动回复”然后把响应速度、上下文长度、参数规模当作竞争指标。这些动作也许能带来短期的新鲜感但很难沉淀成真正的业务壁垒。尤其在汽车产业里一个错误回答可能会导致维修动作出错一次无依据的“自动诊断”可能带来售后责任风险。所以大模型落地不能只看“能不能生成”还要看“依据是什么、谁来做最终确认”。1.2 更值得落地的方向是长尾场景汽车产业真正值得投入的方向是信息找人、经验复制的长尾场景。比如新车上市后售后技师遇到一个没见过的故障码过去需要翻维修手册、查内部知识库、在工单系统里翻历史案例运气不好还要打电话问总部专家。如果系统能把维修手册、技术通报、历史工单统一接入大模型通过检索增强生成和 AI Agent 把信息快速汇总给技师再由技师判断执行这个效率提升是非常直观的。这种场景不是“替代人”而是“辅助人”。它不追求让 AI 独立做出维修决定而是缩短人获取正确信息的时间减少重复劳动。这也是本文示例要选“售后知识助手”的原因业务边界清晰、知识库相对封闭、价值容易量化。1.3 案例目标本文要实现的示例是一个汽车售后问答 API。它包含三个能力根据维修手册片段回答保养和故障排查问题。当用户询问故障码时通过 Function Calling 调用本地故障码查询函数。回答必须引用检索到的资料资料不足时明确提示“转人工处理”不允许编造。这样一个案例麻雀虽小却已经覆盖了大模型应用开发、AI 工程实践和模型部署的大部分关键知识点。2. 汽车产业 AI 应用的核心技术拆解2.1 RAG 为什么是业务落地的第一站RAGRetrieval-Augmented Generation检索增强生成是目前大模型进入企业业务系统最稳妥的路径。原因是企业真正有价值的知识往往不在通用大模型的训练数据里而是散落在维修手册、设计文档、历史工单、实验报告中。如果不做 RAG直接让大模型凭训练知识回答很容易出现“一本正经地胡说八道”。做了 RAG 之后系统会先从知识库里检索出和用户问题最相关的片段再把片段拼到 Prompt 中让大模型基于这些片段回答。这里要理解一个关键点RAG 并不是把整个知识库发给模型而是“先检索、后生成”。检索质量直接决定了回答质量。很多人以为 Prompt 写得越长效果越好其实当相关片段被淹没在大量噪声中时模型反而更容易答偏。2.2 AI Agent 与 Function Calling 的作用光有 RAG 还不够。有些业务问题无法通过知识库检索解决而是需要调用已有系统。比如用户问“帮我查一下 P0073 故障码”这个故障码的解释可能存在售后系统中而不是维修手册里。这时候就需要让大模型具备“工具调用”能力。在 OpenAI 兼容接口中这个能力通常叫 Function Calling 或 Tool Calling。大模型负责理解用户意图把问题转换成结构化的函数参数然后由业务系统去执行真实查询最后再把查询结果交给大模型组织成自然语言回复。在 AI Agent 架构里这只是一个很小的循环模型决定调用什么工具系统执行工具模型拿到工具结果后继续回答。真实项目中 Agent 可能会包含多轮工具调用、状态记忆、人工审批节点但底层机制是一样的。2.3 为什么仍然需要人机协同无论是 RAG 还是 Function Calling本质都是“降低人获取信息的成本”而不是“替代人的责任”。汽车维修涉及安全、保修、责任认定完全由模型自动输出处理建议并直接执行风险非常高。因此工程上要设计人工审核节点。模型可以生成维修建议、整理工单摘要、推荐检查步骤但最终是否执行、是否下单、是否通知客户必须由有资质的人员确认。这也是为什么我说大模型不应该成为“内卷工具”如果把它用于压减人工审核环节短期看省了人力长期看可能把风险成倍放大。3. 环境准备与模型选型3.1 运行环境本文示例代码使用 Python 编写这样能最直观地展示 embedding、检索、Function Calling 的完整链路。你本地需要准备Python 3.10 或更高版本。一个可用的国产大模型 API Key推荐阿里云百炼 DashScope或者 DeepSeek 开放平台。一个支持 OpenAI 兼容协议的 SDK本文使用openaiPython SDK。FastAPI 与 Uvicorn 用于暴露 HTTP 接口。如果你更习惯 Java 技术栈后文也会给出 Spring AI 接入国产大模型的配置参考但完整示例以 Python 为主。版本方面不同框架迭代很快不建议照抄过旧或过新的版本号。建议安装以下库的最新稳定版pip install openai fastapi uvicorn[standard] python-dotenv numpy如果你的网络环境下载缓慢可以临时切换为镜像源但要注意镜像源的同步时间。3.2 模型服务选择国产大模型 API 普遍提供两个关键能力文本生成和文本向量化。本文在示例中选择 DashScope 的 OpenAI 兼容模式对话模型qwen-plus适合日常问答与工具调用。向量模型text-embedding-v3用于把维修手册切分后的片段向量化。如果你使用 DeepSeek通常只需要修改LLM_BASE_URL为 DeepSeek 的接口地址并把CHAT_MODEL换成 DeepSeek 的模型名。但要注意不同平台的向量模型能力不一样如果你的平台没有提供 embedding 接口可以继续使用 DashScope 或其他兼容平台做向量化也可以在后续工程化阶段替换为本地部署的 BGE 系列模型。下面是.env环境变量文件的示例LLM_API_KEYsk-你的密钥 LLM_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 CHAT_MODELqwen-plus EMBEDDING_MODELtext-embedding-v3需要注意密钥不要提交到 Git 仓库。生产环境建议使用密钥管理服务或 CI/CD 的 Secret 变量。3.3 项目结构创建一个干净的实验目录完整结构如下car_rag_demo/ ├── .env ├── requirements.txt ├── manual.txt └── app.py其中manual.txt是模拟的维修手册app.py是完整的 FastAPI 应用和 RAG 逻辑。下面我们一步步实现。4. 完整实战基于国产大模型构建汽车售后知识助手4.1 需求分析与流程设计这个知识助手需要服务两类问题。第一类是“知识查询”例如“空调不制冷应该先检查什么”。系统先从维修手册知识库中检索相关段落再把段落发送给大模型让模型基于资料回答。第二类是“工具查询”例如“帮我查一下 P0073 故障码”。系统需要识别用户意图调用query_fault_code函数然后再把查询结果整理成回答。完整业务流程可以拆成四步用户输入问题。系统对问题做向量化并在本地索引中检索 top_k 条相关知识片段。把知识片段、工具定义、用户问题一起发送给大模型。如果大模型返回工具调用指令则执行本地函数并把结果回传给大模型否则直接返回回答。之所以先检索再发送是为了控制 Token 消耗也为了让模型聚焦于与当前问题最相关的信息。4.2 准备维修手册数据我们先准备模拟的维修手册数据。为了演示简单这里只放两份文档。# 车内空调无法制冷排查手册 适用车型示例车型 X5 EV 故障现象出风口风量正常但制冷效果差。 排查步骤 1. 检查空调压缩机是否启动。 2. 检查制冷剂压力静态压力低时补充制冷剂。 3. 检查冷凝器表面是否堵塞。 4. 使用诊断仪读取空调控制模块故障码。 # 制动异响排查手册 适用车型示例车型 X5 EV 故障现象低速轻踩制动时有尖锐异响。 排查步骤 1. 检查刹车片厚度。 2. 检查刹车盘表面是否有沟槽。 3. 检查制动卡钳回位是否正常。 4. 若刹车片磨损到极限需要更换刹车片。实际项目中这些内容应该来自企业文档系统、售后知识库或技术通报。数据导入前最好做清洗去除重复章节、把扫描 PDF 转成文本、统一术语表述。如果知识库文件特别多需要先做任务拆分例如按车型、按系统、按故障类型建立独立索引。4.3 编写向量检索模块下面开始写核心代码。新建app.py先把依赖加载进去import json import os from pathlib import Path import numpy as np from dotenv import load_dotenv from fastapi import FastAPI from openai import OpenAI from pydantic import BaseModel load_dotenv() API_KEY os.getenv(LLM_API_KEY) BASE_URL os.getenv(LLM_BASE_URL, https://dashscope.aliyuncs.com/compatible-mode/v1) CHAT_MODEL os.getenv(CHAT_MODEL, qwen-plus) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-v3) if not API_KEY: raise RuntimeError(请在 .env 文件中配置 LLM_API_KEY) client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) app FastAPI(title汽车售后知识助手)接下来定义知识库类。这个类负责读取文档、切分文本、调用向量模型构建索引并提供相似度检索方法。class KnowledgeBase: def __init__(self, doc_path: str, chunk_size: int 300, overlap: int 30): self.doc_path Path(doc_path) self.chunk_size chunk_size self.overlap overlap self.chunks [] self.vectors np.array([]) def load_and_split(self): raw_text self.doc_path.read_text(encodingutf-8) sections [s.strip() for s in raw_text.split(\n\n) if s.strip()] chunks [] for section in sections: if len(section) self.chunk_size: chunks.append(section) else: start 0 while start len(section): end start self.chunk_size chunks.append(section[start:end]) start end - self.overlap self.chunks chunks def build_index(self): if not self.chunks: raise RuntimeError(请先调用 load_and_split) vectors [] batch_size 10 for i in range(0, len(self.chunks), batch_size): batch self.chunks[i:i batch_size] resp client.embeddings.create( modelEMBEDDING_MODEL, inputbatch ) vectors.extend([item.embedding for item in resp.data]) self.vectors np.array(vectors, dtypefloat32) def search(self, query: str, top_k: int 2): if self.vectors.size 0: raise RuntimeError(请先调用 build_index) resp client.embeddings.create( modelEMBEDDING_MODEL, input[query] ) query_vec np.array(resp.data[0].embedding, dtypefloat32) def _cosine(a, b): return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-8)) scores [_cosine(query_vec, vec) for vec in self.vectors] top_idx np.argsort(scores)[-top_k:][::-1] return [{text: self.chunks[i], score: scores[i]} for i in top_idx]这里需要解释几个细节。第一文档按段落切分而不是按空格切分这样能保留语义完整性。chunk_size表示最大字符数overlap是相邻片段的重叠长度。重叠字符可以避免一个完整句子被切断后丢失上下文。第二向量化时把多个文本片段组成 batch 发送可以减少网络请求次数提升索引构建速度。这里 batch 大小取 10真实项目中要根据 embedding 服务限制调整通常可以在 16 到 64 之间。第三相似度计算使用余弦相似度。对 embedding 向量先做归一化在工业实现中可以直接用内积代替余弦相似度速度会更快。但为了可读性这里保留完整计算过程。4.4 实现故障码工具调用接着定义模拟的故障码数据库和查询函数。真实项目中这个函数会去调用 DMS 售后系统、诊断仪数据平台或配件目录服务。FAULT_CODE_DB { P0073: { name: 环境温度传感器电路高, advice: 检查环境温度传感器及线束连接必要时更换传感器。, }, C0501: { name: 空调压缩机控制电路故障, advice: 检查压缩机继电器、保险丝与线束重新上电后再次读取故障码。, }, } def query_fault_code(fault_code: str) - str: fault_code fault_code.strip().upper() if fault_code not in FAULT_CODE_DB: return f暂未收录故障码 {fault_code}请转人工查询。 item FAULT_CODE_DB[fault_code] return f故障码{fault_code}含义{item[name]}建议{item[advice]}接下来定义 Function Calling 需要的工具描述。这个描述会被发送给大模型大模型根据用户问题决定是否调用TOOLS [ { type: function, function: { name: query_fault_code, description: 查询车辆故障码的含义与维修建议, parameters: { type: object, properties: { fault_code: { type: string, description: 整车故障码例如 P0073 } }, required: [fault_code] } } } ]工具描述必须足够清晰尤其是description和参数描述。很多模型不触发 Function Calling并不是模型不行而是函数名和参数含义写得模糊。例如“含义与维修建议”比“查询”更能帮助模型判断什么时候调用。4.5 编写对话处理逻辑接下来实现核心对话逻辑。这一段负责拼接 Prompt、调用大模型、处理 Function Calling 中间结果。def ask(question: str): docs kb.search(question, top_k2) context \n\n.join( f[来源{i 1}]\n{d[text]} for i, d in enumerate(docs) ) messages [ { role: system, content: ( 你是一名汽车售后技术支持助手。 请优先根据维修手册资料回答不要编造资料中没有的信息。 如果问题涉及故障码请调用 query_fault_code 获取结果。 如果资料不足请明确回复资料未覆盖请转人工处理。 f\n\n 维修手册检索结果 \n{context} ) }, { role: user, content: question } ] response client.chat.completions.create( modelCHAT_MODEL, messagesmessages, toolsTOOLS, temperature0.2, ) message response.choices[0].message if message.tool_calls: messages.append({ role: assistant, content: message.content, tool_calls: [ { id: tool_call.id, type: function, function: { name: tool_call.function.name, arguments: tool_call.function.arguments, }, } for tool_call in message.tool_calls ], }) for tool_call in message.tool_calls: tool_name tool_call.function.name args json.loads(tool_call.function.arguments or {}) if tool_name query_fault_code: tool_result query_fault_code(args.get(fault_code, )) else: tool_result f未知工具{tool_name} messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result, }) response client.chat.completions.create( modelCHAT_MODEL, messagesmessages, temperature0.2, ) message response.choices[0].message return { answer: message.content, references: [d[text] for d in docs], meta: { chat_model: CHAT_MODEL, embedding_model: EMBEDDING_MODEL, top_k: len(docs), }, }这段代码有几个容易出错的地方。第一如果有 Tool Call必须先把 assistant 的角色消息追加到 messages再追加 tool 消息。否则 API 会报错因为 tool 消息必须对应一个已经存在的 assistant Tool Call。第二tool_call.function.arguments是 JSON 字符串需要先解析成字典。解析失败时要做好异常处理实测中偶尔会出现参数格式不规范的情况。第三第二轮调用时不需要再带tools也可以。但为了保险建议继续携带tools这样模型如果还需要查其他故障码依然可以继续调用。在实际项目里应该用循环限制最多调用 2 到 3 次避免 Agent 陷入死循环。4.6 封装 FastAPI 接口最后加上两个 Pydantic 模型和 HTTP 路由。class ChatRequestBody(BaseModel): question: str class ChatResponseBody(BaseModel): answer: str references: list[str] [] meta: dict {} app.post(/chat, response_modelChatResponseBody) def chat(req: ChatRequestBody): if not req.question.strip(): return ChatResponseBody(answer问题不能为空) result ask(req.question) return ChatResponseBody( answerresult[answer], referencesresult[references], metaresult[meta], ) kb KnowledgeBase(manual.txt) kb.load_and_split() kb.build_index()这里把索引初始化放在了模块加载阶段简单直接适合演示。但在生产环境中最好把知识库索引放在独立服务中例如 FAISS、Milvus 或 PgVector并通过监听文档更新事件触发重新索引。4.7 运行与验证在项目目录下创建.env文件然后启动服务uvicorn app:app --reload --host 0.0.0.0 --port 8000启动成功后可以先测试知识问答curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {question: 空调不制冷应该先检查什么}预期回答会引用检索到的手册片段内容大致是先检查空调压缩机是否启动再检查制冷剂压力等。接着测试故障码查询curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {question: 帮我查一下 P0073 故障码}如果 Function Calling 链路正常模型会先调用query_fault_code(P0073)然后根据返回结果生成一段自然语言回答。返回的references字段里可能没有与故障码相关的知识片段这是正常的因为故障码数据来自工具调用而不是维修手册。5. 从 Demo 到可上线模型部署与工程化建议5.1 从 API 调用到私有化部署Demo 阶段使用云厂商大模型 API 很合适方便快速验证效果。但很多车企对数据安全要求较高不愿意把维修手册、车辆 VIN、故障数据发送到外部 API这时候就需要私有化部署开源模型。以 Qwen2.5 系列开源模型为例常见的推理部署方案是 vLLM。它支持高并发推理并提供 OpenAI 兼容的/v1/chat/completions接口。假设你有一台带 GPU 的 Linux 服务器可以先安装 vLLM然后执行vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen2.5-7b-instruct启动后调用方只需要修改LLM_BASE_URL为http://your-server:8000/v1CHAT_MODEL改为qwen2.5-7b-instruct代码无需大改即可切换。这也是早期选择“OpenAI 兼容协议”的好处。embedding 模型同样可以本地化部署。比如部署本地 BGE-M3 服务再将EMBEDDING_MODEL和调用地址指到本地服务从而实现全链路数据不出内网。5.2 Java Spring AI 接入方式参考如果团队技术栈是 Java 后端可以考虑使用 Spring AI。它是一个将 AI 模型能力抽象成 Spring Boot Starter 的框架可以让我们用比较熟悉的配置方式接入 OpenAI 兼容接口。下面给出参考配置spring.ai.openai.api-key${DASHSCOPE_API_KEY} spring.ai.openai.base-urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 spring.ai.openai.chat.options.modelqwen-plus注意Spring AI 版本迭代比较快不同版本的配置前缀和ChatClientAPI 可能存在差异。建议以当前使用的 Spring AI 官方文档为准。代码层面可以封装一个 ControllerRestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); } }这个例子只覆盖最基本的对话功能。要在 Java 服务里实现 RAG 和 Function Calling还需要把向量化、向量检索、工具函数等逻辑整合进去。工程上建议先通过 Python 快速验证效果再在 Java 侧做正式重构不要一上来就在 Java 里堆代码。5.3 评测、监控与降级上线前最容易被忽略的是评测。没有评测集就没有办法回答“这次换 Prompt 后效果是变好还是变坏”。可以整理 100 到 500 条真实售后问题分成几类可以在维修手册中找到答案的问题。需要调用故障码工具的问题。知识库覆盖不到、应该拒绝回答的问题。需要多轮上下文才能回答的问题。然后对每个问题预先写好标准答案和关键检查点形成回归评测集。每次修改 Prompt、调整检索参数、更换模型后都跑一遍评测集。重点看三个指标答案准确率、引用覆盖率、拒答准确率。答案准确率衡量回答内容是否与标准答案一致引用覆盖率衡量模型是否正确使用了检索到的资料拒答准确率衡量模型能否在资料不足时主动说“不知道”。生产链路还必须加监控和降级。如果大模型 API 超时或者向量数据库不可用接口不应该直接报错而应该降级为“搜索模式”只返回检索到的知识片段或者提示用户稍后重试。每次请求的模型、Prompt 版本、知识库版本、Token 消耗、响应延迟、人工修改结果都应该记录到日志或数据库中否则后续很难排查线上问题。6. 常见问题与排查思路问题现象常见原因解决思路调用 API 返回 401API Key 错误或没有对应模型权限检查.env中的密钥、服务所在区域、模型是否开通返回内容与知识库无关RAG 检索结果不相关或 Prompt 约束不足提高 top_k检查文档切分质量降低温度参数模型回答编造资料外内容Prompt 没有明确拒绝或知识库检索为空在 System Prompt 中要求“资料未覆盖必须转人工”并设置兜底逻辑Function Calling 不触发工具描述不清晰或模型不支持该格式精简函数描述增加示例参数尝试换更强模型报错 tool 消息没有对应 assistant未把 assistant Tool Call 记录追加到 messages在追加 tool 消息前先追加包含 tool_calls 的 assistant 消息embedding 模型不能调用当前平台没有提供向量模型改用 DashScope text-embedding-v3或本地部署 BGE 系列模型知识库更新后回答仍是旧内容索引没有重建建立文档变更监听触发重新切分、重新 embedding 并更新索引检索结果返回空文档切分后为空或 embedding 维度不一致检查知识库文件编码建议统一为 UTF-8Spring AI 配置不生效版本不同导致配置前缀变化检查依赖版本以官方文档对应章节为准接口响应太慢向量检索全量扫描或模型推理耗时长生产环境使用向量数据库对模型推理做缓存和超时控制这里的核心思路是先区分问题出在检索链路、模型链路还是系统链路。检索链路问题看召回内容模型链路问题看 Prompt 和模型参数系统链路问题看日志、超时和熔断配置。7. 最佳实践让 AI 成为“助手”而非“内卷工具”7.1 以业务指标作为验收标准在汽车产业做大模型应用不应该用“上线了多少 AI 功能”来验收而应该用“每张工单平均查询时间下降了多少”“首次修复率是否提升”“技师培训周期是否缩短”来衡量。如果某个 AI 功能上线后只是让系统多了一个聊天框但业务人员根本不用那它本质上就是内卷。反过来如果系统能让新技师在遇到陌生故障时少花一半时间找到维修资料这个 AI 应用就有明确价值。所以在做任何一个方向之前先问一个问题这个功能让谁的工作更简单了7.2 权限、安全与数据合规汽车行业涉及的数据敏感度高车型配置、维修记录、客户信息、供应链信息都不能随意输入外部大模型。建议遵循最小权限原则普通账号只能查询与自己工作相关的知识库。涉及客户隐私数据的字段在进入大模型之前先脱敏。系统日志中不记录完整 Prompt 和完整回复只记录关键统计信息。私有化部署时做好模型服务的网络隔离和账号审计。外部 API 调用前由安全团队审核数据流向。如果未来要让 AI 自动写维修工单或自动下单必须增加人工审批节点。AI 可以起草内容但“确认”这个动作必须由人完成。7.3 长期维护与 Prompt 版本管理很多团队把 Prompt 当成“写一次就永久有效”的配置这是错误想法。业务知识在变、模型版本在变、用户提问方式在变Prompt 和知识库都需要持续维护。工程上可以这样管理每一个 Prompt 都有一个版本号例如aftersale_qa_v23。每次修改 Prompt 都要在评测集上跑一遍记录效果变化。知识库文档更新时记录来源、更新时间、负责人。线上调用时在日志中记录 Prompt 版本方便问题回溯。大模型 API 升级模型版本前先在预发环境跑评测集再决定是否切换。这听起来像传统软件的版本管理但确实是大模型应用稳定运行的关键。不要相信“Prompt 看起来差不多所以不用测试”很多线上效果下降都是因为检索到的知识片段变了而不是模型变笨了。7.4 落地节奏建议如果今天要启动一个汽车产业大模型项目我建议按这样的节奏推进第一步选一个明确的小场景例如“售后故障码查询辅助”不要一上来就做全公司知识中台。第二步用本文示例快速跑通完整链路确认 API、模型、向量检索都可行。第三步整理 50 条真实问题设计简单的评测集记录当前效果基线。第四步逐步接入真实知识库和业务系统每接入一个数据源就重新跑评测。第五步设计人工审核和反馈收集机制让一线人员可以在页面上标记“回答有用”或“回答错误”。当积累了一定量的真实反馈后你会发现系统改进方向不再是“换更大的模型”而是“把知识库组织得更好把工具调用设计得更稳把人机协作流程打磨得更顺”。这才是国产大模型在汽车产业里更有意义的路径不是造一个内卷工具而是造一个能放大一线工程师、技师和客服人员能力的助手。如果你正在做类似的大模型应用开发希望这篇文章能帮你少走弯路。代码只是一个起点真正有价值的是你对业务场景的理解、对评测体系的坚持以及对“人机协同边界”的清醒认识。