拾光友人帐 —— 大模型评测作业

作业基本信息

• 仓库链接：https://codehub.devcloud.cn-north-4.huaweicloud.com/1cc4d1420a3d44a88e53cc3c2084e46f/222.git

目录

第一部分 调研，评测

1 评测设计：怎么让「公平」可被验证

1.1 被测对象与选型理由

模型标识必须核实，否则整篇结论都会被读歪：deepseek-flash 是 DeepSeek 官方 API 的现行模型名，自 2026-09 起由 DeepSeek-V4.1-Flash-1017 提供服务（旧名 deepseek-v4-flash 会被路由到同一模型）。所以本文的 "大模型一" 准确说是 V4.1-Flash，不是早期文档里常见的 deepseek-chat（V3 系列）。平台侧也不是直接用开放平台控制台，而是经自建 harness 调用，记录里已注明。

选这两个不是为了 "比大小"，而是为了让对比有意义：

1. 两者都是面向大众的通用对话产品，界面成熟、用户基数大，测的是 "普通用户实际能拿到的体验"，而不是 API 的理论上限；

2. 两者都有低价或免费入口（DeepSeek 按 token 计费且价格低，ChatGPT 有免费额度），符合 "不购买付费模型或设备" 的作业要求；

3. 任务与话术被压到一致，客户端没有：两组用同一份执行卡、同一套 25 轮话术逐轮发起，都不做 "一键跑批"（提前把后续轮次写进同一条消息，会让模型看到还没发生的题面，记忆类测试会偏乐观）。但客户端不同：一组是自建 harness，另一组是 Codex CLI（App Server）。这一条没法统一，是本次最大的不可控变量，已写进第 8 节局限。

两组的 "模型标识" 都是照界面 / 接口返回值原文抄的，不许按印象写版本号：deepseek-flash 在 2026-09 起由 DeepSeek-V4.1-Flash-1017 提供服务；gpt-6.1-sol 是 Codex App Server 在记录头里回写的模型名。前者是我们主动指定的，后者是平台回写的 —— 两者性质不同，后者更接近 "我们只能记录，不能选择"。

测试日期：DeepSeek 组 2026-11-08；ChatGPT 组 2026-11-09（均为北京时间）。

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

1.3 固定车型库（教学模拟数据）

12 款车，覆盖 SUV / 轿车 / MPV、燃油 / 混动 / 插混 / 增程 / 纯电、前驱 / 后驱 / 四驱，价格集中在 12–28 万。

必须声明：这是一份教学模拟车型库，车型名（启元、云途、星驰、恒岳、陆洲、明澜）与参数均为教学虚构，不是真实市场数据，不得引用为行情。

口径与单位（表头必须写清，否则「落地价 20 万」这句话就无法判定真假）：

• 价格单位：万元；指导价 为厂商指导价，落地价 含购置税、首年保险、上牌费；

• 功率 kW；零百加速 s；油耗 L/100km（WLTC）；电耗 kWh/100km（CLTC）；

• 纯电续航 km（CLTC）；轴距 mm；后备厢 L（七座车型为满员状态）；

• 3 年保值率 %；年保养成本 元；

• 口径日期：2026-10-15。

1.4 场景设计与「事前写定」的预期答案

关键做法：预期答案不是事后总结出来的，而是在正式跑批之前就用规则算出来、写进配置的（SCENARIOS[*].expect）。否则「评分」会变成「照着模型的答案编标准」。

• 场景数量：3 个正式场景 + 1 个边界场景（单独标注）；

• 重复运行：每模型每场景独立跑 3 次 → 2 模型 × 4 场景 × 3 次 = 24 次完整多轮任务（其中正式场景 18 次，满足作业要求）；

• 上下文管理：同一任务内保留上下文，不同运行之间重建会话；

• 需求变更：场景 B 第 6 轮插入，用来查「上下文保持 vs 需求更新」这两件事能不能分开处理（用户明确改需求后采用新需求，不算前后矛盾）。

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

单次任务的自动分 = C1 + C2 + C3 + C4（满分 80）；聚合阶段再补 C5、C6（满分 20）。

C6 为什么仍是 N/A，而不是 "谁快谁慢"：C6 的设计前提是两个模型都测得同一口径的延迟与 token。本次只有 B 组有这两个数（逐轮计时 + Codex 会话累计），A 组 12 份记录该栏全空 —— 一侧有数据、另一侧没有，任何比值都只是 "拿 A 组的空白去比 B 组的实值"，比出来必然是满分或零分，属于指标失效，不是结论。所以这里记 N/A，只在 3.2 与表 2 里并列展示 B 组的绝对数字，不做比较。

样本量：每格 n = 3。样本很小，所以本文所有结论都写成「在本次数据、场景与设置下」，不做行业排名。

1.6 测试流程

图 1　购车决策多轮任务自动化评测流程（两模型共用同一管线）

流程对应作业要求的 5 个动作：提出购车意图 → 初步推荐捕获候选列表 → 逐条输入购车要点 → 参数表格化对比 → 选出目标车型 → 自动评分与落盘。

代码规模：主脚本 car_eval.py 约 800 行，--provider mock 模式用于自检「解析 + 评分 + 可视化」这条管线本身是否成立（也是我们调试评分器的主要手段），--provider live 用于直接调 API 跑批。本次真实数据没有走 live：两组约定在对话界面逐轮执行，记录落盘后由同一套评分规则离线判定（见 1.2 与 1.6）。

2 大模型一：DeepSeek-V4.1-Flash（deepseek-flash）

2.1 体验

基本功能：对话式问答、长上下文、文件上传、深度思考开关、联网搜索开关；开放平台侧另有 OpenAI 兼容接口、按 token 计费与用量面板。

实际使用过程：先在网页端把 "预算 20 万、通勤、要空间和安全" 原样问一遍，然后按执行卡跑完 4 个场景 12 次任务（每次新开会话、关掉联网）。整轮下来最直观的一点是**它愿意说 "没有"**：C、D 两个空集场景里，它三次都把冲突写成一句话（"后备厢 ≥450L 与预算 ≤25 万在这张表里互斥"），而不是硬凑一款车出来。

图 2　DeepSeek 网页端会话（占位图，发布前替换为真实截图）

解决了用户的问题么？ 在 "约束明确、答案有限" 的问题上解决了：给它一张表 + 一句 "落地价 20 万、轴距 2750、要 L2"，它能收敛到 2 款车并逐个报数。在 "约束互相打架" 时，它给的是 "最接近方案 + 取舍建议"，而不替你决定该放宽哪一条—— 这既对（它不该替你决策），也让人有点空：它没有结合 "你常跑山区路" 这个语境告诉你四驱和后备厢哪个更该让。

