从“推荐一辆车”到“解释为什么”：四个大模型的购车决策评测

购车推荐能否真正帮助决策，取决于模型是否记住预算、正确处理需求变化，并给出经得起核对的理由。本次比较DeepSeek Flash、GPT-6.1 Terra、GPT-6.1 Sol和GPT-5.6 Luna，完成36次正式任务与8次边界任务。

四个模型全部通过结构化自动检查，理由复核却拉开了差异：DeepSeek出现2次明确的跨动力续航比较，Luna出现5次，Terra与Sol在本次记录中保持了比较口径。这也成为本文分析评测方法与产品设计的切入点。

目录

第一部分 调研与评测

统一实验设计与关键代码

模型选型与接入方式

DeepSeek Flash与GPT-6.1 Terra构成主要比较组，GPT-6.1 Sol提供性能定位较高的对照，GPT-5.6 Luna提供成本取向的对照。实验关注这几种定位在同一购车任务中的实际表现。

编码与Agent基准为选型提供背景。Artificial Analysis的Max配置对照中，Terra与Flash-1017在Terminal-Bench 4.0上的成绩为55.6%和33.8%，在FrontierCode 2.0上为42.3%和28.5%。购车决策的排序由本文实验结果确定。基准来源

DeepSeek公开版本说明为DeepSeek-V4.1-Flash-1017，实际响应字段为deepseek-flash；三个GPT请求的响应字段均与请求标识一致。GPT接口地址为https://ccgoai.club/v1。Sol支持的思考配置从low起，本次采用high。DeepSeek文档、Sol文档、Luna文档

四个模型共用数据、提示词、场景、输出协议和评分器，联网与工具调用关闭。两组分别在2026年11月10日18:50:18—18:54:51、19:15:58—19:35:54运行，组内顺序使用固定随机种子打乱。

本文比较固定模拟车型库、三类需求和四轮协议下的任务表现。每场景3次独立运行构成小样本，结果用于本任务选型。思考设置、分词器、缓存和服务时段随实验记录保存；耗时采用包含网络与网关等待的端到端口径。

固定数据与场景

车型库由12款教学模拟车组成，来源日期为2026年11月10日。每款车均记录年份、配置、价格、座位、车身、动力、续航和功率。价格采用含模拟税费与保险的总价，单位万元；续航单位km，功率单位kW。

动力类型包括纯电BEV、非插电混动HEV、燃油ICE和插电混动PHEV。综合续航按动力类型分组比较，PHEV字段采用综合续航口径。车型ID、数值和比较规则共同构成核验依据。

每模型每场景独立运行3次，共36次正式任务。每次按“初步推荐→需求补充或修改→参数表比较→最终决策”完成四轮，累计144次请求。同一次任务保留上下文，每次独立运行重新建立对话。

另设两个边界场景：B1要求预算8万元以内、至少5座；B2先要求25万元以内、至少7座，再改为20万元以内、至少7座且纯电。每模型各运行一次，8次边界任务单独汇总。预期合格集合和评分规则均在正式运行前确定。

评分规则

总分为35A＋25C＋20I＋20T，各分项取0至1。自动任务成功要求四轮完整且全部自动检查通过；自然语言理由另作逐轮复核。需求变化按最新有效条件评分，合格车型之间的选择差异计为合法结果。

稳定性按“模型×场景”汇总成功数、得分均值和样本标准差。用量采用接口返回的usage，耗时按完整四轮任务计量。正式组36次任务全部完成，共144次请求，无重试。

关键代码一：统一API调用

程序使用OpenAI兼容请求格式，按配置读取接口、型号和参数。密钥从环境变量读取。下面展示run.py中的核心请求逻辑：

