最近有人问，AI 是否正在杀死长期主义。
普通人现在面对的困难，已经不只是「怎样坚持」，而是「根本不知道什么值得坚持」。一个开发工程师今天选 Java、Rust、AI Infra 还是 Agent？刚把一个框架学熟，模型换代了；刚把岗位路线想清楚，公司的招聘要求又变了。坚持十年听起来仍然正确，问题是没有人能替他证明，眼前这件事十年后还值钱。
世界经济论坛对一千多家企业的调查预计，2025 到 2030 年间，劳动者现有技能组合中平均有 39% 将发生变化或变得过时。1 当技能的半衰期变短，靠「先选中正确方向，再稳定积累」规划整个职业生涯，就越来越站不住了。
被杀死的是知识存量型长期主义
过去，一个工程师花几年掌握框架、API、设计模式和工程细节，这批知识本身就是资产。别人不会，他会；别人要查半天，他能直接写出来。熟练度可以稳定地换成工资。
现在，模型几秒钟就能吐出标准算法、接口调用、配置文件和常见架构。凡是能够完整写进教材、文档、Stack Overflow 答案或 benchmark 的知识，都在被快速压缩。它们仍然有用，却不再天然稀缺。
如果长期主义指的是，在一个封闭而稳定的知识体系里不断深挖，以后持续领取技能溢价，那么 AI 的确正在杀死它。
被压低价格的主要是知识存量。多年实践还会留下另一种资产。
一个完全不懂数据库的人也能让模型写出分布式服务，代码甚至能跑。真正懂数据库的人看到某个并发路径，会追问事务边界、隔离级别、复制延迟和故障恢复。他不一定比模型记得更多参数，却知道应该怀疑什么，知道哪个 consistency model 会在哪条异常路径上出问题。
做 Agent 也是如此。模型可以写出一套 LangGraph workflow，演示结束以后，难题才真正出现。为什么线上任务不稳定？问题来自模型、Harness、context 还是任务分解？为什么 benchmark 有九十分，真实用户只觉得勉强可用？哪些信息应该交给模型，哪些约束必须写进系统？这些问题在 痛定思痛，AI Agent 给我的教训 和 相比层出不穷的 Agent 框架，不变的 Agent Protocol 是什么 里反复出现。
工具熟练度不再稀缺以后，能不能把东西真的做出来，能不能解释它为什么工作、为什么失败，价格反而会上升。AI 吃掉的主要是那批可描述、可重复的实现工作。
没有人能先选出十年的正确答案
系统思维、判断力、学习能力当然重要，但招聘市场不会发布一个「适应变化工程师」岗位。HR 仍然要看你今天能交付什么，公司仍然按具体岗位付钱。
普通人必须有一项当前能交换价值的技能。后端开发、数据工程、AI 应用、Agent 工程、安全，都可以成为职业锚点。这个锚点必须回答一个眼前的问题——别人为什么愿意为我的工作付钱？
只是不要把锚点误认成终身身份。
职业投入可以按不同时间尺度处理。问题定义、系统设计、debug、验证、沟通、领域经验、信誉和作品，值得按五到十年积累。市场定位每一两年要重新检查，例如从传统后端移动到 AI-native backend，再到可靠的 Agent 系统。Claude Code、Codex、MCP、某个新模型或框架，只给一到三个月做小额试验。有用就继续加注，失去价值就停。
我愿意把这种安排叫作「二阶长期主义」。工作和技术可以更换，十年里反复做的是寻找、验证并加注更有价值的方向。投资者不会因为长期投资，就在 2010 年买下一家公司后永不复核事实；职业选择也不该和一个岗位名称结婚。
适应变化是一套硬机制
「适应变化」听起来像一句公司文化墙标语。落到工作里，就是面对陌生领域，快速建立一个有效模型，再用真实反馈不断修正。
假设明天又出现一个新的 Agent 框架。最容易走的路径是看教程、记 API、复刻演示，再收集一批最佳实践。两个月后框架失去维护，这批知识也跟着大幅折旧。
更有价值的做法，是先问它解决了什么旧问题，改变了哪些假设，哪些只是包装，哪些属于 Agent runtime 的稳定边界。然后拿一个真实而有限的任务去跑，不等到全部学完。让它接入现有数据，记录延迟、失败率、恢复方式和人工介入点，再和旧方案比较。失败以后继续追问，是抽象错了、上下文不够、工具不可靠，还是评价标准一开始就没写清楚。
这样学到的内容不只属于那个框架。状态管理、上下文构造、工具执行、权限边界、评测和故障恢复，会迁移到下一套系统。框架消失了，心智模型还在。
适应得快的人不一定读得更快。他往往只是更早动手，更快拿到反馈，也更快知道自己错了。
代码变便宜以后，工程才露出来
开发工程师一直在把模糊的现实问题，变成能够稳定运行、能够验证对错的计算系统。敲下某种语法只是其中一段工作。
产品说「搜索效果不好」，模型可以立刻改一版代码。工程师还得问，所谓不好究竟是召回不足、排序错误、查询理解偏了，还是用户的预期根本没有被定义；随后建立指标，拆开数据、检索和展示链路，设计实验，观察线上反馈，再修正最初的判断。
从一句模糊的抱怨到一次可验证的改动，中间要经过问题定义、因果推断、系统分解、实现、验证和反馈。AI 正在压缩实现那一段，却没有替任何人决定什么算对，也没有替线上事故承担责任。
GitHub 在 2026 年把开发者角色的变化概括为从 coder 转向 orchestrator：工程师开始负责代码如何被提出、验证、review 和交付，智能体的输出进入确定性的测试、扫描和分支保护。2 这个说法带着产品立场，但它点中了一个真实变化。生成代码越便宜，定义边界和证明正确的成本越显眼。
Anthropic 同年的使用研究也看到，Claude Code 中的任务比聊天产品获得了更多自主权；超过三分之一的受访者预期自己或同事的工作职责会在一年内显著变化。工作经验更长的人则更常提到判断、上下文和情境推理，这些默会知识很难直接交给模型。3
企业以后是否还需要「Agent Engineer」这个职位名，没有人知道。企业会继续需要人把新的计算能力接进真实业务，给它数据和权限，限制成本和风险，判断结果是否可信，出问题时接手，最后把东西上线。职位名会换，这份责任不会立刻消失。
一套可以马上执行的做法
先写下一句具体的职业锚点。别写「保持竞争力」，写一个别人能购买的结果，例如「我能把 AI 接入复杂业务系统，并让它在可观测、可评测的约束下运行」。这句话不要求十年不变，只需要对今天的市场成立。
给新方向设置短周期试验。四到八周完成一个真实产物，提前写下成功标准和停止条件。没有真实用户，也至少要有可重复的任务集、失败样本和对照方案。读完十篇教程不算反馈，一个用户拒绝使用、一次回归测试失败、一个成本数字超标才算。
积累也要从「我学过什么」转向「我验证过什么」。保留上线过的作品、失败案例、eval、取舍记录和修改前后的结果。工具名称会迅速过期，这些证据能告诉下一家公司，也告诉未来的自己，面对陌生问题时，你怎样形成判断，又怎样承认判断错了。
两个月后，那个新框架也许已经无人维护，仓库里的演示项目甚至应该删掉。只要你还说得清它在哪个约束下失败、下一次准备怎样更快验证，那两个月就没有全部折旧。