Обратный порядок: сначала текст, разметка — в последнюю очередь

Большинство авторов начинают с фрагментов {a|b|c} в надежде, что набор синонимов сложится в статью. Эта стратегия ломается в тот момент, когда в шаблон попадают грамматика, специфичные факты сайта или реальный нарратив. Решение — изменить направление работы.

Ментальная модель

Парсер и автор работают в противоположных направлениях.

• Парсер раскрывает синтаксис изнутри наружу. Сначала внутренние перечисления, потом внешние, потом permutations, потом подстановка переменных.
• Автор должен проектировать шаблон в обратную сторону: от готовой читаемой фразы обратно к синтаксису.

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

Вот эта смена направления:

готовая читаемая фраза
→ связать грамматику
→ выбрать безопасные границы веток
→ вынести переменные
→ добавить структурную вариативность
→ локальные синонимы — в последнюю очередь

Синонимизация — это финальная шлифовка, а не первый шаг.

Пятишаговый обратный workflow

1. Напишите финальное предложение обычным языком. Без фигурных и квадратных скобок, без переменных. Просто ту фразу, которую должен увидеть читатель.
2. Отметьте грамматику, которую нельзя разрывать. Подлежащее и сказуемое. Предлог и падежная форма. Существительное и согласованное прилагательное. Артикль и именная группа. Всё это не должно ломаться границей ветки.
3. Выберите безопасные границы веток. Граница ветки проходит между грамматическими единицами, а не внутри них.
4. Вынесите повторяющиеся или специфичные для сайта факты в переменные. Всё, что меняется от сайта к сайту, от продукта к продукту или от статьи к статье — переезжает в %ИмяПеременной%.
5. Сначала структурная вариативность, потом локальные синонимы. Permutations и необязательные фрагменты дают настоящее разнообразие. Синонимы — мелкая финальная доводка внутри уже безопасных грамматических слотов.

Практический тест перед каждой новой записью {a|b}:

Если я подменю только этот фрагмент, останутся ли корректными падеж, согласование, управление, артикль и порядок слов?

Если ответ не «да» сразу — связывайте в одну ветку бо́льшую фразу.

Фаза 0 — Сначала читаемая статья

Исходный текст — это сначала статья, и только потом вход для spintax. Читаемость всегда важнее удобства шаблонизации.

Шаг 1. Напишите обычную статью

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

На этом этапе не оптимизируйте под spintax. Вы пишете для одного живого читателя. Шаблон — потом.

Шаг 2. Отметьте шаблонизируемые зоны

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

• Фактические перечни (возможности, варианты использования, поддерживаемые интеграции) — элементы можно перемешивать и выбирать подмножеством.
• Параллельные описания (тарифы, типы продуктов, уровни платформы) — однотипно построенные элементы можно менять местами.
• Вступительные предложения разделов — обычно допустимы два-три альтернативных варианта формулировки.
• Конкретные данные, которые меняются от сайта к сайту — превращаются в переменные.

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

Типичная статья обычно состоит примерно из 60–70% фиксированного читаемого текста и 30–40% шаблонизируемых зон. Такое соотношение — признак здорового шаблона.

Шаг 3. Подготовьте шаблонизируемые зоны

Внутри отмеченных зон (только там) применяйте следующие принципы:

• Самодостаточность предложений. Каждое предложение в permutable-зоне должно читаться отдельно. Никаких «Вот почему...», «Следовательно...» или «Как уже упоминалось выше...» — всё это ломается при перестановке.
• Параллельные пункты списков. Элементы, которые будут переставляться, должны иметь один и тот же грамматический паттерн — одну структуру, одну форму. Параллельные элементы взаимозаменяемы, а именно это и нужно permutations.
• Одна мысль — одно предложение. Разделяйте идеи на отдельные предложения. Каждое становится элементом permutation.
• Конкретика вместо общих мест. Конкретные факты дают больше материала для вариаций, чем обобщённые прилагательные. «Запросы выполняются меньше чем за 100 мс» сильнее, чем «это быстро».

Общие правила статьи

Эти правила применяются ко всему тексту, а не только к шаблонизируемым зонам.

• Упоминания бренда. Упомяните бренд в начале, дальше используйте обобщённые замены («платформа», «сервис», «продукт»). Статья должна читаться естественно без названия бренда в каждом абзаце.
• Избегайте устаревающих инструкций. Не описывайте пошагово интерфейсы сторонних продуктов (кошельки, панели, внешние интеграции). Они меняются, и ваш шаблон устаревает. Лучше одно-два предложения о том, что делает инструмент.
• Длина секций. <h2>: 100–250 слов. <h3>: 50–150 слов. Если раздел перевалил за ~300 слов — разбивайте.
• Никаких наполнителей и мета-комментариев. Убирайте фразы, которые говорят про текст, а не сообщают информацию: «Давайте рассмотрим...», «Стоит отметить, что...», «В этом разделе мы расскажем...»

Типичные ошибки на этапе авторства

Чеклист исходного текста

Прежде чем переходить к разметке, проверьте:

• Статья хорошо читается как отдельная страница.
• Шаблонизируемые зоны выделены — не весь текст целиком.
• Предложения внутри этих зон самодостаточны.
• Элементы списков внутри этих зон параллельны.
• Бренд упоминается нечасто.
• Нет пошаговых инструкций по сторонним UI.
• Нет наполнителей и мета-комментариев.
• Каждый <h2> и <h3> укладывается в лимиты по длине.

Если все галочки стоят — исходный текст готов. Следующие три гайда превращают его в шаблон: переменные, permutations и грамматически безопасная синонимизация — именно в таком порядке.

Продолжить серию