软件工程实践——大模型评测作业

这个作业属于哪个课程	202601福大-软件工程实践-W班社区-CSDN社区云
这个作业要求在哪里	软件工程实践——大模型评测作业-CSDN社区
这个作业的目标	通过编写统一的自动化测试程序，模拟多轮购车决策任务，对至少两个大模型的推荐准确度、多轮一致性、指令遵循、信息真实性、稳定性、响应延迟与调用成本等指标进行量化评测和可视化分析；同时结合实际体验、用户访谈和失败案例，分析模型、数据、提示词、解析程序及接口服务可能造成问题的原因，比较同类产品的适用场景，并从软件工程质量、测试覆盖、异常处理、产品规划和市场竞争等角度提出改进建议。
其他参考文献	软件工程 案例分析作业_软件工程例子-CSDN博客；如何评价微软的 UI 设计？ - 知乎；现代软件工程课件 需求分析 如何提出靠谱的项目建议 NABCD - SoftwareTeacher - 博客园；《构建之法》；智谱 AI：GLM-5.3-Flash 模型文档；智谱 AI：模型定价说明；阿里云百炼：Qwen3.8-Max 模型信息；阿里云百炼：模型调用价格与限流规则；36 氪《一份报告、两个第一，阿里云和火山引擎在争什么？》；研精毕智《中国 AI 大模型产业黄金时代（2026）》；华尔街见闻《高盛大幅上调中国大模型收入预期》；新华网《日均 Token 调用量达 140 万亿》；InfoQ《AI Agent 商业化的四个判断（一）》；36 氪《智谱对标 Anthropic 还不够》；乘联分会 2025 年数据

目录

一、第一部分：调研，评测

1.1 大模型1：Qwen3.8-Max

1.1.1 体验

（1）介绍和使用软件

被测模型基本信息（平台、精确模型标识与测试日期）：

项目	内容
模型名称	Qwen3.8-Max（通义千问深度思考版）
平台	阿里云百炼
模型 ID	qwen3.8-max
测试日期	2026-11-08
模型类型	推理模型（深度思考模式）
主要参数	平台默认（temperature、top_p 未调整，max_tokens 平台默认）
核心能力	多轮对话、深度推理、联网搜索、文本生成、结构化输出

功能简介与使用过程：在阿里云百炼注册并开通 Qwen3.8-Max（深度思考版）后，通过网页端实际操作，围绕四类任务测试其基本功能：①购车推荐——以"20 万元预算、城市通勤、空间大、安全性高"为需求，观察其分纯电/插混/燃油三类的推荐结果；②数学推理——用平均速度计算题检验其推导过程与结果；③开放讨论——"大学生买车必要性"；④信息查询——2026 款比亚迪宋 PLUS 的参数与价格。实际使用截图见下。

实际使用截图

1. 购车推荐提问与深度思考过程

2. 购车推荐车型详情

3. 平均速度计算题

4. 大学生买车必要性讨论

5. 2026 款比亚迪宋 PLUS 信息查询

（2）优缺点分析

数据量方面

• 优点：知识库覆盖主流家用车型，20 万预算级别推荐比较全面，分纯电、插混、燃油三类列举约 8 款车型；每款车型包含价格区间、空间参数（轴距）、安全配置（C-NCAP 评级、高强度钢占比）、优势点、适合人群等维度；对年份较新或小众车型（如 2026 款比亚迪宋 PLUS DM-i 荣耀版）信息不确定时，不会硬编参数，而是主动提示"大概率不准确，建议关注官方渠道"。
• 缺点：价格均为大概区间（如"约 14–18 万"），不够精确，需要用户自行核实。

界面方面

• 优点：聊天界面简洁清晰，深度思考过程可展开/折叠，能完整看到模型的推理步骤；每条回答底部显示字数、首帧时间、尾帧时间、输入输出 token 数，方便观测性能；左侧有历史记录列表，可切换不同对话；输入框旁有深度思考开关、联网搜索开关，功能入口直观。
• 缺点：深度思考过程默认展开，每次回答后一大段灰色文字占满屏幕，连续多轮对话时需要反复手动折叠，看多了累。

功能方面

• 优点：深度思考模式表现明显，回答前先输出结构化推理过程（如"分析用户需求→预算范围→用途→空间要求→安全要求"）；数学计算题能完整推导过程，还能解释背后的原理（调和平均数），不会直接给答案；输出结构化程度高，用列表、分点、分类排版，阅读体验好；支持联网搜索开关，可按需开启获取实时信息。
• 缺点：深度思考模式下输出内容偏长，简单问题也会展开较多推理过程。

准确度方面

• 优点：平均速度计算题回答正确（48 km/h），完整推导过程，没有掉进"直接取算术平均 = 50 km/h"的常见陷阱；购车推荐的车型和价格区间基本符合市场实际，车型选择合理；对不确定的信息主动提示风险，不会编造不存在的参数。
• 缺点：具体车型参数（如精确轴距、实测油耗）需要用户自行核实，模型给出的是参考值。

用户体验方面

• 优点：回答结构清晰，分点明确，容易阅读；对用户需求的理解准确，能从"20 万预算、城市通勤、空间大、安全性高"提炼出具体筛选维度；对不确定的信息态度谨慎，不硬撑。
• 缺点：深度思考模式下响应偏慢，简单问题也要等 10–20 秒；输出内容偏长，简单问题也会展开较多内容，信息密度可以更高。

（3）对产品的改进意见

1. 优化深度思考模式响应速度：简单问题（如日常闲聊）应该支持快速模式，不用每次都走完整推理流程，减少等待时间。
2. 增加对话收藏与对比功能：购车决策是多轮、多方案的场景，用户需要回看之前的推荐、对比不同方案，目前只能手动翻历史记录。
3. 深度思考过程默认折叠：现在每次回答后灰色思考区默认展开，占屏幕太多，默认折叠会更清爽。

（4）采访另一个用户

采访基本信息：

项目	内容
被测产品	Qwen3.8-Max
采访对象	计算机科学与技术专业大三学生
采访形式	线上文字访谈
测试任务	对话问答、代码解释、联网搜索、深度思考模式
采访总时长	约 25 分钟
测试时间	2026-11-08

采访聊天记录截图（线上文字采访，受访者使用约 25 分钟）

（1）采访对象的背景与需求

计算机科学与技术专业大三学生，平时有借助 AI 工具辅助学习的习惯。选择 TA 的原因：一是符合作业要求的"计算机、软件相关专业学生"条件；二是 TA 平时就常用 AI 工具查资料、解释代码，能对产品体验给出具体、有依据的反馈。采访方式为线上文字访谈，时间 2026-11-08，受访者使用时长约 25 分钟。TA 的需求：日常学习中的资料查询、代码解释与报错排查，希望回答准确、易懂、等待时间短。

（2）实际使用的产品栏目

受访者在网页端使用约 25 分钟，实际使用了这些功能：对话问答（问一个专业概念）、代码解释（解释一段 Python 报错）、联网搜索（查某个技术名词的现状）、深度思考模式（观察推理过程）。受访者无需指导即可上手，操作路径与普通聊天工具一致。

（3）使用过程中的问题与亮点

亮点（实际观察）：

• 深度思考过程完整，能看到"需求分析→原因→方法"的推理链，比直接给答案更让人放心；
• 回答分点、分类，结构清晰，容易阅读；
• 遇到不确定或冷门的问题不硬编答案，主动提示"大概率不准确，建议以官方渠道为准"，避免误导。

困难（实际观察 + 原因推测）：

• 深度思考区默认展开，连续多轮问答时屏幕上大段灰色文字，需反复手动折叠。（实际观察）
  【原因推测】产品可能把"展示推理能力"作为默认卖点，未针对连续多轮对话做默认收起。
• 联网搜索需手动开启，受访者不确定何时该开、回答是否联网。（实际观察）
  【原因推测】产品把"是否联网"的控制权交给用户，但缺少"建议开启"或"未联网"的提示。
• 回答习惯把背景、原因、方法都讲一遍，只想要关键结论时还要追加"说简短点"。（实际观察）

（4）用户体验改进建议

1. 深度思考过程默认折叠，需要时一键展开；
2. 简单问题走快速模式，不必每次都完整推理，缩短等待；
3. 增加对话收藏与方案对比功能，方便回看；
4. 回答中标注信息来源：哪些是联网查的、哪些是模型自身推断，便于判断可信度。

说明：带【原因推测】的为推测内容，其余为实际观察记录。

1.1.2 自动化测试

（1）模拟购车决策环境与统一测试条件

Qwen3.8-Max 使用 Python 程序调用模型接口，输入车型库 2026-11-08-teaching-v1 中的 14 款教学模拟车型。价格采用厂商指导价量级，单位为万元，参数单位和来源日期在车型数据文件中固定。测试条件、提示词、车型数据、输出格式和评分规则与 GLM 完全一致。每个场景运行 3 次，每次新建 ChatSession 并调用 reset()，同一次任务内连续保留上下文；场景 2 在第 4 轮进行需求变更。

环境、数据与接口封装：

• 运行环境： 使用 Python 虚拟环境安装 openai>=1.40.0 和 python-dotenv>=1.0.1。正式运行前依次执行 python scripts/self_check.py、python scripts/smoke_test.py --only qwen，前者只检查车型数据和提示词，后者只发送一条短请求检查接口，不输出密钥内容。
• 密钥与模型配置： 项目根目录的 .env 只保存本地密钥，不提交仓库；Qwen 使用 DASHSCOPE_API_KEY，默认地址为 https://dashscope.aliyuncs.com/compatible-mode/v1，模型标识为 qwen3.8-max。GLM 对应的 ZHIPU_API_KEY、地址和模型标识也由同一配置文件读取，避免把密钥写入代码。
• 统一 API 客户端： src/car_eval/llm_client.py 使用 OpenAI 兼容接口封装两个模型，统一发送 model、temperature、top_p、max_tokens、stream 等参数，并记录返回模型、正文、思考内容、prompt/completion/total token、耗时和请求参数。如果平台拒绝模型专属参数，客户端会在记录回退说明后重试一次，便于区分平台兼容性问题和模型能力问题。
• 统一采样条件： 两个模型均使用 temperature=0.7、top_p=0.95、max_tokens=4096、超时 180 秒、非流式输出。GLM 和 Qwen 都开启思考模式，不额外设置 reasoning_effort，以避免只对某一模型进行额外调参；虽然 GLM 官方推荐温度可能不同，本实验为了可比性统一使用 0.7。
• 固定车型数据： data/cars.json 标记为教学模拟数据，版本为 2026-11-08-teaching-v1，共 14 款车型，整理日期为 2026-11-08；车型含年款与配置版本（如 2025 款 DM-i）。价格口径是近似厂商指导价，单位为万元，不代表实时成交价；功率、扭矩、续航、油耗、电耗、轴距、车身尺寸和座位数等字段均在数据文件中注明单位和来源日期。数据校验会检查版本、必需字段、类型、能源类型、重复 car_id 及纯电/燃油字段的合理性。
• 公共提示词与输出约束： prompts/system_prompt.txt 明确要求只能使用固定车型库、不得虚构车型和参数；stage_templates.json 统一定义初始意图、逐条要点、需求变更、参数对比和最终选择五个阶段；output_rules.txt 要求先给简短中文说明，再返回结构化 JSON，候选 ID 必须来自车型库，对比表固定核验指导价、能源、功率、续航、油耗、电耗、轴距、座位数和 AEB 九个字段。场景 2 的新约束会明确替换旧约束，防止模型继续使用已失效条件。

