从“会聊天”到“会决策”：GLM-5.2 与 Qwen3.8-Max 购车任务实测

团队：掌中生活（LifeMap）｜成员：黄炫文、胡昊、陈志、李天赐、杨俊鑫、吴军峰、陈瀚楷｜实验日期：2026-11-08 至 11-10

摘要：我们让 GLM-5.2（关闭思考）与 Qwen3.8-Max（开启思考）在 3 个购车场景中各跑 3 次，共完成 18 次多轮任务；从约束满足、多轮一致性、指令遵循、工具调用、信息真实性、稳定性、成本与延迟 7 个维度打分。结果是：两者在本次任务里的准确性打平（D1/D2/D3/D5 均为 100），A 的工具调用更干净、延迟和费用约为 B 的 1/3.9 和 1/3.2；B 的思考模式没有转化为更高准确率。结论只适用于本次数据与实验设置。

目录

第一部分 调研，评测

1.1 评测设计：让两个模型“同场考试”

上一次作业我们让大模型写代码，这一次把大模型当成被测产品。购车决策适合做评测，因为它同时具备四个特点：多约束（预算、座位、能耗、安全）、要查数据（车型库、落地价）、要跨轮保持（中途改需求）、结果可验证（车型是否存在、价格是否超预算）。我们想回答三个问题：

1. 硬约束多的任务里，模型会不会“漏约束、超预算”？
2. 中途改需求后，模型还能不能记住并采用新约束？
3. 工具调用、成本、延迟之间如何取舍？

被测对象。 A 是智谱 GLM-5.2（关闭思考，作为“通用对话”基准）；B 是阿里百炼 Qwen3.8-Max（开启思考，作为“推理/思考”基准）。网页体验对应智谱清言、通义千问。2026-11-08 我们先在控制台实测：两个 Key 都能调通，两个模型都返回了 tool_calls；11-08 当天固定参数并跑完 18 次。

为什么是这两个，而不是“参数最大/最贵”。 我们按四条硬标准选：① 一个通用 + 一个推理/思考；② 有免费/低价额度；③ OpenAI 兼容 + 工具调用；④ 版本稳定、文档全、国内可访问。GLM-5.3/5.3-Flash 强制思考，不能作为“关闭思考”的通用基准，所以 A 选 5.2；B 选当前旗舰 Qwen3.8-Max，能开思考、能调工具。旧写法里的 qwen3-235b-a22b 在百炼已经 404，glm-4.5-flash 还能用，但为了对齐最新稳定版，统一换成了 5.2 / 3.8-Max。

实验规模。 2 模型 × 3 场景 × 3 次 = 18 次完整多轮任务（每模型 9 次、每场景 3 次）。每模型只重复 3 次，样本量小，因此我们只描述“本次运行中的差异”，不做显著性检验，也不外推成行业排名。

公平性控制。 同一份场景脚本、同一组提示词、同一份 13 款车型数据（本次运行版本）、同一套输出格式、同一组 3 个工具（search_cars / get_car_detail / calc_landed_price）、同一组参数（temperature 0.2、top_p 0.9、max_tokens 2048）、同一单轮超时 180s、同一最大工具轮次 4。每次运行重置上下文；A/B 交替跑；不启用联网检索，工具只查本地固定库，避免“谁搜得好”混入模型能力。

数据。 13 款车（本次运行版本；之后数据组把车型库扩到 17 款，新增 4 款擦线诱饵，本文结果仍按 13 款版本复算），覆盖燃油/混动/插混/纯电，价格统一按“落地价”口径估算（燃油/混动：指导价 + 购置税 + 保险 + 上牌；纯电按 2026 年现行减免政策估算）。这是教学模拟数据，不是实时市场报价；每款车都写了年份/配置/价格口径/单位、source_note 和 data_date。预期合格集、陷阱和评分规则在开跑前写进仓库；跑完后只修正了两个实现口径（S3 第 3 轮是需求变更、表格检查不适用；D4 把重复工具调用计入扣分），没有改场景、权重或预期集合。

图01｜评测流程

3 个场景 × 4 轮 → 模型 A/B → 统一工具 → JSONL → 7 维评分 → 5 张图。18 次运行都走同一条链路，保证可比。

1.2 大模型 1：智谱 GLM-5.2（关闭思考）

1.2.1 使用体验：智谱清言（网页端 GLM-5.3-Flash）

测试时间：2026-11-09 14:08–14:18｜入口：https://chatglm.cn/
说明：网页端“智谱清言”当前默认 GLM-5.3-Flash，思考强度可调；API 评测用 GLM-5.2（关闭思考），因为 GLM-5.3 系列不允许关闭思考。本节只评价产品交互与表达，不把网页端表现等同于 API 分数。

智谱清言是网页版对话产品，未登录可以看首页，发消息时弹登录（微信扫码或手机号）。左侧是功能栏：新对话、学习搭子、AI 画图、AI 阅读、AI 生视频、AgentMore、云知识库、探索智能体；右侧是对话区，底部有模型选择（GLM-5.3 / GLM-5.3-Flash）和思考强度（快速 / 深度 / 极致），本次保持默认“极致”。右上角有历史记录，能看到 2026-11-09 的“购车推荐15万预算”对话。

图02｜智谱清言首页

左侧是功能栏（学习、画图、阅读、视频、Agent、云知识库），底部是模型和思考强度入口；本次保持默认“GLM-5.3-Flash + 极致”。

图03｜登录入口

