Loop Engineering（循环工程）万字深度解析：2026 年最火的 AI 开发范式——从 Prompt 到自主循环的系统架构革命

一、引言：那个让 AI 圈炸锅的推文

2026 年 6 月 7 日，OpenClaw 创始人 Peter Steinberger 在 X 上发了一条推文，后来获得了约 800 万次浏览。原文大意：

"每月提醒你一次：你不应该再给编程 Agent 写提示词了。"

同一天，Claude Code 的创建者 Boris Cherny 也发了几乎相同方向的内容：

"我不再给 Claude 写提示词了，我在写 Loop。让 Loop 去提示它们。"

三天后，Google Cloud AI 总监、前 Chrome 开发者工具负责人 Addy Osmani 发表了一篇系统长文，正式将这一新范式命名为 "Loop Engineering"（循环工程），并给出了完整的理论框架。

如果你还在每天手工写 Prompt、逐轮跟 AI 对话，那这篇文章就是为你写的。

二、范式回顾：AI 辅助开发的四次跃迁

在正式拆解 Loop Engineering 之前，有必要先回顾过去三年我们经历了什么。

2.1 Prompt Engineering（2023-2024）

核心玩法：写好提示词，让 AI 生成期望的输出。

你 → 【写 Prompt】 → LLM → 【出结果】 → 你判断 → 再改 Prompt ...

你扮演的是"提示词工程师"。每一轮输出质量直接取决于你的 Prompt 写得好不好。问题是——Prompt 优化很快进入边际效益递减：从 50 分提升到 80 分很容易，但从 80 分到 95 分需要花 10 倍的时间去微调措辞和例子。

2.2 Context Engineering（2024-2025）

大家终于发现：光有好 Prompt 不够，AI 需要更多的背景信息。

RAG（检索增强生成）火了起来。向量数据库、Embedding、文档分块、检索召回——这些成了标配。你不再只写 Prompt，而是往上下文里塞进项目文档、API 规范、历史代码。

你 → 【构建 Context（RAG + 文档） + Prompt】 → LLM → 【出结果】

这个阶段的问题：Context 再丰富，也只是"一次性输入"。AI 完成当前任务后，不会自动思考下一步该做什么。

2.3 Harness Engineering（2025-2026 初）

AI 不再只是回答问题，而是开始执行任务。你需要给它配工具、定权限、加日志。Harness 就像给 AI 搭"脚手架"——注册工具函数、定义 MCP 协议、设置权限控制、配置可观测性。

你 → 【Harness（工具注册 + 权限 + 观测） + Context + Prompt】 → AI Agent → 【执行】

这是 Loop Engineering 的直接前身。但 Harness 仍然有一个致命局限：它是一次性配置。AI 执行完一个任务就停了，没有"循环"的概念。

2.4 Loop Engineering（2026.6- 现在）

核心思想：你不是在跟 AI 对话，你是在设计一个让 AI 自主运行的系统。

你 → 【设计 Loop】 → 
  Loop 自动:
    1. 发现工作
    2. 分配任务给 Agent
    3. Agent 执行
    4. 验证结果
    5. 判断是否完成
    6. 未完成 → 继续
    7. 完成 → 通知你

你的角色从"操作工"升级为"流水线设计师"。

三、Loop Engineering 核心架构：六块积木

Addy Osmani 在系统文章中把 Loop 拆成了 5+1 个核心组件。我们来逐一深入。

3.1 自动化（Automation）—— Loop 的起搏器

没有自动化就没有 Loop。自动化是 Loop 的"心跳"，负责定时或事件驱动地启动循环。

三种触发模式：

（1）定时触发（Cron）

# Claude Code 中的自动化配置示例
automations:
  - name: "daily-bug-triage"
    schedule: "0 9 * * 1-5"     # 工作日早上 9 点
    action: "triage-open-issues"
    
  - name: "hourly-ci-check"
    schedule: "0 * * * *"        # 每小时
    action: "check-ci-failures"

（2）事件触发（Hook）

{
  "automations": {
    "on_issue_created": {
      "trigger": "github:issues.opened",
      "action": "analyze-issue-and-propose-fix"
    },
    "on_pr_review_requested": {
      "trigger": "github:pull_request.review_requested",
      "action": "auto-review-code"
    },
    "on_ci_failure": {
      "trigger": "github:check_run.completed",
      "filter": "conclusion == 'failure'",
      "action": "diagnose-ci-failure"
    }
  }
}

