Когда людям всё ещё нужно сидеть за клавиатурой и построчно инструктировать агентов, ключевым навыком является написание подсказок. Сегодня агенты могут получать цель и действовать самостоятельно — новым ключевым навыком стала циклическая инженерия.

Автор статьи: CyrilXBT

Статья скомпилирована, источник: ME News

В июне 2026 года, в течение одной недели, три человека независимо друг от друга пришли к одному и тому же выводу.

Разработчик OpenClaw Питер Штейнбергер открыто заявил, что людям следует перестать напрямую писать подсказки для программных агентов и вместо этого создавать циклические системы, которые автоматически отправляют команды агентам.

Почти в то же время Борис Черни, ответственный за Anthropic Claude Code, также заявил, что больше не вводит подсказки непосредственно в Claude. Сейчас он запускает набор циклов, которые автоматически вызывают Claude и определяют следующие шаги, а его настоящая работа — написание и проектирование этих циклов.

Несколько дней спустя инженер Google Эдди Османи систематизировал эту практику и дал ей название:

Loop Engineering, циклическое инженерное дело.

Они не изобрели этот способ работы, а просто дали название уже происходящему изменению.

До этого базовые инструменты преодолели ключевой порог: программные агенты начали способны выполнять настоящие задачи без присмотра; стоимость автоматического планирования снизилась настолько, что повторное запускание задачи по расписанию больше не кажется расточительным; стоимость однократного запуска агента также снизилась до нового уровня — теперь дешевле позволить агенту попробовать пять раз, чем тратить много времени на тщательное обдумывание одного подхода.

Это именно то, для чего существует данный дорожный план.

Когда людям всё ещё нужно сидеть за клавиатурой и построчно инструктировать агентов, ключевым навыком является написание подсказок. Сегодня агенты могут получать цель и действовать самостоятельно — новым ключевым навыком стала циклическая инженерия.

Ниже приведён полный 20-шаговый путь от оператора промптов к системному дизайнеру. Необходимо продвигаться строго по порядку, поскольку последовательность шагов на этом пути зачастую важнее любого отдельного шага.

Циклическое инжиниринг — это не единственный навык, который либо освоен, либо нет, а набор слоёв компетенций, каждый из которых зависит от прочности нижележащих основ.

Например, если сразу создать автоматический триггер на шаге 14, прежде чем на шаге 10 установить настоящие условия остановки, вы получите систему, которая будет автоматически тратить ваши средства без присмотра. Раньше она хотя бы тратила ресурсы только тогда, когда вы смотрели на экран, а теперь она может самостоятельно непрерывно сжигать деньги.

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

Это не только не поможет системе развиваться, но и приведет к накоплению ошибочного опыта, превратив слой памяти из «временно бесполезного» в «активно вредный».

Поэтому пропуск некоторых шагов — это не просто отсутствие реализации одной функции. Более серьезная проблема заключается в том, что вы строите кажущиеся захватывающими продвинутые возможности на фундаменте, который не способен их поддержать, и часто обнаруживаете проблемы только после того, как система уже масштабировалась и вызвала реальные последствия.

Первый настоящий шаг не связан с какой-либо технологией.

Вы должны признать, что в текущем рабочем процессе ограничивающим фактором эффективности часто уже не является способность модели, а то, что вы всё ещё находитесь в цикле.

Каждый раз, когда вы сидите за компьютером, ожидая ответа модели, читаете результат и вводите следующую команду, вы становитесь самым медленным звеном всей системы.

Модель может выполнять, проверять и повторять эти операции со скоростью, намного превышающей скорость человеческого пошагового контроля за выполнением задачи.

Этот шаг не имеет соответствующих подсказок; это когнитивное решение.

До тех пор пока вы действительно не примете это, все последующие шаги будут казаться лишней дополнительной работой, а не их истинным смыслом — устранением самого большого узкого места в системе.

Когда возникают проблемы с выводом модели, самой естественной реакцией людей обычно является добавление еще одного правила в исходный запрос.

Через несколько месяцев такой подход создаст стену из правил: насыщенную, противоречивую и слишком длинную, чтобы модель могла одновременно обработать все требования в кратковременной памяти.

В конечном итоге модель часто может сопоставлять шаблоны только на основе недавно появившихся или наиболее заметных данных, незаметно игнорируя другие правила.

Circular engineering has completely transformed this approach.

Когда возникает проблема, вы больше не просто добавляете новое требование в подсказку, а добавляете новый компонент в систему, например:

