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

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

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

Разделите постоянные правила и сведения конкретной задачи

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

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

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

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

Покажите рабочую версию и источник каждого решения

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

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

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

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

Проверьте, как выбранный агент загружает инструкции

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

Например, официальное руководство OpenAI по AGENTS.md описывает последовательность глобальных и проектных инструкций, а также более близкие к рабочему каталогу переопределения. Там же указано ограничение совокупного размера загружаемых файлов. Эти правила относятся к конкретному продукту; переносить их без проверки на другой клиент нельзя.

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

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

Оставьте в начале необходимое, подробности сделайте доступными

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

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

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

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

Дайте задаче наблюдаемый результат

Поручение «улучши карточки» допускает слишком много разных ответов. Уточните, что должен увидеть и сделать пользователь. Например: заголовок остаётся читаемым на узком экране; дата и время чтения стоят в одной строке, пока хватает места; нажатие открывает прежний адрес статьи; карточка с длинным названием не перекрывает соседнюю.

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

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

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

Инструкции, примеры и доступы выполняют разные роли

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

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

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

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

Проверьте передачу на небольшой законченной работе

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

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

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

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