最近几年没有写什么内容。主要原因是工作量相对增大不少，资源也比较紧张，导致没有什么精力来写东西（以上都是借口，去年述职我给自己定了 KPI，要继续写一点东西）。这次借着五一没有出门，统一写一份流水账。
首先，从大的方面看，这几年的变化基本都是 AI 的发展带来，尤其是 Agent 的发展，对技术开发、技术管理、团队管理等等方面都带来了非常大的影响，甚至可以说是革命性的。对行业内的所有参与者来说，不论是 P几、title 里面有啥，不能适应和变革的，都会被淘汰。对应的，所有的组织也一样。虽然现在还在迷雾期，大家都在探索，但是正如《万历十五年》一样，看起来平常的日子，已经决定了未来的结果。
本来我希望一次性写一个 23-26 的三年期流水账，但是发现真的过于复杂。只能分多篇，这一篇先说说几条杂项民科思考。其实私人记录里面，杂项的问题也已经很多了。
技术杂项
In-house labeling & Human-in-the-loop Auto-labeling
关于 in-house labeling 这个其实 Andrej Karpathy 多年前在 AI Day 就提到过，主要的原因就是 latency。其他什么数据质量、合规安全等等，都是次要的，甚至从我的个人经验上来看，唯一的原因就是 latency。数据驱动的一个重要前提就是能够有数据来驱动改进迭代。如果 latency 过高，哪怕问题分析得再完美，都无法对模型进行迭代改进。而外包标注的 latency 面对数据迭代的周期需求，是完全无法满足的。
所以，组建一套内部的标注团队，可以认为是任何宣传所谓数据驱动的公司的及格条件，否则，可以认为这个公司根本就是在吹牛X。 当然，不同的公司，in-house labeling 的形式可能不太一样，可能是自己组建、也可能是供应商驻场、外包团队等等。但是，这样的一个实体组织必须存在，用来进行快速响应。
对应的，auto-labeling（AL） 是辅助 in-house labeling 的一个重要工具。AL 可以说是数据迭代流程中的重要杠杆，成倍、成数量级的放大 in-house labeling 的能力。同样，AL 不可避免的会有问题，如果真的 100% 可以 AL，没有人类参与，那么最先应用的一定是大模型公司，都轮不到自动驾驶公司拿这个吹。 100% AL 的过程，其实是一个完全的正反馈系统，随着几次迭代，会进一步放大数据、AL模型的 bias，错误会变得越来越明显，或者进入一个无法有改观的局部稳态。
为了打破这种状态，我们需要引入负反馈。显然，现在最快速、最简单、成本最低（自动驾驶领域）的方法，就是将 in-house labeling 团队接入这个迭代过程。这也是我所说的 human-in-the-loop 的 AL。
HIL-AL 有助于克服数据标注过程中的低效区间，将人力进一步精准地投入到需要改进的部分。当然，这依赖良好的系统、人机工程学设计、高效的数据流程、准确的问题分析、可靠的数据挖掘。背后整整一套的支撑，才能够将 HIL-AL 的潜力真正发挥出来。其实，这也是后面我要说的非技术杂项中的“面向功能 vs 面向体系”的经典例子。
对于数据迭代流程，只要不差钱，那么最大的问题就是资源投送效率。毕竟，在不限制资源的情况下，数据是真的可以做到海量的，但是譬如精确制导弹药的诞生带来打击效率数量级的提升，精确的数据资源投送，快速、精准地进行 HIL-AL 才是数据迭代流程中的重要因素。
Rapid updating & Offline evaluation
数据驱动其中的一个重大优势，就是快速更新。因为，绝大部分不用人类参与。所以，“尽一切可能的减少人类在流程中的比重”，就是数据驱动的重要原则。 用我们机器学习领域最出名那个段子来类比 “每当我开除一个语言学家，语音识别系统就更准确了。”对于数据驱动来说，“流程中每减少一个人的参与，数据迭代的效率就会进一步提升”。要想有数据驱动、要想有快速迭代，就必须把人类的参与降到最低，甚至完全不需要人类参与。定这个作为 KPI，甚至比定迭代周期作为 KPI 更加靠谱。
快速更新的前提是能够有一个快速的迭代流程来支撑。这个迭代流程，除了前面说的 in-house labeling 和 AL 之外，还需要有一个高效的离线评测系统来支撑。离线评测系统的效率和准确性，直接影响到整个迭代流程的效率和质量。而要将整个流程的迭代速度提升，那么就需要离线评测系统可以覆盖完整的 ADS 技术栈。其背后的技术挑战和工程挑战都是非常大，尤其是离线系统的可复现性、开闭环测试能力、数据效率等等。可以看到，这同样依赖一个体系支撑。
非技术杂项
面向功能 vs 面向体系
虽然从工程角度，或者从我们习惯的所谓辩证法角度，说法一定是两者都重要。但是这种中华田园辩证法的段子已经很多了，不啰嗦了。
两者显然必须有一个排序，在自动驾驶领域。尤其是现在这个 AI 技术变革的时代，面向体系 是绝对的第一位。
如果一个组织、一个leader，还是按照面向功能的思路。每天考虑的是怎么加功能，功能怎么改进，功能怎么测试，功能怎么上线，功能怎么迭代…… 等着淘汰就好了。
基于功能，设计体系来支撑功能的迭代和发展，这个才是正确的思路。
为什么目前很多 leader 还是习惯面向功能，因为面向功能最简单，不用动脑子。体系设计需要动脑子，需要对未来有一个清晰的预判，需要对技术发展趋势有自己的判断，需要对团队发展有思路，更重要的需要有非常好的领导力。 面向功能只要把功能做好就可以，其他的无所谓、不需要关心，非常容易适配自己的舒适圈。 面向体系需要对整个发展有判断、同时又能够承担技术决策的不确定性，对 leader 的内功要求非常高。
尤其是之前的年代，拼凑功能是主流，东西弄出来了就好。相反，我们可以看到 A 家的 Claude Code，每周都能够释放出新的功能，甚至是抄不到的创新功能。其背后的体系支持重要性不言而喻。再看看 Tesla 的 FSD release 的周期，多个车型，可以有周级别的迭代。
很多缺少工程研发经验的人，容易本末倒置，单纯的追求快速迭代。其实，快速迭代只是结果，真正的原因是背后有一个非常好的体系设计来支撑快速迭代。
其实也可以认为其缺少成本意识，看到别人有什么，自己也想要有（比如，包括快速迭代本身就可以认为是一个功能）。但是因为缺少成本意识，不知道背后财务成本、时间成本，无法从体系层面逆向分析，最终是浮于功能。
隐形成本 vs BOM 价格
这一部分刚好也接着“功能 vs 体系”的问题。我要求组员一定要懂工程造价。作为软件开发，其实也符合工程体系。那句段子同样适配：“不懂工程造价，不懂工程造假”
于己方，不懂工程造价，提供对技术方案的合理成本估计（包括时间成本、财务成本、人员成本），并不要求能够做正确的成本估计（毕竟技术方案的成本估计本来就很难），但是至少要能够提供一个合理的范围，不能完全脱离实际。 于他方，自己也不能评估实际的成本。对方告诉你一个假的成本，都无法识别。
软件开发中的造价，又与领域知识相关。不同的方向，如果没有相关的领域知识，造价估计会非常离谱。这也是为什么我对团队内部要求有一条底线，没干过相关活的，没有发言权，只有建议权。因为没有相关领域知识，他是不能对自己说的话负责的。
大部分的研发工作，其隐性成本是高于显性成本的。这里的显性成本是可以量化、方便计算的，最简单就是用来算毛利的 BOM 价格。这也是为什么单纯的财务模型是无法建模软件开发成本。尤其是有研发性质的成本，研发性质的工作隐性成本的占比更高。涉及到技术方案选型、风险控制、技术债务、人文因素（我专门没用人力因素，人力因素也不过是通过工作经历、学历背景、传统的性格分析这种做的显性成本估计）。
我并不是一个管理学专家，但是显然现在这一套的成本估计方法，从一开始就很难适配新兴技术的发展。从几十年前的《人月神话》里面的项目管理失效崩溃，已经说明了问题复杂度；到现在新的技术研发，依然面对各种隐性成本的挑战。
项目对先进技术和工程经验的积累
技术部门管理者的一个重要职责就是要为团队积累先进的技术和工程经验。这个积累是通过项目来实现的。项目的选择和管理直接影响到团队技术能力的提升和经验的积累。
如果一个项目完成之后，团队没有从中积累到新的技术能力或者工程经验，那么这个项目就没有真正的技术价值。当然，很多人会说，项目要看重客户、看重商业价值。对于这句，我的回应倒是很简单：
- 不用大道理，因为大道理都是屁话，小学文化也能说。没人不知道商业价值重要。
- 这两者不矛盾，既不用玩文字游戏，也不用玩中华田园辩证法。甚至这俩是互相促进的。
- 作为技术团队，技术价值的追求是必须的。天天提客户优先、商业价值，可以直接去干销售，干技术太屈才了。
- 组织结构的设计，已经考虑了多方面。每个模块都有每个模块的职能。都客户优先，那肯定是个骗子公司，毕竟，能毫无选择满足客户天马行空的要求的，只能是骗子。都技术优先，也一样，毕竟也不是个非营利组织，糊弄谁呢。
那么一个项目结束了，完全可以总结下，是否引入了先进的技术、是否积累了工程经验、人员都有没有成长。做完一个项目，一点积累都没有，再等半年被淘汰就可以了。现在技术迭代速度越来越快，尤其是还处在一个技术代际变革的区间段里，团队未来的竞争力和发展潜力，都需要持续增长。
AI agent 带来的新变化和新挑战
目前我们内部的工程实践，已经有车端的某个功能节点完全由 AI 接管。这包括：
- 数据流程：数据下载、自动标注、数据筛选工具
- 模型流程：模型开发、训练、评测、改进
- 部署流程：ONNX 导出、目标平台部署、C++ 节点代码开发编译、离线板端部署、板端测试与可视化
现在也就因为车端涉及到了更大 scope 和工具链问题，我们的团队无法直接修改适配。这个节点可以说是达到了 ALL AI 的初级标准（中间还是有一部分人类介入指导和需求说明）。 现阶段，完全不用说什么 All in AI 的大话，先搞一个 ALL AI 的局部能力证明，就是最踏实的做法。
这种新的变化，在我看来是革命性的。其潜力刚刚被认识到，更不要说稍微的挖掘。我们内部已经确定，需要进一步提升 AI 在所有流程中的比例，进一步接管我们日常的研发工作。我们期望在未来的半年时间里，能够让 AI 接管整个数据端 -> 车端的完整流程，包括模型设计层面的优化。其实在之前的新人入门文档里面，我已经用三句话说明了工作理念：”We build tools. Tools help models. Models solve problems.”
新的变化，必然带来新的挑战。只是目前在我看来挑战还不是需要考虑的时候。拥抱、使用、适应、改进，才是现阶段最重要的。