优点（按作业要求的四个角度）

缺点

我对产品的改进意见（三条能落地的）

1. **对话内 "约束台账"**：把用户说过的硬约束抽成一张可折叠、可勾选的卡片，每轮更新时高亮变更项。这比让模型 "记得" 更可靠，也便于用户纠错 —— 本次 4 处 "L2 被写成 L2+" 就是这么漏掉的。

2. 表格视图与会话分离：参数对比表应该是可排序、可固定首列的组件，而不是一段会长会短的 Markdown 文本。

3. 价格口径前置：用户说 "20 万" 时，产品应主动区分 "指导价 / 落地价 / 分期首付" 并常驻在会话顶部，而不是每轮重新问一遍。

2.2 自动化测试

DeepSeek-V4.1-Flash 完成 4 个场景共 12 次完整任务（正式场景 9 次 + 边界 3 次），单次 6～7 轮对话。注意：原始记录来自人工逐轮执行，评分由 car_eval.py 离线判定，不是 API 批量跑出来的。

扣分集中在 C3（指令遵循）：C 场景三次、D 场景一次，共 4 处把 "L2" 复述成 "L2+"；以及 B 场景 1 次把库表字段错记为更高档（C4 −3，见第 6 节）。

关键代码（完整版见仓库 car_eval.py）：评分器的核心不是 "看懂回答"，而是把回答变成可判定的事实。

def violations(car, cons):
    """把一款车和一组约束做机械比对，返回未满足的约束文字。"""
    out = []
    for con in cons:
        v, op, want = car.get(con["field"]), con["op"], con["value"]
        if   op == "<=" and not (v is not None and v <= want): out.append(con["text"])
        elif op == ">=" and not (v is not None and v >= want): out.append(con["text"])
        elif op == "==" and not (v == want):                   out.append(con["text"])
        elif op == "!=" and not (v != want):                   out.append(con["text"])
    return out

def valid_set(cons):
    """可行集由数据算出，不由模型或人给。"""
    return [c["name"] for c in CARS if not violations(c, cons)]

# 每轮对话：同一会话内累积 messages；不同运行之间重建 messages
steps = [(1, sc["intent"]), (2, "请给出 3 款初步推荐候选并说明理由。")]
steps += [(3, f"我再补充几项关注点：{p}。请结合这些要点分析候选车型。") for p in sc["points"][:3]]
steps += [(3, "还有两点：…"), (4, "请把候选车型的关键参数用 Markdown 表格对比…"),
          (5, "结合前面所有信息，请给出唯一个最终推荐车型，并列出至少 3 条理由。")]

图 3　管线自检：在终端跑 python car_eval.py --provider mock --models deepseek --runs 3，12 次任务全部跑通、评分与 CSV/MD 落盘正常（该模式只验证管线本身，数值不代表真实结论，真实数据见第 2 节；占位图，发布前替换为终端实拍）

2.3 结论

DeepSeek-V4.1-Flash 在本次设置下是 "稳、肯说没有" 的那一个：4 个场景 12 次任务里没有一次违反硬约束，没有一次编造车型；C、D 两个空集场景 6 次全部正确声明无解，被追问时还能逐条打勾、自己判 "后备厢 380L ❌"。

它的短板全在表述层，不在结论层：

• 复述约束时把 "L2" 写成 "L2+" 共 4 处（C 三次、D 一次）；

• B 场景第 1 次运行把明澜 V6 的智驾错记为 L2+（库表是 L2）；

• 效率只测到 token 量级（约 1.0 万 token / 任务），延迟因网页端无计时未采集，所以本文不给它任何 "快" 的结论。

3 大模型二：ChatGPT（gpt-6.1-sol，经 Codex CLI 调用）

这一节的记录不是人工抄的：12 份 md 由 Codex 在跑批时自动生成，逐轮回答原样写入，同时记下模型标识、运行参数、每轮耗时与 token 用量。所以它比第 2 节多两样东西 —— 可核对的耗时与可核对的 token，也因此在 "效率" 这一维上，本文只有它一侧有数。

3.1 体验

基本功能：走 Codex CLI（App Server，以 ChatGPT 账号登录），命令行里发一条消息拿一条回答，返回里带 usage；可设推理档位（本次 reasoningEffort=high）、可挂本地文件与工具（本次 web_search=disabled，全程无工具调用事件）；不设 temperature 与 max_tokens（Codex 默认）；每次运行新建会话，上下文只在本任务内累积。

实际使用过程：四个场景各跑 3 次，每次 6 轮（B 场景 7 轮，因为多一次需求变更），另有 1 轮初始化确认。单场景总耗时 50.40–82.11 秒，平均每轮 8.40–13.09 秒，逐轮记在记录头里。

它把 "不知道" 当成了答案的一部分 —— 这是本次最鲜明的印象。库表 20 列里没有挡位字段，12 款车里只有恒岳 H6 的 trim 明确写了 "手动"（2024款 1.5T 手动 精英）。ChatGPT 从第一轮起就把 "不接受手动挡" 判成 "库表未注明挡位类型，无法确认"：A 场景第 4 轮直接给了一张只有表头的空表，第 5 轮才给出" 唯一优先目标 星驰 EV3，前提是确认它不是手动挡 "，第 6 轮逐条打勾写成"3 条满足、1 条无法确认、不能算 100% 满足 "。

这种保守一半是优点、一半是错误：D 场景它主动补了 "库表未注明 Q5 挡位，只有确认是自动挡，17.50 万才够"，这是负责任的诚实；A 场景它却对纯电车型（星驰 EV3，物理上不存在手动挡）也拒绝排除这一项，把 2 款的可行集判成 0 款，这是**把 "字段缺失" 错当成 "条件不成立"**（第 6 节案例三）。

图 4　ChatGPT / Codex 会话与记录（占位图，发布前替换为真实截图）

解决了用户的问题么？ 要分三类看：

• 有解且约束清晰（B）：解决得很干净。需求变更后三次都从明澜 V6 切到云途 M7，第 7 轮还专门列表写清 "两款都是 L2，所以智驾不是换车的原因，变更是预算 22→25 万 + 新增四驱 "。这不是" 答对 "，是把因果说对了。

