一条自述，为什么值得求职者认真读

消息提到，DeepSeek 内核工程师刘胜与在博客中称，自己所热爱的内核工作即将被自己的成果淘汰，并为此感到挣扎；他还用“希特勒先于盟军获得原子弹”来比喻让 Anthropic 控制 AI 的风险。推文作者认同其观点，认为资源正被过快消耗，必须保持开放。这些是个人观点，不代表公司立场，也无法据此判断行业整体的替代速度。但对正在选底层系统方向的程序员来说，它提供了一个真实的提问起点：你做的工具，会不会先改变你自己的岗位内容？

面试时，怎么问出岗位的长期性

不要只问“用什么技术栈”。可以问团队过去两年岗位内容发生了哪些变化，哪些工作从人工变成了工具自动完成，哪些反而变多了。

同一件内核调试任务，两种做法差别很大：一种是把已知问题写成脚本反复跑，另一种是面对陌生崩溃，从日志、内存布局和调用链里定位根因。前者容易被工具吸收，后者更依赖对系统的理解。面试时你可以追问：这个岗位日常更偏哪一类？团队如何划分“构建工具”和“使用工具”的职责？

如果对方只强调内部工具链熟练度，却说不清问题定位和设计决策由谁负责，这个岗位的可迁移性就值得再确认。

哪些能力更值得优先积累

假设一个场景：你负责的模块被自动化覆盖了，接下来你能做什么？如果答案是“只能等新工具”，说明能力绑得太窄；如果能转向相邻系统方向，比如性能分析、资源调度或稳定性治理，迁移空间就更大。

优先积累跨系统的问题定位、性能分析和抽象设计能力。它们不依赖某一套内部工具，换团队、换系统仍然用得上。反过来，只绑定某套内部工具链的经验，在岗位内容变化时议价空间会变小。

看到“资源被过快消耗”这类观点，求职者该核查什么？把它当提问素材，而不是行业结论。可以问目标团队的实际资源投入方式、开源策略和人员分工，看这些是否与你的判断一致。

一个实际可做的小建议：下次面试前，写下三个你希望向面试官确认的问题，围绕“过去两年岗位内容变化”“工具与人的职责边界”“相邻方向迁移路径”，带着它们去聊。

本文为求职分析，不构成对任何公司或行业趋势的判断。