我眼里的算法工程师？
在22年，作者同业内好友闲谈，我说，到今天我已经在算法岗位工作了6个年头，纵然自主开发的定位系统、导航系统随扫地机产品也已经服务了几万家，但我仍然没有足够的底气称自己是“算法工程师”，若不是确实在此岗位上开展工作及已有明确被市场验证的成果产出，我更愿意说自己是“软件工程师”，我后来反思，这可能要归结于两方面谈起：其一，应该是由于我计算机软件工程专业背景相干，其实本质上，仍然是通过编码行为实现期望的产品效果，至于过程中，所研习的那些公式理论，所优化的那些时空复杂度，不过是产品开发中需要解决的问题、需要做出的动作，性质和解bug无异。其二，对于算法仍然是存魅的，彼时，脑海中的第一印象算法工程师的自然语言是由符号和公式组成表达的，请原谅我这根歪路野的主观与片面，而在下，最舒服的方式仍然是代码的解读。
与朋友的检讨，让我更加清晰了一些概念，总结如下：
算法工程师是一个岗位，也是一个方向，但这里面又可以划分两个派系及四个级别：
- 学院派和工程派
学院派一般指向科研、理论，实验室场景，往往在相对理想或聚焦环境下关注指标上限，于学术相引导其方向；
工程派一般指向落地、应用，项目组场景，往往在复杂多变环境关注指标下限，于应用相引导其落地方案； 一些经典原生算法乃至框架一般由学院派主导发布，而工程派，更多是结合产品特性，在考虑应用场景、算力、成本等诸多边界元素的约束下，如何正确合理的去选择及应用。
于行业而言，两派并不对立，均在不同维度共同促进发展与成熟。
但由于工作场景的特性，与人才流动方向，两方面又促成了之间的矛盾！
实验室场景，以研究为导向、以答辩做闭环、时间概念相对模糊、重在过程与课题收获（无论是成功的贡献、还是失败的经验），对于最终结果失败的容忍度、可解释性较高。
项目组场景，以结果为导向、以产品落地做闭环、追求时间颗粒度细化、以项目成功为目标，几乎没有可解释性。
人才的流动的方向往往是学院、研究所向私企事业单位输送，场景思维的转换与适应，往往不是在短时间可以完成的，这就造成了极大的预期落差
人才方面，执著于算法技术本身的研磨，而轻视产品属性与项目节奏，要知道，即使同一个技术问题，在课题方向和产品方向上，也会有两个不同的答案，一个是宏观鲁棒性、另一个则是在明确场景与边界条件前提下的鲁棒性，偏差极大。
企业方面，为什么我全部招聘的名校/所的高材生，做不出我想要的产品？效果总是低于预期、时间不充分、项目风险失控。
这场面就很尴尬，明天投资人要来看演示了，但是，研发人员还在纠结是不是框架算法选的不合理？都很急也很茫然。
尤其在以上特性下，犯下高层用人认知错误：学院派高学历 = 高项目统筹管理能力。
科研视角是聚焦的、思维是深度垂直的，而项目统筹，是全局、发散的。这两方面的能力，并非擅长与平均的关系，往往是两个极端，极擅长科研并极弱于统筹，如果没有足够判断力，把错误的人用在错误的位置，对项目乃至初/中期企业的打击是致命的。 - 四个级别
主要针对工程派某算法方向的掌握度进行划分
知道 - 了解 - 工程 - 产品
1.知道：概念向，知其词汇、应用场景、解决什么问题，比如：Cartographer是google开源激光slam框架，可以进行机器人定位与地图构建。
2.了解：理论向，知其原理、流程与算法思想，比如，是基于图优化思想的前/后端架构，可以融合处理激光、imu、gps等传感数据，前端用来数据匹配关联，构建submap，后端进行回还检测与优化。
3.工程：实操向，大部分同行集中于此，由实操能力又有如下细分
3.1 开源框架移植部署与调参
3.2 开源框架基础上，小范围二次开发、裁剪
3.3 开源框架基础上，有产品意识，在场景驱动下，可以某框架为基础深度定制开发
3.4 多框架多思想，产品、场景、业务驱动下，可融合不同思想、策略取长补短自研生产最适合的算法系统
4.产品：验证向，多指工程化各项指标完成度达标，产品发布经过一定量级真实市场考验迭代后所具备。
如上，业内非常容易陷入的一种错觉：
选择一个好的开源框架，完成部署调参 = 基本完成了产品化开发，于是，反复在框架级的了解/选择/部署/调参/验证，在2-3.1循环反复
而实际真实的有效投入应是在3-4之间的摸索，乃至水平达到3.3之后，大部分的思考应是在技术基础之上集中在产品与场景端
3.3是一个明确的水平分水岭，往往需要至少一个完整的项目经验支撑，在这之前，充满了诸多的不确定性，算法概念、产品思维、项目思维均不成熟，需要漫长的摸索、验证与认知的提升，在这之后，才有可能将算法开发像软件开发一样进行计划式管理推动。对于算法工程师，即使具备了产品级的开发能力，虽然算法技术与思想是通用的，但横跨其他产品，往往也是从3.3做起。
希望如上表述，可以让您更加清楚的观测目前的团队状态。
这里的预期偏差
软件开发和算法开发的差异？
两者的底层逻辑、目标导向、能力模型完全不同 ——软件开发的核心是「用工程化方法，把明确的需求转化为稳定、可维护、可复用的软件系统，核心是 “把事情做对”」；算法开发的核心是「用数学建模解决不确定性问题，优化精度 / 效率 / 鲁棒性等核心指标，核心是 “找对的事情做”」。
核心目标
软件：实现明确的产品需求，构建稳定、可扩展、可维护的软件系统，保障功能可用、流程闭环
算法：用数学建模解决特定场景的不确定性问题，优化精度、速度、鲁棒性、泛化能力等核心性能指标
底层思维
软件：工程思维：追求确定性、标准化、可复用、低耦合，优先用成熟方案解决问题，避免重复造轮子
算法：科研思维 + 工程思维：先解决 “方案是否可行” 的不确定性，再做工程化落地，追求指标最优，常需要针对性造轮子
工作流程
软件：标准化线性流程：需求评审→架构设计→编码实现→单元测试→集成测试→发布上线，可通过敏捷 / 瀑布模式精准规划，迭代节奏可控
算法：非线性探索流程：问题定义→方案选型→数学建模→数据 / 仿真验证→代码实现→调优迭代→实机场景验证→工程化落地，存在大量推倒重来的可能，迭代节奏不可控
评判标准
软件：
确定性优先，核心看「不出错」：
核心维度：功能完整性、bug 率、长期稳定性、可用性、可维护性、兼容性、安全性；
合格标准：连续运行无崩溃、功能符合需求、无致命问题
算法：
最优性优先，核心看「效果好」：
核心维度：精度 / 准确率、召回率、运行效率、内存占用、鲁棒性（抗干扰）、泛化能力（跨场景适配）；
合格标准：核心指标达到设计要求，复杂场景下不失效
发展路径
软件：
通用性强，赛道跨度大：
初级开发→高级开发→架构师 / 技术专家→技术经理 / CTO；
横向可转产品、项目管理、测试、运维，几乎全行业通用
算法：
垂直性强，跨赛道难度极高：
初级算法工程师→高级算法工程师→算法专家 / 架构师→算法负责人；
横向仅可转 AI 产品、数据科学，细分赛道间壁垒极高（如 SLAM 算法转 NLP 算法几乎等于从零开始）
简单讲
软件开发：在确定的规则里，做稳定的工程实现，核心是 “守”，守住系统的稳定性、可维护性、可用性；
算法开发：在不确定的场景里，找最优的解决方案，核心是 “攻”，突破性能的上限、解决场景的核心痛点。