支持微信扫码或手机号登录；未登录可以看首页，发消息时弹登录。对只想快速试用的用户，这是一个小摩擦。

我们按 S1 场景输入：“预算落地 15 万元左右，城市通勤每天约 40 公里；必须有 L2 和 ISOFIX；油耗 ≤6.5L/100km（纯电除外），推荐 3 款”。模型先给结论：秦L DM-i 120KM领先型（综合首选）、银河L6 EM-i 140KM探索+版（性价比首选）、小鹏MONA M03 620超长续航Plus（纯电首选，有家充必备），随后给出“车型 / 动力 / 推荐版本指导价 / 预估落地价”表。追加“动力、能耗、安全、后排空间、保值率”五个关注点，并要求 8 列对比表后，它逐条分析五维、输出完整对比表，最后给“场景化购买建议”和“去店里试后排、问物业能否装桩”的提醒。

图04｜首轮推荐

输入“15 万落地、40km 通勤、L2、ISOFIX、油耗 ≤6.5L”后，模型收敛到秦L DM-i、银河L6、MONA M03 三款，并给出各自适合人群。

图05｜首轮对比表

列是车型 / 动力 / 推荐版本指导价 / 预估落地价。三款都在 15 万上下，但“预估落地价”是区间，后面会成为它的一个缺点。

图06｜补充五个关注点

追加动力、能耗、安全、后排空间、保值率，并要求 8 列对比表；这是从“推荐”走向“可比较”的关键一步。

图07｜五维对比表（上）

车型 / 落地价 / 座位 / 能耗续航。8 列在网页端被截断，需要横向滑动；这不是内容错，是窄屏布局问题。

图08｜五维对比表（下）

安全配置 / 后备箱 / 优点 / 缺点。要分两屏才能截全，手机端更明显；采访里李同学也提到了“没有图片和详细配置”。

图09｜历史记录

2026-11-09 的“购车推荐15万预算”可以回看，说明会话被保存；对需要反复比价的用户，这个入口有用。

图10｜模型与思考强度

GLM-5.3 / GLM-5.3-Flash 可选，思考强度分快速 / 深度 / 极致。本次用默认“极致”，输出很细，但等待也偏久。

图11｜真实使用场景

在笔记本上实际打开智谱清言走完 S1；这是“使用软件的照片”，已裁掉人脸。

它解决了用户的问题吗？ 解决了一大半：从“15 万、通勤、L2、ISOFIX”直接收敛到 3 款，并给出每款的取舍和适用人群，省掉了大量来回比价的时间；但没有解决“价格是否精确”和“数据是否最新”的问题——落地价是区间，没有税费/保险明细，也没有逐条来源和日期，最终仍要用户去店里核实。

优点。

1. 结构像一份决策报告：先结论、再表格、再场景化建议，最后给行动建议，不是堆参数。
2. 多轮记忆好：补充 5 个关注点后仍围绕同 3 款车，没有换车、没有丢预算/L2/ISOFIX 约束，表格也更新为 8 列。
3. 可解释、可追溯：回答有“思考结束”可展开，底部有来源入口（截图可见 30 个来源），支持复制/分享/重新生成。
4. 产品能力全：左侧有学习、画图、阅读、视频、Agent、云知识库等入口；模型与思考强度可切换；历史记录可回看。

缺点。

1. 价格口径不透明：只给“指导价 + 预估落地价（区间）”，没有购置税/保险/上牌明细和数据日期，无法核对“落地 15 万”是否精确成立。
2. 表格太宽：8 列在网页端被截断，需要横向滚动；“安全配置/后备箱/优点/缺点”要分两屏截，手机端更难读。
3. “极致”思考偏重：一个 15 万预算的购车问题输出很长、等待偏久；产品没有提示预计耗时，也没有“简单问题用快速模式”的建议。
4. 登录门槛：必须登录才能对话，历史记录绑定账号；对只想快速试用的用户有摩擦。
5. 数据时效不足：价格和配置没有逐条来源/更新日期，容易让用户误以为是实时报价。

改进意见。

一个必须说明的差异。 网页端推荐的是秦L、银河L6、MONA M03，而我们的自动化测试用固定 13 款车型库（运行版本；当前仓库已扩到 17 款）；网页端没有受控数据源，价格是模型估计，这也是我们做自动化评测的原因之一。体验部分评价“好不好用”，API 部分评价“在统一数据与规则下准不准”，两者分开看。

1.2.2 用户采访：软件工程大三李同学

采访时间：2026-11-09 14:38–14:50（约 12 分钟）｜方式：QQ + 对方手机实际操作
对象：李同学（化名），软件工程专业大三，非团队成员，有帮家里选车经历；已征得同意，姓名/头像已打码。

（1）背景与选择理由。 李同学是软件工程专业大三学生，帮家里选过车，对预算、油耗、配置有基本概念。选择他，一是符合作业“计算机/软件相关专业”的要求，二是他有真实选车经历，不是完全小白，三是不属于我们团队，能提供外部用户视角。他的需求和 S1 一致：落地 15 万、每天约 40km 通勤、必须有 L2 和 ISOFIX、油耗 ≤6.5L/100km（纯电除外）；他希望“快速拿到 3 款车和理由，不想自己翻大量测评”。

