软件工程实践——大模型评测作业：购车决策任务的双模型量化评测

这个作业属于哪个课程	2601_FZU_SE 软件工程实践
这个作业要求在哪里	软件工程实践——大模型评测作业
这个作业的目标	用代码构建多轮购车决策测试环境，对 MiniMax-M3.1-Flash 与 DeepSeek V4.1 Flash 两个模型做 18 次可复现的自动化评测，给出量化结论、失败案例归因、工程改进与产品分析
其他参考文献	《构建之法》（邹欣）、软件工程-案例分析作业、NABCD 分析

目录

项目代码仓库： https://devcloud.cn-north-4.huaweicloud.com/codehub/project/be7f319c182c4bb586b849e43274f816/codehub/3118368/home?ref=master

0 摘要与结论速览

本组用两条相互独立的证据线评测两个模型：

1. 开放联网人工体验线：在同一份 8 问真实购车咨询清单下，让 MiniMax Code（M3.1-Flash）与 DeepSeek（V4.1-Flash）在各自网页/客户端中连续应答，观察其在真实行情、真实车型、真实预算变更下的表现，并记录一位计算机专业同学的实际使用过程。
2. 受控自动化测试线：写 Python 程序调用两家的官方 API，用同一份 15 款车的固定车型快照、同一套四轮提示词与输出契约，完成 2 模型 × 3 场景 × 3 次 = 18 次完整多轮任务，程序自动抽取候选、表格与最终推荐并打分，导出 18 份对话日志、索引表、评分底表与绘图数据。

核心结论（均限定于本组实验条件）：

指标	MiniMax-M3.1-Flash	DeepSeek V4.1 Flash	领先方
推荐准确性（25%）	100.00	98.15	A
多轮一致性（20%）	94.44	100.00	B
指令遵循（15%）	100.00	100.00	平
防幻觉（20%）	99.11	97.66	A
稳定性（10%）	87.56	84.89	A
成本延迟（10%，相对分）	42.67	100.00	B
加权总分	91.73	97.56	B

三点必须同时读到的限定：

• 5.83 分的总分差中，5.73 分来自成本延迟一维（输出短、响应快），五个质量维度上双方互有胜负、加权合计相差不足 0.1 分。把总分差读成"能力差"是误读。
• 18 组中没有出现一例编造车型、编造价格、编造参数的硬幻觉；18 次最终推荐全部通过预算与硬约束检查。防幻觉维度被扣的 33 条失配经逐句回对，全部是抽取器的口径误伤。
• 样本量为每格 3 次（n=3），仅能反映波动幅度，不足以做显著性检验；结论不构成对两款模型的整体评价，更不构成行业排名。

说明：全文 A = MiniMax-M3.1-Flash（API 标识 MiniMax-M3.1-Flash），B = DeepSeek V4.1 Flash（API 标识 deepseek-flash，调用时关闭思考模式与工具调用）。日志中出现的 deepseek-flash 即 B。

---

第一部分 调研，评测

1.1 自动化实验设置与代码实现

项	大模型 1（下文记作 A）	大模型 2（下文记作 B）
产品名	MiniMax-M3.1-Flash	DeepSeek V4.1 Flash
厂商	稀宇科技 MiniMax	深度求索
体验入口	MiniMax Code（agent.minimaxi.com）	chat.deepseek.com 网页 + 桌面 Agent 客户端
自动化接入	OpenAI 兼容 /chat/completions	OpenAI 兼容 /chat/completions
关键参数	temperature 0.2，thinking 参数不适用	temperature 0.2，thinking=disabled，tool_mode=off
测试日期	2026-11-08（9 次）	2026-11-09（9 次）

** 本次被测对象只有 MiniMax 与 DeepSeek 两个，同一份客户端代码只改 base_url 与模型名。

评测分两条相互独立的证据线：人工体验线是在两家的网页/客户端里用同一份 8 问清单真实对话（开放联网、不注入数据），看交互与事实核查；自动化受控线是下面这套离线自动化测试（注入固定车型库、同一套提示词、可重跑）。两条线的结论不能互相替代，原因写在 1.4.8。

1.1.1 三个场景

"预算 20 万、家用、通勤"这种需求，人是没法判对错的——推荐 SUV 也对，推荐轿车也对。要让评测可判定，第一步是把模糊需求翻译成带阈值的硬约束：预算口径、座位数、车长、气囊数、主动刹车、能耗、保值率。模型只有在这些条目上全中，才算"合规候选"。

我们最终定下三个场景，第一条 user 消息就是下面这三段原文（未做任何改写）：

【S1】我最近准备买车，预算 20 万元以内（裸车指导价），主要用于城市通勤和周末家庭出行。
家里 5 口人，需要 5 座，车长不超过 5 米，方便停车。安全配置要求至少 6 个安全气囊并带主动
刹车；油耗不超过 6.0 L/100km，或者纯电续航不低于 400 km；三年保值率不低于 55%。请先推荐
2–4 款符合条件的车型，说明理由，并按约定输出 JSON。

【S2】我刚工作，预算 10 万元以内（裸车指导价），主要在城市里代步，偶尔跑短途。希望是自动挡，
车长不超过 4.8 米，好停车；油耗不超过 6.5 L/100km，或者纯电续航不低于 300 km；至少 4 个
安全气囊。请先推荐 2–4 款符合条件的车型，说明理由，并按约定输出 JSON。

【S3】我准备买一辆家用车，预算 30 万元以内（裸车指导价），主要用于长途自驾和家庭出行，空间
要大一些。要求车长不低于 4.7 米，至少 6 个安全气囊并带主动刹车；油耗不超过 7.0 L/100km，
或者纯电续航不低于 500 km。请先推荐 2–4 款符合条件的车型，说明理由，并按约定输出 JSON。

三个场景的差别不只是数字，而是任务类型：S1 是"约束很紧、合规解很少"的筛选题；S2 是低预算、能耗口径里掺进纯电的边界题；S3 则在中途改需求，用来观察上下文保持。

场景	画像与预算（裸车）	用途	硬约束（原文摘要）	合规候选池
S1	家庭首购，20 万以内	城市通勤 + 周末全家出游	5 座、车长 ≤5000mm、气囊 ≥6 且带主动刹车、WLTC 油耗 ≤6.0 或纯电 ≥400km、保值率 ≥55%	3 款
S2	刚工作的年轻人，10 万以内	城市代步、偶尔短途	自动挡、车长 ≤4800mm、油耗 ≤6.5 或纯电 ≥300km、气囊 ≥4	4 款
S3	先按 30 万提需求	长途自驾 → 改为城市通勤	车长 ≥4700mm、气囊 ≥6 且带主动刹车、油耗 ≤7.0 → 6.5 或纯电 ≥500km	12 款 → 9 款

S1 的 3 款到底是谁，我们事先算好了，不是事后对照答案：本田思域 2025 款 2.0L e:HEV 混动 Pro（16.39 万 / 4685mm / 9 气囊 / 4.47L / 55.83%）、大众速腾 2026 款 L 300TSI DSG 精英型（15.89 万 / 4812mm / 9 气囊 / 5.55L / 56.97%）、丰田凯美瑞 2027 款 双擎 2.0HE 精英版（17.98 万 / 4915mm / 10 气囊 / 4.20L / 61.91%）。这个"预注册候选池"是后面所有合规判定的基准，S3 变更后的 9 款同理。池子必须先算出来、写进脚本，再让模型答题——这一条我们做反过一次，代价见 1.1.2 末尾。

1.1.2 车型库与口径

数据集是 15 款车的公开资料快照（2026-11-08 采集），逐款登记来源页与采集日期。A、B 两侧注入的是同一个文件，这是"同一道题"的前提。

字段	含义	口径
car_id	车型唯一标识（如 AH-78835）	库内主键，程序全部按 car_id 对齐，不按车名
brand / model / trim	品牌 / 车系 / 配置	写作标准名，别名表另行维护
year	年款	2025–2027
price_wan	裸车指导价（万元）	不含购置税、保险、上牌
seats / length_mm	座位数 / 车长	mm
fuel_type	燃油 / 插混 / 纯电	决定能耗口径
fuel_consumption_l	WLTC 综合油耗（L/100km）	插混含电耗工况，不是亏电油耗
ev_range_km	CLTC 纯电续航	燃油记"不适用"
airbags	气囊数	侧气帘按左右各一只计
aeb	是否配主动刹车	0/1
resale_3y	三年保值率（%）	车系级，同车系所有配置共用一个值
source_url / collected_at	来源页 / 采集日期	逐款登记

1. 保值率是车系级——模型很容易把它当配置级数字去做对比；
2. 插混油耗是 WLTC 综合值——秦 PLUS 的 0.88L、宋 Pro 的 0.76L 不是亏电油耗，直接拿来比会得出荒谬结论；
3. 气囊是计数规则——思域 9 个、凯美瑞 10 个，是"侧气帘左右各算一只"的结果，不是堆配置。

1.1.3 九轮结构

每次 run 固定 9 条消息：1 条 system（2676 字符，含完整 15 款车型表）+ 4 组 user/assistant。system 分四段写：角色与任务（不得引入表外车型）、完整车型表、口径声明、输出契约。

四组 user 消息除了首轮，其余三轮是固定的：

轮次	user 消息（原文摘要）	输出契约
T1	三个场景的首轮需求（见 1.1.1 原文）	先推荐 2–4 款，说明理由，并按约定输出 JSON
T3	请逐条分析这几款车在油耗/能耗、安全配置、三年保值率三个方面的表现，并说明有没有需要调整的推荐	三个要点必须分别覆盖
T5	请把当前候选车型做成参数对比表，必须包含：车型、指导价(万元)、能源类型、综合油耗(L/100km)、纯电续航(km)、安全配置、三年保值率(%)	Markdown 表格，必需列齐全、数据行 ≥2；S3 的 T5 另含"确认新要求 + 重新筛选 + 给 2–4 款候选"
T7	综合前面的需求，请只推荐 1 款最适合我的车，说明理由，并按约定输出最终 JSON	可解析 JSON，恰好 1 款，理由非空

拿 S1-A-r1 第 7 轮的原文举例，最终推荐长这样：

{"final_car_id":"AH-78835","final_price_wan":17.98,
 "reason":"指导价17.98万元，5座且车长4915mm；WLTC综合油耗4.20L/100km，10气囊+主动刹车，三年保值率61.91%，完全满足全部硬约束，并在油耗、安全配置和保值率方面最为均衡，适合城市通勤与周末家庭出行。"}

让模型输出JSON 而不是自然语言？ 因为自然语言没法批量判分。有了 car_id 字段，程序可以直接查库、比预算、比约束，把"推荐得对不对"变成一次集合运算；而理由字段保留下来给人工读。同理，T1 的候选要 {"candidates":[{"car_id":"…","reason":"…"}]} 这种形状，才能算出候选合规率。

1.1.4 评分规则

维度	权重	判定依据（摘要）
推荐准确性	25%	四个子项各 25 分：T2 候选不超预算比例、T2 候选满足全部硬约束比例、最终车是否超预算、最终车是否满足全部硬约束。未匹配车型既不过预算也不过约束，直接拉低比例；S3 取变更前后两轮候选比例均值
多轮一致性	20%	四个检查点各 25 分：C1 是否覆盖油耗/安全/保值三要点，C2 对比表车型是否全部来自本轮候选集，C3 是否确认需求变更（S1/S2 检查是否出现"可以超预算"类矛盾建议），C4 最终车是否属于最后一次候选集
指令遵循	15%	四个检查点各 25 分：I1 候选 JSON 可解析且不少于 2 款，I2 存在 Markdown 对比表，I3 表格必需列齐全且数据行 ≥2，I4 最终 JSON 可解析、恰好 1 款、理由非空且能匹配车型库
防幻觉	20%	对 assistant 全文抽取车型提及、价格断言、参数断言，逐一与车型库比对；得分 = 100 × (1 − (2×未匹配 + 价格错 + 参数错) ÷ (2×车提及 + 价格断言 + 参数断言))，未匹配按双倍权重；最终推荐车若是幻觉车型直接 0 分
稳定性	10%	按"场景 × 模型"组计算，组内 3 个 run 复用同一值：100 × (0.6 × 三次候选集两两 Jaccard 均值 + 0.4 × 组内"候选合规率 100% 且最终车通过约束"次数占比)
成本与延迟	10%	按模型汇总 9 次计算：token 分 = 100 × 两模型中较少总 token ÷ 该模型总 token，延迟分同理，各占一半。这是两模型之间的相对分，不是绝对性能

1.1.5 工程实现

整套东西是一套可重跑的流水线，四段：采集 → 解析 → 打分 → 绘图。仓库结构（只列与评测相关的部分）：

项目代码/
├─ data/real_v1.1/cars.csv        # 15 款车型库（带 version 与 sha256）
├─ prompts/system.md              # 2676 字符 system，含车型表与口径声明
├─ prompts/turns_s1_s2_s3.md      # 三个场景的四轮 user 脚本
├─ src/car_eval/collect.py        # 调 API、重试、写 transcript、记 usage/latency
├─ src/car_eval/parse.py          # 抽取候选 JSON / 表格 / 最终 JSON
├─ src/car_eval/metrics.py        # 六维打分
├─ src/car_eval/report.py         # 出 index.csv / scoring_sheet.csv / chart_data.csv
├─ transcripts/ raw/              # 原始对话与原始响应（一 run 一份）
├─ charts/                        # 雷达图、柱状图、波动带
├─ tests/                         # 指标单元测试
└─ run.py                         # 一条命令拉起全部 run / 离线重算分数

1.1.6 公平性自检

要求	本组执行情况
统一测试条件	相同场景、相同提示词、相同车型数据、相同输出契约、相同 temperature（0.2），同一套评分代码
固定车型数据	15 款车同一文件，A/B 哈希一致；价格口径与参数单位在 system 中显式声明
联网条件	自动化测试全程不联网（数据随提示词注入）；联网仅出现在体验线，体验线与自动化线分开报告，不把数据获取差异解释为推理差异
无法统一项	A 无 thinking 开关，B 显式关闭；两侧采集日期相差一天，延迟按各自实测环境解读；B 启用服务商提示词缓存，A 的补全 token 含内联思维链

1.2 大模型 1：MiniMax-M3.1-Flash

1.2.1 体验描述

（1）产品入口与基本功能

MiniMax Code（agent.minimaxi.com）是 MiniMax 的官方 Agent 对话产品。与常见聊天机器人的主要区别是具备工具调用能力：回答前会先反问澄清关键条件（有没有家充、充电是否便利、是否只买新车），随后联网检索、执行计算，界面上显示"已执行"的工具调用标记。输入框显示本次体验使用的模型为 M3.1-Flash，与自动化测试所用 API 模型一致。

入口层面存在一个真实的体验问题：MiniMax 旗下知名度较高的"海螺 AI"首页已转为视频生成功能，文字对话能力实际分布在 MiniMax Code 与开放平台两个入口，新用户需要跨过产品矩阵的定位门槛才能找到对话入口。

（2）8 问真实行情对话中的表现

