从Prompt到自动化工作流：Loop Engineering构建AI编程新范式

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

如果你还在手动给AI写提示词，每次让它改个bug、写个函数，然后自己检查、再写下一个提示词，那么你很可能正在错过AI编程真正的效率革命。这种“人肉调度”模式，看似提升了单点效率，实则让你成了整个流程中最忙、最不可替代的“瓶颈”。AI Agent越强大，你手动Prompt的瓶颈就越明显。

真正的转变，是从“使用AI”到“运营AI”。这背后的核心方法论，就是Loop Engineering（循环工程）。它不是一个新工具，而是一套系统性的设计思想：让AI Agent能够在一套明确的边界内，自动发现任务、分配任务、执行检查并决定下一步，形成一个可持续运行的自动化工作流。简单说，就是让AI自己写代码，甚至自己构建和优化工作流，实现“AI造AI”的自动化循环。

这篇文章要解决的，正是每个尝试将AI融入开发流程的工程师都会遇到的终极困惑：如果我不想一直守在Agent旁边，如何让它安全、可控、可验证地持续工作？我们将深入拆解Loop Engineering的核心理念、五大核心组件，并通过一个从零到一的完整示例，展示如何构建一个能自动修复单元测试失败的AI Agent工作流。读完本文，你将掌握从手动Prompt到自动化工作流的设计方法，并能够亲手搭建你的第一个“自循环”AI工程师。

1. Loop Engineering：从“司机”到“系统架构师”的思维转变

过去两年，我们使用AI编程Agent的典型模式是线性的：写Prompt -> Agent返回结果 -> 人工阅读审核 -> 再写下一个Prompt。在这个循环里，人类是那个必须时刻握着方向盘的“司机”，Agent只是听令行事的“乘客”。这种模式的效率天花板非常低，因为它无法规模化，也无法利用Agent的持续学习和迭代能力。

Loop Engineering的本质，是角色转换。你不再做“司机”，而是成为“交通系统的架构师”。你一次性设计好信号灯规则、道路网络（工作流）和车辆行为规范（Skills），然后让多辆“AI车辆”（Sub-agents）在这个系统里自主、并行、安全地运行。你的工作变成了监督系统状态、处理异常和优化规则。

这种转变解决了三个核心痛点：

1. 解放人力：从重复的Prompt编写和结果检查中脱身，专注于更高层次的设计和决策。
2. 提升可靠性：通过标准化的工作流、隔离的执行环境和明确的验收标准，减少人为疏忽带来的错误。
3. 实现规模化：一个设计良好的Loop可以7x24小时运行，处理海量重复性任务，如代码评审、测试修复、日志监控等。

理解Loop Engineering，首先要抛弃“AI工具”的旧观念，建立起“AI系统”的新认知。

2. 核心组件拆解：构建自动化工作流的五大基石

根据Addy Osmani在《Loop Engineering》中的阐述，一个健壮、可持续的AI自动化循环需要五个核心组件（原语）和一个外部记忆系统。缺失任何一环，循环都可能“泄漏”——失控、出错或停滞。

2.1 Automations：循环的“心跳”与触发器

这是Loop的启动层，决定了“什么时候该让Agent动起来”。它不再是手动输入/命令，而是预设的规则。

• 定时触发：例如，每天凌晨2点运行全量测试并生成报告、每10分钟检查一次生产环境健康状态。
• 事件触发：例如，GitHub上有新的Pull Request创建、Sentry捕获到一个新的Error事件、CI/CD流水线失败、收到特定格式的Slack消息。

在不同的工具中，它可能被叫作/loop命令、Scheduled Tasks、Cloud Routines或Webhooks。其核心是将人工决策“现在该做什么”转化为系统可识别的事件。

2.2 Worktrees：并行执行的“隔离沙盒”

当多个Agent同时处理不同任务时，最怕的就是上下文污染和文件冲突。想象一下，一个Agent在修复bug，另一个在重构代码，它们同时修改src/main.js会是什么结果？

• Git Worktree是这个问题的优雅解决方案。它允许你在同一个Git仓库中，创建多个独立的工作目录，每个目录关联不同的分支。这样，每个Agent都可以在完全隔离的沙盒中工作，互不干扰。
• 价值：实现真正的并行化。你可以让Agent A在worktree/fix-bug-101分支上修复Bug，同时让Agent B在worktree/refactor-auth分支上进行重构，最后再人工或自动合并。

2.3 Skills：项目的“持久化记忆”与规范库

