这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践——大模型评测作业
这个作业的目标	设计购车决策多轮测试场景，通过自动化脚本比较智谱 GLM-4-Flash 与 DeepSeek 的约束遵循、多轮一致性、指令遵循、稳定性及成本延迟；结合网页端体验、用户采访和失败案例分析模型能力边界，并从程序、软件工程和商业模式三个层面提出改进方案与选型建议。
其他参考文献	邹欣.《构建之法：现代软件工程》相关章节；智谱 BigModel 开放平台官方文档；DeepSeek API 官方文档；市场数据及其详细来源见附录 A。

大模型购车决策评测：两个平台的体验、自动化测试与软件工程分析

一句话结论：常规场景（约束一次说清）两个模型无差异，差距全部出现在"需求会变、目标会冲突"的场景。 DeepSeek-R1 综合 95.80、GLM-4-Flash 综合 51.66，但我们最终的建议不是"换更贵的模型"，而是"给任何模型都加一层可判定的约束校验"。

目录

---

作业基本信息

项目	内容
课程名称	软件工程
作业名称	大模型评测 · 购车决策任务（案例分析作业）
班级 / 团队	zq践地组
被测产品 1	智谱 BigModel 开放平台（GLM-4-Flash，通用对话模型）
被测产品 2	DeepSeek 开放平台（deepseek-reasoner，按仓库配置名简称 DeepSeek-R1，推理模型）
测试时间	2026-11-08 23:54 — 2026-11-09 00:21（UTC+8）
测试规模	2 模型 × 3 场景 × 3 次重复 = 18 次多轮任务（5–6 轮/次）
代码仓库	点击跳转仓库

团队分工

成员	负责内容	对应本文位置
陈时文	环境与测试框架、18 次调用执行	1.2 / 2.2 自动化测试设置
陈子涵	车型库、三场景脚本、评分规则	1.2 自动化测试设置
兰秀楠	自动评分与可视化（雷达图、柱状图）	1.3 / 1.6 结论与图表
甘羽潇	两平台网页端体验、用户采访	1.1 / 1.4 体验
梁鑫敏	第一部分撰写、案例与改进方案、统稿发布	第一部分全部
张祺	第二部分分析（三层分析 / 市场 / NABCD）	第二部分全部

---

第一部分 调研、评测

一、大模型 1：智谱 GLM-4-Flash（通用对话模型）

1.1 体验

1.1.1 介绍与使用过程

智谱 BigModel 开放平台提供 GLM 全系列模型的 API 与网页端对话入口。本次体验覆盖三件事：注册与领额度、网页端对话（模型选择）、把购车任务问一遍。

从注册到能用的实际耗时：约 3 分钟（观察到的事实）。免费额度写在注册页 / 活动页，原文为"新用户可获得 20.00 million Tokens（约 2000 万 Tokens）的专享体验包"——这是平台公开宣传的体验额度，不是本账号可核销的确定余额。

1.1.2 优缺点分析

维度	优点	缺点	依据（观察 / 推测）
功能	模型广场共 24 个模型，可按 GLM-5 / 4.7 / 4.6 / 4.5 等系列筛选并指定具体版本	页面同时堆了 API、Coding Plan、智能体、API Key、开发文档等入口	观察：模型列表可打开并选中 GLM-4-Flash；推测：入口过多会增加初次使用者理解平台结构的负担
界面	模型选择入口在对话页上方，位置明显，受访者较快找到	—	观察：受访者在 20 分钟内完成三个购车问题
数据 / 准确度	常规场景（约束一次说清）输出与推理模型无差距且 token 少 44%	中途改需求时会虚构库外配置（见案例一）、预算数值判断自相矛盾（见案例二）	观察：results/models.csv；scores.csv 第 14-16 行（s2 三次）与第 17-19 行（s3 三次）
功能完整性	—	没有导出 / 分享功能	观察：两平台对比时智谱侧无导出入口（DeepSeek 有）
成本	GLM-4-Flash 定价 0 元，128K 上下文	免费额度只在注册 / 活动页宣传，控制台内未看到本账号余额的可核销口径	观察 + 推测（后者为推测）
报错体验	—	本次体验未出现报错，无法评价	观察

1.1.3 用户改进意见

受访者建议智谱 BigModel 对功能入口进行分类，将普通对话功能与 API、智能体等开发者功能分开，并增加新手引导，以减少首次使用时的选择压力。同时，受访者认为 API Key、API 定价、财务等多个入口需要进一步说明用途，降低用户判断成本。

1.1.4 采访另一个用户

受访者：2024 级软件工程专业，日常主要使用大模型解决学习问题。采访日期为 2026 年 11 月 10 日，试用时长约 20 分钟。受访者使用相同的三个购车问题体验智谱 BigModel 和 DeepSeek，任务包括初步车型推荐、参数对比和需求变更。

观察到的事实

• 受访者在两个平台均完成了初步车型推荐、车型参数对比和需求变更三个任务。
• 在智谱 BigModel 中，受访者很快找到对话框上方的模型选择入口，查看了 GLM 系列模型，操作没有明显困难；同时打开过模型设置页面，页面提供 max_tokens、temperature、top_p 等参数。
• 智谱 BigModel 页面左侧同时展示 API 平台、Coding Plan、Managed Agents、体验中心、API Key、开发文档等多个入口。面对多个入口时，受访者出现短暂停顿，需要判断当前任务应从哪个入口进入。
• 在 DeepSeek 中，受访者打开网页端后可直接进入对话并输入问题，完成了三个购车任务，也成功切换并使用了“深度思考”模式。
• 受访者在 DeepSeek 网页端查找免费额度、剩余 Token 或 API 价格时停顿较久，反复观察页面，但未看到明显的额度和价格入口。
• 受访者认为 DeepSeek 网页端进入对话更直接；智谱 BigModel 的模型选择入口比较明显，但功能入口较多，需要先判断不同入口的用途。

我的推测

• 智谱侧模型切换门槛较低，但普通对话与开发者功能混在同一导航层级中，可能增加首次使用者理解平台结构的负担。
• DeepSeek 侧对话路径短、上手较快，但网页端没有明显的额度与价格入口，用户可能难以判断使用限制。

能否独立上手及主要困难：受访者能够独立完成两个平台的三个任务，没有出现无法继续操作的情况。最主要的困难集中在信息入口识别：智谱 BigModel 是功能入口较多、需要判断用途；DeepSeek 是网页端缺少明显的额度和价格信息入口。

1.2 自动化测试

1.2.1 被测模型与环境

项目	值	来源
精确模型标识	glm-4-flash（原定通义千问因账号欠费不可用，临时替换为智谱 GLM-4-Flash）	models.json 的 model 字段
接口地址	https://open.bigmodel.cn/api/paas/v4	providers.py
关键参数	temperature=0.3、max_tokens=1600	models.json
测试起止时间	2026-11-08 23:54:20 → 2026-11-09 00:21:16（首条 deepseek s1 r1 23:54:20，末条 glm s3 r3 00:21:16）。两模型之间有明显空档：DeepSeek 最后一条 00:01:36，GLM 第一条 00:11:38，约 10 分钟；meta.json 的 test_date 取的是较早批次 2026-11-08T23:54:20（runner.py L163-L177）	runs/*/*/r*.json 的 timestamp、runs/meta.json
实际执行次数	18 次（runs/all.jsonl 共 18 行，无重跑）	runs/all.jsonl 行数
运行环境	仓库未声明 Python 版本：无 pyproject.toml、无 setup.py、无 python_requires（实测均 NOT_FOUND）。依赖只有 requirements.txt 两行——openai>=1.40、matplotlib>=3.8；visualize.py L39、L74 里有 import numpy as np，但 requirements.txt 未声明 numpy，靠 matplotlib 传递依赖带入。README 的复现指引也只有两条（L12-L16：pip install -r requirements.txt、cp .env.example .env）。所以这一格照实写「仓库未声明 Python 版本」，不猜 3.x	requirements.txt L1-L2、README.md L12-L16、visualize.py L39/L74

1.2.2 测试数据集与免责声明

车型库 data/cars.json：12 款车 × 16 字段（实测键数 16，cars.json L18-L35：id、brand、name、year、trim、price_wan、body、seats、powertrain、ev_range_km、fuel_l_per_100km、power_kw、cylinders、adas_l2、airbags、aliases），价格单位为万元（厂商指导价）。来源口径为「公开车型参数资料人工整理（品牌官网与主流汽车媒体），未逐条留存原始链接」（cars.json L4），整理日期 source_date: 2026-11-08（L7）。没有可给出的来源 URL——这是数据集自身的声明，不是我们漏标，博客里照实写。

数据集免责声明（原文照抄，data/cars.json L5）：本数据集为教学模拟数据，价格与参数按公开资料合理估算后统一口径填写，不代表任何真实市场报价，不得作为购车依据。

1.2.3 三个测试场景（约束全部可判定）

场景	场景名（轮数）	约束条目（结构化）	预期合格车型 ID
s1	城市通勤 · 预算敏感型（5 轮）	price_max=20、adas_l2=true、cylinders_not=[3]、body_in=[轿车, SUV]（价格单位：万元，厂商指导价）	qin_plus_dmi、qin_plus_ev、corolla、songplus_dmi
s2	二胎家庭 · 中途收紧预算并限定纯电（6 轮）	阶段 1（1–3 轮）：price_max=35、seats_min=6、powertrain_in=[纯电, 插电混动, 增程]；阶段 2（4–6 轮）：price_max=28、seats_min=6、powertrain_in=[纯电]	tang_ev、id6
s3	长途自驾 · 北方冬季用车（5 轮）	price_max=25、body_in=[SUV]、adas_l2=true、any_of[ev_range_min=500, powertrain_in=[插电混动]]	g6、songplus_dmi

s2 第 4 轮的需求变更原文：

重新想了一下，预算必须压到28万以内，而且我只考虑纯电，不接受增程和插混。请按这个新要求重新筛一遍，并告诉我哪些原来合适的车被排除了。（scenarios/s2_family.json L58，原文照抄）

