offer帮选，好未来vs联想

如题，南方人，没有北京长期居住安家打算，算各种补贴政策总包其实差不多，北京生活成本还略高，但是妈妈平台确实很有吸引力。各位大佬给点意见。

到底如何才能用好呼入机器人？很多企业刚开始使用呼入机器人都满怀期待，想借助AI实现自动接待、降本增效。但上线一段时间后却发现，效果不如预期：接通量明明不少，但多数对话无法闭环；客户反复对话却无法理解需求，最后还是得转人工；但很多企业却不知道如何调整，甚至机器人“在哪儿卡壳了”“为啥解决不了”都无从得知——服务体验不好，运营也束手无策。这些问题背后，不是机器人不能用，而是企业缺乏一些工具来发现问题、分析原因、优化体验，让呼入机器人能听得懂、答得上，完得成。为此，天润融通基于大模型将传统呼入机器人升级为呼入Agent，并新增三大关键能力，帮助企业从服务数据中提取洞察、追踪行为细节、拆解转人工成因，...

大概方向是自动驾驶/具身智能感知、三维视觉、多模态等算法岗，先把目前的情况写一下，后续随缘更新。目前一部分进度：自动驾驶/雷达：速腾聚创 - 笔试挂地平线 - 一面挂滴滴 - 一面挂小鹏 - 等待二面元戎 - 等待二面百度IDG - 等待二面文远 - 等待二面京东 - 准备笔试具身智能：高德  - 二面结束深信服人才计划 - 一面结束智元机器人 - 一面结束机器视觉：拓竹科技 - 一面结束大疆 - 终面结束其他（小的初创公司就不写了）：TPLINK - offer，已拒中兴人才计划 -京东TET -OPPO -虾皮Shopee -接好运接offer

在推进微服务 API 自动化测试的过程中，研发和测试人员常常需要在接口请求中动态构造带有特定业务规则的数据。我们团队就遇到过这样令人头疼的问题：在接口测试过程中，需要动态生成带有特定规则的用户手机号、带业务标记的 UUID，以及一些结构化的测试邮箱地址。我们过去所使用的工具Postman，尽管提供了一系列内置变量如 {{$guid}}、{{$timestamp}} 等，但面对这类带业务语义的动态值生成需求却无能为力。这类问题的解决，一直依赖测试人员在 Pre-request 脚本中手写 JS 函数来补足变量功能。然而，随着接口数量和规则复杂度的增长，这种方式逐渐演变成脚本维护和能力鸿沟的灾难。...