你是否曾把一长串项目规范（如“使用ESLint Airbnb规则”、“API调用必须通过@/api模块”、“提交前必须跑通单元测试”）塞进System Prompt？这会导致Prompt臃肿且难以复用。

• Skills机制将这些稳定的、项目特定的知识从易失的对话上下文中剥离出来，沉淀到如SKILLS.md、AGENTS.md或项目知识库文件中。
• 工作方式：在Loop启动时，或Agent执行特定任务前，自动将相关Skills文件的内容作为上下文注入。这确保了所有Agent都遵循同一套项目规范，降低了沟通成本，提高了输出的一致性。

2.4 Plugins / Connectors：通往真实世界的“桥梁”

一个只会写代码却无法操作版本库、不能读取issue、不能发送通知的Agent，只是一个高级记事本。Plugins（插件）或Connectors（连接器）是Agent与现有工具链（如GitHub, GitLab, Jira, Slack, Sentry, 数据库）交互的桥梁。

• 作用：让Loop从本地玩具升级为融入团队工作流的生产力设施。例如，一个完整的“PR自动评审-修复”Loop需要：通过GitHub Connector读取PR差异 -> 在独立Worktree中创建修复分支 -> 执行修复 -> 运行测试 -> 通过Connector将修复结果写回PR评论或创建新的PR。
• 标准：Model Context Protocol (MCP) 正在成为连接Agent与工具的事实标准，它定义了统一的资源访问接口。

2.5 Sub-agents：职责分离的“角色扮演”

让一个Agent既当运动员（写代码）又当裁判员（评审代码），它很容易陷入“自我确认偏差”，忽略自己代码中的问题。

• Sub-agents模式通过引入角色分工来解决这个问题：
  • Proposer/Planner：分析任务，制定解决方案和拆分子任务。
  • Implementer/Coder：在隔离的Worktree中，具体执行编码任务。
  • Reviewer/Verifier：根据Skills、测试用例和代码规范，对Implementer的输出进行审查。
• 优势：实现了制造与检查的分离，降低了单点风险，更贴近人类团队的协作模式，尤其适合复杂任务。

3. 环境准备：构建你的第一个AI自动化工作流

在开始构建之前，我们需要搭建一个实验环境。本文将使用Claude Code或Cursor这类集成了强大Agent能力的IDE作为演示平台，因为它们对Loop Engineering的支持相对友好。同时，我们会结合简单的脚本和Git来模拟一个完整的流程。

核心工具栈：

1. IDE/Agent平台：Claude Code (推荐) 或 Cursor。确保你有权限使用其高级Agent和自动化功能。
2. 版本控制：Git (版本 >= 2.15+，以支持Worktree)。
3. 项目语言：本文示例使用Node.js/JavaScript，但原理通用。
4. 包管理器：npm 或 yarn。
5. 测试框架：Jest (用于创建可验证的任务)。

环境检查：打开你的终端，运行以下命令确保基础环境就绪：

# 检查Git版本及Worktree支持 git --version git worktree --help # 确认有此命令 # 检查Node.js环境 node --version npm --version # 创建一个用于实验的目录 mkdir ai-loop-engineering-demo && cd ai-loop-engineering-demo git init

我们的目标：构建一个能自动检测并修复单元测试失败的Loop。这个任务边界清晰、结果可验证（测试通过与否），是入门Loop Engineering的绝佳起点。

4. 从0到1：构建自动修复测试的AI Loop

让我们遵循“从薄到厚”的原则，一步步搭建这个Loop。

4.1 第一步：定义清晰的SPEC（规格说明书）

这是唯一必须由人类完成的一步，它定义了“完成”的状态。在项目根目录创建SPEC.md。

<!-- SPEC.md --> # 自动测试修复循环规格说明书 ## 目标 创建一个自动化工作流，当项目的单元测试失败时，能自动分析失败原因，尝试修复代码，并验证修复是否成功。 ## 触发条件 1. 主分支(`main`)上的CI测试失败（通过GitHub Actions webhook模拟）。 2. 或，本地运行测试命令`npm test`返回非零退出码。 ## 输入 - 失败的测试输出日志。 - 关联的源代码文件。 ## 输出 - 修复后的代码，提交到以`fix/test-fail-<timestamp>`命名的分支。 - 修复结果的摘要报告，包括：失败原因、修改了哪些文件、修复后的测试结果。 ## 验收标准 1. **功能正确性**：修复后的代码必须通过所有之前失败的测试用例。 2. **代码质量**：修复不得引入新的ESLint错误或警告（遵循项目规则）。 3. **最小改动**：修复应尽可能精准，避免不必要的代码重构。 4. **隔离性**：修复过程必须在独立的Git worktree中进行，不影响主工作区。 ## 停止条件 1. 成功：测试通过，代码符合规范，创建修复分支和报告。 2. 失败（循环终止）： - 连续3次修复尝试后测试仍然失败。 - 单次运行时间超过10分钟。 - Agent尝试执行危险命令（如`rm -rf /`, `:(){ :|:& };:`）。

