目录

第一部分 调研、评测

大模型 1｜智谱 GLM-4.5-Flash（glm-4.5-flash）

体验

本次在智谱 Zcode 中选择 GLM-4.5-Flash，新建任务并输入 15 万元以内的城市通勤购车需求。第二轮追加纯电和自动紧急制动（AEB）两条硬约束，第三轮要求整理对比表并选出一款车。模型最终推荐比亚迪海豚，并说明了没有优先选择埃安 Y Plus、五菱缤果等候选的原因。

优点。 左侧任务列表保留了会话入口，底部输入框可以直接追加要求。回复覆盖价格、续航、电耗、空间和安全配置，最终建议同时解释了预算、车身尺寸和通勤便利性的取舍。

不足与改进。 回复按车系列出价格和续航范围，有些 AEB 判断仍停留在车系层级。例如，模型把海豚描述为标配 AEB，但截图中的表述没有给出可逐项核对的配置来源。建议按年款和配置分别列出指导价、当地报价及 AEB 状态，给关键字段附来源，对待核实项作统一标记，并把仍满足所有硬约束的候选集中展示。

实际使用截图

图 1 智谱 Zcode 的通勤需求与初选

图 2 新增纯电和 AEB 后更新候选

图 3 请求生成车型对比表

图 4 最终推荐与车型取舍

自动化测试

2026 年 11 月 9 日调用智谱开放平台的 glm-4.5-flash。脚本未显式设置温度或思考模式，采用接口默认值。通勤、家庭出游和预算变更各完成 3 次，最终车型分别为 A、C、E。

程序为每次任务重新建立会话，在四轮内持续传递前文。下表按场景汇总该模型的 9 次正式任务。候选变化和最终车型均可从逐轮日志核对，耗时和 Token 用量按一次完整四轮任务计算。

结论

九次任务的推荐准确性、多轮一致性、指令遵循和结构化参数真实性均达标。预算变更场景中，模型连续三次用 22 万元替换原预算，并在新增七座要求后将 B 换成 E，同时保留纯电和至少 550 公里的要求。它的结构化回复可以直接用于生成车型对比表，并用固定车型库复核。

本次四轮任务平均耗时 48.57 秒，平均用量 3,244.8 Token。在已有智谱 API 接入、可以异步生成车型清单或对比表的任务中，GLM 能达到本次内容门槛。需要用户频繁追问并同步等待时，应把完整任务耗时纳入选型。

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

体验

本次在客户端选择 DeepSeek V4.1 Flash High，输入相同的 15 万元城市通勤需求。首轮按充电条件和长途需求组织建议，补充纯电和 AEB 后重新筛选。第三轮给出候选对比表，最终推荐小鹏 MONA M03 515 长续航版，并解释与秦 L EV、海豚智驾版等车型的取舍。

优点。 回复把购车预算、充电条件和安全配置转换为具体的比较项，附有参考链接。对比表覆盖价格、续航、车身尺寸、AEB 和主要优缺点。最终回复标明零跑 B10 的部分 AEB 配置信息待确认，便于后续核对。

不足与改进。 第二轮将零跑 B10/B01 合在一行并称标配 AEB，第三轮又将 B10 的全系标配状态标为待确认，容易让读者误判其是否通过硬约束。表格也需要横向滚动，截图中部分单元格直接显示了换行标签。建议按车型和版本拆行，将待确认车型移至独立分区，并把价格口径和硬约束列放在表格前部。

以上推荐和参数均为客户端回复。车型配置与当地成交价应结合相应年款配置表和报价核对。客户端采用开放式购车问答，后文的 18 次自动化测试则采用固定教学车型库与统一评分规则。

实际使用截图

图 5 DeepSeek 按通勤和充电条件给出初选

图 6 新增硬约束后的候选表

图 7 车型对比、待核实字段与最终推荐

自动化测试

2026 年 11 月 9 日调用 DeepSeek 官方 API，模型 ID 为 deepseek-flash。官方文档将该 ID 映射至 V4.1-Flash-1017。脚本未显式设置温度或思考模式，采用接口默认值。三个场景各完成 3 次，最终车型分别为 A、C、E。

程序为每次任务重新建立会话，在四轮内持续传递前文。下表按场景汇总该模型的 9 次正式任务。候选变化和最终车型均可从逐轮日志核对，耗时和 Token 用量按一次完整四轮任务计算。

结论

九次任务的推荐准确性、多轮一致性、指令遵循和结构化参数真实性均达标。以家庭出游为例，三次运行均在加入 AEB 要求后剔除 D，第三轮只为 C 制表，最后也推荐 C。这个结果说明，后续制表与推荐沿用了更新后的候选。

