作业简介： 本实验在同一套程序、同一份固定车型库和同一组提示词下，对三个大模型进行多轮购车决策测试，并从推荐合理性、一致性、指令遵循、信息真实性、稳定性与资源效率六个维度评分。

目录

作业格式描述

项目	内容
这个作业属于哪个课程	2601_FZU_SE
这个作业要求在哪里	软件工程实践——大模型评测作业
这个作业的目标	用代码自动完成购车决策，对至少两个大模型做量化评测，并分析平台在程序、软件工程和商业上的差别
其他参考文献	《构建之法》；实验记录见 car-decision-eval 中的 DATA_SOURCES.md、SCENARIOS.md、WEIGHTED_SCORING.md

项目	内容
测试日期	2026-11-09
被测模型	DeepSeek-flash；Qwen3.7-Plus；Kimi-K3
代码	car-decision-eval
正式结果批次	DeepSeek：20261109T102919158508Z；Qwen：20261109T105813490129Z；Kimi：20261109T132351578978Z

---

第一部分 调研，评测

1 评测设计

1.1 被测对象与选型理由

本次选取三个模型，分别对应作业所建议的通用对话与推理两类。

模型	平台	类型	本次参数
DeepSeek-flash	DeepSeek 开放平台	通用对话	thinking 关闭，温度 0
Qwen3.7-Plus	阿里云百炼	通用对话	enable_thinking 关闭，温度 0
Kimi-K3	Moonshot	推理	reasoning_effort = high

1.2 统一测试条件与公平性说明

三个模型使用相同的场景、车型库、提示词、输出要求和评分公式。推荐合理性、一致性、指令遵循、信息真实性与稳定性据此评定。实验未启用联网检索，也未启用工具调用。

evaluate.py 的版本差异只涉及三项：切换各平台接口、核验运行配置，以及在 Kimi 批次中把防限速等待单独记账并从任务耗时中扣除。题目文本与车型合格判定保持不变。

未能统一的运行参数如下。Kimi 的 21 秒请求间隔用于避免接口限速，资源效率只采用扣除该等待后的任务耗时。

项目	DeepSeek-flash	Qwen3.7-Plus	Kimi-K3
思考或推理	关闭	关闭	reasoning_effort = high
输出上限	4096	4096	8192
超时	120 秒	120 秒	300 秒
请求间隔	无	无	21 秒，不计入资源效率

1.3 固定车型库

车型数据位于 data.json，来源与未核实字段见 DATA_SOURCES.md。每条记录包含年款、配置和历史厂商指导价，单位为万元，并非现价、成交价或落地价。续航须标明工况。车型库中取值为 null 的字段，模型输出亦须为 null，不得推测保值率、保险费用或月使用成本。库内无合格车型时，仅表示该资料集无解，不得表述为市场上不存在此类车型。

1.4 场景设计与事前写定的预期结果

实验设五个场景，每场景独立重复 3 次。每个模型完成 15 次任务、75 轮对话，三个模型合计 45 次任务。各场景的最终允许车型集合已在运行前写定，见 SCENARIOS.md。推荐无须列出全部合格车型。最终车型不同而均满足当时硬约束的，不记为不稳定。

场景	初始需求	预算以外的硬约束	中途变更
family	预算 10 万，家庭通勤	三厢轿车	第 2 轮改为只接受插电混动
business	预算 25 万，商务接待兼通勤	三厢轿车	第 2 轮改为只接受纯汽油
commute	预算 30 万，有充电条件，城市通勤兼周末	只考虑纯电	第 2 轮要求 CLTC 至少 500 km
change	预算 80 万，高端家庭、周末自驾	五座 SUV	第 2 轮加四驱；第 3 轮预算降到 50 万，五座和四驱保留
first_car	预算 12 万，首次购车，有充电条件	两厢车	第 2 轮改为纯电且 CLTC 至少 300 km

change 在后续轮次修改预算，用于检查上下文是否按新需求更新。用户明确修改后的需求按新约束评定，不记为前后矛盾。

1.5 评分维度、权重与判定标准

评分权重为：推荐合理性 R 35%，一致性 C 10%，指令遵循 I 15%，信息真实性 F 20%，稳定性 S 10%，资源效率 E 10%。场景分是六项的加权和，模型分是五个场景的算术平均。稳定性按严格成功次数除以尝试次数计算。严格成功须同时满足：五轮完整、最终选择合格、五轮候选均合格，且 I、F、C 均为 100。资源效率不参与成败判定。信息真实性只核验第 4 轮结构化表格中的 20 个字段，不覆盖理由中的全部表述。资源效率由五轮总耗时与累计 token 各占一半；阈值由本实验设定，并非行业标准。每个场景仅有 3 次重复，样本量较小，下文比较只适用于本次数据与实验设置。任一必需指标为 N/A 时不补 0，相应场景分及依赖该场景的模型总分亦为 N/A。

1.6 测试流程

三个模型采用同一任务流程。同一次任务保留上下文，不同任务之间重新开始对话。每次任务分为 5 轮：

1. 提出预算、用途及至少一条预算以外的硬约束。
2. 追加一条动力或配置约束。
3. 修改一条需求，或要求依据资料比较，不得编造资料未提供的数据。change 场景在本轮将预算由 80 万元调整为 50 万元。
4. 按规定 JSON 的 table 列出候选参数，未知项填 null。
5. 按最新需求给出最终车型，说明理由、一项不足以及仍需线下确认的信息。

输出须为一个 JSON 对象，键仅限 candidates、table、final、reason、no_match。提示词规定前 4 轮 final 为空，第 5 轮填写最终车型。该规定属于本实验自定的输出协议。程序提取候选列表和参数表，并按 1.5 节的规则自动评分。

关键代码一：合格候选与五轮提示

evaluate.py 先按预算及座位、车身、动力、续航等硬约束筛出候选 ID，再把同一场景拼成五轮提示。提示中写明预算按历史指导价，不是落地价。

图 1-1　evaluate.py 中的 eligible 与 stages。eligible 按预算及座位、车身、动力、续航等硬约束筛选候选 ID。stages 将场景拼成五轮提示，并写明预算按历史指导价、不是落地价。

---

2 大模型一：DeepSeek-flash

2.1 体验

自动化测试调用的是 DeepSeek 开放平台接口，模型标识为 deepseek-flash，密钥通过环境变量 DEEPSEEK_API_KEY 读取，未写入代码或正文。本节的使用记录来自网页端 chat.deepseek.com。账号在本次记录前已经注册，截图从登录后的主界面开始。网页对话没有显示模型标识，不能把它写成同一次 deepseek-flash 调用。

网页提供多轮对话。主界面左侧保留历史对话，并设有「开启新对话」。输入框下方有「深度思考」和「智能搜索」两个开关，右侧可添加附件并发送。

本次打开的是智能搜索。输入的问题是：预算 25 万元，主要用于商务接待和日常通勤，需要三厢轿车，家里没有充电条件；请推荐两三款合适的车，并说明如果出现超过 25 万元的车，为什么排除。界面显示已搜索 12 个网页。可见回答认为，没有家用充电条件时，较稳妥的是燃油或油电混动三厢轿车；后文以丰田亚洲龙（2.0L 燃油或 HEV）为例，并说明搜索结果中的宝马 3 系 325i M 运动套装指导价为 25.80 万元，超出预算约 8000 元，因后排空间和落地价不予推荐。收束建议为帕萨特 2.0T、迈腾 330TSI 和亚洲龙，并写明三者都不需要充电、25 万元以内可以落地。比亚迪汉等纯电车型被排除，理由是家中没有充电条件。

这次提问要求在 25 万元预算、无家用充电条件的前提下推荐两三款商务三厢轿车，并说明超预算车型为何排除。回答给出了帕萨特 2.0T、迈腾 330TSI 和亚洲龙，解释了宝马 3 系超出预算后不予推荐的原因，也排除了需要充电的纯电车型，因此完成了这次提问。落地价的具体构成仍未列出，不能据此核对「25 万元以内可以落地」这一句。

从这次使用看，网页检索能补充车型、指导价、车长和配置方向，范围比自动化测试里的固定车型库更宽，但来源随搜索变化，和实验使用的历史指导价不是同一套数据。界面把新对话和两个模式开关放在同一屏，历史对话留在左侧。功能上，一次对话同时完成了推荐、超预算车型的排除和汇总，并标出网页来源。准确度方面，25.80 万元被标成超出预算，指导价和落地价也被分开表述；「落地价必然超过 25 万」是模型的推断，截图正文没有给出落地价的计算过程。车长等数字来自搜索结果，本页没有逐条打开原始网页核对。回答按车型、超预算说明和一句话建议分段，问题原文也保留在对话中。整段回答较长，需要滚动才能看完。

改进上，12 个网页在界面中收成一枚来源标记，正文里的价格和尺寸不能从截图直接对应到具体网页。若每条价格或尺寸都能展开来源，核对会更直接。回答页也没有标出本次开启的是深度思考还是智能搜索，当前只能从「搜索到 12 个网页」确认使用了智能搜索。

图 2-1　DeepSeek 网页端登录后的主界面，可见新对话入口、深度思考和智能搜索

图 2-2　本次输入的购车需求，以及智能搜索返回的 12 个网页

图 2-3　回答对亚洲龙的说明、对超预算宝马 3 系的排除，以及三款车的收束建议

2.2 自动化测试

正式批次 20261109T102919158508Z 的 15 个任务均完整完成，未进行失败补跑。加权分来自该批次的 weighted_report.md，单次成败来自 weighted_tasks.csv。