• 无解（C、D）：比预期好。C 场景三次都先说 "按原预算无完全满足车型"，再给加钱方案（run1/run2 收在陆洲 K5 26.90 万、超 1.90 万；run3 收在云途 M7、后备厢差 70 L），第 6 轮逐条 ✅/❌（都是 4✅1❌）；D 场景三次都答 "无解"，并给两条路 —— "守住 16 万就得同时放弃自动挡和 L2"、"不放弃配置则预算至少提到 17.50 万买启元 Q5"，还诚实地补一句 "库表未注明 Q5 挡位，只有确认是自动挡，17.50 万才够"。

• "未标注" 与 "不满足" 混在一起（A）：没解决。可行集本来是星驰 EV3（18.60 万）+ 陆洲 K3（19.80 万），它交出的是一张空表和一句 "不能算 100% 满足"。

优点（按作业要求的四个角度）

缺点

我对产品的改进意见（三条能落地的）

1. **区分 "缺失" 与 "否定"**：结构化数据里 null 与 false 是两件事。字段缺失时应给出 "未知 + 可用的替代证据（能源类型 / 配置表 / 厂商口径）"，而不是把整条约束判死。

2. 给 "待核实" 一个出口：现在它只能说 "无法确认"，用户拿到的是死胡同。更好的做法是 "无法确认 + 一条可执行的核实动作（查配置表 / 问经销商）+ 该前提下的推荐" —— A 场景第 5 轮其实已经这么做了，只是第 4 轮没做，落差就出在这里。

3. 长度自适应：明确要求列数 / 行数的指令，应触发最小输出长度约束，而不是让模型自己决定要不要展开。

3.2 自动化测试

ChatGPT 完成 4 个场景共 12 次完整任务（正式场景 9 次 + 边界 3 次），单次 6～7 轮。原始记录由 Codex 自动生成，评分由 car_eval.py 的同一套规则离线判定，模型名不做任何特判。

扣分逐条说明（每条都能按 模型 + 场景 + run 回到记录）：

• A 的 C1 −3：最终推荐星驰 EV3 落在可行集内，但三次都把 "非手动挡" 判成 "无法确认"，第 6 轮自评 "3 条满足、1 条无法确认、不能算 100% 满足"；

• A 的 C2 −3：第 4 轮 "没有可确认满足全部要求的车型（不列对比表）" 与第 5 轮 "唯一优先目标 星驰 EV3" 前后张力过大；

• A 的 C3 −3：第 4 轮被要求给 6 列以上的对比表，实际只给了表头；

• A 的 C4 −3：对纯电车型也以 "库表未注明挡位" 为由拒绝判定 —— 数据没错，但把常识上可推定的信息当成未知；

• B 的 C2 −1：第 2 轮先称 "没有能确认满足全部要求的车型"，第 5 轮又推荐明澜 V6（结论对，过程自相拉扯）；

• C 的 C3 −4 / D 的 C3 −3：C、D 的第 4 轮只回一句 "无完全满足车型"，未按指令给对比表。

效率与计量（本节独有，A 组无此数据）

口径提醒：这里的 token 是
Codex 会话累计
—— 每轮都把历史重发一遍，输入里 70%～85% 是缓存命中。它与 A 组 "中文字符 ÷ 1.6 估算 ≈ 1 万" 不是同一种计量，
差一个数量级且不可互比
。因此表 2 并列展示、但不排名，C6 仍记 N/A。

3.3 结论

ChatGPT 在本次设置下是 "讲得清、但不敢下判断" 的那一个：

• 强项：空集场景（C、D 共 6 次）全部正确声明无解并给出取舍；量化比较能力突出（保值率排名、同座数内油耗排名全部算对）；12 次任务零编造、零价格错记；

• 弱项：把 "字段缺失" 当成 "条件不满足"，在 A 场景把本可行的 2 款车判成 0 款 —— 这是 12 次里唯一一处结论级错误，也是第 6 节案例三、第 13 节归因的主线；

• 表述：三次运行答案几乎逐字一致（四个场景的自动分标准差全为 0），B/C/D 的稳定性都拿满 10.0；但 A 场景因为 "通过率为 0"（可行集被判空），C5 只有 4.0 —— 它很稳，只是稳在了不该稳的地方。此外篇幅偏短，"给对比表" 这类指令容易被压缩成一句话。

4 用户采访记录

a) 采访对象的背景与选择理由

• 对象：同班同学 L，软件工程专业大三，正在准备实习，家里确有购车计划（预算 20 万上下）；

• 为什么选 TA：① 属于作业要求的「计算机 / 软件相关专业学生」，能同时从 "用户" 和 "工程" 两个视角反馈；② TA 有真实购车需求，不是被迫体验；③ 我们组里其他人都是模型评测视角，需要一个 "纯用户视角"。

• TA 的需求：在有限预算内把 12 款车筛成 1 款，并且能对着家里人讲清理由。

b) 实际使用的产品栏目

c) 会遇到的问题与亮点（区分实际观察与原因推测）

d) TA 认为需要改进的地方

1. 口径确认前置：预算必须问清 "落地 / 裸车 / 首付"，并常驻在会话顶部；

2. 约束台账：把用户说过的硬约束做成可勾选、可修改的清单，改动后自动重算；

3. 表格适配窄屏：固定车型列 + 横向滚动，或直接给 "卡片式对比"；

4. **敢说 "没有"**：找不到完全满足的车时，先明确告知冲突项，再谈取舍；

5. 可信度标识：每个数字标注来源（本车型库 / 联网检索 / 估算），让用户知道哪些能信。

收获：用户对 "准不准" 的容忍度，比对 "快不快" 低得多。一次编造就会让 TA 放弃整个产品 —— 这和我们在评分里把「防幻觉」单独设 15 分是同一个判断。

5 测试结果汇总与可视化

表 1　各场景综合得分（每格为 3 次独立运行均值）

口径：C6（成本与延迟）需要两个模型在同一口径下互为对照才成立。本次只有 ChatGPT 一侧有延迟与 token 数据，DeepSeek 侧两者全缺 → C6 记 N/A，综合分按
90 分制
计。

四场景平均：DeepSeek-V4.1-Flash 88.5 / 90（98.3%）、ChatGPT 83.5 / 90（92.8%）。

C5（稳定性）按 1.5 的公式 6×通过率 + 4×max(0, 1−σ/12) 计算，两组的差别恰好解释了它为什么这样设计：

• DeepSeek：A、C 三次得分完全相同（σ=0）得 10.0；B、D 各出现 1 次 3 分差（77/80/80，σ=1.41）得 9.5。分差全部落在 "复述约束不严谨" 这一件事上；

• ChatGPT：B、C、D 三次完全一致（σ=0）得 10.0；A 场景通过率为 0（C1 未满分，三次都把可行集判成空集），按公式 6×0 + 4×(1−0) 只得 4.0。