本次四轮任务平均耗时 5.32 秒，平均用量 2,628.3 Token，三个场景的平均耗时均低于 6 秒。在这组固定数据和官方 API 默认设置下，DeepSeek 更适合用户需要连续调整预算或配置、并尽快看到结果的交互式购车推荐。

用户访谈｜DeepSeek 的日常学习使用体验

受访者背景。 受访者是一名人工智能专业学生，平时经常使用 DeepSeek 辅助课程学习。根据访谈记录，TA 主要用它起草作业文档、润色已有内容，以及理解难题和错题，也常使用深度思考和联网搜索功能。

选择理由。 这位受访者经常用 DeepSeek 写文档、查资料和解题，能从实际操作举例。TA 提到的历史对话难找和图片文字识别错误，为访谈提供了两个具体的体验问题。

学习与使用需求。 文档任务中，TA 希望快速形成可继续修改的初稿，并把表述整理得更清楚。遇到难题或错题时，TA 需要模型准确理解题意，给出便于核对的解释。在需要查资料或补充图片时，TA 希望能结合联网搜索和图片输入补足上下文，并能找回之前的对话继续学习。

实际使用功能与亮点。 受访者表示常用深度思考和联网搜索，也会在问题较难表达时补充图片。对日常学习任务，受访者认为回答表述较专业，平时感受到的出错频率较低，并评价相关功能整体使用方便。

使用困难与应对。 受访者报告，模型偶尔误解问题，有时找不到旧对话，也遇到过图片文字识别错误。模型误解时，TA 会重写问题、补充关键词或上传图片。历史对话查找可从关键词匹配和搜索范围排查，图片识别可从清晰度和排版排查。访谈未记录当时的检索条件和上传原图，原因有待复现。

用户提出的改进。 受访者最希望改进历史对话查询和图片文字识别。结合其学习场景，产品可考虑提供按关键词和日期定位旧对话的入口，并在图片文字用于后续解答前展示识别结果，让用户先核对题干、公式或容易识别错的字符。

访谈截图 1　使用频率、学习场景与常用功能。

访谈截图 2　问题理解、历史对话查询、图片文字识别与用户建议。

评测方法与对比

评测任务从购车意图开始，经过候选推荐、需求更新和参数比较，最终给出车型及理由。两款模型使用同一套教学模拟车型数据、场景、提示词与输出要求。三个场景分别考察通勤、多人家庭出游和预算变更后的城际出行。单次任务保留四轮上下文，每次独立运行从新会话开始。

2026 年 11 月 9 日通过两家官方 API 完成 18 次独立四轮任务，每个模型在每个场景运行 3 次。两家均使用各自的默认采样参数。车型数据为教学模拟数据，价格为模拟裸车价（万元），续航为模拟工况（公里）。

统一测试条件与场景设计

两家 API 使用相同的系统提示、场景约束、车型库和 JSON 输出要求。每次任务新建消息列表，四轮共享该任务的历史消息。采样和思考模式分别采用各平台默认设置。脚本通过 API 请求模型，测试未启用联网检索或工具调用。车型库是 2026 年 11 月 9 日编制的教学模拟数据，记录年款、配置、模拟裸车价（万元）、模拟续航（公里）、座位数、动力和 AEB 状态。

自动化测试代码实现

评测脚本使用 Python 标准库。车型数据、场景和预期答案放在 benchmark.json，evaluate.py 负责调用模型、解析回复、评分和保存结果。两个模型走同一个请求函数，模型 ID 和 API 地址由配置提供。密钥由环境变量或本机私有配置读取，通过请求头传递。以下为脚本中的关键片段。

构造四轮请求并传递上下文。 每次独立任务先新建 messages，把固定车型库序列化为 JSON 放进系统消息。前两轮从场景配置读取初始意图和更新要求，后两轮复用固定的制表与最终推荐提示词。预期答案供本地评分使用，不加入发送给模型的消息。

messages = [{"role": "system", "content": SYSTEM + "\n" + json.dumps(catalog, ensure_ascii=False)}]
inputs = [
    scenario["intent"] + "\n" + PROMPTS[0],
    scenario["update"] + "\n" + PROMPTS[1],
    PROMPTS[2],
    PROMPTS[3],
]

每一轮把用户提示追加到 messages 后发送请求。收到回复后，程序把同一段回复追加为助手消息，供下一轮一并发送。因此模型生成参数表时能看到上一轮的候选，最终推荐时也能看到此前的要求、候选和参数表。外层按场景、重复序号、模型遍历，每次调用 run() 都从新的消息列表开始。正式评测中每个模型在每个场景运行三次，合计 18 次四轮任务、72 次请求。

