Loop Engineering实操指南 | 90%工程师还在做AI时代的"人肉API"

🎯 Главная суть

90% разработчиков до сих пор вручную пишут промпты для AI-агентов, повторяя цикл «запрос → генерация → ошибка → новый запрос» десятки раз в день. Вместо этого нужно проектировать самоисправляющиеся циклы (loop engineering) — системы, которые сами генерируют код, запускают тесты, читают ошибки и правят себя до достижения цели. Человек перестаёт быть «человеческим API» и становится архитектором автоматизированного пайплайна.

🧠 Почему ручной промптинг — bottleneck

Типичный рабочий процесс с AI: разработчик пишет промпт, ждёт генерацию, проверяет, находит баг, снова пишет промпт с описанием ошибки. За день такие итерации повторяются десятки раз. Парадокс: куплен инструмент для автоматизации, но сам разработчик превращается в «человеческий API» — выполняет самую однообразную и скучную работу. 90% разработчиков, по данным Codex, ни разу не писали цикл для своего AI-агента.

🔁 Loop Engineering: что это и почему стало возможным в 2026

Loop engineering — это не for/while в традиционном смысле, а рекурсивная целеориентированная система. Задаётся конечная цель (например, «реализовать REST API с OAuth-логином»), определяется набор правил, и система сама генерирует код, запускает тесты, читает лог ошибок, вносит исправления и повторяет цикл, пока тесты не пройдут. Человек лишь задаёт границы, критерии приёмки и выполняет финальную проверку.
Ключевой катализатор — эволюция LLM. Два года назад модели были неспособны к самокоррекции: при малейшей ошибке могли переписать весь файл в хаос. С появлением моделей уровня Claude Opus и Claude Sonnet 4.5 у моделей появилась сильная способность замечать и исправлять собственные ошибки. Теперь искусственное вмешательство человека — не помощь, а узкое место.

🧪 Уровень 1: тест-драйв и самокоррекция (Cursor)

Самый простой и быстрый способ внедрить loop — настроить агента в Cursor.

• Включить режим run mode → Run Everything или AutoReview.
• Промпт пишется в стиле: «Сначала напиши тесты, потом код, запусти тесты и исправляй код, пока все тесты не пройдут».
• Агент сам создаёт тестовые файлы, реализует код, выполняет npm test в фоне, читает лог ошибок, правит код и запускает тесты снова. Разработчик может не трогать клавиатуру.
• Рекомендуется добавить в белый список (Command allowlist) команды npm test, npm run build, pytest и т.д., а также включить защиту от автоматического удаления файлов.

Пример: нужно написать сложную функцию конвертации Markdown в HTML. Традиционно — написать промпт, получить код, вручную запустить тесты, скопировать ошибку обратно. В режиме loop агент сам делает все шаги до тех пор, пока все тесты не будут зелёными. Условие остановки — «все тесты пройдены».

🎯 Уровень 2: целеориентированность с памятью (Cloud Code)

Когда задача затрагивает десятки файлов (например, рефакторинг или миграция API), простого автозапуска недостаточно — нужно, чтобы агент помнил, что уже сделано, и не повторял ошибок.

• Используется инструкция GO в Cloud Code. После каждого раунда независимая модель-оценщик (по умолчанию Claude Haiku) проверяет, достигнуто ли целевое состояние, описанное в промпте. Промпт формулируется как наблюдаемое конечное условие: «Все вызовы API мигрированы на новую версию, сборка проходит успешно, тесты зелёные».
• Если условие не выполнено — цикл продолжается. Максимум можно ограничить, например, 20 раундами.
• Проблема «памяти» решается через файл CLOUD.md, куда записываются архитектурные решения, подводные камни, инсайты из предыдущих итераций. Если команда уже использует AGENTS.md, его можно импортировать в CLOUD.md. Агент читает эти заметки перед каждым раундом, чтобы не наступать на те же грабли.

⚡ Уровень 3: динамические workflow и конкурентная верификация

Для сверхсложных задач (например, аудит 500 файлов) один агент не справится — нужна параллельная работа.

• Fanout and Synthesize (распараллеливание и синтез). В Cloud Code можно написать скрипт на чистом JavaScript (или попросить Claude написать его), который создаёт десятки под-агентов, каждый со своей задачей: один читает финансы, другой анализирует коммиты, третий парсит отзывы. Данные собираются и сводятся в единый отчёт.
• Adversarial Verification (состязательная проверка). Один агент пишет код, второй агент получает задание проверить его на соответствие требованиям. Если второй находит логическую ошибку или потенциальную галлюцинацию — первый получает задание переписать фрагмент. Цикл повторяется, пока агент-проверяющий не даст добро.
• На этом уровне используется разделение труда: дорогостоящие модели (Claude Opus) для планирования и принятия решений, дешёвые (Claude Haiku) — для выполнения конкретных правок. Это радикально снижает токен-затраты.

