企业官网建设流程全解析

过去一年，国产AI大模型进入密集发布期，从“百模大战”到行业落地，几乎每周都有新模型、新应用刷屏。作为技术人员，我们确实看到了差距在缩小、能力在提升；但放到汽车产业这个场景里看，我会产生一种明显的分裂感。一边是发布会上“AI赋能智能座舱”“大模型提升研发效率”的宏大叙事，另一边是很多开发团队每天都在做的重复劳动：调提示词、做Demo、追新模型、改短视频脚本，甚至只是为了给老板做一场“看起来AI了”的汇报。

国产AI跑得快，本质上靠的是算力、数据、算法和工程能力的综合进步。它应该成为汽车研发、制造、销售、售后全链路的生产力底座，而不应该只沦为车企之间互相内卷的话术工具，更不应该变成“为了AI而AI”的面子工程。这篇文章不打算追发布会热点，而是从AI工程实践的角度展开聊一聊：在汽车产业里，真正有价值的AI落地长什么样，团队该怎么选模型、怎么搭知识库、怎么做Agent，以及如何避开“内卷式AI”的坑。无论你是后端开发、算法工程师，还是汽车软件团队的技术负责人，这篇文章都会给你一套可以落地的思路和参考代码。

1. 国产AI狂飙背后：汽车产业需要怎样的“非内卷”落地

1.1 算力、模型和产业需求都在快速变化

国产AI最近几年的进步是肉眼可见的。从基础大模型的参数规模、中英文能力、代码能力，到推理成本、私有化部署生态，都在快速追赶国际主流水平。尤其在中文场景、行业数据和合规部署方面，国产模型有自己的优势。汽车产业作为制造业里数字化程度最高的行业之一，自然成为大模型落地的重点试验场。

我们可以把汽车行业里的AI应用粗略分成两类：

• 面向C端用户的智能化体验，比如智能座舱语音助手、虚拟形象、用车顾问。
• 面向B端和内部效率的AI能力，比如研发辅助、产品文档生成、售后知识库问答、质量缺陷分析、供应链数据抽取等。

前者的曝光度高，容易出现在发布会PPT上；后者才是真正决定企业运营效率和研发质量的部分。但现实是，很多团队把大部分精力都投入到了前者，PPT做得很漂亮，实际业务价值却很有限。这种现象本质上就是“内卷”：大家都在同一个低水平维度上比谁的话术更花哨、谁的演示视频更流畅，却没有多少人去解决“这条产线的不良品报告能不能自动生成”“这份维修手册能不能让新手技师3秒找到答案”这些真实问题。

1.2 内卷式AI的典型特征

结合我自己在行业里观察到的现象，内卷式AI通常有以下特征：

• 重演示、轻数据：把模型接到几个公开样例上跑通就宣布落地，完全没有考虑业务数据的质量和规模。
• 重对话、轻场景：什么都做成聊天框，用户不知道输入什么，系统也不知道该输出什么。
• 重接入、轻评测：模型API接了一大堆，却没有一套属于自己的评测集来判断“回答对不对”。
• 重短期宣传、轻长期维护：上线后不管数据更新、不做badcase回流、不跟踪线上效果。

这类项目做完之后，通常的结果就是：上线时热闹一阵，一个月后活跃量骤降，最后被归入“AI试验阶段”。原因不是国产模型不够好，而是落地方式出了问题。

1.3 工程化AI才是行业真正的分水岭

汽车产业的特点是链条极长、知识密度高、容错率低。一辆车从概念设计到量产交付，再到售后维保，涉及的文档、图纸、标准、故障码、维修案例不计其数。大模型在这种场景里的价值，不在于生成一份通顺的文案，而在于把非结构化的行业知识变成可检索、可推理、可辅助决策的结构化能力。

这才是国产AI在汽车产业里的正确打开方式：

• AI应该是研发的知识助手，而不是替代工程师做决定。
• AI应该是售后服务的加速器，而不是给车主制造新困扰。
• AI应该是质量数据的分析器，而不是替管理者制造“数字化繁荣”的假象。

