Мы больше не пишем промпты, мы строим системы, которые промптят сами себя

На прошлой неделе в отрасли произошли две вещи одновременно.

С одной стороны, вирусным стало утверждение, что "промпт-инжиниринг мёртв". С другой, Anthropic опубликовала двадцатисемиминутный воркшоп о том, как писать промпты для Claude. Одна неделя, одна отрасль, два прямо противоположных сообщения.

Это противоречие на самом деле не противоречие. Оба утверждения верны, потому что говорят о разных слоях. Эта статья разделяет, что происходит на каком слое.

Быстрый ответ: Промпт-инжиниринг не исчезает, он меняет слой. Умерли приёмы: ролевые игры "ты эксперт", формула "думай шаг за шагом", строчки с чаевыми и угрозами, призванные манипулировать моделью. Всё это работало в 2023 году, потому что модели плохо следовали инструкциям. Не умерла сама работа: решать, что модель увидит. Разница в том, что это решение больше не принимается в окне чата, оно принимается в вашей кодовой базе. Системные инструкции, описания инструментов, какой документ и когда загружается, и что проверяет вывод модели. Сегодня сбой агента почти никогда не означает "плохой промпт". Он означает "неверный контекст".

Содержание

• Вирусное утверждение и цитата, которую никто не может подтвердить
• Приёмы, которые действительно умерли
• Растущий слой: инженерия контекста
• Как это делаем мы
• Что не умерло
• Где вы всё ещё пишете промпты вручную
• Словарь терминов
• Часто задаваемые вопросы
• Чек-лист

Вирусное Утверждение и Цитата, Которую Никто Не Может Подтвердить

Самая известная версия утверждения, ходящая по социальным сетям, - фраза, приписываемая Эндрю Ыну: "промптинг умрёт через шесть месяцев, его заменят циклы и графы".

Подтвердить эту цитату мы не смогли. Проследите фразу, и единственным источником окажется сам пост, который её выдвигает. То, что Ын написал на самом деле, отличается. По его собственным словам, агентные процессы обращаются к модели с промптом многократно; вместо того чтобы брать вывод модели напрямую, запускается несколько кругов, чтобы она шаг за шагом дошла до лучшего результата. Его задокументированная позиция - не "промптинг умирает", а "больше промптов, но внутри цикла".

Мы говорим это сразу, потому что в этой области расстояние между хайпом и данными велико. Прикрепить броскую цитату к настоящему видео с конференции стало форматом сбора вовлечённости. Не принимайте архитектурное решение на основе фразы, источник которой невозможно проследить.

Тем не менее под утверждением лежит реальное наблюдение. Просто доза преувеличена.

Приёмы, Которые Действительно Умерли

Многие техники, работавшие в 2023 году, сегодня либо бесполезны, либо вредны. Они действительно умерли, и если всё ещё лежат в ваших промптах, их стоит вычистить.

Общее у всех одно: каждый из этих приёмов существовал, чтобы компенсировать слабость модели. Как только слабость исчезла, компенсация стала лишней. Хуже того, часть теперь активно вредит. Крикните "НИКОГДА так не делай" модели, которая хорошо следует инструкциям, и она воспримет правило слишком буквально, отказываясь от того, что должна была сделать.

Растущий Слой: Инженерия Контекста

Именно сюда работа переместилась, а не исчезла. В отрасли за этим закрепляется название инженерия контекста (context engineering).

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

Поэтому, когда агент сегодня терпит неудачу, проблема почти никогда не в том, что "промпт написан плохо". Модель увидела не то, или не увидела то, что было нужно.

Системные инструкции

Определяют, кто такая модель, каким правилам следует и чего никогда не должна делать. Раньше это была вся работа. Теперь это отправная точка.

Описания инструментов

Когда вы даёте агенту инструмент, поле description этого инструмента - это промпт. Именно оно решает, когда модель вызовет инструмент.

Самая частая ошибка в корпоративных проектах - противоречащие друг другу описания инструментов. Если в одном написано "используй это для данных клиентов", а в другом "используй это для всех запросов данных", модель не может разрешить противоречие и выбирает наугад. Описания инструментов нужно рассматривать как контекст первого класса, а не как поле, которое заполняют потом.