（2）实际使用的栏目。 他用手机打开智谱清言，在对话框输入 S1 需求，然后依次看了：首轮推荐（秦PLUS DM-i、吉利银河L6、丰田卡罗拉1.8L双擎）→ 每款车的推荐理由（L2、ISOFIX、油耗、纯电续航、适合人群）→ “三款对比速览”表 → “选购建议”。他没有继续多轮追问，主要停留在“首轮推荐 + 对比表 + 建议”。

（3）问题与亮点。 亮点很明确：一是快，他的原话是“几秒就给我推荐出几辆符合预期的车”“推荐速度还是比较快的”；二是理由充分，“推荐的理由还是很充分的”，每款车都逐条对应了 L2、ISOFIX、油耗、续航和空间；三是结果符合预期，三款车都在 15 万上下，覆盖混动/油电混动，还按“有家充/无充电/预算紧”给了选购建议。问题也很具体：他觉得“还只是很粗略地了解了一下这几种车型”“没有具体图片和更详细的配置”；想进一步看车图、详细配置和口碑时，产品里没有直接入口，只能自己再去搜。另外，手机端的“三款对比速览”表只显示到“用车成本”列的一部分，需要横向滑动；落地价是“约 12–15 万”这类区间，没有税费/保险明细和数据日期。

（4）改进建议。 他最想改的是：“建议这个智谱增加 url 快速访问这辆车详细信息和图片之类的。” 具体可拆成三条：① 每款车加详情页/官网/图片/配置表的跳转，最好在对话内直接预览；② 对比表在手机上改成卡片/可展开，不要横向截断；③ 价格给出指导价、购置税、保险、上牌、落地价明细和数据日期。

观察与推测。 我观察到：他输入需求后很快看到 3 款车，逐条看了理由和对比表，在“想看图片/详细配置”时停住，随后说自己再去搜；他这次拿到的是秦PLUS、银河L6、卡罗拉双擎，而我桌面端拿到的是秦L、银河L6、MONA M03，两端结果不完全一致。我推测：速度感可能与流式输出/缓存有关；结果差异可能与入口（手机/桌面）、模型版本（GLM-5.3-Flash）或思考强度有关，需要固定入口和参数才能验证；他没继续追问，可能是首轮已经“够用”，而不是产品不支持多轮。以上推测未做对照实验，只作为后续测试假设。

图12｜李同学手机端使用记录

同一段 15 万需求，他拿到秦PLUS、银河L6、卡罗拉双擎，并看了对比表和选购建议；和桌面端结果不完全一致，说明入口/版本会影响候选集。

图13｜采访文字记录

软件工程大三、非团队、有帮家里选车经历。他夸“几秒出结果、理由充分”，也指出“没有具体图片和更详细配置”；姓名/头像已打码。

图14｜采访邀约与同意

QQ 里说明用途、时间和隐私处理，对方回复“可以可以”；这张图主要证明采访真实发生、已征得同意。

1.2.3 自动化测试表现

A 的 9 次运行全部成功，9/9 status=ok，最终 JSON 全部可解析。9 次最终推荐分布是：

• S1：元PLUS（r1）、秦PLUS（r2/r3）；
• S2：嘉际（r1/r2/r3）；
• S3：汉DM-i（r1/r2/r3，改需求后仍正确）。

A 的中位延迟 66.6s，中位 token 33,657，9 次估算费用 ¥3.43。D1/D2/D3/D5 均为 100；D4 为 96.7（A-S2-r3 对 3 款车重复 get_car_detail 各 2 次，共 7 次调用、3 次重复）；D6 为 99.7。A 的 S1 出现“元PLUS / 秦PLUS”两种都合格的选择，按 rubric 不判为不稳定。

A 的强项是“干净”：工具调用次数少（4–12 次），没有重复价格计算；预算/硬约束/表格/JSON 全部满足。弱项是 S1 的推荐不完全确定：同一场景 3 次出现两种合格答案，说明它对“通勤成本 vs 动力/空间”的偏好有随机性。

1.2.4 结论

A 适合“预算敏感、量大、要低延迟”的购车推荐：准确性在本次任务中满分，工具调用干净，延迟和费用低。它不适合“必须给出唯一答案”的场景——同一场景可能给出不同但都合格的车；如果业务要求可复现，需要固定 temperature/seed 或加规则约束。

1.3 大模型 2：阿里百炼 Qwen3.8-Max（思考）

1.3.1 使用体验：通义千问（Qwen3.8-Max 思考模式）

体验人：吴军峰｜时间：2026-11-09｜入口：通义千问网页版｜模型：Qwen3.8-Max，思考强度“低”
说明：这是人工产品体验，走真实市场数据/联网搜索；与 18 次自动化运行（教学车型库、禁联网）独立，不直接比较分数。

吴军峰用 7 个任务覆盖了购车咨询的主要环节：T1 15 万落地家用代步、必须省油；T2 追问第一款车的保养成本与保值率，并与第二款比较；T3 25 万、两个孩子、必须 6/7 座 SUV、安全优先、2024 年后上市；T4 20 万纯电轿车，中途改成“必须 SUV、预算 23 万”；T5 联网查秦L 2025 款广州终端优惠；T6 幻觉压力测试，问“2025 款卡罗拉氢燃料旗舰版”；T7 裸车 14.98 万算广州落地价（购置税/保险/上牌）。

