智能化工程的 8 个段位：你的团队卡在哪一层？

一句话总结：智能化工程的 8 个段位不是用来「打怪升级」的，而是用来照镜子的——真正决定团队上限的是 3-5 层这块地基（上下文工程、复利工程、MCP 与技能），跳过地基去追后台智能体和多智能体团队，都是空中楼阁。

开场：AI 跑得快，人却没跟上

过去一两年，Claude Code、Codex、Cursor 这类工具的编程能力进步得飞快。但坦白说，绝大多数团队驾驭 AI 的水平没跟上，而且这个差距正在被不断拉大。已经掌握 AI 工具的团队，生产力是飞跃式提升；大量团队还停留在「装了 Copilot、偶尔让它补几行」的初级阶段。

注意先把名词分清楚。Agent Engineering（智能体工程） 关心的是怎么把一个智能体从「能跑」做到「好用」，覆盖构建、测试、观测、迭代；Agentic Engineering（智能化工程） 关心的完全不一样——它问的是：一个团队怎么用智能化工具来展开软件工程。两者互补，前者把智能体做扎实，后者帮团队看清自己现在处在哪一档，下一步往哪走。

那么团队该怎么自检？答案是一句话：沿着 8 个递进层级照镜子，重点补 3-5 层的地基。下面分三段展开：先走完八层全貌，再点出地基为什么是地基，最后总结落地原则。

金字塔总览

mindmap
  root((智能化工程<br/>8 个段位))
    入门两层
      1 代码补全
      2 智能 IDE
    地基三层 核心
      3 上下文工程
      4 复利工程
      5 MCP 与技能
    进阶三层
      6 运行环境工程
      7 后台智能体
      8 自主智能体团队
    跨层原则
      乘数效应 短板木桶
      实现与审查分离
      约束优于指令

一、入门两层：代码补全 与 智能 IDE

第一层：代码补全。最早期的 Copilot 形态——你敲几个字，它帮你补一段。本质上是在已有的代码结构里做填充，对开发者起辅助作用。这也是大多数人第一次接触 AI 编程的入口。

第二层：智能 IDE。代表作 Cursor。比单纯补全强的地方是：能跨文件编辑，后来又有了计划模式，可以做任务拆解、一步步执行。从这一层开始，Agent 的概念其实就已经被引入了——所以叫 Agentic Engineering，和智能 IDE 的演化是密不可分的。

听众里看视频的人，大概都会用这两层。但作者要点出的现实是：绝大部分开发者还停留在这里，对 AI 没感知、不会很好地使用，甚至连 Cursor 都没碰过。第一件事是帮身边的伙伴从这一档走出来。

金句：第一层和第二层不是终点，而是起点；多数开发者甚至连起点都没站稳。

二、地基三层：上下文工程、复利工程、MCP 与技能

这一层是全篇最重要的部分。 作者反复强调：如果你只记得这一篇视频的一件事，就记住地基这三层。后面三层再炫，没这块地基都是空中楼阁。

2.1 第三层 · 上下文工程：每个 token 都要为自己争位置

「你喂给 AI 什么信息，决定了它最终能产出什么质量的结果」。上下文工程要做好三件事：

一句话：让正确的上下文，出现在正确的时刻。

2.2 第四层 · 复利工程：让经验越滚越多

复利工程（Compounding Engineering）的核心矛盾是：大模型本身没有状态。计划-委派-评估-固化看起来很简单，但你需要主动建立一个循环学习的机制，让每一轮的经验能被沉淀下来、在下一轮被用上。

flowchart LR
    A[计划] --> B[委派 AI 执行]
    B --> C[人/压测评估]
    C --> D[固化到规则文件]
    D --> A

具体做法：形成机制去更新规则文件（cursor rules、CLAUDE.md 这类经验性文件），整理它们的目录，并且确保下一次对话能用上。这本质上是一个数据问题——经验文件就是你最重要的资产。

2.3 第五层 · MCP 与技能：让 AI 不只「看得到」，还能「做得到」

前两层解决的是 AI 能看到什么，这一层解决的是 AI 能做什么。