• Добавьте отдельный шаг проверки;
• Добавить файл памяти;
• Добавить таймер-триггер;
• Добавьте структурированный этап оценки.

По мере усиления возможностей внешних систем сами промпты должны становиться все короче, а не длиннее.

Независимо от того, к какой области относится конкретная задача, каждое выполнение цикла можно разбить на пять базовых действий:

Идентификация, передача, проверка, сохранение, планирование.

Обнаружение

Определите, какая задача действительно должна быть выполнена.

Передача

Передайте задачу модели, агенту или инструменту, ответственному за выполнение.

Верификация

Проверьте результаты на соответствие реальным стандартам.

Постоянство (Persistence)

Запишите, что произошло во время этого запуска, и что вы узнали, чтобы не потерять опыт при следующем запуске.

Планирование

Определите, когда этот процесс должен быть запущен снова.

У большинства людей существующий рабочий процесс включает только первые два действия: идентификация задачи и передача задачи, причем обычно они выполняются вручную в окне чата.

Три других действия либо вообще не существуют, либо скрыты в собственном мозге человека.

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

Перед началом создания системы выберите задачу, которую вы уже регулярно выполняете и можете четко описать с точки зрения стандартов качества.

Не выбирайте самые сложные вопросы и не беритесь за инновационные задачи, не имеющие аналогов.

Первое кандидатское задание должно удовлетворять трем условиям:

1. Тебе нужно выполнять это повторно;
2. Он обладает четкими критериями, которые можно записать;
3. У него есть легко распознаваемый «статус завершения».

Другими словами, коллега, увидев результат, должен быстро определить, правильно ли выполнена задача.

Это ограничение важнее, чем кажется на первый взгляд.

Если у задачи нет четких критериев завершения, невозможно создать настоящий механизм проверки. А цикл без надежного механизма проверки — это не настоящий цикл, а всего лишь угадывание без контроля.

Это самый простой шаг, который пропускают большинство, но он является ключевым для обеспечения корректной работы системы в дальнейшем.

Прежде чем писать какие-либо инструкции для агента, сначала четко и естественно опишите, каким должен быть правильный результат.

Вам нужны конкретные, проверяемые стандарты, а не расплывчатые оценки качества, такие как «чувствуется хорошо» или «выглядит профессионально».

Можно использовать следующий шаблон:

Название задачи: [Название задачи]

Завершение определения (Definition of Done, DoD):

• [Конкретный, проверяемый стандарт 1]
• [Конкретные, проверяемые стандарты 2]
• [Конкретный, проверяемый стандарт 3]

Даже если финальный вывод выглядит завершенным и тщательно отредактированным, задача не может считаться выполненной, если отсутствует что-либо из вышеперечисленного.

Если вы не можете заполнить этот шаблон для текущей выбранной задачи, вернитесь к шагу 4 и выберите другую задачу, более подходящую для построения цикла.

Это наиболее важное архитектурное решение во всех циклических системах.

Роли, ответственные за генерацию результатов, и роли, ответственные за проверку результатов, должны быть разделены.

Причина в том, что, когда модель сразу после генерации содержимого проверяет свой собственный вывод, она часто склонна защищать только что сгенерированный ответ, а не действительно критически анализировать возможные проблемы в нем.

В рамках разумного цикла должно быть как минимум две отдельные роли:

Строитель

Разработчики имеют определенную свободу для творчества и отвечают за создание первого результата.

Рецензент (Judge)

Рецензент получает вывод строителя и определение завершения, разработанное на шаге 5, и оценивает, соответствует ли результат этим критериям.

В идеальном случае рецензенты также должны иметь доступ к независимым доказательствам, недоступным для разработчиков, например:

• Тестовый набор;
• Исходные данные;
• Реальные данные;
• Авторитетная база данных;
• Original task brief.

Таким образом, оценщик сможет сделать выводы на основе реальных доказательств, а не повторять субъективное мнение, используя те же рассуждения, что и создатель.

Если рецензент может видеть только вывод строителя, он может судить только о том, выглядит ли результат последовательным.

Он не может определить, действительно ли результат правильный.

Следовательно, рецензенты должны иметь объективные проверяемые основания, то есть Ground Truth. В зависимости от контекста это можно понимать как «базовые факты», «истинные данные» или «авторитетные источники».

Для различных задач объективные критерии также различаются.

Программная задача

Объективными основаниями являются набор тестов и результаты, полученные при реальном выполнении кода.

