Как держать источник статьи так, чтобы Codex не писал из тумана
Когда статья рождается из чата, главный риск не в том, что модель «плохо пишет». Чаще проблема проще и неприятнее: у текста нет устойчивого источника. В одном сообщении была важная договорённость, в другом — уточнение по фактам, в третьем — запрет на лишние выводы, но в итоговый пакет это не попало. В результате Codex или другой агент начинает собирать статью из воздуха: формально всё выглядит связно, а по сути в тексте появляется догадка вместо основания.
Для ONFF это не абстрактная методическая проблема. Это вопрос производственной дисциплины. Если редакция, контент-завод или автоматизированный контур не умеют хранить исходник статьи в компактном и проверяемом виде, то потом невозможно понять, что именно было исходной правдой, где модель добавила связку «для плавности», а где уже редактор не заметил разрыв.
Практическое решение здесь не в том, чтобы «лучше формулировать просьбу». Решение в другом: перед запуском написания должен существовать источник статьи как отдельный артефакт — source packet. Это маленький, но строгий пакет данных, который отделяет рабочую реальность от текста, который потом увидит читатель.
Почему обычный чат не подходит как источник
Чат удобен для обсуждения. Но как носитель источника он слаб по нескольким причинам.
Во-первых, он живёт фрагментами. Решение может быть принято на 18-й реплике, а важное ограничение — на 42-й. Если потом кто-то откроет только середину ленты, он увидит не контекст, а обрывок.
Во-вторых, в чате смешиваются роли. Там одновременно обсуждают тему, тон, сроки, стоимость, визуалы, публикацию, иногда ещё и правки из соседнего проекта. Для человека это терпимо. Для агента — почти гарантированный источник фантазии.
В-третьих, чат плохо показывает происхождение решения. Кто именно утвердил формулировку? Какая версия промпта была активна? Какой модельный профиль писал черновик? Если это не вынесено в отдельную структуру, потом остаётся только реконструкция по памяти.
Поэтому в нормальном производственном процессе чат — это место для переговоров, а не финальный носитель истины. Истина должна быть пересобрана в компактный источник: что мы знаем, откуда знаем, что запрещено утверждать и что должно выйти на выходе.
Что такое source packet на практике
Source packet — это не бюрократическая папка и не «ещё один документ ради документа». Это рабочий пакет, который делает границу между «модель угадала» и «модель работала по основаниям».
Удобно держать его в шести блоках:
- Рабочая тема
О чём статья на самом деле. Не абстрактно «про ИИ», а конкретно: как держать источник статьи так, чтобы Codex не писал из тумана.
- Факты и источник данных
Что уже известно, откуда это взято, какие внутренние артефакты или наблюдения подтверждают задачу.
- Границы
Чего статья не должна утверждать. Например: не приписывать продукту несуществующие функции, не смешивать внутреннюю служебную информацию с публичным текстом, не выдавать догадку за факт.
- Производственные метаданные
Кто писал, каким модельным профилем, в какой итерации, с какой версией промпта, в каком чате или lane. Это не для читателя, а для контроля и сравнения.
- Контракт выхода
Что именно должно быть на выходе: черновик, структура, public body, визуальный пакет, карточка публикации, поля для проверки.
- План верификации
Что проверяем после выпуска: соответствие источнику, корректность карточки, наличие визуалов, статус переобхода поисковыми системами, попадание в социальные очереди.
Именно эта структура делает пакет полезным. Модель не должна угадывать, что считать важным. Ей надо дать рамку, внутри которой она пишет.
Ниже — компактное сравнение трёх сущностей, которые часто путают.
Как собрать пакет, чтобы модель не додумывала
| Артефакт | Зачем нужен | Что содержит | Чего не должен делать |
|---|---|---|---|
| Чат-инструкция | Быстро обсудить задачу | Разговор, уточнения, гипотезы | Быть единственным источником правды |
| Source packet | Зафиксировать рабочую основу | Тему, факты, границы, метаданные, контракт | Расплываться в свободный диалог |
| Publication card | Показать факт выпуска | Авторство, модель, визуалы, ID каналов, статус проверки | Подменять собой редакционный процесс |
Хороший source packet строится не вокруг вдохновения, а вокруг ограничений. Это полезно звучит сухо, но именно сухость защищает от ошибок.
Сначала формулируется одна рабочая тема. Не несколько. Если тема расползается, агент почти всегда начинает соединять несвязанные куски красивыми переходами.
Потом собираются проверенные факты. Если факт нельзя быстро объяснить, откуда он взялся, он либо должен быть подтверждён, либо исключён из публичного текста. Для статьи про дисциплину источника особенно важно не смешивать внутренние служебные артефакты и публичные утверждения.
Дальше задаются границы. Это может быть список простых запретов:
- не утверждать то, чего нет в source packet;
- не выводить причинно-следственные связи без основания;
- не называть внутренние теги частью текста статьи;
- не превращать статью в отчёт об изменении процессов.
После этого фиксируются метаданные производства. Здесь ONFF как раз использует компактные writer tags вроде writer:openai:gpt-5.4-mini:low. Такие теги полезны для фильтрации, сравнения качества и разбора ошибок. Но это именно метаданные. Их место — в карточке, в фильтрах, в учётных слоях. Не в основной прозе обычной статьи.
И наконец, задаётся контракт на выпуск. Модель должна понимать, что в финале нужен не просто текст, а текст вместе с проверяемыми сопутствующими слоями: структура, визуальный пакет, публикационная карточка, связка с downstream-каналами.
Что должно быть в хорошем источнике перед запуском
Если свести практику к рабочему минимуму, source packet до старта написания должен отвечать на несколько вопросов без обращения к чату.
- Что именно мы публикуем?
- На каких основаниях это пишем?
- Что считать сомнительным и не включать?
- Кто и чем это писал?
- Какой должен быть результат кроме самого текста?
- Как поймём, что выпуск завершён?
Если на любой из этих вопросов пакет отвечает расплывчато, агент будет компенсировать пустоту собственными связками. Обычно это выглядит гладко, но потом ломается на аудите.
Полезно держать пакет как короткий управленческий объект. Он должен помещаться в рабочую итерацию, быть версионированным и сопоставимым между выпусками. Тогда можно сравнивать не только тексты, но и процесс: где источник был точнее, где промпт был избыточным, где команда заранее зафиксировала ограничения, а где этого не сделала.
Что проверять после публикации
Хороший источник не заканчивается на отправке в модель. Он должен замыкаться проверкой.
После публикации стоит сверить минимум следующее:
- текст действительно опирается на source packet, а не на расширенные догадки;
- публичная статья не утащила внутрь служебные детали;
- карточка публикации показывает нужные метаданные;
- writer tag, если он нужен для фильтрации, хранится в metadata, а не в prose;
- визуальные материалы, если они предусмотрены, привязаны к публикации;
- downstream-каналы знают, что и когда ушло;
- статус переобхода или повторной индексации зафиксирован там, где его потом можно проверить.
Именно здесь становится видно, зачем вообще нужна дисциплина источника. Без неё публикация может выглядеть завершённой, но на самом деле останется неаудируемой. А в производственной среде неаудируемость — это форма скрытого риска.
Рабочий запрос и короткий чек-лист
Ниже — минимальный запрос, с которого удобно начинать работу с агентом:
Подготовь статью только по source packet. Если в пакете нет факта — не додумывай. Если есть сомнение — пометь его как ограничение. Сначала дай структуру, потом черновик, затем список мест, где нужен ручной контроль.
Чек-лист перед запуском статьи
- Тема сформулирована одним предложением.
- Факты собраны отдельно от чата.
- Есть список запретов и границ.
- Зафиксированы writer tag, итерация и версия промпта.
- Понятен выходной контракт: текст, карточка, визуалы, статусы.
- Определён план проверки после публикации.
- Public body не содержит служебных тегов и внутренней механики.
Вместо вывода: источник важнее «умного» текста
Если коротко, устойчивый контентный процесс начинается не с таланта модели, а с качества исходника. Codex и похожие инструменты полезны тогда, когда они работают как исполнители с ясной границей ответственности, а не как генераторы тумана. Для этого и нужен source packet: он фиксирует рабочую правду до того, как текст начнёт становиться красивым.
В ONFF мы всё чаще смотрим на такие пакеты как на основу управляемого выпуска. Это помогает не только писать лучше, но и сравнивать модели честно, разбирать ошибки предметно и не терять связь между черновиком, публикацией и следом в системе. Именно так контент остаётся рабочим объектом, а не случайным результатом удачной формулировки.
