redpolicy-overview

name	redpolicy-overview
description	Ред-политика для обзорных статей-эссе по теме проекта. Словарные, обзорные и разборные статьи: что это такое, как это работает, чем отличается от соседних понятий. Фактура собирается самостоятельно через исследование.
user-invocable	false

Редакционная политика: обзорные статьи

Общие правила хорошего письма описаны в скилле good-writing и antipatterns.md. Ниже — только правила, специфичные для обзорных статей.

Суть подхода

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

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

Целевая аудитория

Целевая аудитория берется из профиля проекта. Не подставляй аудиторию из старого проекта и не пиши «для всех».

Для них важно:

• Разобраться в теме на уровне, достаточном для работы и принятия решений
• Перестать путать термины и говорить о теме грамотно
• Понять, как применить знания в своей работе
• Не тратить часы на источники, которые написаны для другой аудитории

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

Структура

Структура зависит от темы. Фиксированного шаблона нет. Но есть принципы:

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

Типичная логика обзорной статьи:

1. Что это такое (определение простыми словами)
2. Как это работает (механика без математики, через аналогии)
3. Где и как это применяется (конкретные сценарии, инструменты)
4. Практическая часть (что с этим делать читателю)
5. Ограничения или нюансы (честная картина)
6. Итог или выводы

Не все блоки обязательны. Для некоторых тем нужны сравнения, для других — подборка инструментов, для третьих — хронология развития. Структура подстраивается под тему.

Обязательные принципы структуры:

• Обзорная статья ОБЯЗАТЕЛЬНО содержит блок с практическими сценариями использования. Не «где применяется в индустрии», а «что читатель может сделать или попробовать прямо сейчас». Конкретные действия, конкретные инструменты, конкретные примеры из жизни.
• Если тема подразумевает инструменты — начинать с самого доступного для обычного пользователя, а не с самого известного на рынке.
• Не создавать отдельных блоков сравнения («чем A отличается от B»), если различия уже очевидны из определений. Встраивать ключевое различие в блок определений.
• Если понятие — не главная тема статьи, давать минимальный контекст (1-2 предложения) и двигаться к главному. Не расписывать типологию, историю и классификацию второстепенного понятия.
• Каждый важный вопрос читателя заслуживает отдельного заголовка. Не прятать важные темы в подразделы.
• Один заголовок = один вопрос. Не «Что такое [термин] и как он работает», а «Что такое [термин]». Если в заголовке два вопроса через «и» — это два блока.
• Подзаголовок статьи не должен быть кратким пересказом содержания. Если лид уже вводит в тему и перечисляет ключевые вопросы — подзаголовок не нужен. Подзаголовок-оглавление («Почему русский текст обходится дороже, что такое контекстное окно и как экономить») — антипаттерн.

Работа с фактурой

Фактура собирается агентом-исследователем ДО написания плана. Результат исследования лежит в файле research.md.

Правила работы с фактурой:

• Используем только факты из research.md. Не добавляем информацию, которой нет в исследовании.
• Если в research.md указано, что факт не подтвержден или источники противоречат друг другу, не используем его.
• Цифры, тарифы, даты берем строго из research.md с проверенными источниками.
• Можем переструктурировать и переформулировать найденное, но не выдумывать.
• Абстрактная статистика (размеры рынка, прогнозы аналитиков, проценты внедрения по отраслям) — не включать, если из нее нельзя извлечь конкретное действие для читателя. Прогноз «рынок вырастет до $50 млрд к 2030» не помогает читателю принять решение.
• Включать только продукты, релевантные целевой аудитории. Инструменты для другой аудитории не приоритизировать, даже если они известные или модные.
• Технические детали продуктов убирать, если они не нужны аудитории проекта. Достаточно объяснить, что продукт делает, кому подходит, сколько стоит или каких ресурсов требует.
• Каждый факт проверять вопросом: «Что читатель сделает с этой информацией?» Если ответа нет — факт убирать. Тренды рынка, динамика цен за годы, бенчмарки моделей, размеры словарей токенизаторов — наполнитель, если за ними не стоит конкретное действие для читателя.
• Абстрактные факты заменять конкретными советами. Не «исследование показало разницу в 50% между языками», а «если платите за токены — общайтесь на английском, так дешевле». Факт без действия = наполнитель. Факт с действием = польза.
• Проверять утверждения на актуальность. Если ограничение технологии частично снято (например, модели получили доступ к интернету), не писать о нем как об абсолютном. Добавлять оговорку: «если к модели не подключен поиск» или «на момент написания статьи».