Поэтапное раскрытие

Давать модели то, что нужно, в тот момент, когда это нужно, вместо загрузки всего сразу. Положите двадцать документов и пятьдесят инструментов в контекст одновременно, и вы и стоимость поднимете, и внимание модели рассеете. Правильный подход - доставать нужное в нужный момент.

Циклы и оценка

Вместо ожидания верного ответа с одного захода строится цикл, в котором модель может проверить и исправить собственный вывод. Запустить тест и вернуть ошибку, добавить шаг проверки, оценить результат по критерию. Именно это Ын и описывает: рефлексия, использование инструментов, планирование и взаимодействие нескольких агентов.

Как Это Делаем Мы

Этот раздел не теория. В наших собственных проектах промпты живут не в окне чата, а в репозитории.

В корне каждого проекта лежит файл правил, который автоматически загружается в каждую ИИ-сессию, работающую над этим проектом. В нём правила письма, шаблоны производительности, поведение при коммитах и указание, какой файл когда читать. Пример:

## Правила Git и коммитов

**Цель коммита (ОБЯЗАТЕЛЬНО):** когда сказано "закоммить",
коммить в текущую ветку. НЕ открывай новую ветку, не переключайся.
Если "закоммить" сказано на `main`, коммит идёт прямо в `main`.
Это осознанный выбор.

Это правило ПЕРЕОПРЕДЕЛЯЕТ поведение Claude Code по умолчанию
"сначала открой ветку, если это ветка по умолчанию".

Важна последняя строка: мы осознанно переопределяем поведение модели по умолчанию. Мы не перепечатываем это в окно чата каждую сессию. Мы написали это один раз, оно попало в систему контроля версий и действует в каждой сессии, работающей в этом репозитории. Когда правило меняется, открывается pull request и оно обсуждается.

В том же файле есть таблица, указывающая, какой документ читать для какой задачи, и прямо сказано: "эти файлы не загружаются автоматически, откройте их перед началом". Это поэтапное раскрытие в простейшем виде. Мы не раздуваем контекст заранее, а достаём по мере надобности.

Третий пример - описания инструментов. На нашем сайте работает MCP-сервер, и описание каждого открытого им инструмента определяет, когда модель его вызовет. В ответ сервера при подключении мы вписали такую фразу:

This server is read-only: it cannot submit contact or quote
requests. To start an inquiry, direct the user to the contact
or quote page returned by get_company_info.

Это промпт. Но живёт он не в разговоре, а внутри протокола и автоматически уходит каждому подключившемуся агенту. Мы сообщаем агенту ограничение на уровне протокола.

Общее у всех трёх: ни один не является разовым сообщением. Все они - версионируемая, переиспользуемая, проходящая ревью инфраструктура. Вот куда ушёл промпт-инжиниринг.

Что Не Умерло

Теперь обратная сторона медали. Вот что пропускают материалы про "промптинг мёртв".

Писать инструкции - это всё ещё писать. Системная инструкция - промпт, и описание инструмента тоже. Слой изменился, но навык тот же: сказать модели, чего вы хотите, не оставляя двусмысленности. Плохо написанное описание инструмента даёт ровно тот же результат, что и плохо написанный промпт.

Anthropic на той же неделе выпустила воркшоп по промптингу. Если создатели модели всё ещё учат писать промпты, фраза "промптинг мёртв" как минимум преждевременна.

С ростом моделей падает цена промпта, а не его ценность. На сильных моделях проще выправить плохую инструкцию. Но отдача от хорошей инструкции не исчезла. Наоборот, когда агент делает много шагов, неопределённость в начале умножается на каждом шаге.

Смерть части приёмов - не смерть всех. Назначение роли умерло, а описание формата вывода нет. "Думай шаг за шагом" умерло, а разбиение задачи на части нет.

Где Вы Всё Ещё Пишете Промпты Вручную

Разговор о построении систем не означает, что всё станет автоматическим. Вы всё ещё садитесь и пишете промпт в таких случаях:

• Исследование и прототипирование. Чтобы понять, работает ли идея, систему не строят. Её пробуют.
• Разовые задачи. Перевести текст или привести список в порядок инфраструктуры не требует.
• Написание самой системной инструкции. То, что строит систему, тоже текст, и кто-то должен его написать.
• Отладка. Когда агент ведёт себя неверно, отделить проблему контекста от проблемы инструкции можно только пробуя вручную.

