Prompt Engineering 正在变成"汇编语言"

---

2024 年，如果你不会写 Prompt，你就不算懂 AI。

2025 年，如果你只会写 Prompt，你就只能做 Demo。

2026 年，如果你还在写 Prompt，你可能正在做一件 10 年前还在手写 SQL 的事。

这不是危言耸听。这是正在发生的事情。

---

一场 820 万人围观的"葬礼"

2026 年 3 月，一个叫 Harrison Steinberger 的工程师在 X（原 Twitter）上发了一篇长帖，标题是：

"Prompt Engineering is dead. Loop Engineering is the future."

820 万阅读。3.2 万转发。评论区吵成了一锅粥。

他的核心观点只有一句话：

"Prompt Engineering 的本质是'一次性告诉 AI 该怎么做'。但在 Agent 时代，AI 不是执行一次就结束------它在一个循环里反复执行、观察、修正。你需要的不是一个完美的 Prompt，而是一个完美的 Loop。"

这话说得狠，但说得对。

让我们把时间线拉开来看。

2023 年，ChatGPT 刚出来，所有人的注意力都在 Prompt 上。怎么写出更好的 Prompt？用什么技巧能让 GPT 输出更准确？"Prompt Engineering"成了一门显学，甚至有人把它当成一个独立的职业方向。

2024 年，RAG 火了。人们发现，与其在 Prompt 里塞一堆背景知识，不如让 AI 自己去检索。Prompt 的角色开始从"知识载体"变成"指令载体"。

2025 年 ，Agent 框架爆发。LangChain、AutoGen、CrewAI、Claude Code......每个框架的核心都不是"怎么写 Prompt"，而是"怎么设计执行循环"。ReAct、Plan-and-Execute、Reflexion------这些模式的名字不一样，但本质相同：AI 在一个循环里反复思考、行动、观察、修正。

2026 年，这个趋势已经不可逆转。

Prompt Engineering 没有"死"------就像汇编语言没有"死"一样。它只是从"主流技能"变成了"底层知识"。你不需要每天写它，但你需要理解它。

而 Loop Engineering，正在成为新的主流技能。

---

什么是 Loop Engineering？

先说清楚定义。

Prompt Engineering：设计一个静态的提示词，让 AI 在一次调用中产生期望的输出。

Loop Engineering：设计一个动态的执行循环，让 AI 在多步迭代中逐步逼近目标。

两者的区别，用一句话说就是：

Prompt Engineering 是写菜谱。你告诉 AI "先放油，再放蒜，再放肉，炒 3 分钟"。AI 按照你的菜谱执行一次，不管结果好不好。

Loop Engineering 是设计厨房。你告诉 AI "做一道好吃的菜"，然后给它一个循环：做菜 → 尝一口 → 不好吃就调整 → 再尝一口 → 直到好吃为止。

前者是一次性的、确定性的、人类驱动的。

后者是迭代性的、自适应的、AI 驱动的。

---

为什么这个转变是必然的？

这不是某个人的主观偏好。这是技术演进的必然结果。

让我用三个历史类比来解释。

类比一：从汇编到高级语言

1950 年代，程序员直接写机器码。每个指令都是手工编写的，精确到寄存器和内存地址。

后来有了汇编语言，稍微抽象了一层，但本质上还是"告诉 CPU 每一步该做什么"。

再后来有了 C 语言、Java、Python------你不再需要告诉 CPU 每一步该做什么，你只需要描述"我想要什么结果"，编译器/解释器会帮你生成具体的执行步骤。

Prompt Engineering 就像汇编语言：你需要精确地告诉 AI 每一步该怎么做。

Loop Engineering 就像高级语言：你描述目标，设计循环，让 AI 自己决定每一步该怎么做。

汇编语言没有"死"。但 99% 的程序员不需要每天写它。

Prompt Engineering 也不会"死"。但 99% 的 AI 应用不需要手工调 Prompt。

类比二：从手动运维到 DevOps

2010 年之前，运维工程师的工作是：登录服务器，手动执行命令，修改配置文件，重启服务。

每个操作都是手工的，每个操作都依赖运维工程师的经验。

后来有了 DevOps、有了 Ansible、有了 Kubernetes。运维的工作从"手动执行操作"变成了"设计自动化流程"。

你不再需要手动重启服务，你设计一个健康检查循环：检查 → 不健康 → 重启 → 再检查 → 直到健康为止。

Prompt Engineering 就像手动运维：每次都要人工介入，每次都要手工调整。

Loop Engineering 就像 DevOps：设计好循环，让系统自己运转。

手动运维没有"死"。但在生产环境里，没有人还在手动重启服务。