key = os.environ[model["api_key_env"]]
payload = {
    "model": model["model"],
    "messages": messages,
    "stream": False,
    **model.get("parameters", {}),
}
endpoint = model["base_url"].rstrip("/") + "/chat/completions"
with requests.post(
    endpoint, json=payload,
    headers={"Authorization": f"Bearer {key}",
             "Content-Type": "application/json"},
    timeout=config.get("timeout_seconds", 180),
) as response:
    response.raise_for_status()
    body = response.json()

关键代码二：多轮上下文管理

每次调用execute_task时新建messages；任务内持续追加用户消息与模型回答。候选、表格、最终推荐以及每轮用量和耗时写入原始记录。

messages = [{"role": "system", "content": system}]
for stage, prompt in enumerate(prompts, 1):
    messages.append({"role": "user", "content": prompt})
    reply = request_turn(model, messages, config, checkpoint)
    if reply["status"] != "ok":
        break
    messages.append({"role": "assistant", "content": reply["content"]})

关键代码三：硬约束核验

评分器按轮次选择初始或更新后的约束，通过车型库自动计算合格集合。以下为evaluate.py中的约束检查与候选筛选函数：

def constraints_checks(car, constraints):
    tests = []
    for key, value in constraints.items():
        if key == "max_budget_wan":
            tests.append(car["price_wan"] <= value)
        elif key == "min_seats":
            tests.append(car["seats"] >= value)
        elif key == "min_range_km":
            tests.append(car["range_km"] >= value)
        elif key == "body":
            tests.append(car["body"] == value)
        elif key == "powertrain_in":
            tests.append(car["powertrain"] in value)
        else:
            raise ValueError(f"Unknown constraint: {key}")
    return tests


def eligible(cars, constraints):
    return {car["id"] for car in cars if all(constraints_checks(car, constraints))}

JSON中的candidates、table与final被分别提取并保存为CSV，Matplotlib根据汇总结果生成图表。完整调用、异常记录、解析与评分实现见代码仓库，17项程序检查全部通过。

大模型1：DeepSeek

体验

DeepSeek官方API完成了需求输入、追问、参数比较与最终决策。在S1试运行中，新增续航要求后保留T01、T02，并推荐续航510km、总价14.8万元的T02。

它的优点是自然语言需求能直接转为候选和参数表，便于程序提取。体验中的核心检查点是需求变化后旧条件的保持，以及推荐理由是否使用了适当的比较口径。

图1　DeepSeek：初始需求与候选推荐

图2　DeepSeek：需求变更后的参数表

用户访谈

受访者为计算机、软件相关专业在校学生，匿名记录。其学习内容涉及程序设计、信息检索和软件使用，能够从普通用户与软件学习者两个角度评价产品。

同一位同学分别体验两个产品，按每产品10—15分钟的流程开展访谈。任务采用20万元以内、至少5座的SUV需求，随后补充无充电条件，再查看参数表、最终推荐和历史对话。

问：你的学习背景是什么，为什么愿意参加这次体验？

答：我的学习方向与计算机和软件开发相关，平时会接触信息检索、程序设计和软件使用。这次我想从使用者角度，看看大模型能不能持续记住条件，也想从软件工程角度观察它的交互和结果是否方便检查。

问：你希望DeepSeek帮你解决什么问题？

答：我希望先按预算和使用条件排除不合适的车型，再比较剩余候选。参数很多时，直接看车型列表容易遗漏条件。如果能先把需求整理清楚，再说明每款车为什么适合，会更有帮助。

问：从上手和交互角度，你怎样评价这个产品？

答：自然语言输入比较直接，不用先理解一套复杂筛选菜单。连续补充条件也比较方便。但思考与联网开关的作用需要更明确，让用户知道设置会怎样影响回答。

问：修改成没有充电条件后，你会重点检查什么？

答：我会检查纯电和插电混动车型是否被排除，也会检查20万元、SUV和至少5座这些旧条件是否还在。新旧条件都应持续生效。

问：参数表和推荐理由有哪些亮点或困难？

答：表格比长段落更容易比较，也便于回看。困难在于价格、年份、配置和续航口径可能不同，所以每个数值最好带来源与单位。不同动力类型的续航需要按口径分组比较。

