智能座舱Agent架构升级项目

把“让 NOMI 更智能”拆成可落地的场景配置框架

在项目初期，我们需要先弄明白三个问题：用户会说什么？用户真正想要什么？有哪些场景是值得做的？

我们结合线上用户表达数据、关键词归纳分析，以及访谈和问卷等方式，持续整理高频需求和典型表达模式，从中识别出温度舒适、氛围营造等一批高价值车内场景。

接下来，我们进一步梳理和定义了 13 个核心场景的体验目标与能力边界。对于每个场景，我们都会拆解：用户通常会怎么表达、希望系统达到什么样的策略效果、需要接入哪些 Function 能力、需要哪些 context 情境信息和 memory 记忆偏好，以及 Prompt 设计上需要注意什么。通过这一步，原本比较抽象的“让 NOMI 更智能”，被转化成一套更可落地的场景配置框架。

以温度舒适场景为例，用户一句“我好冷”并不只是触发某个固定功能，而是需要结合车内当前温度、风速状态、车外环境和用户习惯温度，综合判断是否调高空调温度、降低风速、开启座椅加热，或联动其他相关能力。

验证模型能否在复杂情境下做出合理的意图判断与工具调用

原有 One Step 链路更偏向单步策略选择，对复杂情境、多轮信息和多样化策略的支持有限。新链路我们采用量级更大的基座模型，并结合用户表达（query）、车辆情境信息（context）、用户偏好（memory）和可调用车控工具列表（tool list），完成更为智能的意图理解、推理和规划。

在这一阶段，我主要从产品侧参与新的基座模型在座舱垂域场景中的微调效果验证与评测集设计，重点关注模型在给定更多的输入信息后，是否能输出符合预期的 tool call 策略。

训练数据构建

训练数据主要分为两类：一类是面向车控通用能力的训练数据，用于保持模型基础工具调用能力；另一类是围绕核心场景沉淀的高质量垂域数据，用于强化模型在重点体验场景中的理解与决策能力。

数据构建过程中，产品侧明确结构化的要素如下：核心场景、query、context和memory变量、 tool边界。我们将多样化的上下文信息输入一个更加聪明的模型，让它推理得出合适的意图，再映射到对应的车控工具，作为一个学习的范本。

实践的过程中，用户的表达往往是模糊的，因此我们针对“表达模糊/意图模糊”分别进行了大量的特殊数据构造，进一步培养模型的泛化能力。

此外，我学会的经验是：1.单条数据质量足够高和足够接近真实场景时，效果会比大规模低质数据更好。我们可以以一条高质量数据为本体，通过同场景不同query、同query不同context等方式作为变体，来构建大量数据。2、输入的context会很影响结果，篇幅过短丢失信息、过长会无关干扰以及增加大量时延，格式最好是简单清晰的JSON格式。

评测集设计

核心评测集覆盖 300 余条典型场景样本，其中产品侧重点定义了 50+ 条 golden case，用于校准标注规则和典型样例。每条样本输入下列内容：query表达、 context情境信息、memory记忆偏好与 tool list，并且人工标注出预期的tool call答案（必选策略/可选策略/禁选策略）。

在评测时，我们重点关注模型输出与预期 tool call 策略的匹配度，并结合意图理解、策略顺序和响应时延等因素进行综合判断。评测结果主要用于模型准出对比、badcase 归因和后续数据迭代。

在具体的方案打分时，我们对「方案质量」进行打分，关注答案与预期tool call答案的匹配度，并结合「响应时延」「意图理解」「策略顺序」等因素进行硬约束。

对于智能座舱 Agent 的效果评估，模型效果仅是其中一环。真实车辆环境中，从语音输入 ASR 识别、query 分类路由、车辆实时情境context获取、云端模型推理与 tool call 下发，到车机端实际执行、GUI 展示和 TTS 播报反馈，每个环节都会影响最终用户体验。