改动后约束：price_max=28、seats_min=6、powertrain_in=[纯电]（改动前为 price_max=35、powertrain_in=[纯电, 插电混动, 增程]）。合格项数由 3 → 2：变更前合法的是理想 L8、唐EV、ID.6，变更后仅剩唐EV 与 ID.6，理想 L8 因超预算且为增程被排除，汉兰达因油电混动始终不合法（scenarios/s2_family.json L25）。模型侧对这条最明确的复述来自 DeepSeek：「理想 L8 2025 Pro：指导价 32.18 万元，超过 28 万元预算；且动力形式为增程，不符合「只考虑纯电」的新要求，双重排除」（runs/deepseek/s2/r1.json L50）。

1.2.4 评分规则（合计 100，已与 weights.json 核对）

指标	权重	判定标准（无"酌情"）	计算方式	样本数
约束遵循	30	最终推荐车型满足该场景最终阶段全部硬约束记 1，否则 0；查车型库判定，不看模型自述	1/0 判定后按组求均值；只读"最终推荐："行，缺该行无法判定记 0	n=3/场景，9/模型
多轮一致性	15	最终推荐车型在前期轮次出现过=1；未出现但合法=0.7；不合法=0	按组求均值	n=3/场景
指令遵循（格式）	15	表格轮 0.2（有表）+0.4（行数达标）+0.4（表头命中率）；最终轮 0.6（有格式行）+0.2（库内车型）+0.2（长度≥60 字）	两轮得分取平均	n=3/场景
防幻觉	15	1 − min(0.5, 0.15 × 库外品牌数)；全程未识别到任何库内车型记 0	按组求均值	n=3/场景
稳定性	15	组内通过率 ×(1 − 组内得分标准差/50)	按组求均值	n=3/场景
成本与延迟	10	0.6×(1 − 归一化延迟) + 0.4×(1 − 归一化 token)	延迟与 token 组间 min-max 归一化	n=3/场景

1.2.5 执行情况与两个比率

项目	GLM-4-Flash	DeepSeek	口径
status=ok / status=error 条数	9 / 0	9 / 0（合计 18 条全部 ok，run_id 18 个全部唯一，无重复记录）	runs/all.jsonl 共 18 行、status: ok 出现 18 次。需说明：runs 目录是在提交 3c47055 一次性加入的，该提交信息写明「接入智谱 GLM-4-Flash 替换不可用的通义千问」，即 GLM 侧发生过换模型重跑，但不是同一模型重复跑；--force 覆盖重跑开关（runner.py L143）从现有记录看不出被使用过
失败记录明细	无失败：error 字段全为 null	—	runs/all.jsonl
表格解析成功率	9/9	9/9	能被 parse.py 解析出 Markdown 表格的运行数 / 该模型总运行数。18 次 notes 均含「表格轮：表格N行，表头命中x/y」，用仓库自带的 parse.parse_markdown_tables 重算行数与列命中率，18 次全部与 notes 一致
幻觉出现次数（白名单外品牌）	notes 标记 2 次（第 17、19 行，均为「现代」）——实测为误报：原文是「现代汽车普遍采用模块化设计」「现代电动汽车的充电技术发展迅速」（runs/glm/s3/r1.json、r3.json L50），是普通名词被 parse.py L78-L81 的 brand in text 命中 brands.json L8 的「现代」	0 次	brands.json 白名单子串匹配；扣分链路真实（每次 0.15，两次各记 grounding 0.85），但判定不成立
违反新约束次数	s2：车型层 1 次违规（r1 推 5 座 Model Y），r2/r3 车型合规但缺格式行；s3：车型层 3 次全违规（两次唐EV 26.98 万、一次 Model Y 26.35 万）	0 次	scores.csv 里只记录到 1 行「违反约束」（第 18 行 s3 r2），因为 s2 的 r1 缺格式行、final_car 为空，违规没被结构化记录。所以「1/3」只是机器读到的数，车型层真相要逐份读 run JSON
3 次重复的极差（组内 run_score 最高−最低）	11（s3：40 − 29）；s2 为 0（32/32/32）	0（三场景均 100）	scores.csv 第 17-19 行（GLM s3）与第 8-10 行（DeepSeek s3）
单次平均耗时	12.6 s（avg_latency_ms 12,587.5）	9.3 s（avg_latency_ms 9,311.7）	results/models.csv 的 avg_latency_ms（n=9/模型）
最长耗时（两种口径，别混称）	单次运行平均延迟的最大值 16.0 s（glm s1 r1）；单轮最长 24.1 s（glm s1 r1 第 4 轮）	单次运行平均延迟的最大值 12.2 s（deepseek s1 r3）；单轮最长 25.3 s（deepseek s1 r3 第 2 轮）	前者取 scores.csv 的 latency_ms 最大值，后者逐轮读 runs/*/*/r*.json。按单轮口径 GLM 反而更快，这一项必须写清用了哪把尺子
首 token 延迟	未记录	未记录	确实没采集：providers.py L15-L19 的 ChatResult 只有 latency_ms、prompt_tokens、completion_tokens 三个字段，没有首 token 计时。不能用平均延迟顶替这一项
单任务平均 token	9,675.444（9 次合计 87,079）	17,209.667（9 次合计 154,887）	models.csv 的 avg_tokens。口径：每轮 prompt_tokens + completion_tokens 全程累加（rubric.py L153-L155、runner.py L103-L104），多轮会重复计入上下文，不是去重后的 token

接口层现象：本次 18 次调用未出现限流、超时、内容审核拦截，因此两家平台的 429 / 5xx 与错误码语义差异只能通过文档与自述推断，本次不做实测结论（详见 2.1.2 软件工程层，其中"200 但正文为空"是我们自己踩到并已用代码兜住的）。

1.3 结论（大模型 1）

六维得分（GLM-4-Flash，均取自 results/models.csv）

维度	GLM-4-Flash	DeepSeek	差值	证据	一句话解释
约束遵循	0.333	1.000	−0.667	models.csv 的 constraint_compliance；groups.csv L5-L7（GLM 三组 1.0 / 0.0 / 0.0）；scores.csv 第 11-19 行 notes	组均值口径：(1.0+0.0+0.0)/3 = 0.333，因每组 n=3，数值上等于 3/9。不等于「一台合规车都没选出来」——车型层实际 5 次合规、4 次违规，只因 5 次没写「最终推荐：」行、机器只读到 4 次（其中 3 次合规）。详见 1.3 结论第 2 点
多轮一致性	0.333	1.000	−0.667	models.csv 的 consistency；groups.csv L5-L7 同为 1.0/0.0/0.0；runs/glm/s2/r1.json L72 末轮	改需求后不复述新约束、也不修正旧结论；s2 r1 甚至把前期已出现的合规候选（唐EV）反过来判成超标。规则是「最终推荐在前期轮次出现过记 1，未出现但合法记 0.7，不合法记 0」（weights.json L14）
指令遵循（格式）	0.778	1.000	−0.222	models.csv 的 instruction_following；格式行 GLM 4/9、DeepSeek 9/9（缺的是 s2 的 r1/r2/r3 与 s3 的 r1/r3）	表格都写对了（双方 9/9 解析成功，列命中率 18 次全部与 parse.py 重算一致），差在最后一行结论的固定格式。规则里表格轮 = 0.2 有表 + 0.4 行数 + 0.4 列命中，最终轮 = 0.6 有格式行 + 0.2 识别到库内车型 + 0.2 长度 ≥60 字，两者取平均（weights.json L15）
防幻觉	0.967	1.000	−0.033	models.csv 的 grounding；scores.csv 第 17、19 行 notes：「待核验品牌：现代」	这 0.033 来自检测器误报：原文是「现代汽车」「现代电动汽车」两个普通名词（runs/glm/s3/r1.json、r3.json L50），被 parse.py L78-L81 的 brand in text 子串匹配命中品牌词。反过来，真正该扣的「可选装 6 座」这类库外字段当前规则完全扣不到——同一套规则一边误伤、一边漏判
稳定性	0.333	1.000	−0.667	models.csv 的 stability；groups.csv 的 run_score_mean：s2 三次 32/32/32、s3 三次 29/40/29	公式是「组内通过率 × (1 − 组内加权得分标准差 / 50)」（weights.json L16）：GLM 的组内极差其实不大（s2 为 0、s3 为 11），0.333 几乎全部来自通过率为 0——缺格式行就整组判失败，所以这一项测的是「有没有按要求交付」，不是「稳不稳定」
成本与延迟	0.55	0.58	−0.03	models.csv 的 cost_latency；单任务 avg_tokens 9,675.444 vs 17,209.667；avg_latency_ms 12,587.5 vs 9,311.7	GLM 的 token 少 44%，但比 DeepSeek 慢 35%，按「延迟 0.6 + token 0.4」复合后为 0.55，低于 DeepSeek 的 0.58。分场景看，GLM 只在 s2 的成本延迟得分更高（0.791 vs 0.600），s1 与 s3 更低（0.382/0.477 vs 0.383/0.758）。因此它的优势是省 token 和零现金成本，不是综合成本延迟更优

分场景得分（两套口径并列，取自 results/groups.csv）

模型	s1 单次分	s2 单次分	s3 单次分	s1 综合分	s2 综合分	s3 综合分	模型综合分	排名
GLM-4-Flash	100.0	32.0	32.667	93.82	31.91	29.26	51.663	2
DeepSeek-R1	100.0	100.0	100.0	93.83	96.00	97.58	95.803	1

口径提示（这一列一列都对不上号，是本报告最容易出错的地方）