这个 4.0 是公式在提醒一件事：稳定性只奖励 "稳"，不奖励 "稳在对的方向"。ChatGPT 在 A 场景上稳定地错，如果只算 σ，它会拿满分 —— 所以 C5 的 6 成权重压在 "通过率" 上，是刻意的。

表 2　效率、成本与稳定性

口径说明一：DeepSeek 侧的 token 由中文字符数 ÷ 1.6 估算，含每轮重发的系统提示与车型库；A 场景三次估算值 9,500 / 8,500 / 8,500 有 ±10% 波动，属于
估算本身的不确定性
，不构成模型差异。
口径说明二：ChatGPT 侧的 token 是
Codex 会话累计
（每轮把历史重发一遍，输入中 70%～85% 是缓存命中），单位是 "万级"；DeepSeek 侧是 "千级"。两者
差一个数量级且不可互比
，所以这张表只并列、不排序，也不换算 "谁更省"。
口径说明三：单次任务成本一栏两组都留空 —— 我们拿到了 token 数，但没有取得两家可核对的公开单价（且一组的 token 本身是估算值）。
用估算 token × 记忆里的单价算钱，得到的数字不具可复核性，本文不做。

图 5　两模型五维得分率对比（四场景均值；成本维度因计量口径不可比记为 N/A，故雷达只有五轴）

图 6　各场景综合得分对比（自动分 + 稳定性，满分 90；每格为 3 次运行均值）

图 7　同一场景 3 次独立运行的自动分波动（横线为均值，标注了 σ；三点重合即 σ=0）

图 8　ChatGPT 侧的单轮耗时与单次 token（DeepSeek 侧未采集、且 token 口径不同，因此不做双模型对比）

读图要点

1. 两组的差距几乎全压在 A 场景上：DeepSeek 90.0、ChatGPT 72.0，差 18 分；其余三个场景只差 1.5、1.0、1.5 分。换句话说，样本里 24 次任务的差异，主要由一张表里的一个缺失字段决定。

2. A 场景不是 "谁更聪明" 的题，而是 "字段缺失时怎么办" 的题：库表 20 列没有挡位字段，只有恒岳 H6 的 trim 写了 "手动"。DeepSeek 据此推定其余 11 款非手动（保守起见只取 EV3 + K3），ChatGPT 则坚持 "未注明即无法确认"，连纯电的 EV3 也不排除。前者激进、后者保守，两种策略都能自圆，但按本文事先写定的可行集判定，后者错（见第 8 节讨论）。

3. **DeepSeek 的扣分在 "表述"，ChatGPT 的扣分在 "判定"**：前者 4 处把 L2 复述成 L2+、1 处字段错记（都是 "说得不准"）；后者 1 处把可行集判空、3 处该给表只给一句话（都是 "答得不全"）。这决定了第 7 节的修复方案必须同时管住两类错误。

4. "稳定" 不等于 "正确"：ChatGPT 四个场景 σ 全为 0，比 DeepSeek 更稳；但它在 A 上稳地错，C5 只有 4.0。反过来 DeepSeek 有两次 3 分波动，却每次都在可行集内。评测里 "方差小" 是加分项，不是结论。

5. 成本与延迟不能下结论：图 9 只有一侧的柱子，两组既不同客户端、也不同计量口径，任何 "谁快谁省" 的说法都不成立（第 8 节局限第 4 条）。

6 失败与边界案例分析

案例一（真实，可复核）：复述约束时把「L2」抬高成「L2+」

• 记录：deepseek / C / run1-第2轮、C / run2-第2轮、C / run3-第4轮、D / run3-第4轮（共 4 处）。

• 具体表现：用户原文是 "必须有 L2 及以上"，它把这条复述成 "L2+"。库内启元 Q5 是 L2（不是 L2+），按 L2+ 筛会把它排除 —— 而 Q5 恰恰是它在 D 场景第 5、6 轮给出的 "加钱方案"，也就是说复述失真是与后续推荐自相矛盾的。

• 为什么值得记：这不是算错数，而是把用户的门槛偷偷调到更严。在约束求解类任务里，"复述失真" 比 "结论错" 更难被发现，因为答案看起来仍然自洽。

• 可能原因（后两条为假设）：① 该模型对 L2 / L2+ 分级的表述不稳，习惯性写成 "L2+"；② 提示词里 "智驾≥L2" 与表格列值 "L2 / L2+" 混用，缺一句 "必须按原词复述"（这一条是我们这一侧的问题，可以改）；③（假设）模型把 "及以上" 额外理解成 "取更高一档"。

案例二（真实，轻微）：把库表字段记成更高档

• 记录：deepseek / B / run1-第7轮。

• 具体表现：写 " 油耗 8.9 对 5.8、后备厢 380 对 400、智驾 L2 对 L2+ 都在退 "。但库表里明澜 V6 与云途 M7 的智驾都是 L2，并不存在 "从 L2+ 退到 L2"。

• 同场景对照：run2 写的是 "智驾同 L2"（正确），run3 未提此项。同一个模型三次运行对同一字段给出不同事实，这正是 "只跑 1 次就下结论" 会漏掉的那类问题。

案例三（真实，可复核）：把 "库表未标注" 当成 "条件不满足"，把可行集判成空集

• 记录：chatgpt / A / run1、run2、run3（三次同型；关键位置在第 4、5、6 轮）。

• 具体表现：A 场景的硬约束是 "落地 ≤20 万 / 轴距 ≥2750mm / 有 L2 及以上 / 不接受手动挡"。按库表算，可行集是 星驰 EV3（18.60 万、轴距 2750、L2+） 与 陆洲 K3（19.80 万、轴距 2780、L2+）。ChatGPT 三次都把 "不接受手动挡" 改写成 "库表未注明挡位类型 → 无法确认"，第 4 轮给出只有表头、零数据的空表，第 6 轮自评 "3 条满足、1 条无法确认，不能算 100% 满足"。

• 为什么这是错误而不是 "谨慎"：库表 20 列里确实没有挡位字段，它这一点没说错。但它漏了两条可用的替代证据：① 12 款车里只有恒岳 H6 的 trim 写了 "手动"（2024款 1.5T 手动 精英），其余 11 款 trim 里没有 "手动" 字样；② 星驰 EV3 是纯电（2026款 纯电 520km 智享），纯电车型不存在手动挡。也就是说，"无法确认" 这一步它没有把可推定的事实用上。