（3）目标触发（/Goal）

最简单的入口。设定一个目标，AI 自己判断"完成了吗"：

/goal 为这个项目的所有 API 端点添加 OpenAPI 3.0 文档注释

Agent 执行一轮后自动判断目标是否达成，未达成则继续下一轮。

3.2 工作树（Worktree）—— 并行隔离

多 Agent 并行操作同一仓库时，最大的问题是代码冲突。如果两个 Agent 同时修改同一个文件，后一个会覆盖前一个的改动。

Git Worktree 的工程化方案：

# 为每个 Agent 分配独立的 worktree
git worktree add ../workspace/agent-fix-bug-123 feature/fix-bug-123
git worktree add ../workspace/agent-refactor-auth feature/refactor-auth
git worktree add ../workspace/agent-add-tests feature/add-tests

# 查看所有 worktree
git worktree list
# /repo/main                     (bare)
# /repo/../workspace/agent-fix-bug-123         abc1234 [feature/fix-bug-123]
# /repo/../workspace/agent-refactor-auth       def5678 [feature/refactor-auth]

// Codex App 中的 worktree 管理实现
interface WorktreeConfig {
  baseDir: string;
  agentCount: number;
  isolation: "git-worktree" | "docker" | "directory";
}

class WorktreeManager {
  async allocateWorktree(agentId: string, branch: string): Promise<string> {
    // 1. 创建独立工位
    const worktreePath = path.join(this.baseDir, `agent-${agentId}`);
    await exec(`git worktree add ${worktreePath} ${branch}`);
    
    // 2. 设置 worktree 专属配置
    await fs.writeFile(
      path.join(worktreePath, '.agent-config.json'),
      JSON.stringify({ agentId, branch, createdAt: Date.now() })
    );
    
    return worktreePath;
  }
  
  async mergeAndCleanup(worktreePath: string): Promise<void> {
    // 1. 确保测试通过
    await exec(`cd ${worktreePath} && npm test`);
    
    // 2. 提交合并
    await exec(`cd ${worktreePath} && git add -A && git commit -m "auto: agent changes"`);
    await exec(`git worktree remove ${worktreePath}`);
  }
}

为什么不能直接在同一目录下运行多个 Agent？ 因为 Agent 在生成代码时，可能读取的是正在被另一个 Agent 修改的中间状态，产生竞态条件。Worktree 从文件系统层面解决了这个问题。

3.3 Skill（技能包）—— 意图的持久化

Skill 是 Loop 系统中的"长期记忆"。它不是写在 Prompt 里的——它是持久化到文件系统中的、Agent 每次运行都会读取的规范化指令集。

一个典型的 SKILL.md：

# 项目 Skill

## 代码规范
- TypeScript 使用 strict 模式，禁止 any
- React 组件使用函数式 + Hooks
- 测试覆盖率≥85%，使用 Vitest