要做到这些，单纯靠一个通用大模型是不够的。我们需要理解RAG（检索增强生成）、Agent（智能体）、模型微调、部署和评测这些工程概念，并且知道它们在什么场景下该用什么。下面我们从工程视角出发，逐一拆解。

2. 汽车行业AI应用形态：从对话、RAG到Agent

2.1 不要把“会聊天”当成会干活

很多团队拿到大模型后的第一个动作是把接口接进IM工具，让员工“有问题直接问AI”。这个想法没有错，但它解决的是最表层的需求。如果企业内部的知识库没有结构化、没有权限管理、没有实时更新，AI就只能基于训练时的记忆回答，结果必然是幻觉多、答案旧、不敢信。

在汽车行业，一个维修技师问“2023款某车型的ESP故障码C0031常见原因有哪些”，肯定希望得到来自维修手册和真实案例的精确回答，而不是模型凭空生成的通用解释。这里就需要引入RAG：先根据用户问题检索企业知识库，把相关的技术文档片段拼进上下文，再让大模型基于这些材料生成答案。

2.2 RAG适合哪些场景

RAG在汽车行业的典型场景非常集中：

• 售后维修知识库问答：维修手册、故障码表、技术通报、历史工单。
• 产品规格查询：配置参数、保养周期、零件适配关系。
• 研发文档助手：设计规范、试验标准、历史问题库。
• 质量报告分析：不良现象聚类、排查建议生成。

RAG的核心价值是可以让模型“知道”企业私有数据，同时不暴露原始数据。模型不需要记住你的维修手册，只需要在回答时临时检索相关片段即可。这种方式天然适合知识频繁更新的场景——数据变了，更新向量库就行，不需要重新训练模型。

2.3 Agent在多步任务中发挥作用

如果说RAG解决的是“单轮知识检索与问答”，那Agent解决的就是“多步骤、多工具配合”的问题。

汽车行业里很多问题不是一句检索能回答的。比如用户问“我的车保养提示还有500公里，最近刹车有点软，应该先做什么检查？”这时候，系统可能需要：

• 先判断用户意图是保养咨询还是故障咨询；
• 保养部分去查保养周期数据；
• 故障部分去检索维修手册；
• 综合两块信息后再生成建议话术；
• 最后判断是否需要推荐用户去门店做检测。

这个流程里需要用到大模型做意图识别、路由决策和答案生成，还需要配合结构化数据查询、文档检索、门店信息查询等多个工具。把大模型编排起来去调用工具、决定下一步动作，就是Agent的典型形态。

从技术分层来看，一个成熟的汽车行业AI应用通常可以拆解成六层：

很多团队一上来就追求Agent化，结果工具不稳定、召回效果差、又没有业务反馈日志，最后整个链路崩溃。正确的路径应该是：先从一个具体场景的单点问答开始跑通RAG，再逐步增加Agent能力。

3. 环境准备与模型选型：先别急着追参数

3.1 环境准备

为了便于后续示例演示，本文默认的技术栈如下：

• 操作系统：Linux（Ubuntu 20.04或22.04）或macOS均可；
• 开发语言：Python 3.10+；
• Web框架：FastAPI；
• 向量数据库：本示例使用FAISS和简单的持久化方式，生产环境可替换为Milvus、Elasticsearch或云上向量库；
• 大模型：采用支持OpenAI兼容接口的本地或云端模型服务，例如国产主流开源模型部署后的兼容接口，或商用API；
• 基础依赖：requests、openai（兼容接口时）、numpy、fastapi、uvicorn、pypdf。

需要说明的是，大模型版本和接口规格变化很快，上面只是推荐的基础环境，具体版本请以你项目的实际情况为准。本文的重点是整套链路的设计思路，代码可以直接参考，但部署参数需要按实际环境调整。

3.2 模型选型的核心考虑因素

