当热爱的手写算子可能被工具接管，转岗时该保留什么、放弃什么？

一位算子工程师在文中提到，AI在一年内从查文档、读代码、找bug的小助手，变成能独立阅读CUDA、PTX与SASS编码并独立优化算子的工具。他判断自己不至于失业，但必须转业，并认为未来手写算子甚至编程可能变成娱乐活动而非生产活动。这是他的个人观察，不是行业定论，但足以让同方向的人认真想一件事：被工具接管的到底是什么。

被接管的是具体操作：查指令、读汇编、逐条分析停顿。可迁移的是另一层东西——判断哪个瓶颈值得先动、在延迟与吞吐之间怎么取舍、一个算子改动会怎样影响整条链路。这些判断换个场景仍然值钱，比如从单算子优化转向整机性能调优、从手写内核转向工具链与评测体系。转岗不是从零开始，而是把已有的判断力换一个应用场景。

怎么判断一个新方向值不值得投入，而不是从一个被压缩的方向跳进另一个？

不要用“听起来前沿”当安全证明。更实际的做法是把它拆成可核查的问题：这个方向的核心任务里，还有多少环节需要人做取舍？团队过去半年交付物有没有变化？如果工具已经能完成大部分执行，人剩下的是定义问题、验证结果还是只做搬运？

两类方向值得分开看。一类是离硬件和系统更近的方向，判断依赖真实约束，工具能加速但难替代对约束的理解；另一类是离评测、工具链、工程效率更近的方向，价值在于把工具产出变成可信结果。两者都不保证安全，但关注点不同：前者看你对底层约束的掌握程度，后者看你能否定义“什么算对”。

面试转岗方向时，怎么问清团队真实的工作内容与变化节奏？

把“这个岗位做什么”拆成能验证的问题，比问“前景好不好”有用得多：

  • 最近半年团队的主要交付物是什么，和一年前相比变了哪些？
  • 哪些环节已经交给工具，人在这部分实际做什么？
  • 新人前三个月通常产出什么，是独立负责一块还是配合他人？
  • 团队怎么看待工具对工作内容的影响，有没有因此调整分工？

对方的回答比岗位名称更能说明问题。如果回答含糊，或者只说“我们也在探索”，那本身就是信息。那位工程师在补充说明里讲，写文章不是表达失业焦虑，而是和过去手写算子的时光说再见——这句话对转岗者的启发是：告别一个具体做法，不等于告别整个能力。

一个实际可做的小建议：挑一个你正在做的任务，写下其中哪些步骤已经能交给工具、哪些判断只有你能做，再拿这份清单去对照目标岗位的描述，看它要的到底是执行还是判断。