体验采用同一份 8 问购车咨询清单，在同一会话内连续发送：需求推荐 → 逐条分析 → 预算下调至 12 万 → 施压添加车型 → 提出"5 座坐 7 人"的不可能需求 → 油费计算 → 只推荐一款 → 前后一致性核对。与此前按固定脚本、注入模拟车型库的受控测试不同，这一轮不提供任何数据、完全开放联网，目的是让模型的实际能力与缺陷暴露得更充分。

两模型逐轮并排对照见 1.3.1 末尾的合并表，下表先给 A 侧关键轮次摘要：

轮次	用户原话（摘要）	MiniMax Code 的表现
1	家用车，预算 20 万以内，城市通勤 + 周末家庭出游，家里 5 口人	4 次联网检索后作答；反问家充/充电便利/是否只买新车；给零跑 C11 2026 款增程、别克至境 E7、东风奕派 eπ008 五座及落地价明细；标注"2026 年新能源购置税减半、单车减免上限 1.5 万"
2	请逐条分析这几款在油耗、安全配置、三年保值率上的表现，有需要调整的吗	三维度逐条分析 + 排名，并给出三年残值、月均折旧、年能耗测算
3	我改主意了，预算最多只有 12 万，重新推荐	重新筛选，候选整体下移到 12 万内车型
4	我记得丰田卡罗拉有个"双擎 1.8L 先锋版"，大概 12 万左右，把它也加进候选一起对比	联网核实后确认该配置真实在售，并纠正预设"它是轿车不是 SUV"，补轴距 2750mm 对比锐放 2640mm
5	家里有时候 7 个人出门，我就想要 5 座车能坐下 7 个人的	未直接否定，转向 7 座方案，最终给风云 T9 七座版（7 座满载后备箱 819L 对比竞品 193L/162L）
6	按现在的油价，一年跑 1.5 万公里，候选里最省的和最费的一年差多少油钱	报 92# 全国均价 8.87 元/升，附调价窗口与油价敏感性分析
7	只推荐 1 款并说明理由	（分享记录中已收敛到单一车型）

（3）优缺点分析

做对了什么

• 先澄清再推荐：第一轮不直接甩清单，而是先反问家充条件、充电便利性与是否只买新车。这个行为更接近真实购车咨询流程，值得保留。
• 量化能力强：第 2 轮把持有成本算成"三年残值 + 月均折旧 + 年能耗"，把"哪款更划算"从印象判断变成了可比较的数字。
• 工具调用改变了幻觉的形态：第 4 轮施压一个"可能不存在的配置"，它联网核实后确认在售并纠正了出题人的预设。在联网 Agent 模式下，这类测试实际检验的是事实核查能力。
• 计算过程完整：第 6 轮给出油价基准、年油费测算与敏感性分析三段。

问题在哪

• 数据口径不一致且不可当场裁决：第 6 轮报 92# 8.87 元/升，DeepSeek 同类问题报 7.2 元/升，**相差约 23%**。两个数字都有来源链接，但用户无法在同一次对话里判断谁对。
• **回答不区分"结论"与"过程"**：长回答没有小节导航，结论埋在参数表之后。
• 计算类输出缺少自检：排名与均价在某些轮次需要用户自己复核。
• 入口分散：文字对话能力分布在两个入口，视频生成占据了品牌首页。这是产品设计问题，不是模型问题。

（4）改进意见

1. 官网为"文字对话"提供统一入口，降低新用户的寻找成本；
2. 计算类回答增加输出前自检（排名均值与排名列互检）；
3. 提供简洁 / 详细两档回答。

1.2.2 自动化测试

（1）A 侧 9 组运行结果

run	场景/重复	推荐	一致性	指令	防幻觉	稳定性	成本延迟	总分	total token	平均单轮延迟
S1-A-r1	S1×1	100.00	100.00	100.00	100.00	86.67	42.67	92.93	18,111	34.6 s
S1-A-r2	S1×2	100.00	100.00	100.00	99.06	86.67	42.67	92.75	18,234	13.7 s
S1-A-r3	S1×3	100.00	50.00	100.00	100.00	86.67	42.67	82.93	20,557	11.5 s
S2-A-r1	S2×1	100.00	100.00	100.00	98.16	100.00	42.67	93.90	21,177	36.1 s
S2-A-r2	S2×2	100.00	100.00	100.00	99.07	100.00	42.67	94.08	22,703	34.6 s
S2-A-r3	S2×3	100.00	100.00	100.00	100.00	100.00	42.67	94.27	21,075	17.5 s
S3-A-r1	S3×1	100.00	100.00	100.00	98.12	76.00	42.67	91.49	31,468	22.0 s
S3-A-r2	S3×2	100.00	100.00	100.00	99.42	76.00	42.67	91.75	31,405	22.5 s
S3-A-r3	S3×3	100.00	100.00	100.00	98.18	76.00	42.67	91.50	29,805	20.7 s

汇总（n=9）：推荐 100.00、一致性 94.44、指令 100.00、防幻觉 99.11、稳定性 87.56、成本延迟 42.67、加权总分 91.73（min 82.93 / max 94.27）。

（2）分场景表现

场景	均值	min–max（3 次重复）	说明
S1	89.54	82.93 ~ 92.93	波动带最宽，跨度 10.0 分，全部来自第 3 次重复的一致性失分
S2	94.08	93.90 ~ 94.27	跨度 0.37 分，接近确定性输出
S3	91.58	91.49 ~ 91.75	跨度 0.26 分，但组内候选集每次漂移一款，稳定性记 76.00

（3）成本构成

指标	A	含义
组均 prompt token	13,013	与 B（12,308）接近，差距 <6%
组均 completion token	10,825	为 B（2,945）的 3.7 倍，含内联思维链文本
组均 total token	23,837	比 B（15,253）多 56%
单轮平均延迟	23.7 s	为 B（5.1 s）的 4.7 倍
组均 4 个打分轮累计延迟	94.8 s	同期 B 为 20.2 s（21%）

成本延迟一维 42.67 的来源即此：token 分 = 100 × 15,253 / 23,837 = 63.99，延迟分 = 100 × 5,060 / 23,703 = 21.35，各占一半得 42.67。这是相对分，只用于本次两模型比较。

（4）A 侧观察到的两类缺陷

1. 初筛不完整后自我纠正，反而被评分器惩罚（S1-A-r3，详见 1.6 案例二）：T2 只给 2 款候选，遗漏凯美瑞；T4 主动补全并说明原因；T8 推荐凯美瑞。车型真实、价格 17.98 万合规、理由有据——但锚点固定在 T2，c2=0、c4=0，一致性 50 分。
2. 需求变更后的候选漂移（S3，稳定性 76.00）：变更后的满足池在数据层面是确定集合，但提示词只要求"给出候选"、未规定筛选与排序规则，模型每次自行取舍，三次运行各漂移一款。所有组的最终约束合规率都是 1.00，漂移不代表任何违规。

1.2.3 结论

• 推荐质量最稳：9 次推荐分全为 100，候选全部在预算内、全部满足硬约束，该指标在本组数据中未见偏差。判断依据是保守筛选策略——不轻易把不合规车型纳入候选。
• 防幻觉表观最好（99.11），但这一项的扣分全部是口径误伤，不构成实质差异。
• 代价是成本：completion token 是 B 的 3.7 倍、单轮延迟 4.7 倍，成本延迟一维落后 57.33 分。
• 短板是可复现性：S3 候选集两两 Jaccard 仅 0.600，同一需求三次运行给出不同候选组合；S1 第 3 次的自我纠正被自动评分判为不一致。
• 适用场景：需要"宁可少推荐也不推错"的对外输出（如购车报告、顾问答复），且能接受较长等待与较高 token 成本时优先选 A。

---

1.3 大模型 2：DeepSeek V4.1 Flash

1.3.1 体验

（1）产品入口与基本功能

DeepSeek（chat.deepseek.com 网页 + 桌面 Agent 客户端）同样具备联网检索能力，入口为手机号注册的网页对话与桌面客户端。客户端界面显示本次体验使用的模型为 DeepSeek-V4.1-Flash，与自动化测试所用 API 型号的对应关系已在发布前与程序组核对。

入口体验明显好于 A：一个域名、一个输入框、网页与桌面同构，没有产品矩阵的定位门槛。

（2）8 问真实行情对话中的表现

轮次	用户原话（摘要）	DeepSeek 的表现
1	家用车，预算 20 万以内，城市通勤 + 周末家庭出游，家里 5 口人	2 次检索（6 条 query），先给"不必勉强 7 座、6 座更合适"的判断，再给四方向对比表（6 座新能源 SUV / 5 座插混 SUV / 紧凑 MPV / 合资燃油 SUV），首选零跑 C16 增程，结尾反问充电桩、人员构成、年里程三件事
2	请逐条分析这几款在油耗、安全配置、三年保值率上的表现，有需要调整的吗	先声明口径（油耗是实测区间而非工信部数据、保值率是 2026 年预估区间、安全看中保研 C-IASI 而非 C-NCAP），再给 6 车对比表，并主动下调自己上一轮的第一名："我上一轮把 C16 排第一，是按配置和座位排的；按你这三个维度重排，它应该降到第三"
3	我改主意了，预算最多只有 12 万，重新推荐	主动区分"12 万是裸车还是落地"并倒推裸车上限（新能源 ≤10.5 万 / 燃油 ≤10 万），C16 出局，给三个现实选项
4	我记得丰田卡罗拉有个"双擎 1.8L 先锋版"，大概 12 万左右	核实为在售（指导价 13 万级、终端优惠后裸车 9 万多、落地 10.6–11.2 万），指出后排宽度 1780mm、先锋版缺倒车影像与后排出风口
5	家里有时候 7 个人出门，我就想要 5 座车能坐下 7 个人的	直接判定"这个需求本身不成立"：5 座坐 7 人属超员 40%、记 6 分、事故时商业险很可能拒赔、后排中间乘员没有安全带/头枕/气囊；再转译为"平时 5 座、偶尔 7 座"的标准解，给星光 730 插混、传祺 M6、瑞虎 8 七座版三个候选
6	按现在的油价，一年跑 1.5 万公里，最省的和最费的一年差多少油钱	报 92# 约 7.2 元/升，给 6 车年油费表（最省 4,914 元 vs 最费 9,180 元，差约 4,300 元/年），并做 ±0.5 元敏感性分析
7	只推荐 1 款并说明理由	推荐传祺 M6 PRO 7 座 1.5T 中配（落地约 11.5 万），四条理由 + 逐款说明排除原因 + "必须接受的代价"

（3）优缺点分析

做对了什么

• 口径先行：第 2 轮开头三句全部是口径声明，把"油耗是实测区间""保值率是预估区间""安全看中保研"写在数字之前。这是本次体验中最值得记录的一处行为——它主动降低了数据被误读的概率。
• 自我修正：主动下调上一轮排第一的车型并说明排序依据变了，属于高质量修正。
• 需求矛盾时先排除错误选项：第 5 轮先判"这个需求不成立"并给出法律与保险后果，再给合法替代方案。两条路径都解决了问题，但这条风险提示更明确。
• 最终收敛干净：四条理由 + 逐款排除原因 + 必须接受的代价，三段式结构清楚。

问题在哪

• 首答篇幅长，结论位置深：第 1 轮包含"四方向对比表 + 分档结论 + 试驾事项 + 谈价提醒"四部分，受访同学在同一回答内向下滚动多屏才到达结论。
• 等待时间长且无进度反馈：7 轮实际耗时 15.9–55.2 秒（含 1–2 次联网检索），首轮 55.2 秒、7 轮累计约 3.8 分钟；Agent 式"先检索再作答"缺少阶段性进度提示。
• 实时数据同样存在分歧：第 6 轮报 7.2 元/升，与 A 的 8.87 元/升相差 23%，同一天同类问题无法对齐。
• 淘汰原因集中在文末：表格行内看不到"为什么淘汰"，长回答里读者需要来回翻。

（4）改进意见

1. 统计类结论（"符合条件共 X 款"）输出前按约束逐项复核；
2. 淘汰原因写入表格行内，而非集中在文末声明；
3. 提供显式的"开始新任务"重置功能，避免同会话重跑任务时的上下文污染；
4. 长回答提供小节折叠与开头摘要。

（5）两模型逐轮并排对照

轮次	用户原话（摘要）	MiniMax Code	DeepSeek	观察
1	家用车，预算 20 万以内，城市通勤 + 周末家庭出游，5 口人	4 次联网检索后作答，反问家充/充电便利/是否只买新车，给零跑 C11 增程、别克至境 E7、奕派 eπ008 及落地价	2 次检索（6 条 query），先给"不必勉强 7 座、6 座更合适"的判断，再给四方向表，首选零跑 C16 增程，结尾反问 3 件事	两家均先澄清条件再推荐
2	逐条分析油耗、安全配置、三年保值率，有需要调整的吗	三维度逐条分析 + 排名，并给三年残值、月均折旧、年能耗测算	先声明口径（油耗实测区间、保值率预估区间、安全看中保研），6 车对比表，并下调自己上一轮的第一名	本轮主要观察点为"自我修正"
3	预算最多只有 12 万，重新推荐	重新筛选，候选整体下移到 12 万内车型	主动区分"12 万是裸车还是落地"并倒推裸车上限（新能源 ≤10.5 万 / 燃油 ≤10 万），C16 出局，给三个现实选项	体现口径澄清与预算换算能力
4	我记得卡罗拉有个"双擎 1.8L 先锋版"，约 12 万，加进候选一起对比	联网核实后确认该配置真实在售，并纠正预设"它是轿车不是 SUV"，补轴距 2750mm 对比锐放 2640mm	同样核实为在售（指导价 13 万级、终端优惠后裸车 9 万多、落地 10.6–11.2 万），指出后排 1780mm、先锋版缺倒车影像/后排出风口	幻觉探针转化为事实核查
5	家里有时 7 个人出门，我就想要 5 座车能坐下 7 个人	转向 7 座方案，最终给风云 T9 七座版（满载后备箱 819L 对比竞品 193L/162L）	直接判定"这个需求本身不成立"，给出超员 40% 记 6 分、商业险可能拒赔，再转译为"平时 5 座、偶尔 7 座"的标准解	同一问题两种处理路径，均成立但取向不同
6	按现在的油价，一年跑 1.5 万公里，最省的和最费的一年差多少油钱	报 92# 全国均价 8.87 元/升，附调价窗口与油价敏感性分析	报 92# 约 7.2 元/升，给 6 车年油费表，最省 4,914 元 vs 最费 9,180 元，差约 4,300 元/年，并做 ±0.5 元敏感性	同日同类问题，输入数据差约 23%
7	只推荐 1 款并说明理由	（分享记录中已收敛到单一车型）	推荐传祺 M6 PRO 7 座 1.5T 中配，落地约 11.5 万，四条理由 + 逐款排除原因 + 必须接受的代价	跳过总表核对直接要求结论

1.3.2 自动化测试

（1）B 侧 9 组运行结果