4.2 第二步：沉淀项目Skills

创建SKILLS.md文件，这是Agent的“项目手册”。

<!-- SKILLS.md --> # 项目开发规范 (Skills for AI Agent) ## 代码风格 - **语言**: JavaScript (ES6+) - **缩进**: 2个空格 - **字符串**: 优先使用单引号(`'`) - **分号**: 不使用分号 (遵循 StandardJS风格) - **命名**: 变量/函数使用`camelCase`，类使用`PascalCase` ## 测试规范 - **框架**: Jest - **文件位置**: 测试文件与源文件同名，后缀为`.test.js`，并存放在`__tests__`目录或同级。 - **断言**: 使用Jest提供的`expect()`语法。 - **覆盖率**: 非强制，但新增代码应有对应测试。 ## 提交规范 - **分支命名**: `fix/test-fail-<YYYYMMDD-HHMMSS>` - **提交信息**: 遵循Conventional Commits，例如：`fix(calculator): correct division by zero handling` ## 安全与权限边界 - **严禁操作**: - 删除任何非由本循环创建的文件或目录。 - 修改`package.json`中的核心依赖版本。 - 向`main`分支直接推送代码。 - 执行任何网络请求（除非明确授权）。 - **必须操作**: - 所有代码修改必须在独立的git worktree中进行。 - 任何修复尝试前，必须先运行`npm test`确认失败状态。 - 修复后，必须运行`npm run lint`检查代码风格。

4.3 第三步：创建最小可运行Loop骨架

我们用一个Bash脚本run_test_fix_loop.sh来模拟Loop的第一次触发。这个脚本封装了核心逻辑。

#!/bin/bash # run_test_fix_loop.sh - 测试修复循环的最小骨架 set -e # 遇到错误即退出 LOG_FILE="loop_$(date +%Y%m%d_%H%M%S).log" echo "=== 启动测试修复循环 $(date) ===" | tee -a "$LOG_FILE" # 1. 检查触发条件：当前测试是否失败？ echo "[1/5] 检查测试状态..." | tee -a "$LOG_FILE" if npm test 2>&1 | tee -a "$LOG_FILE"; then echo "所有测试通过，无需修复。循环结束。" | tee -a "$LOG_FILE" exit 0 else TEST_FAILED=true echo "检测到测试失败，启动修复流程。" | tee -a "$LOG_FILE" fi # 2. 为本次修复创建独立的Git Worktree BRANCH_NAME="fix/test-fail-$(date +%Y%m%d-%H%M%S)" WORKTREE_PATH="../worktree_${BRANCH_NAME}" echo "[2/5] 创建独立工作区: $WORKTREE_PATH (分支: $BRANCH_NAME)..." | tee -a "$LOG_FILE" git worktree add -b "$BRANCH_NAME" "$WORKTREE_PATH" # 3. 进入工作区，准备上下文 cd "$WORKTREE_PATH" cp ../SKILLS.md ./ # 注意：这里简化了，实际应将失败日志、相关代码文件传递给Agent echo "[3/5] 上下文准备完毕。即将调用AI Agent进行修复..." | tee -a "$LOG_FILE" # 此处是调用AI Agent的核心位置。我们用一个模拟的“思考”过程代替。 # 真实场景下，这里会调用Claude Code API或Cursor的Agent，并附上SPEC、SKILLS和失败日志。 echo "模拟：AI Agent正在分析测试失败日志和代码..." | tee -a "$LOG_FILE" sleep 2 echo "模拟：AI Agent尝试修改了 src/calculator.js 中的 divide 函数..." | tee -a "$LOG_FILE" # 假设Agent“修复”了代码，我们模拟一个修改 cat > src/calculator.js << 'EOF' // 模拟修复后的代码 function divide(a, b) { if (b === 0) { throw new Error('Division by zero is not allowed.'); } return a / b; } module.exports = { divide }; EOF # 4. 验证修复结果 echo "[4/5] 验证修复结果..." | tee -a "$LOG_FILE" if npm test 2>&1 | tee -a "$LOG_FILE"; then echo "✅ 测试通过！修复成功。" | tee -a "$LOG_FILE" npm run lint 2>&1 | tee -a "$LOG_FILE" && echo "✅ 代码风格检查通过。" | tee -a "$LOG_FILE" # 提交更改 git add . git commit -m "fix(calculator): handle division by zero error" | tee -a "$LOG_FILE" echo "[5/5] 修复已提交到分支: $BRANCH_NAME" | tee -a "$LOG_FILE" RESULT="SUCCESS" else echo "❌ 修复后测试仍然失败。" | tee -a "$LOG_FILE" RESULT="FAILURE" fi # 5. 清理与报告 cd .. echo "=== 循环结束，结果: $RESULT ===" | tee -a "$LOG_FILE" # 保留worktree供审查，实际可根据策略删除或保留 # git worktree remove ../worktree_${BRANCH_NAME} # 此处可添加Connector逻辑：将结果发送到Slack、创建PR等。 # echo "模拟：将结果摘要发送至团队频道..." | tee -a "$LOG_FILE"

