Acceptance criteria для AI-агента, которые он поймет буквально

Agent пишет код не так, как вы хотели, по одной причине: он не знает, где стоит финишная черта. Acceptance criteria это и есть та черта, набор проверяемых условий готовности задачи. Пропишите их в промпте через формат given/when/then, добавьте edge cases и запреты, и нейросеть перестанет додумывать за вас. Ниже разберем формат, который агент читает буквально, дадим готовый шаблон и покажем, куда его класть в Cursor и Claude Code.

TL;DR: Acceptance criteria для AI-агента это список условий вида «дано -> действие -> результат», по которым видно, что задача готова. Формат given/when/then плюс блок edge cases и запретов снижает число итераций в разы. В статье: шаблон промпта, таблицы сравнения и примеры для Cursor и Claude Code.

Данные по инструментам актуальны на июль 2026.

Что такое acceptance criteria и зачем они AI-агенту

Acceptance criteria это набор условий, при которых задача считается выполненной. Для нейросети они работают как чек-лист готовности, по которому агент сам проверяет свою работу.

Критерии приемки пришли из гибкой разработки, где каждую пользовательскую историю сопровождает список условий. Когда все пункты выполнены, задача закрыта. Идея простая: критерии готовности переводят расплывчатое «сделай форму входа» в проверяемое «форма делает вот это, вот это и вот это». Автор ролика про написание критериев с ChatGPT формулирует то же самое: хорошие критерии тестируемые, понятные, лаконичные и согласованы со всеми участниками.

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

Почему агент игнорирует ваши требования

Чаще всего дело не в модели, а в формулировке. Размытый критерий вроде «удобная форма» агент понимает как угодно. Проверяемый критерий он выполняет буквально.

Ученые из ETH Zurich в феврале 2026 (исследование arXiv 2602.11988) прогнали 138 задач по 12 репозиториям и получили цифру: сгенерированные нейросетью файлы с контекстом снижали успех на 3%, а написанные человеком поднимали на 4%. Вывод простой -> критерии надо писать руками и коротко, а не поручать их сборку самой модели.

Три вещи ломают понимание чаще всего. Первое: вы описываете способ, а не результат. «Используй useState для формы» связывает агенту руки, хотя вам важно, чтобы форма просто работала. Второе: критерий нельзя проверить. «Быстрая загрузка» это не критерий, «первый экран рендерится за 1 секунду» это критерий. Третье: нет несчастливых путей. Агент пишет happy path и забывает про пустые поля и неверный ввод, потому что вы про них не сказали.

По факту размытость это главный враг. И лечится она форматом.

Как работает формат given/when/then для промпта

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

Формат родился в BDD и синтаксисе Gherkin для инструмента Cucumber, но для промпта фреймворк не нужен. Given задает контекст, When действие пользователя или системы в активном залоге, Then наблюдаемый итог. Одна связка = один проверяемый сценарий. Несколько условий склеиваются словом «и». Такой критерий агент понимает без переспросов.

Разберем на форме входа. Вместо «сделай логин» пишем сценарий: Given пользователь на /login, When вводит валидный email и пароль, Then редирект на /dashboard. Дальше добавляем ветку для ошибки: Given неверный пароль, When жмет «Войти», Then показывается сообщение об ошибке и поле пароля очищается.

Вот структура, по которой строится каждый пункт.

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

Что писать в edge cases, чтобы агент не сломал логику

Edge cases это несчастливые пути: пустой ввод, лимиты, отказы. Плюс блок запретов. Без них агент делает только happy path и роняет продукт на первом же неверном действии пользователя.

В гайде по правилам Cursor (cursor.com/docs/rules) есть точная мысль: сказать агенту, что делать, это половина работы. Вторая половина сказать, чего делать нельзя. Поэтому в критерии добавляют блок «НИКОГДА» с конкретными примерами неправильного поведения. Явный запрет весит больше десяти намеков.

Happy path это когда все идет по плану. Но продукт ломается на краях. Что будет, если email пустой? Если пароль ввели пять раз неверно? Если API не ответил? Эти ветки и есть edge cases, и агент про них молчит, пока вы не спросите.

Разбивайте так. Основной сценарий -> given/when/then для нормального хода. Альтернативные -> отдельные сценарии для каждой ошибки. Запреты -> список того, что агент не должен делать ни при каких условиях.

Пример блока запретов для формы входа:

• не хранить пароль в localStorage
• не отправлять пароль в параметрах URL
• не логировать пароль в консоль

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

Готовый шаблон acceptance criteria для промпта

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

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

Задача: [что делаем одним предложением]

Критерии готовности (выполни все):
- Given [контекст], When [действие], Then [результат].
- Given [контекст ошибки], When [действие], Then [сообщение + поведение].
- Given [граничный случай], Then [что происходит].

Нефункциональные:
- [скорость, например: ответ сервера не дольше 300 мс]
- [безопасность, например: пароль хешируется, не хранится в открытом виде]

НИКОГДА:
- [запрет 1 с конкретным примером]
- [запрет 2]

Готово, когда: все критерии выполнены, npm run test проходит,
в консоли нет ошибок.

Нефункциональные критерии часто забывают, а они решают. Пример из разбора системного аналитика: «время поездки формируется не более 1 секунды» это тоже критерий приемки, просто про скорость, а не про кнопку. Для AI-кода такими пунктами задают лимит ответа API, формат JSON, требования к доступности.

Строка «готово, когда» дает агенту стоп-сигнал. Без нее он либо не доводит, либо продолжает улучшать то, о чем вы не просили.

Как оформить критерии готовности в Cursor

Разовые критерии пишите прямо в чат. Постоянные правила проекта выносите в AGENTS.md или .cursor/rules, тогда Cursor подтягивает их в каждый запрос автоматически.

Cursor читает файл AGENTS.md в корне проекта и папку .cursor/rules с mdc-правилами. AGENTS.md это открытый стандарт под эгидой Linux Foundation (спецификация), его понимают больше 30 агентов в 60 000+ репозиториев. Простой markdown без схемы. Туда кладут стек, соглашения и границы, включая критерии, общие для всего проекта.

Логика простая. Критерии для конкретной задачи -> в промпт, они разовые. Критерии-константы уровня проекта («все формы валидируются через zod», «ошибки API в формате {error, code}») -> в файл правил, чтобы не повторять их каждый раз.

Совет из гайда по правилам Cursor: после того как записали критерий, откройте файл и попросите агента сгенерировать что-то, что должно ему следовать. Не следует -> формулировка нечеткая, правьте. Это тот же принцип, что и «прочитай критерий человеку, который не знает проект». Подробнее про сам редактор в нашем обзоре Cursor на VibeCoderz.

Как задать acceptance criteria в Claude Code

В Claude Code постоянные критерии живут в CLAUDE.md. Файл собирается командой /init и читается автоматически перед каждой задачей. Разовые критерии по-прежнему идут в промпт.

Claude Code использует свой файл памяти CLAUDE.md с более богатой моделью, чем плоский AGENTS.md, и тоже умеет читать AGENTS.md для совместимости. Команда /init сканирует кодовую базу и собирает черновик. Дальше его нужно урезать руками: то самое исследование ETH Zurich показало, что сырой автогенерат вредит, а вычищенный человеком файл помогает.

Практика у нас в VibeCoderz такая. В CLAUDE.md идут архитектурные критерии и запреты, которые действуют всегда. В промпт конкретной задачи идет блок given/when/then под нее. Так агент держит и общую рамку, и точечную границу готовности.

Вот куда что класть в двух инструментах.

Разберитесь один раз, и критерии перестанут теряться между сессиями. Обзор терминального агента у нас лежит на странице Claude Code, а рядом обзор GitHub Copilot для тех, кто работает в связке.

Чем acceptance criteria отличаются от Definition of Done

Acceptance criteria уникальны для задачи и описывают ее результат. Definition of Done это общие правила для всех задач: тесты, форматирование, отсутствие ошибок. Путать их дорого.

Разницу хорошо объясняет аналогия из ролика про критерии на примере торта. Заказ «шоколадный торт на 12 персон» это acceptance criteria, они свои для каждого заказа. А «торт охлажден, упакован, к нему приложена открытка» это Definition of Done, производственные практики, одинаковые для любого торта. Первое проверяет конкретный результат, второе гарантирует стабильность на потоке.

Для AI-кода это выглядит так. Acceptance criteria: «форма входа редиректит на /dashboard при верном пароле». Definition of Done: «код проходит линтер, покрыт тестами, не роняет сборку». Первое пишете под задачу. Второе прописываете один раз в rules-файл и распространяете на все.

Держите их раздельно. Смешаете -> критерии раздуются, а агент утонет в шуме и начнет пропускать главное.