在项目初期 POC 阶段，链路各环节都存在不稳定问题，仅用“成功/失败”无法有效定位问题来源。因此，我们逐步形成了“质量评分 + 问题归因”的评估方法：一方面通过0/0.5/1的打分方式衡量单条样本的任务完成情况，判断全链路任务成功率；另一方面进行badcase 归因，拆解为模型理解、参数调用、context / memory 获取、工具调用、车机执行、GUI 展示、NLG/TTS 播报等问题类型，从而更清晰地定位问题，快速推进模型、链路、交互等团队进行修复。

在测试集设计上，我们围绕 13 个核心场景构建实车测试样本，覆盖典型指令、模糊表达、情境依赖、记忆依赖、多意图组合和边界 case 等不同类型。每轮测试会根据当前版本的优化重点、场景成熟度和历史问题情况，选择重点验证的场景与 query；对于效果已经较稳定的场景，会降低测试频率，而对新改动场景、高风险链路和历史 badcase 进行重点复测。

测试前，我们会为样本配置对应的Prompt、所需情境记忆函数、场景候选tool list等内容。由于真实车辆环境中的 实时context会随车辆状态、座舱环境和用户设置动态变化，实车测试无法提前固定唯一的预期执行结果。因此，在测试过程中，我们会同步记录每条样本触发时的实际 context，结合 query、memory、tool call和最终链路表现进行综合标注，逐条判断实车测试的综合效果。

相比单纯的模型评测，实车评估更接近真实用户体验验证。它的重点不是预设唯一标准答案，而是在动态真实环境中记录变量、统一评分口径、判断决策合理性，并通过问题归因推动链路各模块逐步优化。

经过几个月的努力，项目共推进了 10+ 轮实车测试与 4 个关键版本迭代，全链路任务成功率由约 20% 提升至 80%+，从POC转入正式开发阶段。

AI 产品经理：以产品问题为起点，以技术理解为基线

这段长期实习让我更具体地理解了 AI 产品经理的工作边界：AI 产品经理首先仍然是产品经理，核心依然是发现真实需求、定义问题、设计解决方案，并推动产品真正落地。

在这个过程中，我系统训练了产品经理的基础能力：从竞品分析、需求拆解、PRD 撰写，到跨团队沟通、问题追踪和工程推进，都经历了比较完整的实践。很多事情不是一开始就能设计得完美，而是要先推动它跑起来，再在真实问题中持续把它做好。

但在 AI 产品中，产品经理还需要对技术有足够基础的理解。只有理解模型能力与算法的基础原理、能力边界、数据构造、评测体系等，才能更准确地判断需求是否可实现、方案如何落地、问题应该如何归因。

技术理解是一条基准线，越过这条基准线之后，产品经理仍然要回到产品本身，去判断用户真正需要什么、技术能力应该落在哪些具体场景里，以及如何把复杂能力转化成用户能感知到的稳定体验。

评估体系是推动 AI 产品迭代的重要方法

在这段实习中，我接触并参与了多种评估体系：既有面向模型能力的离线评测，也有面向真实车辆环境的实车效果评估，还包括一些专项 Agent 能力评估。它们的评估对象、样本设计和评分口径并不完全一样，但底层逻辑可以抽象为三类：指标评估、badcase 归因和回归验证。

指标评估用于判断整体效果是否达标，badcase 归因用于定位具体问题来源，回归验证则用于判断历史问题是否在新版本中真正收敛。这也让我意识到，评估本身不仅是验收手段，也是推动 AI 产品持续迭代的重要工具。尤其在输入变量复杂、没有唯一标准答案的真实场景中，产品经理需要在统一评分口径和场景化判断之间找到平衡。

Agent 的智能体验来自全链路收敛

我也更深刻地理解到，在工程场景中，Agent 的“智能”和“好用”并不只由大模型本身决定。从 ASR 识别、query 路由、context / memory 获取，到模型推理、Tool Call、车机执行、GUI 展示和 NLG / TTS 播报，每一环都会影响最终用户体验。

很多看似不直接属于模型能力的工作，例如 GUI 反馈时机、流式展示、思考过程是否外显、播报语义是否自然，也会影响用户是否觉得这个助手可靠、聪明、可用。