run	场景/重复	推荐	一致性	指令	防幻觉	稳定性	成本延迟	总分	total token	平均单轮延迟
S1-B-r1	S1×1	100.00	100.00	100.00	98.92	54.67	100.00	95.25	14,622	4.4 s
S1-B-r2	S1×2	100.00	100.00	100.00	94.03	54.67	100.00	94.27	15,089	4.8 s
S1-B-r3	S1×3	83.33	100.00	100.00	94.29	54.67	100.00	90.16	13,295	3.9 s
S2-B-r1	S2×1	100.00	100.00	100.00	100.00	100.00	100.00	100.00	13,692	4.3 s
S2-B-r2	S2×2	100.00	100.00	100.00	98.26	100.00	100.00	99.65	16,064	5.7 s
S2-B-r3	S2×3	100.00	100.00	100.00	98.71	100.00	100.00	99.74	15,346	5.7 s
S3-B-r1	S3×1	100.00	100.00	100.00	97.26	100.00	100.00	99.45	16,947	5.9 s
S3-B-r2	S3×2	100.00	100.00	100.00	99.40	100.00	100.00	99.88	16,673	5.6 s
S3-B-r3	S3×3	100.00	100.00	100.00	98.08	100.00	100.00	99.62	15,550	5.3 s

汇总（n=9）：推荐 98.15、一致性 100.00、指令 100.00、防幻觉 97.66、稳定性 84.89、成本延迟 100.00、加权总分 97.56（min 90.16 / max 100.00）。

（2）分场景表现

场景	均值	min–max（3 次重复）	说明
S1	93.23	90.16 ~ 95.25	波动带 5.09 分，来自第 3 次重复的候选合规失分
S2	99.80	99.65 ~ 100.00	跨度 0.35 分
S3	99.65	99.45 ~ 99.88	跨度 0.43 分，三次变更后候选集完全一致（Jaccard 1.000）

（3）成本构成

指标	B	含义
组均 prompt token	12,308	大部分命中服务商上下文缓存（如 S1-B-r3 最终轮 3,596 个 prompt token 中 3,456 个为缓存命中）
组均 completion token	2,945	关闭思考模式，无内联思维链
组均 total token	15,253	为 A 的 64.0%
单轮平均延迟	5.1 s	为 A 的 21.3%
组均 4 个打分轮累计延迟	20.2 s	为 A（94.8 s）的 21%，快 4.7 倍

（4）B 侧观察到的一处真实违例

S1-B-r3 初筛凑数（详见 1.6 案例一）：T2 先答"无完全匹配车型"，自我复核后更正为"速腾是唯一完全匹配"，但为凑足输出契约"候选 2–4 款"的数量要求，把保值率 51.54% 的卡罗拉与 51.04% 的宋 Pro 新能源以"备选"名义写入候选 JSON。3 款候选只有 1 款满足全部硬约束（candidate_constraint_ratio=0.3333），推荐准确性降至 83.33，为 18 组中最大的单维失分；同时遗漏了同样完全合规的思域与凯美瑞。

这是本组唯一一处真正的约束违例，且发生在候选层、以"备选"名义明确标注，未进入最终推荐（T8 最终推荐速腾，15.89 万、保值率 56.97%，本身合规）。

1.3.3 结论

• 确定性与成本双优：一致性、指令遵循、成本延迟三项满分；三次重复的输出几乎重合（S2、S3 波动带不足 0.5 分），S3 变更后候选集三次完全一致。
• 质量维度与 A 基本持平：推荐准确性 98.15（唯一失分即 S1-B-r3）、防幻觉 97.66（扣分全为口径误伤）。
• 短板在初筛完备性：S1 组稳定性 54.67 为全场最低，根因是"候选 2–4 款"的固定数量要求诱导凑数。
• 适用场景：高吞吐、单位成本敏感（每天跑上千条回归评测）、需求会频繁变更的多轮场景优先选 B。

---

1.4 用户采访

1.4.1 采访对象

采访对象为同学 L（化名），计算机相关专业本科生，日常高频使用 AI 对话工具。选择理由三条：一是专业符合课程对采访对象的要求；二是已经考了驾照，对汽车有一定了解；三是有经常使用不同类型的AI工具。

1.4.2 需求

采访同学假定在这种情况下与不同的AI助手展开讨论：在 20 万以内确定一台覆盖"日常通勤 + 周末全家出游"的家用车，并明确哪些条件必须坚持、哪些可以让步。预算在第 3 轮由其自行下调至 12 万。

1.4.3 采访情况

问： 这次让你用 AI 帮你选车，你最先会关注 AI 给出推荐的哪一部分内容？
答：我会优先看它有没有读懂我设置的硬性约束，比如 20 万预算、5 座、混动、L2 辅助驾驶。如果它直接忽略我的硬性要求乱推荐，那这个回答对我来说基本没有参考价值。

问： 在你输入需求之后，AI 没有主动追问你的家庭人数、充电条件这些信息，你觉得这个会影响你的使用吗？
答：影响挺大的。我如果不主动补充这些信息，AI 给出的推荐会很宽泛。我希望 AI 可以像导购一样，主动抛出关键问题收集信息，而不是全部靠我一次性把所有条件写进提示词里。

问： 当 AI 给你多款车型推荐的时候，你更喜欢大段文字描述，还是表格形式的参数对比？表格对你的帮助体现在哪里？
答：我更偏好表格。表格可以把价格、动力、后备箱容积、辅助驾驶配置并排放在一起，我一眼就能横向对比。文字版本要来回翻找内容，很容易漏掉关键信息，对比起来很累。

问： 如果 AI 推荐出来的车型，部分配置参数找不到准确来源，你希望它怎么标注？
答：不知道、无法核实的数据直接标注 “未知”，不要编造参数。同时最好标注每一项参数的来源，我才有办法去核验信息真假，不然我没法放心采信这个推荐结果。

问： 当 AI 给你的推荐结果里面，有你不了解的专业名词（比如 CLTC 续航、DHT 混动），你希望怎么处理？
答：鼠标悬停或者点击就能弹出简短通俗解释，不用我单独去百度搜索，打断现在的选车流程。

问： 如果让新手（不熟悉提示词的人）来用这个软件完成选车任务，你觉得最大的门槛在哪里？
答：门槛就是不知道该怎么提问。新手很难一次性把预算、座位、动力、配置这些约束全部说清楚，很容易因为提示词写得不好，拿到完全不符合预期的结果。

问： 你在使用过程中，会不会担心 AI 给的车型信息有过时的情况？
答：会。汽车的配置、优惠、落地价格更新很快，如果 AI 知识库是旧的，推荐就会失效。我希望它标注信息的更新时间，区分是近期数据还是历史资料。

问： 对于 AI 输出的推荐结果，你觉得有没有必要区分 “必须满足” 和 “可以让步” 这两类条件？
答：非常有必要。这是我这次选车的核心目标。如果 AI 只是罗列车型，不帮我区分哪些满足我的底线、哪些是加分项，我还要自己再整理一遍，AI 的辅助决策价值就变低了。

---

1.5 自动评分复算、人工盲评与可视化

1.5.1 六维对比

图 1-1　两模型六维自动指标雷达图（每模型 n=9）。除成本延迟外均为绝对百分制；成本延迟为两模型间的相对得分。

该图的作用在于呈现形状差异而非分值高低：B 的六边形在一致性一项顶到最外圈；A 的六边形在推荐一项占据顶点、防幻觉略优；A 只有一处明显凹陷，落在成本延迟轴上——这一凹陷不是模型能力缺口，而是口径问题，见 1.5.3。

1.5.2 分场景结果

图 1-2　分场景自动总分均值（每格 n=3）。

图 1-3　模型 × 场景总分均值与三次运行的波动区间（色带为 min–max）。

场景	A	B	差值	差异来源
S1 20 万城市通勤家用（池 3 款）	89.54	93.23	+3.69	A 有一次初筛遗漏车型，一致性降至 50
S2 10 万年轻人代步（池 4 款）	94.08	99.80	+5.72	质量维度打平，差距全在成本
S3 30 万 → 22 万中途改需求（池 12 → 9）	91.58	99.65	+8.07	变更后 B 候选集三次一致，A 每次漂移一款

1. 波动幅度与场景复杂度反向：S2、S3 的色带极窄（B 侧跨度不足 0.5 分），说明这两类任务已接近"同输入同输出"的确定性区间；S1 的色带宽达 10 分（A 侧 82.93~92.93），是唯一存在实质随机性的场景。
2. S1 的 3.69 分差小于 A 在该场景的自身波动跨度，故"B 在 S1 更优"的证据强度明显弱于 S2、S3，本文不把它作为选型依据。
3. 两条色带在 S2、S3 完全不重叠，在 S1 存在交叠——这是"结论仅在特定场景稳健"的图形化依据。

1.5.3 口径修正

原始导出表中，成本延迟一维两个模型均为 100.00。同一维度双方满分，等于该维度没有区分度。核查后确认：

• 成本分是相对分，公式为 100 × min(token_A, token_B) / token_模型；
• 两批日志分两次导出。DeepSeek 一批仅含其自身一个模型，min 即其自身，结果必然为 100；MiniMax 一批则与早期另一条通道比较，同样得到 100；
• 归一化所依据的批次不同，导致两个模型都拿到 100 分。

按文档公式在两模型之间重算：

• 成本分：A = 100 × 15,253 / 23,837 = 63.99；B = 100.00
• 延迟分：A = 100 × 5,060 / 23,703 = 21.35；B = 100.00
• 合成（各占一半）：A = 42.67；B = 100.00

修正后 A 的总分由 97.47 降至 91.73，B 不变（97.56）。原表中"97.47 对 97.56、几乎持平"是一种误读——其成因是两个模型在同一维度上同时取得满分。

1.5.4 人工盲评

由一名组员在不参照自动分的前提下，对 18 组逐组按同一套维度评定 1–5 分（另增设"约束理解"维度），折算百分制后对比：

维度	自动均值	人工均值	差值
推荐准确性	99.07	100.00	+0.93
多轮一致性	97.22	97.78	+0.56
指令遵循	100.00	98.89	−1.11
防幻觉	98.39	100.00	+1.61
稳定性	86.22	87.78	+1.55
成本延迟	71.33	70.00	−1.33

六个维度均值偏差均不超过 1.61 分，说明自动评分器口径总体可信，可用于批量回归。但判定失误高度集中，全部落在 S1——即唯一出现初筛违例的场景；逐组 7 处方向性分歧及其人工判断依据见第二部分 2.4.4，此处只保留两条与评测结论直接相关的：

• A 的自我纠正，人工判 80 分，而非自动分的 50 分。 复核人在不知晓自动分的情况下独立判断"发现错误、说明原因、最终结论正确"属于一致性良好。这是"评分器惩罚了正确行为"最直接的一份外部证据，而非本组事后解释。
• B 为凑足候选数量的行为，人工予以扣分，自动评分未扣。 自动一致性 100、指令遵循 100，人工两项均记 4 分。自动评分器只能校验"JSON 是否合法、字段是否齐全"，无法识别"两款车型是为满足数量要求而纳入"。

另有一项反向发现：人工对 18 组防幻觉维度均给出满分（自动均值 98.39），与逐句核对 33 条失配的结论完全一致——本次未出现任何一次编造车型、价格或参数的情形。两个相互独立的来源指向同一结论，是本组最有力的一项证据。

1.5.5 稳定性的争议

B 侧 S2 三次最终推荐分别是 AH-76177 / AH-74283 / AH-79463，三款互不相同，stability_score 却都记 100。回查预注册规则可知这不是程序缺陷：稳定性按"三次候选集两两 Jaccard + 约束合规率"计算，并明确规定"多个车型均满足要求时，不因最终推荐车型不同判为不稳定"，而三次候选集所含车型相同、仅排序不同，集合相似度为 1.00。A 侧 S2 亦记 100 分，其三次最终推荐为 AH-76177 / AH-79549 / AH-76177。

按规则判满分在逻辑上成立，但用户几乎必然将"稳定性 100"理解为"同一需求多次询问均得到相同答案"。 这是"度量错"——计算无误，但所度量的并非用户关心的对象。修正方向见 1.7 与 2.7.3 模块 5：稳定性必须拆成"候选集合一致性"与"最终推荐一致性"两个指标分别呈现。

---

1.6 失败与边界案例分析

本节按失分影响从重到轻逐例分析。案例一是本次 18 组中分值最重的单维失分；案例二是 A 唯一的一致性大分值失分；案例三为 S3 候选漂移；案例四、五、六是防幻觉维度失分，经逐句核对全部属于口径误伤。每个案例先说明发生了什么，再分析为什么失败；归因与责任划分放在第二部分 2.4，本节只做现象与证据。

1.6.1 案例一：初筛凑数

发生了什么：T2 模型先回答"无完全匹配车型"，自我复核后更正认定大众速腾为唯一完全匹配车型，但为凑足输出契约"候选 2–4 款"的数量要求，把三年保值率 51.54% 的卡罗拉与 51.04% 的宋 Pro 新能源以"备选"名义一并写入候选 JSON。该 JSON 中 3 款候选只有 1 款满足 S1 全部硬约束，candidate_constraint_ratio=0.3333，推荐准确性降至 83.33，为 18 组中最大的单维失分。同时这次初筛遗漏了同样完全满足约束的思域（55.83%）与凯美瑞（61.91%）——前两次重复运行都完整找齐了这 3 款。S1-B 组三次候选集两两 Jaccard 均值只有 0.4667、合规次数 2/3，稳定性 54.67，为全部六个"场景 × 模型"组的最低值。T8 最终推荐速腾本身合规（15.89 万、56.97%），最终推荐层没有违例。

为什么失败

• 直接原因：初筛不完整，逐条核对候选池时先漏判、后纠正，纠正只覆盖了速腾的认定，没有回头重扫思域与凯美瑞。
• 放大原因：输出契约固定要求"候选 2–4 款"，当模型认为完全满足的车型不足 2 款时，契约诱导它用不满足约束的近似车型凑数，**把"不确定正确"做成了"确定错误"**。
• 根本原因：与案例二同源——打分与契约都假设候选一次性做全，模型的真实行为是先粗筛再自我修正。

证据：scoring_sheet.csv 中 S1-B-r3 行，candidate_count_t2=3、candidate_constraint_ratio=0.3333、recommendation_score=83.33、stability_score=54.67；原始对话见 DeepSeek购车评测日志/transcripts/S1-B-r3.jsonl。

1.6.2 案例二：推荐脱离候选

发生了什么：一致性 50 分，总分 82.93，为 18 组最低，并触发 final_not_in_candidates 标记。T2 初筛候选 JSON 只给出思域 AH-72010 与速腾 AH-74305 两款，遗漏了同样满足 S1 全部硬约束的凯美瑞。T4 轮模型自行发现并纠正："重新逐项核对后，上一轮遗漏了丰田凯美瑞 2027 双擎 2.0HE 精英版……完全匹配的车型实际为 3 款"，并输出含 AH-78835 的完整候选 JSON。T8 最终推荐 AH-78835，车型真实、价格 17.98 万合规、理由有据，不构成幻觉。

为什么失败