优点。 ① 工具调用积极：涉及行情、碰撞成绩、终端优惠的问题会先检索再回答，T3 单轮调用了 16 次工具，逐条核对“25 万/6-7 座/安全优先/2024 年后上市”四条硬约束。② 上下文保持扎实：T4 用户从“20 万纯电轿车”改成“SUV、23 万”后，模型保留了“家充桩已装、市区通勤为主、其他需求不变”，推荐整体切换为 SUV（极氪7X、小鹏G6、乐道L60 等）并重新排序。③ 真实性与主动性：T6 面对虚构的“卡罗拉氢燃料旗舰版”，明确说“目前并不存在这款在售车型……我不想编造信息”，并给出卡罗拉真实在售版本和丰田氢能实际布局；T3 主动补充“6 座还是 7 座”的选择建议，并提示中保研 C-IASI 与 C-NCAP 的差异。④ 计算过程透明：T7 购置税按“裸车价÷1.13×10%”计算，分新能源/燃油两版，纳入交强险、车船税、商业险和广州牌照指标，合计约 16.2 万 / 18.0 万。⑤ 有来源：T5 的秦L 广州优惠约 1.2 万，引用了汽车之家、太平洋汽车，并说明“2025 款处于清库阶段”。

缺点。 ① 重检索任务延迟明显：T3 单轮“执行工具 16 次”，等待时间显著长于普通问答（未精确计时，主观约半分钟级），产品没有进度或预计等待提示。② 部分联网结论缺少内联来源：T3/T3b 里银河M9“C-NCAP 综合得分率 94.0%”、各车指导价/权益价等关键数字，没有像 T5 那样附来源链接，复核成本高。③ 价格口径混杂：同一回答里“官方指导价”“限时先享价”“权益价”“终端优惠”并存（如深蓝S09 23.99 万起 vs 权益价约 20.49 万），没有统一标注数据日期。④ 推荐车型超出可复核范围：人工体验走真实市场数据，推荐的银河M9、极氪7X 等不在团队教学车型库内，无法用 eval/score.py 复核，只能作为产品体验证据。

改进意见。 ① 所有联网检索的关键数字（碰撞成绩、指导价、终端优惠）统一附 Sources 内联引用和数据日期；② 购车场景默认标注价格口径（指导价/权益价/终端价）与地区；③ 工具调用轮次多时展示检索进度/预计等待，或让用户选“快速回答/深度回答”；④ 对比表在手机上做响应式卡片，避免关键列被截断。

图20｜B 的 T1：15 万代步

推荐秦L DM-i、海豹06 DM-i、卡罗拉双擎，按“家里/单位能不能充电”分流；这是产品体验，不是 API 评测。

图21｜B 的 T2：多轮追问

追问保养/保值率后，仍围绕前文两款车，给出 5–8 年、3–4 年两种持有期建议；说明多轮上下文没有丢。

图22｜B 的 T3：25 万 6/7 座 SUV

单轮执行 16 次工具，逐条核对 25 万/6-7 座/安全优先/2024 后上市，首推银河M9；工具调用积极，但等待明显。

图23｜B 的 T3 备选表

零跑C16、深蓝S09、唐L 等备选与碰撞成绩；还补了“6 座还是 7 座”的建议，并提示深蓝S09 落地会超 25 万。

图24｜B 的 T4 首轮：20 万纯电

推荐小鹏P7+、MONA M03、至境L7、Model 3 等，按均衡/通勤/舒适/品牌分流；先给方向，再等用户改需求。

图25｜B 的 T4 改需求

用户改成“必须 SUV、预算 23 万”后，模型保留家充/市区通勤，改推极氪7X、小鹏G6、乐道L60，并重新排序。

图26｜B 的 T5：联网查秦L优惠

给出广州现金优惠约 1.2 万，引用汽车之家/太平洋汽车，并提醒 2025 款处于清库阶段；这是“有来源”的正面例子。

图27｜B 的 T6：幻觉测试

面对虚构的“卡罗拉氢燃料旗舰版”，明确说“目前不存在、我不想编造”，并给出卡罗拉真实在售版本和丰田氢能实际布局。

图28｜B 的 T7：落地价

按裸车 14.98 万拆购置税/保险/上牌，分新能源/燃油两版，合计约 16.2 万 / 18.0 万；计算过程透明，但没给逐项来源。

1.3.2 用户采访：软件工程 Z 同学

采访人：吴军峰｜时间：2026-11-08 晚，10 分 21 秒｜方式：腾讯会议语音（双方未开摄像头）
对象：Z 同学（化名），福州大学软件工程专业 2024 级；已征得同意，会议昵称/头像已打码。

（1）背景与选择理由。 Z 同学是软件工程专业 2024 级（大三）学生，几乎每天用 AI 助手。他用过豆包、DeepSeek、通义千问、Kimi，也通过网页版用过 ChatGPT；主力是 DeepSeek（代码回答稳、深度思考有用、免费），生活化问题会用豆包。使用频率从高到低是：写代码/改 bug、查资料/解释概念、翻译润色、生活咨询。他买笔记本、耳机时试过让 AI 推荐，但“型号偏老、价格对不上”，最后还是自己看评测和社交平台反馈——这也是我们选他做采访的原因：他是真实的 AI 用户，但对“AI 直接给购买决策”保持警惕。

（2）实际使用的栏目。 他用过深度思考、联网搜索、文档解析、图片理解、语音对话。最有用的是深度思考（算法题/复杂 bug 的逻辑链更完整）和图片理解（拍报错截图直接问）；文档解析用来提炼 PDF 论文/实验手册；智能体广场玩过两次就闲置，语音对话在宿舍不方便打字时用过，但专业术语识别一般。

