Фаундер открывает чат с моделью, пишет пару строк, получает воду вместо результата и решает, что искусственный интеллект переоценён. Чаще дело в том, как сформулирован запрос. Промпт-инжиниринг — это навык управлять ответами модели через постановку задачи, контекст и формат. Обучение с нуля строится как маршрут: вы осваиваете приёмы по шагам и сразу обкатываете их на своих рабочих задачах.
Зачем фаундеру навык
Промпт-инжиниринг с нуля — это маршрут из нескольких ступеней: вы учитесь давать модели роль и контекст, показывать примеры нужного ответа, просить рассуждение перед выводом и задавать строгий формат результата. Полноценным инженером становиться лишнее. Фаундеру хватает понимать продукт, видеть, где модель промахивается, и переписывать запрос так, чтобы она попадала с первого раза. Тренируетесь сразу на своих задачах: разбор писем, черновики постов, выжимки из договоров, ответы клиентам.
Модель отвечает ровно на заданный вопрос, и держит в голове то, что вы подразумевали. Вся разница между бесполезным ответом и готовым результатом прячется в формулировке: добавили роль и условия — получили по делу, бросили одну строку — получили общие слова. Промпт-инжиниринг закрывает именно этот разрыв между намерением и запросом.
В работе с фаундерами я часто вижу одну и ту же историю. Человек уже хорошо понимает, что искусственный интеллект забирает на себя значительную часть рутинной работы, и при этом продолжает кидать модели короткие обрывки фраз, после чего жалуется на пустые ответы. Освоение навыка переворачивает картину: тот же инструмент с грамотным запросом начинает выдавать черновики, выжимки и разборы, которые остаётся только проверить.
Рабочие приёмы
Базовых приёмов немного, и они дают почти весь результат. Разберу четыре, которые я применяю каждый день и ставлю команде первыми.
- Роль и контекст. Вы говорите модели, кем она выступает и в каких условиях работает: «ты редактор делового письма, тон сдержанный, адресат — клиент банка». Чем точнее рамка, тем меньше воды.
- Примеры нужного ответа. Приём few-shot: вы показываете два-три образца «вот так правильно», и модель подхватывает формат, тон и структуру без долгих объяснений.
- Рассуждение перед ответом. Приём chain-of-thought: вы просите модель сначала разложить задачу по шагам, а уже потом выдать вывод. На разборах договоров и расчётах это заметно снижает число ошибок.
- Строгий формат вывода. Приём structured output: вы заранее задаёте структуру ответа — таблица, список полей, JSON. Так результат сразу ложится в вашу систему и избавляет вас от вычитки сплошного текста.
Фаундер пишет модели одну строку, получает общий ответ и делает вывод, что инструмент слабый. На деле слабым был запрос. Перед тем как ругать модель, добавьте роль, один-два примера и формат вывода — и тот же вопрос даст совсем другой результат. Качеством управляет ваша формулировка, и в ней вся работа.
Отдельно держите в голове контекстное окно — объём текста, который модель видит за один заход. Когда вы заваливаете её всем подряд, важное тонет, и ответ плывёт. Грамотный запрос подаёт только то, что нужно для задачи, и держит остальное за рамкой.
Маршрут с нуля
Освоение идёт ступенями. Каждая даёт законченный навык, и вы сразу применяете его к своей рабочей задаче, ещё до конца курса.
- Возьмите одну живую задачу. Выберите то, что делаете руками каждую неделю: ответы клиентам, разбор входящих писем, черновик поста. Эта задача станет вашим тренажёром на весь маршрут.
- Сформулируйте роль и условия. Напишите модели, кем она выступает и в каких рамках работает, и сравните ответ с тем, что выходило на голой строке. Разница видна сразу.
- Добавьте примеры. Покажите два-три образца нужного ответа и убедитесь, что модель подхватила тон и структуру. Так few-shot превращается из теории в привычку.
- Попросите рассуждение и формат. На задачах со счётом или логикой включите разбор по шагам, а вывод заприте в таблицу или список полей. Здесь сходятся chain-of-thought и structured output.
- Соберите свою библиотеку запросов. Удачные формулировки сохраняйте отдельным файлом и переиспользуйте. Через несколько недель у вас набирается личный набор готовых заготовок под повторяющиеся задачи.
Учебные задачки из курсов отвечают на вопрос «как это устроено вообще». Навык приходит на вашей реальной работе. Когда вы обкатываете приёмы на собственной рассылке или разборе договоров, результат сразу ваш и сразу окупается, тогда как тетрадь упражнений лежит мёртвым грузом.
Фаундер и команда
Когда навык выходит за пределы одного человека, встаёт вопрос разделения труда. Покажу, что осваивает сам фаундер и что разумно передать команде, чтобы запросы работали одинаково у всех.
| Уровень | Что осваивает | Где применяет |
|---|---|---|
| Фаундер | Роль и контекст, формат вывода, граница задачи для модели | Стратегические разборы, выжимки из договоров, личная переписка |
| Руководитель отдела | Сборка библиотеки запросов и общих правил для команды | Единые шаблоны под отдел: продажи, поддержка, маркетинг |
| Сотрудник | Применение готовых запросов и точечная правка под случай | Ежедневная рутина: ответы клиентам, черновики, отчёты |
Разделение держится на простом принципе. Фаундер задаёт планку и формат, руководитель превращает удачные находки в общие шаблоны, сотрудник работает по готовому и дорабатывает под конкретный случай. Так команда говорит с моделью одним языком и избавляется от привычки изобретать запрос заново на каждом столе.
Один человек с хорошими запросами ускоряет себя. Команда с общей библиотекой запросов ускоряет весь бизнес.
Расскажите, какую рутину ваша команда делает руками каждый день, и я покажу, как собрать под неё набор рабочих запросов.
Предел навыка
Промпт-инжиниринг закрывает огромный класс задач фаундера: разборы, выжимки, черновики, ответы, классификация входящих. Для устойчивых процессов с потоком данных к нему добавляют кэширование запросов и связки с вашими системами — здесь уже зовут инженера. Полноценным специалистом по моделям становиться лишнее. Вам хватает уверенно управлять ответами и понимать, где задача переросла ручной запрос и просит автоматизации.
Граница проходит там, где разовый запрос превращается в поток. Пока вы вручную разбираете десяток писем в день, хватает грамотной формулировки. Когда писем сотни и их надо обрабатывать без вашего участия, запрос становится частью системы: его кэшируют, подключают к почте и базе, обкладывают проверками. Это уже инженерная работа, и её честнее отдать тому, кто её делает.
- Вы перестаёте получать воду и доводите ответ модели до готового вида с первого-второго захода.
- Вы видите, где модель промахивается, и чините это одной точной правкой запроса вместо долгих попыток наугад.
- Вы передаёте команде готовые формулировки, поэтому качество ответов держится у всех ровно.
- Вы трезво понимаете, где ручной запрос упёрся в потолок и пора звать инженера под автоматизацию.
Рядом с обучением запросам встаёт вопрос базовых правил одного промпта: как устроить структуру, какие слова работают, чего избегать. Это отдельная тема, и я разобрал её в материале про то, как писать промпты для модели. Здесь же речь о маршруте — как пройти путь от первого неуклюжего запроса до уверенного навыка на своих задачах.