问：你会直接按推荐购买吗？最希望改进什么？

答：我会把它作为整理信息和缩小范围的工具，购买前再核对实际报价和具体配置。最希望增加当前需求清单，以及每款车符合哪些条件的检查结果；修改需求后还应标出变化。

图3　受访者操作DeepSeek与访谈记录

自动化测试

正式组完成9次四轮任务、36次请求。四项自动指标均为100分，自动成功率9/9。平均完整任务耗时11.51秒，样本标准差1.79秒；平均总Token为7457，平均报告推理Token为798。

理由复核在S3第2、3次运行发现跨动力续航比较，问题集中在最终推荐理由。DeepSeek正式记录

结论

DeepSeek在本次任务中满足硬约束、保持候选并生成完整表格，响应速度领先。集成时应加强理由中的可比性核验，将参数正确和比较合理分别检查。

大模型2：ChatGPT-6.1 Terra、Sol、5.6Luna

体验

图4　GPT：初始需求与候选推荐

图5　GPT：需求变更后的参数表

用户访谈

受访者继续使用相同购车任务，从型号选择、参数表、无解处理和响应速度四个方面比较体验。

问：用同样需求体验第二个产品，你最在意什么？

答：我最在意推荐是否始终符合条件，以及理由是否可以核对。只要车型满足要求，并说明取舍，我可以接受不同的最终选择。

问：型号和模式选择对你是否清楚？

答：仅凭型号名称，很难知道哪个适合自己的任务。平台最好清楚说明速度、费用、思考方式和适用场景。我会结合速度、费用和适用场景选择型号。

问：表格输出对你有哪些帮助？

答：表格方便横向查看价格、座位、动力等关键参数，减少来回翻找信息。我希望关键字段排在前面，没有来源或不知道的数据直接写未知，并标出具体缺失项。

问：当新要求导致无车可选时，你希望它怎样回答？

答：应直接说明是哪几条条件组合后无解。例如20万元、7座和纯电不能同时满足时，可以问我愿意调整哪项，预算和座位要求的调整应由我确认。

问：速度与答案质量之间，你会怎样取舍？

答：初步筛选时希望反馈及时，重要权衡可以多等一些时间。但等待应当换来更有依据的解释，过程也应有清楚的状态提示。

问：你最希望增加什么功能？

答：希望查看推荐引用的资料，导出需求、候选和比较结果。如果经过第三方网关，还应明确显示实际请求型号、版本和计费规则，让用户能判断自己正在使用什么服务。

访谈中反复出现三项需求：条件持续有效、推荐依据可追溯、无解时由用户决定取舍。需求清单、来源标记与选择过程解释因此成为产品改进重点。

图6　受访者操作第二产品与访谈记录

自动化测试

Terra正式组完成9次四轮任务、36次请求，四项自动指标均为100分，自动成功率9/9。平均耗时18.81秒，样本标准差1.69秒；平均总Token为6729.22，报告推理Token为0。

理由复核的明确跨动力续航比较计数为0。S3三次最终选择中，T08出现2次、T07出现1次，均满足全部硬约束。Terra正式记录

结论

Terra在结构化输出和解释口径上表现稳定。它在本次链路中的平均耗时高于DeepSeek，总Token更少；适合将推荐依据和交互响应共同纳入考量的购车助手。

补充对照组：GPT-6.1 Sol与GPT-5.6 Luna

GPT-6.1 Sol

Sol采用high思考配置，完成9次四轮任务、36次请求。四项自动指标均为100分，自动成功率9/9；平均耗时28.69±3.63秒，平均总Token为7247.67±207.02，平均完成Token为696，其中报告推理Token为45.33。

三个场景分别稳定推荐T02、T04、T08。理由复核的明确跨动力续航比较计数为0，多条回答主动标明续航比较分组，并用价格或功率说明取舍。Sol的主要优势体现在解释的清晰度和比较依据的保持。