• 对照组很干净：同一个可行集、同一句话，DeepSeek 三次都判 "EV3 与 K3 均满足" 并从中选一款作为最终推荐。两组的分歧不在数据，而在 "缺失字段如何处理" 的策略上（第 8 节专门讨论，不给对错标签，只给适用条件）。

• 代价：A 场景 C1 −3、C2 −3、C3 −3、C4 −3，自动分 80 → 68，稳定性 10 → 4.0，综合分 90.0 → 72.0。一次 "过度严谨" 掉了 18 分，是本次 24 次任务里最大的一处分差。

案例四（真实，可复核）：被要求给对比表时只回一句话

• 记录：chatgpt / A / run1..3 第 4 轮（只给表头）、chatgpt / C / run1..3 第 4 轮（只回 "无完全满足车型。"）、chatgpt / D / run1..3 第 4 轮（"无完全满足车型，不列对比表。"）。

• 具体表现：第 4 轮的指令是 "请把候选车型的关键参数用 Markdown 表格对比（列 ≥6、含 7 个指定字段）"。它在 A 给了空表，在 C、D 直接以 "无车可列" 为由跳过表格。

• 为什么值得记：C、D 是空集场景，确实没有 "通过筛选" 的车型可列；但指令要的是 "候选对比（含被排除的）"—— DeepSeek 的做法是把被排除的车也列进表（所以 C、D 各有 4 行以上），ChatGPT 只列通过项，于是无行可列。**两种都是合理的表格风格，却被一条 "表格 ≥4 行" 的机械规则判成 "指令遵循失败"**。

• 归因：这一条应当记在评分器头上（第 13 节第 5 行），而不是记成模型的缺陷。我们这一侧要改两处：C3 的行数规则改成 "通过项 + 被排除项 ≥3 行"，提示词里补一句 "即使无车可选，也要列出被排除的车型与排除原因"。

边界测试（单独标注）：无解场景下的 "正确答案" 长什么样

• 记录：deepseek / C / run1..3、D / run1..3 与 chatgpt / C / run1..3、D / run1..3，共 12 次。

• 现象一（DeepSeek，6 次）：

1. 6 次都直接给出 "无完全满足车型"，并把冲突收敛成一句话："后备厢 ≥450L 与预算 ≤25 万互斥"；

2. 第 6 轮被要求逐条打勾时，C 场景三次都把第 4 条判 ❌（"380L，差 70L"），还补了一句 "软化表述不成立"；

3. D 场景三次都拒绝硬选，给出两条路（"放弃 L2 + 自动挡买恒岳 H6" / "加钱到 17.50 万买启元 Q5"），并把代价写清。

• 现象二（ChatGPT，6 次）：

1. C 场景三次都先声明 "按原预算无完全满足车型"，再给加钱方案：run1、run2 收在陆洲 K5（26.90 万，超 1.90 万），run3 收在云途 M7（后备厢差 70 L）；第 6 轮逐条 ✅/❌，三次都是 4✅1❌，并注明 "仅在你同意放宽时才是推荐目标"；

2. run2 第 3 轮还自己补了一段成本账："K5 每跑 1 万公里比 M7 少用 100 L 油，但年保养多 300 元" —— 这是 24 次任务里唯一一次主动做保有成本权衡的；

3. D 场景三次都答 "无解"，给两条路（守 16 万就得同时放弃自动挡与 L2；不放弃配置则预算至少提到 17.50 万买 Q5），并诚实补一句 "库表未注明 Q5 挡位，只有确认是自动挡，17.50 万才够"。

• 推论："敢说没有" 在本次是两家都做到的（12/12），说明提示词第 3 条 "允许并鼓励无解" 的授权是生效的。反过来说，如果提示词里没有这一条，这类场景大概率会退化成一款硬凑的车 —— 这一点对我们做产品（第 15 节）比对模型选型更有价值。

• 但两家 "敢说没有" 的边界不同：DeepSeek 是 "算完发现没有 → 说没有"；ChatGPT 有时是 "没法确认 → 说没有"（案例三）。前者是求解结论，后者是信息不足，用户看到的却是同一句话。这也是产品侧最该防的一类混淆：**"无解" 和 "未知" 不能共用一个出口**。

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

评测暴露的核心技术问题有四类，前两类是模型的，后两类是我们自己的：

1. 结论与事实之间没有强制校验（案例一：L2 复述成 L2+；案例二：字段错记）—— DeepSeek 侧，属 "说得不准"；

2. 数据完备性判定缺失（案例三：把 null 当成 false，可行集判空）—— ChatGPT 侧，属 "答得不全"；

3. 多轮约束没有版本管理：约束散在自然语言里，谁都能改一版，B 场景三次都对，是因为每次变更都写得很明确，不是因为系统管住了它；

4. 评分器的规则过刚（案例四：表格 ≥4 行误伤了 "只列通过项" 的合理风格）—— 这一条会把表述风格差异误判成能力差异，必须先修。

方案 A：校验 — 重采样闭环（提出并推荐）

在 "模型出答案" 和 "答案交付用户" 之间插一个确定性校验器：

1. 让模型先输出结构化槽位（{"final": "云途 M7", "constraints_used": {...}, "table": [...]}），而不是自由文本；

2. 程序侧做两道校验，产出机器可读的失败原因：

• 与库内真值对撞：restate_drift: 约束原文 L2 / 复述 L2+、field_mismatch: 明澜 V6 driver_assist L2 / 回答 L2+；

• 完备性校验：constraints_used 里每条约束必须带 source: 数据 / 推定 / 未知。标了 "未知" 却据此判 "不满足"、或标了 "推定" 却没有任何替代证据（能源类型、trim 关键词）的，一律拦下（治案例三）；

1. 校验不通过时，把失败原因作为反馈拼回提示词重采样，最多 2 轮；仍不通过则降级为 "无解 / 需人工确认"，绝不放行。

备选方案 B：提示词加固（不改流程）

在 SYS_PROMPT 里加 "输出前自检清单"（车型必须在库内 / 每个数字必须来自表格 / 约束冲突时必须先声明），并给 3 组 few-shot。实现成本最低，但靠模型自觉。

备选方案 C：换更强的推理模型 / 开启联网检索

用推理模型的 "想得更久" 或多步检索来补事实。成本最高（token 与延迟都上升），且会让 "数据获取差异" 混进 "推理能力差异"，评测口径变脏。

选择理由：A 是唯一同时具备「可判定、可观测、不改变评测口径」的方案。它把 "模型靠不靠谱" 变成 "流水线靠不靠谱"，这正是软件工程该做的事 ——不指望模型永远对，而是让错的答案出不去。

验证方法（无需实际实现即可说明）：