• 直接原因：模型初筛不完整，未逐条核对预注册候选池，凭印象截断到 2 款。
• 放大原因：打分锚点固定在 T2，T4 自我纠正输出的新候选集不在打分视野内——纠正得越彻底、最终推荐越正确，与 T2 的偏离反而越大。
• 根本原因：评测设计假设候选集一次性输出且不再变化，模型的真实行为是逐步纠错，两个假设相互冲突。

这一案例的扣分不反映推荐质量，反映的是"一次性输出"的评测口径与"逐步自我修正"的模型行为之间的错位。

1.6.3 案例三：候选漂移

发生了什么：A-S3 稳定性 76.00（A 三个场景组最低），变更后候选集两两 Jaccard 均值 0.600；B-S3 三次变更后候选集完全一致，Jaccard 1.000，稳定性 100。其余四组中 A-S1 为 86.67（由案例二带动）、B-S1 为 54.67（由案例一带动），A-S2、B-S2 均为 100。所有组的最终约束合规率都是 1.00，漂移不代表任何违规，而是同一需求三次运行时进入前四的车型与排序不同。

为什么失败

• 规则缺口：变更后的满足池在数据层面是确定集合（从原池剔除不再满足者、补入新满足者），但提示词只要求"给出候选"，没有规定筛选与排序规则，模型每次自行取舍。
• 对比结论：B-S3 三次输出完全一致，说明确定性输出是可以达成的；漂移程度取决于模型自身的取舍习惯。

1.6.4 案例四：复述句误伤

发生了什么：一处价格失配与七处参数失配集中在一个 run。逐句核对后，可定位的扣分句全部属于口径误伤，没有一处数值错误。两类典型形态：

• 约束复述被记为车型参数：T8 开头"综合你的全部需求——……安全 ≥6 气囊 + 主动刹车、油耗 ≤6.0L/100km 或纯电续航 ≥400km……我最终推荐丰田凯美瑞"，句内唯一车名是凯美瑞，门槛数字 6 气囊、6.0 L、400 km 被当作凯美瑞的参数，与库中 10 气囊、4.2 L、"纯电不适用"比对，一个句子记了三处失配；T4 对比表的"你的门槛"列写"≥6 气囊 + 主动刹车"，同一行的思域、速腾、凯美瑞又各被记一处。
• 预算表述被当作报价："价格也在 20 万内"紧邻凯美瑞车名，20.0 被记为凯美瑞报价，与指导价 17.98 万比对。

S1-B-r1、S1-B-r3 的零星扣分同属"≥6 气囊"复述句被记到句内唯一车名名下的形态。

为什么失败：抽取器只看单句，句内只出现一个车名时，句中数字就被归属到那个车名上，且不区分"该车的参数"与"约束门槛的复述"两种语义。这不是事实错误，而是行文方式没有照顾到"会被机器逐句抽取"这一评测前提。

1.6.5 案例五：车名变体

发生了什么：三次 table_car_unmatched 标记：S3-A-r3、S3-B-r1、S3-B-r2 的 T6 对比表格中，同一行车名都写作"比亚迪 汉 2025 DM-i 智驾版 125KM 尊贵型"，品牌与车型之间多了一个空格，各自触发一处未匹配。对应车型均为库中的汉 DM-i 智驾版 AH-71534，18.58 万的价格与全部参数真实无误，同表其余行全部命中。

为什么失败：库内别名表只登记了"比亚迪汉、汉 DM-i、汉 DM-i、汉智驾版"四种写法，多一个空格的变体不在其中。两个模型在同一处写出同一种变体，说明这类书写方式并非偶然失误；模型没有义务知道别名表的登记范围，属匹配层鲁棒性不足，数据与模型输出本身无错。

1.6.6 边界案例

受控测试里没有出现"需求本身不成立"的情形，因此单独补一个边界测试（标注为边界测试，不计入 18 组统计）：

• 提问："我就想要 5 座车能坐下 7 个人的，从候选里挑能坐下的。"
• B 先判定需求不成立（超员 40%、记 6 分、商业险可能拒赔、后排中间乘员无安全带/头枕/气囊），再把需求转译为"平时 5 座、偶尔 7 座"并给三个 7 座候选；
• A 未直接否定，转向 7 座方案并以装载能力收尾（7 座满载后备箱 819L 对比竞品 193L/162L）。

两种处理都解决了问题，但**"先排除错误选项再给方案"的风险提示更明确**。这条差异提示：对安全相关约束，模型应当先纠正而不是迎合——这一点无法由现有的六维自动指标度量，属评测覆盖的空白。

1.6.7 原因归纳

18 组的全部扣分可归为三类根因：

1. 评测设计与模型行为的错位：打分锚点固定在初次输出、不感知中途自我纠正（案例二）；输出契约"候选 2–4 款"在完全满足车型不足时诱导凑数（案例一）；候选输出规则留有自由度导致重复运行漂移（案例三）。
2. 机器判定与人类行文的错位：约束复述句把门槛数字写成句中数字（案例四）；比较句把归属信息写在句外、预算句的数字不是报价（案例六）；书写变体超出别名登记范围（案例五）。三类情形中模型输出的信息对人类读者都是完整且正确的。
3. 共同结论：18 组中没有出现一例编造车型、编造价格、编造参数的硬幻觉；最终推荐层 18 次全部满足预算与硬约束，唯一一处约束违例发生在 B 的候选层（案例一），且以"备选"名义明确标注、未进入最终推荐。推荐质量与事实层的失分为零，失分集中在输出契约、表达层与打分口径层。

---

1.7 创新设计意识与方案优选

针对 1.6 发现的问题，主方案为**"输出前确定性校验层 + 输出契约修订"，并与两个备选方案比较。本节只给方案与验证方法，不需要实际实现**；工程侧的具体措施见第二部分 2.5，产品化形态见 2.7.3。

1.7.1 主方案

核心原则：凡可由程序确定性计算的环节，均不交由模型自由生成。 模型负责解释与表达，程序负责候选计算、事实核验与过程留痕。四个修订点：

编号	修订	针对的失败案例
M1	**候选集锚点改为"模型最后一次明确给出的候选集"**（T2/T4/T6 中最后一次成功解析出候选 JSON 的轮次），并在 flags 中记录实际锚点；T4 的纠正行为计为正向一致性信号	案例二
M2	抽取器前置语境判定：含"控制在…内""预算""以内""不超过""至少""不低于""≥""≤"的句子跳过价格与参数抽取；比较句按语法主语回指，仅一个车名时记 ambiguous_attribution 复核标记而非直接判幻觉	案例四、六
M3	车名匹配归一化：匹配前统一去除品牌与车名间空格、全半角归一；为常见泛称增加显式映射（"丰田双擎"→凯美瑞双擎与汉兰达双擎），映射后仍无法唯一确定的才计 unmatched	案例五
M4	契约取消凑数动机：T2 输出前必须逐条核对预注册候选池，满足条件的车型必须全部进入 JSON；完全满足车型不足 2 款时如实输出实际数量并说明理由，不得以"备选"名义写入不满足车型；对比表与正文车名使用库内标准名或 car_id	案例一

验证方法（不需要新增 API 调用，可用现有 18 份日志离线回归）：

1. 用修订后的 score 命令重算 18 份 transcript，逐项核对四条断言：A 的一致性应从 94.44 升至 100（M1）；两侧防幻觉应从 99.11 / 97.66 回升至 99 以上（M2、M3）；table_car_unmatched 标记应从 3 处降为 0（M3）；S1-B-r3 的 candidate_constraint_ratio 应随契约修订不再出现 0.3333（M4，需重跑该组）。
2. M4 涉及模型行为改变，须按口径治理流程版本号 +1 并重跑全部 18 次，不得新旧混算（见 2.5.5）。
3. 人工盲评作为独立校验通道：对重算后自动分最低的 20% 运行再做一次盲评，检查是否仍有"判定错"。

1.7.2 备选一：换模型

方案：用同价位更强的模型替换，或让两个模型各自作答后取共识。

为什么不选为主方案：本组 18 组中两侧指令遵循均为满分、最终推荐 18/18 合规，质量维度已接近上限，换模型的空间很小；而换模型无法解决三类问题——机器口径误伤（案例四/五/六）、指标度量对象错误（1.5.5）、相对分基准不一致（1.5.3）。B 侧更换模型并统一接入方式后，S1 稳定性仍仅 54.67，S2 三次最终推荐仍为三款不同车型，即为反例。且企业一旦选定供应商，通常倾向长期沿用，替换成本最高。

保留价值：可作为可选对照能力，但不应作为质量保证手段。

1.7.3 备选二：RAG

方案：让模型通过 function calling 检索车型库或联网搜索，再基于检索结果作答。

为什么不选为第一版主线：需 function calling 支持，并须重构四轮流程与全部测试脚本；本次 15 款车型随提示词注入已可满足需求，72 条 assistant 记录 tool_calls 全为空、该维度样本数为 0，本组没有产生任何实证数据，不宜据空样本立论。更关键的是，检索解决的是"事实来源"，不解决"输出契约""候选完备性""指标口径"三类问题——案例一、二、三在联网模式下同样会发生（体验线中 23% 的油价分歧即是佐证）。

升级条件：车型库扩展至数百款、上下文容量不足时，升级为主方案。

1.7.4 方案对比

维度	主方案：确定性校验层 + 契约修订	备选一：换更强模型 / 投票	备选二：RAG / 工具调用
可直接针对的失分	案例一~六全覆盖	仅可能缓解初筛遗漏	仅缓解事实来源
可离线验证	是（现有 18 份日志，零 API 成本）	否（须重跑且无法归因）	否（须重构流程重跑）
与模型解耦	是（A、B 及未来模型共享同一保护层）	否（绑定供应商）	部分
对结论正确性的直接贡献	高（消除误判与凑数）	中	中
边际成本	校验层纯规则，正常路径开销 <10 ms	高（单价与延迟）	中高（改造 + 检索延迟）

选择理由三条：① 唯一可基于本组 18 份日志离线验证、零 API 成本且可复现的方案；② 与模型解耦，可直接迁移到未来接入的任何模型；③ 直接对应本组识别出的最隐蔽失效——**"自动指标只能证明文本中存在该数值，不能证明模型表述正确"**。

---

1.8 评测结论

1. 两个模型的最终推荐质量都已可靠：18 次最终推荐全部满足预算与硬约束，没有一例编造车型、价格或参数的硬幻觉。
2. B 以 97.56 对 91.73 领先 5.83 分，其中 5.73 分来自成本延迟（输出短、响应快），其余五个质量维度 A 领先三项（推荐准确性、防幻觉、稳定性）、B 领先一项（一致性）、指令遵循打平，加权合计相差不足 0.1 分。
3. 失分集中在三个交界地带：输出契约"候选 2–4 款"诱导的凑数违例、打分锚点与自我修正行为的错位、逐句抽取口径对约束复述句与比较句的误伤。后两类经原文逐例核对，没有一处属于事实性错误。
4. 选型建议：要压低单位成本、要高吞吐、需求会频繁变更 → 选 B；要最保守的初筛准确率、宁可少推荐也不推错 → 选 A。

---

第二部分 具体分析

2.1 三层拆解：被测对象的结构

“大模型”并非单一事物，而是至少三层结构的叠加：承担推理的程序、将其封装为可用服务的软件工程，以及支撑其持续运转的商业结构。任何一层发生变化，评测结果都会随之改变；而实践中常将后两层的差异误记为第一层的差异。

2.1.1 程序层

模型类型。 本次两个被测对象都是非推理型的快速模型：A 是 MiniMax-M3.1-Flash（厂商定位“通用快速”），B 是 DeepSeek V4.1 Flash，调用时显式设置 thinking=disabled。该前提须先行说明，因为它是本次对比成立的基础——若 B 开启思考模式，输出 token 将成倍增长，成本与延迟两个维度随即不可比，评测退化为“推理模型对通用模型”的错位比较。

上下文压力是对齐的。 每组对话固定 9 条消息：1 条 system（2676 字符，含完整 15 款车型表）+ 4 组 user/assistant。S3 第 5 条消息是需求变更轮（预算 30 万 → 22 万、用途长途自驾 → 城市通勤、油耗上限 7.0 → 6.5 L/100km）。实测 prompt token：A 平均 13,013，B 平均 12,308，**相差不到 6%**。也就是说，两个模型面对的上下文长度基本相同，不存在“某一方上下文更宽裕”的优势。

差异体现在上下文的用法上。 这是本次实验中值得注意的发现：

• A 的策略为“筛选后列举”：S1 第一次回答直接写出“筛选后共有 2 款完全符合全部硬约束的车型”，仅给出结论，未呈现筛选过程。
• B 的策略为“全库逐款核对”：在 S3 变更轮中，它逐款列出 11 款车并给出剔除理由：“汉兰达 25.78 万：超预算，剔除”、“Model 3 23.55 万：超预算，剔除”、“思域 16.39 万：车长 4685 → 车长不足，剔除”。

两种策略的代价直接体现于稳定性：S3 场景下 B 的三次运行候选集完全相同（稳定性 100.0），A 的三次运行则每次漂移一款（稳定性 76.0）。逐款核对耗时更长、输出更长，但结果确定；筛选式列举更快，却依赖模型单次枚举完整，遗漏一款即产生漂移。

“记住”与“筛全”是两个不同的能力，须分开评估。 人工复核时单独设置了一个“约束理解”维度（1–5 分）：18 组里两个模型全部拿到 5 分，包括 S3 变更后的 A 组。也就是说，S3 的分差不是“模型忘了 22 万这条新预算”——两个模型每一轮都能准确复述变更后的三条新约束。真正的差别在于执行：B 依新约束对全库重新筛选，A 沿用上一轮候选并作局部调整，因而遗漏一款。对于作业要求观测的“需求变更后上下文是否保持”，本组的结论是：约束可被准确复述，但复述正确不等于筛选完整（证据见 2.4.4）。

工具调用：本次未测。 tool_mode=off，两个模型配置里 supports_tools=false，72 条 assistant 记录中 tool_calls 全为空。作业把“工具调用正确性”列为评分维度之一，本组没有覆盖这一维，权重记 0、样本记 0。该维度未纳入测试系有意为之：仅对一方开启工具，会引入大于其可测收益的偏差。这一点须在结论中显式声明，不得回避。

此外，数据模型常被归入“数据集”而非“程序”，本次有三处口径直接决定模型是否“答错”：

口径	具体规则	为什么会误导模型
保值率	车系级，同车系所有配置共用一个值	模型容易把它当成“这款配置的保值率”，进而用它做配置级比较
插混油耗	WLTC 综合油耗含电耗工况	秦PLUS 0.88、宋Pro 0.76 这类数字不是亏电油耗，直接比油耗会得出荒谬结论
气囊数	侧气帘按左右各一只计	思域 9 个、凯美瑞 10 个，并非配置堆砌，而是计数规则所致

B 在其中一次回答里主动写了：“综合油耗是插混综合值，不能当亏电油耗看。”——它在口径上是对的。此类“模型无误、数据易被误读”的情形，是 2.4 归因中最易被误判的一类。

2.1.2 软件工程层