提取候选、对比表和最终推荐。 score() 先把四轮回复分别解析为 JSON 对象，从前两轮取 candidates，从第三轮取 table，从第四轮取 choice 和 reason。随后按预设合格车型集合校验最终推荐，检查表中车型是否与更新后的候选逐一对应，并用车型 ID 回查固定数据中的价格、续航、座位、动力和 AEB。

first, update, compare, final = [decoded(turn["content"]) for turn in turns]
initial = ids(first.get("candidates"))
candidates = ids(update.get("candidates"))
table = compare.get("table")
rows = table if isinstance(table, list) and all(isinstance(row, dict) for row in table) else []
table_ids = [row.get("id") for row in rows]
choice = final.get("choice")
reason = final.get("reason")

保存逐轮证据与汇总结果。 每次任务保存为 runs.jsonl 中的一行，包含模型、场景、重复序号、逐轮提示和回复、耗时、Token 用量及评分。请求出错时，程序保留已完成的轮次和错误类型，评分字段留空。summarize() 再按模型与场景汇总尝试数、完整任务数、指标达标比例和资源用量，写入 summary.csv，供正文表格和柱状图使用。Token 数据缺失的任务不计入用量均值。

stream.write(json.dumps(record, ensure_ascii=False) + "\n")
stream.flush()
records.append(record)

可先运行 python evaluate.py --mock --out pipeline-check 验证离线流程。配置模型、地址和密钥后，使用 python evaluate.py --out results 在新的输出目录运行正式评测。完整评测代码 · 运行说明

四轮对话流程与数据保存

首轮给出购车意图并读取初选候选数组。第二轮追加或修改要求并读取更新候选。第三轮要求把更新后的候选输出为结构化参数表。第四轮提取最终车型 ID 和理由。逐轮原始 JSON 保存在同一条任务记录中，评分器从中提取候选和参数行，正文另列逐次推荐结果。

图 8　四轮购车评测流程。一次完整任务包含四轮对话，流程对 GLM-4.5-Flash 和 DeepSeek V4.1 Flash 使用同一套评测规则。

评分指标与计算口径

每个模型在每个场景有 3 次完整任务。二元指标的分母为完整任务数。用量均值采用返回完整 Token 数据的任务，本次每组均为 3 次。理由文本作为逐次结果展示，真实性自动评分核对的是结构化字段。

测试结果汇总

表 1　两款模型在三个购车场景中的评分与资源用量

四项评分和任务成功均以“达标次数 / 完整任务数”表示。耗时和 Token 均以一次完整四轮任务为单位，各组取 3 次运行的平均值。表中“参数真实”指回复中的车型参数与教学车型库一致。

两款模型在每个场景的四项评分均为 3/3。DeepSeek 在三个场景中的平均耗时和 Token 用量均较低。预算变更场景的耗时差最大，GLM 平均 54.83 秒，DeepSeek 平均 5.09 秒，相差 49.74 秒。

图 9　四轮购车任务耗时。柱高为平均值，圆点为单次运行。每个模型在每个场景运行 3 次。

图 10　四轮购车任务的 Token 用量。柱高为平均值，圆点为单次运行。每个模型在每个场景运行 3 次。

每次任务分别核对最终车型是否满足预设约束、更新候选与对比表及最终推荐是否一致、四轮输出是否遵循指令，以及结构化车型字段是否与车型库一致。四项同时达标计为成功。耗时和 Token 分别为四轮请求耗时与 API 返回的 Token 总量之和，再按场景求均值。

评测结论与量化对比

在本次固定车型库和官方 API 默认设置下，DeepSeek V4.1 Flash 更适合需要即时反馈的多轮购车推荐。选型先看内容是否合格，再比较完整任务的耗时和 Token 用量。

• 推荐准确性与多轮一致性。 两款模型均为 9/9。它们在追加 AEB 后剔除了不符合要求的车型，在预算上调并新增七座要求后切换到 E，同时保留了纯电和续航条件。三类场景中，每款模型三次运行均通过。
• 指令遵循与参数真实性。 两款模型均为 9/9。四轮都完成了候选、更新、对比表和最终理由的输出，表中结构化参数与教学车型库一致。这两项结果支持将回复接入程序自动提取和核对。
• 耗时与 Token 用量。 DeepSeek 平均每次四轮任务耗时 5.32 秒，GLM 为 48.57 秒，前者少约 89.0%。平均用量分别为 2,628.3 和 3,244.8 Token，前者少约 19.0%。对反复修改预算、座位或安全条件的用户，较短的完整任务耗时意味着更快看到更新后的候选。

