圈里聊起理想ONE的智能驾驶智驾有个一直绕不开的话题牵头定义这套方案的人不会写代码也不是姚班出身为什么反而是他把这套系统的框架定下来了很多人第一反应是“这不可能”觉得智能驾驶这种技术密度极高的领域没有代码功底、没有顶级算法素养凭什么说了算但把理想ONE从立项到量产的完整过程翻出来看你会发现智驾系统最难的地方从来不是某一行代码怎么写而是在无数个岔路口上谁来决定走哪条路。这篇文章我想围绕这条标题里埋着的问题把智驾“定义者”的能力模型拆开讲。会聊到理想ONE为什么选视觉为主而不是堆激光雷达、为什么把高速NOA当第一个核心战场、数据闭环和测试标定到底怎么组织以及一个不靠写代码吃饭的人凭什么能在智驾团队里拍板。无论你是智驾产品经理、软件工程师还是想转行做智能车的年轻人这篇里都有可以带走的东西。1. 智驾方案的本质是一道选择题代码只是最后一步1.1 为什么“会写代码”和“会定义智驾”是两件事先做个区分写代码是把确定的事情做出来定义智驾是在不确定的事情里找方向。你让一个程序员去实现“车道居中保持”他拿到需求后能写得井井有条——PID参数、横纵向控制、状态机切换这些都有成熟办法。但真正难的是这行代码背后一连串的问题车道线消失后车辆应该继续滑行还是立刻减速旁边大车压线挤过来系统是先躲还是先鸣笛提醒夜间逆光下的行人置信度只有70%这时候要不要触发AEB这些问题没有任何一本算法教材能给标准答案。它们涉及用户体验、安全冗余、系统边界和对人性恐惧的理解是一个典型的取舍题。我当时参与过类似系统的评审感触很深算法工程师最自然的倾向是提高触发灵敏度因为他们脑子里的指标是“多识别出一个障碍物”而真正拍板的人会追问“这个功能在一年两万公里的真实使用里会给用户带来几次惊吓”。一次误触发对系统来说只是个数据点对用户来说却是对品牌的信任崩塌。所以“会定义智驾”的人实际上是在替用户做价值排序——什么情况下宁可不做事什么情况下必须做点事。这个排序能力和会不会写代码没有太直接的关系。1.2 理想ONE的智驾方案到底是怎么拍板的理想ONE立项的时间点正是智驾方案路线最分裂的时期。一边是Mobileye的黑盒方案算法打包封装车企只能调用结果优点是省事、可靠、量产成熟另一边是英伟达平台加自研算法灵活度高但团队要能从底层写起周期和人力成本巨大。如果只看代码能力理想ONE的方案自然会倒向Mobileye全家桶但这套系统后来证明是有上限的——你没法把Mobileye盒子里的规划逻辑拆开重写每一次想要调整体验细节都要走供应商排期。这在软件定义汽车的时代几乎是致命的。所以那条标题里提到的“定义者”做了一件很关键的事把智驾系统拆成感知、融合、决策、规划、控制、交互这几个层面然后一层层判断哪些必须自研哪些可以用成熟方案。感知可以用供应商的视觉芯片方案但决策和交互必须握在自己手里因为这才是用户能感受到的“驾驶性格”。这个决策背后是这样一个逻辑一套系统的核心价值在于它最高频、最容易被用户感知的那部分体验这部分如果被别人卡脖子产品就永远慢半拍。代码能力在这个决策里当然有用但真正起决定作用的是对“什么该自研、什么该采购”的判断力。也可以拿装修来类比硬装找个靠谱施工队没问题但全屋动线、收纳规划、灯光氛围这些决定居住体验的东西必须自己拿主意。方案路线优势劣势理想ONE的选择全供应商黑盒开发快可靠体验不可控迭代受制于人部分感知采用全自研底层上限高灵活周期长风险大放弃核心自研成熟硬件量产节奏快体验可控需要极强的系统架构能力最终采用2. 场景全拆解功能定义的核心是学会做减法2.1 为什么第一个核心战场是高速NOA而不是城区智驾智驾系统能做的东西很多但每个阶段能稳稳交付的东西有限。理想ONE在功能定义阶段最聪明的一步是没有去追“城区自动驾驶”这个最性感却能见度最高的标签而是把宝押在了高速导航辅助驾驶上。这个选择不是保守而是对用户场景冷静拆解后的结果。理想ONE的目标用户很清晰家庭用户经常跑高速带全家人出行同时又是增换购用户大多家里有小孩。对这批人来说城区路况拥堵、行人电瓶车穿插、信号灯复杂系统的失控风险和社会容忍度都很低一次处理不好就可能上新闻。而高速场景边界高度清晰车道线完整、交通参与者相对规律、没有行人横穿系统能在这种环境里建立闭环体验。更重要的是家庭用户对辅助驾驶的心理预期是“稳”。城区智驾做得再炫一次意外剐蹭就足以劝退整个家庭决策链。理想ONE把高速NOA设定为第一主战场本质上是在做“用户信任曲线”的规划——先用高频、安全、体验稳定的场景建立信任再逐步扩展功能边界。这个思路对任何智驾从业者都有参考意义不是你技术能做什么就做什么而是你的目标用户现阶段敢用什么你就先把什么做好。2.2 三个不起眼但决定体验的细节AEB、变道风格、泊车功能清单定下来是第一步真正考验定义功力的是细节策略。理想ONE上有三个细节单看每个都小合起来就是这台车智驾性格的全部。第一个是AEB的触发策略。家用车最忌讳的是误触发想象一下你在高速上正常行驶前方根本没有障碍系统突然来个紧急制动后车追尾的概率反而更大。所以理想ONE的AEB定义里“宁可不触发也不能乱触发”是一个基本原则。这意味着要牺牲掉一部分极端场景下的表现——有些在测试场里能pass的case量产策略上宁可调低灵敏度也要保证不误报。决策逻辑很简单误报伤的是全体用户漏报只伤极小概率的特定用户。第二个是自动变道的决策风格。理想ONE的变道逻辑很明显不是“有机会就变”而是“有必要才变”。前方慢车堵着、旁边车道有明显空间它才会变如果变道只能带来一秒钟的收益系统会选择保持原车道。这种带点“佛系”的变道策略在追求性能指标的工程师看来可能不够激进但对家庭用户来说这种“不折腾”恰恰是最让人放心的体验。定义者要做的功课是把车辆在路上的行为与品牌人设对齐。第三个是泊车。理想ONE没有把宣传重点放在各种花哨的泊车姿势上而是把常规车位识别率、窄车位通过性、坡道泊车稳定性这些“不性感的指标”打磨扎实。这背后是一个很朴素的逻辑智驾功能对用户的价值不是“能秀”而是“敢用”。如果一个功能十次里有两次需要用户接管用户就会彻底放弃它反之哪怕功能不炫但每次都能稳稳把车停好用户就会日常依赖它。这是产品定义里最容易被低估的“可用性工程”。2.3 人机交互才是智驾定义里最见功力的地方很多团队做智驾把90%精力放在算法上最后装车才发现用户根本不知道系统什么时候能用、什么时候不能用结果产生了一堆困惑和焦虑。这恰恰是不懂代码的定义者最能发力的地方。智驾系统的人机交互核心不是画一个漂亮的中控界面而是回答三个问题系统当前在做什么系统为什么退出用户下一步该做什么理想ONE在这块有一个很典型的处理——系统进入和退出辅助驾驶时仪表盘会用清晰的视觉动效配合语音播报把“接管”这件事讲得明明白白。高速上系统判定需要用户接管时提示的紧迫程度是分级的不是一股脑地狂响警报而是根据接管时间余量调整提醒强度。这套交互逻辑听起来不复杂但背后需要定义者对真实驾驶心理有深刻理解。人从“看着系统开”到“自己接过方向盘”中间有一个注意力和手眼协调的切换过程这个过程少则一秒多则三五秒。如果交互设计师不懂这个切换成本做得再好看也是花架子。智驾定义者的价值恰恰体现在这种“看不见的体验”上。3. 从定义到量产架构、数据与测试体系怎么搭3.1 智驾软件架构的基本盘不会写代码不代表可以不懂软件架构。一个智驾系统要能稳定量产必须在一开始就把模块边界、数据流、故障处理策略定清楚。我接触过不少智驾团队发现架构混乱的项目有个通病所有模块都在一个进程里互相调用依赖关系像蜘蛛网一样改一个刹车逻辑要牵动感知、融合甚至交互谁也动不了。规范的智驾软件架构一般是分层的每一层职责清晰层与层之间通过标准接口通信。层级职责典型内容感知层识别周围环境车道线、车辆、行人、交通标志、可行驶区域融合层多传感器信息对齐视觉与雷达目标关联、时间戳同步、置信度融合决策规划层决定怎么走行为决策、轨迹规划、速度规划、避障逻辑控制层执行指令横向转向控制、纵向加减速控制、底盘协同系统监控与交互层兜底与沟通故障诊断、降级策略、HMI告警、用户接管提示这个架构里最容易被忽视的是最下面那层“系统监控与交互”。它决定了当上游某个传感器失效时车辆是直接退出辅助驾驶还是降级成自适应巡航还是保持一段时间的受控滑行。这个降级策略如果定义不清楚车辆可能会在最糟糕的时机突然“撒手”后果非常严重。所以那些真正能定义智驾的人虽然不亲自敲代码但必须能看懂这张架构图并且能在一场评审会上指出“你这个接口设计感知延迟一高下游规划跟不跟得上”这类关键问题。这种能力来自对系统整体运行逻辑的理解而不是对某一种语言语法的熟悉。3.2 数据闭环与影子模式智驾迭代的发动机智驾系统不是一次性开发完就上线的而是卖出去之后才开始真正进入迭代。这里就牵出一个智驾行业的核心概念数据闭环。简单说就是车在用户手上开遇到的每一个边缘场景——极端天气、修路、事故现场、逆光、大车并行——都会被系统记录下来回传到研发端经筛选、标注、训练、验证后再通过OTA推回车里。这里有个关键策略叫“影子模式”系统在后台里“偷偷”跑一遍自己的算法但不会真正控制车辆只记录它“如果当时接管会怎么开”同时记录用户实际是怎么开的。两者一对比就能发现算法和真人驾驶的差距这些差距就是优化方向。影子模式让车队的每一公里都为系统迭代贡献力量而不是等到产品出事才被动发现问题。对于定义者来说数据闭环里最关键的决定不是模型结构而是“该采集什么数据、该定哪些指标”。如果光盯着“百公里接管次数”这个单一指标团队很容易把算法调得过于保守动不动就退出辅助驾驶接管次数确实少了但用户体验反而更差。所以理想ONE这类系统的定义层关注的是一组复合指标功能使用率、主动退出率、系统退出后用户反应时间、紧急介入频率甚至还包括用户长时间不碰方向盘时系统的提醒次数。这些指标组合起来才能还原出真实体验的全貌。3.3 测试标定量产前的百万公里验证是怎么组织的再好的定义最终都要靠测试体系来兜底。智驾测试分好几个层级每一层解决不同的问题。第一层是软件在环纯靠模拟器跑算法逻辑第二层是硬件在环把真实传感器和控制器接进来,模拟各种极限场景第三层是封闭场地测试专门复现危险场景第四层是开放道路路试在真实交通里累计里程。测试层级验证对象典型指标软件在环算法逻辑场景通过率、运行时间、内存占用硬件在环传感器融合、控制器延迟、时序一致性、故障注入响应封闭场地极端场景AEB触发距离、泊车成功率、稳定性开放道路整体体验接管次数、变道成功率、用户投诉率测试管理这件事恰恰是不写代码的人可以做到极致的一环。因为测试的核心不是写脚本而是设计“什么场景必须测”“通过标准是什么”“失败了是改代码还是改需求”。一个优秀的智驾定义者会要求团队把每个功能都配套一张详尽的验收矩阵比如“自动变道功能在雨天、夜间、拥堵路况下分别需要达到什么样的成功率”然后每周盯测试报告哪个指标没达标就拉相关团队复盘。标定也是同理。传感器的安装角度、AEB的触发阈值、变道的安全距离这些参数都决定了最终的驾驶风格。标定工程师能调出一版技术上无懈可击的参数但调不出“像真人司机那样开车”的感觉。唯一能把“感觉”讲清楚的就是那个每天都在思考用户会怎么开车的定义者。4. 不会写代码的人凭什么定义智驾4.1 把用户场景翻译成技术需求的能力智驾行业非常缺一种人能同时听懂“用户抱怨”和“工程师诉苦”的人。用户说“这车在高速上老是自己乱变道我害怕”工程师听到的是一堆技术可能性——是感知目标跳变是规划权重问题还是交互反馈不足普通人很难在这两者之间搭一座桥而智驾定义者恰恰就是这座桥。这种能力的本质是场景抽象化。假设你要定义“高速大车并行”这个场景不能只说“让系统离大车远一点”而是要拆成一个矩阵大车在左侧还是右侧、相对速度是快还是慢、旁边车道是否空闲、当前车速是多少、用户有没有打转向灯意图。每一个条件组合都应该有明确的系统响应。能把这个矩阵画出来的人即使不写一行代码也已经在定义这套系统的灵魂了。我见过很多团队做功能评审产品经理一上来就讲“我们要做一个更智能的变道”工程师问“多智能算更智能”产品经理答不上来。而真正的定义者会说“当车速高于80、系统判定前车慢于设定速度超过15%、且相邻车道后方无来车时自动发起变道。”这句话不需要任何代码基础但它已经是一个可以开发的PRD了。这就是定义能力的具象表现。4.2 用工程语言把各职能团队拧成一股绳智驾团队可能是汽车行业里职能跨度最大的团队之一有搞深度学习的算法工程师、有写嵌入式C的软件工程师、有做仿真场景的测试工程师、有画界面的交互设计师、有管底盘的车辆工程师。这帮人平时说着各自的黑话很容易互相听不懂。定义者在这中间实际上是一个翻译官和粘合剂。他不需要比算法专家更懂Transformer但要能在评审会上指出“这个模型在雨夜场景的回归结果为什么掉了两个点”他不需要比嵌入式工程师更懂CAN总线但要能判断“这条指令到底能不能在100毫秒内执行完”他不需要比交互设计师更懂配色但要能拍板“接管预警的动态图标必须在系统发出指令后的0.5秒内展示”。怎么做到方法很朴实先定功能清单再定验收标准然后再让各团队动手。没有验收标准就开工是智驾项目最常见的失控原因。定义者应该逼着团队把每个功能都写成“在什么条件下、系统做什么事、用户感受到什么”这三段式描述对齐了再进研发。这样看似多花了两天时间实际上省掉了后面两个月的返工。4.3 一套可复用的自研与采购判断框架最后说说“自研还是采购”这件事。这是智驾定义者最常面对、也最容易翻车的决策。我的经验是可以从四个维度来判断这个功能是否直接影响用户的日常驾驶体验。影响越大越倾向于自研。这个功能的迭代频率高不高。高频迭代的必须自研低频的可以外采。市场上有没有足够成熟的方案。有成熟方案且质量稳定没必要重复造轮子。这个功能是否容易形成差异化壁垒。如果自研做出来和供应商一样那不如直接采。按这个框架走下来理想ONE的逻辑就很清楚了感知算法在当时市场已有可用方案所以部分采用但用户直接感受的决策逻辑、变道策略、人机交互提示这些是形成产品性格的地方必须自研。这套框架不仅仅适用于智驾你做智能座舱、做自助设备、做SaaS产品都可以拿来用。核心思路是把资源集中投在用户能感受到差异化的地方其他的尽量用成熟方案摊平成本。我在实际项目里也踩过不少坑其中一条最典型为了证明团队技术实力强行自研一个市面上已有成熟方案的模块结果浪费了大半年时间最后体验还不如供应商版本。从那以后我给自己定了一条规矩——任何“自研”的立项都要先回答“用户能不能感知到这个差异”。如果答案不明确这个自研就是自嗨。5. 给普通工程师和产品经理的实操建议5.1 没有代码背景怎么快速建立智驾系统认知如果你也想走智驾定义这条路又不会写代码别慌有方法。第一步先把行业主流的智驾方案书找来看不需要看懂每一行公式但要能画出整套系统的数据流图从传感器采集到感知输出到融合到决策规划再到执行。第二步去试驾市面上所有主流智驾车型做对标笔记。同样是高速NOA有的车变道果断有的车龟速跟车你要能说出背后可能是哪些参数差异导致的。第三步找一个仿真平台哪怕只是拖拽式的场景编辑器自己搭几个典型场景比如前车切入、施工路段、雨夜行驶看系统的表现。这三步做下来你对智驾的认知不会比很多写代码的人差因为你理解了“系统行为”层面。真正决定一套智驾系统上限的不是某一个模型的精度而是系统在各种真实场景下的整体行为是否合理。而这种行为是可以不通过代码去理解和学习的。5.2 一个简单的方法论场景卡片法这里分享一个我个人觉得非常实用的工具我叫它“场景卡片法”。拿一叠卡片每张写一个用户会遇到的智驾场景比如夜间下高速匝道、暴雨天前车急刹、修路导致车道线消失、旁边大货车长时间并行。然后给每张卡片回答四个问题系统应该做什么、用户这时在干什么、用户会有什么情绪、系统应该怎么应对这个情绪。这套方法能帮助定义者把抽象需求变成具体可讨论的对象。我建议智驾产品经理每两周就更新一轮场景卡片把用户反馈、测试发现的问题、社交媒体上的吐槽都转化成新卡片。做久了你对智驾的理解会比任何一份竞对分析报告都深入。它不要求任何代码基础但对产品判断力的训练效果极好。5.3 想成为定义者先从“给结论”开始训练最后说一个扎心但真实的现象很多智驾从业者能力其实不错但从来没练过“给结论”这个基本功。评审会上算法说“这个方案可以试”测试说“这个场景还没测完”交互说“设计稿下周出”产品说“我等大家对齐”。一圈下来没人敢拍板。而定义者恰恰是那个在信息不完整时就敢说“就按这个方向走责任我来扛”的人。给你一个训练方法下一次参加任何技术评审试着在两分钟之内给出一个明确立场——支持、反对、或者需要补充什么信息才能决定。不要用“都可以”“再看看”“等数据出来再说”这类话术搪塞。你可能会说错但错了再调整的成本远低于在一个模糊的决策上反复拉扯的成本。智驾行业这么快的节奏等什么都确定了再做机会早就是别人的了。我个人的切身体会是这套系统后来被一些用户评价为“老司机风格”其实并不是团队里谁写代码特别厉害而是定义者把每个场景的边界都划到了用户能感受到的颗粒度。这件事给我最大的启发是在智能驾驶这么复杂的系统里最稀缺的不是算力不是模型参数量而是有人能站在系统之上替用户把每一段路都预先走一遍。那句“凭什么”最终的答案就藏在这里。