Сколько критериев на одну задачу это норма

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

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

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

Лиза: «Прикинь, я раньше вручную разбирала 15-20 видео на одну контентную единицу. Потом написала скрипт в Google Таблицах: вставляешь ссылки -> транскрибация -> разбор по 15 критериям. Было 4 часа, стало 5,5 минут. Четкие критерии это и есть та штука, которая заставляет модель делать ровно то, что нужно, без ручной допилки.»

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

Частые ошибки в критериях для ai агента

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

Самая частая ошибка звучит безобидно: «сделай красиво и удобно». Агент выполнит это как понимает, и вы получите не то. По данным разборов, замена одного размытого критерия на проверяемый сценарий убирает в среднем одну итерацию ревью. На десяти задачах это десять сэкономленных проходов.

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

• Описываете реализацию вместо результата. Пишите «что», а не «как», решение оставьте агенту.
• Критерий нельзя проверить да/нет. «Интуитивный интерфейс» замените на «кнопка видна без прокрутки».
• Нет edge cases. Добавьте ветки для ошибок и пустого ввода.
• Нет запретов. Блок «НИКОГДА» с примерами дешевле, чем ловить дыры на ревью.
• Слишком много условий в одном промпте. Больше восьми -> дробите задачу.
• Критерии в настоящем времени путаются с будущим. Держите одно время, обычно настоящее.

Пройдитесь по списку перед отправкой промпта. Тридцать секунд проверки экономят цикл переписывания.

Мини-глоссарий

Короткие определения терминов из статьи. Для тех, кто пришел из маркетинга или дизайна и не варится в Agile-жаргоне.

Acceptance criteria (критерии приемки) это список проверяемых условий, при которых задача считается готовой.

Definition of Done (критерии готовности) это общие правила завершенности для всех задач проекта: тесты, стиль, отсутствие ошибок.

Given/when/then это формат записи критерия: контекст -> действие -> проверяемый результат.

Edge case (граничный случай) это нестандартная ситуация: пустой ввод, лимит, отказ сервиса.

Happy path это сценарий, когда все идет по плану, без ошибок.

BDD это разработка через описание поведения, откуда пришел формат given/when/then.

AGENTS.md, CLAUDE.md это markdown-файлы в корне проекта, куда кладут правила и критерии для AI-агента.

FAQ

Ответы на вопросы, которые чаще всего задают про acceptance criteria и промпты для нейросетей.

Что такое acceptance criteria простыми словами? Это список условий, при выполнении которых задача готова. Для AI-агента это граница: он понимает, что функция сделана, и не додумывает лишнего. Проверяется каждый пункт ответом «да» или «нет».

Обязателен ли формат given/when/then? Нет. Он удобен для поведения с входом и выходом: формы, API, пользовательские сценарии. Для чисто технических задач вроде настройки базы данных формат избыточен, хватит списка правил. Инструмент под диалог, а не догма.

Куда вставлять критерии, в промпт или в файл? Разовые под конкретную задачу пишите в промпт. Постоянные правила проекта выносите в AGENTS.md или .cursor/rules для Cursor и в CLAUDE.md для Claude Code. Тогда агент читает их автоматически, повторять не нужно.

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

Можно ли попросить нейросеть саму написать критерии? Как черновик да, как финал нет. Исследование ETH Zurich показало, что сырой автогенерат снижает успех задачи. Просите модель накидать варианты, потом урезайте и уточняйте руками.

Чем помогает блок запретов? Он закрывает типовые дыры, о которых агент молчит: хранение пароля не там, отправка данных не туда. Явный список «НИКОГДА» с примерами дешевле одного цикла ревью.

Работает ли это для новичка без опыта в разработке? Да. Формат given/when/then читается как обычный язык. Если можете описать, что должно произойти после нажатия кнопки, вы уже умеете писать критерии приемки для нейросети.

С чего начать прямо сейчас

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

Соберите свой первый блок критериев по шаблону из статьи и прогоните на реальной задаче в Cursor или Claude Code. Инструменты, которые упоминались, лежат в каталоге AI-инструментов VibeCoderz с обзорами, ценами и плюсами-минусами. Если хотите настроить связку промптов и правил под свой продукт, а не собирать методом проб, запишитесь на консультацию к Максиму. Разберет ваш стек и покажет, как выстроить процесс, чтобы агент делал с первого раза.

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

Материал команды VibeCoderz. Обновлено: июль 2026.