场景	完整	R	C	I	F	S	E	场景分	严格成功
business	3/3	99.00	100	100	100	33.33	99.85	92.97	1/3
change	3/3	100	100	80	100	0	99.91	86.99	0/3
commute	3/3	100	100	80	100	0	99.63	86.96	0/3
family	3/3	100	100	93.33	100	66.67	99.74	95.64	2/3
first_car	3/3	100	100	80	100	0	100	87.00	0/3

五个场景的等权总分为 89.91 / 100。15 次任务中严格成功 3 次，分别为 business-3、family-1、family-2。

推荐合理性除商务场景前两次为 98.5 外，其余均为 100。15 次任务的一致性与信息真实性均为 100。信息真实性为 100 仅表示所核验的结构化字段与车型库一致，不表示自然语言理由已全部核验。总分主要受稳定性及部分场景的指令遵循影响：change、commute、first_car 的指令遵循均为 80，稳定性均为 0。

资源效率高于 Qwen3.7-Plus。business-1 五轮耗时 18.25 秒，输入 token 44631，输出 token 3197。change-1 五轮耗时 18.92 秒，输入 token 47236，输出 token 4060。资源效率按实验设定的耗时区间与 token 区间计算，上述两次均处于高分段。token 数量不表示人民币费用。

对话与评分截图位于 deepseek截图.zip，五个场景各有一轮对话图，另有任务评分和程序输出。正文选用其中数张即可。

图 2-4　business-1 第 1 轮。候选含 BMW5-2025-140，理由写明宝马 5 系 525Li M 运动套装指导价 43.99 万元，超出 25 万元，仅作参照不入选

图 2-5　change-1 第 1 轮。理由已写「最终选理想 L6 2024 款 Pro」。画面展示的是候选车型与理由，没有展示 final 字段

图 2-6　commute-1 第 1 轮。预算 30 万元、只考虑纯电。候选含 SU7-2024-STD、SU7-2024-PRO、SU7-2024-MAX、MONA-2024-620、QIN-EV-2024-510、YUAN-PLUS-2024-510

图 2-7　family-1 第 1 轮。预算 10 万元、三厢轿车。候选含 QIN-DMI-2024-55、DESTROYER-2024-55、GALAXY-L6-2025-60、FULWIN-A8-2025-70

图 2-8　first_car-1 第 1 轮。预算 12 万元、两厢车。候选为 SEAGULL-2025-405、DOLPHIN-2024-302、BINGO-2024-333、ORA-2024-401

图 2-9　DeepSeek-flash 程序输出的五场景加权分与总分 89.91，与本节表格一致

2.3 结论

在本次设置下，DeepSeek-flash 完成了全部五轮，最终推荐与表格字段大多符合要求，响应时间较短。主要失分来自结构化协议：在商务场景中，文本已说明某款车超出预算，候选数组仍保留该车型；在豪华 SUV 等场景中，前 4 轮即将最终车型写入 final。严格成功为 3/15。若调用方需要控制耗时与 token，并可在程序侧再次过滤候选，该接口较为合适。将 JSON 候选直接视为已满足约束的结果，则存在偏差。

上述结论仅适用于 2026-11-09 这一批次、deepseek-flash、思考模式关闭以及上述五个场景。

---

3 大模型二：Qwen3.7-Plus

3.1 体验

自动化测试调用的是阿里云百炼兼容接口，地址为 https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions，模型标识为 qwen3.7-plus。密钥通过环境变量 DASHSCOPE_API_KEY 读取，未写入代码或正文。本节的使用记录来自网页端 https://www.qianwen.com/。账号在本次记录前已经注册，截图从登录后的主界面开始。网页模型选择显示为「Qwen-快速」，不能把这次网页对话写成同一次 qwen3.7-plus 调用。

网页提供多轮对话。主界面分「日常」和「工作」两个入口，左侧有新对话、云空间、千问创作、对话分组和定时任务。输入框上方显示「你好，我是千问」，框内提示为「向千问提问」，并带有工作助理、AI 生视频、PPT 创作等快捷入口，右上角有 API 服务和电脑端下载。

本次使用的是「Qwen-快速」。输入的问题是：预算 30 万元，有固定充电条件，主要用于城市通勤，周末偶尔出城，只考虑纯电车；请推荐两三款合适的车，如果某款车价格或续航不符合，请说明为什么排除。界面显示「已完成分析，共参考 14 篇资料」，并列出了检索用的语句，包括「30万以内纯电车推荐 2026」「2026年 20-30万纯电轿车 续航 推荐」「特斯拉Model 3 价格 续航 2026」和「小米SU7 价格 续航」。可见回答按该场景推荐三款，并写明都在 30 万元以内：极氪 007（首推）2026 款后驱 Max 版指导价 20.39 万元（75kWh）或 22.39 万元（103kWh），续航覆盖 715–905 km；小米 SU7 标准版指导价 21.99 万元，CLTC 720 km；特斯拉 Model 3 长续航后驱版 25.95 万元，CLTC 830 km，并补充若希望留出预算余量，后驱版 23.55 万元、634 km 也可通过。

这次提问要求在 30 万元预算和固定充电条件下推荐两三款纯电车，并在价格或续航不符合时说明原因。回答列出了三款车的指导价和续航，因此完成了推荐。回答中的「2026 年 10 月销量第一」等市场表述来自检索结果，本页没有逐条打开 14 篇资料核对。

从这次使用看，网页检索能给出指导价、电池容量和续航，范围比自动化测试里的固定车型库更宽，但数字随检索变化，和实验使用的历史指导价不是同一套数据。界面把日常对话、云空间和创作入口放在同一页，模型名称显示为「Qwen-快速」。功能上，一次对话完成了资料检索和三款车的推荐。准确度方面，三款车都标出了指导价和续航；销量排序未经逐条核对。回答按编号分段，检索状态和检索语句留在问题下方。

改进上，14 篇资料收在「共参考 14 篇资料」之后，正文中的指导价和续航不能从截图直接对应到某一篇资料。若每条价格或续航都能展开来源，核对会更直接。

图 3-1　千问网页端登录后的主界面，模型显示为 Qwen-快速

图 3-2　本次输入的纯电车需求，以及参考 14 篇资料后的检索语句

图 3-3　回答推荐的极氪 007、小米 SU7 和特斯拉 Model 3

3.2 自动化测试

正式批次 20261109T105813490129Z 的 15 个任务均完整完成。下表场景分来自 weighted_report.md，与运行截图中的 94.69 一致。

场景	完整	R	C	I	F	S	E	场景分	严格成功
business	3/3	99.38	100	100	100	33.33	57.17	88.83	1/3
change	3/3	100	100	100	100	100	57.00	95.70	3/3
commute	3/3	100	100	100	100	100	51.63	95.16	3/3
family	3/3	100	100	100	100	100	68.96	96.90	3/3
first_car	3/3	100	100	100	100	100	68.51	96.85	3/3

五个场景的等权总分为 94.69 / 100。15 次任务中严格成功 13 次。未达严格成功的两次均出现在商务场景，即 business-1 与 business-3；business-2 达到严格成功。change 场景三次均达到严格成功，其中包括将预算由 80 万元调整为 50 万元的任务。

15 次任务的指令遵循均为 100，未出现 DeepSeek-flash 提前填写 final 的情况。一致性与信息真实性亦均为 100；信息真实性同样只覆盖已核验的表格字段。

资源效率为六项中最低，场景均值约为 51–69。business-1 五轮耗时 133.33 秒，输入 token 60527，输出 token 7423。按同一阈值，任务耗时超过 80 秒或 token 较高时，资源效率下降。该记录表明本次调用耗时更长、上下文更长，不能据此换算为费用。

现有截图包括加权总分表、weighted_report.py 的终端输出以及 weighted_tasks.csv。逐轮对话截图尚未单独整理，原文见该批次各任务的 conversation.md 与 turn-N.json。

图 3-4　Qwen3.7-Plus 加权报告。五个场景分与总分 94.69 与本节表格一致

图 3-5　运行 weighted_report.py 后的终端输出，总分 94.69

图 3-6　weighted_tasks 中 15 次任务的分项。business-1 与 business-3 的 success 为 0

3.3 结论

在 DeepSeek-flash 与 Qwen3.7-Plus 均关闭思考模式的两次运行中，Qwen3.7-Plus 的稳定性更高：指令遵循未降至 80，需求变更场景三次均达到严格成功，总分 94.69，高于 DeepSeek-flash 的 89.91。分差主要来自稳定性与指令遵循；两项模型均可给出满足硬约束的最终推荐。商务场景中，Qwen3.7-Plus 同样将超预算车型保留在候选数组中，故严格成功为 13/15。其单次任务耗时更长，token 也更多。若系统需要减少对输出格式的补救，本次实验中 Qwen3.7-Plus 更为合适；若单次调用需控制在约 20 秒，DeepSeek-flash 更为合适。上述比较限于已得出五场景总分的两个模型，不包括 Kimi-K3。

---

4 大模型三：Kimi-K3

4.1 体验

自动化测试调用的是 Moonshot 开放平台接口，地址为 https://api.moonshot.cn/v1/chat/completions，模型标识为 kimi-k3，reasoning_effort 设为 high。密钥通过环境变量 MOONSHOT_API_KEY 读取，未写入代码或正文。本节的使用记录来自网页端 https://www.kimi.com/zh。账号在本次记录前已经注册，截图从登录后的主界面开始。网页对话没有显示 kimi-k3。主界面有「快速 / 进阶」，回答页没有再次标出档位，不能把这次网页对话写成同一次 kimi-k3 调用，也不能判断回答使用的是哪一档。

网页提供多轮对话。主界面中央为 Kimi 标识和输入框，框内提示可通过「/」唤起插件和技能，右侧有「快速 / 进阶」、语音输入和发送。输入框下方有选择项目、插件和「使用客户端」。页面还列出 3D Make、PPT、深度研究、文档、构建应用、表格和设计等入口，底部有「探索灵感」。