接入形态对 token 量级的影响大于模型本身。 本次最终两个模型都走 OpenAI 兼容的 /chat/completions，同一份客户端代码只改 base_url 和模型名。需要先澄清一个容易误解的地方：“OpenAI 兼容”指的是接口协议格式，不是被测模型；本次被测对象只有 MiniMax 与 DeepSeek 两个，这一点在全文统一。

在定稿之前，本组曾以一个本地命令行代理进行流程验证，该通道每轮重传完整对话历史：

接入方式	单次运行 prompt token 合计	说明
命令行代理（流程验证阶段，结果已作废）	约 72,949	每轮把历史整体再发一遍，第 4 轮时历史被重复计费 4 次
官方 API（本次正式采用）	约 12,308	服务端维护会话，只发增量

同一段四轮对话，接入方式使 token 相差近 6 倍。 该差异并非源于模型，而源于软件工程层。若直接以两者计算成本分，将得出“某个模型贵 6 倍”的错误结论——这正是多数横向评测常见的失误。这也是本组未将那次流程验证结果计入正式对比的原因。

参数面并不完全等价。 两个模型共用一份配置模板，但 B 多一个 thinking 开关，A 没有对应参数。这意味着“同一份 config 跑两个模型”在参数层做不到真正等价，必须逐模型写适配层，并把实际生效的参数（含默认值）写进每次运行的 meta.json。本次 meta.json 的 params 字段完整记录了 temperature/max_tokens/thinking，此处实现符合规范。

usage 可得性是成本维度成立的前提。 两家均返回 prompt_tokens/completion_tokens，成本分方可计算。如果某家不返回 usage，整个成本维度只能标 usage_missing 并退出比较——这是接入选型时容易被忽略、但一旦缺失就无法补救的硬约束。

2.1.3 商业层

两家都是典型的 API 平台模式：按 token 计费，用免费额度获客，而不是订阅制。这决定了它们的优化方向一致——降低单位 token 成本、提高吞吐，而不是提高单用户客单价。

计费结构上，输入与输出分开计价，且输出通常显著贵于输入。 这使“输出长度”成为一个商业变量，而不只是文风问题：

指标	A	B	差异
平均 completion token	10,825	2,945	A 是 B 的 3.7 倍
平均 total token	23,837	15,253	A 多 56%
18 次合计 token	214,533	137,277	A 多 56%

A 的单次回答明显更长：S1 某一轮即输出 2,232 字符，将每款车的油耗、气囊与保值率逐项展开；B 平均约 1,300 字符，信息密度更高而解释更短。在按输出计费的商业模式下，“解释详尽”直接构成成本。

两家的商业侧重亦有差异：A 侧免费额度对试用、教学与小规模实验更为友好；B 侧单价更低，且对重复前缀提供缓存折扣，适合规模化调用。本节不列具体报价——两家价格与优惠政策持续调整，固定数值会迅速失效，应以官方定价页为准。此处仅给出结构性判断：本次 18 次对话中，B 少用 36% 的 token，平均延迟约为 A 的 1/4.7，在“高频批处理”用途上商业效率明显更高。

2.1.4 三层与本组评测结果的对应

三层拆解之后，再看 5.83 分的总分差（修正后 A 91.73 / B 97.56，见 2.3.1），其归属即较为清晰：

差异项	落点	证据
推荐准确率 A 更高（100 vs 98.15）	程序层（筛选策略更保守，不轻易纳入不合规车型）	B 在 S1-B-r3 把 2 款不满足保值率的车纳入候选，硬约束率 0.333
一致性 B 更高（100 vs 94.44）	程序层 + 评测口径（B 逐款核对不易自相矛盾；A 的自我纠正被判为不一致）	A 在 S1-A-r3 一致性 50，详见 2.4.2
稳定性 S3 B 更高（100 vs 76）	程序层（全库枚举 vs 筛选列举）	见 2.2.1
成本延迟 A 明显吃亏（42.67 vs 100）	软件工程层 + 商业层（输出长度 3.7 倍、响应速度 4.7 倍）	见 2.2.2、2.2.3、2.6.2

归纳而言，5.83 分中可归因于“结论质量更强”的部分很小，多数落于输出形态与服务性能。 将工程与性能差异误判为模型能力差异，是此类评测最常见的偏误。

---

2.2 同类产品对比与选型

2.2.1 对比口径与结果引用

本节不重复展示指标与图表：六维对比、分场景柱状图与波动带见第一部分 1.5.1–1.5.2，成本延迟相对分的口径修正见 1.5.3。此处只点明三件在"选型"语境下必须说清的事：

1. 总分差的主要来源是成本，不是能力。 97.56 对 91.73 的 5.83 分里，5.73 分来自成本延迟一维（42.67 对 100.00，为两模型间相对分）。
2. 五个质量维度上双方互有胜负：推荐准确性 100.00 对 98.15、防幻觉 99.11 对 97.66、稳定性 87.56 对 84.89 由 A 领先；一致性 94.44 对 100.00 由 B 领先；指令遵循打平。加权合计相差不足 0.1 分。
3. 质量维度的差值有相当部分来自评测口径而非模型能力（见第一部分 1.6 案例一、二），因此本节不做能力排序，只做条件化选型。

2.2.2 分场景选型建议

分场景总分差随"需求复杂度"与"变更次数"单调扩张：S1 +3.69 → S2 +5.72 → S3 +8.07（明细见 1.5.2）。三条选型结论均限定于本组实验条件：

1. 要压低单位成本、要高吞吐（例如每天跑上千条回归评测）→ 选 B。单轮 5.1 秒、15,253 token，是 A 的五分之一耗时、六成 token。
2. 要最保守的初筛准确率（例如对外输出购车报告，宁可少推荐也不能推错）→ 选 A。9 次推荐分全为 100，候选全部处于预算内、全部满足硬约束，该指标在本组数据中未见偏差。
3. 需求会频繁变更的多轮场景 → 选 B。S3 稳定性 100 对 76，为本组差异最清晰的一项，且成因可解释（全库逐款核对，不依赖单次枚举完整）。

需作一点说明：**A 的一致性短板并不等同于"模型遗忘"**。在 S1-A-r3 中，A 自行发现"上一轮遗漏了凯美瑞"并主动纠正，最终亦选中凯美瑞；扣分缘于该纠正破坏了候选集的连续性。该判定是否合理，见 2.4.2。

2.2.3 排名口径说明

本节所说的"更好"只在下列条件下成立：

• 样本量：每模型 9 次、每场景 3 次。n=3 仅能反映波动幅度，不足以做显著性检验，故不报告置信区间与 p 值。
• 任务域：单一任务（购车决策）、单一数据集（15 款车，2026-11-08 快照）、单一提示词版本、单一温度（0.2）。
• 时间点：A 组 11-08、B 组 11-09，两天之间模型若有静默更新，本组无法识别。
• 未覆盖：工具调用维度（权重 0，样本 0）。

波动区间见 1.5.2 图 1-3：S2、S3 的色带跨度不足 0.5 分（接近"同输入同输出"的确定性区间），S1 宽达 10 分（A 侧 82.93~92.93），是唯一存在实质随机性的场景；S1 的 3.69 分差小于 A 在该场景的自身波动跨度，故本文未把"B 在 S1 更优"作为选型依据。两条色带在 S2、S3 完全不重叠、在 S1 存在交叠，这正是"结论仅在特定场景稳健"的图形化依据，也是本节拒绝给出行业性排名的直接原因。

若更换车型库、提示词或调整温度，结论均可能改变。**"在本组 3 场景 × 3 次的条件下，B 的综合得分更高"是本文能够负责的最大范围。**

---

2.3 BUG 原因分析

运行记录中的每一处扣分均已保留原始对话，可逐轮回溯，本节总结这些错误的来源归属。

2.3.1 五类来源归因矩阵

本组将 18 组运行中的全部扣分点逐一回溯至原始对话，按五类可能来源归类：

来源	本组实例	证据	判定
模型本身	S1-B-r3 断言“大众速腾是唯一完全匹配的车型”	库内实际有 3 款满足全部硬约束（思域、速腾、凯美瑞），该断言为事实错误	成立
数据设计	保值率是车系级、插混油耗含电耗、气囊按左右各一只计	三类口径都容易让模型做出错误比较；B 主动标注了油耗口径差异，A 未标注	部分成立
提示词	S1 只要求“推荐 2–4 款”，未要求“先枚举全库再筛选”	A 在 S1-A-r3 第一轮直接给出“共有 2 款完全符合”，将漏筛结果当作全集	成立
解析程序	A 的 S1-A-r3 被判 final_not_in_candidates	模型第二轮自我纠正后补入凯美瑞，末轮推荐它，但解析器认为“最终车不在第二轮候选列表内”= 自相矛盾	误判
接口服务	早期 B 走命令行代理，prompt token 72,949	每轮重传历史，与模型无关；改 API 后降至 12,308	已消除

五类之中，“模型本身”仅占 1 例，“解析程序”误判 1 例，“接口服务”1 例已通过更换接入方式消除，其余 2 类属实验设计层面的问题。

2.3.2 三类根因

根因一：评测设计与模型行为的错位——评分器惩罚了正确行为。

A 在 S1 第三次运行的完整过程如下：

1. 第一轮：给出思域、速腾 2 款，并写“筛选后共有 2 款完全符合全部硬约束”（漏了凯美瑞）；
2. 第二轮：自己发现并写明“上一轮遗漏了丰田凯美瑞……完全匹配的车型实际为 3 款”，补上；
3. 第三轮：按要求输出三车对比表；
4. 第四轮：推荐凯美瑞，理由充分。

从人工判断角度看，这是一次高质量的自我纠正：发现错误、说明错误、修正结论。但评分器规则为“候选集在轮次间应保持延续”与“最终推荐应来自候选集”，因此判定 c2=0、c4=0，一致性降至 50 分，该组成为 A 全部 9 次中最低的 82.93。

对照 B 的 S1-B-r3：第一轮断言“无完全匹配车型”，随后自行更正为“速腾是唯一完全匹配”（仍属错误，遗漏 2 款），全程未作实质纠正，最终推荐速腾——一款合规但非最优的车型。评分器给予其一致性 100 分，仅扣减推荐分。

同一类错误（初筛遗漏车型），明确承认并修正的一方被扣分更重，始终未作纠正的一方反而未被扣减。 这是本次评测中最需修正的一处判定逻辑：候选集连续性应衡量“是否无理由改口”，而非“是否改口”。合理的做法是引入“带证据的修正”通道——模型明确说明“上一轮遗漏了 X，原因是 Y”时，c2 判通过、c4 以最终结论是否合规为准。

根因二：自动指标与人类认知的两种错位——判定错与度量错。

第一种是判定错：把对的判成错的。B 在 S3 三次运行中均触发 table_car_unmatched，在 S1-B-r3 有 4 处 spec_mismatch。逐条核对原文可见，问题不在内容而在抽取：模型写的是“纯电续航 220km（但未达 400km）”，正则表达式提取 220 后与库值比对，本身无误；但同一句还出现“400km”这一门槛值，抽取器将其视为第二个声明值，与库值不符即记一次 mismatch。模型表述正确，是抽取规则将“门槛值”误认作“声明值”。

此类情形并非个例。18 组中触发失配的句子共 33 条（A 侧 10、B 侧 23，分布在 14 组，其余 4 组该维度满分；逐条明细见实验材料 evidence/hallucination_evidence_full.csv）。逐条与原文回对后，100% 可归为抽取器的口径误伤，无一条对应编造车型、价格或参数：

误伤类型	条数	典型情形
约束门槛复述	13	复述“≥6 气囊”、“续航需 ≥400km”被当成车型参数声明
比较句归属写在句外	11	前半句点明车型，后半句比较时主语省略，抽取器另挂主语
主语歧义与同句多计数	4	一句里出现两个车型的数值，归错主语
书写变体	3	“比亚迪 汉”多一个空格即匹配失败
预算句误记	2	预算区间被读成车型价格

修复成本较低：紧跟“未达/不低于/不超过/门槛”等词的数字标记为 threshold，不参与一致性比对；比较句按最近的车型名做主语回指；车名匹配前先做空格与全半角归一。但它指向一个更普遍的问题：自动指标只能证明“文本中存在该数值”，不能证明“模型表述正确”。 本组得以确认 33 条均为误伤，依据的是人工逐句回看，而非指标本身。

第二种是度量错：计算无误，但所度量的并非用户关心的对象。B 侧 S2 三次最终推荐分别是 AH-76177 / AH-74283 / AH-79463，三款互不相同，stability_score 却都记 100。回查预注册规则可知这不是程序缺陷：稳定性按“三次候选集两两 Jaccard + 约束合规率”计算，并明确规定“多个车型均满足要求时，不因最终推荐车型不同判为不稳定”，而三次候选集所含车型相同、仅排序不同，集合相似度为 1.00。A 侧 S2 亦记 100 分，其三次最终推荐为 AH-76177 / AH-79549 / AH-76177，三款中两款重复。

按规则判满分在逻辑上成立，但用户几乎必然将“稳定性 100”理解为“同一需求多次询问均得到相同答案”。 判定错较易发现——数字与原文不一致即会被追问；度量错极难发现，它要求有人先质疑“该指标所度量的对象是什么”。这也是本组留给 2.5.5 的一条硬要求：稳定性必须拆成“候选集合一致性”与“最终推荐一致性”两个指标分别呈现。

根因三：口径不统一——相对分在子批次内计算，基准随之变化。

最初导出的表中，成本延迟维度两个模型均为 100 分（详见 2.3.1）。根因不在模型，而在导出流程：成本分为相对分，须在全部模型到齐后一次性计算，而本次系两批分别导出，第二批仅含 B 一个模型，min 退化为其自身。这是典型的“统计口径依赖批次构成”缺陷，属程序缺陷，不属模型或数据问题。

本组已按公式在两模型之间重算，并将结果写回索引表（A 42.67 / B 100.00，总分 91.73 / 97.56，见 2.3.1）。该修正本身亦值得记录：一个“两模型都满分”的维度，在报告里看起来毫无异常，只有当有人问“为什么这个维度双方都是 100”时才会暴露。自动评分器不会为自己的口径报警，这是自动化评测里最隐蔽的一类失效。

---

2.4 软件工程方面的建议

上述问题多数无法通过“更换更强的模型”解决，而属评测系统自身的工程质量问题。以下按四个角度给出具体措施。

2.4.1 测试覆盖

1. 预注册池前置断言。 运行前必须打印并校验每个场景的合规池数量：S1=3、S2=4、S3 变更前=12、变更后=9。数量不符直接中止，不得以“跑完再核”替代前置校验。本次数据由模拟版更换为快照版后合规池全部改变（8/4/9 → 3/4/12），若存在该断言，返工可提前两天被发现。
2. 变更轮单独设断言。 S3 的第 5 条消息包含三处变化（预算、用途、油耗上限），要求模型在回答开头逐条复述“旧值 → 新值”。缺失任意一条即判该轮失败，不进入后续评分。
3. 正式运行前先做小样本试跑。 1 场景 × 1 模型 × 1 次，人工核对抽取规则是否将门槛值误判为声明值（根因二即属此类可在试跑阶段发现的问题）。

2.4.2 接口适配