Объяснение сложного

Обзорные статьи часто объясняют технические концепции. Правила:

• Определение — через знакомое. Не «[термин] — это метод реализации [сложная формулировка]», а простое объяснение через задачу, которую читатель узнает.
• Механика — через аналогии из жизни. Face ID, Google Translate, Roomba, рекомендации в YouTube — все, что читатель видит каждый день.
• Механику объяснять через конкретный сценарий, а не через абстракцию. Не «на входе у нас есть документы», а «у юридической компании есть сотни договоров, в которых она хочет разобраться». Читатель должен увидеть себя или знакомую ситуацию в объяснении.
• Если аналогия вводит сложное понятие, доводить ее до конца. Не «карта, только многомерная» — а объяснить, почему многомерная и что это значит, оставаясь в рамках той же аналогии. Если аналогия не позволяет объяснить нюанс, сказать об этом прямо: «аналогия здесь заканчивается, но суть в том, что...».
• Один термин за раз. Не вываливаем пять новых слов в одном абзаце.
• Если используем английский термин, даем пояснение при первом упоминании.
• Не упрощаем до неточности. Лучше сказать «это сложнее, но для понимания достаточно знать вот что» — и дать корректное упрощение.

Открывашка

Обзорные статьи часто начинаются с определения («X — это...»). Это самый слабый способ открыть текст.

Разрешенные типы открывашки — ровно один из пяти:

1. Провокационный вопрос — вопрос, который заставляет читателя увидеть привычную тему под новым углом.
2. Конкретный сценарий — узнаваемая ситуация, где читатель сталкивается с темой на практике.
3. Неожиданный факт — конкретная цифра или деталь, которая удивит читателя
4. Смелое утверждение — сильный тезис по теме, который хочется проверить дальше.
5. Контринтуитивный тезис — утверждение, которое противоречит ожиданиям и сразу дает понять, что читатель узнает что-то новое

Запрещено:

• «X — это...» (словарное определение в начале)
• «В мире [темы]...» / «В эпоху [темы]...»
• «Когда речь заходит о...» / «Когда речь идет о...»
• Пересказ содержания статьи вместо открывашки

Открывашка не объясняет, что будет в статье. Она вовлекает.

Особенности стиля

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

Можно обращаться к читателю на «вы» в практических блоках, но без панибратства.

Там, где уместно, учим правильно называть вещи. Блок «как правильно говорить» с примерами через галочки и крестики — хороший прием для терминологических статей.

Не начинать блок с переходного абзаца. Заголовок уже дает контекст — начинаем сразу с сути. Не «Теперь посмотрим, что можно попробовать на практике», а сразу про практику.

Заголовки простые, от читателя. Не «Какие продукты уже работают и сколько стоят», а «Какие инструменты можно попробовать». Без кликбейтных добавок («о чем молчат в рекламе», «что скрывают вендоры»).

Перед блоками про стоимость, тарифы, API — объяснять контекст для обычного пользователя. Не предполагать, что читатель знает разницу между подпиской и оплатой по API, между бесплатным и платным использованием. Сначала контекст (кто платит, за что, когда это актуально) — потом цифры и таблицы.

В рекомендательных блоках (что попробовать, какой инструмент выбрать) писать естественным языком, а не структурировать как каталог. Не «Для знакомства с технологией:» / «Для продвинутого использования:», а «Самый простой вариант — ...», «Если нужно что-то серьезнее — ...». Текст должен читаться как совет знакомого, а не как карточка товара.

Форматирование

Горизонтальные разделители (—) внутри статьи не используются. Разделение через заголовки.

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

Если в статье есть блок с обзором конкретных сервисов или инструментов, описание каждого сервиса пишется по принципам из ред-политики для статей-подборок (skills/redpolicy-article/SKILL.md): название, ссылка, стоимость, описание на 2-3 абзаца (что за инструмент, для чего нужен, что можно делать, какие фишки). Информация о сервисах проверяется через поиск, а не берется из знаний модели. При этом стиль подачи остается как в обзорной статье — естественным языком, а не как каталог.

Проверочные вопросы

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

Примеры обзорных статей находятся в examples/essays/. Загрузи 1–3 примера, если они есть. Если примеров нет, работай по этой ред-политике и профилю проекта.