🚫 Типичная ошибка: бросать огромную задачу в один цикл

Многие пытаются дать агенту единственный промпт «напиши полноценный интернет-магазин, при ошибках перезапускайся» и ждут чуда. Такой цикл либо никогда не завершится, либо сожжёт сотни долларов на токенах.

Суть loop engineering — в декомпозиции. Сложную бизнес-логику нужно разбить на атомарные, детерминированные операции, каждая из которых легко проверяется. Это не попытка обучить модель быть супермозгом, а проектирование конвейера, где каждый шаг делает ровно одну простую вещь.

Переход от prompt engineering к loop engineering — это сдвиг от «литературного» общения с моделью к системному проектированию: конечные автоматы, обработка исключений, метрики валидации, управление состоянием.

🔮 Будущее Loop Engineering

• Инфраструктура для агентов. Уже появятся специализированные фреймворки для оркестрации агентов, скрывающие boilerplate для циклов, откатов, параллельного выполнения.
• От статических циклов к динамическим. Сейчас структура цикла жёстко задана разработчиком. В будущем система будет сама на лету подбирать топологию цикла под сложность задачи: для простого бага — линейная цепочка, для рефакторинга — турнирная сетка параллельных агентов.
• Зависимость от локальных SLM. Когда цикл масштабируется, стоимость и задержка при каждом обращении к облачной модели становятся критическими. Ожидается архитектура: облачная модель (например, Opus) для роутинга и планирования, локальные малые модели (тонко настроенные SLM вроде специализированных версий) для массовых проверок и фильтрации. Это позволит 95% работы делать моделью в 10 раз дешевле, а оставшиеся 5% ошибок исправлять оркестратором.

🔚 Роль человека: определять, когда остановиться

Машины научились самоисправляться. Инженер больше не нужен, чтобы говорить агенту «сделай то» — это сделает архитектура цикла. Его истинная ценность — определить момент, когда процесс должен остановиться. Не пытаться идеальным промптом «убедить» AI, а строить механизмы, которые ограничивают неопределённость: тесты, логи, проверки, точки ручного контроля.

