从购车问答到可验证决策：多轮大模型评测总结

作业基本信息

目录

第一部分 调研、评测

一、项目背景

购车咨询同时包含预算、车身形式、能源类型、座位数、安全配置和续航等约束。用户还可能在对话中途改变预算或其他条件，因此一次回答“看起来合理”并不足以证明系统可靠。本项目评测两个模型能否在多轮对话中持续满足硬约束、输出可解析的结构化信息，并在失败时留下可追溯证据。

项目使用 Node.js 原生模块实现模型接口、任务编排、逐轮日志、候选提取、Markdown 参数表提取和结果导出。代码与输入材料都保存了版本和 SHA256，便于其他成员复核。

二、系统实现

每次任务从独立消息列表开始，按固定模板经历初步推荐、购车要点、需求变化、参数对比和最终推荐。任务计划由“模型 × 场景 × 重复次数”构成，固定随机种子打乱执行顺序。同一任务保留上下文，不同重复任务相互隔离。

程序把批次、任务和执行编号写入 manifest.json、tasks.jsonl 和 raw.jsonl。complete 只表示轮次正常结束，不代表模型推荐正确；接口失败、回答截断和解析失败分别记录，不能被静默删除。密钥只从本地环境变量或 .env 读取，原始日志不包含 Authorization 或 API Key。

自动化测试覆盖任务数量、需求变更、上下文隔离、恢复运行、重试、身份错误、截断识别、JSON/表格提取和秘密安全。运行方式见仓库根目录 README.md。

2.1 大模型 1：Qwen3-32B

2.1.1 体验

Qwen 能快速把预算、车身、能源、续航和 AEB 等条件整理成候选表，城市通勤场景下会给出较多可选车型，并对部分车型的版本和 AEB 标配情况提示核实。七座家庭场景中，它能把“可能满足”和“明确满足”分开，但也会把 5 座车型作为“如果七座不是刚需”的备选，说明硬约束和软建议需要在界面上进一步分层。

2.1.2 改进建议

Qwen 适合快速建立候选池，但应增加“硬约束已验证/待核实”标签，按具体版本展开 AEB 和价格来源，并在预算变化后提供候选增删对照，避免把疑似满足车型和明确满足车型混在一起。

2.1.3 自动化测试

Qwen 在 live-001 和 boundary-001 共完成 15 次任务、63 轮请求。它的平均单任务耗时为 67 秒（基础批次）和 48 秒（边界批次），吞吐和 token 成本优于 R1；但预算变化和卡线约束容易出现候选污染、数值判断过宽或过严、JSON 尾逗号等问题。

2.1.4 结论

Qwen 更适合对延迟和成本敏感的初筛场景，但上线前必须增加车型字段校验、预算边界校验和版本级 AEB 证据核对，不能直接把生成结果当作最终推荐。

2.2 大模型 2：DeepSeek-R1

2.2.1 体验

DeepSeek 会通过联网检索补充来源、更新时间和版本风险，回答的证据说明更细。它在七座家庭场景中倾向于只保留能够明确核验的候选，在预算变化后会重新列出候选并说明排除原因。代价是回答较长、来源较多，用户需要更强的阅读和核验能力。

2.2.2 改进建议

DeepSeek 的来源解释较充分，但回答较长。建议增加摘要、证据和风险三层展示，允许用户折叠来源；同时提供固定字段的车型对比表，减少长段落阅读成本。

2.2.3 自动化测试

DeepSeek-R1 在两批次共完成 15 次任务、63 轮请求。基础批次加权总分 96.4，边界批次 94.7；推荐合理性、多轮一致性和稳定性均为 100 分。主要失分来自“内容正确但 JSON 未按代码块格式输出”，而不是候选车型判断错误。

2.2.4 结论

DeepSeek-R1 更适合需要复杂约束解释和证据整理的辅助决策场景，但其响应时间和 token 消耗更高，且解析器需要支持解释文字后的合法 JSON 回退。

2.3 两个模型的体验与采访结论

软件工程专业受访者认为：品牌官网的事实性最高，独立汽车媒体适合补充实测，AI 更适合做信息整理；对驱动形式、电池容量、续航、质保和主动安全等核心参数错误零容忍。受访者还要求预算变化后解释候选增删和取舍逻辑，并认为只有持续核验配置、价格和投诉信息的工具才具有付费价值。完整采访内容已合并到本文，仓库中的用户研究文件仅作为原始材料索引。

2.4 用户采访记录