三个场景的判断难点不同。 通勤场景主要检验能否在原预算下追加纯电、至少五座和 AEB 要求。两款模型都从 A、F 中保留 A，排除了没有 AEB 的 F。家庭出游场景中，C 和 D 初选时都符合 20 万元预算和七座要求，追加 AEB 后两款模型都保留了 C。预算变更场景还要求用 22 万元替换原来的 20 万元，同时保留纯电和最低续航要求。两款模型都把五座的 B 替换为七座的 E。三组结果分别说明，两款模型在本次设置下能够执行追加约束、按新条件重新筛选，并保留未被修改的要求。

三个场景都测得耗时差。 通勤、家庭出游、预算变更的平均任务耗时，GLM 分别为 43.10、47.79、54.83 秒，DeepSeek 分别为 5.73、5.14、5.09 秒。预算变更的差距最大，DeepSeek 平均少用 49.74 秒。

稳定性要分开看结果和耗时。 每个模型在每个场景的三次运行都给出相同的最终车型，且均通过四项评分，说明在这批输入下，重复执行得到了相同的选车结果。图 9 同时显示了完整任务耗时的波动。尤其在预算变更场景，GLM 的三次耗时分布较散。面向正式交互上线时，可补测更多需求和重复次数，进一步考察慢请求出现的频率。参数真实性评分的范围是车型库中的结构化字段，现实报价与具体年款配置的可核验性应通过真实车型数据另行评估。

两款模型都达到本次内容门槛，选型差异来自响应效率。每个模型在每个场景运行三次，结论限定在这组数据、提示词和接口设置下。Token 用量按 API 返回值统计，实际费用取决于各平台费率。

18 次正式运行的选车建议

每行对应一次独立四轮任务。候选变化取自前两轮，最终车型与理由取自第四轮。车型名称和参数来自本次教学模拟车型库。

边界案例与接口故障分析

18 次正式任务全部通过。以下两例分别检验新增硬约束后能否剔除原候选，以及修改一项约束时能否保留其他条件。逐轮输出均可在正式日志中按场景和运行序号复核。

边界案例 1｜家庭出游新增 AEB，低价候选必须退出

首轮要求预算不超过 20 万元、至少 7 座。教学车型 C（松原 H7 家庭版，19.4 万元）和 D（白石 G7 基础版，16.9 万元）均满足这两项。第二轮保留预算和座位要求，并新增必须配备自动紧急制动（AEB）。C 有 AEB，D 没有，因此预期只保留 C。

在正式日志中按 scenario=family、repeat=1 定位。两款模型先返回 [C, D]，追加 AEB 后改为 [C]，第三轮只为 C 制表，第四轮推荐 C。该场景每款模型 3 次均通过。D 从候选和参数表中同时消失，说明后续回复采用了新增的 AEB 条件。

边界案例 2｜预算上调后，新车型进入，原有续航要求继续生效

首轮要求预算不超过 20 万元、纯电、续航至少 550 公里，预期候选为 B（远山 E7 长续航版，18.6 万元、610 公里、5 座）。第二轮把预算上限提高到 22 万元，并新增至少 7 座。此时 B 虽然仍符合预算和续航要求，却因座位数不足退出。E（星湾 E7 家庭版，21.2 万元、570 公里、7 座）超过旧预算，但符合更新后的全部要求。

在正式日志中按 scenario=change、repeat=1 定位。两款模型都从 [B] 切换到 [E]，第三轮只列 E，第四轮按新预算、七座和原续航要求解释推荐。该场景每款模型 3 次均通过。E 进入候选体现了预算上调，B 退出体现了新增座位要求。

接口故障｜两家 API 在首轮请求阶段均未返回

首次启动的日志中，GLM 和 DeepSeek 各有 9 条记录，错误字段均为 URLError，逐轮回复列表均为空。随后对两个官方 API 域名的连通性检查均报告无法解析域名。调整运行环境的网络访问后，两家接口均返回了完整的四轮回复，18 次正式任务随后全部完成。现有证据将故障定位在首轮模型回复之前的网络访问环节。18 条失败尝试属于同一次故障，单独保留，正式评分的分母为完成的 18 次四轮任务。

正式运行逐轮记录 · 首次启动故障日志

创新设计与方案优选

