Контекстный пакет для AI-редактора: как передать факты, голос и запреты без выдуманных claims

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

Сначала собери редакционную задачу

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

Для одной задачи достаточно четырёх строк:

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

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

Базовую структуру из роли, аудитории, контекста, формата и ограничений можно настроить по гайду «Prompt engineering для контента». Здесь мы добавим слой, который нужен для production-задачи: происхождение каждого claim, явные пробелы в данных, stop-rule и человеческую приёмку.

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

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

В этом рабочем шаблоне пакет состоит из семи секций. Это редакционная схема статьи, а не стандарт OpenAI или Anthropic.

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

1. Задача и артефакт

Напиши, что модель должна подготовить. Не «помоги с контентом», а «собери черновик письма для текущих клиентов на 3500–4500 знаков с одним выводом и без коммерческого предложения».

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

2. Аудитория и ситуация

Дай только подтверждённые сведения о читателе. Сегмент, стадия осознанности, текущая задача, знакомые термины, типичное возражение. Не проси модель «самой определить ЦА», если аудитория уже влияет на тезис, примеры и лексику.

Хорошая секция отвечает на три вопроса:

Кто читает?
Что происходит у него сейчас?
Что он уже знает о теме?

3. Текущий продуктовый контракт

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

Конфликт версий считается отдельным блокером. Сначала человек выбирает текущий контракт, потом AI-редактор пишет текст.

4. Claims и их происхождение

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

Для каждого claim сохрани четыре поля:

Claim	Канонический URL	Опорный фрагмент	Допустимая формулировка
[Одно проверяемое утверждение]	[Ссылка на первоисточник]	[Точная цитата или абзац]	[Фраза не шире источника]

Этот provenance ledger служит рабочим шаблоном. Официальные рекомендации не предписывают именно такую таблицу. Они подтверждают более узкий принцип: фактическую работу стоит привязывать к цитатам и проверять claims по источникам. Anthropic описывает такой подход в материале Reduce hallucinations.

5. Примеры голоса и антипримеры

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

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

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

6. Формат результата

Задай носитель, объём, структуру и обязательные блоки. Если нужен Markdown, таблица claims или отдельный список вопросов, напиши это прямо.

OpenAI советует отделять части промпта заголовками, списками или XML. Anthropic отдельно рекомендует XML-теги для сложных пакетов, где смешаны инструкции, контекст, примеры и переменные входы. Теги не гарантируют точность. Они помогают модели не спутать данные с инструкцией.

7. Ограничения и stop-rule

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

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

Как собрать provenance ledger

Ссылка сама по себе не подтверждает claim. Нужно проверить, что конкретный фрагмент источника поддерживает именно ту формулировку, которая попадёт в материал.

В этой схеме работа идёт так:

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

Ссылка подтверждает claim только вместе с опорным фрагментом и формулировкой не шире источника.

Условный пример:

Источник говорит: «Экспорт доступен в PDF». Допустимая формулировка: «Сервис поддерживает экспорт в PDF». Фраза «сервис экспортирует документы в любые форматы» уже шире источника и должна быть удалена либо отправлена на дополнительную проверку.

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

Более широкий процесс с брифом, фактами, примерами стиля и ручной проверкой текста разобран в статье «Как ИИ помогает вести блог».

Stop-rule: когда модель должна остановиться

Anthropic рекомендует прямо разрешать модели признавать неопределённость и отвечать «не знаю». Это может снизить риск выдуманных фактов, но не устраняет его и не заменяет фактчекинг человеком.

Для этого workflow критическими считаются четыре пробела:

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

Конфликт версий продуктового контракта тоже блокирует черновик.

При критическом пробеле модель возвращает статус «недостаточно», список отсутствующих входов и конкретные вопросы. Черновика в ответе быть не должно. Некритичные пробелы можно вынести в риски, но нельзя незаметно превращать их в факты.

Как собрать пакет за один проход

Открой один документ и двигайся сверху вниз.

Зафиксируй артефакт, читателя, его ситуацию и критерий приёмки.
Вставь текущий продуктовый контракт. Если есть две версии, остановись и выбери одну.
Собери claims ledger. На каждое публичное утверждение нужны URL, опорный фрагмент и допустимая формулировка.
Выбери примеры голоса из того же канала и жанра. Рядом положи антипримеры с объяснением ошибок.
Опиши формат: объём, заголовки, таблицы, обязательные блоки.
Добавь запреты и stop-rule.
Передай пакет модели через промпт ниже.

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

Готовый промпт для AI-редактора

Скопируй шаблон и замени поля в квадратных скобках. Не удаляй stop-rule и блок человеческой проверки.

<role>
Ты AI-редактор. Структурируй только предоставленные материалы. Формулируй роль, задачу и ограничения прямо. Не заполняй пробелы догадками.
</role>

<inputs_context>
1. Задача и артефакт:
[ЧТО ИМЕННО НУЖНО ПОДГОТОВИТЬ]

2. Аудитория и ситуация:
[ТОЛЬКО ПОДТВЕРЖДЁННЫЕ ДАННЫЕ О ЧИТАТЕЛЕ, ЕГО ЗАДАЧЕ И СТАДИИ ОСОЗНАННОСТИ]

