NOA产品诊断｜从真实道路体验到产品优化优先级
这不是一次“开车打分”，而是把用户对智驾好不好用的模糊体验，转化为场景、指标、执行记录、Bad Case和产品决策。
客户真正要回答的，不是谁分数最高
项目需要评估千里浩瀚H3、H5、H7三套不同能力梯度的智驾方案。真正的业务问题是：它们与同级竞品相比处于什么位置，差距发生在哪些真实场景，应该优先解决什么，以及哪些稳定优势能够转化为用户定位和营销表达。
竞争位置
按入门、主流家庭和旗舰能力梯度选择Benchmark，而不是放进同一排行榜。
体验差距
定位安全、效率、舒适和功能完整度损失发生在哪些真实场景。
产品动作
把问题转成修复优先级、产品优化方向和可验证的用户价值。
我的角色与项目边界
我参与实车评测执行、原始事件记录、数据整理、竞品对比和报告分析，重点是把主观驾乘体验转成可比较的行为证据和产品结论。
实车执行
依据统一路线和记录口径观察接管、变道、避障、通行与泊车事件。
数据整理
将事件日志转成成功率、接管频率、平均速度、用时等可比较指标。
分析交付
结合竞品行为聚类Bad Case，形成产品问题假设、优先级和报告结论。
项目整体覆盖8款车型、47个测试场景和112项指标。以上数字用于说明团队项目规模，不将全部体系设计包装为个人独立产出。
从真实道路场景建立评价体系
团队先明确要验证的能力，再寻找能够触发这些能力的路线和车位。场景由功能、道路结构、交通参与者、自车状态和环境条件共同组成；指标围绕三个核心用户体验维度，并辅以可靠性和HMI观察。
安全
接管、避障、会车、行人横穿、Cut-in及风险提示是否可靠。
效率
平均速度、完成时间、主动变道、等待和决策是否过度保守。
舒适
急加减速、制动时机、转向动作和泊车过程是否自然平顺。
按能力梯度选择同级竞品，保证比较对象具有产品意义。
高速／城区／泊车 → 道路结构 → 交通参与者 → 特殊环境。
固定路线、固定驾驶人员、统一记录口径与双机位录像，尽量控制比较变量。
先记录车辆行为、事件条件与接管原因，再由原始事件计算指标。
一条Bad Case如何变成产品建议
以下以H5城区通行效率为例，展示从观察到产品动作的完整证据链。它的价值不在某个孤立分数，而在于解释用户为什么会感到“系统开得偏保守”。
城区跟随慢车时，系统较少主动超车，部分路段长时间保持低速。
报告记录H5方案城区测试用时约168分钟、平均速度约17km/h；对比车型约155分钟、18km/h。
报告进一步观察到，H5方案触发主动超车所需的前车速度差更大，竞品更早进入超车判断。
行为证据指向“主动超车触发策略偏保守”。没有内部日志，因此不直接断言规划算法或感知模型故障。
在不突破安全约束的前提下，重新校准跟车与超车触发条件，并在相同城区慢车场景中专项回归。
该问题影响高频通行效率，但低于避障、接管等安全红线，应在P0安全问题之后进入主链路体验优化。
三套方案处于不同产品阶段
| 方案 | 产品判断 | 主要差距 | 优先方向 |
|---|---|---|---|
| H3 | 基础功能可用，但用户信任尚未稳定建立 | 汇入、避障制动、主动超车等主链路 | 先解决安全与可靠性，再优化效率和舒适 |
| H5 | 场景覆盖更完整，但策略表现不够均衡 | 部分安全响应不足，同时正常通行偏保守 | 安全红线优先，其次改善城区通行效率 |
| H7 | 能力上限更高，但全场景完整度尚未完全匹配旗舰定位 | 城区博弈、泊车完整度和HMI体验 | 补齐城市与泊车短板，提高旗舰体验一致性 |
产品结论来自项目报告与竞品横评。没有内部算法日志时，分析停留在可观察行为和Root Cause Hypothesis，不把相关性表述为已证明的算法因果。
从Drive Trace迁移到Agent Trace
这段经历形成的不是一套只能用于汽车的评分表，而是一种复杂系统的场景化诊断方法。后来做ChargeFlow与Agent Eval时，我把它迁移到任务、工具和权限链路中。
智驾产品评测
Scenario → Metric → Drive Trace → Bad Case → Root Cause Hypothesis → Product Optimization
Agent产品评测
Task → Metric → Agent Trace → Bad Case → Root Cause → Regression
能力迁移边界：智驾关注道路安全、控制和人机共驾；Agent关注意图、上下文、工具、权限和恢复。可以迁移的是场景设计、过程观测、Bad Case归因和回归思想，而不是直接照搬指标。
附录证据｜完整测评报告
完整报告用于核验项目范围、路线、场景、指标和竞品结论。招聘方无需先阅读全文，本案例页已提炼与AI产品岗位最相关的产品方法。
打开《2025年吉利汽车NOA智驾测评项目报告》 ↗