本次对话标题为「12万两厢车推荐」。输入的问题是：预算 12 万元，年轻人第一次买车，家里有充电条件，希望两厢车、停车方便；请推荐两三款合适的车，如果某款车价格或车身不符合，请说明为什么排除。回答先把条件归纳为纯电小型或紧凑型两厢车，界面显示正在搜索网页；完成后标明「使用 2 个工具」，并写「查完 2026 年 11 月最新行情」。可见推荐三款：吉利星愿 480km 探索+版约 9.48 万元，限时权益价约 9.18 万元，CLTC 480 km，车长 4135 mm；比亚迪海豚智驾版 9.98–12.58 万元，建议 405 km 中高配，落地约 10.5–11 万元，CLTC 405/510 km；蔚来萤火虫自在版整车 11.98 万元，另写 BaaS 租电 7.98 万元、每月 399 元，CLTC 420 km，车长 4003 mm。表格下方标出价格来源，可以辨认的有新华网和 sina.cn。回答接着写明，萤火虫自在版整车价为 11.98 万元，加上保险和上牌后落地约 12.8–13 万元，略微超出预算。

排除部分标题为「为什么排除其他热门候选」。比亚迪海鸥标价 6.99–8.59 万元，回答认为价格和两厢形式符合，但将其视为 A00 级微型车，并写出车长 3.78 米、动力和装载余量不足。五菱缤果 PLUS 被排除，理由是小型 SUV 造型，不符合两厢轿车。特斯拉 Model Q 被排除，理由是预计 14 万元起售且超出预算，并写明 2026 年底才上市。大众 ID.3 未被排除，被标为备选，页面写优惠后落地约 11.5 万元、续航 451 km。收束建议把星愿对应省钱、海豚对应均衡、萤火虫对应个性化配置，并建议下单前试驾。推荐理由一列在截图右侧没有完整入画。

这次提问要求在 12 万元预算、家中可充电、两厢且便于停车的前提下推荐两三款车，并说明价格或车身不符合的车型为何排除。回答给出了星愿、海豚和萤火虫，并写了海鸥、缤果 PLUS 和 Model Q 的排除理由，因此完成了这次提问。落地价没有计算过程，不能据此核对「10 万落地」「10.5–11 万落地」和「12.8–13 万」。萤火虫仍列在推荐三款中，同时正文写明其上牌后略超预算。行情月份、车长和上市时间来自检索，本页没有逐条打开来源核对。

从这次使用看，网页检索和工具调用能补充在售价格、续航和车长，范围比自动化测试里的固定车型库更宽，但数字随检索变化，和实验使用的历史指导价不是同一套数据。自动化测试不使用联网搜索；这次网页回答使用了网页搜索和 2 个工具。界面把输入、插件以及文档、表格等入口放在同一页。功能上，一次对话完成了检索、三款推荐、排除说明和收束建议，问题原文保留在对话中。准确度方面，三款车都标出了版本和价格；海豚的标价区间上沿为 12.58 万元，回答另行收窄到 405 km 中高配；萤火虫的整车价与落地价被分开表述。排除说明位于推荐表之后，需要继续向下滚动。

改进上，价格来源收成表格下方的站点标记，正文里的价格和车长不能从截图直接对应到具体网页。若每条价格或尺寸都能展开来源，核对会更直接。回答页没有标出本次使用的是「快速」还是「进阶」。整车价在预算内、落地价超出预算的车型，若在推荐表中直接标出，比对预算会更直接。

图 4-1　Kimi 网页端登录后的主界面，可见插件入口、快速与进阶以及文档、表格等功能

图 4-2　本次输入的 12 万元两厢车需求，以及正在搜索网页

图 4-3　回答推荐的吉利星愿、比亚迪海豚和蔚来萤火虫

图 4-4　回答对海鸥、缤果 PLUS、Model Q 的排除说明，以及 ID.3 的备选说明

4.2 自动化测试

正式批次 20261109T132351578978Z 的 15 个任务均完整完成，未出现 HTTP 429。加权分来自该批次的 weighted_report.md。评分规则规定：某一必需指标为 N/A 时不补 0，相应场景分及依赖该场景的模型总分亦为 N/A。

场景	完整	R	C	I	F	S	E	场景分	严格成功
business	3/3	64.67	N/A	66.67	N/A	0	64.56	N/A	0/3
change	3/3	66.67	N/A	66.67	N/A	33.33	58.81	N/A	1/3
commute	3/3	100	100	93.33	100	66.67	53.92	91.06	2/3
family	3/3	98.00	100	81.67	100	0	60.04	82.55	0/3
first_car	3/3	0	N/A	20.00	N/A	0	70.78	N/A	0/3

五个场景的等权总分为 N/A，状态为 insufficient_data。未形成场景分的是 business、change 与 first_car。同一场景中任一任务的一致性或信息真实性为空时，该场景不计算总分。first_car 的三次运行，以及 business-2、change-3，因 Markdown 代码块无法解析；business-3 可以解析，但 facts_total 为 0，信息真实性仍为空。15 次任务中严格成功 3 次，分别为 change-2、commute-1、commute-2。

可与另外两个模型比较场景分的仅有通勤与家庭。通勤场景中，Kimi-K3 为 91.06，DeepSeek-flash 为 86.96，Qwen3.7-Plus 为 95.16。家庭场景中，三者分别为 82.55、95.64 与 96.90。

commute-1 计入评分的五轮耗时为 182.05 秒，输入 token 45821，输出 token 7557。first_car-1 计入评分的五轮耗时为 86.52 秒，另行记录的调度等待为 17.77 秒。Kimi 批次设有 21 秒请求间隔；该等待已从任务耗时中扣除，不进入资源效率。

4.3 结论

Kimi-K3 本次启用高强度推理。解析成功时，通勤场景得分为 91.06，需求变更场景有 1 次严格成功。五个场景的等权总分因数据不足而未给出。first_car 的三次运行均因代码块无法解析，推荐合理性与指令遵循分别为 0 和 20，场景分空缺。商务场景另有一次将表格字段误作新增硬约束。就本次记录而言，该模型可作为推理模型的对照；在未增加格式容错时，其输出尚不能直接接入自动购车流程。每场景样本量为 3。题目、车型库与合格判定与另外两个模型相同；输出长度上限和超时设置不同，防限速等待不计入资源效率。

---

5 三个模型的对比

指标	DeepSeek-flash	Qwen3.7-Plus	Kimi-K3
模型总分	89.91	94.69	N/A
严格成功	3/15	13/15	3/15
思考 / 推理	关闭	关闭	reasoning_effort = high
通勤场景分	86.96	95.16	91.06
家庭场景分	95.64	96.90	82.55
商务场景 S	33.33	33.33	0
需求变更场景 S	0	100	33.33
单次任务耗时	business-1：18.25 秒	business-1：133.33 秒	commute-1：182.05 秒

图 5-1　三个模型的场景分与模型总分。每个场景 3 次。Kimi-K3 未形成分数的项目留空，不以 0 分绘制。资源效率采用实验自定阈值，Kimi 的防限速等待已从任务耗时中扣除。结论限于本次实验设置。

三个模型的一致性与信息真实性同时有分数的，只有通勤和家庭。图 5-2 取这两个场景各项分数的算术平均。推荐合理性、一致性、信息真实性都在 99 以上。可见差距在稳定性、指令遵循和资源效率。商务、需求变更和首购没有计入，本图也不代替模型总分。

图 5-2　通勤与家庭两个场景的六项均分。DeepSeek-flash 为 R 100、C 100、I 86.67、F 100、S 33.34、E 99.69。Qwen3.7-Plus 为 R 100、C 100、I 100、F 100、S 100、E 60.30。Kimi-K3 为 R 99.00、C 100、I 87.50、F 100、S 33.34、E 56.98。每项是两个场景的算术平均。Kimi-K3 的模型总分仍为 N/A。

在已得出模型总分的两次运行中，Qwen3.7-Plus 高于 DeepSeek-flash。Kimi-K3 因总分为 N/A，不纳入该排序。三个模型均不能仅凭最终一轮判断成败：DeepSeek-flash 的候选与最终车型可以均合格，仍会因提前填写 final 而失败；Qwen3.7-Plus 的最终推荐为帕萨特（PASSAT-2025-330，历史指导价 18.85 万元），仍因首轮候选不合格而失败；Kimi-K3 有三次任务的五轮均完整返回，但 JSON 外包裹了代码块，候选准确率记为 0。

---

6 失败与边界案例

6.1 与 6.2 依据 DeepSeek 批次的原始记录及 deepseek失败案例分析.md。Qwen 商务场景属于同类现象，列于 6.1 之后，不另计为独立错误类型。原因分析仅依据可见输出；记录不能证实的模型内部机制标为推测。

6.1 商务场景的文字和候选数组不一致

business 第 1 轮要求历史指导价不超过 25 万元，车型为三厢轿车。冻结车型库中，宝马 5 系 525Li M 运动套装（BMW5-2025-140）的指导价为 43.99 万元，不应进入合格候选。

business-1 第 1 轮的 candidates 含 4 个 ID，其中之一为 BMW5-2025-140，其余 3 个属于当轮允许集合，合格比例为 3/4。理由同时写明该宝马车型超出 25 万元，仅作参照、不予入选。文本与结构化字段不一致。该记录不能证明模型未识别超预算，也不能证明最终选择为宝马。该任务其余 4 轮的候选检查通过，五轮候选平均为 95%，最终选择合格，R = 0.7×100 + 0.3×95 = 98.5。