大家好,我是为什么叫QQ你现在用AI写代码是不是这样的?敲一段提示词,等它生成,看一眼,发现有个bug你再敲一段,这里有个空指针异常,改一下它改了你又发现逻辑不对,继续敲这个过程你一天要重复几十次,甚至上百次但这里有个很离谱的地方你买了一个号称能极大提升效率的自动化工具结果你自己却变成了这个工具的人肉API接口在做最枯燥的重复劳动2026年了如果你还在手动提示你的编码agent那你可能已经被时代甩在身后了今天我们要聊的是目前硅谷最前沿的工程范式转变它不叫harness engineering它叫loop engineering而且今天我不光讲理论我还要教你怎么用cursor和cloud code把这些理论落地在最近几个月X上几位重量级的AI工程师不约而同的开始讨论同一个话题先是OpenCloud的作者现在在OpenAI工作的Peter Stanberger发了一条推文他说你不应该在手动提示编码代理了你应该设计循环来提示你的代理紧接着知名开发者Eddie Osmani也发文解释Loop Engineering的本质就是替代你自己作为提示者的角色你要设计一个系统来代替你做这件事Anthropic团队的Lance Martin更是直接指出他们内部的工作方式已经完全被CloudFable 5这类模型改变了自纠正循环成了标准配置看到这里你可能会想这不就是自动化吗写个脚本掏个循环有什么新鲜的如果你这么想那就大错特错了Codex做过一个统计90%的开发者从来没有写过一个提示代理的循环绝大多数人依然停留在输入等待阅读再输入的原始阶段为什么一个听起来很简单的概念却有这么多人做不到Loop Engineering到底解决了什么深层次的工程痛点在深入拆解之前我们需要先对齐一下认知到底什么是Loop在传统的编程里循环就是for循环while循环条件满足就一直跑但在AI工程的语境下loop是一个地规的目标导向系统你定义一个最终目的比如实现一个支持OS登陆的接口然后你定义一套执行流程这个系统会自己生成代码自己跑测试自己看报错信息自己修改代码一遍一遍的迭代直到测试通过在这个过程中人类不再参与每一步提示但仍负责设定边界验收标准和关键审查为什么这个概念在2026年才彻底爆发因为底层模型的演进你回想一下两年前那时候的模型你敢让它自己跑循环吗它写错了一行代码你让它自己修它可能会把整个文件改得面目全非模型缺乏足够的自省能力和上下文窗口它很容易陷入死循环或者产生幻觉但现在随着类似CloudFable 5这种Midows级别模型的普及情况变了这类模型不仅在代码生成上更准更关键的是他们拥有了极强的自我纠正能力当模型具备了发现自己错误并修复的能力时人工介入就不再是必须的反而成了整个系统的性能瓶颈这就好比你有一辆具备L4级自动驾驶能力的车但你非要自己握着方向盘每到一个路口都手动告诉他怎么转弯这不叫驾驶这叫折磨那么一个成熟的loop到底长什么样在工程实践中我们怎么落地Anthropic Z Building Effective Agents中总结的不是六大loop而是一组可组合的Agentic Workflow链式处理路由 并行 编排 评估 优化以及更开放的Autonomous AgentLoop Engineering真正要做的是把这些模式组合成可验证可停止可回滚的工程系统我把这些核心思想结合Cursor和Cloud Code直接教你怎么落地第一层测试驱动与自纠正这是最基础也是最容易上手的Loop模式假设你要写一个把markdown转成html的复杂函数传统做法是你写提示词AI写代码你跑测试报错了你再把报错贴给AI但在cursor里你可以直接配置agent的运行模式打开agents的run mode设置选择run everything或autoreview这样agent就能自己执行终端命令读写代码等工具你的提示词只需要写一句先写测试再写代码然后运行测试并更新代码直到所有测试通过接下来魔法发生了Cursor会自动创建测试文件写实线代码在后台运行npm test如果有6个测试失败它会自己读取失败日志自己改代码再跑测试整个过程你的双手可以离开键盘去喝杯咖啡建议同时配置保护项在Command allowlist里添加npm testnpm run build pdst等常用命令开启file deletion protection防止自动删文件日常开发用AutoReview或Allowlist with Sandbox就够了Run Everything只在Demo或小项目里用这就是最典型的Loop Until Done模式你设定的停止条件是测试通过系统在这个闭环里自我纠正第二层目标导向与记忆持久化当你遇到跨越几十个文件的重构或者修复整个测试套件时单纯的自动执行模式就不够用了这时候我们需要Cloud Code的Go指令Go是目前最省时的功能它会在每一轮操作后用一个独立的评估者模型默认是骇哭来检查你的目标是否达成比如你要做一个API的迁移你输入go就API的每个调用点都已迁移完毕且构建成功20轮后停止注意这个写法的核心条件必须是可观察的最终状态你不能写让代码达到生产就绪因为AI没法验证你必须写测试通过且lent检查无误这样评估者才能通过读取终端输出判断是否真正完成对于那些需要定时轮巡的任务比如每小时检查一次CI状态你可以用Loop指令但这里有个关键AI是没有记忆的如果它在第五轮犯了个错怎么保证它在第15轮不犯同样的错CloudCode用Cloud.md来持久化项目指令如你的团队已经用Agence.md记录了架构规范和采锅的坑可以在Cloud.md里用atgents.md导入它这样AI在每一轮循环开始时都会先读取这些记录确保它不会在一个坑里跌倒两次第三层动态工作流与并发择优这是loopengineering的更高阶形态当任务变得极其复杂比如要做一份跨越500个文件的代码审计单线的agent就搞不定了我们需要并发在cloudcode里这被称为动态工作流它允许你用纯javascript编写一个编排脚本你可以用effort altercode的指令让cloud自动为你编写和运行这些工作流假设你要做竞品分析传统做法是一个agent从头搜到尾而在动态工作流中这叫fanout and synthesize发散与综合系统会同时生成数十个字代理一个去巴财报一个去分析github提交频率一个去爬用户评论他们同时开工最后由一个合并节点把数据汇总还有一种叫adversarial verification对抗验证如果你只用一个agent的生成代码它可能会偷懒产生幻觉怎么办引入一个找茬的agent agent A写代码Agent B拿着需求文档主行审查发现Elo直接打回重写这个循环一直跑到Agent B挑不出毛病为止在这个层级我们不仅使用了高级的规划模型如Cloud Fable, Opus来做决策还大量调用了成本极低的小模型Cloud Haiku来做具体的代码修改通过这种大脑加四肢的分层架构不仅提升了效率还能显著降低Token成本听到这里很多人会觉得哦我懂了Loop Engineering就是写个Wile循环把API包起来让它多跑几次呗但这里有个很离谱的误解Loop Engineering的本质根本不是关于AI的而是关于系统架构的很多人在尝试写Loop的时候最容易犯的错误就是把一个极其庞大模糊的任务直接扔进一个循环里指望模型通过不断重视来奇迹般的解决问题比如帮我写一个电商网站报错了就一直重视这种Loop跑一天也跑不出结果只会烧掉你几百块钱的Token费真正的loop engineering是对任务极其克制的解偶你需要把复杂的业务逻辑拆解成模型在当前能力下确定性极高的原子操作你不是在训练一个全能的超级大脑你是在设计一条流水线流水线上的每一个工位只做一件极其简单容易验证的事情所以从prompt engineering到loop engineering的转变实际上是从文科生思维向理科生思维的转变写prompt你是在雕琢语言用各种修制手法来哄骗模型输出好结果而设计loop你是在做系统工程你在设计状态机你在处理异常捕获你在设计验证指标你在管理状态流转这就解释了为什么大量开发者还停留在手动提示手动粘贴错误手动重视的阶段因为他们还在用跟人聊天的方式跟AI沟通而没有把AI当成一个可编程的系统组件那么对于我们普通的工程师来说这到底意味着什么这里有一个可能有点刺耳但非常现实的洞察在AI时代低级编码能力的价值正在快速归零但系统分解与编排能力的价值正在呈指数级上升如果你每天的工作只是把产品经理的一句话翻译成一段增删改查的代码那你就是那个随时可以背一个简单的loop until done脚本替换掉的节点但如果你是那个能够设计出这套loop的人呢如果你能把你们团队复杂的开发规范代码审查标准部署流程抽象成一套adversarial verification的规则如果你能设计出一个高容错低成本的并发架构那你就不再只是一个纯写代码的码农你成为了这套自动化流水线的架构师过去我们用代码来指挥CPU和内存现在我们用loop来指挥成群结队的智能体底层的逻辑其实没有变香农在信息论里告诉我们降低系统商的唯一方法就是引入负反馈loop engineering中的每一次验证每一次自纠正就是系统在或许负反馈通过测试日制评估器和人工验收点我们不是把LLM变成确定性系统而是把它的不确定性限制在可观察可纠错可回滚的边界里这就是工程师的浪漫我们不相信奇迹我们只相信机制展望未来从2026年往后看Loop Engineering会如何演进第一基础设施会全面爆发现在我们设计Loop可能还要自己手写很多状态管理的胶水代码很快就会有专门针对Agent的编排的框架出现他们会把重视机制状态回滚 并行控制封装的非常优雅第二 从静态loop走向动态loop现在的循环逻辑是我们预先硬编码写死的未来的系统可能会根据任务的复杂度在运行时动态生成最合适的loop拓扑结构遇到简单的bug走单线修复遇到架构重构自动展开成锦标赛模式第三对本地算力和SLM小语言模型的极度依赖当你开始跑大规模的loop时Token成本和延迟会成为致命问题把所有循环都跑到云端大模型上是不现实的我们一定会看到这样一种架构用云端的大模型做高阶的路由和规划然后把大量的验证过滤简单生成的循环交给本地部署的经过深度微调的小语言模型来跑这也是为什么像Cruiser Composer 2这种专门针对多文件编辑优化的轻量级模型会越来越受欢迎在此代理工作流中用便宜十倍的模型完成95%准确率的工作再由编排器纠正那5%的错误这才是工程上可落地的最优解最后我想用一句话来总结今天的内容不要再试图用完美的提示词去感动AI去设计无懈可击的循环来约束AI当机器开始学会自我迭代你的核心价值就不再是告诉它做什么而是定义它什么时候该停下看到这里你可能会想我自己平时的开发流理有哪些环节是可以立刻改成loop的我想把这个问题抛给大家把你每天最痛恨最重复的那个开发环节打在评论区我们一起来看看怎么用今天讲的loop模式结合cursor或cloudcode把它自动化掉如果你觉得这期视频对你有启发别忘了点赞投币收藏你的三连是我持续创作的最大动力我是飞什么叫QQ我们下期见