1. 用 records/ 里 24 条记录（两组各 12 条）做离线回放：把每条记录里的 "最终回答 + 表格" 喂给校验器，统计应拦截数（预期：DeepSeek 4 处复述失真 + 1 处字段错记 = 5 条；ChatGPT 案例三 3 条 + 案例四 6 条表结构问题）；

2. 抽取 12 次真实调用做在线 A/B：A 组（校验 — 重采样）vs B 组（仅提示词加固），比较 C1 通过率、C4 编造率、平均延迟增量、平均 token 增量（延迟与 token 只有 ChatGPT 侧可测，所以这一项只能在 B 组上做）；

3. 判据：C1 通过率提升 ≥15 个百分点，且延迟增量 ≤ 1.5s 才算成立。

8 评测结论、选型建议与局限

结论（仅限本次数据、场景与设置）

局限声明（必须写清，否则结论会被误读）

1. 样本量小：每格 n = 3，标准差本身就不稳定，只能看出 "量级差异"，不做显著性检验；

2. 单一数据集：12 款车的教学模拟库，参数由我们自己定义，结构比真实市场简单得多；

3. 关闭联网：这放大了 "编造" 类错误，若开启联网结论会变；

4. 测速与计量只有一侧：ChatGPT 有逐轮计时与会话级 token，DeepSeek 侧两项全缺、且 token 口径不同（估算 vs 会话累计）。因此 C6 记 N/A，任何 "谁更快 / 谁更省" 的说法都不成立；

5. 客户端不同（本次最大的不可控变量）：A 组自建 harness 调开放平台，B 组 Codex CLI（App Server）。两边的系统提示、上下文拼装、回合切分都由各自客户端决定，与各自的网页端也不是同一产品。所以本文比的是 "两个可脚本化调用的助手"，不是 "两个网页端产品"；

6. 单一任务类型 + 非行业排名：购车决策是 "约束求解型" 任务，不能外推到写作、代码等场景。

第二部分 分析

9 程序 / 软件工程 / 商业：三个层次的对应

「程序 = 算法 + 数据结构」「软件 = 程序 + 软件工程」「软件企业 = 软件 + 商业模式」

（1）程序层面

• 算法：模型侧是多层 Transformer 的自回归推理、采样（本次用界面默认参数，未手动设 temperature）、上下文注意力；评测侧是我们自己写的算法 —— 车型库加载后建 BY_NAME/BY_ID 哈希索引（O (1) 取车）、约束判定 valid_set() 是 O (N×C) 的集合筛选、表格解析是 "按行切分 + 正则抽取 + 真值比对"、评分是规则引擎而非人工打分。

• 数据结构：车型库是 CSV → dict 列表（20 个字段带类型）；约束是一组 {field, op, value, pri} 的四元组，其中 pri 是优先级权重，用来在无解时挑 "语义上最接近" 的方案；多轮对话是 messages[] 的线性结构（这就是上下文管理的全部真相：一个会越来越长的数组）；跑批结果是 JSONL（一行一条 trace，天然可追加、可 grep）；真实评分是 real_scores.csv 的 24 行宽表（model / scenario / run / c1..c5），图 6–图 9 直接读它 —— 数据源只有一处，改了分数图就跟着变，这是 "图表可复核" 最省事的做法。

（2）软件工程层面

• 服务与文档：两家的开放平台都提供 API 网关（鉴权、限流、计量）、模型列表、SDK / 文档、控制台用量面板；deepseek-flash 侧兼容 OpenAI 的 chat/completions，ChatGPT 侧本身就是这套协议的原生实现 —— 协议兼容本身就是巨大的工程价值：换模型时改的是配置，不是代码。

• 协作机制：版本迭代（模型按版本号发布，如 V4.1 这类小版本节奏）、能力声明（是否支持工具调用 / 多模态）、免费额度与配额（获客手段也是工程约束）、社区与 issue 体系。

• 我们这套评测 harness 也是软件工程产物：配置化场景（SCENARIOS）、双 provider 切换（--provider live/mock）、失败重试与超时、错误分层（网络 / 限流 / 解析）、原始记录落盘、图表一键再生成。它解决的问题是 "让结论可复现"，而不是" 跑一次拿个分 "。

• 两组的记录方式本身就是一次对照实验：ChatGPT 侧由 CLI 自动生成 trace（模型标识、参数、逐轮耗时、token 全在头部），DeepSeek 侧靠人工模板复制 —— 结果是前者能支撑 "效率" 这一维、后者不能（C6 记 N/A）。可观测性不是加分项，它直接决定你有哪些指标可用，这是第 12 节第 6 条的现实版。

（3）商业层面

• DeepSeek：开源权重引流 + API / 私有化双轨，靠 "高性价比" 抢开发者；定价按 token，推理模型有溢价空间；

• OpenAI（ChatGPT）：订阅制（Plus / Team / Enterprise）+ API 按 token 计费 + 免费额度极小，靠品牌与生态获客，价值主张是 "接入即用" 而不是 "最便宜"。具体份额与价格数据本组未取得可靠来源，本文不引用未核实的数字；

• 共同的商业逻辑：**用免费额度把开发者拉进来，用 token 计费把用量变成收入，用 Agent / 工具调用把 "聊天" 变成 "干活"**—— 从卖 token 转向卖 "任务完成度"。

10 开发时间估计

参考《构建之法》8.6 的做法：估计必须给区间，并记录偏差原因。用三点估计（乐观 O / 最可能 M / 悲观 P，期望 = (O+4M+P)/6）。

实际投入约 60 人时（+25%），偏差主要来自四处，都是 "书上有、当时不信" 的：

1. 评分器（估 8.5h，实际～14h）：写规则容易，定 "什么算一致" 很难。第一次跑出来 DeepSeek 在无解场景被判 "一致性失败"，排查后发现是评分逻辑把 "没有完全满足的车型" 也算成 "忘记约束"——评分器的 bug 会伪装成模型的 bug，这是最危险的一类偏差。

2. 中文数字解析（估 0，实际～3h）：20 万 / 20万元 / 约 20 个 / 24.90 四种写法都要兼容，正则一改再改。

3. 图表返工（估 4.3h，实际～7h）：雷达图标签重叠、柱状图图例压住数据标签、流程图连线穿框 ——可视化的成本 80% 花在 "能不能看清" 上；第二次返工是因为第一版图用的是模拟数据，真实记录到齐后必须整体重绘。

