AI 让技术平权了。谁都能靠 prompt，搭出一个能跑的东西。但计算机专业的学生，花了四年。从编程语言学到算法，再到软件工程，啃完一整套系统性课程。这套训练，在 AI 时代还有必要吗？这篇文章带你了解其中的差异。
计算机系的课程表，还能适应 AI 时代吗？
过去几十年，计算机科学有一条清晰的路径。学语法 → 学算法 → 学系统设计 → 进大厂做软件工程师。同一段代码，同样的输入，永远得到同样的输出。这条流水线，曾经很好用。
但它正在断裂。
不是因为 AI 替你写代码。是因为写代码这件事，意义变了。几十年来，软件工程就是给计算机写显式指令。每一步、每个分支、每个边界条件，都手动定义。现在，不再是把每行逻辑亲手敲进去的人。变成了描述目标、设置约束、验证输出的人。工程精力的投放方向，变了。
确定性 vs 概率性
传统软件工程的根基，是确定性。
你写if (balance < amount) throw new Error('余额不足')。这段逻辑，今天跑一百次，明天跑一百次，行为一致。Bug 可追溯。一个错的条件判断、一个漏的状态转换、一处边界值没处理。你总能沿着调用栈找到它。每一步都是预定义的。
LLM 进来之后，情况变了。
你不再写具体的判断逻辑。你说：「如果余额不足，告诉用户原因，给三种补救选项。」AI 去解释这个目标。它可能今天给三个选项，明天给五个。措辞每次不同。正确不是非黑即白。正确是「看起来对」。这些系统不再只执行僵化逻辑。而是解释目标。
一旦你把这种概率性输出，接上记忆、工具调用、规划和反馈循环。你就不再是调一个模型。而是在管一个 agent。
Write Behavior → Shape Behavior（编写行为 → 塑造行为）
从高层次看。传统软件工程里，开发者编写行为（write behavior）。在 agentic engineering 里，开发者塑造行为（shape behavior）。本质，是从确定性逻辑，转向概率性判断。
这个词拆开来看，更清楚。
Agentic指的是：一群 agent 写代码。人类开发者监督和验证输出。Agent 或多 agent 系统迭代子任务时，始终保持人在环中（human in the loop）。
Engineering指的是：用 agentic 工作流做正经代码生产。需要一定专业水平。不能危及代码质量。
两者加在一起：AI 负责执行。你负责编排和验证。工程素养没有消失。只是作用的位置变了。
一张光谱，五个位置
AI 编程领域，每年都造新词。2024 到 2026，就有 AI-assisted coding、vibe coding、agentic coding、agentic engineering。很容易搞混。
与其纠结分类，不如把它们看成一个光谱。不是从差到好。是按「人类保留多少控制力 vs 系统获得多少自主权」排列：
阶段 | 谁主导 | 典型场景 |
|---|---|---|
Traditional SE | 人写每一行 | 所有逻辑显式定义，AI 最多辅助，人在架构和决策上完全掌控 |
AI-Assisted Coding | 人主导，AI 辅助 | Copilot 补全、重构、生成代码片段，开发者仍主导整体实现 |
Vibe Coding | 人描述意图，AI 生成 | 自然语言描述意图，迭代塑造结果，焦点从精确实现转向创意方向和快速实验 |
Agentic Coding | AI 自主规划+执行 | 系统自主规划任务、使用工具、写代码跑测试、调试失败，有限监督下迭代 |
Agentic Engineering | 人编排+监督 | 超越代码生成，设计让自主系统推理、协调、评估、动态适应的环境 |
重点：这些不是硬性分类。这些术语互相渗透。大多数团队从 vibe coding 起步，快速验证想法原型。随着风险和复杂度增加，逐步演进到 agentic coding。最终到 agentic engineering。
AI 越自主，人越重要
一个常见误解：agentic 系统越强，对人的要求越低。
正好相反。
传统系统故障是可预测的。有 bug？顺着调用栈往下追，总能定位到某个错误的条件判断、状态转换或实现细节。Agentic 系统不一样。它以概率方式运行。可能看起来完全正确，却在表面之下做着有缺陷的决策。幻觉、误解意图、误用工具、生成语法正确但架构糟糕的方案。它不会报一个漂亮的NullPointerException。它悄悄做错了。
所以 agentic engineering 的关键技能，不是写代码。是两个动作：
- Orchestrate（编排）
：定义 agent 能做什么、不能做什么、在什么约束下运行。
- Verify（验证）
：确认 agent 的输出，不仅在语法上正确，架构、安全、性能上也对。
工程瓶颈，从「写得不够快」，变成了「管得不够严」。
这也解释了开发者社区对这个转变的复杂反应。有些人把这当机会。终于可以把时间花在更有思想深度、更有成就感的工作上。另一些人持怀疑态度。这种怀疑有道理。确定性系统的故障方式，你熟悉。概率性系统的故障方式，你还没习惯。
Agentic 系统应该加速开发。不是取代工程专业能力。这或许意味着需要一种新文化。鼓励实验，同时保持问责。
Vibe Coding 为什么成不了规模
Vibe coding 在原型阶段极其高效。描述意图，看结果。不满意，再描述。极度适合探索。
到了规模化生产，三个问题暴露：
- 无结构
。AI 生成的代码，没有统一架构约束。每次生成的结果，互相不一致。
- 无测试
。vibe coding 的工作流，天然跳过 Red-Green 循环。你不知道它哪里会挂。
- 无一致性
。三个 prompt 生成三次，三次实现方式完全不同。维护成本指数上升。
这就是 agentic engineering 这个词存在的原因。它强调 engineering 还在。不是要取代软件工程。是扩展一个新的抽象层。Agentic engineering 改变的，是工程师把大部分时间，花在工程化什么东西上。
开发者的下一站
如果你在看这个变化，有些不安。正常的。确定性系统的故障方式可预测。概率性系统，在最不可预测的方式下悄悄出错。
但方向很清楚：
写代码 → 设计代码 → 塑造 AI 行为 → 监督 AI 系统每一层都还在。你只是在往上移。
不确定从哪开始？从小处开始。在现有工作流里，引入一个 AI 辅助工具。观察它哪里帮你、哪里帮倒忙。然后从这里迭代。
最重要的一条：不要用自动化替代理解和质量。让 AI 写更快，不是目的。让 AI 在你的判断和监督下写得更正确，才是。
小结
Agentic Engineering 不是一个 buzzword（流行词）。它是一个光谱的尽头。从亲手写每一行代码，到设计让 AI 写好代码的环境和约束。
记住两点：
光谱思维，替代二分法。别问「AI 编程好还是不好」。问「你在光谱的哪个位置」。
AI 越自主，工程素养越重要。概率性系统的故障，比确定性系统更难发现、更难修复。
