圈里聊起理想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 想成为定义者，先从“给结论”开始训练
最后说一个扎心但真实的现象：很多智驾从业者能力其实不错，但从来没练过“给结论”这个基本功。评审会上，算法说“这个方案可以试”，测试说“这个场景还没测完”，交互说“设计稿下周出”，产品说“我等大家对齐”。一圈下来，没人敢拍板。而定义者恰恰是那个在信息不完整时就敢说“就按这个方向走，责任我来扛”的人。
给你一个训练方法：下一次参加任何技术评审，试着在两分钟之内给出一个明确立场——支持、反对、或者需要补充什么信息才能决定。不要用“都可以”“再看看”“等数据出来再说”这类话术搪塞。你可能会说错，但错了再调整的成本，远低于在一个模糊的决策上反复拉扯的成本。智驾行业这么快的节奏，等什么都确定了再做，机会早就是别人的了。
我个人的切身体会是，这套系统后来被一些用户评价为“老司机风格”，其实并不是团队里谁写代码特别厉害，而是定义者把每个场景的边界都划到了用户能感受到的颗粒度。这件事给我最大的启发是：在智能驾驶这么复杂的系统里，最稀缺的不是算力，不是模型参数量，而是有人能站在系统之上，替用户把每一段路都预先走一遍。那句“凭什么”，最终的答案就藏在这里。
