Как поставить задачу, чтобы агент понял с первого раза
Коротко
Большинство «агент сделал не то» — это не про агента, а про постановку. Модель не читает мысли: она заполняет пробелы догадками, и догадки редко совпадают с тем, что было у вас в голове.
Хорошая постановка держится на четырёх опорах:
- Намерение — что и, главное, зачем. «Форма обратной связи, чтобы люди могли жаловаться на баги» лучше, чем просто «форма».
- Границы (scope) — что НЕ входит. «Только отправка на почту, без базы данных и без админки» отсекает лишнюю работу.
- Критерий готовности — как вы поймёте, что готово. «Отправил → пришло письмо → увидел «спасибо»».
- Контекст — где это живёт. «Это React-проект, форма — на странице /contact».
Хорошая новость: движок Quest спроектирован так, чтобы добирать недостающее за вас — но чем лучше вход, тем меньше кругов уточнений.
Почему это важно
Каждая недосказанность — это развилка, на которой агент выберет за вас. Без «критерия готовности» он остановится там, где сам сочтёт нужным. Без «границ» — сделает лишнее (и, возможно, что-нибудь заденет). Без «зачем» — решит не ту задачу технически правильно.
В движке Quest есть встроенная защита от этого — слой элицитации: движок превращает «хочу CRM» в качественную спеку через короткие вопросы-развилки, у каждого — рекомендация по умолчанию («как обычно делают»). Но лимит таких вопросов небольшой (движок бережёт ваше время), поэтому то, что вы сказали сразу, экономит эти вопросы для по-настоящему важных развилок.
Плохо → хорошо (шаблон)
Плохо: «Сделай логин.»
Хорошо: «Добавь вход по email + пароль в мой React+Express-проект. Только вход и регистрация, без восстановления пароля и без OAuth (это потом). Готово = могу зарегистрироваться, выйти, войти снова, и защищённая страница /dashboard недоступна без входа.»
Вторая формулировка задаёт намерение, границы, критерий и контекст — и агенту почти нечего додумывать.
Как это работает в движке: вход → что делает движок → результат
Вход (намеренно неполный, как в жизни):
«Хочу CRM для моей мастерской.»
Что делает движок (слой intake + роли владельца продукта и аналитика):
- Не пишет код сразу. Сначала задаёт батч вопросов-развилок с рекомендацией:
- «Кто ведёт учёт — вы один или команда? (рекомендую: с полем «ответственный», это почти не усложняет)»
- «Главная сущность — клиент, заказ или и то, и другое? (рекомендую: клиент → заказы, самое частое)»
- «Нужны напоминания о заказах? (рекомендую отложить в backlog для первой версии)»
- Собирает из ответов спеку в EARS — точные требования с happy path, краевыми случаями и ошибками:
КОГДА добавлен клиент без телефона, СИСТЕМА ДОЛЖНА сохранить его и пометить контакт как неполный. - Показывает границы явно — что вошло в первую версию, что ушло в backlog, — чтобы вы согласились до того, как что-то написано.
- Только потом планирует и делает, сверяя каждый шаг с критерием готовности.
Результат:
Вместо «CRM вообще» — согласованная спека с ясными границами, по которой команда ролей делает предсказуемо то, что вы имели в виду. Один раунд уточнений вместо пяти раундов переделок.
Быстрый чек-лист перед отправкой задачи
- Сказал зачем, а не только «что»?
- Обозначил, чего делать не надо (границы)?
- Описал, как выглядит готово?
- Дал контекст (стек, где живёт, на что похоже)?
- Оставил движку право спросить на реальной развилке, а не гадать?
Честно
- Элицитация с вопросами-рекомендациями и спека в EARS — уже часть дизайна базового движка и едут в пакет как текст-рецепт.
- AI-сборка «опиши цель → готовый движок» (from-goal) — это про сборку самого движка под вашу цель, и она в разработке (roadmap), не путайте с постановкой задачи внутри уже установленного движка (это работает).
- Движок — инструкция, не гарант. Хорошая постановка резко повышает шанс «понял с первого раза», но итоговое качество всё ещё зависит и от целевой модели; движок минимизирует эту зависимость буквальностью рецепта, но не устраняет её полностью.