Вы поручаете задачу — неважно, нейросети в чате или живому коллеге, — и получаете не то. Не совсем не то, но мимо. Вы возвращаетесь к формулировке, дописываете «пожалуйста, сделай всё внимательно и аккуратно», добавляете «это ВАЖНО», ставите восклицательный знак. И ловите себя на мысли: «Я же всё понятно и чётко расписал».
Чаще всего — нет, не чётко и не совсем понятно. И это не упрёк: ставить задачи действительно трудно, этому почти нигде не учат специально. Мы осваиваем делегирование на ходу, по обрывкам опыта, и редко получаем честную обратную связь о том, насколько хорошо у нас это выходит.
Но есть профессия, где постановка задачи — не побочный навык, а основное ремесло, отточенное до приёмов. Это промпт‑инженеры — люди, которые профессионально настраивают работу больших языковых моделей и каждый день формулируют для них задачи. Они делают это сотнями и быстро поняли, что качество ответа почти целиком зависит от качества запроса. За последние пару лет у них накопился набор рабочих принципов — и почти каждый из них, как оказалось, переносится на делегирование живым людям. И на постановку задач самому себе.
Расскажу про пять таких принципов. Каждый — сначала на примере из работы с ИИ, потом на том, как он живёт за пределами экрана.
Почему учиться стоит именно у них
Сначала — почему вообще промпт‑инженеры оказались хорошими учителями делегирования. Дело в обратной связи.
Когда вы поручаете что‑то человеку, качество вашей постановки замылено. Хороший коллега додумает недосказанное, переспросит непонятное, молча исправит вашу небрежность — и сам факт, что задача была поставлена плохо, до вас просто не дойдёт. Результат получился приличный, значит, и поручение было нормальным. Так нам кажется.
Нейросеть устроена иначе. Она не додумывает из вежливости и не сглаживает углы, чтобы вас не расстроить. Расплывчатая постановка мгновенно даёт расплывчатый результат — прямо, без амортизации. Это неприятно, но полезно: получается тренажёр делегирования с предельно честной обратной связью. Человек, который год ставит задачи ИИ, проходит через тысячи таких мини‑уроков. Дисциплина формулировки у него вырабатывается быстрее и жёстче, чем у среднего руководителя, — не потому что он умнее, а потому что зеркало честнее.
Вот пять уроков из такого зеркала.
Урок 1. «Постарайся получше» — это не задача
Показательный случай. Промпт‑инженеры настраивали бота поддержки для телеком‑компании. Среди задач была простая на вид: клиент спрашивает, каким будет счёт, если он сменит тариф в середине месяца. Нужно посчитать сумму с учётом неполного месяца.
В инструкции для бота было написано всё «правильно»: считай корректно, не давай клиенту расплывчатых ответов, числа должны быть точными. А бот всё равно мямлил — рассуждал вслух, прикидывал «на глаз» и не выдавал надёжной цифры.
Причина оказалась простой. Инструкция не добавляет способности. Сколько ни пиши «считай правильно», это не делает модель сильнее в арифметике — ровно как требование «будь внимательнее» не улучшает зрение. Помогло другое: боту дали инструмент — калькулятор, отдельную функцию, которая делает расчёт точно. Не приказ хорошо считать, а возможность хорошо считать.
За пределами ИИ всё то же самое. «Сделай качественно» — это не задача, а пожелание. Если вы поручаете джуну макет и говорите «сделай хорошо», но не показываете эталон, не даёте доступ к нужной библиотеке компонентов и готовых решений, не объясняете, что здесь считается «хорошо», — вы требуете результата, не обеспечив возможности его достичь.
Я это особенно ясно видел, когда менторил команду дизайнеров. Разница между «сделай нормальную форму» и реальной помощью — это разница между требованием и оснащением. Во втором случае вы даёте доступ к дизайн‑системе и уже собранные на ней блоки, показываете образец похожей формы, проговариваете критерии. Делегирование — это не только передача требования. Это передача ещё и возможностей.
Урок 2. Исполнитель оптимизирует ровно то, что вы сказали
Второй случай с тем же ботом, и он, на мой взгляд, самый поучительный.
Иногда бот не должен решать проблему сам — например, при ошибке в счёте её положено передать живому специалисту. В инструкции это попытались учесть и написали примерно так: «Передавать обращение специалисту дорого — каждая передача стоит около восьми долларов и портит наш показатель скорости решения. Избегай этого без крайней необходимости».
Что сделал бот? Перестал передавать обращения вообще. Даже там, где передать было совершенно необходимо. И с его точки зрения он был абсолютно прав: ему назвали ровно один критерий — стоимость передачи, — и он добросовестно его оптимизировал.
Чинилось это так: боту назвали обе стороны. Да, передача стоит восемь долларов. Но если не передать обращение, которое требовало человека, компания потеряет куда больше — придётся возвращать деньги, и пострадает доверие клиента. Получив полную картину, бот начал принимать разумные решения.
Теперь уберите слово «бот». Этот механизм работает с кем угодно — с сотрудником, с подрядчиком, с вами самими. Любой исполнитель оптимизирует тот критерий, который вы озвучили. Скажете команде «закрывайте задачи быстрее» — получите скорость, принесённую в жертву качеству. И формально люди будут правы: вы просили быстрее, они сделали быстрее. Это не саботаж и не глупость — это буквальное, честное исполнение озвученной цели.
Вывод неудобный, но простой. Делегируя, называйте компромисс целиком, а не одну его сторону. Не «дешевле», а «дешевле, но не в ущерб вот этому». Не «быстрее», а «быстрее, при этом качество не ниже вот такого». Если вы назвали только одну величину, не удивляйтесь, что в неё всё и упёрлось.
То же — с целями, которые вы ставите себе. Однобокая метрика перекашивает жизнь не хуже, чем работу бота. «Больше зарабатывать» без второй половины фразы легко оптимизируется в ущерб здоровью или отношениям — и формально вы тоже будете правы перед самим собой.
Урок 3. Если непонятно вам — непонятно и исполнителю
Третий принцип — про структуру.
Инженеры часто наследуют промпты, которые писались месяцами и несколькими людьми. Типичная картина: один сплошной кусок текста, где вперемешку лежат роль исполнителя, жёсткие правила, пожелания по тону, справочные данные и заплатки, прилепленные когда‑то на ходу. Всё свалено в кучу.
Если, читая инструкцию, вы сами не можете отличить, где здесь нерушимое правило, а где справочная информация, — то и модель этого не различит. Решение очевидное: разделить. Отдельно — роль, отдельно — жёсткие правила, отдельно — пожелания, отдельно — данные.
И снова: это вообще не про ИИ. Вспомните типичное описание задачи которое вам скинули — где в один поток намешаны контекст («у нас тут клиент попросил»), само задание, обязательное требование («только обязательно через нашу библиотеку») и необязательное пожелание («ну и хорошо бы покрасивее»). Исполнитель физически не может отделить то, что нельзя нарушать, от того, что отдано на его усмотрение. Он либо переспросит, либо — что вероятнее — истолкует по‑своему, как ему понятнее, и нередко истолкует не так.
Ясность для исполнителя начинается с ясности в вашей голове. Если вы сами не разложили задачу на «обязательное / желательное / контекст / справка», то и собеседник не разложит. Мне как дизайнеру, эта мысль близка: хорошее техническое задание устроено как хороший интерфейс — оно само показывает, что здесь главное, а что второстепенное, и не заставляет продираться через него.
Урок 4. Большую задачу не поручают целиком
Четвёртый случай — про другого агента. Его задача была собрать рабочее расписание смен для магазина: несколько сотрудников, ограничения по доступности, обязательные условия по составу каждой смены.
Сначала инженеры попробовали поручить это одним большим запросом — «вот все условия, выдай готовое расписание». Не получилось: модель путалась, нарушала правила, не проверяла себя. Сработал другой подход — задачу разбили на три простые роли, работающие по очереди. Первая делает черновик расписания. Вторая проверяет черновик и выписывает конкретные нарушения. Третья получает список нарушений и чинит их. Три маленькие понятные задачи вместо одной огромной — и результат стал надёжным.
С людьми ровно так же. Поручение «Спроектируй раздел клиентов в CRM‑системе» одним куском почти обречено: оно слишком большое, чтобы исполнитель удержал его целиком и не растерял половину. Декомпозиция — разбить на этапы с понятным «готово» у каждого — это не бюрократия, а уважение к тому, как вообще работает внимание.
И обратите внимание на отдельную роль проверяющего во втором шаге. Отдельный шаг проверки — это не признак недоверия к исполнителю. Это нормальная часть процесса, заложенная в него заранее. Кстати, и большие личные цели поддаются той же логике: не один героический рывок, а черновик, ревизия, доработка.
Урок 5. Доверяй, но имей критерий
И последнее — про то, как вообще понять, что задача сделана.
У промпт‑инженеров для этого есть приём, который называется evals — по сути, набор контрольных примеров. Для каждого заранее записан однострочный критерий: вот такой вопрос, вот такой правильный ответ, прошло или не прошло. Когда инженер меняет инструкцию для модели, он прогоняет её по этому набору и видит чётко: стало лучше или хуже. Без такого набора любое «улучшение» — это самообман в стиле «ну вроде получше отвечает».
Перенесём. Делегируя задачу, договоритесь с исполнителем заранее — как вы оба поймёте, что она сделана. Не «покажешь, когда закончишь, там посмотрю», а понятный критерий результата, проговорённый на старте.
Это, к слову, выгодно обеим сторонам. С исполнителя снимается тревога — он не гадает, угодил ли он вам, у него есть ясный чек‑лист выполнения. А с вас снимается соблазн микроменеджмента: если критерий есть, не нужно стоять над душой, достаточно сверить результат с ним.
Тем, кто, как и я, увлекается измерением собственной жизни — сном, активностью, привычками, — эта мысль знакома в другой форме. Измеримый критерий честнее ощущения. «Кажется, я стал больше двигаться» и «я прошёл на две тысячи шагов в день больше, чем месяц назад» — это очень разные по надёжности утверждения. То же и с делегированной задачей.
Что в итоге
В программировании есть старое правило: «мусор на входе — мусор на выходе». Каким бы мощным ни был алгоритм, на плохих входных данных он выдаст плохой результат. Так вот, это правило давно переросло код. Оно работает с любым исполнителем — с нейросетью, с сотрудником, с вами самими. Небрежная постановка задачи и есть тот самый мусор на входе.
Пять уроков — про инструмент вместо приказа, про обе стороны компромисса, про структуру, про декомпозицию, про критерий — на самом деле складываются в одну мысль.
Качество результата задаётся качеством постановки задачи. И ответственность за это качество лежит на том, кто ставит задачу, а не на том, кто её исполняет. У промпт‑инженеров это видно особенно отчётливо — просто потому, что нейросеть, в отличие от вежливого коллеги, возвращает им их собственную небрежность без смягчения и сразу.
Но сами приёмы — не про ИИ. Они про делегирование как таковое: кому бы вы ни поручали задачу — модели, сотруднику, подрядчику или даже себе на следующей неделе. Инженеры, работающие с ИИ, просто оказались в условиях, где этому пришлось научиться быстрее всех.
Поэтому предложение простое. На следующей задаче, которую будете кому‑то поручать, попробуйте поймать себя — на каком из пяти уроков вы спотыкаетесь. Скорее всего, на одном конкретном споткнётесь регулярно. С него и стоит начать.
Материалы и примеры про ИИ взяты из презентации: The Prompting Playbook, speaker: Margot van Laar
Частично перекликается с моей статьёй Промпт‑инжиниринг для не‑промпт‑инженеров
Пишу про практики работы с AI в Telegram‑канале «Я и мой друг робот» — про мульти‑агентные системы, визуализацию данных и реальные автоматизации: https://t.me/mewithrobot