首版优先采用显式约束状态、规则筛选和模型解释。预算变更案例表明，一次追问会同时修改预算、增加座位要求并保留已有条件。客户端体验中，零跑 B10 的 AEB 状态又从较确定的表述变成待确认。前者要求系统能回查条件变化，后者要求系统能区分已确认配置和待核实字段。

优选方案的创新点是把约束变化、候选变化和数据证据放在同一条记录中。例如用户把预算从 20 万元改到 22 万元并要求七座，系统回显两项改动，保留纯电和 550 公里的续航门槛。规则筛选说明 B 因五座退出，E 因满足四项条件进入。若另加 AEB 要求且某个配置缺少对应字段，系统把它列入“待核实”，并指明需查验的配置版本。

验证时，两种方案使用相同模型、车型库和场景。先复跑原有三个场景，再补测预算恰好等于车价、无合格车型和 AEB 缺失。记录硬约束违规率、无解识别率、待核实项误入率和平均任务耗时，据此判断规则筛选带来的改进及额外开销。该方案为设计建议，验证尚未执行。

方案如何处理边界情况。 一次更新先记录字段原值、新值与对应用户表述，再执行筛选。例如“预算加到 22 万，还要七座”会生成两项变更。如果用户只说“再加一点预算”，系统应先确认上限金额。若用户把 AEB 设为必需项，已确认缺少该功能的车型直接排除，配置资料缺失的车型进入待核实区。预算也采用相同原则。裸车价能直接与裸车预算比较，若用户给的是落地预算而车型库没有同口径数据，就提示补充报价再确认。三种结果分别显示已确认符合、明确不符合和待核实，让用户知道下一步应比较、排除还是补证据。

首版优先做状态和证据。 预算和 AEB 都能用结构化字段校验。显式状态把规则判定和语言解释分开，便于回查每次修改和候选增删。实现成本主要在字段定义、车型版本关联和缺失值处理。逐轮重述条件可作为低成本对照，检验规则筛选能否进一步降低误荐。

对照试验采用同一模型、同一车型库和相同输入，分别运行两种方案。以违反已知硬约束的推荐数衡量误荐，以正确识别无解和待核实的任务数衡量边界处理，再用平均完成耗时衡量交互开销。发布门槛可设为原有三个场景继续通过，新增用例不把违规车型或关键配置待核实的车型列为已确认合格。若两种方案都通过，再结合工程维护成本和用户查找排除理由的用时选择。表中预期为验收设计，尚无新增实测结果。

复现材料

完整脚本及提示词 · 车型库和场景 · 运行说明及评分口径 · 逐轮记录 · 评分汇总。上表由评分汇总整理。代码与实验材料附件收录脚本、固定车型库、评分说明、正式逐轮记录、评分表和两张对比图。密钥由环境变量或本机私有配置读取。

第二部分 分析

两款模型都通过了固定车型库的四轮测试，端到端耗时是本次选型的主要区分项。客户端体验还发现，缺少具体配置证据会使硬约束无法确认。因此，交互式场景优先考虑响应效率，产品首版优先做约束管理和配置核验。

同类产品对比与选型

对话式筛选优先选 DeepSeek。 第一部分显示，两款模型均通过 9 次任务，DeepSeek 的端到端耗时更短，适合需要连续改条件并等待结果的交互。该耗时包含网络、服务排队和生成过程，日志未分别测量这些环节。

已有智谱接入的离线任务可以沿用 GLM。 例如定时生成内部车型对比表时，可以把输出合格率、集成改动量和批处理时限放在一起衡量。GLM 在三个已测场景均通过，因此已有稳定接入、结果可以异步交付的项目有理由保留它。上线前可用实际批量任务测量完成时长和接口失败率。Token 总量用于比较用量，费用还取决于输入、输出和缓存的各项费率。

客户端给出了不同的真实车型建议。两次体验中，车型范围、报价和配置证据由回复自行组织，适合观察产品如何展示取舍和不确定性。固定数据的自动化实验则用于判断约束跟踪和结构化输出，选型依据主要来自这组可复跑结果。

三个场景分别说明什么

把这三个场景用于采购或部署决策时，可以先设内容门槛，再考虑交付时效。内容门槛包括候选符合硬约束、对比表与车型数据一致和最终理由可回查。时效门槛则由交互决定：页面等待应按实际业务测首屏和完整结果的耗时，后台任务可按一个批次能否在交付窗口内完成来判断。当前记录的是完整任务平均耗时，首屏耗时和并发吞吐需另行测量。

软件工程方面的建议