Задача по созданию контента

Объективные основания — это исходные материалы и краткое содержание. Рецензентам необходимо сравнить исходные материалы с сгенерированным текстом рядом.

Исследовательская задача

Objective basis is the original documents, papers, datasets, or authoritative sources explicitly required for use in the task.

Если вы не можете четко указать, на чем должны основываться проверки рецензентов, то ваш цикл не имеет настоящего механизма проверки, независимо от того, насколько уверенно звучит формулировка рецензентов.

Выводы строителя и заключения рецензента должны иметь четко определенную структуру, а не представлять собой свободно текущий естественный язык.

Иначе у следующего менеджера не будет стабильной и надежной информации для принятия решений и маршрутизации.

Строители могут использовать следующий формат вывода:

Вывод строителя:

• Финальный доставляемый контент;
• Степень уверенности в результате;
• Известная неопределенность.

Рецензенты могут использовать следующий формат вывода:

Вывод по оценке:

• PASS: успешно;
• FAIL：неудача;
• Требуется доработка:
• Обнаруженные конкретные проблемы;
• Объективные критерии или первоначальные доказательства, на которых основана данная проверка.

Перед подключением автоматического планирования и автоматического повтора сначала вручную выполните полный процесс «создатель — рецензент».

Внимательно прочитайте суждение, данное рецензентом, и задайте себе вопрос:

• Вы согласны с его выводом?
• Он когда-нибудь пропускал результат, который вы точно знали, что он неверен?
• Он неправильно отверг результат, который изначально был подходящим?

Если рецензент одобрил результат, который вы знаете, что он неверен, или отклонил результат, который на самом деле не имеет проблем, сначала исправьте объективные основания или стандарты, прежде чем продолжать построение системы.

Автоматизация неверного шага проверки приведет только к более быстрому производству ошибочных результатов.

Чтобы сделать пять вышеуказанных шагов более конкретными, мы можем рассмотреть типичную задачу: преобразование исходного материала в полноценную статью.

Шаг 5: Определите завершение

Критерии выполнения этой задачи могут быть следующими:

• Каждый факт в черновике может быть прослежен до явного содержания исходного источника;
• Черновик удовлетворяет всем конкретным требованиям отчета, включая объем, тон и структуру;
• Основной тезис оригинала сохранен четко и не размыт бессмысленным заполнением.

Шаг 6: Создатель генерирует черновик

Конструктор получает исходные материалы и краткое описание содержания, затем создает черновой вариант.

В то же время ему необходимо четко перечислить неопределенности, существовавшие в процессе написания, например:

• Действительно ли это число появляется в исходных данных;
• Является ли данный вывод явно указан в оригинальном тексте или был сделан моделью самостоятельно;
• Отсутствуют достаточные источники для этого факта.

Шаг 7: Рецензент проверяет по оригиналу

Рецензенты получают черновик и исходные материалы одновременно, а не только черновик.

Он должен отдельно проверить три критерия, определенные в задании, и для каждого критерия дать отдельный вывод «пройдено» или «не пройдено», а не сводить все измерения в один расплывчатый общий балл.

Объединение трех различных стандартов в один общий вывод скрывает, именно в каком из измерений возникла проблема. Это наиболее частая причина, по которой многие ранее работавшие циклы постепенно теряют ценность обратной связи.

Шаг 8: Структурированная передача

Вывод рецензента должен быть структурированным объектом, а не абзацем естественного языка с оговорками.

Он должен вывести три четких результата: «успешно» или «неудачно», и для каждого неудачного случая указать конкретную причину.

Шаг 9: Ручная проверка механизма отзыва

Ручное выполнение полного процесса перед запуском системы поможет вам определить, насколько строги или мягки рецензенты.

Слишком мягкий рецензент может пропустить вымышленные данные, поскольку статья написана плавно.

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

Эти две проблемы очень распространены при первой настройке.

Обнаружение их после 50 бездоглядных запусков системы намного дороже, чем устранение проблем при первоначальном ручном тестировании.

Менеджер отвечает за чтение оценок рецензентов и принятие решения о дальнейших действиях.

Условия остановки также должны присутствовать в менеджере и должны быть записаны в виде четкой жесткой логики, а не мягкой инструкции, которую модель может обойти с помощью самореинтерпретации.

Например:

Условие остановки:

• Максимальное количество изменений: 3;
• При неудаче третьего обзора отправьте полную историю на обработку человеку и не запускайте четвертую правку;
• Критерии качества: каждое действие, определённое в описании, должно отображать результат PASS;
• Лимит бюджета: если стоимость задачи превышает X или время выполнения превышает Y, задача должна быть немедленно остановлена независимо от текущего состояния.

Цикл без настоящего условия остановки — это не система, а долг, ожидающий раскрытия рисков.

Почему такие мягкие инструкции, как «останавливайтесь, когда результат достаточно хорош», ненадежны?

Потому что это всего лишь рекомендация.

Когда модель многократно изменялась, но все еще не прошла проверку, чтобы дать задаче кажущийся удовлетворительным завершением, она, скорее всего, убедит себя, что «эта версия достаточно близка к стандарту», и самостоятельно снизит порог оценки.

In contrast, iterative checks performed by code or explicit rules that managers cannot bypass through reasoning do not encounter this issue.

Если цикл при каждом запуске начинается с нуля, он не будет помнить, чему научился при предыдущем запуске.

Таким образом, необходимо добавить простой уровень постоянного хранения.

Можно создать файл для каждого нового опыта и в начале файла кратко описать его одним предложением:

• Что вы узнали;
• Что было исправлено;
• Почему этот опыт важен.

Основной принцип: записывать только новые знания, которые еще не были сохранены где-либо еще.

Повторяющаяся память — это не знания, а шум.

Для обеспечения долгосрочной эффективности механизма постоянства необходимо проявлять сдержанность при записи.

Легко возникает импульс записывать все детали выполнения, но это лишь воспроизводит проблему «перегруженных промптов», упомянутую на шаге 2, только на этот раз объектом расширения становится не промпт, а папка памяти.

Настоящие ценные опыт — это те, которые, если их забыть, потребуют больших усилий и времени для повторного открытия, а не просто обычные записи успешного выполнения по плану.

Простое добавление механизма постоянства в конечном итоге приведет к проблемам, аналогичным проблемам с чрезмерно длинными подсказками.

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

Следовательно, файлы памяти следует упорядочивать по фиксированному графику. Еженедельное выполнение обычно является разумной частотой.

Процесс упорядочивания включает:

• Проверить существующие данные;
• Объединить дублирующиеся данные;
• Сжать несколько похожих опытов в одно более четкое правило;
• Remove content that has been proven incorrect or outdated.

Цель — не накапливать все больше и больше файлов, а получить меньше информации, но с более высокой плотностью.

Многие полностью пропускают этот шаг, поскольку он не приносит немедленно видимых новых возможностей, а лишь предотвращает потенциальные проблемы в будущем.

Но именно из-за отсутствия немедленной обратной связи его следует четко включить в расписание, а не ждать, пока кто-то обнаружит, что папка с памятью стала трудноуправляемой.

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

При начале каждой новой задачи сначала просканируйте сводку предложений из файла памяти, чтобы определить, какой опыт действительно связан с текущей задачей, и загружайте только соответствующие данные.

Также следует четко потребовать от системы: если в существующей памяти нет никаких данных, применимых к текущей задаче, сразу сообщить, что подходящего опыта нет.

Не пытайтесь навязывать прошлый опыт к совершенно новой проблеме только потому, что система памяти уже существует.

Далее необходимо определить, когда этот цикл будет запускаться автоматически без ручного вмешательства.

Способы срабатывания могут включать:

• Cron-задача;
• Слушатель изменений файлов;
• Календарный триггер цикла;
• Триггер при изменении внешнего события или состояния.

Этот шаг превратит систему, которую можно запустить только вручную, в систему, способную работать даже во время вашего сна.

Ирония в том, что это обычно самый простой шаг в списке, но именно его многие люди откладывают, даже после завершения всех остальных компонентов.

Перед использованием цикла для любой важной задачи необходимо активно протестировать его на четыре режима отказа.

Тест 1: Невыполнимая задача

Предоставьте системе задачу, которую невозможно решить, чтобы подтвердить, что менеджер выйдет по условию остановки, а не зациклится бесконечно.

Если цикл тестировался только на задачах, которые могут быть успешно завершены, он никогда не доказал свою способность к грациозному сбою.

Тест 2: выглядит разумно, но на самом деле неверный результат

Предоставьте рецензенту вывод, в котором вы точно знаете, что есть незначительные ошибки.

Этот результат должен звучать очень плавно, но содержать намеренно встроенную ошибку в факте или логике.

Следите за тем, чтобы рецензенты обнаруживали проблемы, а не просто одобряли контент, потому что он звучит разумно.