场景设计如下，预期候选集合均在正式运行前由 python scripts/check_scenarios.py 根据车型库计算得到：

场景	预算与需求	预算外硬约束	预期候选与判定
S1 城市通勤三口之家	≤16 万；每天往返 35 公里，有固定车位，接送孩子	纯电或插混；气囊 ≥6 个	秦 PLUS、MONA M03、宋 PLUS；最终推荐必须属于这 3 款
S2 六口之家改需求	改口前 ≤28 万，改口后 ≤22 万；两孩两老，市区和近郊	改口前：座位 ≥6、气囊 ≥8；改口后替换为新能源、轴距 ≥2800mm	改口前预期 AITO M7；改口后预期 MONA M03、汉 EV、SU7；第 4 轮起按新规则判定
S3 长途高速通勤	≤14 万；每月两次单程 380 公里，无充电桩，后排常坐老人	排除纯电；能源为插混/油电混动/燃油；油耗 ≤5.0L	秦 PLUS、卡罗拉双擎；候选只有 2 款不视为缺陷

S1 主要考察基础筛选，S2 考察需求变更后的上下文保持，S3 通过只有两款合规车型的边界条件，检查模型是否会为了凑够候选而加入违规车型。

（2）提出购车意图

程序按照场景文件发出初始购车意图。例如 S1 包含“16 万以内、城市通勤、每天往返 35 公里、接送孩子、可安装充电桩”等信息，并要求模型返回结构化候选列表。S2 和 S3 分别加入六口家庭出行、长途高速、无充电条件等场景约束。

（3）大模型给出初步推荐

程序自动读取模型返回的 candidate_ids，将每轮候选保存到 results/raw/{模型}_{场景}_r{次数}.json，并与 data/cars.json 匹配。候选是否超预算、是否满足硬约束由后续脚本核验，不能只依据模型自己写出的理由。

（4）输入购车要点

在初步推荐后，程序逐条输入动力、续航、油耗、安全、空间、轴距和保值等购车要点，要求模型更新候选。S1 和 S3 各 6 轮，S2 为 7 轮，S2 第 4 轮专门发送需求变更；每次运行都重置上下文，不同运行之间相互独立。

（5）性能参数表格化对比

程序要求模型输出候选车型对比表，并保存原始文本和解析字段。评分时逐项核对指导价、能源、功率、续航、油耗、电耗、轴距、座位数和 AEB 等 9 个字段，检查表格数字是否与车型库一致。

（6）选出目标车型