程序层。 车型以 ID 为键存取，同一任务的消息列表记录四轮上下文，规则评分用预设合格集合校验最终推荐。预算从 20 万元改为 22 万元的案例表明，状态更新需要覆盖预算字段，同时保留纯电和最低续航要求。把这些约束表示成独立字段，可以用测试直接检查每次修改的范围。

软件工程层。 车型数据、接口配置、提示词和评分规则承担不同职责。定位问题时，先核对实际请求中传入的条件和车型数据，再比对原始回复与解析结果。这样可以区分推荐本身有误、结构化解析失败和接口未返回。首次启动时两家域名均解析失败，网络可用后完成正式测试，应记录为运行环境故障。生产环境可以对暂时性网络错误做有上限的重试，并分别统计接口完成率和已完成任务的内容合格率。

商业层。 智谱的免费 Flash 型号降低了原型验证的门槛。DeepSeek 提供按量 API，计费区分输入缓存命中与未命中。对接入团队而言，原型阶段关注可用性和集成时间，正式运营则应核算单次成功任务的费用，并同时记录时延和接口失败。 智谱模型文档 · DeepSeek 计费说明

验证计划。 用同一车型库、模型和测试输入对照两个方案。加入价格恰好等于预算、降预算后无合格车型、AEB 缺失、更新座位数后需保留续航要求四类用例。分别统计硬约束违规率、无解识别率、待核实车型误入推荐的比例和平均任务耗时。先用现有三个场景回归，再运行这些新增用例。这些指标用于后续验证，目前尚未实测。

首轮回归用例与预期

以下使用教学车型 A 和 E 的参数设定测试输入，属于拟增加的验收用例。

两种方案各按同一套用例执行，记录每组分子和分母。硬约束违规率以输出了违反已知条件的推荐的任务数除以完成任务数。无解识别率以正确返回无解的次数除以预设无解用例数。待核实误入率统计证据缺失的任务中有多少次把未知项当成已确认。这样可以判断方案究竟改善了哪类问题。

BUG 存在的原因分析

配置证据不一致。 DeepSeek 客户端第二轮把零跑 B10/B01 合并为一行并写作标配 AEB，第三轮将 B10 的全系标配状态改为待确认。排查可先确认两轮是否引用同一年款和配置，以及原始资料是否支持标配判断。若 AEB 是硬约束，待核实车型应在结果中单独列出。

从现象到故障定位

市场概况

Menlo Ventures 基于约 500 名美国企业决策者的调查和市场建模，估计 2025 年企业生成式 AI 支出为 370 亿美元，约为 2024 年的 3.2 倍。其基础模型 API 支出估计为 125 亿美元，横向智能体平台约 7.5 亿美元。横向 AI 应用整体达到 84 亿美元，为上年的 5.3 倍。智能体平台是横向应用中的一个子类，5.3 倍反映的是整体增速。这里引用的是同一报告对不同层级的估计，横向智能体平台的独立同比值未见于该报告。Menlo 的年中追踪另将企业模型 API 支出从 2024 年 11 月的 35 亿美元估计至 2025 年中的 84 亿美元，约为原估计的 2.4 倍。该增幅对应这两个观测时点。 Menlo 年中模型 API 调研 Menlo Ventures 企业生成式 AI 调研

国内用户侧，CNNIC 报告显示，2025 年末中国生成式 AI 用户为 6.02 亿，同比增长 141.7%，同期网民约 11.25 亿。约 5.23 亿的差额描述的是尚未使用生成式 AI 的网民量级。要估算购车助手的潜在用户，应以计划购车且可触达的人群为起点，再按购车预算覆盖、线上比价习惯和使用意愿筛选。现有资料不足以给出该细分产品的可信人数。 CNNIC 第57次报告

对购车助手，个人用户关注预算、版本和安全配置，直接使用的是对话与车型对比页。汽车内容平台、经销商和其他有车型数据的企业可能将它作为服务模块。开发者则是模型 API 的直接集成者。企业和开发者的规模应分别通过活跃组织和活跃 API 项目衡量，公开来源未提供两家平台可比的账户数。

从行业规模推到产品机会

基础模型 API 的客户买的是可嵌入的能力，智能体平台的客户买的是可以运行的工作流。对于购车任务，企业采用一套工作流，需要接入车型数据、跟踪配置变更，并能解释某个推荐来自哪一条数据。模型推理费用只是成本之一，还要计算数据维护、异常复核和客户支持。因此，本文将车型版本核验与推荐追溯列为面向企业的首要能力。