• 单次分＝groups.csv 的 run_score_mean，只由 4 个运行级维度换算（约束 30 + 一致 15 + 指令 15 + 真实 15 = 75，再除以 0.75 归到 100；rubric.py L158-L161），不含稳定性与成本延迟。
• 综合分＝groups.csv 的 composite，六维齐全（rubric.py L215-L224），所以 s1 明明单次分都是 100，综合分却是 93.83 / 93.82——差额全部来自成本与延迟这一项（两者在 6 个组之间做 min-max 归一化，s1 两组分别只拿到 0.383 / 0.382）。
• 模型综合分＝三个综合分的算术平均（rubric.py L244）：GLM (93.82+31.91+29.26)/3 = 51.663，DeepSeek (93.83+96.00+97.58)/3 = 95.803。拿三个单次分直接平均会得到 54.889 和 100，跟 51.66 / 95.80 对不上，这是最常见的错法。
• 93.83 对 93.82 是 DeepSeek 与 GLM 在同一场景的对比（差 0.01，属噪声区间），不是同一个模型的两种口径。
• 两套分数不可混用、不可相加；本文其余处引用时都会注明取自哪一列。

出图脚本实测：图标题原文「各评测维度对比（单位：0–1 分，1.0 = 该维度满分；每组 n=3 次，3 场景平均）」（visualize.py L59-L63），中文字体回退链为 Microsoft YaHei / SimHei / Noto Sans CJK SC（L31-L35），实测无乱码、无缺单位。
图 1 GLM-4-Flash 与 DeepSeek-R1 六维雷达图（数据源 results/models.csv；单位：归一化得分 0–1（成本与延迟维度折算为百分制）；n=3/场景，9 次/模型；"图 1 / 图 2"的编号为本博客自定（仓库无此约定：README.md L53、rubric.py L299、visualize.py L1 均只写"雷达图与柱状图"，全文编号已保持一致））

结论（大模型 1）

1. GLM-4-Flash 在 s1 常规场景拿到 100.0，与推理模型完全打平——约束一次说清时，它不需要「想」就能答对，且 token 少 44%；按智谱公开定价该模型输入输出均为 0 元（附录 A·S10，仓库内不记录金额），本次 9 次运行的现金成本为 0。
2. 它在 s2 / s3 崩了（单次运行分 32.0 / 32.7）。必须澄清一点：GLM 的硬约束符合度 0.333 不等于「一台合规车都没选出来」。 这个 0.333 是 rubric.py L236 的组均值口径：三个场景组的 compliance 为 1.0 / 0.0 / 0.0，(1.0+0.0+0.0)/3 = 0.333；因每组 n_runs=3，数值上等于 3/9（仓库里没有任何地方把这一列写成「3/9」，这句话是按公式推出来的）。它的真实构成要分三层看：格式层——9 次里 5 次没按约定输出「最终推荐：」行（s2 的 r1/r2/r3、s3 的 r1/r3）；车型层——按模型实际推荐的车型判约束，5 次合规、4 次违规；机器可读层——解析器只读到 4 次（s1 三次 + s3 的 r2），其中 3 次合规。这是格式层扣分与车型层错误叠加的结果，两层必须分开陈述。关键证据是 runs/glm/s2/r2.json、r3.json 的最后一轮（L72）：那两次推荐的是 7 座、26.98 万的唐EV，在「28 万以内、≥6 座、纯电」三条硬约束下本身合规（scenarios/s2_family.json L18-L20、data/cars.json L186-L189），失分纯粹来自没写格式行；同场景 r1 推荐的才是 5 座 Model Y，那一次才是车型层违规。
3. 它那 0.033 的防幻觉差距来自 notes 里 2 次「待核验品牌：现代」（scores.csv 第 17、19 行），回原文核对后确认是检测器误报——原话是「现代汽车普遍采用模块化设计」「现代电动汽车的充电技术发展迅速」，「现代」是普通名词，被 parse.py L78-L81 的子串匹配命中品牌词。也就是说这一项分数是规则真算出来的，但它扣的不是真幻觉；而真正严重的「编造库外配置」（案例一的「可选装 6 座」）当前规则一点都扣不到——这是我们评分体系的漏洞，不是 GLM 的功劳。

二、大模型 2：DeepSeek-R1（推理模型）

1.4 体验

1.4.1 介绍与使用过程

DeepSeek 开放平台以网页端对话 + API 两种形态提供，网页端提供"普通对话 / 深度思考"模式切换。本次体验中该账号此前已注册，因此未重复计时注册耗时（观察到的事实）。

1.4.2 优缺点分析

维度	优点	缺点	依据（观察 / 推测）
功能	有导出 / 分享功能（智谱侧没有）	不能由用户直接指定具体模型版本，只有模式切换	观察：网页端未见独立模型选择下拉菜单
界面	对话入口直接，可快速开始提问	额度 / 价格信息不在对话页可见	观察：受访者寻找额度入口时停顿较久；推测：用户难以判断使用限制与成本
准确度	三场景 9 次全部合规（约束遵循 1.000、防幻觉 1.000、格式 9/9）	—	results/models.csv
数据量 / 成本	DeepSeek 9 次任务总 token 154,887，按最贵输出价估算上限 0.31 元（金额按外部定价页估算，附录 A·S11；仓库内无金额字段）	单任务 token 17,210，比 GLM 多 77.9%（思考 token 计入输出）	观察：models.csv；推测：价格页换算（查询 2026-11-08）
延迟	平均 9.3 s，比 GLM 更快；单次运行平均延迟的最大值 12.2 s，单轮最长 25.3 s	观察：models.csv 的 avg_latency_ms、run JSON 逐轮 latency_ms
报错体验	—	本次未出现报错，无法评价	观察
接口契约	—	按外部文档，deepseek-chat / deepseek-reasoner 自 2026-07-24 起改为指向 deepseek-v4-flash 的非思考 / 思考模式；兼容期未关闭，本次 9 次调用全部成功	外部文档：DeepSeek API 文档「模型 & 价格」，查询 2026-11-08；调用记录：runs/all.jsonl

1.4.3 用户改进意见

受访者建议 DeepSeek 在网页端增加明显的额度和价格说明入口，清楚展示免费额度、剩余额度以及可能产生费用的位置，让用户在使用对话功能时能够直接确认成本信息。

1.4.4 采访用户（同一受访者，两平台对照）

受访者使用 DeepSeek 时能完成初步车型推荐、参数对比与需求变更，也主动尝试了"深度思考"模式；在寻找额度 / 价格信息时停顿较久，最终未在当前对话页面找到入口（观察到的事实）。与智谱侧的差异主要集中在两点：模型选择方式（智谱可查看多个 GLM 系列模型，DeepSeek 主要提供普通对话 / 深度思考模式）与成本信息可见性（智谱可看到 API 定价等入口，DeepSeek 网页端未发现明显入口）。

受访者对两平台差异的评价是：“DeepSeek 网页端进入对话更直接，打开后即可输入问题。智谱 BigModel 的模型选择入口也比较明显，但页面功能入口较多，需要先判断不同入口的用途。”采访记录中没有形成单一平台的最终偏好，因此不对此作额外推断。

1.5 自动化测试

测试矩阵、数据集、三场景约束与评分规则与 1.2 完全一致（同一套脚本、同一份 cars.json、同一份 weights.json），此处只列 DeepSeek 侧的差异项：

项目	值	来源
精确模型标识	deepseek-reasoner（思考模式）。① models.csv 的展示名是「DeepSeek · DeepSeek-R1（deepseek-reasoner）」，实际请求串只有 deepseek-reasoner；② 按外部文档，该标识自 2026-07-24 起是指向 deepseek-v4-flash 思考模式的别名，兼容期未关闭；本次 9 次运行全部 status=ok	models.json L18 + models.csv L2 + DeepSeek API 文档（查询 2026-11-08）+ runs/all.jsonl
接口地址	https://api.deepseek.com/v1	providers.py
关键参数	不设 temperature、max_tokens=6000（沿用通用模型的 1600 会被思考链吃光，finish_reason=length 导致正文为空，故上调并加"空正文按失败重试"）	models.json、providers.py
执行结果	18 条中本模型 9 条全部 status=ok，error=0，无重跑	runs/all.jsonl
解析成功率 / 格式行	9/9 解析成功，9/9 输出"最终推荐："行	scores.csv
幻觉次数	0 次（9 行 notes 中无「待核验品牌」标记）	brands.json 白名单核验
平均 / 最长耗时	9.3 s / 12.2 s（12.2 s 是「单次运行平均延迟」的最大值，即 deepseek s1 r3；单轮最长是 25.3 s，出现在 deepseek s1 r3 的第 2 轮）	models.csv 的 avg_latency_ms、scores.csv 与 run JSON 的 latency_ms
单任务平均 token	17,210（9 次合计 154,887）	models.csv 的 avg_tokens

1.6 结论（大模型 2）

图 2 两模型在 s1/s2/s3 的得分对比（分组柱状图）（数据源 results/models.csv；单位：分（0–100，单次运行分 run_score）；每柱 n=1，每组 n=3/模型；标题、轴标签与单位由 visualize.py L83-L86、L114-L115 写入，实测齐全）

