# Критерии приёмки в задаче для ИИ: как написать проверяемый результат > Критерий приёмки описывает наблюдаемый факт, по которому работа считается завершённой. «Сделать удобно» не проверяется; «на mobile 390 px форма помещается без горизонтального скролла и отправляется клавишей Enter» проверяется. Для ИИ-задачи нужны не все возможные тесты, а минимальный набор, который ловит наиболее опасные ошибки конкретного результата. Как превратить пожелание в наблюдаемые критерии: пользовательский результат, данные, ошибки, mobile, restart, безопасность и доказательства выполнения. - Формат: статья - Темы: Effort, Критерии приёмки, Промпт, Тестирование - Автор: Редакция Нейроквалификатора - Опубликовано: 2026-09-06 - Обновлено: 2026-09-06 - Время чтения: 3 мин. - Редакционная проверка: Текст сверён с рабочим кабинетом, границами коробочного продукта и указанными первичными источниками ## Редакционные иллюстрации [Размытое пожелание превращается в чек-лист пользовательского пути, ошибок, mobile и restart]() - Приёмка фиксирует наблюдаемый результат и опасные отрицательные сценарии, а не субъективное «нравится». ## Начните с видимого результата Опишите, что пользователь сможет сделать после изменения и что увидит. Это связывает реализацию с задачей, а не с количеством файлов. Для статьи результатом может быть индексируемый URL с прямым ответом и источниками. Для формы - созданная запись и понятное состояние ошибки. ## Добавьте положительный и отрицательные сценарии Положительный сценарий подтверждает основной путь. Отрицательные показывают, что система не принимает неверные данные и не выполняет запрещённое действие. Для критичного пути полезно минимум два отрицательных случая: неправильный ввод и недоступность зависимости. ## Проверяйте на нужных слоях Unit проверяет доменную логику, integration - реальную базу или внешний контракт, browser smoke - пользовательский путь. Restart подтверждает сохранение состояния. Не требуйте браузер для чистой функции и не ограничивайтесь unit-тестом там, где ошибка возникает только между сервисами. ## Пишите точные, но не хрупкие условия Проверяйте смысл и состояние, а не случайный CSS-класс, если класс не является контрактом. Укажите viewport, статус, обязательные поля и отсутствие ошибок. Критерий не должен диктовать архитектуру без причины. «Данные сохраняются после restart» полезнее, чем «создай вторую базу». - что сделать; - в каких условиях; - какой результат наблюдать; - какое запрещённое последствие отсутствует. ## Заранее определите доказательство Команда и её exit code подтверждают test или build. Скриншот показывает конкретное визуальное состояние. Запрос к API подтверждает контракт, а запись в базе - сохранение. Слова исполнителя «проверил, всё работает» не являются достаточным evidence для рискованной части. ## Пример слабой и сильной приёмки Слабо: «бот должен хорошо отвечать». Сильнее: «на вопрос из опубликованного FAQ бот отвечает по источнику; неизвестную цену не придумывает; просьбу позвать человека передаёт один раз; duplicate update не создаёт второй ответ». Вторая версия определяет четыре свойства, которые можно воспроизвести и защитить регрессией. ## Когда критериев достаточно Покрыты основной результат, критические границы и реальные точки интеграции. Остальные идеи записаны в backlog, а не добавлены в текущую задачу. Effort может предложить структуру приёмки, но риск и достаточность подтверждает владелец продукта. ## Экран продукта **Настоящий экран Effort.** Effort помогает сделать контекст, ограничения и критерии результата явными до передачи задачи ИИ. [Настоящий экран Effort с исходной мыслью и структурированной постановкой задачи]() ## Источники - [Codex documentation]() — OpenAI Developers; проверено 2026-09-06. Сверены рабочий цикл Codex, роль инструкций проекта, локальных проверок и ограниченной области изменений. - [Claude Code best practices]() — Anthropic; проверено 2026-09-06. Сверены рекомендации исследовать контекст, планировать сложную работу, давать модели способы проверки и вести постоянные инструкции проекта. - [Prompt engineering]() — OpenAI Developers; проверено 2026-09-06. Сверены рекомендации о ясных инструкциях, релевантном контексте, примерах и проверяемом формате результата. - [Effort Translator: рабочий интерфейс]() — Нейроквалификатор; проверено 2026-09-06. Сверена граница продукта: перевод исходной мысли в структурированную постановку без подмены цели и без гарантии результата. ## Сделайте постановку задачи проверяемой Effort помогает структурировать исходную мысль. Он не заменяет модель, не знает скрытый контекст и не гарантирует качество результата. [Подготовить запрос в Effort]() ## Связанный материал [Как написать задачу для Codex]() — Поместите критерии в полный инженерный запрос. ### Версии и навигация - [Каноническая HTML-версия]() - [Карта сайта для ИИ-инструментов]() - [Каталог статей и видео]()