个人端可以用“可触达渠道中的购车意向人数 × 接受线上车型比较的比例 × 愿意试用对话助手的比例”建立估算。实际测量时，可在同一渠道按月统计去重用户，并用完成首次车型比较的比例校正试用意愿。企业端则可按渠道合作组织数、具备可授权车型数据的比例、试点转正式部署的比例估算。两套漏斗分别衡量个人触达和企业部署，避免把平台账户和终端用户直接相加。

产品规划

首版功能是可编辑的购车约束清单与候选变动记录。用户在对话中修改需求后，页面同时显示当前生效的条件、车型增删的原因，以及每项判断所依据的车型版本和数据。产品先解决一个具体问题：用户能否看懂并复核一次改条件后的推荐。

N · Need｜用户在哪一步需要帮助

首批目标用户是正在缩小候选范围的购车者。他们通常已经有预算和主要用途，却会在比较过程中补充座位数、充电条件或安全配置。例如，通勤者先说预算不超过 15 万元，看到初选后才明确必须纯电且有 AEB。此时需要重新筛选，也要知道原预算是否仍然有效，以及哪一款车因哪条要求被排除。

第一部分提供了两类需求证据。固定车型库的预算变更案例中，用户上调预算并新增七座要求，原有纯电和续航条件仍须保留。这说明界面需要展示本轮修改与当前全部条件。客户端体验中，DeepSeek 对零跑 B10 的 AEB 状态由较确定的表述改为待确认。这说明关键字段还需要展示证据状态。用户面对的实际问题是如何判断一款车可以继续比较、需要询价核实，还是已经不符合要求。

首版优先服务有明确预算、至少有一条硬约束、愿意比较具体配置版本的人。对表达含糊的用户，先问影响筛选的关键问题。例如“22 万是裸车预算还是落地预算”，回答后再更新状态。这比让用户一次填完所有字段更适合逐步形成需求的过程。

A · Approach｜如何把需求变成可核对的结果

页面由对话区、约束清单和候选区组成。对话区接收自然语言。约束清单显示预算及口径、动力类型、最低续航、座位数和安全配置，每项可编辑或撤销。候选区按符合、排除、待核实分组，并显示变化原因。硬约束用于筛选，普通偏好用于在合格车型中排序。

1. 提取改动。 模型把新消息解析为新增、修改或撤销的字段。如果“预算加两万”有明确的上一轮基准，就按基准计算并显示新值。基准或口径不明确时，先请用户确认。
2. 计算候选。 程序按车型、年款和配置逐条校验。任何已知硬约束不满足即排除。全部已知条件满足但关键字段缺失时，转入待核实。可比较的价格必须采用同一口径。
3. 说明差异。 系统比较前后两轮候选，列出进入、退出和保留的车型。模型根据规则输出解释，例如“B 是五座，低于新增的七座要求”。每条解释关联相应参数和数据日期，用户可展开复核。

以本次教学数据为例，初始条件是预算不超过 20 万元、纯电、续航至少 550 公里，B 符合条件。用户输入“预算加到 22 万，还要七座”后，界面显示预算由 20 调至 22 万元、座位数新增至少 7 座，纯电和续航要求继续生效。B 因五座被移出，E 以 21.2 万元、纯电、570 公里和七座进入候选。若用户另加 AEB 要求，而 E 的对应配置字段缺失，系统将 E 标为待核实，并提示应查哪一款配置的资料。

B · Benefit｜用户为什么愿意用

修改一次，能立即复核。 用户无需回看多轮对话，就能判断系统是否只改了预算和座位数。若误将预算理解为裸车价，用户可以直接改正该字段并重新计算。这个收益可以通过“能否正确说出哪些旧条件仍生效”和“修正一个误解需要几次操作”衡量。

排除理由能指导下一步。 用户可以把车型清单带去询价，逐项核对年款、配置和价格口径。已知五座车型不符合七座需求，可以直接停止比较。AEB 待确认的车型则有一条具体的核对任务。相比一份只显示推荐车型的清单，这种信息帮助用户区分“确定不合适”和“补充证据后可能合适”。

更容易处理争议和复现推荐。 若报价更新或同一车系新增配置，团队可以根据记录回查当时使用的条件和数据，判断变化由用户需求、数据更新还是筛选规则引起。上述收益是产品目标。首版计划通过条件识别正确率、候选变化解释正确率、额外追问次数和完成用时验证。

C · Competition｜用户有哪些替代方式

首版把约束变化、候选变化和数据依据放在同一条记录里。用户用自然语言改条件，再通过结构化字段核对结果。预算变更和 AEB 核验是现有案例直接支持的需求，优先实现这两类操作。车源覆盖、实时行情和预约试驾可在筛选流程通过验证后分阶段接入。