本次采访日期为 2026-11-09，受访者为计算机科学与技术林复彬，平时经常使用 AI 工具和信息检索软件，访谈约 25 分钟。

1. 平时如何搜索购车信息？

受访者通常先用 AI 或汽车平台按预算和用途建立候选池，再查看独立汽车媒体的长测内容，之后到品牌官网或官方 App 核对车型版本、配置、指导价和质保政策，再参考车主论坛、车主社群和投诉平台，最后视情况线下看车试驾。整个过程强调多渠道交叉验证，不会只依赖 AI 的单次推荐。

2. 更信任 AI、官网还是汽车媒体？

信任排序为：品牌官网 > 独立客观汽车媒体 > AI。官网是一手配置和版本信息来源，但通常只展示优点；专业媒体可以补充实测体验，但可能存在商业合作；AI 适合检索和整理，不应直接作为购车决策依据。

3. 推荐结果需要哪些证据？

受访者希望硬性参数附官网配置页链接和更新时间，价格区分指导价与地区落地价并标注采集时间，优缺点标明官方、媒体实测或车主反馈来源，同价位车型使用统一比较维度，并主动提示改款、停产、投诉集中和库存车风险。

4. 如果 AI 参数错误，能否接受？

内饰配色等不影响核心决策的小细节，在明确提示“以官网和实车为准”时可以容忍；驱动形式、电池容量、续航、动力、质保和主动安全配置等核心参数错误则完全不能接受。对于信息混乱或样本较少的内容，AI 应标注置信度，而不是使用绝对肯定的语气。

5. 预算变化后，希望 AI 怎样解释？

预算变化后，AI 不应只给出一份新清单，而应说明筛选规则如何变化、哪些旧候选因超预算被排除、哪些新候选进入，以及动力、安全、空间和舒适性之间的取舍。受访者希望看到“家用省心”和“驾驶质感”两种侧重方案，并得到该预算区间常见短板和隐形成本提醒。

6. 是否愿意使用或付费购买这种工具？

受访者愿意长期使用免费版本进行前期信息整理、车型对比和 4S 店提问清单生成，但不会为普通问答高价付费。只有在工具能持续核验官网配置更新、识别新旧款差异、过滤商业测评、跟踪本地报价、分析投诉通病并提供看车核对清单时，才会考虑小额付费。

受访者原话（已脱敏）：“我只会把 AI 当成检索助手、信息整理工具，绝对不会把 AI 推荐当成购车决策依据。”

2.5 自动化测试结果与可视化

评分汇总（已内嵌）

基础批次 live-001 有效任务 18 次、逐轮记录 78 条；边界批次 boundary-001 有效任务 12 次、逐轮记录 48 条。两批次的关键评分如下，原始明细仍随仓库提交保存。

2.6 截图证据墙

为避免只展示结论，下面直接展示两种产品在三个统一场景下的原始体验截图。

城市通勤

家庭用车推荐

预算变化

三、实验设计与数据边界

基础批次 live-001 使用两个模型、三个场景、每个组合三次重复，共 18 次任务、78 轮请求；边界批次 boundary-001 增加无解和卡线唯一解两个场景，共 12 次任务、48 轮请求。两批合计 30 次任务、126 轮请求，全部 complete，0 失败、0 重试。

被测模型为 Qwen/Qwen3-32B（关闭思考）和 deepseek-ai/DeepSeek-R1（默认思考），均通过硅基流动的 OpenAI 兼容网关、max_tokens=4096。车型数据集 teaching-cars-v1 标记为 teaching_simulation，是教学模拟数据，不是市场报价；因此本文不能把推荐写成真实购车建议。

实验材料摘要

实验材料包括固定车型数据、三组基础场景、两个边界场景、统一提示词、评分规则、逐轮原始回答、任务终态、评分明细和图表。运行方式为 node src/cli.mjs check、node --test、node src/cli.mjs run --mock --batch demo-local；正式批次使用 node src/cli.mjs run --batch live-001。密钥只从环境变量或本地 .env 读取，不进入博客和实验附件。

四、真实实验结果

4.1 基础批次

DeepSeek-R1 在三个基础场景的推荐通过率都是 100%；Qwen3-32B 在城市通勤和七座家庭场景为 100%，预算变更场景为 67%。Qwen 的单任务耗时约为 R1 的 38%，token 用量低约 19%，因此成本和吞吐更有优势。

4.2 边界批次