汽车行业选AI模型时，不能只看评测榜单。你需要考虑以下四个维度：

• 最近有没有案例可以说明领域性能：也就是说，这个模型在中文技术文档理解、汽车术语识别、故障代码处理方面表现怎么样。
• 部署方式是否满足合规要求：数据能不能出企业内网，是否需要私有化部署。很多车企对数据出境和第三方访问要求很严，因此私有化部署的优先级很高。
• 推理成本与响应速度的平衡：本地部署可以用小参数模型降低成本，但回答质量可能下降。云端API质量高，但网络延迟和费用不可控。你需要根据业务访问量做压测。
• 是否方便接入企业工具：很多模型服务提供兼容OpenAI的接口，对开发者非常友好，可以直接复用现有SDK。如果模型只提供自有SDK，在Agent编排时就要考虑兼容性。

3.3 微调还是RAG

这是每场技术评审都会被问到的问题。我的建议非常简单：

• 如果问题是“模型不知道我企业内部的知识”，优先做RAG；
• 如果问题是“模型不按我的格式输出、不会念特定术语、总是漏掉约束条件”，再考虑微调；
• 不要因为老板要求“我们也要微调”，就去微调。

RAG的优点是成本低、见效快、可解释性强、知识可以随时更新。微调的优点是能把特定领域的表达习惯和复杂规则固化到模型参数里，但它的成本和维护代价很高，而且在汽车这种知识频繁更新的场景里，每次资料更新都重新微调并不现实。

比较稳妥的组合方式是：用RAG解决企业知识问答，用提示词工程解决输出格式，只有当模型在大量badcase上出现系统性风格错误时，才用少量高质量语料做微调。

4. 完整实战案例：售后技术服务知识库问答Agent

下面我们用一个售后技术服务问答场景来演示完整链路。假设一家主机厂有大量车辆维修手册、技术通报和售后案例，现在希望做一个智能问答助手，让一线客服和技术人员能快速查到准确的维修建议。系统整体分三部分：

1. 数据准备：把PDF、Word文档解析、分块、向量化后写入向量索引。
2. 答案生成：根据用户问题先做意图判断，再决定走文档检索还是结构化工具查询。
3. API服务：通过FastAPI暴露接口，供内部系统或IM机器人调用。

4.1 项目结构规划

建议先规划好项目目录，方便后续扩展：

car_agent/ ├── app.py # FastAPI入口 ├── agent.py # Agent编排逻辑 ├── intent.py # 意图识别模块 ├── config.py # 配置信息 ├── data/ │ └── raw_docs/ # 原始PDF和Word文档 ├── indexer.py # 文档解析与向量化 ├── index/ │ └── faiss_index # 向量索引文件 └── requirements.txt

如果团队项目比较小，可以省去Agent框架，直接用函数编排流程。对于汽车行业这种需要权限管控和日志审计的场景，轻量实现反而更容易维护。

4.2 文档解析与分块

汽车维修手册动辄几百页，包含大量表格、故障码和操作步骤。如果直接把整本文档丢给模型，既超出上下文窗口，也不能让召回结果精准定位到某个故障点。所以必须做文档切分。

常见的切分策略有三种：

• 固定长度切分：简单粗暴，按字符数切分，适合纯文本。缺点是会把一个段落从中间切断。
• 结构切分：利用文档标题层级来分组，适合目录结构清晰的PDF。你可以用Python库从PDF中提取文本并识别标题。
• 语义切分：按照段落含义进行切分，效果最好，实现成本也高。通常需要先用规则把章节和段落分开，再判断语义边界。

建议先从“按章节标题切分+按段落进一步切分”开始。下面是一个参考示例：