4. 跨客户端的记录对齐（估 0，实际～4h）：两组的记录格式不一样 —— B 组由 Codex 自动生成（带 usage、逐轮耗时），A 组是人工复制（两项都空）。为了让同一套评分器读两种格式，解析层重写了一遍，还得手工补一张 "逐次评分" 表。**"同一个模板" 这件事，必须在跑批之前就落地，不能事后补。**

结论：这类 "评测型" 任务的时间主要不在调用模型，而在
把 "模糊的判断" 变成 "可执行的规则"
。

11 同类产品对比与选型排名

排名只对本次 24 次跑批（2 模型 × 4 场景 × 3 次）有效，不是行业排名：样本里没有豆包、通义、Kimi、Claude 等其他产品，所以下面只排 "我们测过的这两个"，其余产品一栏留空而不是凭印象填。

差距 5.0 分，且几乎全来自一处分歧：A 场景 90.0 对 72.0（差 18 分），其余三个场景只差 1.0–1.5 分。在 n=3 的样本量下，后三个场景的差异不构成结论（第 8 节局限第 1 条）。

选型建议（按使用需求）

• 做评测 / 做研究：选成本低的那一个。本次两组单次任务的 token 相差一个数量级（1.0 万 vs 11.7 万），同样预算能多跑几倍样本量，而样本量是评测的生命线；

• 做面向用户的购车助手：无论选谁，都必须外挂校验层。DeepSeek 的错在 "说得不准"（L2 说成 L2+），ChatGPT 的错在 "答得不全"（可行集判空）—— 对用户来说两者性质相同，都会被当成事实；

• 数据字段不全的场景（配置表、报价单、合同条款）：优先选会推定的那一个，并强制它标注 "推定依据"。反过来，如果需要的是 "凡是没写的都必须标未知"（审计、合规），选 ChatGPT 这种策略更合适 —— 这是策略选择，不是能力高下；

• 做 Agent 编排：本次两家都未接工具调用（web_search=disabled、无工具调用事件），这一项没有证据，不要凭印象下判断；

• 两者都要：用便宜的那个跑量与回归、用会标注的那个做对外话术层，校验器统一把关 —— 这是第 7 节方案 A 的自然延伸。

12 软件工程方面的建议

针对第 6 节的失败案例（不再重复描述），从工程角度给七条能落地的建议：

1. 测试覆盖：把 "无解" 和 "变更" 变成一等公民

   本次 4 个场景里 2 个是空集；两家的分差也集中在 "数据最不全的那一题"（A：90.0 对 72.0）。建议把场景做成矩阵：约束维度 × 有解/无解 × 是否变更 × 是否诱导幻觉，任何新版本上线前把这套矩阵全跑一遍（回归集）。

2. 接口适配层：隔离 "模型差异"

   统一 3 个字段（base_url /model/key）之外，还要统一错误语义：限流 (429)、超时、内容被拒、额度耗尽必须映射成同一套异常码，否则 "接口差异" 会被误读成 "模型能力差异"。

3. 上下文管理：约束要带版本号

   不要把约束散落在自然语言里。建议维护一个 constraints = {field: {value, updated_turn}} 的结构，每轮把 "最新版约束" 以结构化形式前置进提示词，并在变更时显式写 "覆盖第 N 轮的预算" —— 这能同时治案例一（复述失真）与案例三（旧约束复用）。

4. 异常处理：默认 "拒绝交付"，而不是 "降级交付"

   校验不通过时，正确做法是返回 "无法给出符合约束的车型" + 明确冲突项，而不是让模型 "再想想" 直到凑出一个答案。凑答案是这类错误最常见的成因。本次真正的教材是反过来的那一面：ChatGPT 在 A 场景把 "信息不足" 包装成了 "客观无解"（案例三）——**"未知" 和 "无解" 必须走两个出口**，否则用户无法判断该去补数据还是该改预算。

5. 解析程序：宁可报 "无法解析"，不要猜

   我们的表格解析在列数不足时会退化为 "整行抽数字"，这会让评分偏高。建议：字段缺失 → 明确记 parse_error 并按 0 分处理，同时在报告里单列 "解析失败率"。

6. 可观测性：一次任务一条 trace

   每条记录保留 ts / model / turns / latency / tokens / 命中约束 / 最终车型，这样任何结论都能回到原始证据。本次博客里所有案例都能用 model+sid+run 精确定位，靠的就是这个设计。

7. 数据契约：缺失字段要显式声明三态

   车型库 20 列里没有挡位，直接导致两组在 A 场景南辕北辙。工程上应当在数据层就声明三态：true / false / unknown，并在提示词里给出 "unknown 时允许的推定规则 + 必须标注推定依据"。不给规则，模型只能各自猜；而两种猜测都自洽，评分器也判不出谁对。

13 BUG 存在的原因分析

从测试覆盖 / 接口适配 / 上下文管理 / 异常处理四个角度的改进：

• 测试覆盖：新增 "口径歧义" 用例（同一款车给 "满员 / 放倒" 两种后备厢口径），看模型会不会混用；

• 接口适配：把 "内容被拒 / 额度耗尽" 也纳入重试策略，避免一次 429 被记成 "模型答错"；

• 上下文管理：约束结构化 + 版本号（见 12.3），变更时显式声明覆盖；

• 异常处理：解析失败与校验失败分开统计，不要让解析的锅算到模型头上。

14 市场概况

（1）市场有多大

大模型这个市场要分三层看，混在一起谈容易得出错误结论：

这三个数字不是 "同一个市场的三种说法"，而是三层不同的生意：整体市场 ≈ 算力 + 模型 + 服务；MaaS 是 "按调用付费" 的那一层；Agent 是 "按任务完成付费" 的那一层。增速最快、单价最高的是 Agent 层，这也是两家厂商都在推 "智能体中心 / 工具调用" 的原因。

（2）直接用户与潜在用户

• 直接用户（已在付费 / 调用 API）：开发者与企业算法团队。本次我们自己就是最典型的 "直接用户"—— 一个月内用完免费额度就会变成 "要不要付费" 的决策者；

• 潜在用户（尚未调用，但有明确场景）：垂直行业开发者（汽车、金融、政务、教育）、做产品的独立开发者、以及把模型嵌进自家软件的中小团队。像 "购车决策" 这类任务，真正的付费方大概率是汽车垂媒、经销商 SaaS、保险 / 金融比价平台，而不是个人消费者；

• C 端用户：量大但付费意愿低，主要通过免费额度→订阅转化。本次采访的同学就是这一类：愿意用，但一旦出现一次编造就不再信任。

（3）一个来自本次评测的判断

市场在快速增长，但 "能答" 和 "敢用" 之间还有明显差距。本次 24 次可核对的真实任务里，两组都做到了 0 次编造车型、0 次违反硬约束（这比多数人的预期要好），但各自都有 "看起来仍然自洽" 的问题：