D · Delivery｜如何交付、验收与推广

试用从已有明确预算、正在比较几款车型的人开始。给参与者同一份车型库和同一套需求，在普通聊天界面与约束清单界面分别完成任务，并交错安排界面顺序。任务包括上调预算、找出仍生效的旧条件、说明 B 被移出的原因，以及确认哪一项信息需要外部核实。对照两种界面的条件识别正确率、原因识别正确率、用时和追问次数。规则验收中，违反硬约束的车型进入“符合”区属于阻断问题，修复并通过回归后再进入下一阶段。

对个人用户，首批试用入口可以放在车型对比页，完成筛选后可导出包含配置和待核实字段的清单。对汽车内容平台，先以固定来源的车型数据验证接入成本和核对流程，再决定是否扩大车型覆盖。上述交付与试用均为产品规划，实际效果待验证。

大模型对现实生活的影响

我认为，大模型对日常生活最直接的影响，是让人更容易把模糊的需求变成可比较、可执行的下一步。购车评测和学生访谈分别展示了两种变化：购车者可以边比较边调整条件，学生可以在写作或解题卡住时继续追问。两种用法都把一部分信息整理工作交给模型，也让核对关键依据变得更重要。

消费决策：从描述需求到形成核对清单

第一次看车时，购车者往往只能说清预算和用途。比如“15 万元以内，主要在市区通勤”，已经足够让模型给出一批候选，并提示充电条件、座位和安全配置等需要进一步考虑的因素。用户看过候选后再补充“必须有自动紧急制动”，系统就能缩小范围，并说明哪些车型因此退出。这个过程让用户在比较中逐步明确需求，也减少了从头整理条件的工作。

本次教学评测的预算变更案例展示了这种交互。用户把上限从 20 万元调到 22 万元，并新增七座要求。两款模型都保留了纯电和至少 550 公里的续航条件，将候选从五座的 B 更新为七座的 E。对用户而言，解释这次变化和给出车型同样重要。知道 B 因座位数退出、E 因符合新预算和原续航要求进入，才能判断系统是否正确理解了自己的改动。

真实购车还要核对年款、配置和报价。客户端体验中，同一候选的 AEB 状态从较确定的表述变为待确认。此时可以把推荐结果转成询价清单，向经销商确认具体配置是否配备 AEB、报价是否含税费与保险、续航采用什么口径。租房和设备采购也可以采用同样的方式，先按预算和硬约束缩小范围，再核对会改变决定的条款与参数。

学习：降低起步成本，保留独立复核

访谈中的人工智能专业学生经常用 DeepSeek 起草作业文档、润色表达、查资料和理解错题。对这位学生，大模型可以在两个节点提供帮助。写作开始时，可以把零散想法整理成便于修改的提纲。解题卡住时，可以补充关键词或题目截图，请模型解释自己没有理解的那一步，再用课程材料或重新演算检查答案。

访谈也说明，学习工具的体验取决于能否延续前一次学习。受访者有时找不到旧对话，也遇到过图片文字识别错误。如果题干中的数字或符号识别有误，后续解释即使条理清楚，也可能对应另一道题。历史对话搜索能帮助学生找回复习材料，识别结果预览则能让学生在解题前确认输入。这些设计决定了模型能否从一次问答融入连续的学习过程。

软件服务：让自然语言入口接得上可核对的业务流程

大模型使用户可以直接说“预算提高两万，其他要求照旧”。要让这句话在软件里可靠执行，系统还需识别预算字段、保留其余约束、重新筛选并记录变动。以购车助手为例，模型可以理解意图和解释取舍，业务规则负责核对预算、座位数和配置，数据层保留年款、来源日期与价格口径。这样用户能在一个页面看到推荐及其依据，团队也能在结果有疑问时追查是需求理解、数据来源还是筛选规则出了问题。

评测也表明，响应速度是交互设计的一部分。在本次固定车型库和各自 API 默认设置下，两款模型都完成了各自的 9 次任务，平均四轮耗时分别为 48.57 秒和 5.32 秒。需要连续追问的页面对等待时间更敏感，后台生成对比表则可以安排异步交付。产品选型应同时检查结果是否合格、用户要等多久，以及关键判断能否追溯。

大模型把原先耗在整理资料、重填条件和组织初稿上的一部分精力，转移到比较、复核和决定上。对个人，这意味着可以更快开始一项任务并更具体地追问。对软件团队，这意味着要把模型的回复接到可检查的状态、数据和规则上，让用户看得懂结果，也知道下一步该确认什么。

团队贡献表