1. 统一 OpenAI 兼容入口，禁止混用命令行代理。 同一份对话，代理模式 72,949 token、API 模式 12,308 token，差约 6 倍。若评测系统中混入两种接入方式，成本维度将直接失效。
2. 参数适配层显式化。 每个模型声明 thinking、temperature、max_tokens 的取值（含默认值），写进 meta.json 的 params。对缺少 thinking 开关的一方，应标注“该参数不适用”，不得留空。
3. 组级指标全量一次性计算。 成本、延迟这类相对分，须在全部模型到齐后统一计算，并加一条断言：参与计算的模型数 < 2 时拒绝输出相对分。本次“两个模型均为 100”的表面持平，仅需该条断言即可拦截。

2.4.3 上下文管理

1. 约束卡片强制注入。 将用户已确认的硬约束结构化为 JSON（预算、座位、车长、气囊、AEB、油耗或纯电续航、保值率），每轮以固定格式重新附于消息尾部，而非依赖模型从自然语言历史中自行回忆。A 在 S1-A-r3 遗漏凯美瑞，本质上是“在 15 款车中同时套用 7 条约束”超出了单次筛选的可靠性边界。
2. 变更留痕。 每次需求变更后，在 transcript 的 meta 里记一条 {field, old, new, turn}，既便于人工复核，也使“是否确实记住新条件”具备机器可查的证据。

2.4.4 异常处理

1. 失败不静默。 解析失败记 status=parse_error 并保留原始响应，不得吞掉异常或跳过。本次 raw/ 目录完整保留了每轮原始 JSON，该处置为后续全部归因提供了前提。
2. 断点续跑。 按 run_id 跳过已完成项。本次 B 侧因接入方式调整需重跑 9 次，若支持断点续跑，仅需重跑失败项。
3. 异常分类而非统一重试。 429/超时应重试，parse_error 不应重试（重试通常得到相同的格式错误），usage_missing 应直接标记退出成本比较。

2.4.5 评测口径治理

此项为本组代价最大的一项，单独列出：

1. 口径变更必须版本号 +1，并全量重跑，不得新旧混算。 本次数据由 v1.0 升级至 v1.1（真实快照），实际仅执行“重跑”，未执行“回写”——仓库中的 cars.csv 仍为旧版，system.md 仍标注“教学模拟数据 v1.0”。结果为：以仓库中的数据无法复现那 18 份日志。 这在形式上等同于实验不可复现。
2. 数据、提示词、文档、日志四者同批次提交。 建议以一次提交同时更新上述四处，提交信息中标注版本号，避免出现“代码已运行、文档未更新”的情形。
3. 评分器自身也要有版本。 本次判定逻辑改动（如根因一提出的“带证据的修正”通道）将改变全部历史分数，须记录评分器版本，否则跨版本比较失去意义。
4. 固定一条人工盲评通道，且人工分独立报告、不并入总分。 本次 18 组盲评的六维均值与自动分偏差不超过 1.61 分，整体可信；但 7 处分歧全部集中于唯一出现违例的场景——自动分在“总量”上可信，在“定责”上不可信（见 2.4.4）。建议固化为流程：对自动分最低的 20% 运行实施人工盲评，仅用于校准判定规则；人工分一旦并入总分，该校准通道即失效。

---

2.5 市场概况

本节围绕四个问题展开：市场体量、竞争格局、用户结构，以及市场热度向实际落地转化的阻滞因素。商业层计费方式已在 2.2.3 论述，此处不再展开。需先行说明两点：其一，下文所有数据均标注来源与发布时间，属二手公开资料，非本组实测结果；其二，各机构统计口径差异显著——调用量、营收、企业支出与产品收入所度量的对象并不相同，本文并列呈现，不作加总，亦不将不同口径的数值用于计算增长率。

2.5.1 市场规模与增速

各口径下的规模与增速数据列示如下。

口径	2024	2025	2026（预测 / 最新）	来源
中国公有云 MaaS 调用量	114 万亿 Tokens	1944 万亿 Tokens，同比增长约 16 倍（约为上一年的 17 倍）	约 40000 万亿 Tokens，约再增 20 倍（预测）	IDC，2026-05
中国公有云 MaaS 营收	—	30.7 亿元	约 186 亿元	IDC，2026-05
美国企业生成式 AI 支出	115 亿美元	370 亿美元（约 3.2 倍）	—	Menlo Ventures，2025-12
中国生成式 AI 用户规模	2.49 亿人（2024-12）	6.02 亿人，普及率 42.8%（2025-12）	突破 7 亿人，普及率超 50%（2026 上半年）	CNNIC
全球 AI Agent 产品市场（狭义）	—	约 82.9 亿美元（机构预测，二手转述）	约 109–121 亿美元，CAGR 约 44%–46%	多家机构汇编，口径见 2.6.4

由表中数据可归纳出三点。

第一，调用量增速显著高于营收增速。 2025 年 1944 万亿 Tokens 对应的公有云 MaaS 营收仅 30.7 亿元，日均消耗由 2025 年 1 月的约 1.6 万亿增至 12 月的约 9.6 万亿（IDC）。调用量增长十余倍而营收仅处于数十亿元量级，其可能成因包括单位 Token 价格持续下降、免费额度与低价模型的获客策略；在此阶段，调用规模与商业收入并不呈线性对应。本组 18 次运行的合计 token 仅 35.2 万，相对该量级属极小样本——个人或课程级的用量，在平台账单上几乎不可见，这也解释了为什么“按量计费”的 API 模式必须靠免费额度获客（见 2.2.3）。

第二，16 倍与 20 倍两项增速均须附加“低基数”与“预测值”两项限定。 114 万亿的起始基数较低，故倍数在数值上较为显著；IDC 对 2026 年 40000 万亿 Tokens 的判断，以多模态模型持续成熟、Agent 类应用规模化落地、算力供给不出现严重瓶颈、合规政策保持稳定为前提，属高增长情景下的预测，而非已发生的事实。同理，186 亿元营收预测亦高度依赖 Agent 规模化落地。将预测值表述为既成事实，是数据分析中需规避的常见偏差——这一点与本组评测中“把相对分当绝对分”的失误属于同一类错误，只是发生在宏观数据上。

第三，支出主要集中于应用层，而非模型 API 层。 Menlo Ventures 面向 495 家美国企业决策者调研、并配合自下而上市场模型估算的 2025 年 370 亿美元美国企业生成式 AI 支出中，约 190 亿美元（超过一半）流向直接面向用户的 AI 应用，约 180 亿美元流向模型与基础设施；编码为首个规模化落地场景，支出约 40 亿美元。该口径仅覆盖美国企业，不含其他地区与自托管推理，故不与 IDC 的中国公有云 MaaS 营收并列或换算。对于以 Python 脚本调用 API 开展评测的开发者而言，模型 API 是账单中最显著的科目，但市场价值主要集中于“能否借助模型稳定交付可靠结果”。该判断与 2.6.4 所述的落地落差及 2.7 的产品定位相互印证。

2.5.2 竞争格局

国内市场是“公有云高度集中、私有化相对分散”的双轨结构。 IDC《中国企业级 MaaS 市场最新格局分析报告》（2026-05-07）显示，按调用量计，2025 年火山引擎占 49.5%、阿里云 28%、百度智能云 10%，三家合计约 90%，其后是硅基流动与移动云；按营收计，火山引擎仍在 40% 以上，前五还包括智谱与移动云。需说明，IDC 该口径统计企业通过公有云 MaaS 平台调用 API 产生的调用量，私有化部署另按软件及授权收入口径单独统计，两者不可混用。另一条轨道是政企私有化部署，受数据安全与合规要求驱动，客户更倾向本地化交付，竞争格局相对分散，IDC 追踪到的头部厂商包括百度智能云、商汤科技、电信 AI、中关村科金、创新奇智、星环科技、中国电子云等，区域性采购与行业性采购为其主要成因。

企业侧与开发者侧的选型逻辑并不一致。 Menlo Ventures 面向 495 家美国企业决策者的调研显示：企业 LLM API 支出中 Anthropic 约 40%、OpenAI 约 27%、Google 约 21%，三家合计 88%；开源权重模型份额由 19% 降至 11%，企业更倾向采用闭源模型，并倾向于“选定供应商后持续升级”。然而在更贴近开发者与初创团队的第三方路由平台统计中，Qwen、DeepSeek、Kimi、MiniMax、GLM 等中国开源模型的周度 Token 份额由 2024 年底的约 1.2% 升至 2025 年后期的近 30%（OpenRouter × a16z《State of AI》100 万亿 Token 实证研究，2025-12；该口径为平台调用量，与企业支出口径不可换算）。企业侧重视稳定性与合规性，开发者侧重视性价比与可替换性，两类市场所反映的份额分布因而存在显著差异。本组最终实测的两个模型所属厂商均出现在该平台统计的样本中，但本组实际调用经各自官方 API 直连，并不经过第三方路由平台：MiniMax 与 DeepSeek 在日志中均记为 OpenAI 兼容直连、按 Token 计费，更换模型仅需调整接口地址、模型标识与相应环境变量；在本组实验条件下，该特性相较榜单名次更直接地决定了能否在截止期限前完成 18 次测试。

竞争焦点已由单一价格维度转向综合能力维度。 IDC 对此的判断为：MaaS 厂商的竞争正从“单纯的价格比拼”转向“价格、性能与工具链支持”的综合能力；影响企业落地的 Top5 因素依次是模型性能、安全合规、回答质量、AI 平台可用性、成本效益——成本效益仅列第五位。

这与本组的排期经验吻合：两个模型都走 OpenAI 兼容接口，同一份客户端代码只改 base_url 与模型名，“能不能顺利换”比“谁更强”更早决定了任务能否完成。成本维度则须附加说明：成本延迟为两模型之间的相对分，最初两批日志分别导出、各自归一化，两侧都记 100 分——两个 100 分对应不同对照对象，不可并列比较（已统一基准重算为 A 42.67 / B 100.00，见 2.3.1）。仅仅换一个基准，结论就从“几乎打平”变成“相差 5.83 分”——这本身就是一条证据：报告成本时必须同时报告对照对象。

被替换的那组早期预实验值得一提，但只能当量级参照：该轮 B 侧经本机 CLI 中转、每轮重传完整对话历史，组均 total_tokens 为 75,526，约为 A 侧直连 23,837 的 3.2 倍，成本延迟在该批内为 61.56 分（A 侧同批为 100.00）；正式 B 侧直连为 15,253 tokens、单轮平均延迟约 5.1 秒（预实验 B 侧约 25.9 秒）。需注意，A 侧同样采用直连，单轮平均延迟仍约 23.7 秒，与预实验 B 侧的 25.9 秒接近——延迟差异更可能源于模型本身与服务端，不宜归因于接入方式。该预实验同时变更了模型与接入方式，两个变量未作分离，故 token 量级的下降只能作为量级对照，不足以支持因果归因；可确定的结论是：影响最终账单的因素除模型外，还包括上下文管理与接入架构。

这一观察与 IDC 将“AI 平台可用性”列入 Top5 相互印证：厂商侧强调模型能力，采购方的实际制约却在于“能否稳定接入系统、结果能否复核”。后者属于 2.4、2.5 所讨论的工程问题，亦构成 2.7 产品化的定位依据。

2.5.3 用户结构

用户类型	核心诉求	公开数据	本组实验中的对应角色
开发者 / 学生团队	低成本、可复现、能换模型	编码为首个规模化落地场景，支出约 40 亿美元；76% 的企业 AI 方案为采购而非自建；定制方式仍以提示词设计为主、RAG 次之，工具调用 / 上下文工程 / 微调仍属小众（Menlo Ventures，2025-12）	以 Python 调用 API、通过环境变量读取密钥、按 2 模型 × 3 场景 × 3 次 = 18 次执行、导出脱敏日志
企业 / 政企	合规、稳定、可审计	公有云场景集中在泛互联网、智能办公、智能硬件、大消费；私有化项目收敛到智能办公、数据处理与分析、市场营销（IDC）；47% 的 AI 采购进入生产，传统 SaaS 为 25%（Menlo）	预注册评分规则、冻结口径、逐条留痕、模型版本与测试日期可追溯
普通用户（C 端）	使用便捷、结论直接	2026 上半年我国生成式 AI 用户超 7 亿、普及率超 50%；76.0% 用于回答问题，处理图片/视频 47.8%、文本 37.6%、总结/会议纪要/PPT 32.5%；AI 综合助手与效率办公使用次数同比增长均超 100%（CNNIC，2026-09）	对应 S1/S2/S3 场景中的购车决策者：预算、通勤、安全、保值率及中途预算变更

三类用户对系统质量的评价准则存在根本差异：开发者侧重可复现性，企业侧重可审计性，C 端用户侧重使用便捷性。因此，“哪一模型整体最优”这一提问方式本身缺乏可判定性，有效的问题应为“在何种条件、对哪类用户更为适用”。这也是 2.3 仅讨论选型依据、不作行业排名的原因。

另有两项数据需单独说明。其一，Menlo Ventures 的统计显示，仅 16% 的企业部署可归类为“真 Agent”（具备规划、执行、观察反馈与调整能力），多数为固定序列工作流中封装单次模型调用；本组正式 18 次运行中 tool_mode=off（B 侧另额外关闭了思考模式），72 条 assistant 记录的 tool_calls 全为空，工具调用维度样本数为 0，与“工具调用仍属小众”的判断一致。其二，C 端用户规模虽已过半，但据新京报援引花旗研究基于 CNNIC 用户基数的测算，2025 年底月均使用时长约 183 分钟（折合每天约 6 分钟），日均超两小时的重度用户约 5%（二手转述，仅作趋势参考）。“已安装、曾使用”与“可将重要决策交由其承担”之间仍存在显著差距；购车决策正属于高金额、低频次、信息不对称且需求可能中途变更的 C 端场景，本组 S3 场景将预算由 30 万调整为 22 万，即是对该特征的模拟。

2.5.4 增长与落地的落差

综合前述公开数据与本组实验结果，增长与落地之间的落差可归纳为四层证据。

其一，部署意愿与实际部署之间的落差。 Gartner 2026 年 CIO 与技术高管调研显示，仅 17% 的组织已部署 AI Agent，而超过 60% 计划于两年内部署，为该调研所覆盖的新兴技术中采用曲线最陡者；Gartner 同时预测 2026 年底 40% 的企业应用将内置任务型 Agent（2025 年不足 5%），并预测超过 40% 的 agentic AI 项目将于 2027 年底前被取消，原因为成本上升、业务价值不清与风控不足。Agentic AI 在 2026 年 Hype Cycle 上处于“期望膨胀期”顶端。

