第一次在实验室里把毫米波雷达的感知链路完整调通时，我盯着屏幕上的目标列表愣了好几秒——一个被标记为ID 3的目标，距离、速度、角度都在稳稳地刷新，而它的位置坐标在几帧之前还是一团只有我能看懂的复数频点。很多人拿到车载雷达或工业毫米波雷达的SDK时，看到的输入是ADC采回来的中频波形，输出却是带着ID和坐标的目标列表，中间那段感知链路就像一个黑盒。今天我想把这个黑盒彻底打开，从ADC采样开始，一路讲到距离FFT、多普勒FFT、CFAR检测、角度估计、点云聚类和目标跟踪，看看每个环节到底在“感知”什么、又为什么要这样做。
这篇内容更适合正在做雷达信号处理开发、调试雷达硬件或者刚接手毫米波雷达项目的工程师。不管你是写FPGA采集逻辑的、跑DSP算法的，还是只是用雷达做产品的，我都尽量讲到我自己的调试现场那个深度——包括参数怎么算、函数怎么调、坑踩在哪，而不是把公式一摆就完事。
1. 链路总览：从一段中频波形到一串目标ID
1.1 整条链路每一级到底在传什么
毫米波雷达的感知链路，说白了就是在做一件事：把电磁波碰到目标之后带回来的信息，逐级翻译成人类和下游算法能理解的语言。这条链路的起点不是天线，而是混频器之后的那一路模拟中频信号。发射波形通常是FMCW（调频连续波），频率在时间轴上线性上升，碰到目标后返回的回波和本振信号混频，得到一个频率很低的差频信号。这个差频信号的频率，正好对应着目标的距离；它的相位变化，对应着目标的速度。而ADC的任务，就是把这个模拟差频信号离散成数字样本。
整条链路的关键输出形态可以先用一张表看清楚：
| 链路阶段 | 输入 | 输出 | 核心任务 |
|---|---|---|---|
| 模拟前端 | 射频回波 | 中频差频信号 | 混频、滤波、放大 |
| ADC采样 | 中频模拟信号 | 原始复数样本 | 离散化、量化、缓冲传输 |
| 距离维FFT | 原始chirp样本 | 距离-慢时间谱 | 把频率换算成距离 |
| 多普勒维FFT | 距离谱序列 | 距离-多普勒图 | 从相位变化测速度 |
| CFAR检测 | RD谱数据 | 目标候选点 | 自适应门限找峰值 |
| 角度估计 | 多天线谱峰 | 点云（距离/速度/角度） | 测到达角，生成3D点 |
| 聚类与跟踪 | 各帧点云 | 目标轨迹列表 | 数据关联、滤波、航迹管理 |
在原始数据层面，一帧数据的大小是很容易估算的。假设每个chirp采样256个点，一帧有128个chirp，接收天线是4根，那一帧的原始复数数据就是256×128×4，约13.1万个复数。如果实部和虚部都用16bit表示，也就大约512KB。处理板卡要在一个帧周期里把这512KB数据搬进内存、做完两级FFT、CFAR、角度估计和跟踪，还要在下一帧数据到来之前输出结果。很多刚从单片机低速采集思维转过来的人，第一步就卡在这里——以为像配置STM32的ADC一样把样本存进数组就行，但实际上这套链路的实时性压力和算力约束要大得多，整条链路必须分层设计、每级优化。
1.2 分层设计才是工程师思维
感知链路最忌讳把代码写成一个大循环，从ADC数据一路算到目标列表揉在一起。因为只要某个环节出了问题，你会完全分不清是采集的锅还是CFAR的锅还是跟踪的锅。所以工程上最有效的做法是每个阶段做成独立模块，接口固定，中间用显式的数据矩阵或消息结构传递。比如距离FFT的输出是“距离-慢时间矩阵”，多普勒FFT的输出是“距离-多普勒图”，CFAR的输出是“峰值点列表”，每一级都可以单独喂入仿真数据做测试。
我自己调试的时候习惯把一个已知距离、已知速度的单目标注入到模块入口，逐级核对输出。先把一个合成chirp喂给距离FFT，看峰值是否落在预期的距离bin；再把一串慢时间信号喂给多普勒FFT，看峰值是否落在预期的速度bin；确认每一级都对，再串起来跑。这样出了问题能迅速定位到具体模块，而不是对着几百K的原始数据发呆。分层设计还有一个好处：哪一级换了算法，只要输入输出格式不变，上下游完全不用跟着改。比如CFAR从CA-CFAR换成OS-CFAR，跟踪模块完全无感。
2. ADC采样：第一步数据质量决定后面所有层
2.1 ADC在雷达链路里的独特位置
有人说雷达好不好，一半看射频前端，一半看ADC和算法，这话没毛病。ADC前面的一切都是模拟域，信号质量好坏还能靠器件性能顶一顶；ADC之后就是数字域，数字信号处理再厉害，也弥补不了量化噪声和采样失真带来的信息损失。混频器输出的中频信号，频率最高到多少，直接决定了ADC需要多高的采样率，也直接决定了雷达能看多远。
这里有一个让我早期算错过的点，值得单拎出来讲：雷达中频信号的频率和距离成正比，但ADC的最大采样率限制的是最大中频频率，所以最大不模糊距离的公式是：
Rmax = c × fs / (4 × S)
其中S是chirp斜率，B是调制带宽，Tc是chirp时长，S = B / Tc。举个例子：带宽250MHz、chirp时长40us，斜率S就是6.25×10^12 Hz/s；采样率25MSPS时，中频信号最高不能超过12.5MHz，对应的最大距离约300米。我第一次手算时少除了一个2，把最大距离翻了一倍，直到用实际波形测才发现对不上，回头看公式才知道错在哪。
在ADC选型上，常见的车载和工业毫米波雷达会用12bit到14bit的ADC，采样率在25MSPS到100MSPS这个量级。架构上，中频ADC用pipeline或者SAR的都有——pipeline适合高采样率，SAR适合中等采样率加低功耗，具体看芯片整体方案。12bit的理论信噪比大约是72dB，但实际有效位数（ENOB）往往只有10到11bit，所以别只看标称位数，更要关注ENOB，它才是链路真正能吃到的动态范围。
2.2 采样率和位宽怎么选才不会后悔
采样率选择的第一原则是满足奈奎斯特条件：采样率至少大于最大中频频率的两倍。这个最大中频频率由你最远需要检测的距离决定。如果目标最远只要看几十米，就不需要把采样率拉得很高，因为高采样率带来的数据量对后端的FFT计算压力是倍增的。但同时要注意抗混叠滤波，ADC前端必须有一个低通滤波器把带外噪声和干扰滤掉，否则超过fs/2的高频成分折叠回带内，会直接污染目标峰值。
位宽选择的逻辑就更有意思了。位数越多，量化噪声越低，动态范围越大，但数据的存储和搬运量也线性增加。12bit到14bit是雷达界的主流，因为再往上走，比如16bit，数据量变大、ADC功耗变高，但中频信号本身已经被模拟前端的噪声限制了，多出来的位数基本是白费。调试时可以用一个简单的判断方法：把ADC采到的中频信号做频谱分析，看噪声地板是不是已经低于模拟前端的本底噪声。如果是，说明ADC位数已经够用，没必要再堆位宽。这一点跟生活里买音响是一个道理——喇叭的失真比功放大，你换根更贵的线听不出区别。
2.3 从MCU思维到高速采集思维的转变
很多做嵌入式出身的人，包括我自己，早期都习惯用MCU的ADC来想象雷达采集：配置一下GPIO、enable一下ADC中断、然后DMA搬运到内存。这套思路在低速采集场景下完全没问题，但毫米波雷达的中频采样率动辄几十MSPS，单chirp采集的数据量在几十KB量级，一帧几百KB，MCU内置ADC根本不现实。所以雷达芯片通常会内置高速ADC并在芯片内部完成数据缓冲，外部接口输出的是已经打包好的chirp原始数据或预处理后的数据，不再需要你自己去踩ADC中断。
不过MCU的ADC经验也不是完全没用，它可以帮助你理解采样周期、参考电压、量化误差这些基础概念。比如热词里经常有人问“C语言ADC值滤波函数怎么写”，这个在低速采集里很实用。我自己在写调试工具时会用滑动平均加中值滤波，处理传感器读数特别稳。给一份简单可用的参考：
#define FILTER_TAP 8 static uint16_t adc_buf[FILTER_TAP]; static uint8_t adc_idx = 0; uint16_t adc_smooth(uint16_t raw) { uint32_t sum = 0; adc_buf[adc_idx] = raw; adc_idx = (adc_idx + 1) % FILTER_TAP; for (uint8_t i = 0; i < FILTER_TAP; i++) { sum += adc_buf[i]; } return (uint16_t)(sum / FILTER_TAP); }但注意，这种时域滤波在雷达链路里要慎用，因为中频信号本身携带目标信息，时域的简单平滑会把高频分量滤掉，相当于把距离信息抹掉了。雷达的滤波主要靠频域窗函数和后续的信号处理，而不是时域求平均值。这是MCU思维和雷达思维最大的区别之一。
3. 距离-多普勒处理：FFT如何让目标现形
3.1 距离维FFT：时延差变成频率差
单个目标的情况下，ADC采到的中频信号就是一个单一频率的正弦波，频率大小正比于目标距离。多目标的情况下，它就是多个正弦波的叠加。距离维FFT要做的，就是把这个叠加信号拆分开，让每个频率峰对应一个目标。FFT的bin号和距离的对应关系由chirp斜率、采样率和FFT点数共同决定。
距离分辨率的公式是 ΔR = c / (2B)，听起来很简单，但含义很深——如果你想提高距离分辨率，只能增加chirp的调制带宽B，和采样率、FFT点数都没关系。带宽250MHz时距离分辨率是0.6米，带宽做到4GHz时可以压到3.75厘米。这就是为什么车载毫米波雷达一定要用79GHz频段的原因之一，那个频段可以合法分配非常大的调制带宽。而FFT点数增加，只是把频谱分得更细，看起来更平滑，并不会把两个本来就分不开的峰值分开。补零操作也是同样的道理，它只能做插值，不能提高真实分辨率，我见过不少新人以为补零能“提升精度”，这个观念要纠正过来。
实际操作里，距离维FFT之前要给时域数据加窗。加窗函数会压低旁瓣，但也会略微展宽主瓣，这是一个trade-off。目标强的场景，比如近距离金属反射体，不加窗会让旁瓣把弱目标盖住；追求分辨率时用矩形窗，追求动态范围时用汉明窗或汉宁窗。我自己的习惯是：系统调试阶段先不加窗，看原始频谱长的什么样，确认没有异常之后再加上窗函数。
3.2 多普勒维FFT：相位差读出速度
距离维FFT做完，你会得到一个距离谱序列。如果目标在运动，它的距离bin峰值会带着跨chirp的相位旋转：每个chirp之间的往返时延在变化，导致IF信号的起始相位在变化。这个相位变化率，就是目标速度的体现。对每个距离bin，再沿着慢时间方向做一次FFT，就得到多普勒维。
最大不模糊速度是 Vmax = λ / (4 × Tc)。还是用前面的参数：载频77GHz对应的波长约3.9mm，chirp时长40us，Vmax就是24.4m/s，约合87.8km/h。如果你的交通场景需要测到更快，就得缩短chirp时长。速度分辨率则是 Δv = λ / (2 × T_frame)。帧长5.12ms时，速度分辨率大约0.38m/s。这里有个设计矛盾：距离分辨率靠带宽，速度分辨率靠帧长，而最大速度靠chirp时长。你压缩chirp时长去提高最大速度，会减少快时间内的采样点数限制距离范围；你增加帧长去提高速度分辨率，又会降低输出刷新率。所以波形设计永远是围绕应用场景做权衡，没有一个参数组合适合所有场景。
多普勒FFT同样需要加窗，但这里有个更隐蔽的问题：如果目标的距离bin在帧内发生了跨bin移动，也就是距离走动，直接做多普勒FFT会很发散。距离走动在高速度、低距离分辨率时更容易出现，解决思路是帧内先做运动补偿，或者缩短帧长降低积累时间内位移，也可以采用高分辨率的距离结构让走动控制在半个距离bin以内。这个细节在车载雷达处理强横穿目标时特别重要。
3.3 CFAR：别用固定门限，用自适应门限
距离-多普勒图做完之后，就需要判断哪些谱峰值是目标，哪些是噪声。最直接的想法是设一个固定的幅度门限，幅度超过门限的就是目标。这个方案在实验室里还行，一上真实环境就崩——因为热噪声、杂波、干扰的空间分布不均匀，远处底噪可能高也可能低，固定门限不是漏检就是虚警。所以工程上用的是CFAR（恒虚警率）检测，让门限随着背景噪声自适应变化。
CA-CFAR的经典做法是：在待检单元两侧取若干个参考单元，统计它们的平均功率，再乘一个门限因子得到判决门限。参考单元和待检单元之间要留出保护单元，防止目标本身的主瓣能量泄漏到参考单元里，把门限抬得太高，导致目标自己把自己淹掉。门限因子α的计算方式为：
α = N × (Pfa^(-1/N) - 1)
其中N是参考单元总数，Pfa是期望的虚警概率。取N=32、Pfa=1e-4，算出来α约10.7，也就是门限大约是背景均值的10.7倍。这个公式是我调参时的基本盘，实际系统还要考虑采样相关性和窗函数带来的展宽，做一定微调。
CFAR参数里最容易踩的坑是参考单元数量。参考单元太少，噪声估计方差大，门限抖动厉害；参考单元太多，旁边的强目标就会被吞进统计窗口，造成邻近的弱目标检测不出来。我一般从16个参考单元加4到8个保护单元起步，再根据实测的检测概率和虚警率调整。
4. 角度测量与点云：从谱峰到三维空间
4.1 DBF和角度FFT：多根天线的相位差
到这一步，你已经知道目标在哪个距离bin、以什么速度运动，但还不知道它相对于雷达的方位角。角度信息的来源是天线阵列：同一目标回波到达不同接收天线时，由于传播路径长度不同，会产生一个与到达角相关的相位差。测这个相位差，就能算出角度。
工程上最常用的方法是数字波束形成（DBF），本质就是对多根天线的复数值再做一次FFT。如果有4根等间距接收天线，角度FFT就能给出4个角度bin，角度分辨率约14.3度，听起来很粗对吧？所以实际车载雷达会用MIMO技术，通过时分复用的发射天线虚拟出一个更大的等价阵列，比如4发4收可以得到等效几十根虚拟天线的阵列，角度分辨率就能压到几度以内。这也是为什么很多雷达数据里，角度维的维度远大于物理接收天线数。
后面处理里我强烈建议先把DBF跑通跑稳，再考虑MVDR或者MUSIC这类超分辨算法。超分辨算法在仿真里很惊艳，一到实车就翻车——它们对幅相误差、通道间一致性、耦合非常敏感，需要做阵列校正，计算量也大。我在一个项目里遇到过通道间有0.5dB幅度差，DBF只看峰值位置影响不大，但MUSIC的谱峰已经歪掉的情况。先把基础打好，再谈花活。
4.2 点云生成与聚类：从“亮点”到“物体”
距离FFT、多普勒FFT、角度估计做完后，雷达已经知道亮点的距离、速度、角度，再加上没有直接用到的回波幅度，就能算出一个RCS量级，这组数据就是一个点。所有通过CFAR检测并完成角度估计的峰值，合在一起就是这一帧的点云。点云输出的格式很简单，通常就是一个结构体数组：距离、径向速度、方位角、俯仰角（如果有）、信噪比或RCS。需要注意，点云是一帧一帧独立产生的，每一帧的点数不固定，也没有任何点的身份信息——它们只是一堆“此时此地有反射”。
把点云变成物体，第一件事是滤掉静态杂波。地面上静止的护栏、路牌、铁皮墙，在雷达眼里都是很强的反射点。如果目标是运动的，雷达可以直接看多普勒速度，把所有径向速度接近0的点初步过滤掉，但这样一来静止的车辆、静止的行人也没了。这个问题在车载场景特别麻烦，因为雷达RD谱上静止目标的多普勒基本上是0，它和静止杂波混在一起。解决的思路包括利用多帧信息区分真实静止目标和固定杂波，或者在波形设计时就考虑到静止目标检测的需求。总之，静态目标的检测是一个单独的技术栈，没法用一刀切的多普勒门限解决。
点云聚类我习惯用DBSCAN，因为它不需要提前指定聚类个数，也擅长处理任意形状的簇，而且对噪声点有天然的过滤机制。它有两个参数：Eps（邻域半径）和MinPts（邻域内最少点数）。距离分辨率0.5米左右的雷达，Eps我一般取0.5到1.2米，MinPts取3。Eps取小了会把一个物体上的点打散，取大了会把相邻两个物体融成一团。这个参数和角度分辨率强相关，角度分辨率越粗，同一物体的点云在空间上拉得越开，Eps就要适当放大。
5. 目标跟踪与输出：为什么最后要给目标一个“户口”
5.1 为什么点云不能直接当目标
把点云聚类完成后，你已经得到了一些“物体”级别的观测，但它们还没有身份，也没有跨帧的连续性。这一帧在10米处看到一个物体，下一帧在10.3米处又看到一个物体，你无法确定它们是不是同一个——这就是点云和目标的本质区别。实际场景中还有更糟的情况：目标被遮挡导致漏检一帧，点云分裂成两团，或者多径反射出一个假点。如果不做跟踪，下游的决策算法拿到这种数据会非常难受。
我印象很深的一个场景是停车场里的金属柱子。那根柱子因为镜面反射，在RD谱上会周期性丢失，偶尔又分裂成两个峰值，如果不做跟踪，系统会认为柱子周围有凭空出没的物体。加了跟踪和航迹管理之后，这种时有时无的观测被平滑掉了，柱子被稳定地标记成一个目标。跟踪模块存在的意义，就是给每个目标一个稳定的“户口”——一个ID、一条轨迹、一个平滑后的状态估计。
5.2 卡尔曼滤波与数据关联
跟踪里最常用的基础是卡尔曼滤波。对大多数雷达目标来说，匀速（CV）模型已经够用，状态量可以是[x, vx, y, vy]。卡尔曼滤波在每个周期做两件事：用上一帧的状态预测当前位置，再用这一帧的量测更新预测值。它本质上是一个带权重的最优估计器，权重取决于你对预测的信任和对量测的信任。在工程里，我会把过程噪声协方差设得大一点，让滤波更相信量测，对快速机动的目标反应更快；如果你要的是平滑稳定，就把过程噪声设小一点，但这时候目标真实加速变向时，跟踪会明显滞后。
数据关联是跟踪的另一条腿。最简单的是最近邻：把每个观测分配给距离最近且在一定关联门限内的已存在航迹。目标少、彼此离得远时，最近邻又快又好。目标一旦密集，比如城市路口的行人加车辆加道路护栏，最近邻就会串扰。更稳的方案是全局最近邻或JPDA，把关联问题建立一个代价矩阵，在全局范围求解最合理的分配。我个人的经验是：先用最近邻跑通整个链路，确定跟踪的输入输出没有问题，再根据实测密集程度决定要不要升级关联算法。不要一上来就上重武器，因为你可能还没确认点云本身的正确性。
航迹管理同样要定规矩：新目标要连续M帧都能关联上才确认航迹，否则视为虚警；已确认的航迹连续K帧没有观测关联，就删除。M取3、K取5到8是常见起点。这套“确认-维持-删除”机制能非常有效地抑制虚警航迹，代价只是对真目标的认识晚了几帧，在多数应用里完全可接受。
5.3 目标列表长什么样、怎么送出去
跟踪模块的最终输出，就是标题里说的“目标列表”。一份标准的目标列表，每个条目至少包含：目标ID（生命周期内保持不变）、x/y/z坐标（通常以雷达本体为原点）、vx/vy速度分量或径向速度、RCS或目标幅度、存在概率或置信度、目标类别（可选，车辆/行人/未知）。如果关心目标尺寸，还可以扩展出半长轴、半短轴估计；如果下游需要预碰撞判断，加速度分量也要带上。
输出的频率取决于帧率，常见的是10到30Hz。一帧可能有一到几十个目标，这个数据量对CAN总线来说都毫无压力，通常用几帧打包一次或直接逐帧发送。数据也可以走LVDS或者UART给域控制器。我记得最清楚的一个坑是时间戳——目标列表里的时间戳必须与雷达数据帧严格对齐，否则下游把目标位置和视频图像叠加时，会出现位置和图像差了一拍的情况。我见过不止一个项目花了两周时间排查那种“看起来不对但说不上来哪里不对”的bug，最后发现是输出接口的时间戳差了20ms。
6. 工程落地中的常见问题与调参经验
6.1 我踩过的几个ADC和底噪的坑
ADC饱和是最常见的上手问题。近距离有个大目标，中频放大器增益又高，ADC输出直接顶到满量程，时域波形像削平头的信号。在距离FFT里，削顶带来的谐波会制造一堆假峰，看起来像多目标，实际可能只有一个目标。排查方法很简单：直接把ADC原始时域波形抓出来看，如果有明显的平顶，先把增益降下来。我还遇到过示波器探头接上去，ADC采集电压变高的情况，这不是雷达坏了，而是探头寄生电容改变了参考电压的负载，正确做法是用高阻探头或者直接在芯片引脚附近测，不要经过长线缆。
底噪随温度漂移是另一个容易被忽略的问题。同一个波形的噪声地板，在常温下很干净，到低温环境就会抬起来，导致CFAR虚警率飙升。解决思路不是把CFAR门限调高就完事，因为门限调高同时会牺牲检测灵敏度。我会做一轮温度标定，把不同温度下的底噪特性测出来，做成查表或者拟合曲线，在CFAR门限上做温度补偿。这个工作不复杂，但很多团队不做，等冬天测试时才发现虚警爆表。
掉坑记录里还有一个“多径假目标”。雷达在金属护栏、隧道墙壁、铁皮围挡旁边，会通过地面或墙面反射产生一个镜像目标，位置看起来在路外，速度方向也不对。这种假目标靠单帧点云很难滤掉，我会结合多帧航迹做检测——镜像目标的径向速度往往和真实目标不一致，航迹走向也不符合物理约束，跟踪模块里加一个简单的运动合理性检查就能滤掉一大半。
6.2 CFAR参数速查与调参顺序
CFAR调试顺序很重要，我一般按“信噪比地板→虚警率→保护单元→参考单元→门限因子”这个顺序来。先做频谱分析，确认系统底噪在合理水平；再找一个没有目标的场景，统计CFAR每帧输出的假点数，粗调虚警率；然后加单目标场景调保护单元，确保目标旁瓣不进参考窗；最后参考单元和门限因子一起微调，目标是“漏检率和虚警率都低”的那个平衡点。
给一份我个人常用的速查参数：
| 参数 | 推荐起点 | 调整方向 |
|---|---|---|
| 参考单元数 | 距离维16、多普勒维16 | 多目标密集时减小，避免强目标串扰 |
| 保护单元数 | 4到8 | 目标旁瓣宽时增大 |
| 目标虚警率Pfa | 1e-4到1e-6 | 要求低虚警就调低，但注意灵敏度 |
| 门限因子α | 由Pfa和N按公式计算后微调 | 直接乘0.8~1.2倍看效果 |
| Eps（DBSCAN） | 0.5到1.2米 | 角度分辨率粗时调大 |
| MinPts（DBSCAN） | 3 | 点云密集时可调到5 |
还有一个小技巧：在不同底噪环境下对比CFAR检测出的目标个数和位置时，不要只看检测输出，要把RD谱连同CFAR门限一起可视化。很多bug一眼看出门限被谁抬高了，比盯着参数表猜快得多。
6.3 算力优化：先定位瓶颈再动手
感知链路的实时性，优化之前必须先做测试，用profiler或硬件计数器找出瓶颈，再决定动手方向。最常见的瓶颈有三个：FFT运算、CFAR遍历点对数、聚类。FFT的优化有捷径可走，比如用现成的DSP库或FPGA的FFT IP核做定点FFT，通常比自己在通用处理器上写浮点FFT快几倍到几十倍。CFAR计算的本质是对每个待检单元滑动统计背景功率，如果参考单元数多、点数多，可以用移动求和的方式把复杂度从O(N×W)降到O(N)。
聚类和跟踪阶段的数据已经很少了，一般不是瓶颈，反而“数据搬运”才是隐藏瓶颈。ADC数据到内存、FFT中间结果转置、点云数据到处存等，这些内存拷贝在大数据量下甚至比算法本身更吃时间。一个简单的优化是：FFT时把实数数据按通道处理，避免做复数数据的大矩阵转置。实测下来，这种数据布局优化有时能拿到比改算法更明显的收益。
我自己最近一次调新板卡时，第一件事不是看最终目标列表，而是先把ADC抽出来的原始chirp用脚本画出来，再看RD谱、再看CFAR输出，一级一级确认信号在链路中的形态符合预期。我到现在都保存着那个项目的RD谱截图，因为那是整个系统最终表现好坏的地基。感知链路是一个层层递进的流水线，只要每一级都喂得饱、每一级都对得上，最后一层自然好看。这个“一级一级核对”的习惯，就是我做雷达调试这么多年最想分享的经验。
