| name | redpolicy-overview |
| description | Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование.
|
| user-invocable | false |
Редакционная политика: обзорные статьи
Общие правила хорошего письма описаны в скилле good-writing и antipatterns.md. Ниже — только правила, специфичные для обзорных статей.
Суть подхода
Обзорные статьи — это словарные, разборные и обзорные тексты по теме проекта. Они объясняют понятие, явление, подход, рынок, категорию инструментов или спорный вопрос, когда готового исходника нет и фактуру нужно собрать самостоятельно.
Главное отличие от других типов контента: у нас нет готового исходника. Фактуру нужно собрать самостоятельно через исследование темы в интернете, а потом на ее основе построить текст.
Целевая аудитория
Целевая аудитория берется из профиля проекта. Не подставляй аудиторию из старого проекта и не пиши «для всех».
Для них важно:
- Разобраться в теме на уровне, достаточном для работы и принятия решений
- Перестать путать термины и говорить о теме грамотно
- Понять, как применить знания в своей работе
- Не тратить часы на источники, которые написаны для другой аудитории
Текст не должен уходить в глубину, которая не нужна аудитории проекта. Если читатель из профиля проекта — специалист, допустима профессиональная глубина. Если нет — сложные детали объясняются только настолько, насколько они помогают принять решение или действовать.
Структура
Структура зависит от темы. Фиксированного шаблона нет. Но есть принципы:
Структура строится от вопросов читателя, а не от логики предмета. Не «как предмет устроен изнутри», а «что читателю нужно знать, чтобы применить это в работе или жизни».
Типичная логика обзорной статьи:
- Что это такое (определение простыми словами)
- Как это работает (механика без математики, через аналогии)
- Где и как это применяется (конкретные сценарии, инструменты)
- Практическая часть (что с этим делать читателю)
- Ограничения или нюансы (честная картина)
- Итог или выводы
Не все блоки обязательны. Для некоторых тем нужны сравнения, для других — подборка инструментов, для третьих — хронология развития. Структура подстраивается под тему.
Обязательные принципы структуры:
- Обзорная статья ОБЯЗАТЕЛЬНО содержит блок с практическими сценариями использования. Не «где применяется в индустрии», а «что читатель может сделать или попробовать прямо сейчас». Конкретные действия, конкретные инструменты, конкретные примеры из жизни.
- Если тема подразумевает инструменты — начинать с самого доступного для обычного пользователя, а не с самого известного на рынке.
- Не создавать отдельных блоков сравнения («чем A отличается от B»), если различия уже очевидны из определений. Встраивать ключевое различие в блок определений.
- Если понятие — не главная тема статьи, давать минимальный контекст (1-2 предложения) и двигаться к главному. Не расписывать типологию, историю и классификацию второстепенного понятия.
- Каждый важный вопрос читателя заслуживает отдельного заголовка. Не прятать важные темы в подразделы.
- Один заголовок = один вопрос. Не «Что такое [термин] и как он работает», а «Что такое [термин]». Если в заголовке два вопроса через «и» — это два блока.
- Подзаголовок статьи не должен быть кратким пересказом содержания. Если лид уже вводит в тему и перечисляет ключевые вопросы — подзаголовок не нужен. Подзаголовок-оглавление («Почему русский текст обходится дороже, что такое контекстное окно и как экономить») — антипаттерн.
Работа с фактурой
Фактура собирается агентом-исследователем ДО написания плана. Результат исследования лежит в файле research.md.
Правила работы с фактурой:
- Используем только факты из research.md. Не добавляем информацию, которой нет в исследовании.
- Если в research.md указано, что факт не подтвержден или источники противоречат друг другу, не используем его.
- Цифры, тарифы, даты берем строго из research.md с проверенными источниками.
- Можем переструктурировать и переформулировать найденное, но не выдумывать.
- Абстрактная статистика (размеры рынка, прогнозы аналитиков, проценты внедрения по отраслям) — не включать, если из нее нельзя извлечь конкретное действие для читателя. Прогноз «рынок вырастет до $50 млрд к 2030» не помогает читателю принять решение.
- Включать только продукты, релевантные целевой аудитории. Инструменты для другой аудитории не приоритизировать, даже если они известные или модные.
- Технические детали продуктов убирать, если они не нужны аудитории проекта. Достаточно объяснить, что продукт делает, кому подходит, сколько стоит или каких ресурсов требует.
- Каждый факт проверять вопросом: «Что читатель сделает с этой информацией?» Если ответа нет — факт убирать. Тренды рынка, динамика цен за годы, бенчмарки моделей, размеры словарей токенизаторов — наполнитель, если за ними не стоит конкретное действие для читателя.
- Абстрактные факты заменять конкретными советами. Не «исследование показало разницу в 50% между языками», а «если платите за токены — общайтесь на английском, так дешевле». Факт без действия = наполнитель. Факт с действием = польза.
- Проверять утверждения на актуальность. Если ограничение технологии частично снято (например, модели получили доступ к интернету), не писать о нем как об абсолютном. Добавлять оговорку: «если к модели не подключен поиск» или «на момент написания статьи».
Объяснение сложного
Обзорные статьи часто объясняют технические концепции. Правила:
- Определение — через знакомое. Не «[термин] — это метод реализации [сложная формулировка]», а простое объяснение через задачу, которую читатель узнает.
- Механика — через аналогии из жизни. Face ID, Google Translate, Roomba, рекомендации в YouTube — все, что читатель видит каждый день.
- Механику объяснять через конкретный сценарий, а не через абстракцию. Не «на входе у нас есть документы», а «у юридической компании есть сотни договоров, в которых она хочет разобраться». Читатель должен увидеть себя или знакомую ситуацию в объяснении.
- Если аналогия вводит сложное понятие, доводить ее до конца. Не «карта, только многомерная» — а объяснить, почему многомерная и что это значит, оставаясь в рамках той же аналогии. Если аналогия не позволяет объяснить нюанс, сказать об этом прямо: «аналогия здесь заканчивается, но суть в том, что...».
- Один термин за раз. Не вываливаем пять новых слов в одном абзаце.
- Если используем английский термин, даем пояснение при первом упоминании.
- Не упрощаем до неточности. Лучше сказать «это сложнее, но для понимания достаточно знать вот что» — и дать корректное упрощение.
Открывашка
Обзорные статьи часто начинаются с определения («X — это...»). Это самый слабый способ открыть текст.
Разрешенные типы открывашки — ровно один из пяти:
- Провокационный вопрос — вопрос, который заставляет читателя увидеть привычную тему под новым углом.
- Конкретный сценарий — узнаваемая ситуация, где читатель сталкивается с темой на практике.
- Неожиданный факт — конкретная цифра или деталь, которая удивит читателя
- Смелое утверждение — сильный тезис по теме, который хочется проверить дальше.
- Контринтуитивный тезис — утверждение, которое противоречит ожиданиям и сразу дает понять, что читатель узнает что-то новое
Запрещено:
- «X — это...» (словарное определение в начале)
- «В мире [темы]...» / «В эпоху [темы]...»
- «Когда речь заходит о...» / «Когда речь идет о...»
- Пересказ содержания статьи вместо открывашки
Открывашка не объясняет, что будет в статье. Она вовлекает.
Особенности стиля
Используем конструкции «можно сделать» вместо прямого обращения через глаголы, где это уместно. Не «загружаете фото и получаете результат», а «можно загрузить фото и получить результат».
Можно обращаться к читателю на «вы» в практических блоках, но без панибратства.
Там, где уместно, учим правильно называть вещи. Блок «как правильно говорить» с примерами через галочки и крестики — хороший прием для терминологических статей.
Не начинать блок с переходного абзаца. Заголовок уже дает контекст — начинаем сразу с сути. Не «Теперь посмотрим, что можно попробовать на практике», а сразу про практику.
Заголовки простые, от читателя. Не «Какие продукты уже работают и сколько стоят», а «Какие инструменты можно попробовать». Без кликбейтных добавок («о чем молчат в рекламе», «что скрывают вендоры»).
Перед блоками про стоимость, тарифы, API — объяснять контекст для обычного пользователя. Не предполагать, что читатель знает разницу между подпиской и оплатой по API, между бесплатным и платным использованием. Сначала контекст (кто платит, за что, когда это актуально) — потом цифры и таблицы.
В рекомендательных блоках (что попробовать, какой инструмент выбрать) писать естественным языком, а не структурировать как каталог. Не «Для знакомства с технологией:» / «Для продвинутого использования:», а «Самый простой вариант — ...», «Если нужно что-то серьезнее — ...». Текст должен читаться как совет знакомого, а не как карточка товара.
Форматирование
Горизонтальные разделители (—) внутри статьи не используются. Разделение через заголовки.
Изображения и схемы приветствуются. Для каждого изображения предусмотрен alt-текст, описывающий содержание.
Если в статье есть блок с обзором конкретных сервисов или инструментов, описание каждого сервиса пишется по принципам из ред-политики для статей-подборок (skills/redpolicy-article/SKILL.md): название, ссылка, стоимость, описание на 2-3 абзаца (что за инструмент, для чего нужен, что можно делать, какие фишки). Информация о сервисах проверяется через поиск, а не берется из знаний модели. При этом стиль подачи остается как в обзорной статье — естественным языком, а не как каталог.
Проверочные вопросы
- Понятно ли определение аудитории проекта?
- Есть ли в каждом блоке конкретика или только общие слова?
- Есть ли практическая применимость — читатель понимает, что ему с этим делать?
- Не слишком ли упрощено — нет ли фактических ошибок в угоду простоте?
- Не повторяются ли мысли в разных блоках?
- Ответили ли мы на основные вопросы целевой аудитории по этой теме?
- Все ли факты взяты из research.md?
Примеры обзорных статей находятся в examples/essays/. Загрузи 1–3 примера, если они есть. Если примеров нет, работай по этой ред-политике и профилю проекта.