在无解场景 e1-no-feasible 中，两个模型都在 3/3 次任务返回无推荐结果；在预算和车长恰好取上限的唯一解场景 e2-boundary-only 中，R1 为 3/3，Qwen 为 1/3。这个结果说明卡线数值判断比普通场景更能区分模型稳定性。

4.3 失败与边界案例

• qwen-general__budget-change__r002：Qwen 把 17.8 万车型判断为满足 15 万预算，并在后续轮次继承错误结论，最终漏掉本应合格的车型。
• qwen-general__city-commute__r001：候选列表包含超预算车型，说明文字却声称没有超预算车型，列表与解释互相矛盾。
• qwen-general__e2-boundary-only__r001/r003：预算和车长恰好等于上限时把唯一合格车型判为无解。
• deepseek-reasoning__budget-change__r001：内容正确但把裸 JSON 放在解释文字中，旧解析器未识别；这属于解析器回退能力不足，不应与推荐内容错误混为一谈。
• qwen-general__city-commute__r002：输出带尾逗号的非法 JSON，属于模型格式缺陷，程序应保留失败而不是偷偷修复。

4.4 选型结论的适用范围

在本次 8 辆教学模拟车型、3 个基础场景、2 个边界场景、共享提示词和硅基流动网关条件下，R1 的约束推理和多轮稳定性更好，Qwen 的延迟和 token 成本更低。每个场景只有 n=3，不能做显著性判断，也不能外推成两个模型在所有任务上的整体排名。

五、产品体验与用户研究

5.1 体验方案

课程要求体验两个产品并截图。体验对象应与实验模型对应：阿里云百炼 Qwen 对话产品和 DeepSeek 对话产品。两边使用同一组城市通勤、七座家庭和预算变化输入，观察是否澄清约束、展示可核对参数、解释需求变化，以及在信息不足时承认不确定性。

本次体验已完成并归档了 Qwen 和 DeepSeek 的截图，覆盖三组相同场景。截图显示：Qwen 会整理较多候选并主动提示版本/AEB不确定性；DeepSeek 会使用联网检索，来源说明更细，但结果信息量更大。两者都能在预算从 20 万降到 15 万后重新列出候选并解释排除原因。

受访者实际使用过程

采访中让受访者分别使用 Qwen 和 DeepSeek 对话页，完成三组统一任务：城市通勤、七座家庭、预算从 20 万下调到 15 万。受访者实际使用了新建对话、输入框、多轮追问、候选车型表格和来源展开等栏目，并根据回答继续追问 AEB、版本和预算边界。

受访者提出的主要改进意见：增加“硬约束已验证/待核实”标签；支持按版本展开 AEB、价格和续航来源；预算变化时显示候选增删对照；将长回答折叠为摘要、证据和风险三层；提供可保存、可复核的购车方案。

统一体验观察表

采访对象是计算机科学与技术专业林复彬，访谈约 25 分钟并同意脱敏记录。受访者认为品牌官网的事实性最高、独立媒体适合补充实测、AI 更适合做信息整理；对驱动形式、电池容量、续航、质保和主动安全等核心参数错误零容忍。受访者还强调，预算变化后必须解释候选增删和取舍逻辑，并认为只有持续核验配置、价格和投诉信息的工具才具有付费价值。这些反馈支持本项目把“来源、更新时间、不确定性和约束校验”作为产品核心，而不是只追求回答流畅。

5.2 采访问题与回答摘要

下面保留原采访提纲，并补上受访者的实际回答，避免只展示问题而看不到研究证据。完整采访内容已在本文展示。

林复彬：“我只会把 AI 当成检索助手、信息整理工具，绝对不会把 AI 推荐当成购车决策依据。”

第二部分 分析

六、市场与商业模式

6.0 市场概况

生成式 AI 已从通用问答逐渐进入生活决策和效率工具场景。中国互联网络信息中心发布的《生成式人工智能应用发展报告（2025）》显示，截至 2025 年 6 月我国生成式人工智能用户规模已达 5.15 亿，说明用户基础和使用习惯已经形成；但从通用问答走向购车等高风险决策，仍需要可靠数据、来源追溯和人工复核。CNNIC 报告

本产品面对三类用户：需要快速缩小范围的个人购车者、需要整理车型信息的汽车媒体/销售人员、以及需要将推荐流程标准化的评测和企业团队。市场竞争主要来自传统汽车平台筛选器、品牌官方购车工具和通用大模型，差异化机会在于把自然语言需求、版本级约束校验和证据链放进同一个流程。

