AI 时代到底应该学什么

新名字换得太快

今年的热点已经换了好几茬。年初还在聊 Harness，年中变成 Loop Engineering，现在又开始讲 Graph Engineering。名字一个接一个，每个都说自己代表下一代工作方式。

一开始我也觉得这些都是全新领域，得一个一个从头学。后来再看，发现它们背后仍然是软件工程长期在处理的问题：复杂度怎么拆，协作怎么组织。变化主要在实现手段，以前靠人写代码、定流程，现在多了一层 AI 参与。

所以我的判断是，与其跟着名字追，不如先学那些不变、或者至少短期不会变的东西。底子有了，新概念来了再看它到底新在哪，反而会学得更快。

我为什么把 AI 工程看成管理问题

现在流行的 Vibe Coding 和各种 AI 工程化，拆开看都有很大一部分是在做管理。多个 Agent 协作，需要调度、分工和验收结果。光靠口头安排当然不够，还得用技术手段保证这些安排有效，这部分就会落到架构上。

这也是我经常建议组员去考系统架构师的原因。考证不会让架构水平马上上一个台阶，但它能逼着你把系统架构设计完整过一遍，逐渐建立「先看结构再看代码」的习惯。这个习惯在 AI 时代特别有用。通过 Vibe Coding 堆出来的应用起步很快，但复杂度一上来、需求开始迭代，没有架构能力兜底，项目大概率会失败。AI 可以生成代码，系统结构仍然需要有人把握。

软件工程的历史在重演

把这几年 AI 应用的发展和以前的软件工程史放在一起看，能看到很多相似的处理方式。

软件一开始是单体架构，复杂度上来以后开始拆服务。AI 应用也类似：最初在一个对话里处理所有事情，任务复杂以后，又拆出了 Sub Agent。
规模化之后就是复杂系统怎么管的问题。以前软件工程给出的答案是微服务、云原生、Kubernetes。最近 OpenAI 的一些动作也隐隐透出这个趋势，ChatGPT、Codex 都在往云端走，往规模化调度走。
安全治理也是如此。以前管服务之间的权限和攻击面，现在开始管 Agent 的权限和 AI 应用的安全。

以前写代码也是先垒上去再说，复杂度和规模上来以后，才逐渐出现云原生这一套：服务化、弹性、可观测性、韧性、自动化、零信任、可演化。最近的 AI 工程也在处理这些问题，只是对象换成了 Agent 和 AI 应用，实现上又多了让 AI 参与调度和决策。

我现在的学习策略

之前有个流行的梗：AI 时代只要你学得慢，就可以不用学，反正新技术很快过期。

我的看法正好相反。基础打得越牢，新技术来了越不用慌。每个新概念出来，都可以先用第一性原理拆开，再映射到软件工程已有的内容上。当然也有真正的新东西，比如模型能力本身的跃迁、上下文长度和推理成本，这些仍然要跟进。但在工程层面，工作流、编排和治理里的很多问题以前都出现过。

所以当前阶段，我还是准备先把软件工程和基础理论学扎实。新的概念出现以后，再判断其中哪些真的需要重新学。

下次再看到一个新概念，我准备用这三个问题过一遍，当成一个固定清单：

它解决的是什么老问题？
这个问题以前在软件工程里对应什么？
真正新的部分在哪？

答不上来，要么是我还没理解透，要么它就是换皮。