# 文件路径：indexer.py import os from pathlib import Path def read_pdf_text(file_path: str) -> str: """读取PDF并提取文本，真实项目中需要处理表格和扫描件。""" from pypdf import PdfReader reader = PdfReader(file_path) content = [] for page in reader.pages: text = page.extract_text() if text: content.append(text) return "\n".join(content) def split_document(document: str, chunk_size: int = 800, overlap: int = 100) -> list[str]: """ 简单按字符长度切分文本。 注意：chunk_size 需要根据你的文档类型和模型能力测试，通常 300-1000 字是常见区间。 """ chunks = [] start = 0 while start < len(document): end = start + chunk_size chunk = document[start:end] if start > 0: chunk = document[start - overlap:end] chunks.append({"text": chunk, "source": "manual"}) start += chunk_size return chunks if __name__ == "__main__": pdf_content = read_pdf_text("data/raw_docs/2023_vehicle_repair_manual.pdf") result = split_document(pdf_content) print(f"生成文本块数量: {len(result)}") for item in result[:2]: print(item["text"][:200])

这个示例做了最简单的切分，但实际项目中你应该在切分时保留元数据，比如文档标题、章节编号、车型、年份、页码，甚至故障码范围。这些元数据在回答时可以帮助溯源，也能让系统在回答后附上“来源：2023维修手册 第3章 ABS故障排查”这样的引用信息。

4.3 构建向量索引与检索

切分完成后，需要把文本块向量化并存入向量索引。向量化这一步可以调用本地部署的Embedding模型，也可以用云API服务。下面用伪代码示意核心流程，具体模型接口按你使用的服务调整：

# 文件路径：indexer.py（续） import openai import numpy as np import faiss # 通过环境变量或配置文件读取接口地址 # openai.api_base = "http://your-model-service:8000/v1" # openai.api_key = "your-key" client = openai.OpenAI( base_url="http://your-model-service:8000/v1", api_key="not-needed", ) def get_embedding(text: str) -> list[float]: resp = client.embeddings.create( model="your-embedding-model", input=text, ) return resp.data[0].embedding def build_faiss_index(all_chunks: list[dict], save_path: str = "index/faiss_index"): vectors = [] for chunk in all_chunks: vectors.append(get_embedding(chunk["text"])) index = faiss.IndexFlatIP(len(vectors[0])) index.add(np.array(vectors).astype("float32")) faiss.write_index(index, save_path) print(f"索引保存完成，共 {len(vectors)} 条文本块")

注意：这只是内存版索引，适合原型验证。生产环境中建议将原始文本块和向量索引一起管理，例如保存到Milvus或Elasticsearch中，这样能支持更复杂的过滤条件（比如按车型、按模块过滤后再检索），也能方便做权限控制。

4.4 Agent编排与意图识别

对于售后问答来说，不是所有问题都需要检索文档。比如“这款车的保养周期是多少”属于结构化信息查询，“帮我写一条客户回访短信”属于文本生成。如果所有问题都先检索文档，答案质量反而不稳定。

所以Agent里应该先加一个意图识别模块。这里有两类做法：

• 用大模型做意图分类：输入用户问题，让模型返回JSON格式的分类结果。
• 用传统文本分类模型：如果意图种类固定且数量不多，训练一个小模型成本更低。

考虑到可扩展性，下面用大模型做意图路由：

# 文件路径：intent.py import json INTENT_PROMPT = """请判断用户的售后咨询属于以下哪类意图。 意图列表： 1. maintenance_query: 保养周期、保养项目、机油标准等 2. fault_query: 故障排查、故障码、异响、报警灯等 3. parts_query: 配件适配、零件编号查询 4. chat: 非技术类闲聊或业务咨询 5. urgent_suggest: 存在安全隐患，需要引导进店检查 只输出JSON格式，不要附加解释，格式如下： {"intent": "intent_name", "reason": "判断理由", "risk_level": "low|medium|high"} """ def detect_intent(user_question: str, llm_client, model_name: str) -> dict: resp = llm_client.chat.completions.create( model=model_name, messages=[ {"role": "system", "content": INTENT_PROMPT}, {"role": "user", "content": user_question}, ], temperature=0, ) content = resp.choices[0].message.content try: result = json.loads(content) except json.JSONDecodeError: # 对于不稳定的模型输出，要做容错处理 result = {"intent": "fault_query", "reason": "解析失败，默认按故障查询处理", "risk_level": "medium"} return result