类比三：从 SQL 到 ORM

2005 年之前，每个 Java 程序员都要手写 SQL。SELECT、JOIN、WHERE------每个查询都是手工拼接的。

后来有了 Hibernate、MyBatis、JPA。你不再需要手写 SQL，你只需要描述"我想要什么数据"，ORM 框架会帮你生成 SQL。

手写 SQL 没有"死"。但在日常开发中，90% 的查询都不需要手写 SQL 了。

Prompt Engineering 就像手写 SQL：每次都要精确描述"怎么查"。

Loop Engineering 就像 ORM：描述"想要什么"，让框架决定"怎么查"。

---

证据：行业已经在转向

这不是理论推演。这是正在发生的事实。

证据一：Claude Code 的 100% 自主运行

Anthropic 的 Claude Code 是一个 AI 编程工具。它的核心不是"一个完美的 Prompt"，而是一个执行循环：

用户输入任务 → Agent 理解任务 → Agent 制定计划 → Agent 执行步骤 → Agent 观察结果 → Agent 修正计划 → 循环直到任务完成

在这个过程中，Agent 会自主调用工具（读文件、写文件、运行命令、搜索代码），自主决定下一步该做什么。

人类只需要提供一个初始的"任务描述"，剩下的全靠 Loop。

证据二：57% 的企业已经部署多步 Agent 工作流

根据 2026 年初的一份行业调研，57% 的企业已经部署了"多步 Agent 工作流"------也就是基于循环的 AI 应用。

这些工作流的共同特征是：

• 不是一次性调用，而是多步迭代
• 不是人类控制每一步，而是 AI 自主决策
• 不是静态 Prompt，而是动态循环

证据三：主流 Agent 框架的核心都是 Loop

框架	核心模式	本质
LangGraph	状态图 + 循环	条件循环
AutoGen	多 Agent 对话	对话循环
CrewAI	任务编排	任务循环
Claude Code	ReAct	思考-行动循环
Devin	规划-执行	规划-执行循环

名字不一样，但本质相同：AI 在一个循环里反复执行、观察、修正。

---

从 Prompt 到 Loop：你需要的 5 个新技能

如果你是一个 Prompt Engineer，想要转型为 Loop Engineer，你需要掌握 5 个新技能。

这些技能不是"替代"Prompt Engineering，而是在它的基础上叠加新的能力。

技能一：循环设计（Loop Design）

核心问题：如何设计一个有效的执行循环？

一个好的循环需要回答三个问题：

1. 循环的入口是什么？ --- AI 从哪里开始？
2. 循环的退出条件是什么？ --- AI 什么时候停止？
3. 循环的修正机制是什么？ --- AI 走错了怎么办？

# 一个简单但有效的循环模板
def agent_loop(task, max_iterations=10):
    context = initialize_context(task)
    
    for i in range(max_iterations):
        # 思考：当前状态是什么？下一步该做什么？
        thought = llm.think(context)
        
        # 行动：执行一个工具调用
        action = llm.decide_action(thought)
        result = execute_tool(action)
        
        # 观察：结果是什么？
        context.update(result)
        
        # 判断：任务完成了吗？
        if is_task_complete(context):
            return context.final_answer
        
        # 修正：如果走错了，调整策略
        if is_error(result):
            context = recover(context, result)
    
    return "达到最大迭代次数，任务未完成"

关键洞察：循环设计的核心不是"让 AI 做更多的事"，而是"让 AI 能够自我修正"。

技能二：状态管理（State Management）

核心问题：如何在循环中维护状态？

在 Prompt Engineering 中，状态很简单：就是当前的 Prompt + 历史对话。

在 Loop Engineering 中，状态变得复杂：

• 当前任务进度
• 已经尝试过的策略
• 已经获取的信息
• 已经犯过的错误

你需要设计一个状态管理系统，让 AI 在循环中能够"记住"之前的经验。

class AgentState:
    def __init__(self):
        self.task = None  # 当前任务
        self.progress = 0.0  # 进度百分比
        self.attempts = []  # 已经尝试过的策略
        self.errors = []  # 已经犯过的错误
        self.knowledge = {}  # 已经获取的信息
    
    def should_retry(self, strategy):
        """避免重复尝试失败的策略"""
        return strategy not in self.attempts
    
    def learn_from_error(self, error):
        """从错误中学习，避免重蹈覆辙"""
        self.errors.append(error)
        self.attempts.append(error.strategy)

关键洞察：状态管理的核心不是"存储更多信息"，而是"让 AI 能够从过去的经验中学习"。

技能三：工具编排（Tool Orchestration）

核心问题：如何让 AI 在循环中智能地选择工具？