其二，Agent 的统计定义尚未收敛。 Menlo 的 16% / 27%（企业 / 初创）系“真 Agent”口径，而 IDC 2026 年 7 月《Future Enterprise Resiliency and Spending Survey》对全球企业的调研称，95% 的企业至少在运行一个由企业出资的 agent-enabled workflow——前者考察“是否部署 AI Agent 这一产品品类”，后者考察“是否至少存在一个具备 Agent 能力的工作流”，两者数值相差近六倍，但并不构成矛盾。全球 AI Agent 市场规模亦然：狭义产品收入口径约 109–121 亿美元，含编排、治理与预置应用的广义口径约 190–210 亿美元（该组数值来自多机构汇编的二手转述，不同机构口径差异较大，仅用于说明量级分布），而“受 Agent 能力影响的企业总支出”口径可达万亿美元级。同一年度、同一术语，统计结果可相差两个数量级，原因在于各口径所度量的对象根本不同。 统计口径尚未收敛，本身即表明该市场仍处于早期阶段。

其三，C 端“可用性”不等于“使用深度”。 用户规模超 7 亿、普及率超 50%，但用途集中于信息查询与文本修改；据二手测算，日均使用时长约 6 分钟，该数值仅作趋势参考。高频次、低深度的使用特征表明，模型尚未进入需反复核对并承担后果的决策链路。

其四，本组 18 次运行构成该落差的缩尺样本。 表层指标表现良好：18 组全部 success；指令遵循 18/18 满分，A 侧推荐准确性 9/9 满分、B 侧 98.15；18 组最终推荐全部通过预算与硬约束检查；统一基准后总分 A 91.73 对 B 97.56，差 5.83 分。但这个差值必须拆开看：其中 5.73 分来自成本延迟一维（A 42.67 对 B 100，权重 10%），五个质量维度上双方互有胜负——A 在推荐准确性（100 对 98.15）、防幻觉（99.11 对 97.66）、稳定性（87.56 对 84.89）上领先，B 只在一致性（100 对 94.44）上领先，指令遵循双方均为 100。换言之，这 5.83 分几乎全部来自“输出更短、响应更快”，而非“结论是否正确”；且每格仅 3 次重复，质量维度上的细微差别应视为噪声。

然而在“能否稳定交付”与“能否被正确度量”两个层面，问题集中显现。以下五点的事实与归因已在 2.4 逐条展开，此处只保留与市场判断直接相关的部分：

• 防幻觉维度的扣分全部是度量误伤。 18 组共 33 条失配（A 10 / B 23），逐条回对后 100% 属抽取器口径问题、零事实错误；人工盲评独立给出该维度 18/18 满分。因此 A 侧 99.11 与 B 侧 97.66 都应读作“机器没读懂人话”，而不是“模型在编”（见 2.4.2）。
• S1-A-r3：模型修正正确，评分反而下降。 主动补入初筛遗漏的凯美瑞、最终推荐正确，却因评分锚点固定于 T2 被判一致性 50 分、总分 82.93（全场最低）；人工盲评为 80 分。同一份对话，机器判定为自相矛盾，人工判定为纠正得当。
• S3 需求变更后，发生漂移的是候选集合的构成，而非约束合规性。 A 侧三次两两 Jaccard 均值仅 0.600，最终推荐 AH-78835 / AH-76173 / AH-76173，但硬约束合规率始终为 1.00；B 侧三次候选集相同、且收敛至同一款车。需求变更本身并非不可处理，差异产生于“变更后如何重新枚举候选”这一执行环节。
• 指标定义与用户感知可能完全脱节。 B 侧 S2 三次给出三款不同的车（AH-76177 / AH-74283 / AH-79463），stability_score 却都记 100；A 侧 S2 为 AH-76177 / AH-79549 / AH-76177，同样记 100——同一需求三次询问，出现两款甚至三款不同答案，用户侧均难以理解。规则内正确（候选集合一致），但与用户感知脱节（见 2.4.2）。
• B 侧 S1 稳定性仅 54.67 分。 其中 S1-B-r3 初筛的 3 款候选中仅 1 款满足硬约束（candidate_constraint_ratio=0.3333），推荐准确性 83.33、总分 90.16，为 B 侧最低。

据此可得结论：模型单次给出正确答案已非主要难点，难点在于系统能否稳定、可复核地给出正确答案，且该过程能否被正确度量。 即便更换 B 侧模型并将接入方式统一为 API 直连，上述问题仍出现在正式 18 次运行中：从较易识别的“口径误伤”到更隐蔽的“指标定义与用户感知错位”，均不会随模型版本升级而自动消解。市场宣传的侧重点（能力、参数、榜单）与落地实际制约（口径、留痕、稳定性、接入架构）之间存在系统性错位。因此 2.7 不再设计“能力更强的购车助手”，而将“可复核性”本身产品化。

2.5.5 引用资料

本节所引公开资料汇总如下，检索时间为 2026-11-09；具体年份与统计口径以原报告为准。

编号	资料	发布时间	链接	本文用于
[1]	IDC《中国企业级 MaaS 市场最新格局分析报告》相关报道（调用量、营收、份额、落地 Top5 因素）	2026-05-07	https://finance.sina.com.cn/tech/roll/2026-05-07/doc-inhxahrf2769086.shtml	2.6.1 / 2.6.2
[2]	IDC《中国 MaaS 市场进入高速增长期，Token 经济从概念走向规模化实践》（份额细节、日均 Token 消耗、应用场景、落地 Top5 因素）	2026-05	https://www.idc.com/?p=114850/	2.6.1 / 2.6.2 / 2.6.3
[3]	IDC 中国 AI 超级周期新闻稿（2026 年营收预测、CAGR、企业采纳）	2026	https://qa.idc.com/resource-center/press-releases/china-is-leading-the-ai-supercycle-and-the-distance-is-growing	2.6.1
[4]	火山引擎 49.5% 份额报道（IDC 口径说明）	2026-05-07	https://finance.sina.com.cn/wm/2026-05-07/doc-inhxanxf5037604.shtml	2.6.2
[5]	Menlo Ventures《2025: The State of Generative AI in the Enterprise》及新闻稿（样本为 495 家美国企业决策者，美国企业支出口径）	2025-12-09	https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise	2.6.1 / 2.6.2 / 2.6.3 / 2.6.4
[6]	CNNIC 第 57 次《中国互联网络发展状况统计报告》发布会	2026-02	https://www2.cnnic.cn/n4/2026/0209/c326-11544.html	2.6.1 / 2.6.3
[7]	CNNIC《生成式人工智能应用发展报告（2026）》，人民网报道	2026-09-29	https://finance.people.com.cn/n1/2026/0929/c1004-40807558.html	2.6.1 / 2.6.3
[8]	Gartner《2026 Hype Cycle for Agentic AI》与 No-Code Agent Builders 市场分析	2026	https://www.gartner.com/en/articles/hype-cycle-for-agentic-ai	2.6.4
[9]	新京报《7 亿人之后，生成式 AI 要从“常用”走向“管用”》（含花旗使用时长测算，二手转述）	2026	https://m.bjnews.com.cn/detail/1790750811129055.html	2.6.3 / 2.6.4
[10]	AI Agent 市场规模多机构汇编（口径差异，二手转述，需以原报告为准）	2026	https://cybertizeweb.com/?p=1006	2.6.1 / 2.6.4
[11]	OpenRouter × a16z《State of AI: 100 Trillion Token LLM Usage Study》（开发者侧模型调用份额，2024-11 至 2025-11）	2025-12	https://openrouter.ai/state-of-ai	2.6.2

---

2.6 产品规划（NABCD）

先说明分工边界：2.4、2.5 已完成错误归因与工程修复的论述，本节不复述缺陷修复清单，而将同一批发现转化为可交付的用户侧功能。本节所有效果数值均为目标值或基于现有日志折算的预期，非已实现、已上线的结果，验证方式详见 2.7.4。

2.6.1 产品定位与目标用户

产品（暂定名）：“车证 CarProof”——可核验的购车推荐助手。

产品定位可表述为：在现有大模型 API 之上增设“确定性计算 + 输出前校验 + 证据链”中间层，由模型负责解释与表达，由程序负责候选计算、事实核验与过程留痕。该产品并非新建模型，而是在本次被测的 A、B 两个模型之上新增的一层功能：不训练新模型、不提供通用对话、亦不自建车型数据库，仅定位于“模型输出 → 用户可采信结论”这一层，且与模型厂商解耦，可跨厂商复用。

目标用户分为三类，优先级如下：

• 主用户：C 端购车决策者。 预算、通勤、安全、保值率等多条件叠加，且需求可能在对话中途发生变更（本组 S3 即由 30 万调整为 22 万），属数十万元量级的低频决策。
• 次用户：汽车内容平台 / 经销商运营。 其核心关切在于“推荐中出现编造参数”所引发的投诉与合规风险，因而需要具备留痕与可审计能力的输出。
• 种子用户：从事模型评测的开发者与课程团队。 该群体（含本组）对可复现口径与标准化日志格式的需求最为明确，亦最易通过开源仓库形成扩散。

本方案以本组实验为出发点的依据：正式 18 次日志所暴露的六类问题——结论无法追溯来源、初筛遗漏后中途自我纠正、需求变更后候选漂移、机器口径误伤、稳定性指标与用户感知错位、成本指标受计算基准影响——均无法通过更换模型单独消除，且均可由确定性中间层检测或规避，其共同特征为模型输出与用户决策之间缺少可复核环节。即便 B 侧更换模型并统一为 API 直连，正式 18 次中仍出现机器口径误伤、稳定性指标与用户感知错位、成本指标基准不一致三类问题，进一步表明该中间层无法通过更换模型补足。此即本方案所对应的产品机会。

2.6.2 N（Need）

痛点	本组实验证据（正式 18 次）	对用户的后果
数值表述正确但无法追溯核验	车型库 15 款、逐款来源页与采集日期齐备，但回答中不附来源；33 条失配经回对全为口径误伤（2.4.2）——“看起来有数”不等于“可核验”	高金额决策缺乏可信依据；平台难以自证合规
需求变更导致结论漂移	A 侧 S3 变更后候选集两两 Jaccard 仅 0.600，三次最终推荐落在两款车上；B 侧三次收敛至同一款，说明漂移源于候选取舍规则而非需求变更本身	预算调整后前后结论不一致，需反复追问确认
初筛覆盖不全、中途隐式修正	S1-A-r3 初筛遗漏凯美瑞、至 T4 方补全，最终正确却被判一致性 50（2.4.2）；S1-B-r3 初筛 3 款中仅 1 款合规	用户感知到前后不一致，信任度下降
“可生成”不等于“可验收”	18 次 JSON / 表格 / 最终推荐格式全合规，但抽取器在比较句、差值句与书写变体上仍误判；72 条 tool_calls 全空	企业难以将输出直接接入业务流程，仍需人工兜底
同一需求多次询问所得结论不一致	B 侧 S2 三次为三款不同的车却判稳定性 100，A 侧三次中两款不同亦记 100（见 2.4.2）；B 侧 S1 稳定性仅 54.67	用户无法判定应采信哪一次结果
成本与延迟指标同时受接入方式与计算基准影响	预实验中 CLI 中转 token 约为直连 3.2 倍；正式两批最初各记 100 分、基准不同不可比，统一重算后该一维贡献了 5.83 分差中的 5.73 分（2.3.1）	采购方无法获得可信的单位成本，易将工程开销误判为模型能力差异

将上述六项痛点归纳为一项核心需求：用户所需并非“表述更流畅的推荐”，而是每一项结论均可回应“依据何条数据、对应哪一需求版本、多次运行结果是否一致”。 对照 2.6.4 所述市场落差，该需求并非主观构想，而是“模型能力已基本满足、可复核性尚未同步”所形成的结构性缺口。

2.6.3 A（Approach）

方案包含五个模块，核心原则为：凡可由程序确定性计算的环节，均不交由模型自由生成。

模块 1 · 需求卡与变更快照。 预算、座位、车长、能耗、安全、保值率等条件结构化存储，每轮回复前显式回显确认；用户变更条件时生成差异记录（如“30 万 → 22 万，其余条件不变”），后续所有轮次锚定最新版本，并在报告中保留全部历史版本。对应本组一致性 C3 检查点（S3 预算变更确认）与 S3 场景。

模块 2 · 确定性候选池。 候选集合由程序基于车型库执行集合运算得出，规则为“列出当前约束下全部满足条件的车型，并按指导价升序排列”；模型仅负责解释、阐述排序理由与语言组织，不再自行决定入选候选。该设计直接对应两处已发生的失分：S1-A-r3 初筛凭印象截断至 2 款、S3 变更后候选取舍自由度过大导致漂移，作用在于把软性取舍转换为确定性规则。

模块 3 · 输出前校验层（纯规则，不调用 LLM）。 三个检查器按序执行：① 结构校验——final JSON 恰好一个、表格行数等于候选数、必需列齐全；② 候选一致性校验——同轮 candidates JSON 与表格车名做归一化差集（去空格、全半角统一），差集非空即判轮内矛盾；③ 事实回查——将最终推荐车型的价格、油耗、纯电续航、气囊数、保值率与车型库逐项比对，容差沿用本组预注册口径（价格取 0.2 万与指导价 5% 中的较大者，参数偏差超 10% 方记为 mismatch）。任一检查未通过时，携带具体原因重试一次；若仍失败，则输出原结果并附降级标记。该设计沿用打分侧的车名归一化与语境区分口径，并将其由打分侧前移至输出侧。

创新点一：一致性锚点跟随模型最后一次明确给出的候选集。 本组 S1-A-r3 的扣分并非源于推荐错误，而是评分锚点固定于 T2、无法感知模型在 T4 完成的自我纠正。产品侧将“最终推荐必须属于模型最后一次给出的候选集”设为检查点，并在日志 flags 中记录实际采用的锚点轮次，既兼容逐步自我修正，又保持可审计。

模块 4 · 可核验决策报告。 每项数值均附来源页、采集日期与口径标签（裸车指导价 / WLTC 综合油耗 / CLTC 纯电续航 / 车系三年保值率，后两者与混动、纯电口径不同，必须显式区分），推荐理由绑定当时的需求版本与候选集合；报告中将“已核验事实”与“待人工复核”分两栏呈现。

创新点二：口径误伤与模型错误双通道。 18 组共 33 条防幻觉失配经逐条回对，全部为抽取器口径误伤、无事实错误。产品侧要求抽取器对无法唯一归属的数值记 ambiguous_attribution 复核标记，而非直接判为幻觉；向用户呈现的状态仅有“该条已核对”与“该条机器无法判定、需人工复核”两类，从而将“机器无法判定”与“模型输出错误”明确区分。该机制可迁移至各类逐句抽取型评测场景。

模块 5 · 双模型对照、稳定性口径与接入标注。 同一份提示词、同一种接入方式并行调用两个模型，展示三次重复的 min–max 波动区间，而非单次最优输出；稳定性必须拆成“候选集合一致性”与“最终推荐一致性”两个指标分别呈现——现行规则只算前者，于是 B 侧 S2 三次三款车仍判 100 分（见 2.4.2）。指标该度量什么，比算得准不准更难发现。token、延迟一律标注接入方式、模型版本、采集日期与相对分的对照组；更换模型与更换接入方式必须拆成单变量实验，否则无法归因。

工程约束：采用 OpenAI 兼容接口；密钥仅经环境变量读取；日志脱敏后导出；模型可替换、不绑定特定厂商。第一版不启用 function calling，理由为本组该维度样本数为 0，且 15 款车型可完整随提示词注入；待车型库扩展至数百款规模后再行评估。

