这两年我几乎每周都会收到类似的咨询“手头一个机器人项目室内外都有雷达是16线机械式到底该上Cartographer3D还是直接上LIO-SAM”说实话每次看到这种问题我都会多问一句你先告诉我机器人在什么环境里跑、单次工作多久、谁负责长期维护、车上还有什么传感器。因为从Cartographer3D到LIO-SAM表面上看是两个开源方案之间的二选一实际上是两套完全不同的建图与定位哲学之间的取舍。3D激光SLAM算法选型这件事选错方向不是“多调几天参”能补回来的它会直接影响项目周期、硬件成本甚至整个机器人团队的后续技术路线。这篇文章不打算复述论文也不做跑分测试我就以实际落地和踩坑的视角聊聊主流3D激光SLAM算法怎么选尤其是Cartographer3D和LIO-SAM这两个高频选项背后的真实差异。1. 选型之前先把需求盘清楚1.1 三个高频问题精度、场景、资源我接过的项目里咨询者最常问的是三个问题“这个算法精度能到多少厘米”“室内室外都能用吗”“在Jetson上能不能跑”这三个问题本身没问题但孤立拿出来问一定会得到误导性的答案。精度不是算法单方面决定的而是传感器、场景、标定、乃至运行时长共同作用的结果。室内室外都能用不代表同一套配置能同时处理好两种环境更不代表换一个环境后不用调参。而“能不能跑”更是要拆开看是勉强实时还是长期稳定运行CPU余量还剩多少都完全不同。我在一个园区巡检项目里最早用Cartographer3D做原型验证3D点云建图效果确实好闭环一拉地图干干净净。但等真把建图节点挂到Jetson Xavier NX上室内外切换跑了一圈CPU峰值直接接近满载后面再做路径规划和避障时明显感到压力。后来换LIO-SAM做定位才把计算资源挤出来。所以第一步不是打开GitHub找算法而是先把需求盘成一张可执行的清单。1.2 建图、定位、重定位你要的到底是“SLAM”的哪一部分很多项目方嘴上说“我要SLAM”但真正要的东西其实不一样。有的是要离线建图把一份高质量点云地图导出来后续定位交给别的模块有的是要实时建图同时本体定位边跑边建还有的是地图已经存在机器人只需要在既定地图里做重定位。这三个需求对应的算法选型完全不同。Cartographer3D的强项在于离线或准实时的全局建图激光帧与子图的匹配能力强回环检测做得好适合“先把地图建准”的场景。LIO-SAM更像一个完整的多传感器融合里程计系统IMU、激光雷达、GPS因子都可以融进去连续定位和户外长距离运行是它的主场。如果你要的是“边跑边定位边更新地图”两者都行但LIO-SAM在动态环境下的鲁棒性通常更好。我记得有个客户做地下车库清扫机器人场地是封闭的但地形长、柱子多车体本身还有颠簸。他们最开始想用LIO-SAM因为“听起来新一点”但地下车库GPS完全失效IMU又偏消费级长走廊里位姿会慢慢飘。后来我们切到Cartographer3D利用墙柱结构做精确回环地图终于是能看的状态。项目要什么决定算法怎么选这比谁在排行榜上靠前重要得多。1.3 用一张需求清单把现场约束写下来建议你在看任何算法之前先写一份针对项目的需求清单至少包括下面这些维度环境类型室内结构化、室外园区、矿区、隧道、半开放仓储还是混合环境单次运行里程/时长几百米巡逻还是几公里长距离作业运动特性底盘匀速行驶还是频繁加减速、原地旋转、上下坡传感器配置激光雷达型号、线数、扫描频率是否带IMUIMU级别有没有轮式里程计或GPS/RTK计算平台工控机CPU、Jetson系列、内存是否还要同时跑识别和规划精度指标全局一致性更重要还是局部定位精度更重要回环需求是否需要重访已走过的区域能否接受闭环后的位姿跳变团队能力是否有能力改C源码、做参数调优、处理驱动和标定不要急着回答“我大概知道”把这些逐条写下来。选型时你会发现真正起决定作用的往往是那些一开始你没在意的小约束比如雷达扫描频率、IMU消息频率、底盘没有轮速计、现场只有一台老旧的i5工控机。1.4 为什么“能跑通demo”和“能稳定交付”是两件事很多工程师对某个算法的第一印象来自GitHub上的demo视频或者自己的rosbag回放。说实话demo环境下跑通真的不难尤其是官方数据集点云干净、时间戳完整、运动平缓。但交付项目时环境不会迁就你点云会因为雷达本身的抖动出现畸变IMU消息可能因为驱动配置问题少了几十个长走廊来回走一圈回环检测没触发轨迹就慢慢飘了动态车辆从旁边经过点云里多出的簇直接污染特征提取。这些才是你能不能稳定交付的分水岭。所以这篇文章后续所有分析都默认你是冲着“稳定落地”去的不是冲着“把demo视频发朋友圈”去的。带着这个前提我们再看主流算法的血缘和差异。2. 主流3D激光SLAM算法全景系别、血缘与技术差异2.1 LOAM家族的家谱LOAM → A-LOAM → LEGO-LOAM → LIO-SAM如果你刚接触3D激光SLAM第一件事是理清LOAM家族的传承关系。LOAM是2014年Ji Zhang等人提出的经典方案核心思路是把激光里程计拆成两个模块一个用scan-to-scan做高频低精度的位姿估计另一个用scan-to-map做低频高精度的匹配校正。算法提取两类特征边缘点和平面点再通过点到直线、点到平面的距离构建残差。LOAM没有回环检测长时间运行会累积漂移。A-LOAM是港科大对LOAM的简化重写代码更干净是很多工程师入门LOAM系的首选但它依然没有回环。LEGO-LOAM是Tixiao Shan的改进版亮点是地面分割和轻量化适合地面机器人运行效率高。LIO-SAM是同一作者后来的工作把IMU预积分直接融入因子图和激光雷达做紧耦合同时把回环检测、GPS因子都收进同一个优化框架里可以理解为LOAM系在工程易用性和传感器融合能力上的集大成者。这里要提醒一句不要以为LIO-SAM只是LEGO-LOAM加了IMU。它把IMU预积分因子放进了因子图雷达特征又可以反过来修正IMU零偏形成一个双向约束。这个设计让它在快速旋转、剧烈颠簸时依然能维持一个相对稳定的姿态估计这也是LIO-SAM在很多户外场景比纯激光算法更抗造的根本原因。2.2 Cartographer3D谷歌系子图优化的“重炮”Cartographer是Google开源的一套2D/3D SLAM框架2D部分在扫地机器人领域已经很成熟3D部分则常被低估。它的核心思想是子图submap加全局优化雷达帧先和当前局部子图做匹配形成位姿约束随着子图越来越多后端用Ceres求解器做全局图优化把所有子图之间的误差摊平同时配合回环检测修正累积漂移。Cartographer3D对点云数据的处理方式决定了它的性能特点。3D点云数据量远大于2DCartographer内部会做自适应体素滤波把点云分辨率降下来再匹配。如果你们用的雷达是32线或64线且扫描频率很高Cartographer3D的计算压力会非常大。我在室内仓库测试过把参数调低到拥抱实时性的水平后建图细节又会明显变差。这是一个很现实的取舍。但Cartographer3D的优势也很突出它对环境中的几何特征利用得很充分在室内有墙有柱、有稳定结构的场景里回环一旦建立全局一致性非常漂亮。而且它在2D和3D之间共用一套代码框架团队如果后面还要做2D机器人学习成本可以摊薄。2.3 FAST-LIO/FAST-LIO2滤波系的后起之秀只看LIO-SAM和Cartographer还不够现在很多项目里FAST-LIO系列也很常见尤其是港大开源的FAST-LIO2。它和LIO-SAM的路线不同LIO-SAM走的是因子图优化FAST-LIO2走的是迭代误差状态卡尔曼滤波。FAST-LIO2还用了ikd-Tree数据结构直接配准原始点云不需要额外提取角点平面点代码更简洁在CPU资源受限的平台上表现更友好。对工程师来说FAST-LIO2是LIO-SAM之外的另一个实用备选。如果你的场景不需要那么多GPS因子希望代码尽量精简、实时性高FAST-LIO2值得作为第二候选来测试。很多团队在Livox固态雷达上会优先考虑FAST-LIO或LIO-Livox因为LOAM系的特征提取逻辑和Livox的非重复扫描特性并不完全适配。2.4 其它绕不开的名字HDL、BLAM、livox系除了这几个主流选项业内还活跃着一些各有侧重但不可忽视的方案HDL_graph_slam基于NDT配准和图优化代码结构清晰对地面机器人比较友好在室内外小规模场景都有应用。BLAMBerkeley出品用ICP做前端匹配GTSAM做后端优化结构简单适合学习和快速原型但工程化程度偏低。LOAM-Livox / LIO-Livox专门针对Livox固态雷达优化的方案如果你项目里的雷达是Livox系列的直接在通用LIO-SAM上硬跑可能会遇到点云畸变和视角受限的坑。Point-LIO港大后来提出的方案能处理剧烈运动和极端抖动但工程成熟度不如FAST-LIO2。这些算法不是不优秀而是各有明确的适用边界。选型时不要迷信某一家建议先把候选方案限制在两到三个否则测试成本会失控。2.5 这些算法表面在用不同“匹配”本质差异在哪我把主流算法放在一起看真正决定选型的其实是这么几个维度算法前端匹配状态估计IMU融合回环检测典型适用LOAM/A-LOAM特征边面点位姿优化无无入门学习、早期原型LEGO-LOAM特征地面分割图优化松耦合有地面机器人轻量建图LIO-SAM特征边面点因子图紧耦合IMU预积分ICP回环户外长距离、多传感器融合Cartographer3D子图匹配全局图优化Ceres可选分支定界/实时回环室内结构化建图、全局一致FAST-LIO2ikd-Tree直接配准迭代误差状态卡尔曼滤波紧耦合无默认回环嵌入式平台、动态运动从表里能看出LIO-SAM和Cartographer3D其实是两条技术路线的代表一个有IMU和GPS的强融合能力适合连续定位和户外长距离一个靠子图和全局优化能力适合把一张大图建准。这个差异会在具体场景里被无限放大。3. 核心场景实测Cartographer3D与LIO-SAM的正面PK3.1 室内仓储与地下车库Cartographer3D更稳我拿一个实际测试项目说。场地是两层地下车库总面积约一万平方米有立柱、墙面、坡道灯光正常地面平坦。传感器是一个16线机械式激光雷达加一个消费级9轴IMU。我们用同一份rosbag分别跑Cartographer3D和LIO-SAM。Cartographer3D建出来的图柱子和墙面轮廓清晰绕场一圈回到起点后全局一致性良好重合误差肉眼几乎看不出回环检测在库内多次触发。LIO-SAM的结果则依赖IMU状态在空旷停车区域和长直坡道附近出现了缓慢漂移回到起点时轨迹和地图存在轻微错位需要重新触发回环才能拉回来。但Cartographer3D的代价是CPU占用明显更高点云处理频率也被拉低了一截。这个结果不是偶然。室内结构化环境对Cartographer来说是最舒服的主场墙、柱、墙角这些几何特征给了局部子图和全局优化足够多约束。而LIO-SAM过度依赖连续的激光约束和IMU预测在空旷区域一旦特征退化IMU零偏又不够准误差就会悄悄累积。3.2 户外园区与矿区LIO-SAM更抗造换一个户外园区场景情况立刻反转。场地有起伏坡道、大片空地、绿化植被还有零星建筑长度接近两公里。同样的16线雷达和IMU配置LIO-SAM凭借IMU预积分和GPS因子在长距离连续运动时保持了明显更好的姿态稳定性轨迹漂移控制在可接受范围内。Cartographer3D在这种场景下由于全局图优化依赖闭环来消除累积误差而园区路径长、回环触发次数少地图容易出现“整体漂移积累”再想靠回环修正已经晚了。这不是说LIO-SAM永远赢而是在“没有密集几何结构提供闭环”的户外场景里LIO-SAM的IMU-GPS融合补偿了激光退化。矿区那种地形起伏大、路面颠簸的环境同样如此。只要IMU标定靠谱、GPS信号不是完全丢失LIO-SAM比纯激光子图方案稳得多。3.3 长走廊与隧道两种算法都会遇到的问题这两种算法在长走廊和隧道里的表现非常有趣它们都会漂但漂的方式不同。Cartographer3D在长走廊里如果前后没有可回访的位置变化局部子图匹配会沿着走廊方向慢慢累积误差后端图优化因为没有闭环也没法消除。LIO-SAM相对好一些因为IMU预积分给位姿提供了一个短期预测基准在没有激光约束的方向上不至于立刻发散。但如果走廊长度超过几百米且没有任何测距特征IMU零偏误差也会逐渐把姿态带偏只是“晚飘一会儿”。我的实操经验是遇到长走廊只靠算法本身是不够的。正攻法是加入轮式里程计因子、或者在地面布置反光标识再不行就控制机器人速度减少快速转向。你们在测试时最好专门录一段长走廊bag因为这是最容易暴露算法软肋的场景。3.4 计算资源与实时性一张压力测试表不同平台的资源差异会直接影响算法可用性。我用同一份16线机械式雷达的bag在同样的工控机酷睿i7-9700上分别跑三个方案简单记录CPU占用和帧处理表现算法平均CPU占用内存占用能否实时处理16线10Hz点云表现备注Cartographer3D约3.5核满载高勉强可以地图质量好但点云滤波参数需要收紧LIO-SAM约1.5核中轻松实时性充裕有调参空间FAST-LIO2约1核中轻松实时性最好无回环在Jetson Xavier NX这类嵌入式平台上差异会更明显。Cartographer3D跑16线点云时CPU很容易逼近极限此时如果你还需要同一个设备跑YOLO做识别直接卡死。很多项目最终放弃Cartographer3D并不是因为它建图不够好而是因为它运行时吞掉的资源太多挤占了其他模块。3.5 建图质量的评价方法别用“肉眼看着行”来下结论做对比测试时不要只截两张图说“看起来A比B好”。工程交付需要可复现的量化指标。推荐用evo工具评估轨迹误差把你记录的ground truth轨迹和算法估计轨迹对齐后计算ATE绝对轨迹误差和RPE相对位姿误差。在室内可以用全站仪或高精度动作捕捉系统打点在室外可以用RTK轨迹做参考。即便没有高精度真值你也可以用一个笨办法估算全局一致性在起点附近设置一个明显标记物机器人建图跑完一圈回来后把建图结果里的标记物位置与实际位置做差误差能控制在10厘米以内就算优秀。这个方法简单但在项目验收时非常有用。4. 工程落地避坑地图这八类坑我几乎每次都见到4.1 时间同步雷达、IMU、主机时钟的“毫秒级战争”这是所有激光SLAM项目里最隐蔽、最毁心态的坑。LIO-SAM这类紧耦合算法对IMU和雷达的时间戳一致性要求很高如果IMU时间戳和激光点云时间戳不在一个时钟域预积分结果和点云畸变校正都是错的典型表现是机器人静止时地图正常一跑起来轨迹就开始上下抖。机械式激光雷达本身每个点都有精确的时间偏移驱动会把点的时间戳标到主机时间上。IMU消息也同理。如果主机没有配置PTP或NTP同步雷达和IMU各自用的时钟源不一致那你后续所有标定都白费。建议在录制bag之前先做一件事把机器人放到静止状态录制一段时间的数据回放时看rviz里的IMU姿态和点云是否稳定重合。如果静止状态下IMU和点云都对不上先别急着调算法去查驱动参数和时钟同步。4.2 运动畸变底盘一快就露馅很多人第一次碰到运动畸变是在底盘高速原地旋转的时候。机械式雷达的一帧扫描是分时扫描的点云内部的点并不属于同一时刻的机器人位姿如果底盘在快速旋转一帧点云会被拉成螺旋状直接破坏帧间匹配。轮式AGV速度慢感知不到这个问题但换成巡检机器人或者无人车这个坑就非常明显。LIO-SAM会在IMU预积分的基础上做运动补偿把一帧扫描内的点都投影到统一的坐标系下所以对运动畸变有天然抵抗力。Cartographer3D虽然也内置了一定的运动补偿机制但在快速旋转时如果点云分辨率高、滤波又不够畸变依然会体现到子图匹配残差里。选型时一定要问一句“我的机器人会不会快速转向旋转角速度能达到多少度每秒”如果会必须优先考虑有IMU紧耦合和去畸变的方案。4.3 退化场景几何特征消失时优化器开始“自由飞翔”退化场景是激光SLAM的公共死穴。所谓退化就是环境中的几何特征在某一个方向上缺失导致位姿在该方向上不可观测。常见退化场景有长走廊沿走廊方向无约束、大面积开放广场垂直方向和平移方向约束弱、隧道纵向约束弱且点云特征单一。我见过最离谱的一次是在一条长走廊里Cartographer3D的轨迹沿着走廊方向越拉越长地图末端直接偏移了将近一米。LIO-SAM虽然没有立刻发散但因为消费级IMU的零偏估计不准确也慢慢走出了一条“弧线”。正攻法有几个方向一是加传感器因子比如轮式里程计、GPS、甚至激光测距仪二是做退化检测检测到特征退化就降低机器人速度或切换定位模式三是利用已知地图做重定位约束。算法层面没有银弹工程层面才是解决退化问题的关键。4.4 回环检测“开了回环”不等于“有回环”很多工程师以为在配置里把回环检测开关打开项目就自动具备回环能力了。实际完全不是这样。Cartographer3D的回环检测依赖子图之间的匹配大场景下的回环搜索本身有计算压力。LIO-SAM的回环检测用的是雷达帧到历史关键帧的ICP匹配对初始位姿和匹配阈值都很敏感。更麻烦的是即使在相似几何结构较多的环境里回环匹配也容易误检。地下停车场一圈柱子长得一模一样LIO-SAM有可能把这段走廊误认为那一段产生错误的回环约束反而把原本不漂的轨迹拉歪。遇到这种情况我一般会把回环搜索半径调小或者增大关键帧之间的时间间隔避免把太近的帧误判成回环。还有一个容易被忽略的点很多算法回环优化后的位姿是给建图全局优化用的不一定实时反馈到当前定位结果里。如果你的应用是实时定位一定要确认当前使用的算法是否会把闭环修正同步到当前位姿否则会出现“地图突然跳一下但车的位置显示不变”的诡异现象。4.5 IMU选型与外参标定好算法也救不了烂参数LIO-SAM这类紧耦合算法的性能上限很大程度取决于IMU质量和外参标定精度。消费级IMU零偏不稳定、随机游走严重训练出来的预积分结果就是带噪声的雷达就算再准融合进来也会被带偏。我踩过的坑是把IMU和激光雷达的外参随手写了一个大概值机器人在平地没问题一到坡道位姿直接失稳查了半天才发现是外参的旋转分量写反了。给你的建议能用工业级IMU就尽量用工业级IMU至少在样机阶段准备一块性能达标的IMU不然你会把算法问题和传感器问题混在一起排查成本极高。外参标定尽量用工具离线做比如kalibr或li_calib不要把外参当成一个随便填的随机数。4.6 坐标系与TF一个Z轴方向写反整张地图直接歪掉Cartographer3D和LIO-SAM都依赖正确的TF树。常见的树形结构是map - odom - base_link - laserIMU和雷达相对base_link的外参一定要严格对应。我见过太多人把laser的Z轴朝上写成了Z轴朝下或者把IMU和base_link之间的平移忘掉结果建出来的地图整体倾斜。排查这类问题有一个小技巧在rviz里把点云、IMU姿态、TF坐标系一起显示出来让机器人原地转动观察点云和坐标轴是否贴合。如果点云绕着一个错误的旋转中心转外参一定有问题。坐标系问题一定要在调参之前解决否则你后面调的所有参数都会被坐标系错误带偏。4.7 雷达硬件的适配差异机械式、固态、Livox的“性格”完全不同不是所有激光雷达对算法都一视同仁。Velodyne、Ouster这类机械式雷达扫描线均匀、视场覆盖广LIO-SAM和Cartographer3D都能适配。Livox的固态雷达采用非重复扫描模式点云分布和扫描模式与机械式差异巨大直接套用LOAM系特征提取往往效果很差一般需要在特征提取环节单独适配或者直接用LIO-Livox、FAST-LIO这类针对Livox开发的方案。另外现在很多项目喜欢在车体周围加补盲固态雷达来弥补盲区。多雷达融合会引入新的时间同步和坐标变换问题且回环检测时还需要考虑不同雷达视场不一致带来的匹配困难。如果你是多雷达配置选型前最好先确认算法是否支持多雷达输入还是需要自己改前端匹配代码。4.8 参数调优从默认跑到落地差距都藏在配置里每个开源算法都会给一套默认参数但默认参数几乎等于“在作者的数据集上能用”。Cartographer3D的lua配置项很多比如体素滤波尺寸、子图大小、匹配线程数、回环搜索参数任何一个不合适都可能造成地图糊掉或CPU爆炸。LIO-SAM的yaml配置涉及IMU频率、雷达频率、扫描周期、关键帧距离阈值、回环搜索半径等同样需要针对你的雷达和运动特性重调。调参时我有一个铁律一次只改一个参数改完跑同一份bag记录前后差异。如果一次改五个参数出了问题你根本不知道是哪个改错了。最好把每次验证使用的bag、参数、输出地图路径、评测评分都记录下来形成一份自己的调参日志。5. 我的选型决策方法从需求到方案的一套动作5.1 用一张评分矩阵代替直觉我不建议凭“名气”选算法。比较靠谱的方法是先用一张评分矩阵给候选方案打分。比如你的项目更看重全局建图精度和稳定性那你可以把精度权重调高如果项目更依赖长距离导航和实时性则工程成熟度和资源占用更重要。下面是一个简化版评分示例满分5分你们可以按自己项目的权重改维度权重Cartographer3D得分LIO-SAM得分建图全局一致性0.2553户外长距离鲁棒性0.2025计算资源占用0.1524实时定位稳定性0.2034工程成熟度与社区0.2044加权总分13.354.00这不是说LIO-SAM一定比Cartographer3D好。如果你的项目权重换成“室内结构化 全局精度优先”分数会立刻反转。重点是把选型从情绪判断变成可比较的量化过程。5.2 先录真实bag再在办公室反复回放无论你心里倾向哪个算法我都建议先到现场录一段包。环境越接近最终作业场景越好路径要覆盖长走廊、转弯、坡道、空旷区域时长最好超过三十分钟中途不要人为干预。然后把这包数据拿来反复跑候选算法比较轨迹误差、地图质量、CPU占用和回环触发情况。rosbag的价值在于可复现。一次现场测试只能代表一次试跑的结果但同一包数据你可以在不同配置上跑无数遍。我见过很多团队拿着现场有限试跑的数据下结论结果最后发现是那次试跑IMU时间戳没同步好算法白背了锅。数据在手排错才有的放矢。5.3 三个“必须验证”的场景拿到候选算法后不管它评分多高都必须在下面三个场景里做验证退化场景长走廊、空旷广场、隧道至少各录一段观察算法的漂移速度和发散方式。长时间运行连续跑一个小时以上或连续走几次同一路线检查地图是否有重叠误差及回环触发情况。动态环境有叉车、人员、车辆经过的场地观察动态物体是否导致地图糊点或位姿跳变。这三个场景过不了说明算法和当前传感器配置不匹配选型基本可以否掉不用等到最终交付再去返工。5.4 双方案并行的现实策略在项目早期我不建议只押一个算法。更现实的做法是并行维护两套候选方案比如Cartographer3D和LIO-SAM各跑一路在关键场景做交叉验证。等现场测试数据足够多了再砍掉表现差的那一套收敛到唯一方案。双方案并行会增加一些开发和维护成本但相比选错方向后的返工这点成本完全值得。我见过一些团队前期为了省事直接锁死一个算法后来发现算法和场景不匹配整个感知模块都要推倒重来。并行方案虽然“看起来慢”实际上是最快见到确定性的方式。6. 写在最后算法选型没有银弹但有清晰的取舍6.1 我个人的痛苦与收获早几年我做项目时也有过“某算法一出立刻全面切换”的冲动。后来被现场数据教育了几次才彻底明白算法选型的本质是传感器、场景、计算资源和团队能力的匹配而不是找一个“最好的框架”。Cartographer3D和LIO-SAM之间的选择说到底是在问你的机器人“更像室内结构化建图器还是更像户外多传感器融合定位平台”。我能给你的建议只有一个先盘需求再录数据最后跑分用真实数据替你做决定。6.2 一个值得长期投入的小技巧最后分享一个我坚持了很久的小习惯把调参记录、rosbag数据集、评估脚本固化成一个“选型测试平台”。每次接手新项目先把这份平台拿出来用同一套数据做算法对比让结果说话。这套平台救过我太多次了也让团队在项目交付时拿得出数据来向客户解释为什么选这个算法、为什么这个精度已经达标。项目可以不完美但选型的过程必须可追溯、可复盘。这比记住某篇论文的公式有用得多。