企业官网建设流程全解析

最近和汽车行业的朋友交流时，总绕不开一个问题：国产大模型迭代这么快，是不是又要让车企和供应商更“卷”？我的观点其实很明确：大模型即使发展再快，也不应该被简单当作“压成本、拼话术、堆演示”的内卷工具。真正的价值，是把过去依赖老师傅经验、需要反复翻手册、跨系统查询才能完成的业务，改造成“人机协同”的新工作流。

这篇文章不聊宏大叙事，而是从工程视角出发，用一套可复现的汽车售后知识助手示例，把国产大模型接入业务系统的完整链路拆开：模型选型、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 为什么是业务落地的第一站

RAG（Retrieval-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_KEY=sk-你的密钥 LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 CHAT_MODEL=qwen-plus EMBEDDING_MODEL=text-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函数，然后再把查询结果整理成回答。

完整业务流程可以拆成四步：

1. 用户输入问题。
2. 系统对问题做向量化，并在本地索引中检索 top_k 条相关知识片段。
3. 把知识片段、工具定义、用户问题一起发送给大模型。
4. 如果大模型返回工具调用指令，则执行本地函数，并把结果回传给大模型；否则直接返回回答。

之所以先检索再发送，是为了控制 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_key=API_KEY, base_url=BASE_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(encoding="utf-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( model=EMBEDDING_MODEL, input=batch ) vectors.extend([item.embedding for item in resp.data]) self.vectors = np.array(vectors, dtype="float32") def search(self, query: str, top_k: int = 2): if self.vectors.size == 0: raise RuntimeError("请先调用 build_index") resp = client.embeddings.create( model=EMBEDDING_MODEL, input=[query] ) query_vec = np.array(resp.data[0].embedding, dtype="float32") 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_k=2) 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( model=CHAT_MODEL, messages=messages, tools=TOOLS, temperature=0.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( model=CHAT_MODEL, messages=messages, temperature=0.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_model=ChatResponseBody) def chat(req: ChatRequestBody): if not req.question.strip(): return ChatResponseBody(answer="问题不能为空") result = ask(req.question) return ChatResponseBody( answer=result["answer"], references=result["references"], meta=result["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/v1，CHAT_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-url=https://dashscope.aliyuncs.com/compatible-mode/v1 spring.ai.openai.chat.options.model=qwen-plus

注意，Spring AI 版本迭代比较快，不同版本的配置前缀和ChatClientAPI 可能存在差异。建议以当前使用的 Spring AI 官方文档为准。代码层面可以封装一个 Controller：

@RestController 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. 常见问题与排查思路

这里的核心思路是：先区分问题出在检索链路、模型链路还是系统链路。检索链路问题看召回内容；模型链路问题看 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 条真实问题，设计简单的评测集，记录当前效果基线。第四步，逐步接入真实知识库和业务系统，每接入一个数据源就重新跑评测。第五步，设计人工审核和反馈收集机制，让一线人员可以在页面上标记“回答有用”或“回答错误”。

当积累了一定量的真实反馈后，你会发现系统改进方向不再是“换更大的模型”，而是“把知识库组织得更好，把工具调用设计得更稳，把人机协作流程打磨得更顺”。这才是国产大模型在汽车产业里更有意义的路径：不是造一个内卷工具，而是造一个能放大一线工程师、技师和客服人员能力的助手。

如果你正在做类似的大模型应用开发，希望这篇文章能帮你少走弯路。代码只是一个起点，真正有价值的是你对业务场景的理解、对评测体系的坚持，以及对“人机协同边界”的清醒认识。