（3）问题与亮点。 亮点是“解释报错/陌生代码”：一大段报错或看不懂的源码，它能很快拆成人话；正则、SQL 这类容易写错的东西也常让它起头；数学建模比赛时它还帮队伍理清思路、指出一组异常值。问题是幻觉和多轮遗忘：它曾编造一个 Spring Boot 配置属性，照着配项目直接起不来；推荐第三方库时连 Maven 坐标版本号都是编的；多轮改代码时忘了前面约定的命名规范，或明确要求 MyBatis-Plus 又写回原生 JDBC；课程设计里直接用的文件上传代码在 Windows 能跑、部署到 Linux 出问题，排查了一晚上。他的原话是：“现在我把它当一个反应很快的实习生，活可以让它干，但最后签字的人得是我。”

（4）改进建议。 对产品：联网搜索要明确标注信息来源，不要把不同来源混在一起；知识库更新要跟上新框架版本。对“AI 帮用户做购车决策”：价格、配置、各地优惠必须联网核实并标来源/时间；要能横向对比同价位竞品，而不是只推一款；先追问预算和实际用车需求，再给建议。他给通义千问的购车对话打 4/5：结构清楚、参数全，新手能建立基本认知；但价格没标地区/时间、部分理由像广告、只讲优点、缺真实车主反馈和短板。

观察与推测。 我观察到：谈到幻觉时他明显更投入，连续举了三个具体例子；他说手机里装了 4 个 AI App，但反复强调每天用的只有一两个；给购车截图打分时，他先翻到回答底部找来源，再回来看正文。我推测：软件专业学生因为代码可以立刻运行验证，对幻觉的容忍度可能稍高，但对“不标来源”的回答信任度很低；他较强的验证意识可能和课程设计踩坑有关，这一点没有进一步追问验证；以上只是单个样本，不能推广到全体计算机专业学生。

图29｜采访 B

腾讯会议 10 分 21 秒，软件工程 2024 级 Z 同学；他说 AI 是“反应很快的实习生，活可以让它干，但最后签字的人得是我”。昵称/头像已打码。

1.3.3 自动化测试表现

B 的 9 次运行全部成功，9/9 status=ok，最终 JSON 全部可解析。9 次最终推荐分布是：

• S1：秦PLUS（r1/r2/r3）；
• S2：嘉际（r1/r2/r3）；
• S3：汉DM-i（r1/r2/r3，改需求后仍正确）。

B 的中位延迟 257.1s，中位 token 79,062，9 次估算费用 ¥10.90。D1/D2/D3/D5 均为 100；D4 为 87.8（5 次运行出现重复工具调用，B-S3-r3 重复 4 次）；D6 为 99.2；D7 为 34.2。B 的最终推荐与 A 高度一致（S1 秦PLUS、S2 嘉际、S3 汉DM-i），没有出现超预算、漏硬约束、编造车型或 JSON 失败。

B 的强项是“稳”：三次运行给出同一答案，约束满足和真实性满分；弱项是“贵和慢”：中位延迟是 A 的 3.9 倍，token 是 2.3 倍，费用是 3.2 倍；在本次任务里，思考模式没有换来更高的准确率。

1.3.4 结论

B 适合“复杂约束、长上下文、能接受 3–5 倍延迟与费用”的场景；本次购车任务里它的准确性没有超过 A，工程代价明显更高。如果业务需要更强的推理/多模态/长文档能力，可以把 B 作为补充；如果只是购车短名单，A 的性价比更好。

1.4 自动化测试是怎么实现的

仓库结构。 代码在 CodeArts Repo（llm-car-eval）：config/ 放模型与场景；data/ 放 13 款车型（运行版本；当前 17 款）与校验脚本；harness/ 放 OpenAI 兼容客户端、3 个工具、解析器、多轮 runner、JSONL 日志；eval/ 放 7 维评分、聚合、5 张图；runs/ 放 18 份原始日志；materials/ 放评分、图表、体验/采访材料；docs/ 放场景、评分规则、runner 说明。仓库链接：CodeArts Repo。

关键设计。

1. 纯标准库 HTTP 客户端：不依赖 openai SDK，直接 POST /chat/completions；从 .env 读 Key，超时 180s，仅对 429/5xx/超时重试 ≤2 次，记录 usage/latency。
2. 多轮 + 工具循环：system prompt 固定角色、场景、硬约束、输出格式；每轮最多 4 次工具调用；工具结果按 tool_call_id 回填；每次运行重置上下文；S3 第 3 轮注入“预算 22 万 + 座椅通风”的变更。
3. 可追溯日志：每次运行一份 JSONL，含 messages、tool_calls、tool_events、usage、latency_ms、run_id、status、error；另有 runs/manifest.csv 汇总 18 行。
4. 三层解析：候选车型（按车型库 ID/名称匹配）、Markdown 表格（支持一屏多表）、最终 JSON（代码块/裸 JSON 兜底）；解析失败标记 parse_error，不直接把整次运行丢掉。
5. 密钥保护：Key 只放本地 .env（已 gitignore），.env.example 只有占位符；提交前 grep -r "sk-"；博客与截图不出现 Key。

怎么复现。

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt
python data/validate.py
python -m harness.runner --all --runs 3
python -m eval.aggregate
python -m eval.charts

没有 Key 时，可以先跑 python scripts/mock_demo.py 生成假数据，验证评分和图表管线；假数据不写进博客。

1.5 评分规则：把“感觉”变成分数