给脚本添加执行权限：chmod +x run_test_fix_loop.sh。这个脚本已经包含了Automation（手动/定时触发）、Worktree、Skills加载和验证的基本框架。

4.4 第四步：引入Sub-agents分工（概念集成）

在真实的Claude Code或Cursor中，你可以通过设计不同的Prompt角色来模拟Sub-agents。例如，在调用AI时，通过System Prompt明确其角色：

对于 Implementer Agent:

你是一个资深JavaScript工程师（Implementer）。你的任务是修复以下单元测试失败问题。 请严格遵守项目规范（SKILLS.md），在独立的工作目录中进行修改。 你只负责编写和修改代码，不要自行运行测试或评审。 修改完成后，请输出修改后的完整文件内容。

对于 Reviewer Agent:

你是一个严格的代码评审员（Reviewer）。你的任务是评审Implementer提交的代码。 请依据项目规范（SKILLS.md）和以下测试失败日志，检查代码： 1. 是否解决了测试失败的根本原因？ 2. 是否引入了新的语法错误或风格问题？ 3. 是否符合最小改动原则？ 请给出明确的评审结论：通过（APPROVE）或拒绝（REQUEST_CHANGES）并说明理由。

在你的主控脚本或Loop配置中，可以顺序调用这两个Agent，将Implementer的输出作为Reviewer的输入，实现职责分离。

4.5 第五步：连接真实世界（Connectors集成）

最后，让这个Loop融入开发工作流。我们可以用GitHub Actions来模拟一个事件触发的Automation。

创建.github/workflows/test-fix-loop.yml:

name: AI Test Fix Loop on: push: branches: [ main ] workflow_dispatch: # 允许手动触发 jobs: test-and-fix: runs-on: ubuntu-latest if: failure() # 关键：只有测试job失败时才运行 steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 获取所有历史，便于worktree操作 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '18' - name: Install dependencies run: npm ci - name: Run Tests (Expected to fail) run: npm test continue-on-error: true # 测试失败是此工作流的触发条件 - name: Trigger AI Fix Loop if: failure() # 如果上一步测试失败 run: | # 这里可以替换为调用你部署的AI Loop服务 # 例如: curl -X POST https://your-ai-loop-service/trigger \ # -d '{"repo": "${{ github.repository }}", "commit": "${{ github.sha }}"}' echo "模拟：触发AI修复循环。在实际场景中，此处会调用一个托管服务，该服务执行 run_test_fix_loop.sh 的逻辑。" echo "失败日志和代码上下文已被捕获。" - name: Create Issue on Failure if: failure() uses: actions/github-script@v7 with: script: | github.rest.issues.create({ owner: context.repo.owner, repo: context.repo.repo, title: `CI测试失败，AI修复循环未成功`, body: `主分支提交 ${context.sha} 的测试失败，AI修复循环未能自动解决。请人工介入。\n\n 工作流运行链接: ${context.runId}`, labels: ['ci-failure', 'needs-triage'] });

这个工作流实现了：当main分支的测试失败时，自动触发后续处理（这里是模拟触发AI Loop），并在AI Loop也处理失败时，自动创建Issue通知人类。这就是一个完整的事件驱动Automation。

5. 运行与验证：观察你的AI工程师如何工作