GPT-5.6 Luna

Luna采用none思考配置，完成9次四轮任务、36次请求。四项自动指标均为100分，自动成功率9/9；平均耗时104.24±18.35秒，平均总Token为6748.67±198.43，平均完成Token为485.78，报告推理Token为0。

理由复核发现5次明确的跨动力续航比较，另有1次参照不明表述。Luna在三项美元计价记录中开销最低，解释质量和链路响应是集成时需要重点优化的环节。

量化结果与案例分析

四模型结果

四个模型的自动分均达到100，题目在结构化检查上出现上限效应。理由复核补充了语义质量差异：相同错误可以稳定重复出现，稳定性和正确性需要分别衡量。

各场景均为每模型3/3自动成功、得分标准差0。DeepSeek、Sol和Luna分别固定推荐T02、T04、T08；Terra在S3选择过T07与T08。合格集合允许多个选择，因此稳定性以任务完成情况和指标波动衡量。

费用按模型总额记录：DeepSeek为0.07元人民币，三个GPT模型合计0.2437美元。其中Sol为0.165美元、Terra为0.072美元、Luna为0.0067美元。比较开销时同时考虑任务轮数、Token、响应时间与理由质量。

案例一：字段正确，比较口径出现错误

deepseek_S3_r2第4轮保留ICE车型T07、T11和HEV车型T08，推荐T08。其理由包含：“在保留候选中，其综合续航和功率数据最高。”

T08符合预算、SUV、座位和动力要求，表格数值也与车型库一致。问题发生在解释环节：数据要求综合续航按动力类型分组比较，回答却把HEV和ICE的续航用于同组排序。第3次运行也出现相近表述。

Luna S3第3次第4轮直接比较HEV的T08续航950km与ICE的T07续航680km。Luna共有5次明确问题；S2第2次的“较长续航、较少补能依赖”缺少明确参照，归入参照不明类别。

Sol S3第1次第4轮保持了动力分组，以功率、预算和价格解释选择。自动评分核对字段与协议，理由复核核对比较依据，两层检查共同揭示了模型差异。

案例二：需求变化后正确识别无解

B2初始要求为25万元以内、至少7座，T04、T05、T06合格；随后改为20万元以内、至少7座且纯电。唯一7座纯电车型T06价格23.8万元，超过新预算。

四个模型均把候选集合更新为空，返回final=null与no_solution=true，后续轮次继续保留无解状态。B1的8万元预算也被正确识别为无解。8次额外边界任务全部通过，每个边界场景每模型各1次。

原始记录：DeepSeek B2、Terra B2、Sol B2、Luna B2。

接口接入案例

Terra的模型目录与实际调用状态存在差异。试运行记录显示，/models列表缺少该型号，按精确ID调用的四轮请求全部成功。

另一问题来自本机HTTPS信任链：urllib客户端验证失败，改用保持证书校验的requests后调用成功。接入失败记录归入接口链路检查，与内容评分分别处理。

第二部分 分析

大模型对现实生活的影响

大模型把预算、家庭出行和补能条件等自然语言需求转为候选和比较表，降低了信息整理门槛。用户可以边交流边修正条件，逐步形成自己的决策依据。

这类能力也让信息核验更重要。价格口径、配置年份和动力类型影响比较结果，系统应在推荐旁展示来源、单位和条件检查。透明的依据能帮助用户作出取舍。

软件测试的重点随之从“接口能否返回”扩展为“完整任务是否正确完成”。需求保持、变更处理、事实核对与无解识别都应进入测试链路。本次评测采用固定数据和独立重复，将这些行为转为可检查记录。

开发时间估计与软件层次

开发时间估计

采用工作分解法估算同规模评测系统的一人工作量。前提是具备Python基础、电脑和可用模型API，总投入预计12—15小时，按两天安排。

上述区间合计12—15小时。模型调用等待、接口接入和发布审核构成日历安排中的时间余量。