意图识别的一个关键点：在售后场景里，安全风险判断一定要有。如果用户说“刹车失灵”“仪表盘电池灯亮同时动力下降”，系统必须触发紧急引导逻辑，而不是机械地回答技术方案。这里的做法是把risk_level提升到high，然后由上层业务系统做策略分发。

核心的Agent编排逻辑写在agent.py中：

# 文件路径：agent.py from intent import detect_intent import openai client = openai.OpenAI( base_url="http://your-model-service:8000/v1", api_key="not-needed", ) MODEL_NAME = "your-llm-model" def search_documents(question: str, top_k: int = 5): """查询向量索引，省略具体实现，返回相关文本片段。""" # 这里应该调用前面构建好的向量索引 return ["维修手册片段1", "技术通报片段2"] def query_sql(question: str): """通过文本转SQL或固定模版查询结构化数据。""" # 示例：查询保养周期 result = "该车型保养周期为每10000公里或12个月" return result def answer_maintenance(question: str): context = query_sql(question) return context def answer_fault(question: str): docs = search_documents(question) prompt = f"""你是汽车售后技术支持专家，请根据【参考材料】回答用户问题。 如果参考材料中没有直接答案，请明确告诉用户需要进一步排查，不要编造诊断结论。 参考材料： {chr(10).join(docs)} 用户问题：{question} """ resp = client.chat.completions.create( model=MODEL_NAME, messages=[ {"role": "system", "content": "请基于材料客观作答，控制篇幅在200字以内。"}, {"role": "user", "content": prompt}, ], temperature=0.2, ) return resp.choices[0].message.content def run_agent(question: str) -> dict: intent_info = detect_intent(question, client, MODEL_NAME) intent = intent_info["intent"] risk_level = intent_info["risk_level"] if risk_level == "high": return { "reply": "您描述的情况可能存在安全隐患，为了安全起见，请不要继续行驶，建议立即联系就近服务店进行检测。", "need_human": True, "intent": intent, } if intent == "maintenance_query": reply = answer_maintenance(question) elif intent == "fault_query": reply = answer_fault(question) elif intent == "parts_query": reply = "该问题需要核对具体VIN码，建议提供车架号后由配件系统查询。" else: reply = "我是售后服务助手，可以为您提供保养和故障排查建议。如果需要人工服务，请转接客服。" return { "reply": reply, "need_human": False, "intent": intent, "source_docs": [], }

这里有三个细节值得注意：

• 在安全风险较高的意图下，Agent直接交给人处理，而不是强行生成答案。汽车行业容错率低，AI不适合“博概率”。
• 生成回答时的temperature设置为0.2甚至0，是为了让回答更稳定，减少发散。不要用写文案的参数去写维修建议。
• 在prompt里明确要求模型“没有材料时不要编造结论”，这是缓解幻觉非常有效的手段。

4.5 暴露API接口

为了方便接入企业IM、客服系统或内部管理后台，我们需要用FastAPI把Agent包一层HTTP接口：

# 文件路径：app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from agent import run_agent app = FastAPI(title="Car Service Agent API") class QuestionRequest(BaseModel): question: str user_id: str = "unknown" car_model: str = None class AnswerResponse(BaseModel): reply: str need_human: bool = False intent: str = "" source_docs: list = [] @app.post("/api/v1/chat", response_model=AnswerResponse) def chat(req: QuestionRequest): if not req.question or len(req.question.strip()) < 2: raise HTTPException(status_code=400, detail="问题不能为空") result = run_agent(req.question) return AnswerResponse(**result) @app.get("/health") def health(): return {"status": "ok"}

启动服务：

pip install fastapi uvicorn openai faiss-cpu pypdf uvicorn app:app --host 0.0.0.0 --port 8000