То есть фраза "мы больше не пишем промпты" буквально не верна. Точная версия: мы переходим от написания разовых промптов к написанию промпт-систем, которые работают снова и снова.

Словарь Терминов

• Промпт-инжиниринг: проектирование входного текста ради нужного вывода модели.
• Инженерия контекста: проектирование всего, что видит модель: инструкции, документы, определения инструментов, история и вывод инструментов.
• Системная инструкция: постоянная инструкция в начале, определяющая роль, правила и границы модели.
• Описание инструмента: текст, объясняющий модели, что делает инструмент и когда его вызывать. По сути промпт.
• Поэтапное раскрытие: доставать информацию по мере надобности вместо загрузки всего сразу.
• Цикл агента: схема работы, где модель выдаёт результат, оценивает его и повторяет с исправлениями.
• Рефлексия: шаблон, в котором модель критикует и правит собственный вывод.
• Оценка (eval): воспроизводимый тест, измеряющий, помогло ли изменение промпта или системы.
• Раздувание контекста: лишние документы и определения инструментов заполняют окно контекста и снижают качество.

Часто Задаваемые Вопросы

Стоит ли ещё учить промпт-инжиниринг? Да, но не как отдельную профессию. Навык внятно объяснить модели, чего вы хотите, - тот же навык, что и при написании системных инструкций и описаний инструментов. Изменилось то, где он применяется.

Исчезает ли должность промпт-инженера? Как отдельная должность - во многом да. Но работа не исчезает, она растворяется в разработке. Сегодня этим занимается обычно тот же человек, который строит систему.

Нужно ли чистить старые промпты? Да. Назначения роли, капслок и "думай шаг за шагом", написанные для старых моделей, на новых вызывают избыточное срабатывание и лишнюю длину. Уберите и измерьте.

Что значит система, которая промптит сама себя? Схема, где контекст собирается во время работы самой системой. Она решает, какой документ достать, какой инструмент вызвать и что спросить на следующем шаге. Вы пишете правила этих решений, а не отдельные сообщения.

Не слишком ли это тяжело для маленькой команды? Нет. В простейшем виде это текстовый файл. Положить файл правил в репозиторий и отнестись к описаниям инструментов серьёзно - два шага, окупающиеся при любом размере команды.

Чек-лист

• Уберите из промптов назначение роли, угрозы и обещания чаевых
• Снизьте капслок; сформулируйте правило один раз и с обоснованием
• Уберите "думай шаг за шагом" на думающих моделях
• Вынесите системные инструкции из чата в репозиторий
• Проверяйте файл правил как обычный код, через pull request
• Относитесь к описаниям инструментов как к контексту первого класса и устраните противоречия
• Не загружайте всё заранее, доставайте по надобности
• Измеряйте, прежде чем утверждать, что изменение помогло
• При сбоях агента сначала смотрите на контекст, а не на инструкцию
• Пересматривайте инструкции при смене версии модели

Заключение

"Промпт-инжиниринг мёртв" - преувеличенная версия верного наблюдения. Умерли приёмы, и хорошо, что умерли; большинство существовало, чтобы прикрыть слабости моделей.

Не умерла работа по решению того, что модель увидит. Эта работа выросла и переехала. Теперь она живёт в файле правил под контролем версий, в описании инструмента, в оценочном тесте, а не в окне чата. Текст, который вы пишете, по-прежнему текст, но он больше не отрабатывает один раз и исчезает. Он работает заново каждую сессию.

Практический совет прост: вычистите старые приёмы, перенесите инструкции в репозиторий, отнеситесь к описаниям инструментов серьёзно и не утверждайте, что изменение сработало, без измерения. Работы по архитектуре и интеграции ИИ мы ведём в рамках услуги ИИ-решения, а техническое руководство - в рамках CTO as a Service. О роли, которая делает эту работу в поле, читайте в статье Кто такой Forward Deployed Engineer, а о влиянии ИИ на обучение разработчиков - в статье Быть junior-разработчиком в эпоху ИИ.