AI编程新趋势：从提示词工程迈向循环工程化

过去两年间，提及AI编程，人们最先想到的词汇是Prompt Engineering。

如何清晰地阐述需求？如何提供充分的背景信息？如何让AI一次性产出更可用的代码？这些问题固然关键。然而，随着AI编程智能体能力日益增强，真正的核心控制点正在悄然转移。

以往，我们与AI的协作模式更像是逐轮「发号施令」：你提交一段提示词，它反馈一段代码；你指出问题，它再修改一版。全程中，人类始终处于每一轮交互的起点位置。

而今，一种崭新的思路正在浮现：与其频繁手动引导智能体，不如构建一套系统，让系统自动完成任务发现、任务分配、结果校验、状态记录，并据此决定后续行动。

AI编程的核心能力，正从「撰写优质提示词」演进为「构建可持续运转的智能体工作体系」。

这一工程化新范式，便是近期备受关注的Loop Engineering。

Peter Steinberger近期提出过一个观点：

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

其核心含义是：你不应再单纯地向编程智能体发送提示，而应设计能够驱动智能体的循环机制。

Claude Code负责人Boris Cherny也表达了相近的看法：

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

这两句话指向同一个趋势：AI编程协作的重心，正从「人类反复输入Prompt」转向「人类设计持续运行的工作循环」。

为何会出现这种转变？

因为实际的软件开发绝非简单的问答交互。它涵盖需求澄清、方案设计、代码修改、测试验证、缺陷修复、文档维护、代码审查、发布跟进等环节。每一步都可能遭遇失败，每一步都需要反馈机制。

如果我们仍将AI视为「等待指令的工具」，那么人类的注意力将被困在每一个细节节点上。AI越强大，人类反而越容易陷入一种新型的微观操作：不断复制上下文、不断解释项目规则、不断询问下一步。

Loop Engineering正是要解决这一困境。

Prompt Engineering聚焦于「本轮如何提问更有效」，Loop Engineering则关注「整体流程如何持续优化」。

这并非意味着Prompt Engineering已经过时。提示词依然重要，只是它从核心位置退居到系统内部，成为循环中的一个组成模块。

如同编写代码时，单个函数固然重要，但真正决定系统质量的，是函数间的协作方式、状态流转机制、异常处理策略以及边界条件控制。

可以先给出一个简明定义：

Loop Engineering，是围绕AI编程智能体构建一套可重复执行、可观察追踪、可验证确认、可修正调整的工作循环。

这里的Loop，可理解为一个递归目标机制。你设定目标、上下文、工具权限和终止条件，AI在此边界内持续迭代，直至任务完成，或遇到需要人工判断的关键节点。

它关注的不只是「如何撰写提示词」，还包括这些更具工程化特征的问题：

这正是Loop Engineering与Prompt Engineering最显著的差异所在。

举例说明。

传统Prompt Engineering的问题形式可能是：「帮我解决这个登录失败的bug。」

Loop Engineering的问题形式则变为：「每日清晨读取前一天的CI失败记录与用户反馈，识别高优先级bug，为每个bug创建隔离工作区，生成修复方案，执行测试用例，失败后持续修正，通过后生成PR，并将无法处理的部分记录到待办清单。」

前者是一条指令，后者是一套系统。

Prompt Engineering解决的是单次回答的质量问题，Loop Engineering解决的是整个流程的可靠性问题。

正因如此，它更接近软件工程的范畴，而不仅仅是提示词技巧。你需要设计输入、输出、状态、权限、验证、异常处理和人工确认点。

换言之，Loop Engineering将AI编程从「对话艺术」进一步推向「系统设计」。

一个Loop大致需要五个核心组件，外加一层外部记忆层。

这六个组成部分分别是：Automations、Worktrees、Skills、Plugins / Connectors、Sub-agents，以及Memory。

先用一张表将它们放在一起审视：

Automation是让Loop真正「循环」起来的关键。

若缺乏自动触发机制，所谓Loop不过是手动执行了一次任务。只有当它能够按时间、事件或条件自动启动时，循环才拥有属于自己的节奏。