1. 准备一个失败场景：在项目中故意引入一个bug，导致测试失败。例如，修改src/calculator.js中的divide函数，移除除零检查。
2. 首次手动触发：在终端运行./run_test_fix_loop.sh。观察日志输出，看它是否成功创建worktree、模拟“修复”代码、运行测试并通过。
3. 验证Git状态：运行git branch -a，你应该能看到新创建的修复分支。使用git log --oneline <branch-name>查看提交。
4. 模拟CI集成：将代码推送到GitHub仓库的main分支，触发上述GitHub Actions工作流。观察Actions的执行日志，理解事件触发的流程。

成功标志：

• 脚本日志显示所有步骤完成，最终结果为SUCCESS。
• 新的Git分支被创建并包含有效的修复提交。
• （如果集成CI）GitHub Actions工作流被正确触发并执行了定义的后继步骤。

6. 常见问题与排查思路

在构建和运行Loop时，你可能会遇到以下典型问题：

7. 最佳实践与工程化建议

将Loop Engineering投入生产环境，需要遵循以下原则，以确保其可靠性、安全性和可维护性。

1. 目标必须可判定（Verifiable Goals）Loop的终极目标必须是机器可明确判断的。优先选择那些有二进制结果（通过/失败）或可量化指标的任务，如“测试通过率100%”、“lint错误数为0”、“编译成功”。避免“代码质量提升”、“优化性能”这类模糊目标。

2. 权限必须按任务配置（Least Privilege）为不同的Loop配置不同的权限白名单。一个用于自动写日报的Agent，绝对不应该有git push --force的权限。在调用AI服务时，利用其工具调用（Tool Calling）的权限控制系统，明确允许和禁止的命令列表。

3. 成本必须显式预算（Explicit Budgeting）将Loop视为有成本的服务。为每个Loop设置预算：

   • Token预算：单次运行最大Token消耗。
   • 时间预算：单次运行最长时间。
   • 财务预算：每日/每周最大API调用费用。 监控这些指标，并设置告警。

4. 输出必须可审查（Auditable Output）任何由Loop产生的变更，都必须留有“审计线索”。

   • 代码变更：始终提交到特性分支或草稿PR，绝不允许直接推送至受保护分支（如main,master）。
   • 运行日志：所有Loop执行过程、AI的思考过程、工具调用记录，都应持久化到日志系统。
   • 摘要报告：每次循环结束，生成一份人类可读的摘要，说明做了什么、为什么做、结果如何。

5. 设计必须渐进式（Progressive Enhancement）不要试图一开始就构建一个全自动的复杂系统。遵循“爬-走-跑”的节奏：

   • 爬：手动触发，输出建议，人工审核后执行。
   • 走：自动触发，在隔离环境执行，结果提交为草稿，人工合并。
   • 跑：全自动闭环，仅在异常时通知人类。 每增加一个“自动化度”，都必须经过充分测试和验证。

6. 人是最终的责任主体（Human in the Loop）Loop Engineering不是“设置好就忘记”的魔法。它的目标是放大人的能力，而非取代人的判断。始终在关键节点（如生产部署、数据库变更、核心逻辑修改）保留人工审批的入口。定期审查Loop的产出和决策，防止“认知投降”——因为自动化而放弃思考。

8. 总结：从Prompt工程师到Loop架构师

Loop Engineering标志着一个关键的范式转移：我们与AI协作的单元，从一次性的、离散的“对话”（Prompt），升级为持续性的、系统化的“工作流”（Loop）。这要求开发者从“Prompt工程师”转变为“Loop架构师”。

这种转变的核心技能不再是雕琢单句提示词，而是系统设计能力：如何定义清晰边界、如何拆解原子任务、如何设计安全隔离、如何建立验证反馈机制。本文通过一个具体的“自动测试修复”案例，展示了构建这样一个Loop所需的完整路径：从SPEC设计、Skills沉淀、到利用Worktree和Sub-agents实现隔离与分工，最后通过Connectors融入CI/CD流水线。

最危险的误区，是为了追求“全自动”而放弃控制权。最强的Loop，恰恰是那些将人类智慧置于系统关键控制点的设计——人类定义规则、设定边界、处理异常，而AI负责在规则内高效、不知疲倦地执行。你的第一个Loop不必复杂，可以从“每天自动整理我未提交的代码变更并生成摘要”这样的小任务开始。重要的是迈出第一步，体验从“驾驶座”退到“指挥塔”的视角变化。

当你成功运行起第一个Loop，看着AI在你设计的轨道上自动解决问题时，你会真正理解，AI时代的工程师价值，不在于写更多的代码，而在于设计更聪明的系统，让代码（无论是谁写的）能够自动、可靠地运行。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度