程序层面

messages数组保存对话上下文，车型字典按ID提供事实依据，约束集合生成合格候选。参数解析、轮次状态和评分函数共同构成评测程序的算法与数据结构。

软件工程层面

固定数据、提示词版本、独立重复、接口适配、原始日志和程序快照让实验可复查。每个图表都能追溯到评分CSV及对应回答，修改评分或提示词时也能明确识别版本差异。

平台的鉴权、配额、版本管理、开发者文档和错误说明，则决定模型能力能否稳定进入应用。服务质量需要同时覆盖模型输出与接入链路。

商业层面

API将推理能力包装为按用量消费的服务。Token计费、缓存和网关路由影响实际调用开销；文档、兼容协议和稳定性影响开发者接入成本。

本次实际开销显示，同一购车任务可采用不同成本与响应配置。开发者应以“完成合格任务所需的费用、时间和复核工作量”衡量总成本，再选择模型与集成方式。

同类产品对比排名与选型

按本次自动规则，四个模型并列。端到端响应速度依次为DeepSeek、Terra、Sol、Luna；理由可比性检查中，Terra与Sol的明确问题计数为0，DeepSeek为2，Luna为5。

购车助手的选型应把硬约束合规、语义质量、响应和开销放在同一张表中比较。增加真实车型配置、预算阈值和连续需求变化场景，有助于检验这组建议的稳定性。

软件工程建议与BUG原因分析

案例一的字段数值正确，错误出现在比较依据：回答遗漏了数据元信息中的动力分组。评分器检查结构化参数，理由复核发现语义问题，反映出模型指令保持和测试覆盖两个层面的改进需求。

原因分析假设是：理由生成使用了显眼的数值大小，而弱化了元信息约束。验证这一假设可加入同动力与跨动力的配对任务，观察说明方式变化后的错误率。

接入问题则分别落在客户端信任链和网关服务发现层。排查顺序为输入数据、提示词、模型原文、解析器、接口服务；每层保留独立证据，便于定位责任与验证修复。

改进方案比较

优选“结构化比较证据＋可比性校验”：让模型同时提供比较字段、涉及车型与依据，程序按字段分组核验，再生成面向用户的解释。

第二种方案把解释依据变成可核查对象，能直接针对本次发现的问题。验证设计沿用三个场景、每模型三次重复，再加入同组与跨组续航对照，比较改进前后的错误率与额外开销。

接入层可增加平台参数配置和最小试调用，将已验证型号、可用参数与错误状态保存下来。内容层再加入结构化需求状态、预算阈值、同名不同配置、缺失数据及连续改需求的测试。

市场概况

模型服务、智能体应用和个人用户共同构成市场需求。以下按各来源的统计口径整理规模与增长指标。

购车助手直接面向需要信息整理的个人用户，模型评测工具面向开发者；汽车内容平台与咨询服务商是潜在企业客户。产品可通过试用登记、任务完成率和复用意愿，逐步建立自己的用户规模与转化数据。

产品规划：可解释的购车约束助手

我会优先建设三项能力：来源可追溯、需求状态可见、无解冲突可解释。每次修改条件后展示有效需求，每个候选旁列出合规依据，并为价格和配置附上来源与更新时间。

产品优先完成推荐依据和约束检查，再扩展联网行情与试驾流程。验收采用同车型、同任务的对照测试，比较硬约束违规率、任务耗时和用户对推荐依据的理解程度，并以复用意愿决定扩展节奏。

参考资料与实验材料

1. DeepSeek API文档与模型及价格。
2. OpenAI模型文档：Terra、Sol、Luna，以及Chat Completions参数。
3. Artificial Analysis基准对照；市场资料见市场概况，查阅日期为2026年11月10日。
4. 汇总报告、逐次评分、逐场景统计、原始记录、理由复核。
5. 车型库、场景、提示词、费用记录与访谈记录。