• DeepSeek 侧 5 处：4 处把 L2 复述成 L2+、1 处字段错记 —— 属 "说得不准"；

• ChatGPT 侧 1 处结论级 + 6 处表述级：把可行集判空、该给表只给一句话 —— 属 "答得不全"。

两类错误都不会亮红灯。这意味着在 "决策类" 场景里，校验与可观测能力（而不是模型排名）才是真正的工程壁垒，而 "谁更准" 这个问题，往往取决于 "数据不全时你希望它怎么办"。

15 产品规划：如果我是新上任的项目经理

NABCD 分析（面向 "购车决策" 这个垂直切口）

功能优先级（《构建之法》第 8 章的四象限）

为什么做这个、不做那个

• 为什么不做 "AI 帮你砍价话术"？因为它不可验证（我们无法判断话术好坏），而 "约束是否满足" 可以机械判定 ——能判定的事才值得先做；

• 为什么先做无解识别？因为本次两个空集场景（共 12 次运行）恰好把三件事分开考了出来 —— "敢不敢说没有"、"能不能把约束原样复述"、"能不能把「不知道」和「没有」分开"；最后一条正是 ChatGPT 掉分的地方，也是竞品普遍回避的地方（" 说没有 " 不讨喜，但对用户是刚需）；

• 为什么把校验层放在模型前面？因为模型的进步不可控，工程的正确性可控。产品经理能管的是后者。

创新点

1. "无解" 与 "未知" 各走一个出口：把 "找不到完全满足的车型"（附带冲突项排序与取舍建议）与 "数据不足以下判断"（附带核实动作）设计成两种正常输出，而不是失败状态或一句笼统的 "没有"；

2. 多模型分工：用便宜快的模型跑量与回归，用会解释的模型做面向用户的话术层，校验器统一把关 —— 这就是本文第 7 节方案 A 的产品化；

3. 评测即产品：把本文这套 6 维指标做成上线门禁（CI 里跑 24 次任务，C4 不为满分就不许发版）。

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

（1）它确实在改变 "获取结论" 的成本

过去买车要逛论坛、看测评、做 Excel；现在一句话就能拿到一份结构化的候选清单。这种 "从检索到结论"的跃迁，本质上是把一部分" 分析劳动 "外包给了模型。对普通人最大的好处不是" 更聪明 "，而是门槛降低：不会做对比表的人，也能拿到一份像样的对比表。

（2）但它改变不了 "谁该负责"

本次评测最有说服力的一条经验是：两家的 "出错点" 不一样，但都在最需要答案的地方出错。空集 / 冲突题（C、D）反而没人硬凑（12 次全部正确说没有）；真正翻车的是 "有解但数据不全" 的题 —— ChatGPT 把 2 款可行的车判成 0 款（案例三），而现实生活中的决策恰恰大多是这种样子：预算不够、条件互斥、信息不全。所以：

• 模型可以承担 "整理、对比、解释"，**不能承担 "替你决定"**；

• 越是 "看起来完整" 的回答（表格齐全、理由充分），越需要有人核对来源（案例一、案例二都是这个陷阱）；

• 反过来，**"看起来严谨的空答案" 同样危险**：一句 "库表未注明，无法确认"，用户会当成 "客观上没有"（案例三）；

（3）对能力结构的影响

被替代的是 "信息搬运与格式整理"（做表格、找参数、写套话）；被放大的是 "提问的质量"" 约束的定义 ""结果的校验"。我们这次写评测脚本的体会很直接：真正难的不是调用模型，而是把 "什么算对" 写成规则。未来更稀缺的能力，是 "能把模糊需求翻译成可判定标准" 的人。

（4）风险

• 幻觉与错记：本次 24 次任务里 0 次编造车型，但出现 DeepSeek 5 处复述失真 / 字段错记、ChatGPT 1 处可行集判空；这类错误都不带 "错" 的样子，反而更难被用户发现；

• 依赖与技能退化：用户可能失去 "自己判断参数含义" 的意愿；

• 成本与公平：好模型要钱，会形成 "谁的预算高，谁的答案更准" 的分层；

• 隐私：购车决策会暴露收入、家庭结构、通勤路线，这类对话数据的敏感度被普遍低估。

（5）我的总体看法

大模型是 **"降低门槛的工具"，不是 "替代判断的大脑"**。它在 "事实整理" 上已经够用，在 "冲突决策" 上还需要工程化的护栏。作为软件工程的学生，我更愿意把它当成一个 能力很强但需要校验的组件 —— 就像我们不会因为有了编译器就不写测试。

附录

A 六人分工与时间线

协作约定（避免返工的三条）

1. 评分口径先冻结：队长在 11-06 晚定稿 car_eval.py 的评分规则，两组不得各自改规则 —— 否则结果不可比；

2. 原始记录只能追加不能改：records/ 下每份 md 与 results/runs.jsonl 都只追加、不覆盖，出错就重跑一份新的（这是可审计的前提）；

3. 失败案例必须留证据：任何 "模型答错了" 的结论，都要给出 model + sid + run 定位，不许只写 "感觉它不太行"。

时间线（留出博客审核期）

B 代码仓库与实验材料

car-eval/
├─ car_eval.py                 # 主脚本：场景配置 + 多轮驱动 + 评分 + 可视化（约 800 行）
├─ make_figs.py                # 用真实评分重绘图 6–图 9（读 results/real_scores.csv）
├─ data/cars_2026.csv          # 12 款教学模拟车型库（含口径与单位）
├─ records/                    # 24 份原始记录（两组各 12 份，逐轮回答原样保存）
│  ├─ DeepSeek-{A,B,C,D}-run{1,2,3}.md
│  └─ ChatGPT-{A,B,C,D}-run{1,2,3}.md   # Codex 自动生成，含逐轮耗时与 token
├─ results/
│  ├─ runs.jsonl               # 管线自检记录索引（mock 数据）
│  ├─ real_scores.csv          # 24 次真实任务的逐次评分（本文表 1 的数据源）
│  ├─ summary.csv              # 汇总表（可导入 Excel 复核）
│  └─ summary.md               # 自检产出的汇总表
└─ figures/                    # 流程图、雷达图、柱状图、波动图、成本图

• 仓库链接：https://codehub.devcloud.cn-north-4.huaweicloud.com/1cc4d1420a3d44a88e53cc3c2084e46f/222.git

• 关键代码在正文已给出（约束判定、可行集、表格核对、多轮驱动），其余见仓库；