启动后用curl做一个简单验证：

curl -X POST http://localhost:8000/api/v1/chat \ -H "Content-Type: application/json" \ -d '{"question": "请问2023款星越L的发动机故障灯亮了是什么原因？"}'

预期返回结构类似：

{ "reply": "根据维修手册，发动机故障灯亮涉及的原因较多，常见包括氧传感器信号异常、点火线圈故障、燃油蒸发系统泄漏等。建议先用诊断仪读取故障码，再根据故障码定位具体方向。", "need_human": false, "intent": "fault_query", "source_docs": [] }

这里要强调，真实项目中source_docs不应该为空，而应该返回命中的文档编号和节选，方便前端做引用展示，也方便后续做结果审计。

5. 不做内卷工程：建立AI应用的评测与数据闭环

很多AI项目失败，不是因为模型不行，而是因为没有评测标准。开发阶段看起来回答都像模像样，一上生产就暴露出各种badcase：答非所问、引用错误、语气不专业、关键安全信息缺失。原因很简单：你从来不知道“正确”是什么。

5.1 构造业务评测集

无论做RAG还是Agent，第一件事不是写代码，而是构造评测集。评测集至少应该覆盖：常见问题、边界问题、易错问题、拒绝回答场景。每条测评样例标注模型应该输出的语义要点，而不是逐字逐句比对。

例如，针对售后知识助手，评测集可以包括：

• 问题：某车型高速行驶时方向盘抖动，可能的原因有哪些？
  • 预期要点：轮胎动平衡问题、轮毂变形、传动系统问题；建议先做动平衡检测。
• 问题：能建议我直接把刹车油换成更高标号吗？
  • 预期要点：不建议自行更换；应按照保养手册规定标号；更换刹车油需要专业设备和排气流程。
• 问题：ABS灯亮了，车还能开吗？
  • 预期要点：ABS故障不等于制动完全失效，但制动辅助可能受限；建议谨慎驾驶并尽快检修；如果是紧急情况，需要拖车或上门检修。
  • 安全策略：高风险意图，触发need_human。

把这些评测样例跑一遍Agent，把回答保存下来，再由业务专家进行标注和打分。这个过程虽然耗时，但可以真正暴露模型在领域内的缺陷。

5.2 Badcase回流与数据更新

项目上线后，一定要把用户真实问题和模型回答记录下来，并增加一个“评价”按钮或“反馈”通道。对于用户点了“不满意”或者客服转人工的问题，安排定期分析：是检索不到，还是生成错误？如果是检索不到，说明知识库里缺数据，需要补充资料；如果是生成错误，则需要调整Prompt、增加前置校验，甚至考虑微调。

一个数据闭环系统看起来应该是这样的：

用户问题 -> Agent执行 -> 答案返回用户 -> 用户点击有帮助/无帮助 -> Badcase进入人工标注队列 -> 标注后按类型进入知识库/Prompt/评测集更新 -> 重新执行回归评测 -> 通过后发布新版本

模型只是一台发动机，数据闭环才是方向盘和刹车。只有把数据回流机制做好，AI应用才能持续变好，而不是永远在Demo阶段打转。

5.3 可观测性设计

生产环境里，AI接口比普通接口复杂得多。一次回答可能经过多个步骤：调用Embedding、检索向量库、调用大模型、处理返回结果、做安全过滤。如果系统报错或回答质量下降，你很难定位是哪一步出了问题。因此从第一天开始就要记录关键日志：

• 用户输入原文；
• 意图识别结果；
• 检索命中的文档ID与得分；
• 最终Prompt片段；
• 大模型返回的原始内容；
• 耗时时长；
• 用户所在业务线、车型信息等标签。

这些日志既是排障依据，也是后续构造评测集的重要来源。私有化部署或调用商业API时，需要注意日志中不要记录用户敏感数据，必要时应做脱敏处理。

6. 汽车行业AI落地的高频问题与排查思路