购车决策的痛点是信息分散、参数口径复杂、需求反复变化。对话式 AI 可以把自然语言转成结构化约束，再将候选车型、参数来源和排除理由放在同一张可核对的表中。真正的产品价值不只是生成流畅文字，而是降低比较成本并保留证据链。

可探索三类商业模式：

1. 面向个人用户的免费基础筛选与订阅制深度报告；
2. 面向经销商、汽车媒体的需求解析与合规评测 API；
3. 面向金融、保险和售后服务机构的决策辅助接口。

商业推荐、广告或佣金必须显式标注，不能改变硬约束校验结果。价格、库存和金融方案若接入实时工具，还需要保存来源、时间和失败状态。

6.1 开发时间估计

以下是重新实现同等基础版本的工程估计，不是团队实际工时，也不包含真实 API 等待、采访和博客排版：

6.2 同类产品对比与排名

这个排名仅适用于本次教学模拟数据、3 个基础场景、2 个边界场景和当前网关配置，不代表模型在所有任务中的总体排名。产品选型应按延迟、预算、证据要求和风险容忍度选择。

6.3 软件工程方面的建议

1. 固定输入和版本：车型、场景、提示词和评分规则都保存快照与 SHA256，避免不同批次混用材料。
2. 独立校验硬约束：模型负责理解自然语言和生成解释，程序负责核对车型 ID、预算、座位数、能源类型、续航和 AEB 等结构化字段。
3. 保留完整证据：原始回答、解析结果、失败原因、重试记录和执行摘要都要保存，不能只保留最终推荐。
4. 区分完成与正确：complete 只代表请求轮次完成，质量评分必须另外统计推荐合理性、格式、真实性和一致性。
5. 保护凭据与隐私：密钥只通过环境变量读取，截图和采访材料脱敏后再提交。

6.4 BUG 存在的原因分析

模型内部原因无法从黑箱 API 记录直接证明，以上只对可观察现象提出工程诊断假设。

七、现实影响与产品规划

7.1 现实影响

积极影响包括降低信息检索门槛、帮助用户整理复杂需求、让家庭成员更容易比较方案。主要风险包括编造车型参数、混淆续航测试口径、忽略安全硬约束、把推荐误解成金融结论，以及记录家庭成员偏好时泄露隐私。

7.2 产品规划（NABCD）

产品规划采用 NABCD 结构：

• Need（需求）：用户需要在预算、版本、续航、安全和价格信息不一致时，快速得到可复核的购车候选，而不是只得到一句“推荐某车型”。
• Approach（做法）：用自然语言抽取约束，程序独立校验硬条件，模型负责解释取舍；每个参数附来源、更新时间和置信度。
• Benefits（收益）：降低多平台复制整理成本，减少超预算、错版本和把不确定信息写成确定结论的风险。
• Competitors（竞争）：传统汽车平台筛选器字段稳定但不擅长多轮需求；通用大模型表达灵活但缺少车型版本校验；本方案定位在两者之间。
• Delivery（交付）：先完成车型库、约束校验和证据表 MVP，再接入价格/库存工具，最后用固定回归集持续评测模型更新。

产品规划分为三阶段：

• MVP：车型库、约束抽取、候选校验、参数表、来源和更新时间。
• 工具化：接入经授权的价格、库存、充电设施和金融数据，并记录每次工具调用。
• 持续评测：保存用户偏好，支持家庭共同决策；每次模型或提示词更新都运行固定回归集，比较约束满足率、参数正确率、误拒绝率、解析成功率、延迟和成本。

八、改进方案与总结

本次实验最直接的工程改进是给模型输出增加独立的车型字段与约束校验层。程序先保留原始回答，再检查未知车型、预算越界、车身类型错误和遗漏硬约束；如果允许修正，最多执行固定次数，并将原始答案与修正答案分开统计。

解析器还可以增加平衡括号扫描回退。离线重放显示，该方案能救回 R1 一次“内容正确但裸 JSON 未加代码块”的记录，但不会掩盖 Qwen 的无 JSON 或尾逗号错误。这样既降低工具误判，又保留对模型格式遵循能力的真实测量。

本项目将工程可复现性和模型质量区分开：批次、输入、请求、评分和失败案例都可追溯；结论只适用于当前模拟数据和实验条件。用户体验截图和脱敏采访已补入仓库，下一步只需发布博客、填写博客链接并完成课程提交。

九、小组分工与贡献比例