Контекстная инженерия для команд разработки с ИИ

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

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

Я отношусь к контексту как к управляемому ресурсу среды выполнения. У него есть владелец, бюджет, правила допуска, происхождение и срок действия. Такой подход меняет работу. Вместо вопроса «Как вместить в промпт больше?» команда выясняет, какие данные нужны для текущего решения и что следует удалить перед следующим.

Промпт-инженерия заканчивается там, где начинается контекстная

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

Разница проявляется на практике. Если агент редактирует не тот файл, более настойчивое повторение фразы «меняй только модуль выставления счетов» может ничего не дать. Агент мог найти два таких модуля, получить старое руководство по миграции и унаследовать план, который ведет к снятой с эксплуатации версии. Инструкция понятна. Доказательства ненадежны.

Полезная опись контекста называет каждый канал и его приоритет:

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

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

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

Контекстное окно показывает емкость, а не бюджет

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

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

Простой манифест делает договор проверяемым:

context_plan:
  objective: fix invoice rounding without changing tax rules
  budget_tokens: 48000
  reserve_for_response: 8000
  always_include:
    - repository_policy
    - task_acceptance_tests
  retrieve_on_demand:
    - invoice_domain_files
    - current_tax_schema
    - failing_test_output
  exclude:
    - generated_build_artifacts
    - archived_migrations
    - unrelated_chat_history
  stop_when:
    - evidence_conflicts
    - budget_remaining_below: 6000

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

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

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

Гигиена поиска начинается до запроса

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

Для каждого найденного элемента я задаю четыре вопроса о допуске:

1. Отвечает ли он на вопрос, который агент уже сформулировал?
2. Понимает ли агент, откуда пришел элемент и когда он в последний раз был верен?
3. Совпадает ли его область с обсуждаемым компонентом, версией, клиентом или средой?
4. Добавляет ли он данные, которых еще нет в более надежной форме?

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

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

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

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

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

Разделяйте контекст по сроку жизни и области

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

Начните с четырех уровней:

• Уровень политики хранит постоянные требования безопасности, закона и репозитория. Меняйте его осознанно и держите коротким.
• Уровень задачи хранит требуемый результат, приемочные тесты, ограничения и текущий план. Заменяйте его при изменении намерения.
• Уровень доказательств хранит найденные файлы, наблюдения инструментов и состояние среды. Добавляйте происхождение и удаляйте элемент, когда базовое состояние меняется.
• Черновой уровень хранит гипотезы, промежуточные расчеты, отвергнутые планы и временные заметки. Активно очищайте его при смене фазы.

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

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

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

Сводки относятся к уровню задачи только тогда, когда отделяют наблюдение от вывода. «Тесты проходят» становится наблюдением, если рядом указаны команда, среда, время и код завершения. «Изменение безопасно» остается выводом и должно быть так помечено. Если уверенная сводка смешивает эти утверждения, она создает ложную определенность.

За лишними токенами обычно скрывается ошибка в данных

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

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

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

Дисциплинированный запуск меняет порядок:

1. До поиска реализаций определите владельца по текущему графу зависимостей и метаданным пакетов.
2. Получите интерфейс, активную привязку и узкие инструкции пакета. Исключите пакеты, которых нет в активном графе.
3. Запустите самый маленький тест, который воспроизводит нужное поведение. Сохраните ошибки и краткую сводку успешных проверок.
4. После изменения снова запустите этот тест и ближайшую интеграционную границу. Расширяйте проверку, только если измененные зависимости этого требуют.
5. Сожмите запуск до решений, наблюдений с источниками, измененных файлов и открытых рисков. Отвергнутые результаты поиска удалите.

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

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

Оценивайте решения, счетчика токенов недостаточно

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

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

{"event":"context_admit","item_id":"src/billing/rounding.ts@8f31","source":"repository","authority":"runtime_code","scope":"billing","freshness":"commit:8f31","tokens":742,"reason":"implements selected interface"}
{"event":"context_evict","item_id":"docs/rounding-plan.md@19ac","reason":"superseded by runtime code"}
{"event":"decision","decision_id":"d17","evidence":["src/billing/rounding.ts@8f31"],"result":"edit_selected"}

Такая форма позволяет считать полезные отношения. Доля допуска показывает, какая часть найденных элементов прошла проверки гигиены. Доля использования показывает, сколько допущенных элементов повлияло на план, изменение, решение о проверке или передачу вопроса. Доля переноса показывает, какая часть контекста одной фазы перешла в следующую. Частота конфликтов считает запуски с противоречиями между авторитетными элементами. Частота переделок считает решения, отмененные после появления новых данных.

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

Следите за задержкой и деньгами рядом с показателями качества. Разделяйте найденные токены, допущенные токены, токены из кеша, созданные токены и токены, выброшенные при сжатии. Такая разбивка показывает, где нужно вмешательство. Более точное индексирование уменьшает шум поиска. Правила допуска уменьшают загруженный шум. Стабильные префиксы улучшают повторное использование кеша. Очистка по фазам сокращает перенос. Короткий финальный ответ не исправляет ни один из этих ранних дефектов.

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

Шаблоны проектирования для долгих задач

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

Карта, вопрос, получение

Дайте агенту компактную карту компонентов, владельцев, интерфейсов и доступных данных. Пусть он сформулирует конкретный вопрос, а затем получает узкие материалы, которые отвечают на него. Это лучше большого стартового пакета, потому что вопрос создает правило допуска.

Карта должна сообщать, где лежат данные, но не притворяться самими данными. Сводка пакета может сказать, что выставление счетов отвечает за округление и предоставляет калькулятор счета. Она не должна пересказывать каждое правило округления, иначе пересказ разойдется с программой. Получите само правило, когда задача до него дойдет.

Заменяйте, а не дописывайте

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

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

Пакеты передачи

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

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

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

Кешируйте стабильный контекст и удаляйте его по событиям

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

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

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

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

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

Не кешируйте сводки без идентификаторов доказательств. Сводка может пережить поддерживавшие ее файлы, а гладкий текст скрывает расхождение. Храните сводку как производное представление со ссылками на точные версии источников. При изменении одного источника создайте представление заново или удалите его. Если пересоздание стоит дороже получения узкого исходного материала, откажитесь от сводки.

Для чувствительного контекста нужны границы допуска

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

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

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

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

Права инструментов должны сужаться вместе с фазой. Для исследования может понадобиться чтение разрешенной области репозитория. Для редактирования нужна запись только в выбранные файлы. Для проверки нужны утвержденные команды и среда, а не все учетные данные развертывания. Это снижает ущерб, если устаревший контекст направит действие не туда.

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

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

Назначьте владельца контекста

Качество контекста требует владельца, правил проверки и тестов на сбои. Если промпты принадлежат одному человеку, поиск другому, инструменты агентов третьему, а расходы считает финансовый отдел, никто не видит весь путь входных данных. Назначьте одного технического владельца договора контекста, даже если отдельные части обслуживают разные команды.

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

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

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

Team & AI Audit полезен основателю, которому нужно увидеть такую карту всей системы разработки: работа занимает пять рабочих дней, стоит $5,000 и гарантирует не менее $50,000 выявленной годовой экономии, иначе проводится бесплатно. Результат все равно следует оценивать как инженерную работу: какие дефекты контекста найдены, как они влияют на выпуск и какие средства управления предотвратят повторение.

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