该现象出现于 business-1 与 business-2，business-3 未出现，频次为 2/3。商务场景的严格成功为 1/3。

Qwen3.7-Plus 的 business-1 与 business-3 亦属此类。business-1 首轮 15 个候选中有 12 个合格，不合格车型包括宝马 5 系 525Li（43.99 万元）、宝马 5 系 530Li（48.59 万元）和奔驰 E 级（49.98 万元）。文本已指出宝马 5 系和奔驰 E 级超出预算。最终推荐仍为帕萨特，R = 98.8，严格成功为 0。business-3 首轮 9 个候选中有 8 个合格，仍包含指导价 43.99 万元的宝马 5 系 525Li，R = 99.33，严格成功为 0。business-2 未出现该现象。因此，Qwen3.7-Plus 在该场景 3 次中有 2 次出现同一类错误，而非两种不同错误。

一种可能是模型将用于对照的车型写入了候选字段，提示词对“参照车型”与“合格候选”的区分也不够明确。以上为推测。记录能够确认的是：候选数组包含超预算 ID，理由文本又将该车排除。

6.2 豪华 SUV 场景提前填写最终车型

change 的初始条件为预算 80 万元、五座 SUV；第 2 轮增加四驱，第 3 轮将预算降至 50 万元，其余要求保留。提示词规定前 4 轮 final 为 null。用户修改预算后，按新预算筛选不记为前后矛盾。

change-1 第 1 轮至第 4 轮均将 L6-2024-PRO 写入 final，阶段输出检查未通过。第 3 轮已按新预算移除历史指导价 61.5 万元的宝马 X5，第 5 轮最终推荐理想 L6 Pro。五轮候选合理性为 100%，最终推荐合格，一致性为 100%，指令遵循为 80%，严格成功为 0。前 4 轮各扣除阶段输出的 5 分，合计 20 分。change-1、change-2、change-3 均出现该现象，频次为 3/3。

commute-1 的 score.json 显示，前 4 轮 instruction 为 false，第 5 轮为 true；第 1 轮四项检查中仅“阶段输出”为 false，候选约束通过。commute 与 first_car 的场景指令遵循均为 80，分数模式与本案例相同。若将其归为同一类错误，可引用这两处的 turn-1.json。本版不另立案例。

该结果说明模型未遵守本实验的输出协议，不能据此认为模型无法完成选车，也不能据此认为模型遗漏了预算变更。作业要求包含初步推荐与最终选择，并未禁止提前表达当前倾向。该项扣分来自本实验自定的 JSON 协议。

一种可能是，模型倾向于每轮给出当前首选，从而将“当前倾向”与“最终决策字段”写成同一值。提示词同时要求持续推荐，并要求前 4 轮 final 为空。内部机制无法由本次输出确认。

关键代码二：非最终轮不得填写最终车型

scoring.py 在评分循环里检查阶段输出。任务还没到最终轮时，final 须为 None。

图 6-4　scoring.py 的评分循环。非最终轮的阶段检查以 final 为 None 作为条件，该行后半段在截图右侧被裁切

6.3 Kimi 在首辆车场景三次都无法解析

first_car 的预算为 12 万元，车型为两厢；第 2 轮起改为纯电，且 CLTC 至少 300 km。预期合格车型包括海鸥、海豚、缤果与好猫。协议要求每轮只返回一个 JSON 对象，不得在 JSON 外添加 Markdown 代码块。

关键代码三：严格 JSON 解析

evaluate.py 用 json.loads 解析模型原文。解析失败时记为 Invalid JSON (strict parsing, no repair)，不去除代码块标记。

图 6-5　evaluate.py 使用 json.loads 解析模型原文。解析失败时记为 Invalid JSON (strict parsing, no repair)，不去除代码块标记

first_car-1、first_car-2、first_car-3 的五轮输出均包裹于 ```json。解析程序按严格 JSON 处理，不去除代码块标记，因而无法进入候选约束与事实核验。三次记录一致：任务完整，R = 0，I = 20，C 与 F 为空，严格成功为 0，场景分因此为 N/A。就人工阅读而言，回答中的候选 ID 可能符合要求；自动化流程仅能判定为格式失败。后续轮次延续了该格式，故整项任务失败，而非单轮偶发。

图 6-1　first_car-1 第 5 轮。程序提示无法按规定结构解析，原文以 ```json 开始，候选含 SEAGULL-2025-405、DOLPHIN-2024-302、BINGO-2024-333、ORA-2024-401

图 6-2　同一次任务的评分：推荐合理性 0.00，指令遵循 20.00，一致性与信息真实性为 N/A。原文中的 final 为 SEAGULL-2025-405

