1. 自动驾驶产品经理的"需求炼金术"是什么？

我第一次听到"需求炼金术"这个概念时，脑海里浮现的是中世纪炼金术士在实验室里将普通金属转化为黄金的画面。作为从业多年的自动驾驶产品经理，我深刻理解这个比喻的精妙之处——我们确实每天都在进行类似的"转化"工作。

自动驾驶产品经理面对的原材料往往是一堆"粗糙矿石"：模糊的法规条文、零散的竞品信息、碎片化的用户反馈。我们的核心任务就是把这些原始材料"提纯"成可执行的产品需求。这个过程就像炼金术一样，需要特定的"配方"和"工艺"。

举个例子，去年我们在开发"城区领航辅助"功能时，最初拿到的只是交通部一份20多页的技术规范文件。里面充斥着"应确保系统安全可靠"、"需具备适当的人机交互机制"这类抽象表述。经过两周的"炼金"过程，我们最终输出了一份包含87个具体需求项的文档，精确到每个交互提示的显示时长和声音频率。

2. 法规解读：从条文到checklist的转化

2.1 法规收集与筛选

法规解读是需求炼金的第一步，也是最容易被低估的环节。我习惯把这项工作比作烹饪前的食材准备——如果连最基本的食品安全标准都不清楚，再好的厨艺也做不出合规的菜品。

在实际操作中，我建立了自己的法规追踪体系：

• 国内法规库：定期检查工信部、交通部官网更新
• 国际标准：ISO 21434网络安全标准、UN R79转向系统法规等
• 地方政策：特别是自动驾驶测试示范区的特殊规定

去年在深圳某项目上，我们就因为漏看了当地对自动驾驶车辆夜间测试的特殊照明要求，导致原型车无法上路测试。这个教训让我养成了用Excel建立法规矩阵表的习惯，按地区、法规类型、生效时间等多维度管理。

2.2 法规的工程化拆解

拿到法规文本后，真正的挑战才开始。我总结了一套"三步拆解法"：

1. 关键词提取：标出所有含"应"、"不得"、"必须"等强制性表述的条款
2. 需求映射：将每条法规对应到具体功能模块。比如"系统应具备驾驶员监控能力"对应DMS模块
3. 验证标准：为每个需求制定可量化的验证方法。例如"监控间隔不超过1秒"

最近在处理欧盟新出台的GSR法规时，我们就用这个方法将200多页的文档转化成了包含32个核心需求的checklist。特别要注意的是法规中的"灰色地带"，比如"适当的预警时间"这类模糊表述，需要结合行业惯例给出具体定义。

3. 竞品对标：超越简单的功能对比

3.1 建立多维对标体系

很多新人产品经理容易陷入"功能清单对比"的误区。我早期做过一个竞品分析，简单罗列了各家的ACC、LCC等功能配置，结果被CTO反问："这些信息官网上都有，你的价值在哪里？"

现在我的对标报告会包含五个维度：

1. 硬件配置：传感器方案、计算平台算力
2. 场景覆盖：各功能支持的ODD范围
3. 交互设计：提示方式、频率、强度
4. 性能参数：跟车距离、变道成功率等
5. 用户评价：各大平台的车主真实反馈

去年分析某竞品的自动泊车功能时，我们不仅测试了标准车位的识别速度，还专门找了斜列车位、立柱车位等边缘场景。最终发现他们在软件算法上做了特殊优化，这个发现直接影响了我们下一代产品的研发方向。

3.2 竞品数据库的建立与维护

我带领团队搭建的竞品知识库现在已经成为公司的重要资产。这个库包含：

• 功能参数表：超过200个量化指标
• 场景视频库：按功能分类的实测视频
• 用户评价分析：语义分析后的关键词云
• 技术路线图：各厂商的演进路径预测

维护这个库最关键的是建立标准化采集流程。我们为每个测试场景设计了固定的记录模板，包括环境参数、测试动线、数据采集点等。新同事经过两周培训就能产出符合要求的报告。

4. 用户需求挖掘：从"想要"到"需要"

4.1 突破用户表达的局限性

用户调研中最常遇到的困境是：用户说的不一定是他们真正需要的。有个经典案例是，早期调研时很多用户表示想要"完全不用接管"的自动驾驶，但深入访谈后发现，他们实际需要的是"明确知道何时需要接管"的安全感。

我们开发了一套需求转化框架：

1. 原始陈述："变道时太吓人了"
2. 真实诉求：需要更平顺的变道体验和更早的变道意图提示
3. 工程需求：横向加速度控制在0.2g以内，提前3秒显示变道路径

在最近一次调研中，我们采用"情景再现"法：让用户在模拟器中体验不同交互方案，同时用眼动仪追踪注意力变化。这种方法帮我们发现了传统问卷调研无法捕捉的细节。

4.2 需求优先级量化模型

面对海量用户反馈，我开发了一个需求优先级评分模型，考虑四个维度：

1. 用户价值：影响多少用户？使用频率？
2. 技术可行性：现有架构能否支持？
3. 商业价值：对品牌溢价、销量的影响
4. 法规符合性：是否涉及强制要求？

每个维度按1-5分打分，通过加权计算得出优先级。这个模型帮助我们在一堆"紧急"需求中识别出真正重要的功能，比如将"雨天场景下的传感器清洁"从P2调整到P0。

5. 产品需求输出：精确到比特的沟通

5.1 PRD文档的模块化设计

好的产品需求文档应该像乐高积木一样模块化。我的PRD模板包含以下核心模块：

• 功能概述：用一句话定义功能本质
• 状态机图：所有功能状态的转换逻辑
• 交互时序：精确到毫秒的提示时序
• 异常处理：所有已知异常场景的应对策略
• 性能指标：量化到具体数值的要求

以自动变道功能为例，我们会定义：

• 转向灯激活时机（变道前1.2±0.3秒）
• 横向加速度曲线（正弦波，峰值0.15g）
• 取消操作的力反馈阈值（方向盘扭矩＞3Nm）

5.2 跨部门协作的适配输出

给不同部门的文档需要"量体裁衣"：

• 系统团队：需要详细的信号逻辑和状态机
• HMI团队：关注交互时序和视觉效果
• 测试团队：需要可验证的验收标准
• 法务团队：关注合规性证据链

我习惯在PRD基础上生成多个派生文档。比如为HMI团队准备的交互流程图会用不同颜色区分正常流和异常流，为测试团队准备的验证用例会包含具体的测试场景描述和通过标准。

6. 需求验证：从文档到实车的闭环

6.1 虚拟验证的早期介入

在项目早期，我们就开始在仿真环境验证需求。去年开发交通灯识别功能时，我们在Prescan中构建了200多个光照条件下的路口场景，提前发现了需求文档中多个模糊点。

虚拟验证的关键是：

• 场景覆盖率：不仅要覆盖典型场景，更要关注边缘场景
• 参数敏感性：识别对性能影响最大的关键参数
• 回归测试：每次需求变更后快速验证影响范围

6.2 实车测试中的需求迭代

实车测试是检验需求的终极考场。我们建立了"测试-分析-迭代"的快速循环机制。上周的测试中就发现，原定义的"跟车距离系数"在雨天场景下需要动态调整，这个发现促使我们增加了环境感知模块的输出需求。

测试数据的分析方法也很关键。我们开发了自动化分析工具，可以快速定位问题根源。比如最近发现的变道犹豫问题，通过数据分析发现是决策模块的置信度阈值设置过高所致，而非原先怀疑的感知问题。