例如每日清晨自动检查CI失败、每隔一小时整理issue、每次PR更新后触发审查、每晚生成项目状态简报。这些任务本身并不复杂，却相当消耗注意力。

Automation的价值，在于将这些重复性的触发和发现动作交由系统处理。

在Codex中，可通过Automations标签页配置周期任务。在Claude Code中，也可通过scheduling、hooks、/loop、cron、GitHub Actions等方式实现类似功能。

更关键的是停止条件的设计。例如「所有auth测试通过，且lint整洁」。当循环拥有可验证的终点时，它就不再是盲目的重复尝试。

当多个agent同时修改同一个仓库时，最容易出问题的并非模型能力，而是文件冲突。

一个agent在重构登录逻辑，另一个agent在修复同一文件中的边界条件。如果它们共用同一个工作目录，结果很容易互相覆盖。

Git worktree的作用，就是为每个agent提供一个独立的checkout。它们共享同一份仓库历史，但在不同目录中工作。如此一来，不同尝试可以并行推进，彼此不直接污染。

然而，Worktrees只能解决机械冲突，无法解决人类的审查带宽限制。

你可以同时运行十个agent，但最终仍需有人判断哪个方案值得合并、哪个方案引入了隐患、哪个方案只是表面通过了测试。

许多人在使用AI编程工具时，都会遇到一个困扰：每次新建会话，都要重新解释项目背景。

我们使用什么框架？如何运行测试？哪些目录不能修改？这个模块为何不能重构？上次生产事故留下了什么约束？

如果这些信息只存在于人的脑海中，每一轮Loop都会重新猜测。

Skill的价值，在于将这些项目知识、开发约定、构建步骤、历史决策转化为外部能力。智能体每次执行任务时，都可以读取这些稳定上下文。

这相当于为Loop建立了一套项目操作手册。

没有Skills，Loop每轮都在重新理解项目；有了Skills，项目意图才能逐渐形成复利效应。

一个只能读写本地文件的Loop，其能力边界非常有限。

实际开发发生在更大的系统环境中：issue tracker、PR、CI、数据库、监控平台、Slack、Linear、Notion、内部API。代码只是其中一部分。

Plugins和Connectors的价值，在于让智能体接入这些真实的工具链。

当Loop能够读取issue、查询CI、打开PR、关联ticket、在测试通过后通知团队时，它就从「给你建议」转变为「参与流程」。

当然，连接真实系统也意味着更高风险。权限范围多大？能否写入生产数据？能否自动发送消息？能否修改ticket状态？这些都需要清晰的边界定义。

工具链连接越深，权限设计越要保守谨慎。

在无人值守的Loop中，最重要的结构之一，是将maker和checker分离。

编写代码的agent，不适合完全负责评价自己的代码。它很容易相信自己的假设，也容易把「测试刚好通过」误认为「问题已经解决」。

更稳妥的方式，是让一个agent负责实现，另一个agent负责审查。审查者可以采用不同提示词、不同模型、不同关注点，例如只关注安全风险、只关注边界条件、只关注是否符合规范。

这并不意味着sub-agent越多越好。每个agent都会消耗token，也会增加协调成本。

更合理的做法，是在高风险、高价值、需要第二判断的环节使用它们。例如架构变更、权限逻辑、数据迁移、支付链路、发布前审查。

最后一个看似朴素，却非常关键的部分，是Memory。

模型会遗忘，仓库不会。对于长周期任务，状态必须存在于对话之外。

这个Memory可以是一个Markdown文件，也可以是Linear board、issue列表、状态表、任务清单。它记录已经尝试过什么、哪些测试通过了、哪些问题尚未解决、下一轮应该从哪里继续。

没有Memory，Loop每次启动都像失忆。它可能重复处理同一个问题，忘记已经排除的方案，或者重新走一遍错误路径。

有了Memory，Loop才具备连续性。

将上述组件串联起来，一个典型Loop可能呈现这样的形态。

每日清晨，Automation自动在项目中运行。它调用一个triage skill，读取前一天的CI失败记录、open issues、recent commits，以及团队反馈。

随后，它将发现的问题整理到一个Markdown状态文件，或写入Linear board。每个问题都带上