图 6-3　first_car-2 第 1 轮同样提示无法按规定结构解析，原文以 ```json 开始

6.4 Kimi 把表格字段当成新的硬约束

business-3 在第 4 轮之前的有效硬约束为：指导价不超过 25 万元、三厢、纯汽油。第 4 轮仅要求将驱动、座椅加热等字段列入 table，未知项填 null。用户未要求四驱，也未要求座椅加热必须为标配。

模型在该轮输出“新增硬约束：前排座椅加热必须为 standard、需要 AWD”，随后将帕萨特、凯美瑞、雅阁和天籁全部排除，并判断库内无解。第 1、2、3、5 轮候选合格；第 5 轮写明用户未曾提出上述两项约束，最终推荐 PASSAT-2025-330。weighted_tasks.csv 中本次 R = 94，C = 100，I = 100，严格成功为 0，F 为空。因此，该任务并非持续丢失上下文，而是第 4 轮将“列出规定字段”理解为“这些字段必须达到指定取值”。若仅检查最终推荐，将无法发现该轮错误。

---

7 改进方案与备选比较

针对 6.1，在程序侧增加候选过滤：每轮由程序保存当前硬约束；模型返回后，将不在允许集合内的 ID 从展示用候选中剔除，并另行保存“模型原始候选”。评分仍依据原始输出，过滤后的列表不回写为评分结果。

备选方案为仅修改提示词，强调参照车型不得进入 candidates。当前提示词已要求只输出合格候选，而 DeepSeek-flash 与 Qwen3.7-Plus 仍在商务场景将超预算 ID 写入数组。因此，仅修改提示词尚未经过本次实验的验证。过滤由程序执行，展示列表与自动核验使用同一规则，不依赖模型在后续轮次中保持同一表述。

验证方法为：冻结当前车型库、场景和评分规则，三个模型均重跑商务场景 3 次。原始分仍按未过滤的 JSON 计算，同时记录过滤后候选的合格比例，以及用户可见列表中仍含超预算车型的数量。若仅对某一个模型放宽解析，不能作为改进生效的证据。

6.2 不宜用同一过滤处理。该问题是最终字段填写过早，而非候选超出预算。若另行处理，可将前 4 轮的 final 在评分端记为“当前倾向”，指令分仍按协议扣除，以免将协议偏差记为选车错误。本版不实现该方案。

6.3 需另行处理，且不得只对 Kimi-K3 放宽标准。正式分数仍按原始字符串解析；另设“去除代码块后再解析”的对照指标。对照指标不替换原始成绩。三个模型使用同一版解析重新测试后，方可判断格式容错是否改变模型之间的可比性。

---

8 用户采访

8.1 DeepSeek 网页

受访者为软件工程专业三年级学生。本次使用 DeepSeek 网页端，用时 20 分钟。题目为预算 10 万元以内、家里使用、三厢轿车。以下按采访时的提问记录，答语为受访者陈述，不是事后补写的原因推测。

问：你的专业是什么？平时怎样使用这类产品？

答：我是软件工程大三。平时写作业会用千问和 DeepSeek，查资料多一些，不怎么拿来做决定。

问：为什么选择你来使用？你自己的需求是什么？

答：找我是因为我也是这个专业。我自己暂时不买车，只能按给出的题目使用。这次要看懂的条件是 10 万元以内、家里用、三厢。

问：打开之后用了哪些功能？

答：我直接在输入框提问，没有上传附件，也没有点深度思考。回答过程中页面显示参考了资料，我没有逐篇点开。

问：这次提问有没有得到可用的推荐？

答：得到了推荐，列出了几款插电混动轿车，价格都标在 10 万元附近。我当时没法核对是不是指导价，只能看它有没有按三厢和预算来写。

问：使用过程中哪里不清楚？

答：回答比较长，要往下翻才能看完排除理由。价格写了，但没标每一条价格来自哪一篇资料，我不确定能不能信。

问：哪一部分比较清楚？

答：问题还留在对话上面，推荐按车型分开写，预算和车身形式都能在回答里找到。

问：你最想改哪一处？

答：我希望每条价格旁边直接给来源。现在只写参考了若干篇资料，我还得自己判断哪句是检索来的、哪句是它的推断。

图 8-1　受访者正在使用 DeepSeek 网页，并指向屏幕上的对话

8.2 千问网页

受访者同为软件工程专业三年级学生。选择此人，是因为他平时与大语言模型打交道比较多。本次使用千问网页，用时 30 分钟，看的是第 3.1 节那次提问。页面上的模式为 Qwen-快速；推荐里提到极氪 007 和小米 SU7，价格在 30 万元以内；页面显示参考了 14 篇资料。以下按六个问题记录，答语为受访者陈述。第 3 问至第 6 问里关于表格、无车可选、等待提示和新增功能的话，是受访者希望页面怎样做，不是这次已经发生的情况。

问：用同样的购车需求再试千问时，你最先看什么？推荐有没有一直守住你的条件，理由能不能对上页面上的资料？

答：我先看价格和是不是纯电，续航往后放。极氪 007 和小米 SU7 的价钱都在 30 万里面，这一条对上了。理由和那 14 篇资料对不上，页面只写参考了资料，我点不进每一条价格。

问：页面上的型号和模式，你能不能判断该选哪一个？你希望它怎样说明速度、费用和适用场合？

答：能看见 Qwen-快速，但旁边没有写这一档偏快还是偏完整，也没有写要不要钱。我希望就在型号旁边用一句话写清：更快、更慢、适不适合拿来对价格。

问：如果回答把价格、座位、动力等参数排成表，对你核对有没有帮助？没有来源或页面上没有的数据，你希望它怎么写？

答：排成表会好核对，车名、指导价、续航各一列就够。页面上没有的数，写成“资料里没有”，不要留一个看起来像真的空格，也不要自己估一个落地价。

问：如果后加的条件让现有车型都选不出来，你希望它怎样说明？哪些条件可以建议调整，哪些必须等你自己定？

答：选不出来就直接说库里或这次条件下没有，把卡住的那一条单独标出来。预算这种硬条件让我自己改。它最多提一句“如果放宽续航，还有哪几款”，不能替我把条件改掉再继续推荐。

问：回答快一些，和理由更完整一些，你更倾向哪一边？等待时希望看到什么提示？

答：我更想要理由完整。等的时候写清楚在查什么，比如正在核对指导价，不要只转圈。快一点但后半段对不上，我还是得重看。

问：用完这一次，你最希望千问增加什么功能？

答：最想加的是回答页上的对照表，并且每条价格能点开来源。模型名称在出结果之后再显示一次。

图 8-2　受访者正在使用千问网页，屏幕上可见带配图的结果

---

第二部分 分析

在第一部分的评测中，我们围绕经济型家用车、商务轿车、纯电通勤车、豪华 SUV 和年轻人首辆车五类购车场景，对 Qwen3.7-Plus、DeepSeek 和 Kimi-K3 进行了多轮对话测试。除了关注最终推荐的车型是否符合需求，我们还考察了模型对预算变化的理解、参数对比的准确性、输出格式以及多次运行时的稳定性。

通过这次实践，我们发现，大模型已经能够较好地理解日常生活中的复杂需求，并帮助用户整理信息、比较方案。但当它真正参与购车决策时，仅仅给出一段看起来合理的回答还不够，系统还需要保证推荐条件正确、车型数据可靠、每轮结果能够衔接。结合《构建之法》中的相关知识，我们进一步从软件工程、产品市场和未来规划等方面对本次评测进行分析。

9 程序、软件与软件企业的三个层次

《构建之法》提出了“程序＝算法＋数据结构”“软件＝程序＋软件工程”“软件企业＝软件＋商业模式”的认识框架。在本次评测中，我们既能从三个大模型平台的服务方式理解这三个层次，也能结合自己搭建的购车测试系统分析它们在实际开发中的作用。

（1）程序层面：算法、数据结构与上下文管理

从模型架构来看，Qwen、DeepSeek 和 Kimi 都属于以 Transformer 技术路线为基础的大语言模型，通过对 Token 序列和上下文信息的处理生成回答。模型能够识别用户提出的预算、车型类别和个人偏好，而在具体购车业务中，还需要由应用程序将这些要求转化为明确的筛选规则。相比于单纯讨论模型内部结构，我们更关注如何将模型能力与可检查的程序逻辑结合起来。

在本次测试中，我们整理了包含 27 款具体车型配置的固定数据，分别记录车型编号、年款、配置、历史指导价、动力类型、车身形式和尺寸等参数。测试程序通过 JSON 保存车型信息和用户条件，利用预算、座位数、动力形式、车身类型、续航等字段筛选合格车型，再将模型返回的候选编号与筛选结果进行比较。这样，模型负责理解需求和组织推荐理由，程序负责判断明确的硬约束，两者各自承担不同的工作。

上下文管理是多轮购车决策中尤其重要的一部分。程序按照系统消息、用户消息和模型回答的顺序保存同一任务内的对话，并在下一轮请求中继续传递这些信息；不同的重复测试则从新的会话开始。例如，在豪华 SUV 场景中，用户先提出 80 万元的预算，之后增加四驱要求，再将预算调整为 50 万元。程序按照最新条件计算允许集合，同时保留之前没有取消的五座 SUV 和四驱要求，从而检查模型是否正确理解需求变化。

为了方便自动处理，我们还规定模型每轮返回包含 candidates、table、final、reason 和 no_match 五个字段的 JSON 对象。程序先解析返回内容，再核对字段类型、候选编号、表格数据和推荐阶段。这一过程体现了参数解析在模型应用中的作用：即使自然语言回答看起来完整，后续程序仍需要能够准确提取和使用其中的数据。本次正式测试没有启用模型工具调用，未来若接入车型查询、价格计算等工具，也可以沿用相同思路，对工具名称、输入参数和返回结果进行校验。

（2）软件工程层面：服务接口、评测工具链与版本管理

一个程序能够完成单次问答，只是软件开发的起点。真正面向用户使用时，还需要考虑不同接口如何接入、运行记录如何保存、问题如何定位，以及功能修改后如何验证质量。

三个平台都提供了可供开发者使用的模型接口和接入文档。我们的测试系统为不同模型配置各自的接口地址和调用参数，在公共流程中统一组织请求、读取响应，并记录耗时和 Token 消耗。这样，当需要切换模型时，主要调整接入配置，而场景设计、数据校验和评分逻辑可以继续复用。这种方式也体现了开放平台生态的价值：模型平台提供基础智能能力，开发者可以在其上构建自己的业务程序。

围绕自动化评测，我们将流程划分为场景准备、多轮请求、结果解析、约束校验、分项评分和报告输出几个环节。程序能够保存原始对话、结构化结果、CSV 统计和评分报告，并在运行时保留数据、提示词与评分规则的版本快照。通过这些记录，我们可以比较不同轮次和不同批次的表现，也可以在调整提示词或评分规则后重新检查结果，使实验更容易复现。

在团队协作和后续维护方面，我们认为还应将接口格式、数据字段和评分口径整理成统一文档，并通过代码版本管理保存修改记录。模型接口升级时，先进行小规模连通测试和回归测试，再开展完整评测；不同成员分别负责数据、接口、评分和结果整理时，也可以围绕统一的数据结构开展协作。对未来正式产品而言，还可以进一步建立统一的模型接入层，集中管理鉴权、超时、重试和模型切换，降低对单一服务接口的依赖。

（3）商业层面：调用成本、服务模式与竞争优势

从商业层面来看，大模型不仅是一项技术能力，也是一种可以持续向开发者和企业提供的服务。Qwen、DeepSeek 和 Kimi 都面向应用开发提供模型调用能力，模型平台的竞争除了回答效果，还包括接入门槛、调用成本、服务稳定性和生态建设。

免费试用额度能够帮助开发者降低前期验证成本，使学生团队或小型项目更容易开始实验。正式运行时，模型 API 通常按照输入和输出 Token 的消耗计费；随着会话轮次增加，重复传递历史消息和车型数据也会增加使用成本。因此，我们在自动化测试中记录每项任务的 Token 消耗和运行时间，并把资源效率纳入评测指标。在高频使用的购车咨询产品中，模型调用费用会直接影响后续运营成本。

不同平台还可以通过不同能力档位形成差异化服务。例如，基础模型适合高频问答，计算资源需求更高的推理模型可以提供面向复杂任务的服务；部分平台还采用开源模型与云服务并行发展的策略，开放模型权重与云端托管 API 相结合，为企业提供自行部署或直接调用的选择。对使用者来说，是否需要更强的推理能力、是否重视数据部署方式，以及能否承担长期调用费用，都会影响最终选型。

如果未来将本次测试系统发展为智能购车助手，我们希望把自然语言交互、车型数据管理和严格条件校验组合成完整服务。产品的竞争优势不只在于模型能否生成推荐理由，更在于能否持续提供可靠的车型比较、清楚的排除原因和方便的需求调整。通过以上实践，我们认识到，算法和数据结构实现基本功能，软件工程保障系统质量，而商业模式决定产品如何长期服务用户。

10 开发时间估计与任务安排

《构建之法》第 8.6 节强调，软件项目需要结合任务内容、开发难度和人员投入进行工作量估计。本次大模型评测作业从 11 月 6 日发布到 11 月 11 日截止，时间比较紧张，因此我们更重视任务之间的衔接和人员的并行协作。相比于开发一个完整的商业化购车平台，这次实践的主要目标是搭建能够重复运行的评测程序，完成车型数据准备、模型接入、自动评分、结果分析以及博客整理。

根据这些工作内容，我们将任务划分为七个部分，并估算团队完成同等规模作业所需的投入。这里使用“人时”表示各成员投入时间的合计，多个任务可以同时推进。

工作阶段	主要工作内容	预计投入（人时）	计划安排
需求分析与任务分工	明确评测目标、五类购车场景、统一规则和成员职责	3 h	11 月 6 日
车型数据与提示词准备	整理车型配置、预算等硬约束，统一多轮提示词	6 h	11 月 6—7 日
模型接口与评测流程	接入三个大模型，完成连续对话、结果记录和批量运行	8 h	11 月 7—8 日
自动评分与结果校验	实现候选检查、格式解析、分项评分和结果汇总	9 h	11 月 7—9 日
正式测试与问题排查	完成重复测试，检查异常响应和失败案例	7 h	11 月 9—10 日
数据分析与图表整理	统计模型表现，制作对比表格和可视化结果	5 h	11 月 10 日
博客撰写与材料整理	整合评测结论、工程分析、截图、链接并检查发布效果	7 h	11 月 10—11 日
合计	核心任务预计投入	45 h	六天内交叉推进

考虑到模型接口调用、脚本调试和博客排版可能需要额外调整，我们再预留约 5 人时的机动时间，团队整体预计投入约 50 人时。由于车型数据准备、接口开发和博客资料整理能够由不同成员并行处理，实际完成周期可以明显短于将全部工作交给一人顺序完成的时间。

在具体安排上，我们将车型数据和评分规则放在前面，先保证三个模型使用统一的测试条件，再完成接口调用与自动评分。随后集中运行实验、整理失败案例和统计结果，最后完善博客中的图表、文字分析和材料链接。这样的顺序能够尽早发现数据和程序中的问题，也可以减少临近提交时反复修改评分规则的情况。

通过本次实践，我们认识到，短周期的软件工程任务更需要明确优先级。核心测试流程、原始记录和评分结果直接关系到作业质量，应当优先完成；图表样式和文字表达则在结果稳定后统一整理。同时，合理分工并不意味着各做各的，而是需要提前确定接口格式和数据字段，让不同成员的工作能够顺利整合。

11 同类产品对比与选型建议

本次我们选择 Qwen3.7-Plus、DeepSeek 和 Kimi-K3 作为评测对象，希望比较它们在实际购车决策中对用户条件的理解能力，以及多轮对话、结构化输出和资源消耗方面的表现。

Qwen3.7-Plus 和 DeepSeek-flash 分别完成了五个主场景、每个场景三次独立运行，共 15 项五轮任务。根据本次自动评分结果，Qwen3.7-Plus 严格成功 13/15，加权平均得分 94.69 分；DeepSeek-flash 严格成功 3/15，加权平均得分 89.91 分。Kimi-K3 的正式批次 20261109T132351578978Z 同样完成了 15 项五轮任务，其中 3 项达到严格成功标准。该批次五个场景的等权总分仍为 N/A，不与 94.69 和 89.91 排序。结合各模型的具体问题，我们整理了不同使用需求下的选型考虑。

模型	本次评测中的表现	需要重点改进的方面	适合的应用方向
Qwen3.7-Plus	多轮推荐的严格成功率较高，结构化输出较稳定	个别轮次出现超预算候选	更重视推荐流程完整性和条件遵循的购车服务
DeepSeek-flash	资源效率指标较好，能够根据更新后的预算调整候选	部分场景提前填写最终车型，或出现文字与候选不一致	调用频繁、关注运行效率，同时配有独立规则校验的应用
Kimi-K3	能够完成部分推荐任务，并在个别错误后恢复正确的需求理解	输出格式和展示字段的语义理解存在波动	需要进一步优化人机交互和接口容错的购车原型

如果当前项目优先追求多轮任务的稳定完成，我们更倾向于先采用 Qwen3.7-Plus，并在候选进入展示用推荐前增加程序校验。评分仍依据模型原始输出。如果项目需要频繁调用模型，DeepSeek-flash 在本次测试中的资源效率具有一定吸引力，可以配合明确的阶段控制和结果校验使用。Kimi-K3 的模型总分为 N/A，不能与 94.69 和 89.91 排序。它的记录说明，选型时还需要关注输出格式和运行间的波动，而不只是某一次回答是否合理。

这次比较也改变了我们对模型选型的理解。大模型的优势不必完全相同，产品应根据用户需求决定取舍：面向消费决策的功能优先保证条件正确和推荐可解释；面向高频业务的功能则还要考虑 Token 消耗、响应时间以及接口维护成本。后续我们可以围绕这些要求持续进行回归测试，为模型升级和切换提供依据。

12 软件工程方面的建议

通过本次购车决策评测，我们认识到，大模型能够生成推荐结果，并不代表推荐系统就具备了稳定运行的能力。对于涉及预算、配置和用车条件的应用，除了模型本身的理解能力，还需要通过接口管理、规则校验、数据维护和自动化测试来保障结果质量。结合实际测试中发现的问题，我们主要从以下几个方面考虑后续改进。

（1）统一模型接入与输出校验

不同模型接口在请求参数、响应格式和异常提示方面存在差异。我们希望将这些差异集中到统一的模型接入模块中，按照相同的数据结构向后续程序提供结果，并为请求设置超时、必要的重试和错误日志。对于结构化推荐结果，程序需要先校验 JSON 是否能够解析，再检查字段类型、车型编号和参数是否完整。正式分数仍按原始字符串解析，不在评分前修复格式，也不因重新请求改写原始成绩。可以另行记录去除代码块后再解析的对照结果，并保留异常日志。对照指标不替换原始成绩，三个模型使用同一规则。

（2）加强购车条件与多轮对话状态管理

在用户连续修改需求的过程中，我们计划由程序单独维护当前有效的硬约束、个人偏好和信息展示要求。预算、动力、车身形式等明确条件由规则程序负责判断，模型主要用于理解自然语言、整理比较理由。与此同时，将阶段性推荐与最终选择分别管理，使模型在需求收集、参数比较和最终确认等不同阶段按照统一规则输出，减少条件混淆和过早给出最终结果的问题。

（3）完善数据维护、异常处理与回归测试

车型数据的价格口径、配置版本和更新时间都会影响推荐结果。我们希望为关键参数保留数据来源和更新时间，对未知字段采用统一的空值处理方式，并将车型数据、场景提示词和评分规则一起纳入版本管理。针对重复测试和边界场景，可以建立固定的回归测试集，在更新模型或修改程序后，继续比较候选合格比例、格式解析通过率、严格成功次数及运行成本，观察改进效果。

为了使工程改进更有针对性，我们将实际应用中需要重点关注的环节整理如下。

问题来源	需要关注的情况	工程改进方向
模型输出	文字理由与候选列表不一致，或把展示要求理解为硬约束	对候选结果再次校验，区分硬约束、偏好和展示字段
车型数据	历史指导价与当前成交价不同，部分配置参数缺失	标注数据来源、日期与价格口径，未知字段保持空值，定期更新
提示词与上下文	不同轮次的任务阶段不清晰，新增条件与旧条件混淆	统一输出协议，由程序保存当前条件和阶段状态
解析程序	模型返回代码块、字段缺失或类型不正确	增加 JSON 结构检查和详细错误日志。正式分数仍按原始字符串解析；去除代码块后的结果只作对照，三个模型使用同一规则
接口服务	请求超时、限流或网络中断影响任务连续性	统一接口适配，设置超时、重试间隔与备用服务处理流程

在实际开发中，我们还计划围绕这些环节完善测试覆盖，并把它们纳入回归测试。除了正常的购车推荐，还要测试预算突然缩小、用户只要求展示参数、车型数据含未知值、模型返回异常格式、接口请求失败以及符合条件的车型为空等边界情况。每次修改模型配置或提示词后，都使用同样的场景再次检查，观察问题是否真正得到改善。

通过这些改进，我们希望把模型输出与业务规则明确分工，使自动化购车推荐既能保留自然语言交互的便利，也能满足软件系统对数据正确性和运行稳定性的要求。

13 BUG 存在的原因分析

在第一部分的测试中，三个模型分别出现了候选结果不一致、推荐阶段控制不稳定、结构化格式错误和需求理解偏差等问题。这些现象的具体表现有所不同，也提示我们需要结合模型输出、提示词约束和程序处理方式分析原因，再提出相应解决办法。

（1）候选车型与推荐理由不一致

遇到的问题： 在商务轿车场景中，用户要求预算不超过 25 万元，并且需要三厢轿车。Qwen 的一次测试在首轮列出了 15 款候选车型，其中 3 款超出了预算；另一次测试的 9 款候选中，也包含 1 款超预算车型。DeepSeek 同样出现过类似情况：它在文字中说明宝马 5 系超出预算，却又将这款车放入候选列表。

这些回答说明，模型虽然能够在文字说明中识别预算问题，但候选列表与最终表述没有始终保持一致。如果系统直接将模型返回的候选结果展示给用户，就可能把不符合要求的车型混入推荐范围。

可能原因： 模型在文字说明中识别了超预算问题，却没有将排除判断同步应用到结构化候选列表。提示词对“参照车型”和“正式候选”的边界也可能不够清晰，导致两部分输出出现差异。

解决思路： 我们计划在模型生成候选结果后增加独立的车型约束检查。程序根据用户当前的预算、车身形式、动力类型等条件，对所有候选车型再次筛选。对于不符合条件的车辆，可以在“排除原因”中单独说明，而不再将其与合格候选放在同一展示列表中。展示用列表可以剔除不合格 ID，并另行保存模型原始候选。评分仍依据原始输出，过滤后的列表不回写为评分结果。

（2）多轮对话中没有正确区分推荐阶段

遇到的问题： 在豪华 SUV 场景中，用户最初提出 80 万元的预算，之后将预算降低至 50 万元。DeepSeek 能够根据新预算调整候选车型，却在三次独立测试中均提前填写了最终车型字段，没有按照我们规定的五轮流程，在最后一轮才给出正式选择。

这一现象说明，模型能够理解预算变化，但对不同对话阶段的输出要求执行得还不够稳定。对于真实购车产品来说，用户在前几轮可能只是了解车型，还没有完成最终比较。系统如果过早确定最终结果，容易让后续交互缺少清晰的阶段划分。

可能原因： 模型可能把每轮给出的推荐倾向当作最终决策，未能稳定区分当前阶段的推荐与最后一轮的正式选择。问题主要体现在对输出阶段规则的遵循上，而不是对预算变化的理解。

解决思路： 我们计划将“当前推荐”和“最终选择”设置为两个不同的状态。前几轮允许系统展示阶段性候选及推荐倾向，只有进入最终确认环节后，才生成正式的目标车型。同时，由程序管理当前有效的预算和其他购车条件，确保用户修改需求后，后续推荐能够及时更新。若把前 4 轮的 final 另记为当前倾向，指令分仍按原协议扣除，不把提前填写改记为选车成功。

（3）结构化输出格式不稳定

遇到的问题： 在 Kimi 的首次购车场景中，三次独立运行均出现了相同问题：模型将 JSON 内容放在 Markdown 代码块中，而测试程序要求直接返回可解析的 JSON 对象。虽然回答中已经包含了车型信息，但外层多出的代码块标记导致程序无法正常读取内容，后续评分也受到影响。

这类问题在人工阅读时并不明显，但在自动化系统中，输出格式直接决定后续功能能否继续执行。尤其当推荐结果需要传递给参数表格或前端页面时，格式不一致就可能导致整个流程中断。

可能原因： 模型沿用了常见的 Markdown 代码展示习惯，但测试程序采用严格 JSON 解析，不能直接识别代码块外层标记。模型输出格式与解析器要求不一致，导致后续自动处理无法继续。

解决思路： 针对这一问题，我们比较了三种处理方式。第一种是只在提示词中强调输出格式。当前协议已经要求每轮返回一个 JSON 对象，Kimi-K3 仍把内容放进代码块，因此只改提示词尚未经过本次实验验证。第二种是在解析前去掉代码块标记。第三种是增加结构化输出约束，并在程序侧校验字段。

正式分数仍按原始字符串用 json.loads 解析，不把修复后的文本写回评分。去除代码块后再解析，只作为对照指标，不替换原始成绩，也不能只对 Kimi-K3 放宽。验证时冻结当前车型库、场景和评分规则，三个模型使用同一版解析重新测试，比较 JSON 解析通过率、候选合格比例和严格成功次数，并记录响应时间与 Token 消耗。

（4）将对比参数误认为新增筛选条件

遇到的问题： Kimi 在某次商务场景测试中，用户只是要求将驱动形式、前排座椅加热等信息列入参数表格，并说明未知信息可以留空。模型却将这些展示字段理解为新的购车硬约束，认为用户必须选择四驱、且前排座椅加热必须标配的车型，最终错误地判断没有合适的车辆。进入下一轮后，模型又重新理解了需求，并给出了符合条件的推荐。

这说明，多轮对话中不仅要记录用户提出了什么要求，还需要判断这些要求的实际用途。用户希望“查看某项参数”，与用户要求“某项参数必须达到指定标准”，属于两种不同的需求。

可能原因： 模型没有准确区分用户希望“查看的信息”和用户要求“必须满足的条件”，将表格展示字段错误地加入了筛选规则。如果缺少独立的条件校验，这种误解就更容易直接影响候选结果。

解决思路： 我们计划对用户输入进行进一步分类，将其区分为硬约束、个人偏好和信息展示要求。只有明确提出新增或修改条件时，系统才更新车型筛选规则。对于模型给出的“暂无合适车型”等结果，程序也应再次检查当前条件及车型数据，并提供相应的排除原因，避免因为理解偏差而影响用户判断。

结合这些案例，我们发现，错误并不总是因为模型缺少车型知识。输出协议不明确、程序校验不足，以及对多轮需求状态的管理不充分，都可能使一次局部偏差影响最终的使用效果。将问题原因与工程改进措施对应起来，有助于我们在下一轮开发和评测中更有针对性地解决问题。

14 大模型对现实生活的影响

经过本次购车决策评测，我们对大语言模型在现实生活中的作用有了更加具体的认识。大模型的价值不仅在于能够快速回答问题，更在于它能够通过自然语言与用户交流，帮助用户逐步整理需求、比较信息，并参与一些较为复杂的决策过程。

（1）降低获取和理解信息的难度

对于普通购车用户来说，不同车型之间的价格、动力、续航、配置和适用场景存在较多差异，查找和整理这些信息往往需要花费不少时间。传统方式通常需要用户自行浏览多个页面，再逐项进行比较。而大模型可以通过多轮对话了解用户的预算、出行习惯和其他要求，并将相关信息组织成较为清晰的推荐和对比结果。

例如，用户最初可能只知道自己需要一辆适合上下班通勤的汽车，随后才逐渐明确充电条件、车身形式和续航需求。大模型能够适应这种逐步提出要求的交流方式，让用户在比较过程中进一步了解自己的真实需求。

（2）提高学习、工作和生活中的信息处理效率

大模型能够辅助完成资料整理、问题分析、方案比较和文本生成等工作。在本次作业中，我们通过自动化程序批量调用模型，整理输出结果并进行评分，也体验到了大模型与传统程序相结合的应用方式。这种方式同样可以应用于课程学习、日常办公、数据分析和客户咨询等场景，帮助人们将更多时间投入到判断和决策上。

（3）关注错误信息可能造成的影响

在看到大模型带来便利的同时，我们也发现，流畅的语言表达并不意味着所有内容都正确。本次测试中，有模型能够解释某款车超出预算，却仍然将其放入候选列表；也有模型将用户要求展示的参数误认为必须满足的条件。这些问题如果没有被及时发现，可能会影响用户对车型的判断。

尤其在购车这类涉及较大金额的消费决策中，用户不仅需要推荐结果，还需要了解推荐依据、价格口径和数据来源。对于实际价格、车辆配置及用车成本等信息，系统应结合可靠数据进行核验，为用户提供更加准确的参考。

（4）让人工判断与智能辅助相结合

我们认为，大模型更适合承担辅助分析和信息整理的工作，而用户仍然需要根据自身情况作出最终选择。预算、座位数量和动力形式等条件可以通过程序进行明确判断；驾驶体验、品牌偏好和乘坐舒适程度则具有较强的个人差异，需要结合实际试驾和个人感受进行考虑。

通过这次实践，我们认识到，大模型正在改变人们获取信息和解决问题的方式，但一个真正有价值的智能应用，不仅要让用户更方便地得到答案，也应该帮助用户理解答案的依据，并在必要时作出进一步核实和判断。

15 市场概况与目标用户

（1）大模型 API 与智能体市场的发展情况

近年来，大语言模型逐渐从独立的聊天工具发展为可以通过 API 接入业务系统的智能服务。开发者能够把语言理解、信息分析和文本生成能力集成到网站与应用中；智能体（Agent）则在此基础上结合工具调用与任务流程，承担更完整的业务工作。

根据 Grand View Research 的报告，2025 年全球大语言模型市场规模约为 74 亿美元，2026 年预计达到 98 亿美元，2033 年预计达到 956 亿美元，2026—2033 年的年均复合增长率约为 **38.5%**。同一机构预测，全球 AI Agents 市场将从 2025 年的约 76 亿美元 增长至 2026 年的 109 亿美元，2033 年预计达到 1829 亿美元，2026—2033 年的年均复合增长率约为 **49.6%**。从市场增速来看，智能体相关服务预计会保持较快增长。

从 API 和开发平台相关的商业需求来看，Gartner 在 2026 年 7 月发布的预测中指出，全球 AI 模型与平台终端支出预计将从 2025 年的约 393 亿美元 增长至 2026 年的 643 亿美元，同比增长 **63.4%**。这一统计覆盖模型和相关平台服务，也包括开发者使用的平台能力，与前述大语言模型市场统计的范围有所不同。对我们的项目而言，这一趋势说明，围绕模型接入、运行成本控制、自动评测和行业应用开发的需求正在增长。

（2）汽车消费市场与智能购车服务的机会

根据中国汽车工业协会公布的数据，2025 年我国汽车总销量为 3440 万辆，其中乘用车销量约 3010.3 万辆，新能源汽车销量为 1649 万辆。随着纯电、插混、增程和传统燃油车型同时发展，消费者面对的车型和配置选择越来越丰富，购车前需要比较的信息也随之增加。

汽车消费金额较高，用户往往需要反复考虑预算、使用场景、动力、空间、续航及后期成本。对于首次购车者，产品可以帮助他们理解车型参数并明确需求；对于家庭用户，产品可以在预算和用车条件改变时重新筛选车型；对于汽车资讯和咨询服务人员，结构化推荐结果能够提高整理资料的效率。这些需求与我们本次实验中设计的五类购车场景较为接近，也为后续产品开发提供了方向。

（3）直接用户与潜在用户规模

结合产品定位，我们准备优先面向正在选车的个人消费者提供服务，再逐步拓展汽车咨询机构、资讯平台和开发者等企业客户。用户群体和使用需求可以归纳如下：

用户群体	使用需求	产品提供的主要价值
首次购车者	不熟悉参数，希望明确购车方向	需求引导、基础知识解释和合格车型推荐
家庭与通勤用户	需要反复比较预算、空间、动力及续航	多条件筛选、方案对比和需求变更记录
汽车咨询与内容服务人员	需要快速整理多款车型的信息	结构化报告、参数核验和推荐依据展示
汽车服务企业与开发者	希望把智能推荐接入已有业务	标准化接口、筛选规则配置和结果校验

我们将国内乘用车购买需求作为个人用户的主要市场参考。2025 年约 3010.3 万辆 的乘用车销量，体现了购车咨询的潜在业务规模。由于车辆销量不等于独立购车人数，我们在规划中以购车咨询场景作为衡量对象。产品初期，我们希望争取其中约 1%—3% 的咨询服务机会，按照这一假设估算，每年约有 30 万—90 万次 潜在服务需求。实际能够触达多少用户，还需要结合产品上线后的访问和使用情况进行验证。

从更广泛的潜在用户来看，中国互联网络信息中心发布的《生成式人工智能应用发展报告（2026）》显示，截至 2026 年上半年，我国生成式人工智能用户规模已经突破 7 亿人，普及率超过 **50%**。这些用户已经具有使用智能问答和生活助手的基础习惯，为购车助手等垂直应用提供了潜在的用户基础。面向企业和开发者，我们则计划优先寻找汽车资讯、咨询和门店服务等合作场景，通过小规模试用积累案例，再逐步扩大服务范围。

总体来看，大模型 API 和 Agent 市场的增长为技术应用提供了基础，国内庞大的汽车消费需求则提供了具体业务场景。我们希望先把购车条件筛选与推荐解释做好，再围绕真实用户需求拓展更多服务。

16 未来产品规划

如果由我们继续负责本次项目的后续开发，我们希望在现有评测程序的基础上，设计一款更加贴近实际购车需求的智能购车决策助手。产品不仅能够推荐符合条件的车型，还能够帮助用户整理购车需求、比较不同方案，并解释每一次推荐调整的原因，逐步形成从选车到购车规划的完整服务流程。

（1）产品定位与核心功能

我们计划将产品定位为面向普通消费者的智能购车辅助平台。用户只需要用自然语言描述预算、家庭情况、通勤距离和个人偏好，系统就能将这些信息整理为明确的购车条件，再结合车型数据进行筛选和比较。当用户修改预算或增加新的要求时，系统可以更新有效条件，并重新生成候选名单。

结合本次评测中出现的预算约束遗漏、条件理解偏差和结构化输出不稳定等问题，我们首先希望完善购车条件管理、车型数据校验和推荐依据展示三项基础能力。模型负责理解用户的表达，程序负责检查预算、车型、动力等明确条件，使推荐过程既方便交流，也便于核对结果。

（2）功能选择理由与产品创新点

我们认为，购车助手的价值不只是回答“哪款车值得买”，更在于帮助用户逐步明确需求，并在信息不断变化的情况下作出合适的选择。传统车型筛选工具可以比较价格和配置，但在连续理解用户需求、解释取舍方面仍有提升空间；通用大模型虽然交流灵活，却可能出现候选车型不符合约束或推荐依据不够清楚的问题。因此，我们希望在可靠筛选的基础上，将智能体编排、行业场景、多模态交互等能力应用到实际购车流程中，并进一步探索以下创新功能。

智能体编排与任务协同。 用户提出购车需求后，系统可以按照“理解需求—查询车型—校验条件—比较参数—估算费用—生成方案”的顺序组织任务。大模型负责理解问题与解释结果，具体查询和计算则交给相应工具。例如，用户希望在20万元以内选择适合城市通勤的新能源车，系统可以先筛选车型，再比较续航、空间与费用，最后生成带有推荐理由的购车方案，减少用户反复搜索和整理信息的时间。

面向不同用户的购车场景设计。 我们计划围绕首次购车、家庭出行、日常通勤、商务接待和换车升级等场景设计需求引导。首次购车用户可能关心停车便利性和养车成本，家庭用户更关注空间与乘坐需求，长距离通勤用户则需要综合考虑续航和补能条件。系统可以根据场景调整比较重点，使推荐不只是简单罗列车型参数，而是真正围绕使用需求展开。

多模态信息输入与整理。 除了文字输入，后续可以支持语音描述需求，以及上传车型配置单、报价单或宣传图片。系统提取其中的价格、配置和车型信息后，与车型库进行对照，生成直观的差异说明。例如，用户上传两份经销商报价单，就可以直接询问“哪一份更划算、有哪些配置差别”，减少手动录入和逐项比较的工作。

低代码配置与服务接入。 我们还希望将购车条件模板、参数展示字段、推荐理由样式和流程步骤设计为可配置内容，并提供统一接口。汽车资讯网站、校园购车咨询活动或汽车服务平台可以根据自身需求调整页面和业务流程，而预算等核心条件仍由统一的校验规则处理，从而减少重复开发，提高功能复用性。

需求变化记录与方案对比。 实际选车时，用户经常会在预算、动力、品牌和空间之间反复调整。我们计划记录关键需求的变化，并提供“修改前后方案对比”。例如，预算从20万元调整到25万元后，系统可以说明新增了哪些候选车型、哪些要求仍未改变；如果用户同时提出相互冲突的条件，也可以提示需要优先考虑的因素。这样用户不仅能看到结果变化，也能理解变化的原因。

购车及用车成本模拟。 对不少用户来说，购车价格只是支出的一部分。我们希望增加购置相关费用、能源费用、保养及保险预算等项目的估算，并允许用户填写年行驶里程、充电条件和计划使用年限。系统根据可核实的数据及用户输入形成不同车型的费用对比，帮助用户判断“买得起”之外“是否适合长期使用”的问题。对于随地区和个人情况变化较大的费用，则提供可调整的估算区间。

推荐依据展示与数据追溯。 我们计划为关键车型参数标注对应配置、数据来源和更新时间，并在推荐结果中列出满足的条件、需要进一步确认的信息以及未入选车型的排除原因。对于无法核实的参数，系统优先提示信息缺失，而不是直接补出一个看似合理的数字。这样可以让推荐从单纯的文字结论转变为能够逐项检查的决策依据。

家庭成员共同参与购车决策。 家庭购车通常涉及不止一个人的需求。我们希望支持建立共享购车方案，由家庭成员分别提出预算、空间、外观和驾驶体验等偏好，再由系统汇总共同要求与意见分歧。例如，一位成员更重视空间，另一位更关注经济性，系统可以生成兼顾双方需求的候选方案，并说明不同选择的取舍，减少重复讨论。

上述功能既考虑了当前实验中暴露的推荐可靠性问题，也进一步面向实际购车过程中的信息整理、费用比较和多人沟通需求。通过这些设计，我们希望把自然语言交互与可靠的车型校验结合起来，在方便用户表达需求的同时，为推荐结果提供清晰、可核对的依据。

（3）NABCD 分析

维度	具体分析
N：Need（需求）	用户既需要在复杂的车型信息中快速找到合适选择，也希望在预算或偏好变化时及时比较方案，了解推荐依据、长期费用和不同家庭成员的需求。
A：Approach（做法）	以多轮需求理解和硬约束校验为基础，结合车型数据查询、可解释推荐与方案对比，并逐步扩展工具编排、费用模拟和多模态交互。
B：Benefit（收益）	降低用户搜集信息、反复筛选和整理报价的成本，帮助用户看清不同车型的优缺点及费用差异，提高购车决策效率。
C：Competition（竞争）	相比通用聊天工具，我们更强调条件校验与数据依据；相比传统汽车资讯平台，我们更强调连续对话、需求变化追踪和个人化方案比较。
D：Delivery（推广）	先通过网页端原型验证核心选车流程，再面向首次购车者、家庭用户等群体开展体验测试；在产品稳定后，通过标准接口拓展至汽车资讯与购车咨询场景。

（4）功能优先级安排

本次课程作业主要完成了购车场景下的模型评测与工程问题分析。对于后续真正面向用户的购车助手，我们希望以现有测试成果为起点，先实现最基础的需求管理和推荐校验，再逐步增加更多功能。根据《构建之法》中关于功能定位与优先级的思路，我们按照用户价值、实现难度和功能依赖关系划分三个优先级，优先解决影响推荐正确性和可解释性的问题。

优先级	计划开发的功能	主要作用
P0	购车条件管理、车型校验与统一模型接入	准确执行预算等明确约束，处理格式异常和接口调用问题
P0	数据来源标注与推荐理由解释	让用户了解车型入选或排除的依据
P1	场景化需求引导、需求变化追踪	减少重复输入，帮助用户比较不同购车方案
P1	购车成本模拟与方案保存	从车型价格扩展到实际使用成本，方便用户持续比较
P2	多模态输入与智能体工具编排	支持报价单识别、信息查询和多步骤购车咨询
P2	家庭协同决策	汇总多名用户的共同需求和偏好差异
P2	低代码配置与标准化接口	为其他汽车服务平台提供可复用的推荐能力

（5）产品验证与后续迭代

在具体实施中，我们计划将自动化测试与用户体验测试结合起来。自动化测试重点检查预算变化、候选车型超出约束、缺少参数、格式异常和接口调用失败等问题，保证基础功能稳定。对于购车成本模拟，还需要检查计算规则、输入参数和数据来源是否一致；对于多模态和多人协同功能，则重点关注信息识别、需求合并以及用户操作是否方便。

用户体验测试可以邀请首次购车者和有家庭购车需求的体验者，完成“提出需求—查看推荐—比较车型—修改条件—保存方案”的完整流程，观察操作耗时、理解难度以及对推荐依据的信任程度。我们希望通过持续收集反馈，逐步调整功能顺序和展示方式，使购车助手逐步从实验中的模型推荐工具，发展为更贴近实际购车需求的服务。

17 本部分总结

通过对三个大模型及购车评测系统的分析，我们进一步认识到，大模型的实际应用能力不仅取决于它能否回答用户的问题，还与数据质量、上下文管理、接口设计、异常处理和软件测试密切相关。

本次测试中出现的候选车型超预算、提前输出最终结果、结构化格式错误以及误解用户条件等问题，为我们后续改进提供了明确方向。相比于单纯增加模型功能，我们更加关注如何通过软件工程方法保证推荐结果的可靠性，让用户能够理解推荐依据，并根据自己的实际需求作出选择。

未来，我们将继续围绕真实用户需求完善产品设计，在确保基本功能稳定的基础上逐步扩展应用场景。通过将大模型的自然语言理解能力与程序的数据校验能力相结合，我们希望构建一个更加实用、清晰和可信的智能购车决策助手。

---

参考资料：

1. 邹欣：《构建之法》（软件工程实践课程相关章节）。
2. Grand View Research：Large Language Models Market。
3. Grand View Research：AI Agents Market。
4. Gartner：2026 年全球 AI 模型与平台支出预测。
5. 中国互联网络信息中心：《生成式人工智能应用发展报告（2026）》。
6. 商务部商务预报：2025 年汽车流通行业主要指标（含乘用车销量）。
7. 千问 AI 平台：免费额度说明。