← Все статьи

Комплект «Промпт и контекст» · все материалы

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

Практикум · 21 сентября 2026 · 8 минут чтения · черновик

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструкции конфликтуют. В [AGENTS.md](https://aia-club.ru/glossary.html#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. Ошибка стала частью контекста, и следующие шаги строятся поверх неё.

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

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

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

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

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

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

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

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

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

Источники

Здесь же список того, что читать дальше. Проверено 21 сентября 2026 года. Материалов Anthropic здесь больше, чем материалов OpenAI и Google: Anthropic систематически публикует тексты о самом методе, тогда как документация OpenAI и Google сильна, но в основном модельно-специфична. Дисциплину удобнее учить по первым, ежедневную работу сверять по документации того вендора, чью модель вы используете.

Метод

Приёмы и вендорная документация

Термины

  • Промпт-инжиниринг — практика формулирования инструкции и данных для модели так, чтобы результат был проверяемым и воспроизводимым.
  • Контекст-инжиниринг — практика управления полным набором информации, попадающей во вход модели на конкретном вызове.
  • Токен — единица текста, которой оперирует модель; объём контекста измеряется в токенах.
  • Окно контекста — максимальный объём входа, который модель принимает за один вызов.
  • Деградация на длинном входе (context rot) — снижение качества ответов по мере роста объёма входных токенов внутри заявленного окна.
  • Компактизация — сжатие накопленной истории работы для продолжения в новом окне контекста.
  • Оценка качества (evals) — набор задач с известным ожидаемым результатом, на котором сравнивают версии промпта или контекстной схемы.