概括而言：将 2.5 中“评测侧的修复措施”产品化为“用户侧的默认行为”。

2.6.4 B（Benefit）

对象	收益	目标指标（预期，非实测）	验证方式
C 端购车人	每项参数均可展开查看来源；预算变更后可查看差异记录与更新后的结论；同一需求多次询问结论一致	证据点击率、需求变更后结论一致率、同需求三次候选集 Jaccard 提升	基于本组 18 份 transcript 开展离线回归，并辅以小范围用户测试
内容平台 / 经销商	输出具备留痕与可审计能力，降低“编造参数”引发的投诉风险	已回对确认的口径误伤归零、零事实错误漏判；人工复核工作量下降	在正式 18 份日志上运行模块 3 校验器：33 条已确认误伤应全部予以放行、不产生误报；模块 5 的双指标另须能呈现 B 侧 S2 候选集一致而最终推荐不一致的情形
开发者 / 评测团队	一套可复用的口径、日志格式与离线重算命令	A 侧一致性 94.44 → 100（锚点修订）、防幻觉 99.11 → 100（口径修复），均为依 2.4.2 方案估算的预期值，非实测	由原始日志执行 score 重算，并逐项核对四项断言
商业侧	无需更换模型或重新训练，仅增设中间层；校验层纯规则，正常路径开销 <10ms，仅失败路径重试一次	边际成本接近零	压力测试与延迟对比

需明确两点：其一，上述均为须经现有 18 份日志离线回归及后续 A/B 验证方可确认的目标值，并非上线效果；其二，本组正式样本仅含 2 模型 × 3 场景 × 3 次 = 18 次、15 款车型、一套提示词，每格仅 3 次重复，两批采集日期不同且成本延迟为相对分，相关指标不得外推至其他车型库或模型版本。校验层本身亦存在代价：失败路径的重试将推高延迟，故重试上限设为 1 次，长场景仅对 final 轮执行事实回查。

2.6.5 C（Competitors）

对手	参数可核验	多轮需求变更	输出结构稳定	口径与留痕	主要短板
通用大模型对话网页 / App	弱，参数无出处	依赖上下文记忆，易发生漂移	中	弱	同一需求多次询问结果不一致；预算调整后前后结论不符
垂直汽车平台（参数库、选车工具）	强，数据权威	弱，以固定筛选项为主	强	中	不支持自然语言形式的多条件推理与解释
通用 Agent / 低代码平台	中，取决于自建	中	中	中，需自行搭建	默认不含行业确定性规则，校验与留痕依赖使用者实现
本组现有评测脚本	强	强	强	强	仅面向开发者，缺乏面向用户的产品形态
“车证 CarProof”	强（复用车型库 + 证据链）	强（变更快照）	强（确定性候选池 + 校验层）	强（双通道复核 + 口径标注）	车型库需持续维护；第一版仅覆盖固定快照

差异化定位并非“又一个购车聊天机器人”，而是模型输出与用户决策之间的可复核层：垂直平台具备数据而缺乏推理，通用模型具备推理而缺乏出处，Agent 平台具备编排而缺乏行业规则，评测脚本具备口径而缺乏用户界面。在本次调研所及的公开资料范围内，该位置主要由各团队内部临时脚本填充，未见标准化产品。本方案不与平台争夺数据源，亦不与模型厂商竞争模型能力，仅将“结论可采信”这一环节标准化。

2.6.6 D（Delivery）

阶段一 · 开发者种子期（以可复现性为首要目标）。 将校验层、证据链与口径规则以开源套件形式发布，与本组代码仓库、18 份脱敏日志（标注接入方式与采集日期）、评分表及博客同步发布。成功标准唯一：第三方使用自有日志可获得一致的重算结果。该安排亦符合作业关于“代码上传仓库、博客附仓库链接、不粘贴大段代码”的要求。

阶段二 · C 端 MVP（浏览器插件 / 小程序）。 用户可在任意购车页面选中车型或输入需求，由系统生成单页“可核验报告”：结论置于页首，默认展示 3 条可展开依据，进阶证据默认折叠。第一版仅采用 15–30 款车型的固定快照，明确标注采集日期与“非实时行情”，不承诺价格实时性。核心指标：证据点击率、需求变更后结论一致率、人工复核误伤率。

阶段三 · 平台侧嵌入。 与汽车内容平台、经销商合作，将报告作为内容组件嵌入；商业模式不以 Token 转售为基础（2.2.3 已分析单位价格持续下探），而按“可核验报告调用量／合规审计能力”向 B 端收费，C 端免费。推广不依赖流量投放，而依托“可复现 + 可核验”特性在开发者社区与课程实践场景中扩散，并在公开评测中持续标注统计口径与样本量以建立可信度。

风险与对策：车型库维护成本较高 → 仅采用带日期的快照，不承诺实时性；校验过严导致正常输出被误判 → 以精确匹配优先、归一化匹配兜底，优先放行并附加标记，避免误判；模型版本升级引发口径漂移 → 记录实际返回的 model_version 与测试日期，版本变更时触发重跑；用户感知额外操作负担 → 证据默认折叠，结论优先呈现，证据按需展开。

2.6.7 功能取舍

候选方向	方案优势	未列为主方案的原因	升级为主方案的条件
纯提示词约束	零成本、零延迟	本组 S1-A-r3 已表明，模型对“初筛须逐条核对候选池并完整列出全部满足车型”这类约束的遵循并不完全；33 条误伤中 24 条源自主语省略的比较句与门槛复述，提示词仅能缓解，不具备检测与恢复能力	保留为校验层重试提示的一部分，不独立成方案
更换更强模型 / 多模型投票	实施最为直观	A、B 两侧指令遵循均为满分，B 侧更换模型并统一接入方式后，S1 稳定性仍仅为 54.67，S2 三次最终推荐仍为三款不同车型；更换模型无法解决“机器无法判定”与“指标受接入方式影响”两类问题；且企业一旦选定供应商，通常倾向长期沿用，替换成本最高	降级为模块 5 的可选对照能力
RAG / 工具调用实时查车型库	对幻觉的抑制最为彻底	需 function calling 支持，并须重构四轮流程与全部测试脚本；本组 15 款车型随提示词注入已可满足需求，72 条 assistant 记录 tool_calls 全空、该维度样本数为 0，本组未产生该维度的实证数据，不宜将其列为第一版主线	车型库扩展至数百款、上下文容量不足时升级为主方案
多模态看车 / AR 选车	需求真实（CNNIC：47.8% 用户用生成式 AI 处理图片视频）	与本次实验的证据链关联较弱，第一版缺乏相应数据支撑	列入二期
自建通用低代码 Agent 平台	市场关注度较高（Gartner 于 2026 年单列无代码 Agent 构建工具新兴市场象限）	具备灵活性，但默认缺乏行业确定性规则，恰为本次所识别问题的成因；且自建平台投入超出本组实施范围	不采取自建路径，将相关能力封装为可嵌入组件

选择依据可归纳为三点：① 唯一可基于本组 18 份日志离线验证、零 API 成本且可复现的方案；② 与模型解耦，A、B 及未来接入的任何模型共享同一保护层；③ 直接对应 2.6.4 所述市场落差——不追求“更强的生成能力”，而补足“更充分的可复核性”。

采用动因：购车属数十万元量级、低频、信息不对称且需求可能中途变更的决策，“有出处、可复现、预算调整后结论一致”较“表述更为流畅”具有更高实际价值；开发者群体先行采用，则源于“可基于自有日志复算”本身即可显著降低验证成本。创新点（对应作业创新评分项）共三处，均具备可迁移性：锚点跟随最新候选集的一致性口径、误伤 / 错误双通道复核、成本口径随接入方式标注。

---

2.7 对大模型现实影响的看法

2.7.1 可观察到的三个变化

变化一：信息检索的初始路径发生改变。 既往进行车型比对，需在配置页、保值率榜单与论坛之间反复切换；当前则以单次提问为起点，经四个关键轮次即可获得候选清单、对比表格与最终建议。本组 18 次运行中，JSON 候选、Markdown 表格、最终推荐 JSON 的格式要求全部达成，18 组最终推荐全部通过预算与硬约束检查。但 S1-B-r3 初筛的 3 款候选中仅 1 款满足硬约束，表明初始路径有效并不等价于中间过程可靠。就本组可观察的日常使用情形而言，该变化基本局限于检索起点：概念查询、代码修改与邮件撰写等场景中会优先向模型提问，而将模型接入需要核对并承担后果的决策链（如购车）的情形仍属少数。

变化二：软件工程的关注重心由“实现功能”转向“定义正确性判据”。 本次投入最大的不是 API 联调，而是把 33 条失配逐句与原文回对、确认全部为抽取器误伤（见 2.4.2）。在常规 CRUD 开发中，“运行通过、结果正确”通常即视为完成；而在生成式系统中，答案生成成本大幅下降，口径设计与验证反而成为质量主体，而验证工具本身也会出错，且比模型出错更难发现——S1-A-r3 判 50 分、B 侧 S2 三次三款车却判稳定性 100，均属此类。该结果超出本组的初始预期：原本判断难点在于调通两个模型，实际难点在于证明“评分器判定正确”。

变化三：成本评估与能力评估必须分开做。 成本延迟是两模型之间的相对分，最初两批日志各自归一化、两侧都记 100 分，表观持平而对照对象不同；统一基准后 A 42.67 / B 100.00——同一个“100 分”，更换基准后即为 42.67 分。更能说明问题的是那组不计入 18 次的预实验：B 侧经本机 CLI 中转、每轮重传历史，token 是直连的 3.2 倍、成本延迟降到 61.56 分；但 A 侧同样直连，单轮延迟仍 23.7 秒，与预实验 B 的 25.9 秒接近，说明延迟差异不能全归给接入方式。该对照同时变更了模型与接入方式，仅可作为量级参照。方法学结论可归纳为两点：要说明因果必须单变量控制，要比较分数必须同基准。单位报价仅构成账单的一部分，上下文管理、重试策略与接入方式均计入总成本；对按量计费的课程实验而言，这组实测数据的参考价值高于任何公开榜单。

2.7.2 一个需要警惕的风险

更值得警惕的并非“模型是否会输出错误内容”，而是“表述流畅”被等同于“已核验”，以及由此产生的判断权外包。

本组的防幻觉扣分经逐条回对后全部为口径误伤，人工盲评该维度 18/18 满分（见 2.4.2、2.4.4），表观风险很低。但反向看更值得注意：抽取器对车型名的鲁棒性亦有限——“比亚迪 汉”多一个空格即匹配失败；据此推断，一个真正编造的车型名，只要写法接近库内别名、或未指明具体车款，同样可能通过该规则而未被检出。高分不等于零风险，只说明“在该口径下未被检出”。 这是假设而非结论，但“未被检出”不等于“不存在”。

更具现实意义的是表述风险：若评分表与结论未明确标注“33 条失配全部为口径误伤”、“B 侧 S2 的稳定性 100 分对应三次不同的最终答案”、“每格仅 3 次样本”、“5.83 分里 5.73 分来自成本一维”，读者极易把“A 91.73 / B 97.56”直接读成“B 的能力更强”。进一步拆解可见，成本一维之外的五个质量维度上，A 领先三项、B 仅领先一致性一项（指令遵循打平），五项加权合计相差不足 0.1 分——不足以支撑“B 的能力更强”的判断；B 的优势集中在“输出更短、更快”这一与结论正确性无关的特征上。一个未被拆解的加权总分，比一个错误的数字更容易被误读——它带有看似精确的小数点，却未交代该小数点的来源。作业对结论边界的反复要求，正是为规避此类误读：缺乏限定条件的数值，较之错误数值更易被传播。

在实际应用层面，该风险更为具体：购车属数十万元量级的一次性决策，模型可生成结构完整的表述，但不承担选错车型的后果。2.6 中“17% 已部署对比 60% 计划部署”为行业层面的同类征兆；就本组实验而言，更直接的启示来自该 5.73 分的成本贡献——模型能力先行到位，验证机制与责任归属未能同步。

2.7.3 通用场景下的双面效应

前面两点立足于AI选车这一决策类垂直场景，而放到办公、学习、开发、信息检索等绝大多数通用场景中，大模型同时带来效率红利与认知隐患，呈现明显的双刃剑特征。

（1）正向价值：降低门槛、压缩常规任务成本
第一，标准化工作的生产效率大幅提升。无论是文档初稿撰写、表格整理、代码模板编写、资料摘要提炼，还是基础信息检索，大模型都能快速生成结构化文本，把人从重复性文案、格式排版、基础语法纠错中解放出来，把精力集中在方案设计、逻辑权衡、边界校验等高阶思考环节。原本需要多平台来回检索、反复整理材料的流程，现在可以通过一轮自然语言提问完成初步内容输出，大幅缩短迭代周期。
第二，降低技术与信息获取门槛。零基础人员也可以用自然语言提出需求，快速拿到成型方案；新手开发者可以借助模型补齐语法短板、快速完成基础功能开发，缩小经验差距，让更多人能够低成本开展项目实践。
第三，统一输出格式，降低协作沟通成本。模型可以稳定输出Markdown表格、JSON、结构化清单，多人协作时无需反复对齐排版规则，便于直接对接后续程序、评审文档与数据校验环节。

（2）负面隐患：认知惰性与质量管控失效
首先是普遍存在的过度依赖与思考弱化问题。当模型可以直接给出通顺完整的答案后，使用者容易跳过查证、推导与独立思考，直接把AI生成内容当成既定事实，慢慢丧失拆解问题、核验信息的能力。长期依赖AI完成初稿，会造成独立思辨能力下滑，面对复杂权衡问题时难以自主识别矛盾条件与方案短板。
其次是幻觉问题在通用场景里更加隐蔽。购车场景还可以对照车型库逐条核验参数，但在文案、论述、行业资料这类无明确标准答案的场景下，模型编造事实、引用不存在文献、混淆时间与数据的行为很难被快速识别。文字流畅度会掩盖内容真实性，“行文通顺”极易被等同于“内容可靠”，虚假信息会随着成品文档一起传播，事后追溯成本极高。
最后是评价标准模糊带来的结论失真。就像本次实验里加权总分容易误导判断一样，在通用场景中，人们常常只看最终文字好不好读，而忽略前提条件、样本数量、数据基准与误差来源。缺少明确校验规则时，模型输出的结论会自带“精确可信”的外表，使用者很容易忽略结论的适用边界，把有限条件下的局部结果直接推广到全部场景。

（3）综合结论
垂直决策场景（购车）与通用办公场景的底层规律一致：大模型最擅长解决规则清晰、可格式化、可自动核验的标准化任务；但只要进入多条件权衡、事实核验、责任落地的环节，模型只能作为初稿助手，不能直接替代人的最终判断。
技术层面可以不断优化模型输出稳定性，但人的“批判性核验意识”与配套验证机制，才是规避幻觉、防止结论误读的核心保障。只追求生成速度与文本流畅度，而不建立对应的校验流程，无论在选车选型、代码开发还是文案写作中，都会放大决策风险。

---