告别手动操作：揭秘 AI 时代的“循环工程”新范式
目录
进阶：主导型循环 (Proactive Loops) 与 80+ PR 治理
引言：从“手动挡”到“自动驾驶”的跨越
作为开发者，我们正处于一个转折点。你是否曾感到筋疲力尽？在无休止的 PR 审查、繁琐的 Bug 修复以及对系统日志的监控中耗费了大量心智。这种“手动挡”的开发模式不仅效率低下，更剥夺了我们进行深度系统设计的时间。
然而，AI 正在将我们推向“自动驾驶”时代。通过循环工程 (Loop Engineering)，我们可以构建能够实现“自我进化”的代码和流程。这不仅仅是简单的脚本自动化，而是一种让 AI 智能体（Agent）在反馈闭环中不断自我校正的全新工程范式。本文将基于 Addy Osmani 在构建高效 AI 软件工厂中的实战认知，深度剖析如何利用这一武器重塑研发流程。
核心定义：什么是真正的“循环工程”？
在智能体工程（Agentic Engineering）的语境下，“循环”并非简单的逻辑重复，而是一个具备高度自主性的反馈机制。
“A loop is an autonomous, self-correcting feedback cycle where an AI agent repeatedly acts, tests its results and adjusts its approach until a specific goal is met.” （循环是一个自主、自我修正的反馈周期。在这个周期中，AI 智能体反复执行操作、测试结果并调整方法，直到达到特定目标。）
这种“自校正 (Self-correcting)”能力是区分传统自动化与智能体循环的分水岭。传统自动化在遇到非预期阻碍时往往会直接崩溃，而循环工程则允许 AI 分析失败原因，动态调整策略，并进行下一次尝试，直至满足预设条件。
两大核心原语：/goal 与 /loop 的协同魔法
在 Claude Code 等现代 AI 架构工具中，循环工程通过两个核心原语实现：
任务驱动 (Goal)： 这是一个“有界任务”原语。它为 AI 设定了一个确定性指标 (Deterministic Criteria) 作为终点线。AI 会持续迭代，直到满足硬性规则。
实战示例：
/goal Refactor the data-fetching layer in Dashboard.tsx until Lighthouse performance score is >= 92 and LCP is under 1.8s as shown by the Lighthouse CLI output. Do not change the public API of any hooks. Each turn must improve at least one reported metric; abort if two consecutive turns show no improvement. Stop after 10 turns.
时间驱动 (Loop)： 这更像是一个智能调度器（Cron 任务），用于按固定频率轮询状态或触发动作。
实战示例：
/loop every 1h "Check the GitHub repository for any new open issues. Provide a bulleted summary of their urgency."
协同魔法： 当两者结合时，你便拥有了端到端的自动化能力。例如，用 /loop 每 24 小时检查一次带有 bug 标签的议题，一旦发现，立即触发 /goal 自动修复代码并运行测试。
黄金法则：永远不要让同一个 AI 既当“选手”又当“裁判”
在构建循环系统时，一个严重的架构陷阱是让执行任务的 Agent 同时负责验证。由于 AI 的“过度自信”偏见，它极易产生幻觉，认为任务已完美达成。
作为架构师，你必须引入对抗性评审 (Adversarial Review) 机制。其核心逻辑在于：一个子 Agent 编写代码，另一个完全独立的 Agent 负责验证。
此外，必须理解一个关键的技术细节：/goal 背后自带的评估模型 (Evaluator) 仅通过检查对话记录 (Transcript) 来判断“硬规则”是否满足，它并不具备对代码质量或用户体验的深度审美。因此，你需要定义独立的 Agent Skills 进行端到端验证。
---
name: verify-frontend-change
description: 在宣布完成前，端到端验证任何 UI 更改。
---
# 验证前端更改
绝不要仅凭编辑成功就宣布 UI 更改已完成。像人类评审员一样验证：
1. 启动开发服务器并在浏览器中打开页面。
2. 直接交互：点击新控件、确认状态变化并截取前后对比图。
3. 检查控制台：确保零新增错误或警告。
4. 使用 Chrome Devtools MCP 运行性能追踪并审计 Core Web Vitals。
如果任一步骤失败，修复问题并从第1步重新开始。
警惕“判断力外包”：你可以委托任务，但不能委托“品味”
循环工程虽然能极大地解放生产力，但在涉及人类审美、主观设计或复杂权衡时，它存在明显的瓶颈。
Addy Osmani 在维护其 8 万星开源项目 Agent Skills 时曾遇到这样一个案例：AI 通过竞品分析，自动提出了若干 PR 以弥补功能差距。从逻辑上看，这些 PR 确实达成了任务，但从“品味 (Taste)”角度看，它们引入了不必要的系统复杂性。
核心洞察： 在 AI 驱动的软件工厂中，人类的角色已从“搬砖者”转变为“质检员”。你可以外包任务，但永远不能外包判断力。你必须设定团队的“门槛 (Bar)”，并时刻核查 AI 生成的方案是否符合系统的长期架构品味。
进阶：主导型循环 (Proactive Loops) 与 80+ PR 治理
在处理高流量开源项目时，顶级架构师会使用循环工程的“最高阶”：主导型循环 (Proactive Loops)。
这种模式通过 /schedule（云端运行）结合 /goal 和动态工作流，实现无须人工干预的自动化治理。
- 分层过滤： 使用 /loop 每小时检索新 PR。
- 规则拦截： 根据贡献指南（例如：不接受翻译类 PR）自动关闭不符要求的请求，显著降低批处理负担。
- 深度处理： 对于有效 Bug，系统会自动在多个并行工作树中探索解决方案，并进行对抗性评审。
这种系统让维护者能从每天 80-90 个 PR 的“信息洪流”中解脱，将精力聚焦在真正需要人类智慧的决策上。
避坑指南：给初学者的 3 条“免责声明”
- 确定性指标： 停止条件必须清晰且可量化。严禁使用“让 UI 变好”这种模糊指令，AI 无法评估主观的“好”。
- 死循环防御： 警惕“原地踏步”。如果同一个命令尝试了三次且结果没有任何变化，说明 Agent 已陷入困境，必须立即介入。
- 时效性与作用域： 递归循环通常在 7 天后失效（此前曾误传为 3 天），且受限于当前会话。若需跨会话的长期任务，请使用 /schedule 部署至云端。
结语：从“监工”到“系统设计师”的转变
循环工程通过 goal、loop 和独立验证机制，为我们展示了 AI 时代的研发图景。我们的角色正从紧盯每一行代码的“监工”，转变为定义边界、设定标准和把控品味的“系统设计师”。
当 AI 能够承担 90% 的重复性工程任务时，作为开发者的你，将如何定义剩下的那 10% 属于人类的、不可替代的“判断力价值”？这或许是我们在这个 AI 时代最需要思考的命题。
作者：道一云低代码
作者想说：喜欢本文请点点关注~
浙公网安备 33010602011771号