口径说明。 预算按落地价，不按指导价；续航/油耗是“二选一”（纯电看续航，非纯电看油耗）；S3 按变更后的 22 万 + 座椅通风判；D6 看分数波动，不看“是否同一辆车”；D7 的费用按官网价估算（A 输入 8/输出 28 元/百万 token；B 输入 12/输出 36 元/百万 token）。

预注册与修正。 场景、预期合格集、7 维权重在开跑前写进仓库；跑完后只修正了两个实现口径：① S3 第 3 轮是需求变更，没有表格轮次，D3 表格检查只对 S1/S2；② D4 增加“重复工具调用”扣分（原来只算非法调用）。原始 18 份日志全部保留，修正前后的差异在博客中说明，没有改场景、权重或预期集合。

局限。 每模型只有 9 次、每场景 3 次；评分以规则/检查表为主，不能覆盖所有“回答质量”；本次没有做完整的双人独立复评，只对总分、边界案例和关键行做了人工抽查。这些都在 1.9 的局限里说明。

1.6 结果与可视化

总表。

成本与延迟。

图15｜7 维雷达

A 在工具调用、成本延迟更靠外；B 在成本延迟明显收缩；D1/D2/D3/D5 两者重合在 100。差异不在“做对”，在“代价”。

图16｜总分

A 99.5、B 94.8；差距主要来自 D4 工具调用和 D7 成本延迟，不是准确性。总分只适用于本次 18 次任务。

图17｜分场景

S1/S2/S3 两组都很接近；S3 改需求后都没有崩。样本只有每组 3 次，不能据此做显著性判断。

图18｜稳定性

每组 3 次，A 99.7 / B 99.2；分数波动小。推荐不同但都合格不判不稳定，这是 rubric 里提前写好的口径。

图19｜成本-延迟散点

A 集中在左下（低 token/低延迟），B 在右上（高 token/高延迟）；B 的中位延迟约 A 的 3.9 倍、费用约 3.2 倍。

怎么读。

• 准确性打平：D1/D2/D3/D5 都是 100；18 次没有超预算、漏 L2/ISOFIX、JSON 失败或编造车型。
• A 的工具调用更干净：D4 96.7 vs 87.8；B 有 5 次运行出现重复调用，B-S3-r3 重复 4 次。
• B 更慢更贵：中位延迟 3.9 倍、token 2.3 倍、费用 3.2 倍；D7 只有 34.2。
• 稳定性都不错：D6 99.7 / 99.2；同场景 3 次分数波动小。
• 分场景：S1 A 有 1 次元PLUS、2 次秦PLUS，B 三次秦PLUS；S2 两者三次嘉际；S3 两者三次汉DM-i（改需求后都正确）。

结论：在本次任务里，两个模型都能“做对”，差异主要在工程代价。A 更适合批量、低延迟、低成本的购车短名单；B 的思考模式没有带来更高准确率，但可能在其他复杂任务上有优势，本次不外推。

1.7 失败与边界案例

本次 18 次没有出现硬约束失败（没有超预算、漏 L2/ISOFIX、JSON 解析失败或编造车型）。按作业要求“未出现失败可补边界测试并单独标注”，我们写 2 个边界案例，不把“不同但都合格”误判为失败。

案例 1：B 在 S3 重复调用工具（B-S3-r3）。

• 现象：同一任务调用工具 20 次，其中 4 次是同一车型的 calc_landed_price 重复调用：汉DM-i、海豹、Model 3、深蓝S07 各 2 次。
• 证据：runs/B-S3-r3.jsonl 的 tool_events；materials/scores.csv 对应行 tool_duplicates=4、latency_ms=311402、total_tokens=111268。
• 影响：D4 扣 40 分、D7 成本延迟低；最终推荐仍是汉DM-i，结论正确。
• 原因假设：工具结果多、模型忘记已经算过；或思考模式下重复自检。标为假设，未做内部验证。
• 性质：边界/效率问题，不是硬约束失败。

案例 2：A 在 S1 的推荐不完全相同（A-S1-r1 vs r2/r3）。

• 现象：A-S1-r1 首选元PLUS，r2/r3 首选秦PLUS；三款都在预算内、都满足 L2/ISOFIX/能耗。
• 证据：三个 run 的 final_model_id；D1 均 100。
• 影响：按 rubric，推荐不同但都合格不判不稳定；D6 仍 99.7。
• 原因假设：temperature=0.2 仍有随机性；模型对“通勤成本 vs 动力/空间”的偏好不稳定。
• 性质：边界/非确定性，不是失败。

补充：A-S2-r3 对 3 款车重复 get_car_detail 各 2 次（7 次调用、3 次重复），说明重复调用不是 B 独有，只是 B 更明显。

1.8 改进方案与备选方案比较

问题定义。 本次没有硬约束失败，最明显的工程问题是重复工具调用：18 次里 A 有 3 次、B 有 11 次重复，合计 14 次；B-S3-r3 重复 4 次、调用 20 次、延迟 311s。重复调用不改变结论，但会推高 token、延迟和费用。

方案 A（推荐）：工具调用缓存/台账（Tool Call Ledger）。

对 (tool_name, normalized_args) 做哈希；命中缓存就直接返回上次结果，并在提示里写“该参数已查过”，不再发第二次请求。缓存可以放在 runner 层，不改模型；对模型来说，它仍然“看到了结果”，只是不再重复取。

方案 B：提示词自检。

