本文更多是一种工程路径的推演，而非已经被完整实践验证的结论。
它更像是一张“地图”，用来帮助在构建 Chatbot 的过程中尽量避免迷路。
背景
在很多产品团队的讨论里，“做一款车主 Chatbot”往往会被简化成：
- 接入一个大模型
- 设计一些提示词
- 准备文档材料，接入知识库（RAG）
- 然后在 APP 里设计一个对话框 UI，开启对话功能
但当你真正把它视作一款需要长期落地、持续迭代，并承担真实业务责任的产品时，就会发现：它并不只是“把模型接进来”，而是要让模型在真实业务场景中形成稳定、可依赖的专业判断能力。
在阅读智谱 AI 首席科学家唐杰的分享
「谈 2025 年对大模型的看法」
后，
我尝试从第一性原理出发，推演如果从零构建做一款车主 Chatbot，在业务落地层面，可能需要经过哪些关键路径。
一、第一性原理
目标：用 AGI 替代 汽车技师 的部分工作，解答车主的日常问题咨询。
如果这个目标成立，那么后续所有产品设计，都应该围绕 “专业判断能力是否形成” 展开，而不是围绕用户画像、问题类型或业务流程本身。
二、让模型对齐真实业务场景，增强实际体感
Mid 和 Post Training 使得模型更快对齐业务场景，并具备更强的推理能力成为可能。
换句话说，就是让模型更快学会在真实业务场景下应该如何思考，如何回答。
1. 继续预训练 Continued Pre-Training（CPT）
目标：补齐领域知识与因果结构。
汽车领域的知识并非“百科式知识”，而是由大量工程结构与因果关系构成，例如：
- 系统原理：发动机 / 变速箱 / 底盘 / 电气架构 等
- 故障机理：症状 ↔ 原因 ↔ 处理路径
- 维修动作：检测步骤、拆装流程、风险提示
- 品牌差异：不同车型的共性与特例
CPT 的意义，并不在于让模型“记住更多资料”，而是让模型内部表示方式更接近这一领域的知识结构本身。如果缺少这一阶段，后续的 SFT 很容易沦为“教话术”，而非真正补足能力。
2. 模型微调 Supervised Fine-Tuning（SFT）
目标：对齐专业表达方式与推理结构。
一个成熟技师的回答，往往具备相对稳定的判断骨架：
- 复述问题，确认症状
- 判断优先级（是否存在安全风险）
- 给出排查路径（从低成本到高成本）
- 提供处理建议与注意事项
- 明确哪些情况必须线下处理
SFT 的核心价值，在于把这种结构化判断方式，固化为模型输出的默认行为，而非依赖随机生成。
它解决的不是“模型会不会”，而是“模型像不像一个专业的人”。
3. 强化学习训练 Preference Optimization（DPO / RLHF）
目标：压制高风险误导回答，鼓励更负责、更稳健的回答。
在车主问答场景里，模型的风险通常来自三类情况：
- 误导性确定：基于幻觉给出错误结论
- 危险建议：在高风险场景下给出不当操作建议
- 不负责任的安慰：把复杂故障轻描淡写
DPO / RLHF 的价值在于：将“更可靠、更专业、更放心”的回答 Good Case ，作为模型的偏好固化下来。
对车主 Chatbot 而言，这一阶段甚至比“更聪明”更重要：它直接决定了 AI 是否能够长期对用户负责。
4. 知识蒸馏 Distillation
目标：让能力可部署、可规模化、可控成本。
尽管大模型的能力很强，但它通常意味着：
- 成本更高
- 延迟更大
- 稳定性更难保障
- 高并发场景下更难服务
蒸馏的意义在于：将已验证的可用能力，迁移到更小、更稳定、更适合线上运行的模型上。
它并非单纯“压缩模型”，而是让整个工程系统以更低成本、更高并发地跑起来的关键环节。
三、数据工程
无论采用哪种训练路径，数据 始终是绕不开的前提。
如果说训练路径决定了“能力上限”，那么数据工程决定的往往是“能力下限”。
1. 文档知识源
典型来源包括：
- 维修手册 / 车主手册
- 技术通告 / 厂商培训资料
- 零部件说明与参数
- 故障码解释与处理流程
- …
这些数据的作用，并不在于单纯扩充知识覆盖面，而是提供可靠、可追溯的事实锚点。
车主 Chatbot 最怕的不是“不知道”，而是“自信地胡说八道”。
文档知识源为系统提供了一个可解释、可更新的底层事实基础。
2. 真实车主问答数据
真实车主提问，往往具有强烈的“非结构化特征”：
- 情绪化：焦虑、愤怒、怀疑、不安等
- 信息缺失：只描述症状、不给完整条件
- 表达噪声：方言、缩写、错别字等
- 需求混杂：一半是问故障，一半是求安慰
这类数据的价值，并不在于“让模型知道更多故障”，而在于：
- 对齐真实提问方式
- 建立“车主语言 ↔ 工程语言”的翻译通道
- 提升系统对真实世界噪声的耐受性
换句话说——
文档数据让模型更像技师，车主问答数据让模型更像“能理解车主的技师”。
四、系统层能力
即便模型能力不断增强，系统层的约束与协同仍然不可或缺。
在真实业务场景中，AI 的能力从来不是孤立存在的。即便模型本身得到增强，它仍然需要系统层对角色、边界、知识与工具的协同设计，才能在复杂环境中稳定发挥作用。
1. System Prompt
System Prompt 的目标，并非设计流程，而是明确三件事：
- 你是谁：角色设定（技师助手，而非万能助手）
- 你能做什么：能力边界
- 你不能做什么：安全红线
2. RAG（Retrieval-Augmented Generation）
RAG 的关键价值在于：
- 提供可追溯、可更新的外部知识来源
- 在推理阶段补充事实依据，降低幻觉风险
- 作为模型能力之外的重要兜底机制
更重要的是，它让系统具备持续更新能力：
新车型、新故障、新通告、新召回，都无需重新训练模型。
3. Agent
如果希望 Chatbot 更像一名技师，而非简单的问答机器人，它就需要具备“问题拆解能力”。
Agent 的作用可以理解为：
- 针对不同问题类型，走不同的思考路径
- 将专业人员的判断方式拆解为可执行步骤
- 协调模型、RAG 与工具调用的顺序与边界
4. Tools & MCP
在车主场景中，存在大量“模型不应凭空回答”的问题，例如：
- 车辆配置查询（车型 / 年款 / 版本）
- 维保记录查询
- 保修政策与召回信息
- 各类结构化计算（油耗、费用、里程等）
Tools & MCP 的意义，在于把这些工作交由可靠的系统工具处理，而不是让模型生成。
5. Context Engineering
车主对话通常呈现出“多轮、渐进补全信息”的特征：
- 第一次只说“车抖”
- 第二轮补充“怠速抖”
- 第三轮提到“之前修过发动机”
Context Engineering 的目标是：
- 提取并结构化对话中的关键信息
- 构建可控的短期与长期记忆
- 引导模型沿着正确的决策路径推进
这往往是车主 Chatbot 体验差异的核心来源：
不是模型“聪明多少”，而是系统“记住了什么、忽略了什么”。
五、效果评估与验证
以上内容更多是一种工程路径推演，并不意味着效果一定成立。
这条路径是否可靠，最终仍需回到验证：
- 用户是否愿意持续使用？
- 回复是否稳定达到“用户体验阈值”？
- 是否能够长期、安全地处理高风险场景？
因此，围绕着模型效果的验证，评估体系至少应包含以下几个方面——
1. Bad Case 分析
车主 Chatbot 的迭代，往往并非依赖平均分提升，而是通过：
- 识别致命失败点
- 将系统性错误逐一修复
典型 Bad Case 包括：
- 在中高风险场景下，给出错误建议
- 误判故障原因，给出错误的处理路径
- 未追问关键信息，导致问题定位不清
- 回答方向正确，但缺乏可执行性（过于泛化）
2. Benchmark 的建立与持续评估
评测集必须尽可能来自真实世界，而非仅使用“标准问答题”：
- 常见故障
- 高风险故障
- 低信息密度问题
- 情绪化提问
在车主场景中，模型“答得像百科”，并不等价于“真正可用”。
3. GPT-as-a-judge 等自动化评测方式
在工程现实中，人工评测成本高、效率低，自动化评测不可避免。
但需要明确的是，GPT-as-a-judge 的目标并非替代人工，而是扩大覆盖范围：
- 用于快速回归测试
- 用于趋势监控
- 用于异常波动发现
最终是否可用，仍需回到真实用户反馈与业务指标本身。
备注
以上推演目前仍主要停留在纸面层面。
但它至少逼近了大模型能力落地的一种可行范式：通过 数据 → 训练 → 系统 → 评估 → 迭代 形成持续闭环的工程过程。