在 Prompt Engineering 中，工具调用是线性的：先调用 A，再调用 B，最后调用 C。

在 Loop Engineering 中，工具调用是动态的：AI 根据当前状态，自主决定调用哪个工具。

# 工具编排不是"预设流程"，而是"动态决策"
def select_tool(state):
    if state.needs_information:
        return search_tool
    elif state.needs_to_modify:
        return edit_tool
    elif state.needs_to_verify:
        return test_tool
    else:
        return none  # 不需要工具，直接生成答案

关键洞察：工具编排的核心不是"连接更多工具"，而是"让 AI 知道什么时候用什么工具"。

技能四：错误恢复（Error Recovery）

核心问题：如何在循环中处理错误？

在 Prompt Engineering 中，错误处理很简单：如果 AI 输出错误，就重新生成一次。

在 Loop Engineering 中，错误处理变得复杂：

• 工具调用失败了怎么办？
• AI 走进了死胡同怎么办？
• 循环卡住了怎么办？

你需要设计一个错误恢复机制，让 AI 能够从错误中恢复，而不是直接崩溃。

def handle_error(state, error):
    if error.is_retryable:
        # 可重试的错误：换个策略再试
        state.attempts.append(error.strategy)
        return state.with_alternative_strategy()
    
    elif error.is_recoverable:
        # 可恢复的错误：回退到上一个稳定状态
        return state.rollback_to_checkpoint()
    
    else:
        # 不可恢复的错误：报告失败，请求人类介入
        return escalate_to_human(state, error)

关键洞察：错误恢复的核心不是"避免错误"，而是"让 AI 能够从错误中学习并继续前进"。

技能五：循环评估（Loop Evaluation）

核心问题：如何评估一个循环的效果？

在 Prompt Engineering 中，评估很简单：看 AI 的输出是否符合预期。

在 Loop Engineering 中，评估变得复杂：

• 循环收敛了吗？（AI 是否在逐步逼近目标？）
• 循环效率如何？（用了多少步？花了多少 Token？）
• 循环稳定性如何？（多次运行的结果是否一致？）

def evaluate_loop(loop_runs):
    metrics = {
        "convergence_rate": calculate_convergence(loop_runs),
        "efficiency": calculate_avg_steps(loop_runs),
        "stability": calculate_variance(loop_runs),
        "success_rate": calculate_success_rate(loop_runs),
    }
    
    if metrics["convergence_rate"] < 0.8:
        print("警告：循环收敛速度慢，考虑优化循环设计")
    
    if metrics["efficiency"] > 20:
        print("警告：循环步数过多，考虑简化循环逻辑")
    
    if metrics["stability"] > 0.3:
        print("警告：循环结果不稳定，考虑增加确定性")
    
    return metrics

关键洞察：循环评估的核心不是"看最终结果"，而是"看循环过程是否健康"。

---

这对你意味着什么？

如果你是一个Prompt Engineer：

不要慌。Prompt Engineering 不会消失，就像汇编语言不会消失一样。但你需要开始学习 Loop Engineering。

具体来说：

• 学习 LangGraph 或 AutoGen，理解循环是如何工作的
• 学习状态管理，理解如何在循环中维护上下文
• 学习错误恢复，理解如何让 AI 从错误中学习

如果你是一个AI 产品经理：

你需要重新思考你的产品设计。

不要再问"怎么写一个更好的 Prompt"，而要问"怎么设计一个更好的循环"。

你的 AI 产品不应该是"一次性输出"，而应该是"迭代式逼近"。

如果你是一个技术负责人：

你需要重新思考你的团队技能矩阵。

Prompt Engineering 仍然重要，但 Loop Engineering 更重要。你需要有人懂循环设计、状态管理、错误恢复、循环评估。

---

写在最后

每一次技术范式的迁移，都伴随着阵痛。

从汇编到高级语言，程序员需要学习新的思维方式。

从手动运维到 DevOps，运维工程师需要学习新的工具链。

从手写 SQL 到 ORM，数据库工程师需要学习新的抽象层。

现在，从 Prompt Engineering 到 Loop Engineering，AI 工程师需要学习新的工程范式。

这不是"旧的死了，新的来了"。这是"旧的变成了底层，新的成为了主流"。

Prompt Engineering 不会消失。它会变成 Loop Engineering 的一部分------就像汇编语言变成了编译器的一部分。

但如果你只会 Prompt Engineering，你可能会像只会汇编语言的程序员一样------技术很扎实，但应用场景越来越窄。

2026 年的 AI 工程师，不是"会写 Prompt 的人"，而是"会设计 Loop 的人"。

这是一个新的时代。

欢迎来到 Loop Engineering 的世界。

---