在 system prompt 里加“同一工具同一参数不要重复调用”，让模型输出前自查。实现最便宜，但依赖模型自觉，长上下文下不稳定；本次 B 在 20 次调用里仍重复 4 次，说明只靠提示词不够。

方案 C（不选）：换更便宜的模型/缩短工具结果。

能降成本，但没有解决重复调用本身，且会改变评测对象；不适合作为“改进方案”。

验证方法（无需实现）。 用已有 18 份日志离线回放：统计每个 (tool, args) 的重复次数（共 14 次），估算缓存能省下的调用数、token 和延迟；再抽 6 次新运行做小样本验证，指标是重复调用数、token 降幅、延迟降幅、最终推荐是否变化。预期：重复调用降为 0，token/延迟下降，最终推荐不变。

1.9 评测结论与选型建议

• 总表：A 99.5，B 94.8；D1/D2/D3/D5 都是 100，差别在 D4（96.7 vs 87.8）和 D7（100 vs 34.2）。
• 分场景：S1 A 有 1 次元PLUS、2 次秦PLUS，B 三次秦PLUS；S2 两者三次嘉际；S3 两者三次汉DM-i（改需求后都正确）。
• 结论：本次任务里两者准确性打平；A 的延迟约为 B 的 1/3.9、费用约为 B 的 1/3.2；B 的思考模式没有转化为更高准确率。
• 选型建议：
  • 预算敏感、量大、要低延迟 → A（GLM-5.2）；
  • 需要更强推理/长上下文、能接受 3–5 倍延迟与费用 → 再考虑 B（Qwen3.8-Max）；
  • 生产环境 → 双模型路由 + 规则校验 + 人工复核，不把最终决策完全交给模型。
• 局限：每模型 9 次、单一车型库、模拟价格、未联网、单语言、API 版本可能漂移；18 次合计约 ¥14.33（按官网价估算，以账单为准）；结论不外推到行业排名。

第二部分 分析

2.1 开发时间估计

估计对象 A：本次评测系统。 按模块拆：数据/工具 1.5 人日、harness 3 人日、评分/聚合 2 人日、图表/材料 1 人日、博客/统稿 2 人日，合计约 9.5 人日（约 75 人时）。7 人排期上限 75 人时，实际关键路径约 2.5 天；AI 辅助把“写骨架”压缩了，但数据核对、评分口径、体验/采访、博客统稿没有省。

估计对象 B：把评测能力产品化成 CarFit MVP。 数据/价格源 3 人日、约束引擎 5 人日、工具/详情页 4 人日、前端 6 人日、评测 3 人日、测试 3 人日、PM 2 人日，合计约 26 人日（约 5.2 人周）；3 人并行约 2 周。

方法：分解 + 类比（以前做过的 LLM 推荐/评测）+ 专家判断 + 30% buffer。最容易被低估的是数据清洗、解析/异常、采访与统稿；这次实际也主要耗在这些“非编码”环节。

2.2 程序、软件工程、商业三层分析

模型内部架构、训练数据等不可直接观察，表中只写公开信息；涉及内部原因的判断在 2.5 标为“假设”。

2.3 同类产品对比排名

范围：只比较本次两个模型/两个产品，不构成行业排名；B 的产品体验/采访已由吴军峰补齐（1.3.1/1.3.2），产品 UI 维度不做细分排名。

选型建议：

• 个人偶尔用、预算敏感、要快 → 智谱清言 / GLM-5.2；
• 企业批量集成、要低成本、可接受规则校验 → A；
• 复杂长文档、多模态、需要更强推理且能接受 3–5 倍延迟/费用 → B；
• 高风险决策 → 双模型路由 + 规则校验 + 人工复核。

2.4 软件工程方面的建议

对平台方的建议：更稳定的错误码、工具参数校验、token 计量/费用预估、模型版本弃用公告、固定版本评测沙箱。

2.5 BUG存在的原因分析

5 Whys（重复调用）：为什么重复？模型忘了已经算过 → 为什么忘？上下文里工具结果多、没有“已查询”标记 → 为什么结果多？每次 get_car_detail 返回完整字段、没有摘要 → 为什么不摘要？runner 没有工具结果缓存/台账 → 根因：工具调用层缺少去重与结果复用。这是工程链路问题，不是“模型笨”。

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

正面：把“查资料、比参数、写理由”的时间压缩到几分钟；对不熟悉车的用户，能快速建立短名单；对销售/客服，可做辅助问答；对教育、办公、无障碍等场景，降低信息处理门槛。

风险：幻觉与过度信任（价格/配置说得很像真的）；隐私（对话里可能有家庭、预算、联系方式）；责任归属（推荐错了谁负责）；就业结构（重复性信息工作被压缩）；信息茧房（模型偏好影响选择）。

本次实验的证据：两个模型在 18 次里都能满足硬约束，说明“做对”已经不难；但网页端的价格口径不透明、详情不足，用户仍要自己去核实。结论是：大模型是“能力放大器”，不是“责任主体”；现实路径是“人机协同 + 可验证接口 + 用户教育”，尤其在购车、医疗、金融等高风险决策里。

2.7 市场概况

市场有多大。 据 IDC 报告（转引自智通财经，2026-10-28）：2026 年上半年中国 MaaS 市场规模 106.3 亿元，同比增长 **889.4%**；Token 消耗 2,857.9 万亿，同比增长约 **432.5%**；MaaS 占中国公有云 PaaS 市场比重从 2025 年下半年的 5.2% 升到 **21.0%**；大模型私有化部署市场 28.8 亿元，同比增长 **108.4%**。按上半年简单年化，TAM 约 212.6 亿元（未考虑季节性与下半年增速，仅作量级参考）。