最后要求模型结合当前有效约束，从候选集合中选出目标车型并说明理由；S2 必须使用改口后的预算和新能源/轴距规则，不能继续使用已替换的旧约束。Qwen 共完成 3 个场景 × 3 次，即 9 次独立运行。测试实现文件包括 scenarios/S1_city_commute.json、scenarios/S2_six_seat_change.json、scenarios/S3_highway_commute.json、scripts/check_scenarios.py、scripts/run_all.py、scripts/append_evaluation.py 和 scripts/build_overview.py；运行结果写入 results/raw/*.json、results/runs.csv、results/overview.md 和 results/overview.csv。

运行前先执行场景和环境自检，再进行单场景试跑和全量运行：

python scripts/check_scenarios.py
python scripts/self_check.py
python scripts/run_all.py --models qwen --scenarios S1 --runs 1
python scripts/run_all.py
python scripts/append_evaluation.py

脚本每轮失败自动重试两次；单次任务彻底失败时记录脱敏错误并继续其他任务，可用 --resume 补跑，不会破坏已有记录。results/runs.csv 一行对应一次运行，原始 JSON 中保留每轮 stage、原文、解析结果、耗时和 token。

（7）自动化评测

本次评测把“推荐是否合理”拆解为可以自动复核的指标。程序不直接采用模型的自我评价，而是用固定车型库重新核验预算、硬约束、车型编号和参数字段。场景 2 在第 4 轮发生需求变更：预算从 28 万调整为 22 万，座位数和气囊数被替换为“纯电/插混/增程、轴距不低于 2800mm”；从该轮开始，旧约束不再参与评分。两个平台的 reasoning_tokens 字段不完全一致，因此成本维度统一使用 total_tokens，推理 token 只作为问题分析证据。

指标	权重	判定标准	计算方式	样本数
A 推荐合理性/准确度	25	最终推荐在当期预算内，满足全部有效硬约束，属于运行前冻结的预期集合；候选列表不混入违规车型	合规最终推荐数/运行数，并对违规候选扣分	Qwen 9 次运行
B 多轮一致性	20	是否保留有效上下文，是否丢弃仍合规候选，最终推荐是否来自上一轮候选，评测轮是否推翻前序结论	各轮候选与当期合规集合的 F1，结合倒退次数扣分	Qwen 9 次运行
C 指令遵循	15	是否输出可解析 JSON，stage 是否正确，候选数量是否合规，对比表字段是否完整	结构解析、阶段、数量和字段检查的通过率加权	57 轮
D 信息真实性/防幻觉	15	是否出现车型库外的 car_id，参数是否与车型库一致	正确车型编号率和 378 个参数字段一致率	57 轮、约 189 个字段
E 稳定性	10	同模型同场景独立运行 3 次时，结论是否稳定，指标波动是否过大	结论一致性与 token/耗时变异系数折算	3 组
F 成本与延迟	10	单次任务是否在统一资源预算内完成	按 total_tokens 和各轮耗时相对最小值折算	Qwen 9 次运行
G 工具调用正确性	5	是否调用指定工具、参数是否规范、命中数是否正确、结果是否被使用	工具调用步骤和参数通过率	Qwen 1 次演示

评分脚本先依据车型库独立计算三个场景的合规集合，再与正式运行前冻结的基线逐项比对；若基线不一致则停止评分，防止事后调整标准。parsed 只表示 JSON 解析成功，不代表车型合规。

Qwen 分项结果

模型	A 合理性 25	B 一致性 20	C 指令遵循 15	D 防幻觉 15	E 稳定性 10	F 成本 10	G 工具调用 5	总分
Qwen3.8-Max	24.92	19.09	14.81	15.00	8.02	6.63	5.00	93.46

Qwen 的最终推荐没有出现违反预算和硬约束的硬失败，但多轮过程暴露出两个具有代表性的边界问题。这说明只查看最后推荐车型，可能会漏掉候选集合在中间轮次被错误收缩的情况。

改进上，建议把当前有效约束写入结构化 active_constraints，要求排除理由引用有效字段，并使用 JSON Schema 校验输出。相比只提高 max_tokens 或调整提示词顺序，结构化约束更容易自动验证，也能减少需求变更后的约束漂移。

案例分析

1. 边界案例一：把定性软偏好升级为硬约束。 在 qwen_S1_r2 的第 3 轮，用户表达的是“保值一般”这一偏好。车型库中只有“保值一般”的定性备注，并没有可用于硬筛选的保值率数值，场景 1 的正式硬约束也没有要求保值率必须达到某个阈值。但模型仍然把这条偏好当成排除条件，移除了本来满足预算、能源类型和气囊数量要求的 MONA M03。最终推荐仍然落在预期集合内，所以结果层面没有失败；然而候选集合已经发生了错误收缩，后续比较的对象也因此变少。这个案例说明，模型可能把“用户希望更好”理解成“用户不接受不够好”，导致约束强度被擅自提高。
2. 边界案例二：把模糊偏好解释成排除条件并返回空集合。 在 qwen_S2_r1 的第 3 轮，用户提出“车身尺寸不要太大”。这是一条需要结合场景和候选车型解释的偏好，并不是“车身长度不得超过某个数值”的硬约束。模型却直接把它当成排除条件，返回空候选列表 []。后续轮次中模型又恢复了正常推荐，最终选择仍然正确，因此如果只按“最终推荐是否正确”评分，这次运行甚至可能得到较高分。但从过程角度看，空集合使后续推荐无法追溯到完整的候选筛选过程，也说明模型没有把“偏好”“硬约束”和“暂时不优先”区分开。
3. 可能原因与影响：上述现象可能与自然语言中约束强度没有被结构化表示有关，也可能与模型在多轮对话中对最近一轮表述赋予了过高权重有关。这些只是根据外部输出作出的假设，不能断言模型内部的具体机制。它们共同造成的可观察影响是候选集合不必要地减少，导致多轮一致性和过程可解释性下降，即使最终推荐仍然正确，也不能说明整个决策过程没有问题。

改进与方案比较

方案比较：

方案	解决 JSON 截断	解决约束漂移	是否破坏可比性	成本	可验证性
P1 Schema + 预算解耦 + 自动续写	能解决	能解决	不破坏，反而减少平台差异	中	强
P2 将输出上限提高到 8192	只能降低概率	不能解决	轻微影响	低	弱
P3 关闭思考模式	取决于平台能力	不能解决	会改变被测对象	—	弱
P4 只调整提示词顺序	只能降低概率	不能解决	不破坏	极低	弱

验证方法： 先重放 Qwen 出现候选收缩的两个运行各 10 次，要求 JSON 解析成功率至少达到 19/20、无效约束引用为 0、丢弃仍合规候选次数不超过 1 次；再重跑 18 次全量任务，检查解析失败轮数、错误约束引用次数和推荐合理性，要求 A 维度不低于 24.96/25 基线。

结论范围

• 本部分只适用于 Qwen3.8-Max、14 款教学模拟车型、3 个场景、本次提示词和评分脚本。
• Qwen 每个场景只运行 3 次，共 9 次，适合观察趋势，不足以进行充分的统计显著性推断。
• 结论不能解释为 Qwen 在所有购车任务中的行业排名；本次只说明其最终推荐符合预期，但过程存在约束强度误判。

1.1.3 结论

综合评价：推荐。Qwen3.8-Max 在本次数据和场景下最终推荐准确度较高，9 次运行均满足最终硬约束，且车型参数防幻觉得分最高。但它在多轮过程中存在把软偏好升级为硬约束的问题。该结论仅适用于本次 14 款教学模拟车型、3 个场景和 3 次重复运行。

1.2 大模型2：GLM-5.3-Flash

1.2.1 体验

（1）介绍和使用软件

本次体验的模型为 GLM-5.3-Flash（Model ID glm-5.3-flash），通过 TRAE CN IDE 的自定义模型配置接入，测试日期为 2026 年 11 月 9 日；使用默认上下文窗口与默认采样参数（temperature、top_p 未调整，max_tokens 使用平台默认），深度思考默认开启，第一轮对话触发联网检索，输入支持文本与图片，五轮对话在同一会话内完成。官方 API 仅支持启用思考，本次未使用智能体或插件。

GLM-5.3-Flash 的基本能力包括通用问答、逻辑推理、写作、代码生成与调试、图片/视频/文件理解，以及联网搜索。联网搜索触发后可以获取较新的公开资料，并在回答中给出来源；深度思考模式会在复杂问题前展示推理过程。其多轮上下文能力较好，能够理解“上面提到的车型”“这些车型”等指代表达，并根据后续新增条件重新组织答案。

本次体验设置了一个购车咨询场景：用户年龄 25 岁，预算 15 万至 20 万元，主要用于城市通勤，周末偶尔自驾游，新能源轿车和 SUV 均可，重点关注经济性、智能化配置和驾驶舒适性。体验过程共进行五轮：提出购车意图、追问续航与动力等要点、增加停车和维保条件、要求整理参数对比表、要求给出最终推荐。

第一轮：提出购车意图。 用户要求模型推荐 3 至 5 款车型，并说明参考价格、推荐理由、主要优缺点。模型先表示已联网核实 2026 年 11 月在售车型的价格和配置，随后推荐小鹏 P7+ 2026 款、深蓝 S07 2026 款、小鹏 G7 超级增程版和零跑 C10 2026 款，覆盖轿车与 SUV、纯电与增程车型。整体上正确理解了预算、通勤、自驾游、经济性、智能化和舒适性等条件；小鹏 G7 旗舰版略超预算，模型进行了标注，零跑 C10 低于预算下限但作为价格较低的备选项保留。

第二轮：追问车型要点。 用户进一步询问续航能力、动力表现、智能驾驶辅助、电池安全和日常使用成本。模型沿用了第一轮的四款车型，先给出参数总览，再逐项比较续航、动力、电耗、补能和电池，并结合“高频短途通勤、偶尔中长途”的使用结构进行排序。回答附带多个参考来源，且与第一轮的车型和主要参数保持一致。

第三轮：提出新的需求。 用户补充了经常停车、车身不能太大、需要较好的停车辅助、后期维修保养成本不能太高等条件。模型能够识别这些新约束，并重新评估之前的推荐：明确剔除车身较长的小鹏 P7+ 和保养结构更复杂的小鹏 G7，保留深蓝 S07 和零跑 C10，同时新增尺寸更紧凑的深蓝 S05 和小鹏 MONA M03，给出新的排序和注意事项。这一轮体现了模型对上下文和需求变更的保持能力。

第四轮：整理参数对比表。 用户要求至少比较车型版本、价格、车身尺寸、续航、动力、智能驾驶辅助、停车辅助、日常使用成本及优缺点。模型选择深蓝 S05、深蓝 S07 和零跑 C10，输出覆盖九个项目的对比表；对于无法确认的数据逐项标记“未核实”，没有强行补齐，并主动披露零跑 C10 官网不同页面存在价格差异。该轮的结构化表达和不确定信息标注较好，但零跑 C10 的动力数据仍沿用了前一轮的存疑口径。

第五轮：最终推荐。 用户要求结合预算、通勤、停车、智能化和使用成本给出单一结论，并解释未选择另外两款车的原因，同时说明风险。模型最终推荐深蓝 S07 2026 款 630Max+ 华为乾崑激光版，并从预算、通勤、停车、智能化和成本五个方面说明理由；同时列出车宽与停车需求可能冲突、限时价格波动、保值率、智驾订阅和电耗等风险，并给出到店实测窄位泊车、确认权益和核实充电条件等建议。

（2）优缺点分析

数据与知识： 模型能够把车型参数具体到配置版本，覆盖续航、功率、零百加速、电耗、充电倍率和质保政策等信息；联网后可以获取当期车型和限时价格，并为回答附上较多参考来源。不过，部分回答混淆了年款或配置口径，例如小鹏 P7+ 和小鹏 G7 的车身长度使用了其他版本数据，来源列表中还出现了与推荐车型无关的链接。

界面与交互： 深度思考过程以可折叠内容展示，联网搜索过程可见，Markdown 表格、分节标题和来源列表的排版较清晰，适合连续追问和长内容阅读。但本次接入方式依托 IDE 的自定义模型配置，操作门槛高于面向普通用户的网页或移动端聊天产品。

功能： 模型的多轮上下文保持能力较强，第三轮新增的车身尺寸、停车辅助和维保成本条件均被使用；第四轮要求“无法确认时明确标注、不要编造数据”也得到了较好执行。其不足是缺少可靠的自动纠错机制，零跑 C10 动力数据从第二轮开始持续沿用到第五轮，错误最终影响了车型比较和推荐理由；另外，一些实际可查的数据被保守地标为“未核实”。

准确度与用户体验： 价格、续航、尺寸、质保等主要信息大部分可以通过独立渠道核验，模型也会主动披露不同官网页面之间的价格差异，整体诚实度较好；但零跑 C10 的动力数据与国内官方数据明显不符，且连续多轮未被纠正，说明用户不能只依赖模型自身的核验。五轮回答结构化程度高、需求理解准确、最终建议具有可执行性，但第二、四轮内容较长，对只想快速获得结论的用户来说信息密度偏高。

（3）对产品的改进意见

1. 对车型名称、年款和配置版本建立结构化标识，回答价格、尺寸和性能参数时必须明确对应版本，避免把旧款、纯电版和增程版数据混用。
2. 增加回答后的自动核验机制：对价格、功率、续航、尺寸等关键字段重新查询或与可信数据表比对；如果同一会话中发现前后数据不一致，应主动提示并修正，而不是继续沿用旧结论。
3. 优化来源管理，删除与推荐车型无关的链接，并在每个关键参数后标注来源、发布日期和价格口径，方便用户复核。
4. 为长回答增加“先给结论、再展开依据”的摘要模式，同时保留详细表格和风险说明，满足快速浏览和深入比较两类需求。
5. 对“未核实”信息区分“暂时未找到来源”和“不同来源存在冲突”，并给出下一步核验建议，避免信息过度保守或被用户误解为不存在。

（4）采访另一个用户

采访基本信息：

项目	内容
被测产品	GLM-5.3-Flash
采访对象	软件工程专业本科学生，此前使用过 Cursor、DeepSeek，对 GLM 系列接触较少
采访形式	现场观察与问答访谈
测试任务	多轮购车推荐、动态修改筛选条件、结构化 Markdown 表格输出
采访总时长	22 分钟
测试时间	2026 年 11 月 9 日

（1）采访对象的背景与需求

受访者为软件工程专业本科学生，此前使用过 Cursor、DeepSeek 等大模型工具，但对 GLM-5.3-Flash 接触较少。选择该受访者，一方面是因为其符合计算机、软件相关专业学生的要求，能够从多轮对话、格式遵循和程序解析等技术角度评价模型；另一方面，受访者有其他大模型的使用经验，但对本次被测模型没有明显先入印象，能够提供相对客观的首次使用反馈。

受访者希望围绕购车话题进行多轮对话，在过程中不断修改预算、能源类型和主观偏好，观察模型能否持续跟踪约束变化，并按要求稳定输出对比表格。其主要期待是模型响应较快、能够记住已经修改的条件，同时担心多次修改后模型会混淆新旧约束，也不确定严格的表格格式能否保持稳定。

（2）实际使用的产品栏目

受访者全程通过对话界面完成测试，依次使用了自然语言多轮问答、购车推荐、Markdown 对比表格生成、预算和动力类型等约束的动态修改，以及严格格式输出指令。第一轮对话还触发了联网检索，模型据此获取 2026 年 11 月在售新能源车型的信息和来源。整个过程共进行五轮：

1. 第一轮提出 20 万元以内、城市通勤家用、优先安全性好的购车需求；
2. 第二轮要求整理为 Markdown 对比表格，包含车型、指导价、动力类型、续航或油耗、亮点和短板；
3. 第三轮将预算降到 14 万元以内，并只保留纯电新能源车型；
4. 第四轮增加“内饰塑料感不能太重”的主观偏好，并要求更新表格；
5. 第五轮要求严格只输出 Markdown 表格，不添加开场白和总结文字。

受访者无需额外指导即可完成第一轮需求描述和提问，基本操作能够顺利上手。

（3）使用过程中的问题与亮点

亮点（实际观察）：

• 轻量任务下响应较快，首轮约 50 秒返回，受访者认为等待时间可以接受；
• 上下文记忆较稳定，第三轮把预算从 20 万元降到 14 万元并限制为纯电后，模型没有混入燃油车和插混车，后续也持续记住“14 万元以内、纯电、内饰不能塑料感重”等条件；
• Markdown 表格生成能力较好，第二轮的表头与约定基本一致，没有出现乱码，价格还标注了区间和地区优惠差异；
• 能够区分硬性约束和主观偏好，第四轮理解了“内饰塑料感不要太重”的要求，剔除相关车型并说明理由；
• 会主动给出选购建议，对普通用户较为友好。

问题（实际观察）：

• 第五轮虽然没有添加开场白和总结文字，但自行增加了“结论”一列，没有完全按照用户预先约定的表头输出；
• “内饰塑料感重不重”属于主观判断，受访者无法直接核验模型对内饰用料和质感的描述；
• 车型价格、续航总体上较为合理，但新款车型的优惠和内饰细节可能存在偏差，不能直接视为已验证事实；
• 第四轮需要逐一评估前面全部车型并输出剔除说明和完整表格，耗时 189 秒、消耗 26391 个 token，是各轮中最慢的一轮，说明响应时间会随推理和输出规模显著增加。

观察到的困难与原因推测：

• 受访者实际观察到，严格格式指令下模型仍会自行增加表格列。原因可能是模型把用户指定的格式当成可调整建议，而不是不可变更的硬约束；这一点属于基于输出现象的推测，无法直接观察模型内部机制。
• 受访者实际观察到，主观内饰评价很难判断真假。原因可能是产品缺少与权威配置或实车资料关联的校验能力，模型只能依据已有信息生成参考性描述；这同样属于原因推测。

（4）用户体验改进建议

受访者提出了以下改进意见：

1. 提高格式遵循的严格程度，表头和输出格式确定后，不应自行增删列或添加额外内容；
2. 增强联网检索和数据核验能力，实时查询最新车价与配置，减少训练数据滞后带来的偏差；
3. 区分硬性条件与主观感受，对“内饰质感”这类结论明确标注为参考性判断，并提醒用户以线下看实车为准；
4. 面向开发场景提供严格纯净的结构化输出模式，过滤模型主动添加的说明文字和额外表格列，降低程序解析成本；
5. 对耗时较长的任务显示预计等待时间或处理进度，让用户能够理解响应变慢的原因。

采访小结：

本次采访显示，GLM-5.3-Flash 在简单任务中响应较快，对预算、动力类型等硬性条件的理解较稳定，且具备较好的多轮记忆和表格整理能力。但在严格格式输出、主观信息核验和长内容响应速度方面仍存在不足。该模型适合生成购车参考信息；如果用于正式业务或程序自动读取，仍需要增加格式校验、参数校验和来源核验模块，不能将原始输出未经处理地直接交付用户。

1.2.2 自动化测试

（1）模拟购车决策环境与统一测试条件

GLM-5.3-Flash 使用与 Qwen 完全相同的 Python 测试程序、14 款教学模拟车型、3 个场景、提示词、输出格式和评分规则。车型库为 2026-11-08-teaching-v1，价格统一按厂商指导价量级、单位万元记录。每个场景独立运行 3 次，共 9 次；加上 Qwen 的 9 次，总计 18 次完整多轮任务。场景与预期集合如下：

GLM 接入与可比性设置：

• GLM 使用与 Qwen 相同的 OpenAI 兼容客户端、会话管理和结果记录结构，接口地址默认为 https://open.bigmodel.cn/api/paas/v4/，模型标识为 glm-5.3-flash，密钥通过 .env 中的 ZHIPU_API_KEY 读取。
• GLM 请求同样使用 temperature=0.7、top_p=0.95、max_tokens=4096、180 秒超时和非流式输出，并发送 {"thinking":{"type":"enabled"}} 开启思考模式。Qwen 对应发送 {"enable_thinking":true}，两个平台都不设置额外的 reasoning_effort。
• 两个模型共享同一份 data/cars.json、system_prompt.txt、阶段模板和 JSON 输出规则。程序把每轮原文和结构化结果写入 results/raw/，同时记录模型标识、候选 ID、解析状态、token、耗时及平台参数回退信息；密钥会被清理，不进入结果文件。
• 数据集是 2026-11-08-teaching-v1 的 14 款教学模拟车型，价格为近似厂商指导价、单位万元，字段单位和来源日期固定。运行前通过 self_check.py 和场景检查脚本验证数据版本、字段完整性、能源类型、候选 ID 及提示词文件，确保 GLM 与 Qwen 使用同一测试输入。

场景	预算与使用需求	预算外硬约束	预期候选与判定
S1 城市通勤三口之家	≤16 万；每日往返 35 公里，接送一个孩子，有充电条件	纯电/插混；气囊 ≥6 个	qin-plus-dmi-2025、mona-m03-2025、song-plus-dmi-2025
S2 六口之家中途改需求	改口前 ≤28 万，改口后 ≤22 万；两孩两老，常 6 人同乘	改口前座位 ≥6、气囊 ≥8；改口后为新能源、轴距 ≥2800mm，旧两条不再判定	改口前 aito-m7-plus-2025；改口后 mona-m03-2025、han-ev-2025、su7-2025
S3 长途高速通勤	≤14 万；单程 380 公里、无充电桩、后排常坐老人	排除纯电；插混/油混/燃油；油耗 ≤5.0L	qin-plus-dmi-2025、corolla-hev-2025，候选只有 2 款不算缺陷

预期集合在运行前由 scripts/check_scenarios.py 根据固定车型库计算并冻结；S1 考基础筛选，S2 考需求变更后的上下文保持，S3 考察模型是否会为了凑数加入不合规车型。

（2）提出购车意图

程序首先输入预算、用途和硬约束，要求 GLM 返回初步理解和结构化候选结果；每次运行新建会话并重置上下文，同一次任务内连续保留对话。S1、S3 各 6 轮，S2 为 7 轮，其中第 4 轮发送需求变更。

（3）大模型给出初步推荐

程序保存 GLM 返回的候选 car_id 和每轮原文，写入 results/raw/，再与固定车型库逐项比对。脚本记录车型是否存在、是否超预算、是否违反当前有效硬约束；这些合规判断由评分脚本独立完成。

（4）输入购车要点

测试过程依次加入动力、续航、油耗、安全、空间、轴距和保值等要点。场景 2 第 4 轮把预算从 28 万改为 22 万，并用新能源和轴距约束替换原座位、气囊条件，检查 GLM 是否采纳新需求。任务彻底失败时记录 status=failed 并支持 --resume 补跑，本批次 9 次 GLM 运行均成功。

（5）性能参数表格化对比

GLM 输出候选车型的性能参数表，程序保存 rows_car_ids 和原始表格文本，评分时核验指导价、能源、功率、续航、油耗、电耗、轴距、座位数和 AEB 共 9 个字段。全量 18 次运行共检查 18 张表、42 行、378 个字段。

（6）选出目标车型

最后一轮要求 GLM 在当前候选中做出最终选择，并给出与有效约束对应的理由。随后用 scripts/append_evaluation.py 补发评测轮，不重跑前面各轮；GLM 的 9 次评测轮均解析成功，且 final_choice_id 与上一轮一致。运行汇总显示：18 次任务全部 success，总计 114 次模型调用，补发评测轮 18 次且 0 次失败，没有出现库外 car_id，最终推荐 18 次全部落在预期集合内。脚本与采集阶段总表交叉核对 18 次运行 × 3 个字段（轮数、最终推荐、解析失败轮数），未发现差异。

GLM 对应的原始记录使用 glm_S1_r1 至 glm_S3_r3 命名，字段包括 model_key、scenario_id、status、turns[]、final_choice_id、解析失败轮数和起止时间。这样可以将 GLM 的 9 次独立运行与 Qwen 的 9 次运行放在同一 runs.csv 中复核，而不会把不同模型的上下文混在一次任务里。

（7）自动化评测

本次对 GLM 使用与 Qwen 相同的评分定义，但单独计算 GLM 的结果。评分前同样固定场景 2 的需求变更规则、车型库合规集合和参数核验规则；不把平台不一致的 reasoning_tokens 直接计入得分。

指标	权重	判定标准	计算方式	样本数
A 推荐合理性/准确度	25	最终推荐满足当期预算、有效硬约束和预期集合要求	合规最终推荐数/运行数，并检查候选违规情况	GLM 9 次运行
B 多轮一致性	20	不遗忘有效约束，不恢复已失效约束，最终推荐能追溯到候选流程	候选集合 F1、约束倒退次数和评测轮一致性	GLM 9 次运行
C 指令遵循	15	JSON、stage、候选数量、对比表字段完整	逐轮结构解析和字段通过率	57 轮
D 信息真实性/防幻觉	15	car_id 存在，性能参数与车型库一致	车型编号正确率和参数字段一致率	57 轮、约 189 个字段
E 稳定性	10	同场景 3 次独立运行的结论、token 和延迟波动可接受	结论一致性及变异系数折算	3 组
F 成本与延迟	10	比较单次任务 token 总量和响应时间	相对最小值归一化折算	GLM 9 次运行
G 工具调用正确性	5	工具调用、参数、命中数和结果使用均正确	工具调用通过率	GLM 1 次演示

GLM 分项结果

模型	A 合理性 25	B 一致性 20	C 指令遵循 15	D 防幻觉 15	E 稳定性 10	F 成本 10	G 工具调用 5	总分
GLM-5.3-Flash	25.00	19.44	14.83	14.89	8.28	8.33	5.00	95.77

9 次 GLM 运行的最终推荐全部落在预期集合内，但仍出现输出截断和对比表字段错位等过程问题，具体案例在本节后文展开。

改进与方案比较

针对 GLM，优先采用“输出契约接口化”方案：使用 Function Calling 或 JSON Schema 约束字段结构，检测截断后自动续写，并把有效约束作为结构化参数传入。备选方案包括将上限提高到 8192、关闭思考模式或只调整提示词顺序；它们最多降低截断概率，不能从机制上解决约束漂移。

验证时先重放发生截断的样本，要求 JSON 解析成功率至少达到 19/20、无效约束引用为 0；然后进行 18 次全量回归，检查解析失败、错误约束引用和丢弃合规候选次数，同时保证 A 维度不低于基线。

改进方案对比表

方案	截断问题	约束漂移	是否破坏可比性	实现成本	可验证性
P1 Schema + 预算解耦 + 自动续写	能解决	能解决	不破坏，反而减少平台差异	中	强
P2 将上限提高到 8192	只能降低概率	不能解决	轻微影响	低	弱
P3 关闭思考模式	取决于平台能力	不能解决	会改变被测对象	—	弱
P4 调整提示词顺序	只能降低概率	不能解决	不破坏	极低	弱

改进方案验证判据

验证项目	当前基线	改进后判据
截断样本 JSON 解析成功率	0/1	至少 19/20
无效约束字段引用	未单独约束	0 次
截断样本单轮平均耗时	48.9 秒	不超过 60 秒
全量解析失败轮数	1/114	0/342
评测轮指认不成立次数	2 次	0 次
丢弃仍合规候选次数	2 次	不超过 1 次
A 推荐合理性平均分	24.96/25	不低于基线

P1 不能解决表格中数值跨行取数的问题，仍需在生成后依据车型库逐字段核验；也不能弥补场景难度不足或样本量较小的问题。每个场景仅重复 3 次时，稳定性结论只能说明趋势，不能进行充分的统计推断。

案例分析

1. 失败案例一：思考过程占用输出预算，结构化 JSON 在键名中间被截断。 场景 2 第 4 轮是整个任务中最关键的需求变更轮，用户把预算从 28 万调整为 22 万，同时用“新能源、轴距至少 2800 毫米”替换原来的座位数和气囊约束。GLM 在这一轮只输出到 {"stage":"update","candidate，有开始符号但没有结束符号，甚至没有完成字段名，因此程序无法解析出新的候选集合。记录显示这一轮 completion_tokens 正好达到 4096 的上限，其中 reasoning_tokens 为 3843，占比约 93.8%，留给最终正文的空间只有约 253 个 token。

   同批数据可以形成对照：glm_S2_r2 第 4 轮使用了 3930 个 completion token、3072 个 reasoning token，虽然没有截断但已经接近上限；而 qwen_S1_r2 第 3 轮的 completion token 达到 4815，却没有发生截断。两边使用的配置都写成 max_tokens=4096，但不同平台可能对“思考 token 是否计入 completion 上限”的处理方式不同。这里的接口语义差异只能作为假设，因为测试只能观察请求参数、返回 token 数和截断结果，无法直接看到平台内部的计费或预算规则。

   这个问题不是最终推荐错误，而是过程信息丢失：该轮的候选集合无法从 JSON 中恢复，最终推荐也就无法完整追溯到需求变更后的筛选结果。按照评分规则，指令遵循维度扣分，多轮一致性维度也受到影响，并成为 GLM 本批次得分最低的一次运行。这说明统一填写同一个参数名，并不一定等于两个平台拥有相同的可用正文预算。

2. 边界案例二：对比表发生跨行取数。 在场景 3 的两次独立运行中，GLM 都把卡罗拉双擎的轴距写成 2718 毫米，而车型库中的实际值是 2700 毫米。2718 毫米并不是随机生成的数字，而是同一张对比表中秦 PLUS 的轴距；与此同时，卡罗拉双擎所在行的其他 8 个字段全部正确，而且同一个错误在两次独立运行中重复出现。因此，本次将其记录为“表格字段错位”边界案例，而不是直接认定为模型编造数据。

   全量结果共检查 18 张性能参数对比表、42 行车型数据和 378 个字段，发现的字段错误只有上述 2 处，千问没有出现同类串行。该错误没有改变本次场景 3 的最终推荐，因为场景 3 的硬约束没有使用轴距；但如果把它放到场景 2 这种“轴距至少 2800 毫米”的场景中，就可能直接造成合规车型被错误排除，或者让不合规车型看起来满足硬约束。这个案例表明，结构化表格即使能够成功解析，也仍然需要根据固定车型库逐字段复核。

3. 边界案例三：评测轮重新使用已经失效的约束。 在最后的自我评估轮，GLM 曾指出某车型“因气囊数 6 个不满足气囊至少 8 个的硬约束被排除”，随后又承认“此前排除该车的旧六座约束已解除”。问题在于，场景 2 第 4 轮已经明确用新能源和轴距约束替换了旧的座位数和气囊约束，改口之后不应再用旧气囊条件排除车型。换句话说，模型知道旧六座约束已经解除，却仍然沿用了同一批已经失效的旧限制。

   类似的约束强度问题也出现在千问：它曾把“三年保值率不要跌得太狠”这一软性偏好当作排除条件，而车型库只有“保值一般”的定性备注，没有相应的量化保值率。两个现象共同说明，错误不一定表现为忘记用户要求，也可能表现为把用户提到过的所有条件都当成同等强度的硬约束。后一种错误更隐蔽，因为它会让候选集合变少，排除理由看上去也比较合理。

   【假设】这一错误也可能与评测轮提示词的问法有关——评测轮要求指出“被排除的车型中哪款其实更合适”，问法上暗示了一定存在这样一款车，模型可能为了满足格式而强行找一个理由；这只是基于输出现象的推断，无法直接观察模型内部机制。

4. 可能原因与影响： JSON 截断可能与不同平台对思考 token 和正文 token 的上限计算方式不同有关；对比表错误可能与生成表格时的行列对应、字段读取或模型注意力分配有关；约束复用问题可能与当前有效约束没有作为结构化状态持续维护有关。上述解释均属于基于外部测试现象的假设，不能当作对模型内部机制的确定性判断。它们造成的实际影响分别是输出无法解析、数据字段与车型错配，以及需求变更后出现错误排除，因此需要同时从接口层、数据校验层和约束管理层进行防护。

结论范围

• 本部分只适用于 GLM-5.3-Flash、14 款教学模拟车型、3 个场景、本次提示词、参数和评分脚本。
• GLM 每个场景只运行 3 次，共 9 次；18 次总样本适合观察趋势，但不足以进行充分的统计显著性推断。
• GLM 的总分同时受到推荐过程、结构化输出、稳定性、成本和延迟等指标影响，不能只根据总分判断模型能力。
• 工具调用演示每个模型只有 1 次，只能作为方向性证据，不能代表一般工具调用能力。

1.2.3 结论

综合评价：推荐。GLM-5.3-Flash 在本次实验的 9 次运行中最终推荐均落在预期集合内，但仍存在思考 token 挤占正文预算、输出截断和表格跨行取数问题。这个结果说明最终推荐正确并不代表每一轮过程都可靠，结论范围限于本次数据、场景、参数和 3 次重复样本。

1.3 两个模型的综合对比

1.3.1 总分与分项得分对比

两个模型均使用同一份 14 款教学模拟车型数据、同样的 3 个购车场景、相同的多轮流程和相同的评分规则。每个模型分别运行 9 次，合计完成 18 次独立任务。

模型	推荐合理性 25	多轮一致性 20	指令遵循 15	信息真实性 15	稳定性 10	成本与延迟 10	工具调用 5	总分
Qwen3.8-Max	24.92	19.09	14.81	15.00	8.02	6.63	5.00	93.46
GLM-5.3-Flash	25.00	19.44	14.83	14.89	8.28	8.33	5.00	95.77

GLM-5.3-Flash 比 Qwen3.8-Max 高 2.31 分。分差并不是由最终推荐准确度造成的：两个模型的 9 次最终推荐均落在各场景运行前冻结的预期集合内，推荐合理性得分都接近满分。主要差异来自成本与延迟、多轮一致性和稳定性，GLM 在这三个维度分别高 1.70、0.35 和 0.26 分；Qwen 在信息真实性维度高 0.11 分，指令遵循仅低 0.02 分，工具调用得分相同。

对比分项	GLM 相对 Qwen 的得分差	对总分差的贡献说明
成本与延迟	+1.70	是总分差异的主要来源，约占 2.31 分差的 73.6%
多轮一致性	+0.35	GLM 约束回溯表现略好，但仍出现失效约束复用案例
稳定性	+0.26	GLM 三次重复运行的综合波动折算分更高
推荐合理性	+0.08	两个模型都接近满分，区分度很小
指令遵循	+0.02	两个模型均能完成大部分结构化输出要求
信息真实性/防幻觉	-0.11	Qwen 的车型参数与固定数据集匹配度略高
工具调用正确性	0.00	两个模型各完成 1 次工具调用演示，样本量不足以区分能力

差值 = 未取整的维度分相减后保留两位小数，与表中两位小数的显示值可能存在 ±0.01 的取整差（如多轮一致性 19.44 − 19.09 显示为 0.35、指令遵循 14.83 − 14.81 显示为 0.02；分项差合计 2.30 与总分差 2.31 的 0.01 差异同此原因）。

1.3.2 成本、响应时间与测试效率对比

在同样的场景和重复次数下，GLM 的平均 token 消耗约为 50,084，Qwen 约为 54,400；GLM 的平均响应时间约为 175.6 秒，Qwen 约为 261.3 秒。由此可见，本次总分差异主要反映接口响应效率和成本指标，而不能解读为 GLM 在所有购车推荐任务中都全面优于 Qwen。

指标	Qwen3.8-Max	GLM-5.3-Flash	对比结果
平均 token 消耗	54,400	50,084	GLM 少约 4,316，约低 7.9%
平均输入 token	43,817	39,868	GLM 少约 3,949，约低 9.0%
平均输出 token（含思维链）	10,583（思维链 7,596）	10,216（思维链 6,863）	GLM 少约 367，约低 3.5%
平均响应时间	261.3 秒	175.6 秒	GLM 少约 85.7 秒，约低 32.8%
独立运行次数	9	9	测试样本数相同
最终推荐落入预期集合次数	9/9	9/9	最终推荐准确度相同

按实测 token 与官方单价推算，两个模型的单次会话成本分别约为 0.061 元（GLM-5.3-Flash）和 0.907 元（Qwen3.8-Max），约相差 15 倍；由于两边输出 token 几乎持平，这一倍数主要由输入与输出单价的倍差（15 倍与 12.9 倍）决定，而不是输出量被放大。上述金额为量级估算、未核对平台账单，思维链是否全额计入输出价属于假设，不应作为结算依据。

1.3.3 共同测试条件与差异解释

两个模型使用相同的车型数据、场景、提示词、输出字段、评分脚本和重复次数，且每次独立运行都会重置会话上下文，因此分数可以进行横向比较。但不同平台对思考 token、正文 token 和最大输出长度的处理方式可能不同，这一点不能简单通过设置相同的 max_tokens=4096 完全消除。

联网条件说明： 正式的 18 次自动化评测均不启用联网搜索，也不调用外部实时车型数据库。两个模型只接收并使用版本为 2026-11-08-teaching-v1 的本地固定车型数据 data/cars.json，因此价格、续航、功率、轴距等信息均属于教学模拟数据，不代表实时市场数据。模型如果在回答中自行引用外部车型参数，不纳入正式数据依据，并由程序根据固定车型库重新核验。工具调用演示使用的是预先定义的本地车型查询工具，不涉及互联网检索。这样可以避免把外部数据获取差异误判为模型推理能力差异。

本次最典型的差异是：GLM 在场景 2 第 4 轮出现 JSON 截断，而 Qwen 在对应的运行中没有出现同样的截断；另一方面，GLM 在成本与延迟方面表现更好，Qwen 的车型参数防幻觉得分更高。上述现象只能说明本次具体实验设置下的表现，不足以推导模型的行业排名。

1.3.4 可视化、量化结论与创新设计

（1）数据来源与作图口径

可视化使用以下三类评测结果文件：

文件	内容	用途
results/scoring/dimension_scores.csv	两个模型按七个维度归一化到 0—100 的得分	绘制七维雷达图
results/scoring/model_summary.csv	两个模型的总分和各维原始权重分	绘制总分柱状图和分差图
results/scoring/run_scores.csv	18 次独立运行的逐次得分、token 和延迟	绘制运行分布图和成本—延迟图

为保持图表与评分结果一致，采用以下口径：

1. 成本只统计 total_tokens。两个平台对 reasoning_tokens 的返回口径不一致，且部分记录可能为空，因此不将其用于成本图和成本评分。
2. 延迟统一使用秒，取一次完整任务中各轮 latency_ms_sum 的总和，不使用单轮耗时，避免多轮任务被低估。
3. 七个维度的满分不同，雷达图使用“维度得分 ÷ 该维满分 × 100”进行归一化，仅用于同图比较；总分仍使用原始权重直接相加，不使用归一化分数替代原始分。

（2）四张结果图

图 1：七个维度的归一化得分对比

图中横轴为七个评测维度，刻度为维度得分除以该维满分后乘以 100，单位为分。径向范围取 60—100 是为了放大两个模型之间的细微差异，不表示模型实际得分低于 60。A—F 维度使用每个模型 9 次运行的数据，G 维度使用每个模型 1 次工具调用演示的数据。

本图需要特别说明两点：第一，A 推荐合理性维度几乎没有区分度，两个模型归一化后分别为 100.0 和 99.7，原因是三个场景对两个模型都相对简单，18 次运行的最终推荐全部落在开跑前冻结的合规集合内；第二，G 工具调用维度每个模型只有 1 次演示，两个模型都是 5.00 分，只能作为定性证据，不能据此判断一般工具调用能力。

从雷达图看，两个模型在推荐合理性、多轮一致性、指令遵循、信息真实性和工具调用等维度基本重合，最明显的差异集中在成本与延迟维度。换言之，本次实验中模型质量维度基本打平，主要差异体现在接口响应效率和运行成本。

图 2：总分与差异分解

左图纵轴为模型总分，满分 100 分；右图表示各维度的“GLM 得分减去 Qwen 得分”，括号中的比例表示该维度分差占总分差 2.31 分的比例。GLM 总分为 95.77，Qwen 总分为 93.46。

两个模型总分相差 2.31 分，其中成本与延迟维度贡献 1.70 分，约占总分差的 73.4%。推荐合理性只相差 0.08 分，指令遵循相差约 0.02—0.03 分，工具调用得分完全相同，因此推荐质量没有形成实质差距。Qwen 唯一占优的是信息真实性/防幻觉维度，高 0.11 分，幅度较小，不能单独据此判断模型在所有参数核验任务中更强。

图 3：18 次运行逐次得分分布

纵轴为一次完整任务的合计得分，横轴为两个模型在三个场景中的六组运行，每组包含 3 次独立运行。每次运行都会重置上下文，散点表示单次得分，箱体表示中位数和四分位区间。

18 次运行的最终推荐全部合规，最低分仍为 83.3 分，说明总分差异主要来自过程质量，而不是最终答案是否选错。同一场景三次重复中，GLM 在场景 2、Qwen 在场景 1 和场景 3 各出现过 2 种不同的最终推荐，其余场景 3 次推荐一致；这些车型都属于合规集合，不能因为最终车型不同就直接判定模型不稳定。两个最低点分别是 GLM 的 glm_S2_r1，原因是需求变更轮的 JSON 被截断；以及 Qwen 的 qwen_S1_r2，原因是把“保值一般”当成硬约束并移除了合规车型。两者分别对应输出长度契约问题和约束强度理解问题。

图 4：成本与延迟

左图横轴为单次多轮任务的总 token，单位为万；纵轴为单次任务累计耗时，单位为秒；星号表示 9 次运行的均值。右侧图分别比较两个模型的平均 token 消耗和平均累计耗时。图中成本只使用 total_tokens，不使用平台口径不一致的 reasoning_tokens。

GLM 平均消耗约 5.01 万 token、耗时 175.6 秒；Qwen 平均消耗约 5.44 万 token、耗时 261.3 秒。Qwen 的 token 仅高约 8.6%，但累计耗时高约 48.8%，说明本次延迟差异明显大于输出长度差异。组内耗时变异系数最高达到 20.99%，而 token 变异系数最高为 6.78%，因此延迟还可能受到平台排队和网络环境影响，不能简单等同为模型本身不稳定。

（3）七个维度汇总表

维度	权重	单次满分	样本数	GLM-5.3-Flash	Qwen3.8-Max	差值
A 推荐合理性	25	25	18 次运行	25.00	24.92	+0.08
B 多轮一致性	20	20	18 次运行	19.44	19.09	+0.36
C 指令遵循	15	15	114 轮	14.83	14.81	约 +0.02
D 信息真实性/防幻觉	15	15	114 轮、42 行表格	14.89	15.00	−0.11
E 稳定性	10	摊入每次运行	6 组	8.28	8.02	+0.26
F 成本与延迟	10	10	18 次运行	8.33	6.63	+1.70
G 工具调用	5	5	每模型 1 次	5.00	5.00	0.00
总分	100	—	—	95.77	93.46	+2.31

归一化列仅用于雷达图：原始分除以该维满分后乘以 100。原始权重分、判定标准和计算方式以评分结果文件为准。

（4）结论范围

1. 每个模型每个场景只运行 3 次，共 18 次完整任务，样本量较小，结果用于观察趋势和定位问题，不用于统计显著性判断。
2. 车型库只有 14 款教学模拟车型，价格采用厂商指导价量级，不代表真实市场成交价，结论不能直接外推到实际购车市场。
3. 三个场景的难度不足以区分最终推荐能力，A 维度几乎没有区分度，这是测试集设计的限制，不是模型能力的充分证明。
4. 工具调用每个模型只有 1 次，G 维度只作方向性参考，不能代表模型在一般工具调用任务中的能力。
5. 稳定性指标使用工程经验阈值，成本与延迟分数采用相对折算，换一批任务后绝对分数可能变化。
6. 本次没有对推荐理由的论证质量进行完整人工评分，只检查了理由字段存在和基本长度，理由是否真正满足用户隐含需求仍需进一步人工评审。

（5）创新设计与方案优选

本次数据暴露出三个产品缺口：第一，A 维度 18 次全部合规，说明评测集难度不足，无法有效区分模型；第二，低分均出现在过程轮，最终推荐仍然正确，说明只检查最终答案会漏掉过程错误；第三，F 成本与延迟占总分差的 73.4%，说明在推荐质量相近时可以通过调度策略降低运行成本。

基于这些结果，推荐设计“约束守卫 + 成本感知路由”方案。约束守卫在每轮模型回复后、写入记录前，读取当期 active_constraints，对排除理由、软偏好升格和需求变更是否生效进行本地确定性校验。若模型使用了已经失效的约束、把软偏好当成硬约束，或者改口后仍沿用旧规则，则拒绝当前轮并重发一次，同时记录 violation。这部分由本地程序完成，不消耗额外模型 token，也不改变被测模型的提示词和参数。

在路由方面，默认使用 GLM-5.3-Flash，以利用其较低的平均耗时和 token 消耗；如果任务被标记为需要高保真参数表，或约束守卫在同一任务中连续触发至少两次，则切换到 Qwen3.8-Max 重跑。这样可以在大多数任务中保持较低成本，同时在参数逐字段对齐或模型处于能力边界时使用更适合的模型。

方案	做法	优点	缺点
R1 约束守卫 + 成本感知路由	用确定性规则拦截过程错误，默认使用 GLM，边界任务切换 Qwen	对准本次真实失败位置，成本增量小，可机器验证	需要维护约束配置和校验规则
R2 只使用 GLM	只保留 GLM，不增加校验	实现最简单、成本最低	无法拦截软约束升格和失效约束复用
R3 双模型全量投票	每次都运行两个模型，只采用一致结论	冗余度高	成本接近增加一倍，而本次最终推荐已经 18/18 正确，收益有限

选择 R1 的原因是它与问题发生的位置一致：本次低分主要发生在候选筛选、需求变更和参数对比等过程轮，而不是最终选择轮。R1 可以直接检查过程状态，同时保留两个模型在成本和参数核验方面的互补性，不会像全量双模型投票那样显著增加成本，也不会改变历史实验的可比条件。

建议先使用现有 results/raw/*.json 做离线回放：要求约束守卫能够命中 3 次低分运行中的关键错误轮，合规轮误拦截率不超过 2/114，回放后的 A—F 平均分不低于基线，token 增量不超过 8%。

此外，评测集应增加难度自适应场景，包括“车型库内无解”“预算与硬约束互相冲突”和“预算恰好卡在某车型指导价”等情况，并将 A 维通过率控制在 60%—80%。这样可以避免所有模型都轻易满分，使后续模型选型更有区分度。

1.3.5 综合结论与样本量局限

综合结论是：两个模型在购车推荐质量上基本打平，GLM-5.3-Flash 更适合作为本次系统的默认模型。

第一，推荐质量没有形成明显差距。18 次运行的最终推荐全部落在运行前冻结的合规集合内，两个模型都没有出现最终推荐违反预算或硬约束的情况。A 维度得分为 GLM 25.00、Qwen 24.92，差值只有 0.08 分，低于本次评分的有效区分能力，因此不能简单表述为“GLM 更准确”。

第二，总分差异主要来自成本与延迟。总分相差 2.31 分，其中 1.70 分来自成本与延迟；GLM 平均耗时 175.6 秒，Qwen 为 261.3 秒，GLM 约低 32.8%；GLM 平均 token 为 5.01 万，Qwen 为 5.44 万，约低 7.9%。在推荐质量相近的情况下，GLM 更适合对响应速度和调用成本敏感的场景。

第三，剩余差异只能作为趋势。GLM 在多轮一致性和稳定性上分别高 0.36 分和 0.26 分，但每个场景仅运行 3 次，不能据此断言其具有普遍优势；Qwen 在防幻觉维度高 0.11 分，说明其固定车型参数核验略好，但差距同样较小。

使用需求	推荐模型	依据
批量或在线购车推荐，重视响应速度	GLM-5.3-Flash	平均耗时 175.6 秒，低于 Qwen 的 261.3 秒
按 token 计费、重视成本	GLM-5.3-Flash	平均约 5.01 万 token，低于 Qwen 的 5.44 万
需求频繁变更的多轮场景	GLM-5.3-Flash，弱优势	多轮一致性和稳定性得分略高，但样本较小
必须逐字段对齐车型参数表	Qwen3.8-Max，弱优势	信息真实性/防幻觉得分为 15.00，略高于 GLM
使用 Function Calling 做本地车型检索	两者均可	工具调用各得 5.00，但每个模型只有 1 次演示

本次每个模型每个场景仅运行 3 次，每个模型共 9 次，全部实验共 18 次完整任务。这样的样本量可以用于发现趋势和定位边界案例，但不足以进行充分的统计显著性推断。工具调用每个模型只有 1 次演示，不能代表模型在一般工具调用任务中的稳定能力。最终排名只适用于本次固定车型数据、测试场景、提示词、参数和评分脚本，不代表两个模型在所有购车任务中的普遍排名。

1.4 代码与实验材料

代码仓库：项目主页（master）。

以下材料按类型列出，均可直接打开核对；原始记录未全部贴入正文。

材料	内容说明	链接
车型数据	14 款教学模拟车型，版本 2026-11-08-teaching-v1，含价格口径、单位与来源日期	data/cars.json
提示词	system_prompt.txt、output_rules.txt、stage_templates.json	prompts/
脱敏原始记录（逐轮原文）	18 次运行的逐轮 JSON 记录，密钥已清理	results/raw/
脱敏原始记录（运行总表）	18 行运行总表，每次运行一行	results/runs.csv
脱敏原始记录（汇总）	运行概览（Markdown / CSV）	results/overview.md / results/overview.csv
评分结果	scoring_report.md、dimension_scores.csv 等	results/scoring/
图表	雷达图、总分与差异分解图、18 次运行分布图、成本与延迟图	已在正文中使用图床 HTML 嵌入

二、第二部分：分析

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

大模型改变的不只是信息搜索速度，也降低了普通用户获得专业意见的门槛。过去用户需要向销售、教师或技术人员分别咨询，现在可以先通过对话把预算、用途、限制条件和疑问整理成可执行的问题，再带着结果进行线下决策。因此，大模型首先改变的是专业服务的可及性，而不仅是效率。

这种变化也带来了新的风险。大模型的回答语气通常较为确定，用户可能难以识别其中的错误；当用户无法判断参数、建议或推理是否可靠时，模型输出就可能被误当成最终结论。对本次购车任务而言，18 次运行的最终推荐全部满足预期集合，但错误仍出现在候选筛选、表格字段和数据版本等过程环节。这说明生成式系统不能只评价“最后选了哪款车”，还要评价“依据什么筛选、数据能否追溯、过程能否复核”。

大模型也正在改变服务业的分工。客服首问、售前答疑、报名咨询和材料初审等标准化工作适合由模型承担；需要签字、诊断、现场判断和承担责任的环节仍需要人工参与。因而更合理的定位不是完全替代专业人员，而是把模型作为第一层信息整理和决策预演工具，同时通过规则、数据和人工复核承担兜底责任。

2.2 开发时间估计

参考知识点：《构建之法》8.6 节“对工作的估计”。

本次估计对象为自建的购车决策评测系统，包括固定车型数据、双模型 API 封装、多轮流程、评分脚本、可视化和博客整理。团队按 8 人、5 天工作周期估算，总计划量为 30 人天。估计时将编码拆分为“生成、审查、联调”三部分，并把 API 等待时间与人工工作并行计算。

任务模块	预计人天	实际人天	偏差	说明
统筹、排版、发布	5	5	0	目录、内容整合和发布按计划完成
模型体验与用户采访	5	5	0	体验提纲提前确定，整理过程较为集中
环境、车型数据与 API 封装	4	2	-2	复用固定教学数据，大模型辅助生成基础框架
三场景、多轮流程与 18 次运行	4	3	-1	流程模板复用，等待接口响应期间并行核验数据
评分、失败案例与改进方案	4	3	-1	评分集合在运行前冻结，案例直接从原始记录筛选
可视化、结论与创新设计	4	3	-1	基于既有评分结果绘图，没有新增实验
第二部分分析	4	4	0	完成影响、工程、市场和产品规划分析
合计	30	25	-5	实际投入低于初始估计

实际投入低于预计的主要原因是固定数据集减少了数据采集工作，代码框架由 AI 助手辅助生成，18 次运行期间可以并行进行结果核对。由此得到的估计经验是：后续类似任务应单独预留代码审查、接口联调和异常重跑时间，不能只按“写出代码”的时间估算；同时应明确区分等待模型响应的时间和实际人工投入。

2.3 同类产品对比排名

本次比较只针对两个被测模型（GLM-5.3-Flash 与 Qwen3.8-Max），不额外引入其他产品；结论只适用于本次固定车型、提示词、3 个场景和 3 次重复运行，不代表行业整体排名。

候选模型	主要优势	主要不足	更适合的场景
GLM-5.3-Flash	单价低、响应较快、支持多模态和结构化输出	长输出时延迟上升，版本参数和格式仍需程序校验	高频对话、结构化表格、批量初筛
Qwen3.8-Max	推理能力强，支持联网、视觉理解和长程规划	单价高、单次任务耗时更长，思考 token 会增加成本	实时行情、复杂计算、长文档分析

本次 18 次实验中，两个被测模型的最终推荐质量接近，总分差异主要来自成本与延迟，而不是推荐合理性（具体分数见 1.3 节）。更合理的工程选型不是只选择一个模型，而是采用路由策略：用 GLM-5.3-Flash 承担大多数结构化初筛，再把实时行情、复杂 TCO 和贷款测算交给 Qwen3.8-Max。两条链路必须共享同一份有效约束，避免同一需求在不同模型中被重复解释。

2.4 软件工程方面的建议

（1）程序层建议

两种模型都支持较长上下文、结构化输出和工具调用，因此瓶颈不只是模型能力，还在于接口是否真正启用这些能力。建议把 model_id、提示词版本、数据版本、温度、思考模式、输出上限和工具版本一起记录，作为一次实验的依赖锁；不要只记录模型名称。

• 约束即代码：硬约束（预算上限、能源类型、座位数、牌照条件）不只写成提示词里的一句话，而是写成可执行的校验函数（如 budget_check()、powertrain_check()）；模型只负责提案，程序负责裁决，不通过的提案直接打回重生成。
• 结构化契约与额度分账：输出从“提示词约定 JSON”升级为 JSON Schema 或 Function Calling，并在服务端进行字段、类型和候选 ID 校验；校验失败自动触发修复重试（最多 2 次），仍失败则降级为请求用户澄清。把 max_tokens 拆成“思考预算 + 正文预算”，给正文设下限（例如 800 tokens），并把 finish_reason == "length" 直接判为失败——本次 GLM 在场景 2 第 4 轮正文只剩约 253 个 token 的截断，靠这一条就能在接口层拦住，而不是事后读日志才发现。
• 表头即契约：用户要求的表头列名直接写入 schema 的 properties 与 required，多出的列拒收、缺少的列重试，避免模型自行增删列。
• 复合键与字段级校验：表格中的每一行必须绑定 car_id、年款和配置版本组成的复合键并注明来源，生成后与车型库做逐字段比较（本次核对 378 个字段），避免把另一行的数值复制过来；任何一处不一致都要能定位到运行、轮次、行和字段名。

（2）软件工程层建议

把提示词、车型数据和评分脚本纳入版本控制，将 18 次评测矩阵作为回归测试。每次模型、提示词或数据发生变化，都应重新运行并比较结论指标和过程指标。日志至少记录场景、轮次、模型、版本、解析状态、重试次数、输入输出 token、延迟和失败类型，便于复现。

• 回归指标分两层：结论指标（最终推荐合规率）和过程指标（候选集是否被清空、表格字段一致率、生效约束集合是否正确、是否发生截断）；只看结论会漏掉过程失效——本次多数过程问题没有影响最终结论，但年款与配置混用最终影响了“不推荐 C10”的理由。评分可引入 LLM 裁判加 20% 人工抽检，控制复核成本。
• 约束版本化：需求约束应结构化保存为 constraint_id、version、status 和 strength。需求修改时将旧约束标记为 retired 而不是从提示词中删掉（删掉后模型可能从对话历史里把它“捡回来”，GLM 案例三正是如此），将软偏好和硬约束分开；每轮只把 active 约束注入模型，并要求模型回显本轮使用的约束编号。
• 会话内参数一致性回溯：同一会话中同一个“复合键 + 字段”被多次引用时，必须来自同一条检索记录：第一次写入会话账本，之后逐值比对，不一致立即报警并把冲突摊给用户。Qwen 在第四轮主动披露零跑 C10 官网两处价格差异，说明能力已经存在，缺的是把它变成默认机制。
• 可观测性补齐：除上述日志字段外，记录 reasoning_effort 与缓存命中 token 数等影响成本和稳定性的参数；补一个跨平台归一化层，reasoning_tokens 缺失时按 completion_tokens 兜底并打标记，避免空值悄悄变成 0。

（3）商业与产品层建议

模型成本应按单次会话和日均调用量估算，而不是只看单价。对于简单问题采用快速模式，对实时行情和复杂计算采用高能力模型，并通过缓存、批量任务和路由降低成本。同时应明确数据时效、来源和免责边界，不能把参考性推荐包装成价格或金融承诺。

• 默认低成本 + 差异路由：日常会话默认走 GLM-5.3-Flash（开启缓存），把 TCO、贷款、税费等计算类子任务和实时行情检索路由给 Qwen3.8-Max，结果回填主链路；两条链路必须共享同一份 active_constraints，否则同一需求在不同模型中的解释会不一致。
• 把“会拒绝”做成产品默认行为：没有车型满足硬约束时明确输出“没有符合条件的车型”并给出放宽建议，而不是硬凑一台；Qwen 对不确定的 2026 款宋 PLUS 曾主动提示“大概率不准确、建议关注官方渠道”，说明能力存在，缺的是从“模型自觉”变成“产品默认”。
• 可量化的上线门槛：在质量指标不降的前提下，单次会话成本比全程使用高价模型下降 ≥80%；会话内参数冲突检出率 ≥9/10；改写后提示词的无效约束引用次数为 0。

2.5 BUG 存在的原因分析

本次问题不能全部归因于“模型能力不足”，更适合按失效位置分析：

现象	可能原因	工程归属	改进方向
输出 JSON 被截断	思考内容占用输出预算，接口未启用 Schema	程序层	思考与正文分预算，截断后自动修复
对比表数值跨行	多行生成时字段没有绑定车型 ID	程序层/数据层	行级绑定、字段级 diff
改口后继续使用旧约束	旧约束仍留在自然语言上下文中（主因，可观测）；评测轮提示词问法的暗示只是并列假设（见 1.2.2 案例三）	软件工程层	约束版本化，旧约束置为 retired
软偏好导致候选为空	模型没有区分 hard 和 soft	软件工程层	强度枚举与无解检测
年款或配置参数混用	检索只按车型名称，没有复合版本键	数据层	使用车型、年款、配置三元键
回答耗时明显增加	长上下文、深度思考和大规模输出叠加	商业/容量层	快速模式、缓存和模型路由
计费与 token 统计口径不一致	平台对 max_tokens 是否包含思考 token、缓存命中如何计入用量的处理不同；Qwen 有一轮 completion 4815 超过 4096 却未截断，是间接线索	商业层（单位经济性 / 账单口径）	成本统一按 total_tokens 口径核算，金额以平台账单为准；该条为【假设】，不作确定性断言

其中，GLM-5.3-Flash（大模型2）在体验中把零跑 C10 的动力写成 160kW/7.5s，而国内 2026 款纯电车型官方参数为 220kW/5.9s；该错误从第二轮持续到第五轮，并最终影响了“不推荐 C10”的理由。这说明“前后一致”不等于“事实正确”，跨轮一致性检查还必须结合外部车型库和版本信息。对于无法观察的模型内部原因，只能标为假设，不能作确定性断言。

2.6 市场概况

大模型市场可以分为模型 API、MaaS 服务、应用产品和 Agent 平台几个层次。不同报告的统计口径并不相同：MaaS 只计算模型调用服务，模型市场还可能包含解决方案和应用收入，API 与订阅收入则只计算直接付费调用。因此，来自不同报告的市场规模不能直接相加或简单比较。

（1）MaaS（模型 API）市场：2026 上半年首次破百亿

从 MaaS 看，IDC 数据显示 2026 年上半年中国 MaaS 市场规模达到 106.3 亿元，同比增长 889.4%，首次突破百亿元；同期全市场 Token 消耗量 2857.9 万亿，同比增长 432.5%。MaaS 收入占中国公有云 PaaS 市场的比例从 2025 年下半年的 5.2% 升到 2026 年上半年的 21.0%，半年时间从“云业务里的一小块”变成重要收入来源。

按模态拆，大语言模型贡献 47.0% 的 MaaS 收入，视频生成模型占 32.7%，其他模态占 20.2%；整体 MaaS 营收上火山引擎占 45.1%、阿里云占 25.2%，两家合计 70.3%，但只看大语言模型细分，阿里云以 46.6% 领先。

（2）上游大模型市场与真实用量

更上游的口径：中国 AI 大模型市场规模 2025 年为 495.39 亿元，2026 年突破 700 亿元（同比 +41.3%），预计 2030 年达 3250 亿元；高盛测算中国 AI 模型的 API 及订阅收入将从 2026 年的约 350 亿元增至 2030 年的 8790 亿元，对应日均 token 消耗从 350 万亿增至 4600 万亿，五年约 25 倍。

真实使用量也印证了这一趋势：2026 年 3 月中国日均 Token 调用量突破 140 万亿，相比 2024 年初的 1000 亿，两年增长超千倍；同期中国 AI 大模型周 Token 调用量连续三周超越美国，OpenRouter 数据显示 3 月 16—22 日全球总调用 20.4 万亿 token，中国占 7.359 万亿、36%。

（3）三个“亿”字数字的口径区分

这里出现三个“亿”字数字，容易被读成互相矛盾，需要先把口径分开：

数字	口径	说明
106.3 亿元	IDC“中国 MaaS 服务市场”	2026 年上半年，含各类模型的调用服务
495.39 亿元	“中国 AI 大模型市场”	2025 年全年，含模型、应用与解决方案
350 亿元	高盛“中国 AI 模型 API 及订阅收入”	2026 年全年，只算直接付费调用

它们不是同一层东西，是从窄到宽的三次切法——看趋势可以横向对照（都在高速增长），直接比大小会出错。

（4）Agent 市场：渗透在涨、兑现在跌

Agent 市场的增长更猛但兑现更分化。

• 中国：中国 2026 年 AI 智能体市场规模约 1558 亿元（同比 +93.7%），其中企业级 Agent 市场 2026 年约 449 亿元（同比约 +112%），2029 年有望突破 3320 亿元；企业活跃智能体数量预计从 2025 年的 200 万个增至 2027 年的 1200 万个。
• 全球：2026 年 AI Agent 市场规模约 109—116 亿美元，多家机构给出的 CAGR 落在 43%—50% 区间；Gartner 更宽的统计口径认为 2026 年 AI Agent 软件支出达 2065 亿美元。
• 渗透端也在涨：Gartner 预计到 2026 年底 40% 的企业应用会嵌入任务型智能体，而 2025 年这个比例不足 5%。
• 兑现端在跌：但反面同样明显——Gartner 预计到 2027 年底超过 40% 的 agentic AI 项目会因成本失控、价值不清或风控不足被取消；MIT NANDA 复盘 300 多个公开试点后给出“95% 的企业 GenAI 试点找不到可衡量的损益影响”；S&P Global 调查显示 2025 年 42% 的企业放弃了一部分 AI 项目。

这是一个“渗透端在涨、兑现端在跌”的剪刀差市场。

（5）价格双轨与需求结构

价格呈现明显的双轨结构：高盛把中国模型市场描述成“双层结构”，高端模型定价约 1 美元/百万 token，是低端模型的 5 倍；面向 Agent 任务的低端模型低至 0.06—0.2 美元/百万 token。我们评测的两个对象恰好各站一条轨：GLM-5.3-Flash（0.8 / 2.8 元）落在低端轨，Qwen3.8-Max（12 / 36 元）落在高端轨。

需求结构也在迁移：同一份编码任务，Agent 自动化工作流平均消耗 417 万 token，普通代码问答只有 3390 token，相差超过 1000 倍——当单次任务从“一问一答”变成“多轮调用”时，成本差异被放大。

（6）用户结构：直接用户与潜在用户

• 直接用户（已经在付费调 API 的人）以开发者与中小企业为主：智谱披露其机构客户超过 1.2 万家，产品覆盖 218 个国家和地区，与超过 400 万中小企业及开发者共建生态；2026 年上半年其开放平台及 API 收入 8.25 亿元，同比增长约 27 倍，占总营收的 86.5%。
• 潜在用户方面，以购车场景为例：乘联分会统计 2025 年全国狭义乘用车零售 2374.4 万辆（同比 +3.8%），其中新能源乘用车 1280.9 万辆（+17.6%，零售渗透率 54%），并预计 2026 年与 2025 年基本持平——每年有约 2400 万个购车决策发生，这部分人今天大多还在用免费对话框凑合，缺的不是模型，而是“带约束校验和对比表的产品”。
• B 端潜在用户则包括经销商集团的售前工具、汽车垂媒的选车助手、保险与金融的车贷测算工具。

2.7 产品规划

拟设计的产品为“车参谋”：一个先收集约束、再生成可比方案、最后明确说明数据来源和不确定性的购车决策助手。

（1）Need：需求

购车属于低频、高金额、信息不对称的决策。用户往往无法一次说完整需求，也很难判断车型参数、优惠价格和主观评价是否可靠。产品需要帮助用户把模糊需求转成约束，生成统一口径的对比表，并在没有合规车型时明确拒答，而不是为了完成回答强行推荐。

（2）Approach：做法

采用“模型提案、程序裁决、数据兜底”的三段式架构：

1. 通过多轮反问收集预算、能源、座位、充电条件和使用半径，并写入结构化约束；
2. 使用规则引擎校验预算、能源类型、座位数和续航等硬条件，模型不能推翻程序裁决；
3. 让模型只在合规候选中排序和生成解释，输出使用 JSON Schema；
4. 将实时行情、TCO、贷款和税费计算路由给适合的模型或工具；
5. 所有参数绑定车型、年款、配置和来源，重复出现时进行会话内一致性比对；
6. 没有符合条件的车型时，输出无解原因，并给出放宽哪条约束可以得到候选的建议。

（3）Benefit：收益

对用户，产品可以减少搜索和筛选时间，提供能带到线下谈判的对比表，并让每个结论有来源。对汽车垂媒和经销商，产品可以提供可嵌入、可审计的选车 API。对工程实践，约束即代码、结构化契约和评测即回归也可以迁移到保险、装修报价和课程规划等推荐场景。

（4）Competitors：竞争

通用大模型入口强、语言能力好，但缺少车型库和约束校验；汽车垂媒数据丰富，但主要是筛选器，用户仍需自己比较；4S 店掌握真实成交价，但存在品牌和利益偏向；电商选车工具交互简单，却难以处理复杂约束。车参谋的差异点应放在约束可校验、数据可溯源、无解能拒答和多模型路由，而不是单纯追求“更会聊天”。

（5）Delivery：交付与推广

• MVP： 支持 30 款车型、3 个典型场景、对比表、基础 TCO 和无解提示；
• V1： 增加报价单图片识别、实时行情、报告导出和 18 次回归矩阵；
• V2： 向汽车垂媒和经销商开放 API，加入城市补贴和用户反馈闭环；
• 推广： 先在校园和车友社群试用，再通过实测内容展示成功案例和失败案例，建立用户对数据来源和风险提示的信任。

验收指标包括：最终推荐合规率 100%、无解场景正确拒答率不低于 90%、输出截断率为 0、对比表字段一致率 100%、失效约束命中次数为 0、表头符合率 100%、版本错配率为 0，以及同版本回归测试总分漂移小于 5%。

（6）风险与边界

产品不做一键下单、不直接承诺成交价格、不提供无依据的金融建议，也不将开放式闲聊作为核心卖点。输出应带数据来源、版本和时效说明；对于内饰质感、保值率等主观内容，应明确标记为参考性判断，并建议用户线下核验。