结合前面讲的案例，下面是几个汽车行业开发者最容易遇到的问题。我这里用一张表先做总结，然后在后面展开分析：

展开说几个重要场景。

问题一：模型回答“像那么回事”但数据是错的。

这是RAG系统最常见的问题。根因通常是召回阶段没有把正确的材料找回来。排查时先打印检索命中的文档名和片段，看是不是把另一款车型的维修手册片段召回了。如果是，就需要在索引元数据中加入车型过滤条件，例如按“某车型+故障码”两个条件同时过滤后再检索。

问题二：本地部署和云端API效果差距大。

本地部署的模型参数较小，推理能力弱于商用云端大模型，这是正常现象。你需要确定自己的业务到底需要多强的推理能力。如果只是做售后文档段落总结和提取，7B~14B的量化模型在调优后也可以给出可用结果；如果要做复杂的多步骤推理和自然语言转SQL，建议直接用云端API或更大参数的私有化模型。

问题三：把AI当成了全自动回复工具，导致客户投诉。

售后场景中，AI应该定位为“辅助建议”，而不是“最终答复”。对于涉及维修方案、费用、安全类问题，需要设置人工审核或转人工机制。在产品层面，AI生成的内容要标注“由AI生成，仅供参考，请以服务店技师检测结果为准”；在权限层面，一线客服可以使用，但对外发布前需要具备审核权限的账号确认。

7. 把AI做成生产力而不是PPT：几条工程建议

7.1 先选“窄”场景，再谈“宽”平台

很多团队习惯先做一个“企业级AI中台”，然后再找应用场景。对于供应链复杂、知识体系庞大的汽车行业来说，这种做法很容易变成投入大、产出的坑。我建议反向操作：先从一条业务链路里找到最痛的窄场景，比如“售后客服处理维修手册查询耗时太长”，快速做出一个能用的RAG问答工具，验证效果和用户接受度，再逐步扩展到更多场景。

7.2 重视权限与合规

汽车行业涉及大量供应商数据、研发数据、车主个人信息。任何AI应用在进入生产前都要做权限设计：

• 员工只能查询自己业务范围内的知识；
• 涉及车主隐私的内容不能进入向量库；
• 对于模型调用厂商，需要走合规审批流程；
• 在线回答内容需要留痕，以备追溯。

7.3 性能优化核心在于检索，而不只在于生成

大模型生成一篇回复可能要几秒，但用户真实能感知的等待时间还包括网络和检索时间。优化顺序一般是：先优化检索延迟（例如减少检索过滤条件、使用更好的向量索引），再做流式输出（让用户看到打字效果），最后才考虑换更快的模型。毕竟检索结果不准确，换再快的模型也没用。

7.4 建立“人机协同”的默认模式

在汽车产业里，AI不应该抢占流程中的“人”，而应该把专家从重复劳动中释放出来。以售后技术问答为例，最有价值的设计不是让AI直接“替”技师回答问题，而是让AI快速给出排查方向，然后把通话记录、检索到的文档片段、AI结论一起展示给专家，由专家做最终判断。这种模式下，专家愿意把自己的修正意见回流到系统里，知识库才会越滚越厚。相反，如果AI总是自信满满地给出错误答案，用户点几次不满意就再也不会用了。

工具本身没有价值，只有被人在真实工作流里反复使用，它才可能沉淀出行业Know-How。国产AI走到今天，底层模型能力已经不是最大瓶颈，真正考验工程团队的，是如何把模型组织成可靠的服务、把知识组织成可检索的数据、把反馈组织成持续进化的闭环。这件事很难，但和“发布会上的内卷”无关，值得慢慢做。如果这篇文章里的思路对你有启发，建议先从手头一个具体的窄场景开始，搭一个最小闭环，跑一批真实数据，再迭代下一版。AI在汽车产业里的价值，不会来自谁的PPT更华丽，只会来自多少条一线维修工单因为AI而少翻了几页手册、多少次误判因为AI的提示而被提前识别。