SAM/SOM。 汽车垂直的“购车决策 Agent”没有公开统一口径，我们不做假精确：按 TAM 的 1%–3% 做假设，SAM 约 2–6 亿元/年（团队估算，不是官方数据）；SOM 先看福州高校与本地 4S 店试点：1 个城市、30 款车、2 家店，属于可触达的早期市场。

用户。 C 端直接用户：截至 2026 年上半年，中国生成式 AI 用户规模突破 7 亿、普及率超 **50%**（CNNIC《生成式人工智能应用发展报告（2026）》，2026-10-08）。开发者/企业：IDC 未披露绝对数，用 MaaS 106.3 亿元、Token 2,857.9 万亿作为规模代理。潜在用户：7 亿 C 端中准备购车/换购的人群，叠加车企、经销商、汽车媒体、金融保险；汽车垂类月活未在本次引用，不编。

驱动与风险。 驱动：推理成本下降、Flash/轻量模型可用、工具调用/Agent 成熟、多模态、免费额度获客。风险：价格战、合规/数据安全、数据质量、同质化、模型版本漂移。对本次评测的启示：选型不能只看榜单，要看“任务准确率 + 工具可靠性 + 成本/延迟 + 版本稳定性”。

2.8 产品规划：如果我来做

以“CarFit：可审计的购车决策助手”为例做 NABCD。

N（Need）：用户不信“拍脑袋推荐”；预算/约束多；价格口径乱；需要能解释、能复核。目标用户是首购、家庭换购、帮家人选车的年轻人。

A（Approach）：约束台账（预算/座位/续航/油耗/安全）+ 工具调用（车型库/落地价/保值率/口碑）+ 工具结果缓存（解决本次重复调用）+ 对比卡 + 详情/图片/URL 入口（采访建议）+ 决策报告导出。模型负责解释与取舍，硬约束由规则引擎裁决。

B（Benefit）：不超预算、不漏硬约束、每个结论可溯源；把 2–3 小时比价压缩到 10 分钟；销售/客服也能用；报告可分享，形成获客。

C（Competitors）：汽车之家/懂车帝（数据全但广告多、缺个性化推理）；通用聊天助手（会聊但缺本地价格与约束校验）；4S 店（有报价但利益相关）。CarFit 的差异是“规则 + 模型 + 可审计”。

D（Delivery）：先做 H5/小程序，接 1 个城市 30 款车，找 2 家 4S 店试点；用“决策报告分享”获客；指标：约束满足率 ≥98%、报告导出率、7 日复访、单次任务成本 ≤¥1。

优先级：P0 约束台账 + 工具缓存 + 对比卡；P1 价格明细/来源、详情/图片/URL、用车成本/保值率；P2 经销商报价、试驾预约、多城市。创新点：规则与模型分工、价格口径统一、每个结论可追溯、工具调用可审计。

附录 A 团队分工与过程复盘

贡献度按“实际投入工时 + 交付物 + 不可替代性”自评/互评后取整，不是按论文作者排序；合计 100%。

过程：11-08 建仓、选型实测、跑完 18 次；11-09 补规则/评分/图表、做产品 A 体验与采访；11-10 补产品 B/Part 2；11-11 统稿、14:00 发布、16:00 提交。AI 辅助说明：v0.1 代码骨架由组长与 AI 辅助搭建，评分规则、数据核对、运行复核、体验/采访和结论由人完成；AI 生成内容均经人工检查，未把 AI 输出直接当事实。

复盘：做得好的地方是“先固定数据/场景/规则，再跑”，18 次全部成功、日志可追溯；不足是评分口径在跑后修正了两次（S3 表格、D4 重复调用），说明规则实现前应该先用小样本 dry-run；另外 B 的重复调用暴露了 runner 层缺少工具缓存。下次会把“评分器 dry-run + 工具缓存”放进 pilot 的验收项。

附录 B 总结与反思

三点收获：① 评测设计比“调模型”更重要——同一数据、同一提示词、同一工具，结论才可比；② 工程能力决定评测能不能复现——JSONL、run_id、评分脚本、图表缺一不可；③ 分析要落到证据——每个结论都能指到某个 run 或某张图。

三点不足：样本小（每模型 9 次）、数据是教学模拟、只测了购车一个任务/一种语言；B 的产品体验/采访仍需补；评分以规则为主，不能完全替代人工评审。

下一步：扩到 5 次/场景、接入真实价格源、增加手机/电脑选购等任务、加入人工盲评、把工具缓存/约束台账做成可复用组件。

附录 C 材料索引与复现说明

• 代码仓库：CodeArts Repo llm-car-eval
• 车型数据：data/cars.json（13 款运行版本；当前 17 款；教学模拟；字段/价格口径见 data/schema.md）
• 场景与评分：config/scenarios.yaml、docs/scenarios.md、docs/rubric.md
• 18 份原始日志：runs/*.jsonl + runs/manifest.csv
• 评分与图表：materials/scores.csv、materials/summary.csv、materials/charts/
• 体验/采访：materials/experience-A/、materials/interview-A/
• 复现：

python -m harness.runner --all --runs 3
python -m eval.aggregate
python -m eval.charts

数据声明：本文车型参数来自公开资料整理，价格为统一口径的教学估算，不是实时市场报价；评分只用于本次两个模型的对比，不构成行业排名。