Тест 3: Разработчики и рецензенты делятся слепыми зонами модели

Если создатель и рецензент используют одну и ту же базовую модель, можно намеренно ввести типичную ошибку, которую эта модель часто допускает, и наблюдать, пропустит ли рецензент её.

Если рецензент и создатель имеют одни и те же слепые зоны, то разделение ролей, предусмотренное на шаге 6, теряет смысл.

Тест 4: Расчет операционных расходов в наихудшем случае

Рассчитайте, сколько будет стоить этот цикл в худшем случае, исходя из максимального количества изменений, использования самой дорогой модели и максимально возможной длины вывода в разумных пределах.

Затем честно спросите себя:

Если бы это число появилось в реальном счете, вы бы чувствовали себя некомфортно?

Выполнение этих четырех тестов до обработки важных задач в цикле доверия позволяет выявить большинство потенциальных проблем заранее.

В противном случае эти проблемы, скорее всего, впервые проявятся перед клиентами и менеджерами или напрямую отразятся на вашем счете, а не в ходе теста, который вы контролируете самостоятельно.

После того как цикл начнет стабильно работать, не позволяйте всем персонажам использовать одну и ту же вашу любимую модель.

Разные роли в цикле предъявляют различные требования к способностям модели.

Строитель

Разработчики обычно должны использовать наиболее мощную модель.

Потому что он выполняет основную сложную логическую обработку и генерацию контента. Если здесь использовать модель с недостаточной мощностью, качество первого результата снизится, и потребуется больше циклов доработки.

В конечном итоге, затраты на исправление черновика низкого качества могут превысить затраты на использование более мощной модели с самого начала.

Рецензент

Рецензенты отвечают за проверку по четким критериям и обычно не требуют высокой степени креативности.

При достаточной конкретности стандартов более мелкая, менее дорогая и более быстрая модель также может надежно выполнять задачи рецензирования.

Небольшая модель, работающая по крайне четкому контрольному списку, может достигать стабильности, близкой к крупной модели, но при значительно более низких затратах и задержках.

Менеджер

Менеджер просто выполняет маршрутизацию по заранее заданным правилам и почти никогда не использует самые дорогие модели.

Его задача — выполнять уже определенную логику, а не проводить открытые рассуждения.

Кроме того, независимо от того, как работают строители и рецензенты, менеджер запускается как минимум один раз на каждую итерацию, поэтому его стоимость одного вызова особенно важна.

Разумная многоуровневая настройка обычно выглядит так:

• Сильная модель отвечает за создание;
• Дешевые и стабильные модели отвечают за регулярные проверки;
• Модели или правила с низкой стоимостью отвечают за маршрутизацию и управление.

Значительная оптимизация затрат в циклической системе обычно достигается за счет соответствия моделей и ролей.

Многие считают, что контроль затрат означает уменьшение количества циклов или правок. На самом деле более эффективный подход — сопоставить стоимость модели с реальной сложностью каждой роли в цикле.

После успешного первого цикла людям легко сразу попытаться одновременно создать несколько циклов и параллельно обрабатывать пять разных задач.

Даже если текущая архитектура уже поддерживает такое масштабирование, следует сдерживать эту импульс.

Сначала你应该让第一个循环稳定运行足够长的时间，直到你真正不再需要密切检查它的每一次输出。

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

Только достигнув этого состояния, следует начинать построение второго цикла.

Во втором цикле лучше выполнять задачу, явно отличающуюся от первой.

Таким образом можно проверить, обладает ли базовая архитектура настоящей универсальностью, а не просто все более тонкой настройкой для одной и той же задачи.

После запуска нескольких циклов одновременно необходимо создать единый мониторинговый просмотр, чтобы централизованно отслеживать стоимость всех циклов и случаи срабатывания условий остановки, а не просматривать каждый цикл отдельно.

В отдельности циклический бюджет задач может быть полностью обоснованным.

Но даже если все десять циклов работают в пределах своего бюджета, их общая стоимость все равно может достигнуть неожиданно высокого уровня.

Поскольку отдельные данные каждого цикла выглядят нормально, этот риск часто обнаруживается только при появлении сводного счета.

Помимо успешно выполненных задач, необходимо специально фиксировать каждый триггер условия остановки.

Если какой-либо цикл часто достигает максимального количества изменений, а другие циклы редко сталкиваются с такой ситуацией, передаваемый сигнал может быть не «эта задача особенно сложна», а:

• Критерии оценки установлены нерационально;
• Рецензенты слишком строги, из-за чего ни один результат не может быть одобрен;
• Система проверила объективные основания для ошибки;
• Само определение содержит проблемы.

Если отслеживать только успешные результаты и рассматривать каждое ручное обновление как независимое случайное событие, эта модель на уровне дизайна не будет обнаружена.

Этап 5: Станьте настоящим дизайнером систем Шаг 19: Перестаньте измерять себя количеством написанных промптов

Самый очевидный признак того, что смена мышления действительно завершена, — это изменение показателей, на которые вы обращаете внимание в повседневной жизни.

Операторы подсказок интересуются:

• Сколько эффективных промптов было написано сегодня?
• Какая подсказка работает лучше всего;
• Как сделать промпты более изящными.

Инженеры системы интересуются:

• Сколько циклов в настоящее время запущено;
• Какова надежность каждого цикла;
• Сколько времени система освободила для себя;
• Какие работы уже не требуют человеческого контроля?

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

Последний шаг уже не полностью связан с вашей собственной системой.

Он используется для проверки того, действительно ли вы поняли этот метод.

Тебе нужно попытаться объяснить пять основных действий другому человеку, не используя сложные термины:

Идентификация, передача, проверка, сохранение, планирование.

Если вы сможете带领 другого человека создать его первый цикл, используя только эти пять действий и предыдущие шаги, значит, вы действительно достигли трансформации, описанной в этом руководстве.

Ты больше не тот, кто находится внутри цикла и постоянно вводит следующую команду.

Вы стали тем, кто стоит вне цикла, проектирует систему и наблюдает, как она работает самостоятельно.

Пропустив шаги, вы незаметно накапливаете четыре вида расходов

В конце статьи необходимо дать предупреждение.

Пропуск шагов в этом roadmap часто не приводит к немедленному сбою системы.

Его неудачи обычно происходят тихо и даже в течение длительного времени остаются незамеченными, пока проблемы не накопятся до достаточно серьезного уровня.

Когда вы пропускаете шаги 6 и 7, не создавая действительно независимых рецензентов и не предоставляя надежных объективных оснований, долг по верификации начинает накапливаться.

Цикл на поверхности продолжает работать нормально, поскольку генерируемые результаты «выглядят неплохо».

Только когда ошибка накапливалась десятки раз и в конце концов была обнаружена, вы осознаете, что система с самого начала не могла правильно определить, верен ли результат.

Понимание может деградировать, когда вы пропускаете 20-й шаг.

Вы всё ещё используете цикл, который когда-то сами создали, но уже не можете чётко объяснить, зачем нужен каждый компонент, и не можете эффективно отлаживать систему при сбоях.

Причина в том, что вы никогда по-настоящему не усвоили логику, лежащую в основе этой архитектуры.

Когнитивная капитуляция возникает, если первый шаг никогда не был действительно завершен.

Даже если система проверки уже доказала свою надежность в течение длительного времени, вы все равно будете вручную проверять каждый результат из привычки.

Это поведение выглядит осторожным, но на самом деле сводит на нет весь смысл построения системы.

Если пропустить шаг 10 и не установить истинное условие остановки для цикла, может возникнуть неконтролируемое потребление токенов и стоимость вызовов.

Вы часто не замечаете проблему в тот момент, когда система начинает выходить из-под контроля, а лишь тогда, когда появляется финальный счет, понимаете, что цикл выполнил множество неэффективных вызовов.

Все вышеуказанные расходы можно избежать.

Способ избежать их — всегда одна и та же дисциплина:

Стройте по порядку, не пропускайте шаги, которые кажутся недостаточно впечатляющими.

Часто именно самые скучные части и играют настоящую роль:

• Четкое определение завершения;
• Надежные условия остановки;
• Verifiable objective evidence;
• Independent review mechanism.

В сравнении с теми частями, которые звучат более привлекательно — умными промптами, сложными схемами архитектуры системы — они далеко не так важны, как кажется.

На самом деле, качество системы определяется тем, знает ли система, что:

• Когда вы сами правы;
• Когда вы сами ошибаетесь;
• Когда нужно остановиться.

Это и есть всё различие между оператором промптов и разработчиком системы.

Разница заключается не в том, кто умнее, и не в том, кто может написать более впечатляющие промпты.

Настоящее различие заключается в том, есть ли у вас достаточно дисциплины, чтобы серьезно создавать那些枯燥、容易被跳过，却真正决定系统可靠性的部分。