你有没有算过，每天在AI编程助手里敲了多少次提示词？等代码生成、看diff、发现bug、再敲提示词……这个重复的循环，正在吃掉你大量的开发时间。

2026年，AI工程领域正在经历一次深刻的范式转变——从Prompt Engineering（提示工程）走向Loop Engineering（循环工程）。包括Anthropic团队、OpenClaw作者Peter Steinberger在内的顶尖AI专家都在呼吁：不要再手动提示代理了，去设计能自动提示代理的循环系统！

本期视频，我们将从一线工程师的视角，深度拆解Loop Engineering的核心理念和【真实落地实操】。为什么90%的开发者还在做低效的手动提示？Anthropic总结的6大Loop模式在真实业务中怎么落地？

更重要的是，我们会手把手教你如何使用现有的顶尖工具（Cursor、Claude Code）来构建你的第一个Loop。我们会拆解Cursor的YOLO模式和Composer多文件编辑，演示Claude Code强大的/goal和/loop指令，以及如何通过动态工作流（Dynamic Workflows）和AGENTS.md来持久化AI的记忆。无论你是前端、后端还是算法工程师，掌握Loop设计，将是你未来几年的核心竞争力。

干货满满，建议先收藏再看。评论区聊聊：你现在的工作流里，有哪些环节是可以被Loop化的？

#LoopEngineering #AI工程 #Cursor实操 #ClaudeCode #动态工作流