## 架构约定
- API 层: /src/api/*.ts
- 组件层: /src/components/**/*.tsx
- 工具函数: /src/utils/*.ts
- 状态管理: Zustand，禁用 Redux

## 已知坑
- 数据库连接池默认 10，并发高时需调整
- 不要直接操作 process.env，使用 ConfigService
- API 错误统一使用 ApiError 类包装

## 测试要求
- 每个新功能必须有单元测试
- Mock 外部 HTTP 请求使用 nock 或 msw
- 集成测试需要真实数据库（test 专用库）

Skill 的工作原理：

Agent 启动 → 读取 SKILL.md → 注入到 System Prompt 中 → 
每次循环都重新读取（而不是缓存） → 保证最新规范

Skill 对抗的是什么？意图债务（Intent Debt）。当项目运行半年后，团队积累的隐式约定越来越多——但 Agent 每次都是"全新启动"，不知道这些约定。Skill 就是把这些隐式约定显式化的工具。

3.4 插件与连接器（Plugins & Connectors）—— Loop 的手脚

一个只能读文件的 Loop 是"小 Loop"。能操作真实系统的 Loop 才是"大 Loop"。

基于 MCP（Model Context Protocol）的连接器设计：

// MCP 连接器注册示例
import { McpServer } from "@modelcontextprotocol/sdk";

const server = new McpServer({
  name: "engineering-tools",
  version: "1.0.0",
});

// 注册 GitHub 操作
server.tool(
  "github.create_pull_request",
  {
    title: z.string(),
    body: z.string(),
    head: z.string(),
    base: z.string().default("main"),
  },
  async (args) => {
    const pr = await octokit.pulls.create({
      owner: "my-org",
      repo: "my-repo",
      title: args.title,
      body: args.body,
      head: args.head,
      base: args.base,
    });
    return { content: [{ type: "text", text: `PR #${pr.data.number} created` }] };
  }
);

// 注册 Linear 问题跟踪
server.tool(
  "linear.update_issue",
  {
    issueId: z.string(),
    status: z.enum(["in_progress", "in_review", "done"]),
    comment: z.string().optional(),
  },
  async (args) => {
    await linearClient.updateIssue(args.issueId, {
      stateId: statusMap[args.status],
    });
    return { content: [{ type: "text", text: `Issue ${args.issueId} updated` }] };
  }
);

Loop 中连接器的关键设计原则：

1. 幂等性：同一个操作执行两次，结果一致
2. 可回滚：每次变更都应该有对应的回滚能力
3. 审批边界：高风险操作（生产环境变更、权限修改）需要人工审批

3.5 子 Agent（Sub-Agents）—— 角色分离

这是 Loop 中最容易被忽视但最关键的一环：把"干活"和"验证"拆成两个不同的 Agent。

Maker-Checker 模式：

# .codex/agents/loop-config.yaml
loop:
  name: "auto-fix-cycle"
  goal: "修复所有 CI 测试失败"
  
  agents:
    - role: "maker"        # 写代码的 Agent
      model: "gpt-5.6-sol"
      instructions: |
        分析 CI 失败原因，生成修复代码。
        确保所有新增代码经过 eslint 检查。
        不要修改测试用例本身。
      constraint: "每次最多修改 3 个文件"
      
    - role: "checker"      # 审查的 Agent（用不同的模型！）
      model: "claude-4-opus"  
      instructions: |
        检查 maker 生成的代码：
        1. 修复是否正确解决了 CI 失败问题？
        2. 有没有引入新的编译错误？
        3. 测试覆盖率是否保持或提高？
        4. 代码风格是否符合项目规范？
        如果发现任何问题 → 返回具体修复建议
        全部通过 → 标记为 approved
      
    - role: "committer"    # 提交的 Agent（仅 checker 通过后）
      model: "gpt-5.6-luna"
      instructions: |
        提交代码并创建 PR。
        检查 CI 重新运行结果。
        如果 CI 通过 → 请求人工审查。
        如果 CI 失败 → 回滚到 maker 阶段。

关键工程细节：

1. 不同模型做不同角色：Maker 使用性价比高的模型（如 GPT-5.6 Sol），Checker 使用更强大的模型（如 Claude Opus）。这是 Token 成本最优策略。
2. 独立性：子 Agent 之间不共享上下文窗口，防止"串通"。
3. 检查维度：至少包含——功能性（测试）、合规性（代码风格）、安全性（扫描）。

3.6 状态/记忆（State/Memory）—— 持久化的循环记忆

Agent 本质上是无状态的。每次调用 Agent API，它不会记住之前干了什么。这是循环运行的最大障碍。

Mini 状态机实现：

// loop-state-machine.ts
interface LoopState {
  id: string;
  goal: string;
  status: "running" | "paused" | "completed" | "failed";
  
  // 循环进展
  iterations: number;
  currentStep: string;
  
  // 所有执行过的步骤
  history: StepRecord[];
  
  // 已知失败的模式
  knownFailures: string[];
  
  // 上下文文件引用（不存内容，存路径）
  contextFiles: string[];
}

interface StepRecord {
  step: string;
  agent: string;
  action: string;
  result: "success" | "failure" | "retry";
  timestamp: number;
}

class LoopStateManager {
  private stateDir: string;
  
  async saveState(state: LoopState): Promise<void> {
    // 使用 Markdown 文件存储，人类可读
    const md = [
      `# Loop State: ${state.id}`,
      ``,
      `## Goal`,
      state.goal,
      ``,
      `## Status: ${state.status}`,
      `Iterations: ${state.iterations}`,
      ``,
      `## History`,
      ...state.history.map(h => 
        `- ${h.step} (${h.agent}): ${h.action} → ${h.result}`
      ),
      ``,
      `## Known Failures (下次循环跳过)`,
      ...state.knownFailures.map(f => `- ❌ ${f}`),
    ].join('\n');
    
    await fs.writeFile(
      path.join(this.stateDir, `loop-${state.id}.md`),
      md
    );
  }
  
  async loadState(id: string): Promise<LoopState | null> {
    const filePath = path.join(this.stateDir, `loop-${id}.md`);
    if (!(await fs.exists(filePath))) return null;
    
    // 解析 Markdown 文件恢复状态
    return this.parseStateFile(filePath);
  }
}

为什么用 Markdown 文件而不是数据库？ 因为文件可读、可编辑、可版本控制。你可以直接在编辑器中修改状态文件来干预 Loop 的决策——这是"人在环中"（Human-in-the-loop）的基础。

四、完整 Loop 实战：从理论到代码

4.1 一个真实的每日循环

Addy Osmani 展示了他每天在用的自动化循环。我们把它拆解为可复现的代码：

// daily-loop.ts - 完整的每日自动化循环
import { CronJob } from "cron";
import { WorktreeManager } from "./worktree-manager";
import { LoopStateManager } from "./loop-state-manager";
import { AgentRunner } from "./agent-runner";

class DailyDevLoop {
  private worktree: WorktreeManager;
  private state: LoopStateManager;
  private agent: AgentRunner;
  
  constructor() {
    this.worktree = new WorktreeManager({ baseDir: "/repo/workspaces" });
    this.state = new LoopStateManager({ stateDir: "/repo/loop-states" });
    this.agent = new AgentRunner({ apiKey: process.env.OPENAI_API_KEY });
  }
  
  async start(): Promise<void> {
    // Step 1: 分诊 - 收集当日待解决问题
    console.log("[Loop] 阶段 1: 分诊 - 收集待办问题");
    const triageResult = await this.triage();
    
    // Step 2: 对每个值得修的问题启动修复循环
    for (const issue of triageResult.actionable) {
      console.log(`[Loop] 处理 Issue: ${issue.title}`);
      
      try {
        await this.processIssue(issue);
      } catch (err) {
        console.error(`[Loop] Issue ${issue.id} 处理失败:`, err);
        await this.state.recordFailure(issue.id, err.message);
      }
    }
    
    // Step 3: 生成报告
    await this.generateReport(triageResult);
  }
  
  private async triage(): Promise<TriageResult> {
    const state = await this.state.loadOrCreate("daily-triage");
    
    const result = await this.agent.run({
      role: "triage-agent",
      task: `分析当前仓库状态：
        1. 获取最近24小时的所有 CI 失败
        2. 获取所有新创建的未分配 Issue
        3. 获取所有等待 Review 超过24小时的 PR
        4. 针对每个问题，评估：
           - 修复难度（简单/中等/复杂）
           - 是否需要人类介入
           - 预计修复时间
        
        输出格式：JSON
      `,
      tools: ["github.issues.list", "github.checks.list", "github.pulls.list"],
    });
    
    return JSON.parse(result);
  }
  
  private async processIssue(issue: IssueInfo): Promise<void> {
    // 创建独立 worktree
    const worktreePath = await this.worktree.allocateWorktree(
      `fix-${issue.id}`, 
      `auto/fix-${issue.id}`
    );
    
    try {
      // Phase A: Maker 生成修复
      const fixResult = await this.agent.run({
        role: "maker",
        task: `在 ${worktreePath} 中修复 Issue #${issue.id}: ${issue.title}`,
        context: {
          issueBody: issue.body,
          recentCommits: issue.relatedCommits,
        },
        constraints: {
          maxFiles: 3,
          mustKeepTests: true,
        },
      });
      
      // Phase B: Checker 验证修复
      const reviewResult = await this.agent.run({
        role: "checker",
        task: `审查 ${worktreePath} 中的修复`,
        model: "claude-4-opus",  // 更强大的审查模型
        validationCriteria: [
          "Bug 是否真正修复？",
          "是否引入新的编译错误？",
          "测试覆盖率是否下降？",
          "代码风格是否符合规范？",
          "是否有安全风险？",
        ],
      });
      
      if (!reviewResult.approved) {
        // 反馈给 maker 继续修复
        await this.state.recordFeedback(issue.id, reviewResult.feedback);
        return this.processIssue(issue);  // 递归重试
      }
      
      // Phase C: 运行测试
      const testPassed = await this.runTests(worktreePath);
      if (!testPassed) {
        await this.state.recordFailure(issue.id, "Tests failed");
        return;
      }
      
      // Phase D: 提交并创建 PR
      await this.agent.run({
        role: "committer",
        task: `
          在 ${worktreePath} 中:
          1. git commit
          2. git push
          3. 创建 PR，关联 Issue #${issue.id}
          4. 在 PR 描述中包含修复说明
        `,
      });
      
    } finally {
      // 清理 worktree（无论成功还是失败）
      await this.worktree.cleanup(worktreePath);
    }
  }
}

// 启动定时任务: 工作日每天早上 9 点
const loop = new DailyDevLoop();
const job = new CronJob("0 9 * * 1-5", () => loop.start());
job.start();

4.2 Claude Code 中的 Loop 实践

对于使用 Claude Code 的开发者，可以通过配置实现简化的 Loop：

// .claude/settings.json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "command": "node scripts/decide-next.js"
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Edit*",
        "command": "node scripts/pre-edit-check.js"
      }
    ]
  },
  "agents": {
    "reviewer": {
      "model": "claude-4-opus",
      "instructions": "你负责审查代码质量",
      "independent": true
    }
  }
}

// scripts/decide-next.js - 决定下一步做什么
const fs = require('fs');
const stateFile = '/tmp/loop-state.json';

// 读取当前循环状态
const state = JSON.parse(
  fs.readFileSync(stateFile, 'utf-8')
);

// 检查目标是否达成
const goal = state.goal;
const completedItems = state.completedItems || [];
const pendingItems = state.pendingItems || [];

if (pendingItems.length === 0) {
  console.log(`✅ 目标 "${goal}" 已完成`);
  console.log(`   共处理 ${completedItems.length} 项`);
  process.exit(0);
}

// 输出下一步任务
const next = pendingItems[0];
console.log(`📋 待处理: ${next.title}`);
console.log(`   剩余 ${pendingItems.length - 1} 项`);

4.3 在 OpenClaw 中实现 Loop

# loop-config.yaml - OpenClaw Loop 配置
name: "weekly-code-refactor"
schedule: "0 10 * * 1"  # 每周一早上 10 点

steps:
  - name: "analyze"
    agent: "analysis-agent"  
    prompt: |
      扫描项目代码库，找出需要重构的模块：
      - 圈复杂度 > 15 的函数
      - 超过 200 行的文件
      - 重复代码块（>50行相似度>80%）
      输出: JSON 列表，按优先级排序

  - name: "refactor"
    agent: "refactor-agent"
    depends_on: ["analyze"]
    input: "{{ steps.analyze.output }}"
    parallel: true
    prompt: |
      重构以下模块，遵守项目 SKILL.md 规范。
      每次只改一个模块，改完后运行测试。
      如果测试失败，回滚并记录原因。

  - name: "review"
    agent: "review-agent"  
    depends_on: ["refactor"]
    input: "{{ steps.refactor.output }}"
    prompt: |
      审查以下重构代码：
      - 是否改变了外部 API 行为？
      - 测试是否全部通过？
      - 性能是否有退化？

  - name: "commit"
    agent: "committer"
    depends_on: ["review"]
    condition: "{{ steps.review.approved }}"
    prompt: |
      提交重构代码，创建 PR。
      在 PR 描述中详细列出改动说明。

五、成本分析与 Token 优化策略

Loop Engineering 最大的实际担忧是 Token 成本。一个持续运行的循环可能会疯狂消耗 Token。但实际上，经过精心设计的 Loop 反而可以降低 Token 消耗。

5.1 Token 消耗对比

关键优化策略：

5.2 上下文压缩

每次循环只传递差异信息，而不是重复传递完整上下文：

// context-compressor.ts
class ContextCompressor {
  compress(history: Message[], maxTokens: number = 4000): CompressedContext {
    // 1. 保留最新的 N 轮完整对话
    const recentMessages = history.slice(-3);
    
    // 2. 对之前的内容进行摘要
    const olderMessages = history.slice(0, -3);
    const summary = olderMessages.length > 0 
      ? this.summarize(olderMessages)
      : "";
    
    // 3. 只传递状态变化
    const stateDiff = this.computeStateDiff();
    
    return {
      summary,
      stateDiff,
      recentMessages,
      tokenEstimate: estimateTokens(summary + JSON.stringify(stateDiff)),
    };
  }
}

5.3 模型分层

不是所有步骤都需要最贵的模型：

const modelRouter = {
  maker: "gpt-5.6-sol",       // 便宜，够用
  checker: "claude-4-opus",   // 贵，但准确
  summarizer: "gpt-5.6-luna", // 极便宜
  stateManager: "local-llm",  // 免费
};

六、三大陷阱：Loop 越强，你越危险

Addy Osmani 在完整文章中，花了几乎和描述架构一样长的篇幅来警告三个陷阱。这本身就是一种信号。

陷阱一：验证责任的滞留

Loop 的 "Checker" Agent 说 "验证通过" 不等于真的通过。测试套件本身有盲区——AI 甚至可能去修改测试来迎合结果。

"完成了" 是声明，不是证明。

对策：

1. 人类审查关键路径：部署到生产环境的代码必须经过人工审查
2. 独立验证层：Checker 与 Maker 使用不同的模型/不同的 System Prompt
3. 不变测试：核心测试不可修改（只读权限）

陷阱二：理解债务的指数级增长

当代码在 Loop 中自动生成、自动合并，你没有参与过过程。你从未读过这些代码。

几个月后，代码库里有一半的代码你不知道是干什么的——这就是 理解债务。

对策：

1. 强制阅读：每周花时间通读 Loop 产出的 PR
2. 解释要求：每个自动 PR 必须包含变更说明
3. 限制自动化范围：核心模块禁止全自动修改

陷阱三：认知投降

"AI 生成的代码看起来挺好 → 合并 → 下一个"——这是最危险的循环模式。

当人类开始无脑接受 AI 的输出，不仅是质量下降的问题，而是你的工程判断力在退化。

对策：

• 每次合并 AI 代码前，问自己三个问题：
  1. 我完全理解这段代码做了什么吗？
  2. 如果这段代码在生产环境出问题，我能定位到原因吗？
  3. 如果删掉这段代码，我知道怎么重新实现吗？

如果三个答案中有任何一个"否"——停下来。

七、入门实践：从最简单的 Loop 开始

Level 1：使用 /goal

最简单的入口。不需要任何配置：

/goal 重构 utils 目录下的所有工具函数，加上完整的 TypeScript 类型

Agent 会自己判断完成度、自动继续。

Level 2：配置自动化

在 Claude Code 中添加 Stop Hook：

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "command": "node scripts/decide-next.js"
      }
    ]
  }
}

简单的决定逻辑：

// scripts/decide-next.js
const remaining = getRemainingTasks();
if (remaining.length > 0) {
  console.log(`继续：${remaining[0].title}`);
} else {
  console.log("✅ 全部完成");
}

Level 3：完整的自动化流水线

按照本文四章的架构，逐步搭建你的六个组件：

1. Automation → 配置 Cron 定时任务
2. Worktree → 为关键模块设置隔离工位
3. Skill → 编写项目 SKILL.md
4. Connectors → 通过 MCP 连接 GitHub/Linear
5. Sub-agents → 分离 Maker/Checker 角色
6. Memory → 实现状态文件持久化

八、总结与展望

Loop Engineering 不是取代 Prompts——它是你的角色从"操作工"升级为"工厂设计师"。

2026 年 6 月，Boris Cherny 说"我的工作是写 Loop"——这背后的信息不是编程变简单了，而是编程的难点变了。

以前你花 70% 的时间写代码、30% 的时间设计；现在你用 30% 的时间设计 Loop、70% 的时间思考"该设计什么样的流程"。

那些在 2023 年花大量时间学习 Prompt 技巧的人，现在需要重新学习"如何设计循环"。而那些从第一天就在思考系统设计的人，反而发现新范式更接近他们一直擅长的事。

AI 在变，但工程师的核心价值一直没变：不是写代码的速度，而是做出正确技术决策的判断力。

你设计 Loop，但不要被 Loop 设计。

参考资料：

• Addy Osmani: Loop Engineering
• Peter Steinberger 推文 (2026.06.07)
• Boris Cherny: 关于 Loop 的多次公开分享
• Claude Code Agent Skills 指南
• OpenClaw 自动化配置文档