1. DeepSeek-R1 三场景全部 100.0，综合 95.80，六个维度无一项低于 GLM，没有任何维度被反超。它的优势不是"更会推荐车"，而是需求变更时还守得住约束：s2 中途把预算压到 28 万并限定纯电，它三次都改了结论并按格式交代。
2. 代价是 token：单任务 17,210，比 GLM 多 77.9%（思考 token 计入输出）。但延迟反而更低（9.3 s vs 12.6 s）——我们为"想得更久"付的是 token 钱，不是时间钱。
3. 按官网单价粗估，9 次任务现金成本上限 0.31 元（GLM 侧 0 元）。口径要说清：金额是我们按外部定价页算的（附录 A·S10/S11），不是仓库字段——results/*.csv 里没有任何金额列，cost_latency 是 0~1 的归一化得分（weights.json L18），跟钱无关。即便如此，量级结论成立：这次评测里「贵」是几毛钱，而「错一次」是几千到几万元（差一个座位数、差一个配置）。这两笔账一比，选型结论就很清楚了（见 2.3）。
4. 一个必须记住的坑：按官方文档，deepseek-reasoner 自 2026-07-24 起已改为指向 deepseek-v4-flash 思考模式的别名，兼容期未关闭（附录 A·S11，查询日期 2026-11-08）。本次 18 次调用全部 status=ok，说明运行时段该字符串仍可用；但脚本里写死的 model 字符串不会自己报告它背后的实体已经变化，等到调用失败时，调用方也容易误判为「模型变笨了」。所以我们把 actual_model 与 provider_base_url 一起写进每条 runs/*.json。

三、两个失败 / 边界案例

挑选口径：从 results/scores.csv 的 notes 判罚出发，逐个回原始记录核对；第二部分的 2.4 基于同一批记录位置展开，不另挑一套案例。

案例一：改需求后"发明"了一个配置（s2）

项目	内容
表现	第 4 轮把条件改成"28 万以内、≥6 座、纯电"后，GLM 第 1 次运行推荐 5 座的特斯拉 Model Y（26.35 万），并写"虽然 Model Y 标准配置是 5 座，但可以通过选装第二排座椅来升级为 6 座"；同一次还把 7 座唐EV 判为"座位数为 7 座，超出用户要求的 6 座以上"
记录位置	runs/glm/s2/r1.json 最后一轮（L72）；results/scores.csv 第 14 行 glm__s2__r1，notes =「缺少‘最终推荐：’行」（同场景第 2、3 次为第 15、16 行，notes 同样含缺行标记）
可能原因	模型层（把硬约束当成可商量的偏好，并为凑条件虚构库外配置——座椅布局不在 16 个字段里）＋ 提示词层（第 4 轮只说"请按这个新要求重新筛一遍"，没要求复述约束、没要求逐条对照，模型可以选择不对照）
层属判定	模型（指令遵循 / 上下文更新）＋ 提示词

同一个模型在同一轮里犯了两个方向相反的错误（5 座判成合规、7 座判成超标），说明 ≥6 被读成了 =6。同温度重跑 3 次复现同类问题，因此更像能力边界而非采样噪声；"轻量模型对早期轮次约束的注意力衰减更快"这一层无法从外部观察，只作假设记录。

案例二：预算判断自相矛盾（s3）

项目	内容
表现	预算 25 万，GLM 三次分别推荐 唐EV 26.98 万（r1）、Model Y 26.35 万（r2）、唐EV 26.98 万（r3），全部超预算。更能说明问题的是同段自相矛盾：r2 一边推荐 26.35 万的 Model Y 一边写它"且在预算范围内"，同段又把 24.98 万的理想 L6 判为"价格也超出了预算范围"——更贵的判合规、更便宜的判超标；r3 把 25.99 万的 ID.6 判为"接近 25 万，超出了您的预算"，紧接着把 26.98 万的唐EV 列为最佳选择
记录位置	results/scores.csv 第 17-19 行（s3 的 r1/r2/r3）；第 18 行 glm__s3__r2 的 notes =「违反约束：指导价不超过25万」；第 17、19 行 notes 另含「缺少‘最终推荐：’行」与「待核验品牌：现代」。原话见 runs/glm/s3/r2.json、r3.json 最后一轮（L61）
可能原因	模型层（数值比较错误）为主、解析层为辅：我们只读「最终推荐：」行，所以第 17、19 行的违规是通过「缺行 → 合规记 0」间接暴露的，指标判得了格式、判不了「模型自述的预算对不对」
层属判定	模型（数值推理）＋ 解析口径（指标缺口）

补两个细节：

理想 L6 的真实淘汰原因是增程 + 纯电续航不足，跟价格无关：s3 的硬约束是 any_of(纯电续航≥500km, 插电混动)（scenarios/s3_highway.json L13-L20），L6 是增程、纯电续航 212 km（data/cars.json L135-L136），两条都不满足；场景说明里写明「理想L6/L8为增程且纯电续航不足」（L25），用户原话是「但不要增程」（L47）。而它 24.98 万确实在 25 万以内。模型不是算错了一个数，而是给一个正确结论编了一个错误理由——这类错误比算错更难发现，因为结论看起来是对的。
同两次运行的 notes 标了「待核验品牌：现代」（scores.csv 第 17、19 行），按 grounding 规则每条扣 0.15、两次各记 0.85。但回原文核对后发现这是误报：原话是「现代汽车普遍采用模块化设计」与「现代电动汽车的充电技术发展迅速」（runs/glm/s3/r1.json、runs/glm/s3/r3.json 的 L50），「现代」是普通名词，被 parse.py L78-L81 的 brand in text 子串匹配命中了 brands.json L8 里的品牌词。这暴露两个方向相反的问题：规则会把语言现象当成事实错误（该改成词表精确匹配），而真正严重的「编造库外字段」（案例一的「可选装 6 座」）压根没有对应扣分项。前者是过严，后者是漏判，都属于权重设计的漏洞。

四、改进方案 A vs 备选 B

与第二部分的分工：本节只做改进方案的对比与选择（对应"创新"得分点）；完整的产品化规划（NABCD）在 2.7，两边互相引用、不重复。第二部分的 2.5 给出的是 P0/P1/P2 五条工程建议清单，本节从其中取两条最该本次就补的，写成"方案 A vs 方案 B"。

4.1 方案 A：约束卡片（提示词层，治"不逐条对照"）

做法：每一轮末尾重贴本阶段全部硬约束，强制模型逐条打勾，输出形如 ✅ 价格≤28 万 / ✅ ≥6 座 / ✅ 纯电 的自检表。

• 打哪一类问题：案例一的根因之一——第 4 轮只说"重新筛一遍"，提示词没堵住"不逐条对照"这条捷径。
• 成本：每轮 +200 tokens（本次实测单任务 9,675 tokens，增幅约 6%）。
• 验证方法：同场景同参数重跑 3 次（+1 场景对照），看"最终推荐："缺失率能否从 5/9 降到 0；同时看约束遵循是否从 0.333 上升。

4.2 备选 B：双通道解析（解析层，治"判不了自述对不对"）

做法：以"最终推荐："行为主通道；缺行时回退到"含推荐语义的末句"，并给该次判定打上低置信标记。

• 打哪一类问题：案例二的指标缺口——现在 5 次缺行使合规分连带记 0，格式层与车型层的错误被混进同一个数字里。
• 成本：约 20 行代码（改 parse.py）。
• 验证方法：用现有 18 条记录离线重放，对比新旧分数并写明口径变化。

4.3 选择理由（以及为什么不选"让模型自检"和"换更强模型"）

方案	选 / 不选	理由
A. 约束卡片（提示词自检表）	选（主方案）	成本最低（+6% token，0 元）；直接命中 s2 的复现错误；效果可用现成指标量化（缺行率 5/9 → 0）。风险：靠模型自觉——案例一里它连"6 座"语义都理解反了，自检表也可能把错误写成 ✅，所以必须与 B 或 2.7 的规则校验配合使用，不能单独上线
B. 双通道解析（回退解析）	选（配套，但必须显式改口径）	约 20 行代码就能把"车型层 5/9 合规"与"格式层 5/9 缺失"分开计量，读者不会再误读成"GLM 一台合规车都没选出来"。代价明确：会改变历史分数（原来记 0 的运行回退后可能拿到 0.6），所以必须同步改 weights.json、在博客写明"口径已变更"，否则读者会以为模型一夜之间变强了
只让模型自检、不加外部校验	不选	案例一 / 二都证明"模型自述"不能当证据：它一边说"在预算范围内"一边推超预算的车
全面换成更强的模型（DeepSeek-R1）	不选	token +77.9%，而 s1 上两者都是 100 分；对 90% 的常规场景是浪费，且不解决"自述当证据"的根本问题

一句话：方案 A 降低模型出错的概率，方案 B 让我们能分清"是模型错还是我们的尺子错"。两者都是"承认模型会错，但让错误可定位"，这也是 2.7 里"约束守卫"这个功能的最小前身。

五、第一部分总结论与边界声明

总结论（第二部分 2.3 会直接引用这一句，不重复贴图）：

DeepSeek-R1 总体更强（综合 95.80 vs GLM-4-Flash 51.66），差距集中在 s2（中途改需求）与 s3（约束收紧）——s1 上两者完全打平（组内归一化 93.83 vs 93.82，差 0.01，落在噪声区间）；GLM 没有任何维度反超，仅在 token 用量和现金成本侧占优（单任务 9,675 vs 17,210 tokens，少 44%），且延迟反而更慢（12.6 s vs 9.3 s）。因此真正被测出来的能力是"需求变更下的约束保持"，而不是"谁更会推荐车"。

边界声明（务必保留）：

• 每场景仅 3 次重复（n=3/场景，9 次/模型），样本量小，未做显著性检验；
• 结论仅适用于本次 12 款教学模拟车型、本套提示词与本次参数设置（GLM temperature=0.3、max_tokens=1600；DeepSeek 无 temperature、max_tokens=6000）；
• "综合分"是组间 min-max 归一化后的相对值，groups.csv 的组内综合分与 models.csv 的模型综合分口径不同，不可混用、不可相加，也不代表行业整体排名；
• 车型库为人工整理的教学模拟数据，不代表真实市场报价，不得作为购车依据；
• 模型不可观察的内部原因（注意力衰减、轻量模型定位）一律标注为假设，不作事实陈述。

---

第二部分 分析

《构建之法》里有三句话是本部分的分析框架：程序 = 算法 + 数据结构；软件 = 程序 + 软件工程；软件企业 = 软件 + 商业模式。下面按这三层拆两个被测平台，再回到我们自己的评测系统，最后用真实数字回答"买哪个模型"和"如果是项目经理该做什么"。

---

2.1 三层分析：这两个平台分别站在哪一层

2.1.1 程序层：算法与数据结构

被测侧的算法差异，直接决定了我们在评测里看到的现象。

GLM-4-Flash 是通用对话模型：一次请求进、一次文本出，上下文 128K，官方并发上限 30（来源：智谱开放平台模型页，核对日期 2026-10-17）。它的"算法"就是自回归生成，没有中间推理产物。

DeepSeek-R1（仓库配置名 deepseek-reasoner，这个标识的命名沿革见 2.1.2）是推理模型：输出分两段，先产出思考链（reasoning tokens），再产出正文。这个差异在我们代码里留下了一个真实的坑——最初 max_tokens 沿用通用模型的 1600，思考链把额度吃光，finish_reason=length，正文为空。现在的 models.json 把 reasoning 模型的 max_tokens 提到 6000，并在 providers.py 里加了"空正文判定"：正文为空按失败重试，而不是当成功记录。这就是程序层的第一课：两种模型的输出结构不同，接口不能只换一个 model 名字。

数据结构这一侧，我们的选择是把"领域知识"完全外置：

• data/cars.json：12 款车 × 16 个字段（id/brand/name/year/trim/price_wan/body/seats/powertrain/ev_range_km/fuel_l_per_100km/power_kw/cylinders/adas_l2/airbags/aliases），带 meta.disclaimer 声明为教学模拟数据，并用 meta.source 交代来源口径（公开资料人工整理、未逐条留存原始链接）——**这一条是后来补的，恰好说明"数据有出处"不是写句话，而是要能说清"出处有多硬"**；
• scenarios/*.json：3 条场景脚本，每条 = phases（约束）+ turns（逐轮用户话术）+ expected_valid_ids（手算预期合法车型）；
• runs/*.json：一次任务 = 6 轮 messages 数组 + 每轮的耗时与 token。

上下文管理是我们自己在算法层写的：同一次任务内 messages 累积（模型能看到前 4 轮说过的预算），不同 run 之间清空重开（保证 3 次重复相互独立）。这个设计有代价，但代价落在哪里和我们预想的不一样。DeepSeek 单次任务平均消耗 17,210 tokens，GLM 9,675（results/models.csv 的 avg_tokens）。把 18 条记录按轮次加起来拆开看：输入侧 DeepSeek 10,041、GLM 8,217，只差 22%；输出侧 7,168 对 1,458，差 4.9 倍。token 差距的七成六（5,710/7,535）来自输出，不来自"上下文越滚越长"。 累积的输入确实随轮次上涨，但真正把账单撑大的是思考链。这个反直觉的拆分，正好是 2.1.3 讨论"推理溢价"的直接证据。

工具调用参数解析这一层，我们这次是缺位的。 weights.json 里 tool_calling 权重为 0，说明本次没有接 Function Calling，模型只能靠"自然语言 → 我们自己写的正则/表格解析"（parse.py，102 行）。这不是省事，是能力缺口：一旦接入"查车型库/算落地价"这类工具，模型要输出结构化参数、我们要校验参数合法性与工具返回的可信度，那才是真实工程里最容易出问题的地方。这一点在 2.7 的产品规划里会作为切入点。

2.1.2 软件工程层：服务、文档、协作机制

平台侧，值得注意的有四件事。

第一，OpenAI 兼容接口已经成了事实标准。两家平台的 base_url 不同（https://open.bigmodel.cn/api/paas/v4 与 https://api.deepseek.com/v1），但请求体、流式格式、错误码语义高度一致，所以 providers.py 只用一个 112 行的文件就同时对接了两家。这种"接口收敛"降低了接入成本，也让切换供应商的门槛接近零——models.json 里改两行就能换模型。

第二，模型标识是会失效的契约。DeepSeek 官方文档「模型 & 价格」页（查询日期 2026-11-08）给的是一张"别名—实体"映射表：deepseek-chat 与 deepseek-reasoner 已经不是两个独立模型，而是指向 deepseek-v4-flash 的非思考与思考两种模式，文档标注了 2026-07-24 这个切换日期。我们 11-08 晚的 9 次调用用的仍是 deepseek-reasoner，全部返回 status=ok——说明兼容别名没有关闭，但它背后已不是当初那个独立模型。对做评测的人，这才是真正要命的地方：同一个字符串，调用的实体可能被换过，而你手上只有那个字符串。我们的应对很笨但有效——把 actual_model 和 provider_base_url 一起写进每条 runs/*.json（不是只记配置名），这样半年后回看，能知道当时到底调了谁、走的哪个入口。

第三，开放平台生态是分层的：免费额度层（GLM-4-Flash 定价 0 元，128K 上下文，30 并发）、按量计费层（DeepSeek 价格页给出 v4-flash 输入 1 元/百万 tokens、输出 2 元/百万；v4-pro 输入 3 元、输出 6 元，查询日期 2026-11-08）、企业层（私有化部署、专有实例）。同一家厂商的三个层，服务的是完全不同的用户：学生和独立开发者吃免费层，创业公司吃按量层，政企吃私有化层。

第四，但这几家的软件工程成熟度，其实还差得远。 我们这 18 次调用踩到的、以及查文档时发现的，至少有五处属于"工程上没做完"，而不是"模型能力不够"：

• 文档与实现不同步。 DeepSeek 的兼容别名在 2026-07-24 换了背后的实体，但脚本里写死的字符串不会自己报错，也不会告诉你调用对象已经变了——它只会在某天开始返回 400，而调用方的第一反应通常是"模型变笨了"。平台既没有"别名迁移期"，也没有"这个别名现在指向谁"的查询接口。
• 限额不透明。 文档写 30 并发，实际限流据我们调用中的观察可能按分钟窗口与账户等级动态调整（这一点各家文档都没写清）；429 响应里的 retry-after 语义也不一致，有的给秒数、有的不给，而它直接决定重试策略怎么写，我们只能靠三次退避硬扛。
• 错误码语义不统一。 同样是"内容被拦"，一家返回 400 带中文说明，另一家返回 200 但正文为空——后者最危险，因为它在监控面板上是一次"成功"。我们 providers.py 里那段"空正文按失败重试"，就是被这个坑逼出来的。
• 没有版本化基准。 模型侧更新（换版本、改默认参数）不会通知调用方，也不保留旧版本可回滚。对做评测的人，这意味着昨天的结论今天可能失效，而你无法证明"是模型变了"还是"是我的数据变了"。
• 可观测性缺失。 平台侧只告诉你"本次调用成功"，没有可查询的调用历史接口；费用明细按天汇总，无法定位到单次请求。做成本分析只能像我们这样，在客户端自己记账。

这五条没有一条是模型能力问题，全是接口契约与运维支撑的问题。模型能力的竞争已经很卷了，但把它们接进生产系统的那一层工程，还停在"能用"，没到"可靠"。

我们这一侧，工程机制是按"可复现"设计的。

机制	具体做法	解决的什么问题
职责切分	runner 执行、providers 调用、parse 解析、rubric 打分、visualize 出图	换模型不动评分，改评分不动调用
断点续跑	已完成记录跳过，--force 才覆盖	18 次跑一半断网，重跑不用从零开始
结果隔离	mock 结果写 runs_mock/，不覆盖正式结果	自测数据不能污染正式结论
密钥隔离	.env + .gitignore，仓库内无任何 Key	提交到公开仓库不泄密
版本迭代	16 次提交（截至 f90a454，含 2 次合并、1 次平台初始化），其中 2 次是修自己的 bug（分批运行覆盖 meta.json、mock 覆盖正式结果）	评测系统本身也要被"评测"

这里有个容易被忽略的细节：评测系统的 bug 会伪装成模型的失败。meta.json 被覆盖那次，如果没发现，我们会在博客里写"某模型某场景解析失败"，而真实原因是我们自己的写文件逻辑。所以 2.4 分析 BUG 时，我坚持先分"是模型错还是我们的尺子错"。

2.1.3 商业层：它靠什么赚钱

免费额度获客。 GLM-4-Flash 是 0 元定价（输入/输出均为 0，来源：智谱开放平台定价页，2026-10-14 核验），新用户注册另赠 2000 万 tokens 资源包（同页，2026-10-14 核验）。我们这次 9 次任务用了 87,079 tokens（results/models.csv），成本严格为 0。这是典型的"用免费模型养开发者习惯，用旗舰模型收钱"：等你把 GLM-4-Flash 接进产品、跑顺了链路，需要更强能力时，迁移成本最低的路径就是升级到同厂的付费模型。

Token 计费与推理溢价。 DeepSeek 这一侧更能说明"推理"值多少钱。R1 时期，思考链按输出计费，官方输出价是 V4 的 4.4 倍（第三方价格追踪站 TokenMix，2026-04）；现在厂商的做法变了：思考模式做成同一个模型的开关，单价不涨，但思考 token 计入输出，溢价从"单价"转移到"用量"。我们实测的数字正好印证：DeepSeek 单任务 17,210 tokens，比 GLM 的 9,675 多 77.9%，但平均延迟反而更低（9.3 s vs 12.6 s）。也就是说，我们为"想得更久"付的是 token 钱，不是时间钱。

按官网单价粗估：DeepSeek 侧 154,887 tokens（9 次合计）即使全部按最贵的输出价 2 元/百万计算，上限也只有 0.31 元；GLM 侧 0 元。18 次完整多轮任务的现金成本上限就是这三毛一分——这是 2026 年做大模型评测最反常识的一点：算力贵，但调用便宜到可以忽略。

开源 + 云双轨。 DeepSeek 开源权重、自营 API 也卖；智谱开源 GLM 系列、云 API 也卖。双轨的好处是话语权（开源社区贡献口碑、云服务收现金流），坏处是"同款模型不同渠道不同价"——第三方中转渠道的报价普遍低于官方价（折扣随渠道与时点波动，本文不引用具体折扣数字）。对我们这种只跑 18 次任务的小项目，渠道差异无所谓；但对每天几亿 token 的业务，渠道选择直接决定毛利。

市场结构。 按调用量算，2025 年中国公有云 MaaS 市场火山引擎 49.5%、阿里云 28%、百度智能云 10%，三家占近九成（IDC《中国公有云 MaaS 市场追踪》，2026-05，经 C114 2026-05-07 报道）。按营收算火山引擎仍超 40%，前五里出现了智谱——调用量份额和营收份额不是一回事，这也是"低价模型冲量、旗舰模型创收"的直接证据。

---

2.2 开发时间估计

《构建之法》8.6 讲工作估计要给"单位、依据、误差"。我们的实际数据如下（经验估计，非严谨工时统计）：

部分	代码量	估计人时	依据
config.py + providers.py	143 行	3 h	两家平台对接、失败重试 3 次、空正文判定、mock 通道
prompts.py	44 行	1 h	系统提示 + 12 款车表格注入
runner.py	214 行	5 h	多轮上下文、断点续跑、逐条落盘、批次合并
parse.py	102 行	3 h	Markdown 表格、车型别名模糊匹配、品牌核验、最终行提取
rubric.py	303 行	6 h	6 个维度的公式与归一化，改过 2 轮口径
visualize.py	142 行	2 h	雷达图 + 分组柱状图，中文字体踩坑
车型库 + 3 个场景	12 款 / 3 脚本	4 h	参数核对、expected_valid_ids 手算校验
合计	948 行	≈ 24 人时（3 人日）	6 人协作，2 天内完成

行数口径：按 master 提交 f90a454（2026-11-10 合并 c-charts-n3 与 b-data-source 之后）统计的 7 个 Python 文件。其中 visualize.py 的 142 行含 C 补充的坐标轴单位与 n=3 标注。

误差分析。 按"948 行 × 1.5 h/百行 ≈ 14 h"的经验生产率，实际 24 h，偏差 1.7 倍。超支主要不在编码，在三类返工：

1. 口径返工：评分公式从 4 维度扩到 6 维度，rubric.py 重写一次；
2. 供应商返工：原定通义千问因账号欠费不可用，临时换成 GLM-4-Flash，models.json、提示词、分工文档全部要跟着改一遍；
3. 自测返工：mock 数据覆盖正式结果、分批运行覆盖 meta.json，各修一次。

如果重做，估计 8–10 人时：parse.py 与 rubric.py 的骨架可复用，真正从零的只有车型库和场景脚本。另外要强调一个"运行时间 ≠ 开发时间"的数字：18 次完整多轮任务实际只跑了 27 分钟（23:54 — 00:21），而开发和调试花了 3 人日。评测成本的大头在设计和口径，不在 API 调用——这也是我们建议把"约束自检"和"评测脚本"沉淀成工具的动机。

---

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

第一部分已经给出六维评分、雷达图和分场景得分，这里不重复贴表、不重复算指标，只回答一个工程问题：什么需求下该选谁。

先说一个容易被误读的地方：两者的差距不是"全面强弱"，而是"在需求变化时还守不守得住约束"。s1（常规通勤、约束一次说清）两个模型 6 次运行的单次得分全部是 100.0（scores.csv），组内六维综合分 93.83 对 93.82——那 0.01 只来自延迟与 token 的归一化，是噪声；差距几乎全部来自 s2（中途改需求）和 s3（多目标权衡）。换句话说，这次真正测出来的能力是"需求变更下的约束保持"，不是"谁更会推荐车"。

由此得到三类选型判断。

一、要机器可读的结构化输出（价格计算、合规校验、批量推荐）→ DeepSeek-R1。
代价是单任务 token 多 77.9%，换回来的是可解析的格式与可核验的合规。在业务里这笔账是划算的：一次错误推荐的返工成本是几千到几万元（差一个配置、差一个座位数），远高于单次三分钱的 token 费（17,210 tokens 全按最贵输出价 2 元/百万算约 0.034 元）。

二、高频、低成本、话术类任务（初筛、问答、文案）→ GLM-4-Flash。
0 元定价、token 少 44%，而 s1 的表现与 R1 完全一致。用它承担"第一轮接触用户"的角色，现金成本为零。但有个反直觉的细节必须说清：我们的"成本与延迟"是复合分（延迟占 0.6、token 占 0.4），GLM 在这一项上反而略低（0.55 vs 0.58）——它 token 少 44%、单价为 0，却比对方慢 35%（12.6 s vs 9.3 s）。"便宜"和"综合划算"是两件事：如果用户的痛点是等，省下的钱买不回那 3 秒。

三、任何对"结论正确性"有要求的场景 → 无论选谁，都要加外部校验。
这是本次评测最实用的一条。GLM 在 s2 的 3 次运行里有 2 次其实选对了车，问题出在没按格式交代；而它在 s3 是 3 次全错。**"选对车"这件事本身不稳定，而"模型说自己满足了条件"不能当证据**——案例二里它一边说"在预算范围内"、一边推荐超预算的车，自述与事实相反。

一条反向建议：别用"多跑几轮取多数票"来解决约束问题。 我们的 s2 三次运行在同一温度下复现了同类错误，说明这不是采样噪声，而是能力边界；多数投票只会把同一个错误投三次。

边界声明：每场景仅 3 次重复，样本量小；结论只适用于本次 12 款教学模拟车型、本套提示词与本次参数设置（GLM temperature=0.3、max_tokens=1600；DeepSeek 无 temperature、max_tokens=6000）。两个模型的"综合分"是组间归一化后的相对值，只能在同一批数据内部比较，不代表行业整体排名。

---

2.4 BUG 存在的原因分析

先把"失败"的构成说清楚，否则后面全是误判。18 次运行 status 全部 ok，error 0 条（runs/all.jsonl）。所以本文说的"失败"不是接口失败，而是语义失败，分三类：

• 格式失败：没按约定输出 最终推荐：<车型> 行，机器无法判定 → 合规分连带记 0；
• 约束失败：输出可解析，但推荐车型违反硬约束；
• 事实失败：陈述了车型库里不存在、或与库内字段相反的参数（本次见到的样本是"可选装 6 座""后排座椅可放平"，以及把增程的理想 L8 说成纯电）。

这三类的占比直接决定该修模型还是修提示词。逐条核对原始记录（runs/glm/s2|s3/r*.json 的最后一轮）后，得到的表和 E 在分工文档里的初稿有一处不一致，已在下表更正。

行号口径：下文引用的 scores.csv 行号一律按数据记录序号计（不含表头行），用编辑器打开该文件时对应行号需 +1。全表 18 条记录，第 14–16 条为 glm__s2__r1~r3，第 17–19 条为 glm__s3__r1~r3。

场景	格式行	车型本身是否合规	说明
s1（3 次）	3/3	3/3 合规	完全正常
s2（3 次）	0/3	1/3 违规、2/3 合规	r1 推 5 座 Model Y（违规且称"可选装 6 座"）；r2/r3 推唐EV（7 座、26.98 万，合规），但都没写格式行
s3（3 次）	1/3	0/3 合规	r1/r3 推唐EV 26.98 万、r2 推 Model Y 26.35 万，均超 25 万预算

所以 models.csv 里 GLM 的"硬约束符合度 0.333"，是格式层扣分与车型层错误叠加的结果：车型层面 9 次里 5 次合规、4 次违规；因 5 次没写"最终推荐："行，机器只读到 4 次，其中 3 次合规，最终记 3/9。这个数不拆开讲，读者会以为 GLM 连一台合规车都没选出来——而它其实有一半选对了，只是没说对话。

案例一：改需求后"发明"一个配置（s2）

• 现象：第 4 轮把条件改成"28 万以内、6 座以上、纯电"后，GLM 第 1 次运行推荐 5 座的特斯拉 Model Y（26.35 万），原文写"虽然 Model Y 的标准配置是 5 座，但可以通过选装第二排座椅来升级为 6 座"；同一次还把 7 座的唐EV 淘汰，理由是"座位数为 7 座，超出用户要求的 6 座以上"。第 3 次运行犯了方向相反的同一个错：淘汰 6 座的 ID.6 CROZZ，理由是"提供的是 6 座配置，不符合 6 座以上的要求"。**"6 座以上"这一个短语，三次运行里判错两次——一次把 7 座判成超标，一次把 6 座判成不达标，两次都不是"6 座以上"的意思。**
• 记录位置：runs/glm/s2/r1.json 最后一轮；results/scores.csv 第 14 行 glm__s2__r1，notes = "缺少'最终推荐：'行"。
• 定位：模型层。选装 6 座这个字段在 data/cars.json 里不存在（16 个字段里没有座椅布局），属凭空补一个能力来满足约束；r1 把 7 座判超标、r3 把 6 座判不达标，说明≥6这个符号在两种语境下都被理解错了。错误方向相反，但指向同一件事：**约束语义没有被当成硬规则执行，而是被当成"可以商量的偏好"**。
• 提示词层的贡献：第 4 轮原话是"请按这个新要求重新筛一遍"，没有要求模型复述新约束、也没有要求逐条对照。模型完全可以选择"不逐条对照"，我们的提示词没堵住这条捷径。
• 假设（不可观察，不作断言）：GLM-4-Flash 是轻量定位，128K 上下文里对早期轮次约束的注意力衰减可能更快；3 次复跑在同温度下复现同类问题，更像能力边界而非采样噪声。

案例二：预算判断自相矛盾（s3）

• 现象：预算 25 万，GLM 三次分别推荐唐EV（26.98 万）、Model Y（26.35 万）、唐EV（26.98 万），全部超预算。更能说明问题的是，它在同一段回答里自相矛盾了两次。第 2 次运行推荐 Model Y（26.35 万），并写它"且在预算范围内"；同一段又把 24.98 万的理想 L6 判为"价格也超出了预算范围"——更贵的判合规，更便宜的判超标。第 3 次运行把 25.99 万的 ID.6 判为"指导价接近 25 万，超出了您的预算"，紧接着推荐 26.98 万的唐EV 作为最佳选择——同一段里 25.99 万算超支，26.98 万却是最优解。
• 记录位置：results/scores.csv 第 17–19 行；第 18 行 glm__s3__r2 的 notes = "违反约束：指导价不超过25万"；第 17、19 行 notes 额外含"待核验品牌：现代"（这一条是误报，下面单独说）。第 2、3 次运行的原话分别在 runs/glm/s3/r2.json、r3.json 的最后一轮。
• 定位：模型层（数值比较错误）为主，解析层为辅。我们只读"最终推荐："那一行，所以第 17、19 行的违规是通过"缺行 → 合规 0"间接体现的，而不是被直接抓到"推荐了超预算车"。这说明指标有缺口：**能判"格式对不对"，判不了"模型自己说的预算对不对"**。
• 补充一个细节：理想 L6 的真实淘汰原因是增程（场景要求纯电续航 ≥500 或插混、不要增程），它在 25 万以内。模型不是"算错了一个数"，而是给一个正确的结论编了一个错误理由——这类错误比单纯算错更难被发现，因为结论看起来是对的。
• 必须澄清一处"幻觉"记录：scores.csv 第 17、19 行 notes 里的"待核验品牌：现代"是误报，不是模型编造。 回查原文，那两次说的是"现代汽车普遍采用模块化设计"和"现代电动汽车的充电技术发展迅速"——"现代"在这里是副词，与现代汽车（Hyundai）无关。我们的 find_unverified_brands() 只做一件事：拿 brands.json 里的品牌名去正文做子串匹配（brand in text），于是"现代"被当成了品牌，两次各扣 0.15，grounding 记 0.85。函数自己的 docstring 写的是"作为人工核验线索"，但 rubric.py 把它直接当扣分依据——线索变成了判决。这是"尺子的假阳性"：字面匹配分不清词性与词义。
• 反过来，这几批记录里真正的库外陈述，一条都没被抓到。 s3 的 r1、r3 都说唐EV"后排座椅可放平"，而 cars.json 的 16 个字段里没有座椅放平；s2 的 r2、r3 把增程的理想 L8 称作"纯电动"（库内 powertrain 字段写的是增程）；s3 r1 还把 Model Y（26.35 万）与 L6（24.98 万）说成"价格普遍高于比亚迪唐EV"（26.98 万），大小关系整个调反。三处都可核验，grounding 一分没扣。
• 所以这一项的真实含义是：它测的是"有没有出现库外品牌名"，不是"有没有编造内容"。 GLM 的 0.967 既不说明它只错了 3.3%，也不说明它编的那几处被记住了。要补这个洞，得给 16 个字段各配一套取值域校验（"座椅放平"要能在字段里找到对应项、"纯电动"要与 powertrain 一致），而不是只查品牌——这正是 2.5 里 P1"反向用例"要解决的事。

---

2.5 软件工程方面的建议

2.4 定位了问题出在哪一层，这一节回答"按什么顺序修、怎么验证修好了"。五条建议按投入产出比排序，前两条本次就该补，后三条属于产品化阶段。

优先级	建议	对应 2.4 的哪类问题	验证方法	成本
P0	约束卡片：每轮末尾重贴 4 条硬约束，强制逐条打勾（✅ 价格≤28 万 / ✅ ≥6 座 / ✅ 纯电）	提示词层：第 4 轮只说"重新筛一遍"，没要求复述约束，模型可以选择不逐条对照	同场景重跑 3 次，看格式行缺失率是否从 5/9 降到 0	每轮 +200 tokens
P0	双通道解析：以"最终推荐："行为主通道，缺行时回退到含推荐语义的末句，并标注低置信	解析层：评分只读固定行，判得了格式、判不了"模型自述的预算对不对"	用现有 18 条记录重放，对比新旧分数并说明口径变化	约 20 行代码
P1	反向用例：补"看起来满足、实际不满足"的陷阱（7 座被判超 6 座、26.35 万被判在 25 万内）	测试覆盖：3 个场景都是正向筛选，测不出算数能力	新增 1 个场景，预期合格集合为空或唯一，--dry 能校验	1 个 JSON 文件
P1	启动自检：跑批前发一次最小请求，确认模型标识存活	接口层：别名静默失效会被记成"模型能力下降"	故意写错 model 名，脚本应在 1 秒内报"模型不可用"，而不是跑完 18 次记 18 个 0	约 15 行代码
P2	上下文压缩：只保留"约束摘要 + 上一轮结论"，不留全文	上下文管理：s2 到第 6 轮时输入已含前 5 轮全文，约束容易被淹没	A/B 对比输入 token 与一致性得分	需实验，本次未做

这里有个取舍必须讲明：P0 的双通道解析会改变历史分数。 原来记 0 的运行，回退后可能拿到 0.6。所以它不能悄悄上线，必须同步改 weights.json、在正文里写明"口径已变更"，否则读者会以为模型一夜之间变强了。工程上这叫评测工具要跟着结论一起版本化——比修一个 bug 本身更重要。

还有一条不属于代码，属于流程：把"尺子的 bug"和"被测对象的 bug"分开归档。 我们踩过 meta.json 被分批运行覆盖、mock 结果覆盖正式结果，两次当时的第一反应都是"模型解析失败了"。尺子出错时，量出来的一切都是错的。所以每次异常先问一句"是我们写错了还是它答错了"，这个习惯比任何工具都管用。

---

2.6 市场概况

市场有多大：调用量在爆炸，营收在追赶。

指标	数值	来源 / 日期
中国公有云大模型调用量	2024 年 114 万亿 tokens → 2025 年 1,944 万亿（增约 16 倍，即为上年的 17 倍）	IDC《中国公有云 MaaS 市场追踪》，2026-05（C114 2026-05-07 报道）
中国公有云 MaaS 营收	2025 年 30.7 亿元；2026 年预计约 186 亿元	同上
2026 年 token 消耗预测	约 40,000 万亿（较 2025 再增约 20 倍）	同上
日均 token 消耗	2025 年 1 月 1.6 万亿 → 12 月底 9.6 万亿（公有云 MaaS 口径）；全市场口径 2026-03 已突破 140 万亿	IDC 2026-05；国家数据局（媒体 2026-03 报道）
中国 AI 大模型市场规模	2025 年 495.39 亿元（+68.4%）；2026 年预计 738.57 亿元（+49.1%）	艾媒咨询《中国 AI 大模型市场发展状况及用户行为调查数据》，2026
人工智能核心产业规模	2025 年有望突破 1.2 万亿元，企业数量超 6,200 家	中国信通院，2026（经上市公司年报引用）

口径提醒：本表「日均 token 消耗」一行混有两套口径——IDC 给的是公有云 MaaS（2025 年 1 月 1.6 万亿 → 12 月 9.6 万亿），国家数据局给的是全市场（含私有化部署与自建集群，2026-03 已 140 万亿）。按 IDC 的 40,000 万亿全年预测折算，公有云 MaaS 日均约 110 万亿，仍低于全市场的 140 万亿，两者不冲突；但不可相加，也不可用两者的增速互相印证。

用户有多少：C 端 6 亿，开源开发者 210 万（GitHub 口径）。

用户类型	规模	来源 / 日期
C 端生成式 AI 用户	6.02 亿人，同比 +141.7%	国家网信办《国家信息化发展报告（2025 年）》，2026-07-27
备案生成式 AI 服务	累计 748 款完成备案，435 款应用/功能完成登记（2025 年新增 446 款备案、330 款登记）	国家网信办，截至 2025-12-31；新华社 2026-01-09
开源开发者	GitHub 中国活跃开发者超 210 万（全球第三，美国 508 万、印度 255 万）；计入 Gitee 等国内平台超 350 万（全球第二）	开源社《2025 中国开源年度报告》，2026-06-22
单一生态开发者（对照）	鸿蒙生态注册开发者超 1,100 万（注意：这是单一生态口径，不等于中国开发者总数）	华为开发者大会 2026（HDC），2026-06-15
AI 智能体市场（中国）	2025 年 804 亿元（+123.2%）；2030 年预计 6,968 亿元	艾媒咨询《2026 年中国 AI 办公智能体产业发展白皮书》，2026

我们这个小项目站在市场的哪一格。 748 款备案模型、6.02 亿用户，意味着"选哪个模型"已经变成一个高频、低门槛、但没有标准答案的问题。企业没有能力逐个试，于是"可复现的横向评测"本身成了需求——这正是我们做的事：18 次任务、27 分钟、不超过 0.31 元的 token 成本，就能拿到一份带原始记录的对比表。把这件事产品化（2.7），卖的不是模型，是"选型证据"。

另外两个能反映真实竞争格局的数字：一是按调用量火山引擎占 49.5%、阿里云 28%、百度 10%，三家近九成，说明入口高度集中；二是按营收排名里出现了智谱，而智谱是靠 0 元的 GLM-4-Flash 拉调用量、靠旗舰模型收钱，说明低价模型是获客手段而非商业模式。对开发者，这意味着一件事：免费额度会长期存在，别急着把预算花在 token 上，先花在"怎么验证输出对不对"上。

---

2.7 产品规划：一个"约束守卫"（NABCD）

如果我是这个产品的新任项目经理，我不会去做"更好的推荐模型"——那是模型厂商的战场，而且我们 2.1 已经看到，模型能力的差距在常规场景下几乎为零（s1 两个模型都是 100 分）。我要做的是把"可判定的部分"从模型手里拿走。

新功能：Constraint Guard（购车约束守卫）——一个后置校验 API。业务把"用户约束 + 候选车型"丢进来，它返回"每台车是否合规、违反了哪一条、建议的替代车型"，可以插在任意 LLM 之后。

N（Need，需求）：本次实测里，模型会为了给出答案而伪造合规（"可选装 6 座"）、会把 26.35 万算成"在 25 万预算内"。导购场景一次错误推荐的成本是几千到几万元（差一个配置、差一个座位数），而不是三分钱 token。用户真正缺的不是推荐，是"推荐对不对"的证据。

A（Approach，做法）：规则引擎判定合规 + LLM 只负责解释和排序。约束用我们已有的 8 种可判定类型表达（price_max / seats_min / powertrain_in / adas_l2 / cylinders_not / body_in / ev_range_min / any_of），复用 parse.py 的车型归一化匹配与 rubric.py 的判定函数——948 行里可搬 405 行（parse.py 102 + rubric.py 303），接近一半。接口形态：

POST /check
{ "constraints": [{"type":"price_max","value":28}, {"type":"seats_min","value":6}],
  "candidates": ["model_y", "tang_ev", "id6"] }
→ { "results": [ {"id":"model_y","ok":false,"violations":["seats_min: 5 < 6"]},
                 {"id":"tang_ev","ok":true,"violations":[]} ] }

B（Benefit，好处）：这一层的设计目标是把"约束符合率"从模型侧的 0.333 提到 1.000，收益可验证——本次 9 次 GLM 运行里 4 次车型违规全部能被规则命中，包括 s3 第 2 次那条"在预算范围内"、实际 26.35 万超 25 万的自相矛盾（人眼看不出，规则一跑就露）。但边界要说清：它只覆盖车型层那 4 次，格式层那 5 次缺行不在规则管辖内，那属于接口契约问题，得靠 2.5 的 P0 双通道解析解决。延迟增加 <50 ms（纯本地规则），现金成本 0。对业务方的价值是可审计：每条推荐都带"为什么合规"的判定链。

C（Competitors，竞争）：平台自带的 JSON mode / 结构化输出能保证格式，不能保证事实（案例二就是格式对、数字错）；通用 eval 平台（如 LangSmith、Promptfoo）做的是离线评测，不做线上拦截；通用 RAG 方案解决的是"知识从哪来"，不是"结论对不对"。差异点在于：领域约束 + 库内可判定，这是通用工具不愿意做的脏活。

D（Delivery，交付）：第一周把 rubric.py 包成 HTTP 服务（内部工具，自己先用）；第二周接进我们的评测链路做回归，验证"拦截率 / 误拦率"；第三周开放给 2–3 个校园媒体或垂直导购号试用，指标是"每千次调用拦下多少条违规推荐"。不追求一次性做全品类，先做"新能源 + 预算敏感"这一格。

创新点用一句话说：这个功能不提高模型的能力上限，而是把"模型能力的下限"变成可测量、可拦截的。 现有做法要么信任模型（让模型自检）、要么换更强的模型（加成本），我们走第三条路——承认模型会错，但让错误在交付给用户之前被拦住。对导购这类"错一次就赔钱"的场景，这比把平均分从 51 分提到 60 分更有用。

为什么是这个功能，而不是另外两个备选：

方案	做法	为什么不选
A. 让模型自检	提示词要求模型输出"约束自检表"	靠模型自觉。案例一里模型连"6 座"的语义都理解反了，自检表只会把错误写成 ✅
B. 换更强的模型	全面改用 DeepSeek-R1	成本 +77.9% token，且不解决"模型自述当证据"的根本问题；对 90% 的常规场景（s1）是浪费
C. 后置规则校验（选它）	模型管表达，规则管判定	把不确定的部分（自然语言）和确定的部分（数值比较）分开，出错时可定位到具体一条约束

---

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

写这一节的时候，我把 s2 那次运行又看了一遍。同一句"28 万以内、6 座以上、纯电"，一个模型给了合规的唐EV，另一个模型编出"可选装第二排座椅升级为 6 座"。两份回答都排版工整、理由充足、语气笃定。如果你是一个准备买车的普通用户，你看不出哪份是错的。

这是我这几天最真实的体会，也是我认为大模型对生活影响的核心：它把"找信息的成本"降到了接近零，同时把"验证信息的成本"推到了你面前。

具体说三点。

第一，决策的瓶颈从"信息"变成了"核验"。 以前买 30 万的车，要跑 4S 店、翻论坛、比配置表，一周起步。现在几秒钟就能拿到一张 5 款车的对比表。但那 5 行数据里可能有 1 行是编的。于是新的能力不是"会不会用 AI"，而是"知不知道要去哪里核"。我们做评测时用的方法是笨办法：把每个数字回查车型库。现实生活里对应的动作是——回官网、回 4S 店、回合同。AI 让决策变快，但没有让决策变轻。

第二，软件的形态在变，我们这次写的代码是证据。 948 行代码里，没有一行"车型知识"：哪些车 7 座、哪些车续航 500，全在模型和数据文件里；我们写的只有"约束怎么判、证据怎么留"。传统 MIS 是"把业务规则写进代码"，这次是"业务规则交给模型，代码只做守门"。这个转变对工程能力的要求变了：**从"会写业务逻辑"变成"会设计校验与证据链"**。我们踩的坑（格式行缺失导致合规判 0、mock 覆盖正式结果）全是"证据链"层面的坑，不是"功能没实现"。

第三，可评测性正在变成基础设施。 748 款备案模型、6.02 亿用户，普通用户和中小公司没有能力判断谁更靠谱。我们这 18 次任务，本质上是在给"自然语言软件"补单元测试——而且是那种最朴素的单元测试：给定输入，断言输出满足约束。这件事的门槛比想象中低（27 分钟、3 毛钱），价值却比想象中高：它能把"我觉得这个模型挺好用"变成"在这 3 个场景 9 次运行里，它的约束符合率是 33%"。

最后一个反直觉的观察：s1 上两个模型都是 100 分。 如果只测一个场景，我们的结论会是"两者无差异，选便宜的"——而这是错的。差距全在 s2/s3，也就是"需求会变、目标会冲突"的场景。生活里绝大多数决策都像 s2，不像 s1：预算会改、家里会添人、临时会多一个"必须是纯电"的条件。所以别用一次顺利的对话去判断一个模型，用一次需求变更去判断它。

大模型不会替你做决定。它做的是把做决定的成本降到很低，低到你必须自己承担"判断的责任"。这次评测给我最实用的收获不是"哪个模型分高"，而是学会了在每个结论后面追问一句：这个数，能在原始记录里找到吗？

---

附录 A：数据来源清单

编号	用途	来源	发布/查询日期
S1	调用量 114 万亿→1,944 万亿；MaaS 营收 30.7 亿（2025）/186 亿（2026E）；2026 年 40,000 万亿 tokens；日均 1.6 万亿→9.6 万亿；火山引擎调用量 49.5%、营收超 40%，阿里云/百度/智谱/移动云进前五	IDC《中国公有云 MaaS 市场追踪》，经 C114 通信网 2026-05-07 报道	2026-05-07
S2	备案 748 款、登记 435 款；2025 新增 446 款备案、330 款登记	国家网信办；新华社	2026-01-09
S3	生成式 AI 用户 6.02 亿、同比 +141.7%	国家网信办《国家信息化发展报告（2025 年）》	2026-07-27
S4	AI 大模型市场 495.39 亿元（+68.4%）；2026E 738.57 亿元（+49.1%）；2020–2026 复合增速 88.9%	艾媒咨询《中国 AI 大模型市场发展状况及用户行为调查数据》	2026
S5	AI 智能体市场 804 亿元（+123.2%）；2030E 6,968 亿元；2026 增速回落至 93.9%	艾媒咨询《2026 年中国 AI 办公智能体产业发展白皮书》	2026
S6	人工智能核心产业规模 2025 年有望破 1.2 万亿元，企业超 6,200 家	中国信通院（经上市公司年报引用）	2026
S7	GitHub 中国活跃开发者超 210 万（全球第三，美 508 万/印 255 万）；含 Gitee 等国内平台超 350 万（全球第二）	开源社《2025 中国开源年度报告》（2026-06-22 发布），经《经济参考报》2026-08-24 报道	2026-06-22
S8	鸿蒙生态注册开发者超 1,100 万（单一生态口径，非中国开发者总数）	华为开发者大会 2026（HDC），华为官网	2026-06-15
S9	全市场日均 token 调用：2024 年初 1,000 亿 → 2025 年底 100 万亿 → 2026-03 突破 140 万亿	国家数据局（经媒体 2026-03 报道）	2026-03
S10	GLM-4-Flash 定价 0 元、128K 上下文、30 并发；新用户注册另赠 2000 万 tokens 资源包	智谱开放平台定价页	核对 2026-10-14 / 10-17
S11	DeepSeek v4-flash 输入 1 元/输出 2 元、v4-pro 3/6 元（每百万 tokens）；deepseek-chat/deepseek-reasoner 自 2026-07-24 起改为指向 deepseek-v4-flash 的别名（非思考/思考模式），兼容期未关闭	DeepSeek API 文档「模型 & 价格」	查询 2026-11-08
S12	R1 输出价为 V4 的 4.4 倍（推理溢价参考）	TokenMix 价格追踪	2026-04

口径提醒：S1（IDC 公有云 MaaS）与 S9（国家数据局全市场）不是同一口径，相差一个数量级；S7（GitHub 活跃开发者）与 S8（鸿蒙生态注册开发者）也不是同一口径。本文引用时已分别标注，切勿混用或相加。

附录 B：与第一部分的口径一致性

1. GLM 的 0.333 需要解释：9 次里 5 次没写"最终推荐："行（s2 的 r1/r2/r3、s3 的 r1/r3），其中 s2 的 r2/r3 车型本身合规；s3 另有 2 次车型确实超预算。写作时如果只说"GLM 全部失效"，与 runs/glm/s2/r2.json、r3.json 的内容不符，建议表述为"格式层 5/9 缺失、车型层 5/9 合规、机器可读 4 次中 3 次合规，记 3/9"。
2. 分工文档「案例 1」的表述建议更正：原文写"GLM 3 次全部推荐 5 座的特斯拉 Model Y"，实际只有 r1 如此；r2/r3 推荐的是 7 座唐EV（合规），失败原因是未按格式输出。
3. **所有分差均取自 results/models.csv**，单次得分取自 results/scores.csv；groups.csv 中的组内综合分与模型综合分口径不同（组内 vs 组间归一化），引用时不要混用。
4. "GLM 出现 2 次品牌幻觉（现代）"这个说法不能再用：核对原文，s3 的 r1、r3 说的是"现代汽车普遍采用模块化设计""现代电动汽车的充电技术发展迅速"，"现代"是副词，不是现代汽车（Hyundai）。scores.csv 那两条 notes 是 parse.py 做子串匹配的产物，属假阳性；grounding 因此被从 1.0 压到 0.967。第一部分如果引用了这条 notes，建议删除或按 2.4 的说法处理。
5. 模型名称：models.json 的显示名写作"DeepSeek-R1（deepseek-reasoner）"，但 API 侧 deepseek-reasoner 已是指向 deepseek-v4-flash 思考模式的别名（见 2.1.2）。第一部分若通篇写"DeepSeek-R1"，建议首次出现时补一句"按仓库配置名，以下简称 R1"，否则读者去查官方文档会发现名字对不上。
6. scores.csv 行号按数据记录序号（不含表头），与用编辑器打开时看到的行号差 1，这是全文统一口径。