Промпт-паттерн Архитектор-Исполнитель-Ревьюер: как заставить ИИ сначала спланировать, потом выполнить и затем проверить себя по чек-листу, находя риски.
Ответы ИИ часто звучат уверенно, даже когда в них есть пробелы. Модель может «догадаться» о требованиях, перепутать ограничения, не заметить крайние случаи или добавить правдоподобную, но неверную деталь. Если принять такой ответ как готовый, ошибки переедут в текст, план или код.
Разделение на роли внутри одного диалога заставляет ИИ работать не только на скорость, но и на качество. В этом подходе одна роль держит в голове структуру и риски, другая делает конкретную работу, а третья проверяет результат по заранее понятным критериям. Так вы реже получаете красивое, но хрупкое решение.
Паттерн Архитектор-Исполнитель-Ревьюер полезен, когда задача многослойная и важны детали: статьи и письма, небольшие фичи и интеграции, планы проектов, требования и acceptance criteria.
Представьте небольшой сервис: «форма заявки + сохранение в базу + уведомление». Архитектор предложит схему экранов и API, заранее подумает про валидацию, ошибки и права доступа. Исполнитель сделает конкретные тексты, эндпоинты или компоненты. Ревьюер пройдет по чек-листу и покажет, что не учтено: защита от дублей, обработка пустых значений, понятные сообщения об ошибках.
Важно помнить границы. Паттерн не заменяет фактчекинг, доступ к реальным данным и вашу ответственность. Он не гарантирует «истину без источников» и не снимает необходимости отдельно проверять юридические, финансовые и медицинские утверждения.
Зато он помогает заметить слабые места до того, как вы потратите время на переделки. В vibe-coding на TakProsto такой подход особенно удобен: один диалог хранит замысел, реализацию и список замечаний, к которым можно вернуться перед экспортом кода или деплоем.
Паттерн делит один диалог с LLM на три последовательные роли. Логика простая: сначала ясный план, затем аккуратное выполнение, потом критичная проверка результата. Так меньше хаоса и меньше пропусков, а довести ответ до состояния «можно использовать» проще.
Архитектор отвечает за постановку задачи. Он не пишет финальный текст или код, а собирает рамку, по которой дальше работает Исполнитель.
Обычно Архитектор фиксирует цель (что хотим получить на выходе), контекст (для кого и где это будет использоваться), ограничения (формат, тон, запреты, сроки), план шагов и критерии успеха. Критерии важны: без них Ревьюеру нечего проверять.
Исполнитель делает работу строго по плану Архитектора. «Строго» здесь ключевое: не добавлять лишние части, не менять формат и не расширять задачу без запроса.
Если задача про текст, Исполнитель пишет текст заданного объема и структуры. Если задача про vibe-coding, он собирает каркас: экраны, API, схемы данных. В TakProsto это удобно тем, что Архитектор заранее закрепляет правила (например, фронт на React, бэкенд на Go и PostgreSQL, мобильное на Flutter), а Исполнитель реализует по этим условиям, не перескакивая на другой стек.
Ревьюер включает критическое мышление. Он проверяет результат Исполнителя по критериям Архитектора и ищет то, что часто пропускают: противоречия, недосказанность, риски, места, где модель могла «додумать факты».
Хороший Ревьюер не переписывает все заново. Он возвращает конкретные замечания и точечные предложения: что поменять, где уточнить входные данные, какие пункты плана не выполнены, какие требования нарушены.
Чтобы паттерн работал стабильно, заранее закрепите формат блоков. Например:
Если повторять один и тот же формат из задачи в задачу, качество растет само собой: модель меньше импровизирует, а вы быстрее видите, где именно ответ «просел».
Паттерну нужны хорошие вводные. Чем точнее рамки, тем меньше догадок и тем проще поймать ошибки на ревью.
Начните с контекста и исходных данных: для кого делается результат, где он будет использоваться, что уже известно. Если есть материалы, вставьте их прямо в диалог: требования, тексты, таблицы, куски кода, логи. Если данных нет, лучше прямо так и написать, чтобы модель не достраивала «факты».
Затем зафиксируйте, каким должен быть результат. Большая часть проблем возникает не из-за «плохого ИИ», а из-за неясного формата. Укажите язык, тон, объем, структуру и то, что именно должно быть на выходе (план, черновик письма, список задач, спецификация).
Полезно заранее задать критерии качества, чтобы потом по ним же проверять работу. Чаще всего хватает нескольких: точность (не придумывать числа, цитаты и источники), полнота (закрыть все пункты требований), проверяемость (спорное помечать как гипотезы), безопасность (не раскрывать персональные данные и секреты), практичность (рекомендации должны быть выполнимы в ваших условиях).
Отдельно пропишите запреты и ограничения по инструментам и среде: какие технологии допустимы, какие данные нельзя использовать, какие решения точно не подходят. Если вы делаете прототип в TakProsto, можно сразу указать стек и организационные требования (например, хранение данных в РФ).
И наконец, договоритесь о работе с неизвестным: если данных не хватает, модель задает вопросы, а не угадывает. Например: «Если не указан формат отчета, задай 3 уточняющих вопроса и предложи 2 варианта по умолчанию». Это экономит итерации и делает итог заметно надежнее.
Роли должны говорить по очереди и не подменять друг друга. Один раз задайте правила, дальше повторяйте цикл только там, где нашли ошибки.
Полезная привычка: сначала попросить Архитектора предложить несколько вариантов и коротко сравнить их, а не писать «единственно правильное» решение с ходу.
Критерии приемки должны быть проверяемыми. Не «сделай красиво», а «верни таблицу из 10 строк, поля такие-то, ошибки обработаны так-то».
Ниже заготовка, которую удобно копировать. Она подходит и для обычных задач, и для vibe-coding, в том числе в TakProsto, когда вы хотите получить план, реализацию и самопроверку в одном диалоге.
Ты работаешь в трех ролях по очереди: Архитектор -> Исполнитель -> Ревьюер.
Общие правила:
- Не смешивай роли. Пиши строго блоками с заголовками.
- Нельзя менять требования без моего подтверждения.
- Если данных не хватает, задай до 5 уточняющих вопросов и остановись.
Входные данные:
- Задача: <описание>
- Контекст/ограничения: <сроки, стек, объем, запреты>
- Формат результата: <например: план + код + тест-кейсы/примеры>
Роль: Архитектор
1) Предложи 2-3 варианта решения.
2) Сравни варианты и выбери один.
3) Дай план в 5-8 шагов.
4) Запиши критерии приемки (5-7 пунктов).
Роль: Исполнитель
- Выполни план.
- Следуй критериям приемки.
- Выдай результат в формате: <...>.
Роль: Ревьюер
- Проверь по чек-листу: полнота, соответствие требованиям, логические ошибки, крайние случаи, безопасность/приватность, ясность.
- Верни: (а) список проблем, (б) правки, (в) как проверить, что стало ок.
Если хотите усилить контроль качества, добавьте явную просьбу: «Ревьюер, укажи 3 самых вероятных места, где ответ может быть неверным, и что спросить у пользователя для проверки». В этом паттерне ценность дает именно самопроверка, а не только быстрый ответ.
Роль Ревьюера отделяет «сделано похоже» от «сделано правильно». Полезное правило: Ревьюер не дописывает решение как автор, а проверяет и возвращает замечания и риски.
Эти вопросы ловят большую часть проблем еще до деталей:
После этого обычно понятно, что именно уточнять: цель, вводные или критерии готовности.
Если Ревьюер не уверен, лучше обозначить границы и запросить недостающие данные. Удобный формат: «что точно», «что предполагаю», «что нужно уточнить».
Пример: Исполнитель сделал план фичи «экспорт кода и деплой» для приложения. Ревьюер проверяет, учтен ли откат (snapshots/rollback), кто хранит секреты, что делать при ошибке деплоя и где проходят данные. Если вы делаете это в TakProsto, полезно отдельно сверить ожидания по приватности и размещению на российских серверах.
Представим мини-проект: небольшой веб-сервис и один экран мобильного приложения для учета заявок в офисе («починить принтер», «заказать пропуск»). Цель не в идеальной детализации, а в том, чтобы за один диалог получить понятный план, черновик API и самопроверку.
Архитектор формулирует, что считаем готовым: пользователь может войти, создать заявку, увидеть список, а администратор - менять статус. Затем описывает модули и данные без «магии»: React веб-панель, Go API, PostgreSQL и один Flutter-экран «Мои заявки».
Базовый костяк обычно включает аутентификацию (роли user/admin), заявки (создание, список, карточка, смена статуса), уведомления (история событий), админскую часть (фильтры, назначение исполнителя) и несколько нефункциональных требований: логирование, обработка ошибок, миграции.
Критерии готовности: заявка сохраняется в базе, статусы меняются с проверками, ошибки понятные, действия логируются.
Исполнитель превращает план в конкретику: пользовательские потоки и минимальный контракт API. Например: «Войти -> создать заявку -> увидеть ее в списке -> открыть карточку».
Черновик API часто выглядит так: POST /auth/login, POST /tickets, GET /tickets, GET /tickets/{id}, PATCH /tickets/{id} (status, assignee). Базовые поля: id, title, description, priority, status, created_at, created_by, updated_at.
Ревьюер проходит по чек-листу и задает неприятные вопросы. Что будет, если пользователь попытается изменить чужую заявку? Что вернет API при неверном статусе? Как мы узнаем, кто и когда поменял статус?
Частые находки: авторизация (права на чтение и изменение), валидация (пустой заголовок, слишком длинное описание, недопустимый статус), единый формат ошибок и коды (400/401/403/404/409), миграции (таблицы tickets, users, audit_log и порядок применения), логирование (корреляционный id и запись важных действий).
После ревью Исполнитель правит API (например, добавляет audit_log и ограничивает PATCH только для admin), уточняет сценарии ошибок и обновляет критерии готовности. В TakProsto это удобно делать в одном чате: план, реализация и самопроверка остаются рядом, а правки вносятся сразу.
Самая частая причина, почему паттерн не дает качества, простая: роли не разделены. В итоге модель одновременно придумывает архитектуру, пишет решение и сразу же его защищает, не находя слабых мест.
Проблема часто начинается с формулировок. Если написать «придумай, сделай, проверь», но не задать границы (кто и когда говорит), роли смешиваются, а ревью становится формальным.
Вторая ловушка - критерии уровня «сделай хорошо». Без измеримых требований ИИ выберет удобный для себя вариант: пропустит обработку ошибок, не уточнит ограничения, не проверит крайние случаи.
Еще одна частая поломка: Ревьюер превращается в Исполнителя и переписывает все с нуля. На вид это «продуктивно», но процесс ломается: теряется связь между планом, реализацией и правками, а ошибки начинают повторяться.
И, наконец, если не просить риски и допущения, модель будет уверенно заполнять пробелы. Например, в задаче по vibe-coding вы не указали роли пользователей и требования к данным, а ИИ уже «точно знает», что нужна сложная схема прав.
Несколько правил, которые делают паттерн предсказуемым:
Пример из практики: вы в TakProsto просите сделать API для небольшого сервиса (Go + PostgreSQL). Если не указать, как обрабатывать ошибки и какие эндпоинты обязательны, Исполнитель выдаст аккуратный скелет, а Ревьюер может не заметить, что нет валидаций и сценариев конкурентного обновления. Лучше заранее сказать: «готово, когда есть 3 эндпоинта, коды ошибок, миграции и один тест на крайний случай», а Ревьюеру дать обязанность назвать минимум 5 рисков и 5 вопросов.
Главное - не гнаться за идеалом. Самопроверка нужна, чтобы быстро поймать крупные дыры и сделать следующий шаг осмысленным, а не бесконечным.
Базовая схема Архитектор-Исполнитель-Ревьюер хорошо работает, когда задача понятна и цена ошибки невысока. Но если вы пишете публичный текст, готовите релиз, делаете платежный флоу или просто не уверены во вводных, добавьте несколько правил. Это помогает заранее убрать типичные провалы: недосказанность, самодеятельность Исполнителя и поверхностную проверку.
Иногда один Ревьюер пытается проверять все сразу: смысл, факты, тон, риски, приватность. Практичнее разделить ревью на два независимых прогона: один смотрит читабельность и тон, другой - безопасность и утечки данных.
Это особенно уместно в vibe-coding, когда вы генерируете и код, и тексты вокруг него (описания API, инструкции, сообщения об ошибках). В TakProsto можно попросить два ревью подряд в одном чате, но с разными чек-листами.
Не каждой задаче нужен «аудит». Удобное правило: сначала быстрый чек, а глубокая проверка включается только по триггерам.
Быстрый чек закрывает формат, базовую логику и явные пропуски. Глубокая проверка идет в крайние случаи, безопасность, сценарии отказа и тестовые случаи. Триггеры обычно понятны: деньги, персональные данные, интеграции, продакшн, юридические формулировки.
Если входные данные расплывчаты, запретите Архитектору сразу предлагать решение. Пусть сначала задаст 3-7 уточняющих вопросов и только потом строит план. Так меньше шансов получить «красивый, но не тот» результат.
Простой пример: вы просите «сделай форму регистрации». Без уточнений ИИ выберет поля и правила наугад. В режиме вопросов Архитектор уточнит, какие поля обязательны, нужен ли телефон, какой язык интерфейса, какие ограничения и что считается успехом.
Частая ошибка: Архитектор дал план, а Исполнитель по пути добавил «удобные улучшения» и поменял требования. Помогает правило: Исполнитель реализует только согласованное, а новые идеи оформляет как короткий список предложений после результата.
Так ревью становится честным: критерии не плавают.
Чтобы диалог не зацикливался, задайте явный стоп. Например, максимум 2 итерации (архитектура -> исполнение -> ревью -> правки -> финальное ревью) или список обязательных проверок, без которых нельзя завершить (граничные случаи, сообщения об ошибках, безопасность, соответствие требованиям, тестовый сценарий).
Перед тем как запускать паттерн, сделайте минутную проверку. Она часто экономит часы.
Начните с цели. Хорошая цель помещается в одно предложение и понятна человеку, который не видел переписку. Плохо: «Помоги с проектом». Хорошо: «Составь план и черновик текстов для лендинга сервиса доставки в Казани, чтобы запустить рекламу на следующей неделе».
Дальше проверьте входные данные. Если вы не перечислили, что у вас уже есть (и что нужно придумать), модель начнет гадать. И сразу задайте правило на случай нехватки информации: «если данных не хватает - задай до 5 уточняющих вопросов, иначе используй разумные допущения и пометь их как допущения».
Мини-чек-лист перед отправкой:
Пример для vibe-coding в TakProsto: вы просите собрать экран регистрации. Если не задать критерии приемки, Исполнитель может сделать «приятный» UI, но забыть валидацию, тексты ошибок или требования к паролю. А если формат не задан, вы получите рассуждения вместо структуры: поля, состояния, сценарии.
Финальная самопроверка простая: вы сами сможете быстро прочитать промпт и понять, что получится на выходе? Если нет, уточните цель, формат или приемку до запуска.
Чтобы паттерн реально помогал, начните с пары повторяющихся задач, где вы часто правите результат: форма заявки, отчет, небольшой API-эндпоинт, экран мобильного приложения. На таких кейсах проще отточить роли и понять, какие проверки нужны именно вам.
Дальше заведите единый шаблон ролей и относитесь к нему как к рабочему артефакту: обновляйте формулировки после каждого ревью. Через несколько итераций получается «ваш» шаблон, который дает стабильный результат.
Практичный ритм выглядит так:
Пример: вы делаете мини-приложение для записи клиентов. В Planning mode уточняете поля (имя, телефон, время), правила (нельзя записать на прошедшее время), роли (админ видит все). Потом генерируете, Ревьюер отмечает риск: нет валидации времени, не описаны сценарии удаления данных. Вы правите требования, делаете новый снимок и шаг за шагом приходите к аккуратной версии.
Когда людей несколько, качество держится на простых договоренностях: кто играет Ревьюера и по какому чек-листу, что считается «готово», как называются версии и когда делаются snapshots, где хранится общий шаблон ролей, как эскалируются спорные решения.
Если нужен дополнительный контроль, можно экспортировать исходники и продолжать работу вне платформы, оставив TakProsto как среду для быстрых итераций. Если вы ведете процесс системно, этот паттерн хорошо ложится в командные правила: один формат, понятная приемка и ревью, которое находит риски до релиза.
Используйте его, когда важны детали и цена ошибки заметна: требования, планы, письма, спецификации, небольшие фичи и интеграции. Для простого вопроса «как сделать X» он может быть избыточным, но для задач, где легко пропустить крайний случай, почти всегда окупается.
Попросите Архитектора сначала зафиксировать цель, контекст, ограничения, план и критерии приемки. Затем дайте Исполнителю команду выполнить строго по этому плану без добавлений. В конце включите Ревьюера и потребуйте проверку именно по критериям, плюс список рисков и точечных правок.
Заранее запретите смешивать роли и закрепите формат блоков. Также помогает правило остановки: если данных не хватает, роль задает до 3–5 вопросов и останавливается, вместо того чтобы «додумывать» и двигаться дальше.
Минимум: цель в одном предложении, кто пользователь результата, где это будет использоваться, ограничения по формату и стеку, и что считать «готово». Если есть исходники, требования, логи или таблицы, вставляйте их прямо в диалог, чтобы ИИ не заполнял пробелы выдумками.
Сделайте их проверяемыми: входы, выходы, формат, обязательные части, обработка ошибок и крайние случаи. Вместо «сделай хорошо» пишите «верни 3 эндпоинта, единый формат ошибок, валидацию полей и пример тестового сценария». Тогда ревью будет предметным, а не «в целом неплохо».
Дайте Исполнителю прямой запрет расширять задачу и менять требования. Если у него появились идеи, пусть вынесет их отдельным коротким абзацем после результата как предложения, а не внедряет по ходу. Это сохраняет связь между планом, реализацией и проверкой.
Попросите его не переписывать все заново, а вернуть список проблем, конкретные правки и способ проверки. Полезно требовать приоритизацию (например, критично/важно/желательно) и явные допущения: что он считает неизвестным и где мог ошибиться.
Чаще всего провалы в авторизации и правах доступа, валидации и обработке пустых значений, единых форматах ошибок, защите от дублей и конкурирующих обновлений, логировании важных действий и миграциях базы. Ревьюер должен специально пройтись по сценариям отказа и «что если пользователь делает не то».
Начните с Planning mode: Архитектор фиксирует стек (React, Go, PostgreSQL, Flutter при необходимости), сценарии и критерии готовности. Потом Исполнитель собирает первый рабочий каркас, а Ревьюер проверяет риски по данным, ошибкам и краям. После удачных шагов делайте snapshots, а если правки увели не туда — откатывайтесь через rollback.
Нет, он повышает шанс поймать логические дыры, но не заменяет фактчекинг и доступ к реальным данным. Все юридические, финансовые и медицинские утверждения нужно проверять отдельно, а спорные места помечать как гипотезы и уточнять у источников.