3. Тезис и результат для читателя:
[ЧТО ЧИТАТЕЛЬ ДОЛЖЕН ПОНЯТЬ, ВЫБРАТЬ ИЛИ СДЕЛАТЬ]

4. Продукт или оффер:
[УТВЕРЖДЁННЫЙ КОНТРАКТ, ВЕРСИЯ ИЛИ ДАТА ПРОВЕРКИ; НЕ МЕНЯТЬ]

5. Источники и claims:
[ДЛЯ КАЖДОГО CLAIM: ФОРМУЛИРОВКА | КАНОНИЧЕСКИЙ URL | ОПОРНЫЙ ФРАГМЕНТ | ДОПУСТИМАЯ ФОРМУЛИРОВКА | СТАТУС]

6. Примеры голоса:
[ОТ 3 ДО 10 РЕЛЕВАНТНЫХ ПРИМЕРОВ ИЗ ТОГО ЖЕ КАНАЛА И ЖАНРА]

7. Как не писать:
[АНТИПРИМЕРЫ, ЗАПРЕЩЁННЫЕ ФРАЗЫ, ЧУЖИЕ ПОЗИЦИИ, НЕЖЕЛАТЕЛЬНЫЕ ПАТТЕРНЫ]

8. Канал, объём и формат:
[НОСИТЕЛЬ, ДЛИНА, СТРУКТУРА, ОБЯЗАТЕЛЬНЫЕ БЛОКИ]
</inputs_context>

<task>
Подготовь структурный черновик только из входов выше. Не расширяй продуктовый контракт. Не превращай редакционные рекомендации в факты. Используй публичный claim только в пределах допустимой формулировки из таблицы.
</task>

<stop_rule>
Считай критическим пробелом отсутствие аудитории и ситуации, тезиса, доказательства для публичного claim или правила голоса. Конфликт версий продуктового контракта тоже критичен.

Если найден хотя бы один критический пробел:
1. Поставь статус «недостаточно».
2. Перечисли отсутствующие или конфликтующие входы.
3. Задай по одному конкретному вопросу на каждый пробел.
4. Не пиши черновик и не предлагай собственные факты.
</stop_rule>

<output_format>
Верни ответ в таком порядке:
1. Статус входов: «достаточно» или «недостаточно».
2. Отсутствующие входы, конфликты и вопросы.
3. Черновик. Показывай его только при статусе «достаточно».
4. Таблица: claim | источник | опорный фрагмент | использованная формулировка.
5. Data gaps, риски и места для проверки человеком.
</output_format>

<constraints>
Не придумывай аудиторию, стратегию, цифры, кейсы, claims, цитаты, цены, результаты и личный опыт автора.
Не подменяй первоисточник пересказом.
Не используй claim без URL и опорного фрагмента.
Не меняй продуктовый контракт.
Не скрывай data gaps внутри гладкой формулировки.
Не публикуй и не помечай материал как утверждённый.
</constraints>

<human_verification>
После ответа человек открывает каждый URL и сверяет claim с опорным фрагментом. Затем он проверяет задачу, примеры голоса, формат и запреты. Только человек утверждает черновик или возвращает его на правку.
</human_verification>

Как принять результат claim by claim

Заранее заданные критерии и человеческие контрольные точки помогают проверять результат до следующего шага. Такой принцип описан в материале Anthropic Building Effective AI Agents. Он не требует отдельной модели-оценщика для этой задачи. Достаточно понятной таблицы и внимательного редактора.

Проверяй ответ в таком порядке:

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

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

Мини-чеклист контекстного пакета

Перед отправкой модели проверь:

Один артефакт, один читатель и один результат зафиксированы.
Текущий продуктовый контракт выбран, конфликтующих версий нет.
У каждого публичного claim есть URL, опорный фрагмент и допустимая формулировка.
Примеры голоса относятся к нужному автору, каналу и жанру.
Антипримеры объясняют, какие формулировки нельзя повторять.
Формат результата описан до генерации.
Stop-rule запрещает черновик при критическом пробеле.
Человек назначен на финальную проверку.

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

Частые вопросы

Чем контекстный пакет отличается от промпта?

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

Сколько примеров голоса нужно дать?

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

Что делать, если источник подтверждает только часть claim?

Сузь формулировку до подтверждённой части. Если без второй части мысль теряет смысл, пометь data gap и не используй claim до дополнительной проверки.

Нужно ли загружать весь брендбук и всю базу знаний?

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

Кто отвечает за финальную проверку фактов?

Человек, который принимает материал. Модель может вернуть таблицу источников и указать риски, но ссылка в её ответе не заменяет открытие URL и сверку формулировки с опорным фрагментом.

Источники

Проверено 18 июля 2026 года.

OpenAI: Prompt engineering. Дата публикации на странице не указана.
Anthropic: Prompting best practices. Дата публикации на странице не указана.
Anthropic: Reduce hallucinations. Дата публикации на странице не указана.
Anthropic: Effective context engineering for AI agents. Опубликовано 29 сентября 2025 года.
Anthropic: Building Effective AI Agents. Опубликовано 19 декабря 2024 года.