Промпт и контекст за один вечер: практический вход для программиста

21 сентября 2026 · 8 минут чтения

Читать про промпт-инжиниринг бесполезно: приёмы выглядят очевидными, пока не увидишь, как твоя собственная задача разваливается на третьем прогоне. Этот материал устроен иначе — как вечер работы. Вы берёте одну реальную задачу из своего проекта и проводите её через шесть шагов. К концу у вас будет не список знаний, а работающий цикл и понимание, где он ломается.

Каждый шаг устроен одинаково: что делать, как понять, что получилось, и какая ошибка здесь типична. Порядок шагов — авторская рабочая схема, а не отраслевой стандарт; примеры осечек внутри условны и собирательны. Парный разбор «Что идёт не так: 17 типовых сбоев промпта и контекста» разбирает те же сбои подробнее.

Что нужно на входе

• Один репозиторий, с которым вы работаете каждый день.
• Агент или чат с моделью, к которым у вас уже есть доступ.
• Одна повторяющаяся задача среднего размера: генерация спецификации по тикету, ревью изменения, разбор падающего теста, описание миграции. Не «переписать сервис» и не «поправить опечатку».
• Полтора–два часа без переключений.
• Две заготовки в конце этой статьи: промпт — к шагу 2, разбор входа — к шагу 4. Весь набор материалов — раздел.

Актуальность. Ссылки в конце проверены 21 сентября 2026 года. Вендорная документация меняется вместе с моделями, метод — медленнее.

Шаг 1. Сформулируйте критерии приёмки до промпта

Возьмите выбранную задачу и, не открывая агента, выпишите три–пять признаков, по которым вы примете результат. Не «хорошая спецификация», а «описано поведение при дубликате ключа, при неверной кодировке и при сбое на середине файла; каждый пункт можно превратить в тест».

Anthropic ставит наличие критериев успеха условием входа в промпт-инжиниринг — не из любви к методологии, а потому что без них нельзя отличить удачную правку промпта от неудачной.

Результат шага: список признаков на экране, до первого запроса.

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

Шаг 2. Напишите промпт и запустите его трижды

Соберите промпт из четырёх частей: задача, материал (файлы, тикет, логи), ограничения, формат результата. Готовая разметка — в части 3 заготовки промпта. Разделите части заголовками или тегами, чтобы модель не приняла ваши данные за инструкции. Критичные ограничения поставьте в конец, а не в середину: факт из середины длинного входа используется хуже, чем тот же факт в начале или в конце.

Запустите один и тот же промпт три раза в чистых сессиях.

Результат шага: три ответа и понимание, насколько они расходятся. Разброс между ними — прямая мера недоопределённости вашей формулировки, а не «температуры модели».

Типичная ошибка: один запуск и вывод о качестве промпта по нему.

Шаг 3. Найдите один воспроизводимый сбой и почините его

Выберите из трёх прогонов самый показательный провал и определите его тип. Чаще всего это одно из трёх.

Задача недоопределена. Модель выбрала критерии сама. Лечится переносом пунктов из шага 1 в текст промпта.

Инструкции конфликтуют. В AGENTS.md — файле правил проекта — написано «не менять публичные интерфейсы», в промпте — «рефактори как считаешь нужным»; половина прогонов ломает потребителей. Лечится не усилением формулировки, а решением, какое полномочие сильнее, и явной записью этого.

Не хватает основания. Ответ про авторизацию звучит убедительно и описывает JWT, хотя у вас подписанные заголовки от шлюза. Лечится не запретом галлюцинировать, а подачей нужного файла и разрешением сказать «в материале этого нет».

Исправьте одно. Прогоните снова три раза.

Результат шага: сбой, который вы умеете воспроизвести и снять целенаправленной правкой.

Типичная ошибка: правка сразу пяти вещей — потом невозможно сказать, что помогло.

Шаг 4. Посмотрите, что на самом деле попало в контекст

Теперь то, чего обычно не делают. На одном шаге агента выпишите всё, что фактически оказалось во входе модели: системная инструкция, файл правил проекта, описания инструментов, найденные файлы, вывод команд, история. Рядом с каждым пунктом поставьте «нужно» или «мешает». Таблица для этого — в части 4 разбора входа.

Дальше уберите мешающее:

• Лишние файлы. Три реализации скидок в контексте — актуальная, old/ и черновик из ветки — и агент чинит legacy, потому что она текстуально ближе к формулировке задачи.
• Многословный вывод инструментов. 6000 строк трассировок от полного прогона тестов ради двух строк с именем упавшего теста.
• Пересекающиеся инструменты. search_files, grep_repo и code_search с одинаковыми описаниями заставляют модель выбирать наугад.

Результат шага: тот же прогон с заметно меньшим и чище отобранным входом. Доля выброшенного — ваш запас улучшения.

Типичная ошибка: добавлять контекст «на всякий случай». Похожий, но нерелевантный материал вредит сильнее, чем его отсутствие: так показывает исследование Chroma про деградацию на длинном входе.

Шаг 5. Вынесите устойчивое из диалога наружу

Всё, что вы объясняете агенту второй раз, должно жить не в диалоге. Разложите по двум местам:

• Правила проекта — в файл правил рядом с кодом: как запускаются тесты, что нельзя менять без обсуждения, какие директории являются legacy. О том, где проходит его граница, — «Почему AGENTS.md недостаточно».
• Решения и их причины — в файл решений: «библиотеку X не используем из-за лицензии, выбрали Y». Иначе завтра в новой сессии агент снова предложит X.

Anthropic описывает это как структурированные заметки — внешнюю память агента, которая переживает закрытие сессии и возвращается в контекст выборочно. Развёрнутая форма этой практики — Memory Bank.

Результат шага: новая сессия стартует без пересказа вчерашнего.

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

Шаг 6. Проверьте поведение на длинной задаче

Последний шаг — там, где ломаются даже аккуратно настроенные циклы. Дайте агенту задачу на час–полтора и понаблюдайте за тремя вещами.

Компактизация. Когда история перестанет помещаться в окно, она будет сжата. Проверьте, пережили ли сжатие договорённости: обратная совместимость API, запрет на миграции, согласованный формат. Классическая осечка — агент удаляет старые эндпоинты как «мёртвый код», потому что в сжатом изложении осталось «мигрируем на новую схему», а условие «старые живут ещё релиз» — нет.

Загрязнение ошибкой. Если на третьем шаге агент решил, что тесты запускаются через make test, а у вас bin/rspec, он будет двадцать минут чинить Makefile. Ошибка стала частью контекста, и следующие шаги строятся поверх неё.

Обратная связь. Проверьте, что в цикле есть сигнал не от модели: прогон тестов, линтер, проверка типов. Без него «готово» означает только то, что модель так считает.

У длинной задачи есть и третий выход, кроме ручного перезапуска сессии: замкнуть цикл. Один и тот же промпт запускается на чистом контексте, а прогресс живёт во внешнем файле состояния, который агент дописывает, — это снимает загрязнение ошибкой ценой необходимости заранее задать признак успеха, признак провала и предел числа попыток. Схему разбирает приём «обнуление контекста с сохранением состояния».

Результат шага: у вас есть правило остановки — момент, когда вы начинаете новую сессию с явным переносом решений, вместо того чтобы уговаривать агента в двадцатый раз, — и понимание, какой объективный сигнал закрывает задачу.

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

Заготовка промпта

Разметка условна: важно, что части разделены и модель не принимает ваши данные за инструкции. Разделители подбирайте под своего вендора — рекомендации по разметке у моделей различаются. Заполненный шаблон держите в репозитории и правьте как код: через ревью и историю изменений.

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

Разбор того, что попало во вход

Разбор одного шага агента — проблемного, а не удачного.

Задача:

Шаг (номер и что агент делал):

Доля «мешает» от общего объёма:

Что делать с найденным:

Результат до чистки:

Результат после:

Как понять, что вечер удался

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

Полный список приёмов, выходящий за рамки одного вечера, — в «Приёмах», разбор сбоев по симптомам — в «Что идёт не так».

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

Границы применимости

Это вход, а не методика внедрения. За пределами остались оценка качества (evals) на наборе задач, мультиагентные схемы, выбор модели под задачу и безопасность агентов с широкими полномочиями. Описанный цикл проверен на задачах среднего размера в одном репозитории; для многокомандных процессов и критичных контуров его недостаточно.

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

Источники

Вендорная документация, инженерные тексты и работы, на которые они ссылаются, собраны в отдельном материале раздела: «Источники». Там же дата последней проверки ссылок.

Термины

Повторяющиеся слова раздела — промпт-инжиниринг, контекст-инжиниринг, токен, окно контекста, компактизация и другие — собраны в отдельном материале: «Термины раздела».

Автор: Данил Письменный · Дата: 21 сентября 2026