• MCP：标准化的工具调用协议。让大模型连数据库、调 API、跑流水线、发飞书钉钉消息。
• Skills：不只是工具的能力，还能把流程化的经验描述下来，形成 SOP——一份定制化的标准工作流程。

一个典型案例：一个 PR 提交后，自动触发多个子智能体——有的查数据库、有的看代码复杂度、有的检查提示词，整条链路自动化。背后隐含的就是大量 MCP 提供数据查询能力 + Skills 提供 SOP 指导。

行业方向上，讨论正在逐步偏向 Skills——因为它更接近 CLI 思维，灵活度更高，但 MCP 也没被替代，两者还在共存演化。

2.4 为什么这三层是地基

作者刻意在讲完第五层后停下来强调：

如果上下文有了噪音，到高层会被放大；提示词不确定，智能体会跑偏；工具描述不准，后面的调用都无从谈起。

后面三层全是更复杂的智能体交互与编排——没有地基，越往上越塌。

金句：3-5 层是地基，6-8 层是楼。地基不稳，楼盖得越高摔得越惨。

三、进阶三层：运行环境、后台智能体、自主团队

3.1 第六层 · 运行环境工程（Harness Engineering）

Harness 这个词最近被到处用，定义还没收敛。作者这里特指两件具体的事：

反压（Back Pressure）。这个词从流体力学借过来——水流太猛，管道会产生反向阻力。放到智能体场景里，反压指的是主动设置阻力点，不是被动受压。智能体如果什么阻力都没有就让它一路流过去，会马上撞上一堆问题。要设置的阻力包括：类型检查、测试、linter、静态检查、pre-commit hook。关键是这些阻力点要形成闭环——智能体被拦住后能自己修正。

可观测性。日志、tracing、指标全要能看到、能被审计。否则你根本无法判断智能体到底在干什么——尤其在企业场景里，没有可观测性就没有信任。顺带一提：现在 Claude Code 这类产品在可观测性方面其实还有巨大进步空间，要把它落地到企业生产环境，可观测性是必须解决的硬问题。

3.2 第七层 · 后台智能体：从「人盯着」到「无人值守」

前六层有个共同特征：你得人盯着它干活。到第七层就变了——你不在的时候，工作也要往前推进。最直观的产品就是 Claude Code 的后台模式，发一个消息给它，它在后台帮你做完一堆事，等做完再把消息推送给你。这种模式让人有种被「降维打击」的感觉，似乎一下从第二层跳到了第七层。

但作者明确警告：不能跳级。第七层之前你必须有第六层的地基——反压和可观测性。否则智能体在你看不到的地方烧 token 是小事，关键是你根本不知道它是真的把事做成了，还是弄虚作假糊弄你。这一层还隐含了「编排器」的概念——做得好的系统至少要有 implementer agent + reviewer agent，把实现和审查分开。

3.3 第八层 · 自主智能体团队：去中心化的多智能体协作

代表是 Claude Code 最近的 Agent Teams。核心特征是去中心化——智能体之间可以直接协调认领任务、发现依赖、互相 hand-off，不再是「要么有 supervisor、要么纯 hand-off」的简单模式。

坦白说，目前没有一家能玩得很好。即便用最好的模型驱动 Claude Code，多智能体协作依旧容易出错。这是发展方向，但还需要时间和更强的模型来推动。

金句：第七、八层是趋势，但它们的可靠性建立在地基（3-5 层）和品控（第六层）之上——跳级追新只会让自己更狼狈。

四、跨层的关键：乘数效应与七条原则

讲完层级后，作者抛出一个比层级本身更重要的概念——乘数效应。

它本质上是木桶原理。如果团队里有人玩到第七层、还有人停在第二层连 cursor rules 都没玩明白，团队整体能力会被最低水平的人卡住。你不能光看某些人提升得好，要看整个团队的最低水平。要真正加速，必须把短板拉起来——「手拉手一起往上走」。

这呼应了作者给出的七条原则：

一页速览

一句话收束

别盯着最高那一层看——回头看看你团队的最低那一层；地基不稳，所有的高级玩法都是给自己挖的坑。