humanizer-ru

---
name: humanizer-ru
description: Возвращает автору голос в русскоязычных текстах от LLM. Чистит канцелярит, штампы, цепочки родительного, «является», кальки с английского, преувеличения, типографические маркеры; ведёт голосовой паспорт автора в `.humanizer/voice.json`, поддерживает жанровые пресеты (Habr/Telegram/email и др.) и режим аудита. Применять, когда пользователь просит «сделать текст человечнее», «убрать AI-стиль», «переписать по-человечески», или использует команду /humanizer-ru.
---

# Humanizer-RU

Скилл для редактирования русскоязычных LLM-текстов. Подход редакторский, не противодетекторный: цель — **вернуть автору голос**, а не «обмануть классификатор».

В традиции [Норы Галь](https://ru.wikipedia.org/wiki/Слово_живое_и_мёртвое), инфостиля и Розенталя. Опирается на классику русского редактирования, не на arms race с детекторами LLM.

## Что внутри

Скилл устроен как **три слоя**:

1. **Фразовый слой** — каталог из 50+ правил в 9 тематических группах: контентные паттерны, языковые, стилевые, типография, коммуникация, **морфология** (падежи, виды, согласования), **расширенная идиоматика** (4 класса калек), филлеры, **идеальная грамотность как маркер**.
2. **Документный слой** — структурная диагностика: listicle-сигнатура, плотность тире, разброс длин предложений, доля AI-цитат, плотность точки с запятой и одиночных двоеточий, голосовая консистентность с паспортом.
3. **Голосовой паспорт** — мета-уровень: сохраняемый артефакт `.humanizer/voice.json` с предпочтениями автора, эволюционирующий между сессиями.

Дополнительные механизмы:
- **Светофорная разметка** абзацев (🟢 не трогать / 🟡 точечно / 🔴 переписать) на основе паспорта.
- **Принцип жеста** — каждое предложение должно содержать авторский выбор слова, конкретику или неожиданный поворот.
- **Динамические приоритеты** по жанровому пресету (always/context/ignore вместо статических A/B/C/D).
- **Доменные whitelist'ы** (ИТ / финансы / медицина) — чтобы не заменять профильные термины на «упрощённые».

Это отличие от поверхностного перифразирования: скилл не «делает текст менее предсказуемым», а **возвращает в него конкретного автора**.

См. `dictionaries/` для расширенных словарей и whitelist'ов, `examples/` для регрессионных примеров.

## Команды и режимы

```
/humanizer-ru                          базовый прогон по последнему паспорту или дефолтам
/humanizer-ru --sample                 калибровка по образцу автора (приложить 2-3 абзаца)
/humanizer-ru --interview              калибровка через короткое интервью (если образца нет)
/humanizer-ru --preset=<имя>           использовать жанровый пресет (habr / telegram / email / vc / linkedin / docs)
/humanizer-ru --audit                  только диагностика, без правок
/humanizer-ru --rough                  опт-ин на намеренные микро-неровности (для соцсетей)
/humanizer-ru --reflect <финал>        обновить паспорт по финальной версии (post-hoc feedback)
/humanizer-ru --add-sample             добавить образец в существующий паспорт
```

Флаги комбинируются: `--preset=habr --sample` = калибровка по образцу + дефолты Habr поверх.

## Слой 3 — Голосовой паспорт

### Зачем это вообще

LLM по умолчанию пишет «усреднённого человека». Voice passport фиксирует **конкретного автора**, и каждая правка сверяется не с абстрактной нормой, а с тем, как пишет этот автор.

Паспорт хранится в `.humanizer/voice.json` в рабочей директории пользователя. Если файла нет — скилл предлагает калибровку. Если есть — использует и при необходимости эволюционирует.

### Схема `.humanizer/voice.json`

```json
{
  "version": 1,
  "created": "2026-04-27",
  "updated": "2026-04-27",
  "usage_count": 0,
  "calibration_mode": "sample",

  "address": "ты",
  "formality": 6,

  "typography": {
    "dash": "–",
    "dash_padding": "spaces",
    "quotes": "«ёлочки»",
    "yo_letter": "consistent",
    "nbsp": "minimal"
  },

  "rhythm": {
    "sentence_length_avg": 15,
    "sentence_length_min": 3,
    "sentence_length_max": 35,
    "sentence_variance": "high",
    "paragraph_length_avg": 4
  },

  "voice_features": {
    "irony": "occasional",
    "person": "first",
    "rhetorical_questions": true,
    "personal_anecdotes": true,
    "hedging": "minimal"
  },

  "preferred_phrases": ["по-человечески", "в общем"],
  "banned_phrases": ["являются", "в современном мире"],

  "channel_default": "habr",

  "context_exceptions": [],

  "history": [
    {
      "date": "2026-04-27",
      "session_id": "s1",
      "event": "calibrated_from_sample",
      "details": "initial calibration from 2-paragraph sample"
    }
  ]
}
```

### Поля паспорта

| Поле | Значения | Что значит |
|---|---|---|
| `address` | `ты`, `Вы`, `depends_on_channel` | Обращение к читателю |
| `formality` | 1-10 | Уровень формальности (1 = чат с другом, 10 = официальный документ) |
| `typography.dash` | `—`, `–`, `-` | Тип тире |
| `typography.dash_padding` | `spaces`, `none`, `mixed` | Пробелы вокруг тире |
| `typography.quotes` | `«ёлочки»`, `„лапки"`, `"прямые"`, `mixed` | Тип кавычек |
| `typography.yo_letter` | `consistent`, `never`, `ad_hoc` | Использование Ё |
| `typography.nbsp` | `strict`, `minimal`, `none` | Неразрывные пробелы |
| `rhythm.sentence_length_avg` | число | Средняя длина в словах |
| `rhythm.sentence_variance` | `high`, `medium`, `low` | Разброс длин (важно для burstiness) |
| `voice_features.irony` | `frequent`, `occasional`, `none` | Допустима ли ирония |
| `voice_features.person` | `first`, `we`, `impersonal` | Голос: я / мы / безличный |
| `voice_features.hedging` | `minimal`, `moderate`, `heavy` | Степень оговорок |
| `preferred_phrases` | список | Любимые обороты автора (сохранять) |
| `banned_phrases` | список | Запрещённые обороты (никогда не выдавать) |
| `channel_default` | имя пресета | Жанровый пресет по умолчанию |
| `context_exceptions` | список | Правила, которые не применять в указанных контекстах |
| `history` | список событий | Журнал изменений паспорта |

## Уровни калибровки

### Уровень 1 — Образец автора (идеал)

Автор предоставляет 2-3 абзаца своего письма. Скилл анализирует образец по конкретному алгоритму и заполняет полный паспорт. `calibration_mode: "sample"`.

#### Алгоритм извлечения voice features из образца

**Обращение (`address`).** Сканировать местоимения и формы глаголов:
- «ты, тебя, тебе, тобой» → `ты`
- «вы, вам, вас, вами» (с большой буквы) → `Вы`
- безличные конструкции преобладают, местоимений нет → `impersonal`
- неоднозначно → `depends_on_channel`

**Формальность (`formality`, 1-10).** Базовая = 5, корректировать:
- слэнг или явно неформальная лексика («норм», «короче», «вообще») → −2
- сокращения, аббревиатуры в неформальной форме → −1
- разговорные обороты → −2
- канцелярит («осуществление», «реализация», «в рамках») → +3
- юридические/научные термины → +2
- безличные конструкции преобладают → +1
- результат clamp в [1, 10]

**Тире (`typography.dash`).** Подсчитать em-dash (—), en-dash (–), дефис (-) в роли тире (с пробелами):
- em-dash > 2× en-dash → `"—"`
- en-dash > 2× em-dash → `"–"`
- только дефисы (-) с пробелами → `"-"`
- смешение → доминирующий тип, остальное в `history` как «непоследовательно»

**Пробелы вокруг тире (`typography.dash_padding`).** Если в 80%+ случаях есть пробелы — `"spaces"`. Если их нет — `"none"`. Иначе — `"mixed"`.

**Кавычки (`typography.quotes`).** Подсчитать «ёлочки», „лапки", "прямые". Доминирующий тип идёт в паспорт. Если мало вхождений (<3) — оставить дефолт пресета.

**Ё (`typography.yo_letter`).** Подсчитать слова с Ё и слова, в которых должна быть Ё, но стоит Е (использовать словарь основных Ё-слов: ёж, всё, ещё, плёнка, мёд, ёлка, пчёл, нашёл, и т.д.):
- 80%+ слов с правильной Ё → `consistent`
- 0-5% → `never`
- 5-80% → `ad_hoc`

**Неразрывные пробелы (`typography.nbsp`).** Проверить на наличие U+00A0 перед `%`, `°`, `км`, `шт`, инициалами:
- 80%+ соответствие → `strict`
- 20-80% → `minimal`
- <20% → `none`

**Ритм (`rhythm.*`).** Разбить на предложения по `[.!?]`, посчитать длины в словах:
- `sentence_length_avg` — среднее
- `sentence_length_min` — минимум
- `sentence_length_max` — максимум
- `sentence_variance`: σ ≥ 6 → `high`, 4-6 → `medium`, <4 → `low`
- `paragraph_length_avg` — среднее число предложений в абзаце

**Голосовые черты (`voice_features.*`):**
- `irony`: маркеры иронии (вопросы с восклицанием, контрапункты, само-преуменьшения, «ну», «конечно же», «серьёзно?») → подсчитать долю; >5% предложений → `frequent`, 1-5% → `occasional`, <1% → `none`
- `person`: преобладают «я» → `first`, «мы» → `we`, безличные → `impersonal`
- `rhetorical_questions`: есть ли вопросительные знаки в утвердительных контекстах → `true`/`false`
- `hedging`: доля слов «может быть», «возможно», «вероятно», «наверное», «скорее всего» → >5% → `heavy`, 1-5% → `moderate`, <1% → `minimal`
- `personal_anecdotes`: есть ли в тексте first-person narrative с конкретикой («у меня было», «помню как») → `true`/`false`

**Идиолект (`preferred_phrases`).** Найти повторяющиеся 2-3-словные обороты с частотой ≥2 в образце, исключая стоп-слова. Записать топ 3-5.

**Стоп-слова автора (`banned_phrases`).** На этапе калибровки оставить пустым или попросить автора. Заполняется через inline feedback в последующих сессиях.

### Уровень 2 — Bootstrap-интервью

Если образца нет, скилл задаёт **5-7 вопросов** одним сообщением и ждёт ответа:

```
Чтобы настроить скилл под тебя, ответь коротко на эти вопросы:

1. Обращение к читателю: «ты», «Вы», или зависит от канала?
2. Формальность по шкале 1-10 (1 = пишу как другу в мессенджере, 10 = официальный документ)?
3. Тире: длинное (—), короткое (–) или дефис (-)? Если не уверен — короткое.
4. Ирония: часто, иногда или никогда?
5. Канал публикации в большинстве случаев: Habr / vc.ru / Telegram / LinkedIn / email / документация?
6. Любимые обороты, которые ты вставляешь часто (если есть)?
7. Слова-табу — что точно не должно появляться в твоём тексте?
```

Из ответов собирается **минимальный паспорт**. `calibration_mode: "interview"`.

#### Алгоритм обработки ответов

**Q1 → `address`:**
- «ты» → `address: "ты"`, базовая `formality: 4`
- «Вы» → `address: "Вы"`, базовая `formality: 6`
- «зависит» → `address: "depends_on_channel"`, базовая `formality: 5`

**Q2 → `formality`:** перезаписывает базовую из Q1 (используется ответ автора, если он явный).

**Q3 → `typography.dash`:** прямое присвоение. Если «не уверен» — определить из канала (Q5): `docs`/`email` → `–`, остальное → `–` тоже (безопасный дефолт).

**Q4 → `voice_features.irony`:**
- «часто» → `frequent`, доп. `formality: -1` (ирония обычно снижает формальность)
- «иногда» → `occasional`
- «никогда» → `none`, доп. `formality: +1`

**Q5 → `channel_default`:** записать пресет. Заполнить дефолты пресета поверх ответов Q1-Q4 для полей, которые автор не указал явно (типография, NBSP и т.д.).

**Q6 → `preferred_phrases`:** парсить ответ, разделить по запятым/точкам, добавить в список. Если автор написал «нет» — оставить пустым.

**Q7 → `banned_phrases`:** аналогично Q6.

Поля `rhythm.*` заполняются дефолтами выбранного канала (без образца их не определить точно). После 2-3 сессий с inline feedback или одного `--add-sample` они уточнятся.

### Уровень 3 — Genre preset как fallback

Если автор спешит и не хочет ни образца, ни вопросов:

```
/humanizer-ru --preset=habr
[текст]
```

Скилл использует **дефолтный голос канала** (см. раздел «Жанровые пресеты»). Это **честный baseline**, не личный голос. Скилл явно говорит автору: «Персонализации нет, применён только пресет канала. Для лучшего результата — `--sample` или `--interview`».

`calibration_mode: "preset_only"`. Паспорт всё равно создаётся, но с пометкой о том, что это fallback.

### Иерархия применения

При работе скилл объединяет источники в порядке убывания приоритета:

1. **`context_exceptions`** из паспорта (явные исключения автора)
2. **`preferred_phrases` / `banned_phrases`** из паспорта
3. **Активный паспорт** (calibrated)
4. **Жанровый пресет** (channel_default или явный --preset)
5. **Дефолты скилла** (для полей, которые не заданы)

Если паспорт говорит «короткое тире», а пресет «никакого тире вообще» — побеждает паспорт.

## Auto-evolve: как паспорт растёт между сессиями

Паспорт не статичен. Три механизма обновления работают параллельно.

### Механизм 1 — Sample-driven (новые образцы)

Команда `/humanizer-ru --add-sample`. Скилл извлекает фичи из нового образца и **усредняет с существующим паспортом**:

- Числовые поля (длины предложений, формальность) — взвешенное среднее с прошлым (вес нового образца = 1, существующего = `usage_count`).
- Категориальные поля (тире, кавычки, обращение) — обновляются, если новый образец **уверенно показывает другое значение** (≥80% случаев в новом тексте).
- Списки `preferred_phrases` — пополняются новыми идиолектами автора.

Запись в `history`: `{"event": "sample_added", "details": "..."}`.

### Механизм 2 — Inline feedback (во время прогона)

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

1. Фиксирует событие в `history`: `{"event": "user_reverted", "details": "rule 2.3 в контексте научной статьи"}`.
2. Если **одно и то же правило отвергнуто 2+ раза** в разных сессиях, скилл автоматически:
   - Добавляет правило в `context_exceptions` с указанием контекста.
   - При следующем прогоне применяет правило мягче или не применяет вовсе в этом контексте.
3. Single rejection = только запись, без изменения активного поведения. Защита от шума.

### Механизм 3 — Post-hoc reflection

Команда `/humanizer-ru --reflect <финальная_версия>`. Скилл:

1. Читает снапшот предыдущего рерайта из `.humanizer/sessions/<последний_id>.md`.
2. Сравнивает с финальной версией, переданной автором (текст, который реально опубликован).
3. Различия = что автор откатил/доправил после прогона.
4. По правилу 2+ обновляет паспорт: повторные откаты идут в `context_exceptions` и/или меняют активные поля.

Запись в `history`: `{"event": "reflection", "session_compared": "<id>", "delta": "..."}`.

### Снапшоты сессий

После каждого рерайта скилл создаёт `.humanizer/sessions/<YYYY-MM-DD>-<slug>.md` с:

- Исходным текстом
- Применённым snapshot паспорта
- Финальным рерайтом

Это нужно для механизма 3 (reflect) и как журнал работы для пользователя.

## Жанровые пресеты

Пресет = **контекст публикации**, а не «формула статьи». Пресет описывает ожидания канала: что допустимо, что недопустимо, какая формальность.

### `habr`

Технический, экспертный, среднеформальный канал.

```yaml
address: ты
formality: 6
dash: –   # короткое
quotes: «ёлочки»
yo_letter: consistent
allow_listicle: false   # AI-маркер на Habr с активной модерацией НЛО
allow_micro_imperfections: false
allow_emoji: false
```

### `telegram`

Разговорный, неформальный, авторский канал.

```yaml
address: ты
formality: 3
dash: -   # дефис допустим
quotes: "прямые"
yo_letter: ad_hoc
allow_listicle: true
allow_micro_imperfections: true   # рекомендуются
allow_emoji: minimal
```

### `email`

Деловая или полу-деловая переписка.

```yaml
address: Вы
formality: 7
dash: –
quotes: «ёлочки»
yo_letter: consistent
allow_listicle: true   # уместно для перечислений
allow_micro_imperfections: false
allow_emoji: false
```

### `vc`

Бизнес-экспертный контент. Похож на `habr`, но мягче по модерации.

```yaml
address: ты
formality: 5
dash: –
quotes: «ёлочки»
yo_letter: consistent
allow_listicle: true
allow_micro_imperfections: false
allow_emoji: false
```

### `linkedin`

Полу-деловой нетворкинговый контент на русском.

```yaml
address: Вы
formality: 6
dash: –
quotes: «ёлочки»
yo_letter: consistent
allow_listicle: true
allow_micro_imperfections: false
allow_emoji: minimal
```

### `docs`

Техническая или продуктовая документация.

```yaml
address: impersonal   # безличные конструкции
formality: 8
dash: —   # длинное допустимо в документации
quotes: «ёлочки»
yo_letter: consistent
allow_listicle: true   # норма
allow_micro_imperfections: false
allow_emoji: false
```

### Динамические приоритеты по пресету

Вместо статических priorities A/B/C/D, у нас приоритет правила определяется **жанровым пресетом**. Каждый пресет указывает три набора:

- `always` — правила, которые применяются всегда в этом пресете (критические для канала)
- `context` — применяются с оговорками: если контекст это требует
- `ignore` — правило не применяется в этом канале (его срабатывание — false positive для жанра)

Это даёт точечный контроль: одно и то же правило может быть `always` для Habr и `ignore` для Telegram.

#### Приоритеты по пресетам

**`habr`:**
```yaml
always:
  - 1.1 (штампы эпохи)
  - 1.7 (общие выводы)
  - 2.3 (является)
  - 2.11 (отрицательные параллелизмы)
  - 4.1 (длинное тире)
  - 4.6 (точка с запятой)
  - 4.7 (одиночные двоеточия)
  - 5.1 (чатботные артефакты)
  - 6.* (морфология вся)
context:
  - 2.14 (преувеличения) — сохранить, если есть подтверждающий факт
  - 3.4 (списки) — допустимы 1-2 на статью, не больше
ignore:
  - 4.5 (NBSP) — не критично для онлайн-формата Habr
```

**`telegram`:**
```yaml
always:
  - 5.1 (чатботные артефакты)
  - 1.1 (штампы эпохи)
  - 4.6 (точка с запятой)
  - 4.7 (одиночные двоеточия)
context:
  - 4.1 (тире) — допустимы дефисы
  - 3.2 (эмодзи) — допустимы дозированно
  - 6.1 (паразитные обороты) — частично допустимы для разговорного
ignore:
  - 4.5 (NBSP) — не нужно для мессенджера
  - 3.1 (перегруз жирного) — bold в Telegram это акцент
```

**`email`:**
```yaml
always:
  - 5.1 (чатботные артефакты — кроме завершающих формул вежливости)
  - 1.1 (штампы эпохи)
  - 2.3 (является)
  - 2.4 (данный/указанный) — кроме формальных писем
  - 4.6 (точка с запятой) — заменять, кроме формальных перечислений
context:
  - 2.15 (Вы по умолчанию) — обычно сохранять
  - 3.4 (списки) — уместны для перечислений в email
  - 4.5 (NBSP) — желательны для деловой переписки
  - 4.7 (одиночные двоеточия) — допустимы в смысле «вот что нужно сделать:»
ignore: []
```

**`vc`:**
```yaml
always:
  - 1.1 (штампы эпохи)
  - 2.3 (является)
  - 2.11 (отрицательные параллелизмы)
  - 4.1 (длинное тире)
  - 4.6 (точка с запятой)
  - 4.7 (одиночные двоеточия)
  - 5.1 (чатботные артефакты)
context:
  - 3.4 (списки) — допустимы 2-3 на статью
  - 2.14 (преувеличения) — мягче, чем для Habr
ignore:
  - 4.5 (NBSP)
```

**`linkedin`:**
```yaml
always:
  - 5.1 (чатботные артефакты)
  - 1.1 (штампы эпохи)
  - 2.3 (является)
  - 4.6 (точка с запятой)
  - 4.7 (одиночные двоеточия)
context:
  - 2.15 (Вы по умолчанию) — обычно сохранять
  - 3.2 (эмодзи) — допустимы дозированно (1-2 поста)
  - 3.4 (списки) — норма для LinkedIn
ignore:
  - 4.5 (NBSP)
```

**`docs`:**
```yaml
always:
  - 5.1 (чатботные артефакты)
  - 1.1 (штампы эпохи)
  - 6.* (морфология) — критична
  - 4.5 (NBSP) — желательны
context:
  - 2.15 (Вы) — заменять на безличное, если возможно
  - 2.4 (данный/указанный) — допустимо в документации
  - 3.4 (списки) — норма
  - 4.1 (тире) — длинное допустимо
  - 4.6 (точка с запятой) — допустима в формальных перечислениях
  - 4.7 (одиночные двоеточия) — часто вводят определения, не править
ignore:
  - 1.3 (промо-язык) — в документации обычно не встречается, но если есть — править
  - 3.2 (эмодзи)
```

#### Если пресета не указали

Скилл применяет ВСЕ правила в режиме `always` — самый консервативный (это защита от ложных пропусков). Это эквивалентно «строгому режиму».

#### Custom presets

Пользователь может определить свой пресет в `.humanizer/presets/<имя>.yaml`. Скилл при загрузке проверит:
1. Сначала `.humanizer/presets/<имя>.yaml` в проекте
2. Затем встроенные пресеты в SKILL.md
3. Если не найдено — fallback на `habr` с предупреждением

Кастомный пресет наследует от встроенного через ключ `extends: <base>` и переопределяет нужные поля.

---

## Слой 2 — Структурная диагностика (audit-режим)

Фразовая чистка не лечит документ-уровневые AI-маркеры. Этот слой их **детектирует и сообщает автору** (а не правит автоматически — это требует переписывания целыми кусками с пониманием контекста).

### Когда запускается

- Всегда при `--audit` (только диагностика, без правок).
- В рамках основного прогона как **предварительный этап** — скилл сообщает автору, какие структурные правки понадобятся, и спрашивает, идти ли вперёд.

### Сигнатуры AI-формы

#### S1. Listicle-сигнатура

**Что считаем:** N последовательных секций (заголовок + содержимое) одинаковой структуры.

**Порог:** 4+ параллельных секций → AI-маркер высокого уровня. 6+ → критический.

**Как считать:** заголовки уровня `##` или `###` с одинаковым шаблоном (например, «N. Существительное» × 6 раз) + параллельная внутренняя структура (тезис → таблица → объяснение).

**Сообщение автору:** «Найдено 10 параллельных секций уровня `##`. Это структурный AI-маркер. Рекомендация: разбавить нарративом, объединить часть, изменить форму нескольких заголовков на вопросы или истории».

#### S2. Плотность тире

**Что считаем:** количество тире (любого типа) на 1000 знаков.

**Норма для онлайна:** ≤ 3 тире / 1000 знаков. **Перегруз:** 4-6. **Критический:** 7+.

**Как считать:**
```
em_dash_count = text.count("—")
en_dash_count = text.count("–")
total = em_dash_count + en_dash_count
density = total / (len(text) / 1000)
```

**Сообщение:** «Тире: 84 шт. на 25000 знаков (3.4 / 1000). Это пунктуационный фон, не акцент. Рекомендация: ≤30 тире, остальные заменить на запятые/точки/двоеточия».

#### S3. Доля AI-цитат в теле

**Что считаем:** для текстов, разбирающих AI-паттерны, левая колонка таблиц «было/стало» и блочные цитаты с примерами AI-стиля считаются как AI-текст внутри документа.

**Порог:** ≤ 5% объёма — норма. 5-15% — заметно. 15%+ — критический риск бана классификатором.

**Как считать:** проценту суммы длин `<блок-AI-цитата>` относительно длины тела статьи.

**Сообщение:** «AI-цитаты в теле: 32% объёма. Классификатор не различает контекст и считает их как сгенерированную прозу. Рекомендация: вынести в инлайн короткими цитатами вместо таблиц».

#### S4. Burstiness — разброс длин предложений

**Что считаем:** стандартное отклонение длин предложений по тексту.

**Норма:** σ ≥ 6 слов. **Низкая burstiness:** σ < 4 (AI-маркер).

**Как считать:** разбить текст на предложения, посчитать длины в словах, найти стандартное отклонение.

**Сообщение:** «Длины предложений: avg 16, σ 3.1. Текст ровный по ритму, что характерно для AI. Рекомендация: добавить короткие предложения (3-5 слов) и длинные (25+) вперемежку».

#### S5. Burstiness — разброс длин абзацев

**Что считаем:** стандартное отклонение количества предложений в абзаце.

**Норма:** диапазон от 1 до 6+ предложений в абзацах присутствует. **Маркер:** все абзацы 3-5 предложений.

**Сообщение:** «Все абзацы 3-5 предложений. Добавь однострочные абзацы и длинные (6+) для ритма».

#### S6. Параллельные начала абзацев

**Что считаем:** N абзацев подряд, начинающихся одной частью речи или схожей конструкцией («AI обожает...», «AI вставляет...», «AI пишет...»).

**Порог:** 3+ абзацев подряд с однотипным началом — маркер.

#### S7. Точка с запятой и одиночные двоеточия

**Что считаем:**

1. **Плотность точки с запятой:** число `;` на 1000 знаков. См. правило 4.6.
2. **Доля одиночных двоеточий:** двоеточия, после которых НЕ следует перечисление из 2+ элементов или прямая речь / цитата. См. правило 4.7.

**Как считать одиночные двоеточия:**
```
для каждого ":" в тексте:
  посмотреть текст после ":"
  если следует:
    - перечисление через запятые из 2+ элементов → list
    - прямая речь в кавычках → quote
    - блок-список (markdown) после переноса → list
    - заголовок (структурный элемент) → heading
  иначе → solo
ratio = solo / (solo + list + quote)
```

**Пороги:**

| Метрика | Норма | Предупреждение | Критично |
|---|---|---|---|
| `;` на 1000 знаков | 0 (для онлайн-пресетов) | 0.3-1.0 | >1.0 |
| Доля одиночных `:` | <20% | 20-40% | >40% |

**Сообщение автору:**

> «Точка с запятой: 7 шт. на 5000 знаков (1.4 / 1000). В русском онлайн-тексте это редкий знак — рассмотри замену на точку, тире или запятую (правило 4.6). Двоеточий: 12, из них 8 без перечисления (66%) — рассмотри замену на точку или короткое тире (правило 4.7).»

**Исключения:** в пресете `docs` пороги мягче (точка с запятой может быть уместна в формальных перечислениях; двоеточия часто вводят определения). Для `email` в формальных контекстах двоеточия в смысле «вот что нужно сделать:» допустимы.

### Метрики голосовой консистентности

Если есть активный паспорт, дополнительно:

#### V1. Соответствие типографике паспорта

Какой % употреблений тире/кавычек/Ё в тексте совпадает с паспортом?

#### V2. Соответствие ритма

Средние длины предложений в тексте vs `rhythm.sentence_length_avg` паспорта. Допустимое отклонение: ±20%.

#### V3. Использование `preferred_phrases` / `banned_phrases`

Сколько любимых оборотов автора встречается в тексте? Сколько запрещённых попало в финал?

### Чек-лист структурных правок

Когда диагностика показывает проблемы, скилл выдаёт автору:

```markdown
## Структурный аудит

| Метрика | Значение | Норма | Статус |
|---|---|---|---|
| Параллельных секций | 10 | ≤3 | КРИТИЧНО |
| Тире / 1000 знаков | 3.4 | ≤3 | ПЕРЕГРУЗ |
| AI-цитаты в теле | 32% | ≤5% | КРИТИЧНО |
| Burstiness предложений (σ) | 3.1 | ≥6 | НИЗКАЯ |
| Burstiness абзацев | равномерная | разнородная | МАРКЕР |
| Точка с запятой / 1000 | 1.4 | 0 | ПЕРЕГРУЗ |
| Одиночные двоеточия | 66% | <20% | КРИТИЧНО |

### Рекомендации

1. Сломать listicle: половину секций превратить в нарративные блоки, заголовки разнотипные.
2. Сократить блоки AI-цитат до инлайн-формы.
3. Тире — заменить большую часть на запятые/точки.
4. Добавить короткие предложения (3-5 слов) и длинные (25+).
5. Разнообразить длины абзацев: однострочные перемежать с длинными.
6. Точку с запятой заменить на точку, тире или запятую (правило 4.6).
7. Одиночные двоеточия (без перечисления после) заменить на точку или короткое тире (правило 4.7).
```

---

## Слой 1 — Каталог фразовых паттернов

Эти правила работают на уровне отдельных фраз. Применяются при основном прогоне после калибровки.

### 1. Контентные паттерны

#### 1.1. Штампы «современной эпохи»
AI любит открывать абзац обобщениями про время и технологии.

| Было | Стало |
|---|---|
| «В современном мире, где технологии не стоят на месте...» | Начать с конкретного факта |
| «В эпоху цифровизации каждая компания сталкивается с...» | «70% компаний внедряют X» |
| «В условиях быстро меняющегося мира...» | Убрать |
| «Мир не стоит на месте» | Убрать |

#### 1.2. Раздувание значимости
Придание рутинным вещам эпического веса.

| Было | Стало |
|---|---|
| «Играет ключевую роль в...» | «Используется для...» |
| «Является неотъемлемой частью...» | «Часть ...» |
| «Краеугольный камень / золотой стандарт» | Конкретный факт |
| «Знаменует собой важный этап в эволюции...» | Убрать, заменить фактом |

#### 1.3. Промо-язык
Экскурсоводческий пафос.

| Было | Стало |
|---|---|
| «Уютно расположенный в живописном регионе» | «Находится в регионе X» |
| «Величественный», «захватывающий», «потрясающий» | Факты без эпитетов |
| «Впечатляющая коллекция / богатая история» | Конкретные числа/события |

#### 1.4. Поверхностный анализ через «-ание/-ение»
Цепочки абстрактных существительных, которые звучат умно, но ничего не говорят.

| Было | Стало |
|---|---|
| «Подчёркивая значимость, отражая важность, демонстрируя потенциал...» | Убрать или заменить конкретикой |
| «Осуществляет оптимизацию процессов взаимодействия» | «Ускоряет общение» |

#### 1.5. Ложные масштабы и «от X до Y»
Искусственное расширение темы.

| Было | Стало |
|---|---|
| «От стартапов до корпораций, от разработчиков до маркетологов...» | Перечислить то, что реально релевантно |
| «Затрагивает всё — от экономики до культуры» | Назвать конкретные области |

#### 1.6. Формулаические «вызовы»
| Было | Стало |
|---|---|
| «Несмотря на вызовы, экосистема продолжает процветать» | Назвать конкретные проблемы и реакцию |
| «Перед нами стоят непростые задачи» | Перечислить задачи |

#### 1.7. Общие выводы
| Было | Стало |
|---|---|
| «Будущее обещает быть светлым» | Конкретные планы |
| «Время покажет» | Убрать или назвать срок |
| «Возможности безграничны» | Перечислить реальные возможности |

### 2. Языковые паттерны

#### 2.1. Канцелярит и номинализация
AI-русский превращает глаголы в существительные, раздувая фразу.

| Было | Стало |
|---|---|
| «Осуществление проверки документов» | «Проверка документов» / «Проверить документы» |
| «Принятие решения о запуске» | «Решили запустить» |
| «Обеспечение возможности доступа» | «Позволяет получить доступ» |
| «Производит оценку ситуации» | «Оценивает ситуацию» |
| «Выполняет функцию защиты» | «Защищает» |

#### 2.2. Цепочки родительного падежа
Три и более существительных подряд в родительном.

| Было | Стало |
|---|---|
| «Улучшение качества обслуживания клиентов компании» | «Клиенты стали довольнее» |
| «Процесс оптимизации системы мониторинга производительности» | «Ускорили мониторинг» |
| «Анализ эффективности стратегии развития продукта» | «Проверили, как растёт продукт» |

#### 2.3. «Является» — слово-паразит
Почти всегда можно убрать или заменить на «это» / тире / прямую связку.

| Было | Стало |
|---|---|
| «Данный подход является эффективным» | «Этот подход эффективен» |
| «Это является важным фактором» | «Это важно» |
| «Продукт является решением проблемы» | «Продукт решает проблему» |

#### 2.4. «Данный / указанный / вышеупомянутый»
Канцеляризмы из юридических текстов, неуместные в нормальной речи.

| Было | Стало |
|---|---|
| «В рамках данного проекта» | «В этом проекте» |
| «Указанные выше пункты» | «Эти пункты» |
| «Вышеупомянутая задача» | «Эта задача» |

#### 2.5. Пассивные конструкции без нужды
| Было | Стало |
|---|---|
| «Решение было принято» | «Приняли решение» |
| «Работа была проделана» | «Сделали работу» |
| «Результаты были получены» | «Получили результаты» |

Исключение: пассив уместен, когда субъект неважен или неизвестен.

#### 2.6. Избыточные придаточные с «который»
| Было | Стало |
|---|---|
| «Система, которая обеспечивает мониторинг, который позволяет отслеживать...» | «Система мониторит X и отслеживает Y» |
| «Функция, которая используется для того, чтобы...» | «Функция для...» |

#### 2.7. AI-словарь на русском
Слова-маркеры, которые AI вставляет автоматически:

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

**Связки:** *в свою очередь, с одной стороны / с другой стороны (без нужды), в этой связи, в данном контексте*

**Закрытия:** *в заключение, подводя итог, в свете вышесказанного, как мы видим*

**Действие:** убирать целиком или заменять на прямое утверждение.

#### 2.8. Ложные кальки с английского
Прямые переводы AI-штампов, которые в русском не звучат:

| Калька | По-русски |
|---|---|
| «В конце дня» (at the end of the day) | «В итоге» |
| «На одной странице» (on the same page) | «Одинаково понимаем» |
| «Давайте нырнём / погрузимся» (let's dive in) | «Разберёмся» |
| «Это меняет игру» (game-changer) | Назвать, что именно меняется |
| «В сердце X» (at the heart of X) | «В основе X» |
| «Прикоснуться к будущему» | Убрать |
| «Думать за пределами коробки» (outside the box) | «Нестандартно подойти» |
| «На следующем уровне» (next-level) | Конкретно, чем лучше |

#### 2.9. Правило трёх
Искусственное перечисление через три элемента с нарастанием.

| Было | Стало |
|---|---|
| «Быстро, надёжно и удобно» | Назвать реально важное |
| «Инновации, вдохновение и возможности» | Убрать или заменить конкретикой |
| «Вдохновляет, мотивирует и трансформирует» | Конкретный результат |

**Правило:** если перечисление из ровно трёх элементов, где элементы абстрактные — скорее всего AI. Менять на 2 или 4 пункта с конкретикой, либо один глагол.

#### 2.10. Синоним-цикл
AI боится повторить слово и гонит синонимы даже там, где повтор лучше.

| Было | Стало |
|---|---|
| «Продукт... решение... сервис... инструмент...» (про одну и ту же вещь) | Повторить одно слово |
| «Клиент... пользователь... заказчик... покупатель...» | Выбрать одно подходящее слово и держаться его |

#### 2.11. Отрицательные параллелизмы
Калька с «It's not just X, it's Y». В AI-русском стала эпидемией.

| Было | Стало |
|---|---|
| «Это не просто инструмент, это философия» | «Это новый подход к работе» или «Это инструмент, который меняет X» |
| «Не просто продукт — образ жизни» | Убрать, назвать что продукт делает |
| «Не продукт, а платформа» | Сказать, что платформа даёт |

#### 2.12. Избыточные вводные
| Было | Стало |
|---|---|
| «Необходимо отметить, что...» | Убрать, сказать сразу |
| «Стоит обратить внимание на то, что...» | Убрать |
| «Следует иметь в виду, что...» | Убрать |
| «Хочется подчеркнуть, что...» | Убрать |

#### 2.13. Избыточное хеджирование
| Было | Стало |
|---|---|
| «Потенциально может возможно повлиять» | «Может повлиять» или «Повлияет» |
| «В некоторой степени в определённом смысле» | Одно слово или убрать |
| «Как бы» (паразит) | Убрать |

#### 2.14. Преувеличения и превосходные степени
AI на русском обожает масштаб без оснований.

**Слова-триггеры:** *революционный, уникальный, беспрецедентный, потрясающий, впечатляющий, кардинально, высококлассный, первоклассный, непревзойдённый, передовой, инновационный*

**Действие:** использовать **только** если есть факт, подтверждающий превосходство. Иначе удалить.

#### 2.15. Вежливая дистанция «Вы» по умолчанию
AI по умолчанию переходит на уважительное «Вы» даже в casual-контексте блога или Telegram-канала.

**Действие:** определить тон из паспорта или пресета. По умолчанию (если ничего не указано) — `«ты»` для блогов и соцсетей, `«Вы»` для email/документации.

### 3. Стилевые паттерны

#### 3.1. Перегруз жирного
| Было | Стало |
|---|---|
| «Мы предлагаем **OKR**, **KPI** и **BMC** для вашей команды» | «Мы предлагаем OKR, KPI и BMC для вашей команды» |

Жирным выделять только то, что реально важно для скана — один-два элемента на абзац максимум.

#### 3.2. Эмодзи в заголовках и списках
🚀 💡 ✅ 🎯 — удалить, если пресет не разрешает (см. `allow_emoji` в пресете).

#### 3.3. Инлайн-заголовки «**Термин:** описание»
| Было | Стало |
|---|---|
| «**Скорость:** продукт работает быстро.» | Нормальный текст без подменяющих двоеточий |

#### 3.4. Маркированные списки без причины
AI превращает в списки то, что лучше читается прозой.

**Правило:** список уместен, если есть ≥3 параллельных пункта одной структуры. Два пункта — проза. Пункты разной длины/типа — проза.

В пресетах с `allow_listicle: false` (например, `habr`) дополнительно: подряд более 3 списков на странице — AI-маркер.

#### 3.5. Фрагментарные заголовки
| Было | Стало |
|---|---|
| `## Производительность`<br>`Скорость важна.` | Убрать заголовок или развернуть раздел |

Заголовок должен вводить секцию, а не дублировать единственную фразу.

### 4. Русская типографика

#### 4.1. Тире: длинное / короткое / дефис

**Главный маркер AI:** длинное тире `—` с пробелами в онлайн-контенте. Живые авторы в этих форматах почти всегда ставят короткое тире `–` или просто дефис `-`. Длинное `—` уместно только в отредактированной печати — книгах, журналах, академических статьях.

**Правило применения:**

1. **Если есть паспорт** — копировать стиль автора точно.
2. **Если есть пресет** — использовать дефолт пресета (см. таблицу выше).
3. **Если ничего не известно** — предполагать онлайн-контент и ставить короткое тире `–`. Это безопаснее, чем навязать длинное там, где оно чужеродно.

**Автоматическая замена:** при переписывании AI-текста для онлайн-формата все `—` с пробелами меняются на `–` (или другие знаки) в соответствии с пресетом или паспортом.

#### 4.2. Перегруз тире (независимо от типа)
| Было | Стало |
|---|---|
| «Код — чистый, тесты — зелёные, деплой — успешный, команда — довольна» | «Код чистый, тесты зелёные, деплой прошёл, команда довольна» |

Два и более тире в одном предложении почти всегда заменяются на запятые/точки. См. также метрику S2 в audit-режиме (плотность тире).

#### 4.3. Кавычки
- Книжно-редакторский стиль: «ёлочки» снаружи, „лапки" внутри
- Онлайн: часто «ёлочки» или прямые `"..."`
- AI-маркер: смешение типов или прямые `"..."` в тексте, где автор обычно ставит «ёлочки»

**Правило:** определить тип из паспорта/пресета, применять последовательно.

#### 4.4. Буква Ё
- Если в паспорте `yo_letter: consistent` — ставить везде.
- Если `never` — не ставить.
- Если `ad_hoc` — оставить как у автора.
- Смешение в тексте без указания в паспорте — AI-маркер непоследовательности.

#### 4.5. Неразрывные пробелы
Перед `%`, `°`, единицами измерения, в инициалах (`А. С. Пушкин`) — желательны для типографически строгих контекстов (`docs`, `email`), не критичны для онлайна.

#### 4.6. Точка с запятой (;)

**Сильный AI-маркер в обычном онлайн-тексте.** Точка с запятой в русском используется редко: преимущественно в академических текстах, юридических документах и сложных перечислениях. В блогах, статьях, постах, мессенджерах — почти не встречается.

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

| Было (AI) | Стало (живой) |
|---|---|
| «Это работает; но не всегда» | «Это работает. Но не всегда» |
| «Решение простое; код сразу заработает» | «Решение простое — код сразу заработает» |
| «Мы оптимизировали запросы; добавили индексы; внедрили кэш» | «Мы оптимизировали запросы, добавили индексы, внедрили кэш» |
| «Опасность не очевидна; последствия серьёзные» | «Опасность не очевидна. Последствия серьёзные» |

**Правило:** в большинстве пресетов (`habr`, `telegram`, `vc`, `linkedin`, `email`) — заменять `;` на точку, тире или запятую в зависимости от смысла связки. Исключение — `docs` (документация) и юридические тексты, где точка с запятой может быть уместна в формальных перечислениях.

**Где точка с запятой допустима:**
- Сложные академические перечисления, где элементы сами содержат запятые
- Юридические тексты и официальные документы
- Когда автор её явно использует в образце (паспорт `preferred_phrases` или образец)

#### 4.7. Двоеточие (:) без последующего перечисления

Двоеточие в русском вводит, как правило, перечисление, прямую речь или чёткое объяснение. AI расставляет его в значении «потому что» или «то есть» в каждой третьей фразе — это калька с английской пунктуации.

**Здоровое использование:**
| Употребление | Пример |
|---|---|
| Перед перечислением (список из ≥2 пунктов) | «Команда состоит из трёх человек: дизайнер, разработчик, продакт» |
| Перед прямой речью или цитатой | «Он сказал: «Так не работает»» |
| После обобщающего слова | «Все понимают одно: дедлайн ближе» |

**AI-перегруз (двоеточие без явного перечисления):**
| Было (AI) | Стало (живой) |
|---|---|
| «Решение простое: всё работает» | «Решение простое. Всё работает» или «Решение простое — всё работает» |
| «Главное условие: соблюдать порядок» | «Главное условие — соблюдать порядок» |
| «Это полезный инструмент: он экономит время» | «Это полезный инструмент. Экономит время» |
| «Метод эффективен: работает в 90% случаев» | «Метод эффективен — работает в 90% случаев» |

**Правило:** если после двоеточия идёт **одна** независимая фраза без явного перечисления — заменить на точку или короткое тире. Если идёт **2+ элемента списка** или прямая речь — оставить.

**Метрика для audit (см. Слой 2, S7):** считать долю двоеточий, после которых **не** следует перечисление из 2+ элементов. >40% «одиночных» двоеточий — AI-маркер.

### 5. Коммуникационные паттерны

#### 5.1. Чатботные артефакты
| Было | Стало |
|---|---|
| «Надеюсь, это помогло!» | Убрать |
| «Если остались вопросы — спрашивайте!» | Убрать (если не письмо клиенту) |
| «Рад помочь!» | Убрать |
| «Отличный вопрос!» | Убрать |

#### 5.2. Сикофантия
| Было | Стало |
|---|---|
| «Вы абсолютно правы!» | «Да» / ответ по существу |
| «Прекрасное замечание!» | Убрать |
| «Великолепно сформулировано!» | Убрать |

#### 5.3. Дисклеймеры про cutoff и ограничения
| Было | Стало |
|---|---|
| «Хотя информация по данной теме ограничена...» | Найти информацию или убрать |
| «В рамках доступных мне данных...» | Убрать |

#### 5.4. Приглашения продолжить
| Было | Стало |
|---|---|
| «Дайте знать, если нужно развернуть какую-то часть» | Убрать (кроме переписки) |
| «Готов ответить на дополнительные вопросы» | Убрать |

### 6. Морфологические маркеры

Морфологические ошибки — отдельный класс маркеров, на который статистические классификаторы смотрят дополнительно к лексическим. AI ошибается в морфологии иначе, чем люди: люди путают «-тся/-ться», AI чаще путает падежи в длинных цепочках, нарушает согласование рода в составных подлежащих, использует деепричастия не к тому подлежащему.

#### 6.1. Падежные несогласования
| Было | Стало |
|---|---|
| «для различных платформ: социальные сети» | «для различных платформ: социальных сетей» |
| «в результате анализ данных» | «в результате анализа данных» |
| «при помощи новый инструмент» | «при помощи нового инструмента» |

**Действие:** проверять каждое предложное сочетание и каждое родительное определение на падеж.

#### 6.2. Несогласованные деепричастия
Деепричастный оборот должен относиться к подлежащему главного предложения. AI это правило путает.

| Было | Стало |
|---|---|
| «Проанализировав данные, результаты были получены» | «Проанализировав данные, мы получили результаты» |
| «Просмотрев документ, ошибка стала очевидна» | «При просмотре документа ошибка стала очевидна» |

#### 6.3. Род глагола и прилагательного при составных подлежащих
| Было | Стало |
|---|---|
| «Компания заявил» | «Компания заявила» |
| «Команда разработала и внедрил» | «Команда разработала и внедрила» |

#### 6.4. Вид глагола (совершенный/несовершенный)
| Было | Стало |
|---|---|
| «Он будет делать работу и сделает её» | «Он сделает работу» или «он делает работу» |
| «Постоянно проанализировал ситуацию» | «Постоянно анализировал» |

#### 6.5. Избыточные подлежащие (pro-drop русского)
Русский позволяет опускать подлежащее. AI вставляет его всегда — реликт английского обучающего корпуса.

| Было | Стало |
|---|---|
| «Он встал и он пошёл к двери» | «Встал, пошёл к двери» |
| «Я думаю, что я прав» | «Думаю, прав» |
| «Они сделали то, что они хотели» | «Они сделали то, что хотели» |

### 7. Расширенная идиоматика: типизация калек

Раздел 2.8 покрывал базовые кальки. Здесь расширенный каталог с типологией — AI на русском воспроизводит четыре класса английских конструкций.

#### 7.1. Маркетинговый перевод-стиль
Английские слоганы, переведённые буквально.

| Калька | Источник | По-русски |
|---|---|---|
| «Это меняет игру» | game-changer | Назвать, что меняется |
| «На следующем уровне» | next-level | Лучше в чём-то конкретном |
| «За пределами коробки» | outside the box | Нестандартно |
| «Делает разницу» | makes a difference | Имеет значение / влияет |
| «Двигаемся вперёд» | moving forward | В дальнейшем / далее |
| «Конец дня» | end of the day | В итоге |
| «Прикоснуться к будущему» | touch the future | Убрать |
| «Изменить правила игры» | change the game | Конкретное изменение |

#### 7.2. Академический английский
Кальки из научного и экспертного дискурса.

| Калька | Источник | По-русски |
|---|---|---|
| «Стоит отметить, что» | It's worth noting | Просто сказать |
| «Важно понимать, что» | It's important to understand | Убрать |
| «Можно сказать, что» | One could say | Убрать или утверждать |
| «По мнению экспертов» | Experts say | Назвать конкретного эксперта |
| «Данное исследование показывает» | This study shows | «Исследование показывает» |
| «В контексте этого» | In this context | По теме / здесь |
| «Было бы справедливо сказать» | It would be fair to say | Убрать |

#### 7.3. Корпоративный английский
Бизнес-фразеология, переведённая с инглиша.

| Калька | Источник | По-русски |
|---|---|---|
| «На одной странице» | on the same page | Одинаково понимаем |
| «Бесшовный опыт» | seamless experience | Удобный / без сбоев |
| «Решение из коробки» | out of the box | Готовое решение |
| «Развернуть стратегию» | roll out strategy | Запустить / внедрить |
| «Поднять флаг» | raise a flag | Обратить внимание / предупредить |
| «Иметь смысл» | makes sense | Логично |
| «Двинуть иголку» | move the needle | Реально повлиять |

#### 7.4. Метафорические кальки
Английские метафоры, в русском звучат странно.

| Калька | Источник | По-русски |
|---|---|---|
| «В сердце системы» | at the heart of | В основе |
| «Двусторонний меч» | double-edged sword | У этого две стороны |
| «Низко висящий фрукт» | low-hanging fruit | Простое / очевидное |
| «Бросить камень» | throw a stone | Упрекнуть |
| «Открыть банку червей» | open a can of worms | Затронуть болезненную тему |

**Действие:** при подозрении на кальку — найти английский оригинал. Если калька буквальная, заменить на русский эквивалент или конкретное выражение.

См. также `dictionaries/calques.md` для расширенного каталога с контекстами употребления.

### 8. Филлеры и вода

#### 8.1. Паразитные обороты
| Было | Стало |
|---|---|
| «В рамках чего-либо» | Убрать или заменить простым предлогом |
| «Посредством» | «С помощью» / «Через» |
| «В целях» | «Чтобы» |
| «На сегодняшний день» | «Сейчас» |
| «На текущий момент времени» | «Сейчас» |
| «В первую очередь» | «Сначала» / убрать |

#### 8.2. Двойные наречия
| Было | Стало |
|---|---|
| «Весьма значительно» | «Значительно» |
| «Крайне важно» | «Важно» |
| «Совершенно очевидно» | «Очевидно» |

### 9. Идеальная грамотность как AI-маркер

В неформальных контекстах **идеальная грамотность сама становится сигналом машинной генерации**. Живой человек, печатающий с телефона в Telegram-канале или в личном блоге, не выверяет каждую запятую и не ставит длинное тире через alt-комбинацию — он пишет дефис, иногда роняет пробел перед скобкой, иногда забывает запятую перед причастным оборотом.

LLM этого не делает. Текст AI на русском всегда:
- Идеально пунктуирован
- С правильным длинным тире там, где даже грамотные люди ставят дефис
- С пробелами по ГОСТу
- Без «тся/ться» путаницы
- Без забытых запятых даже в длинных предложениях

Эта стерильность сама по себе диагностична — особенно в каналах, где аудитория ожидает живого голоса.

#### 9.1. Идеальная пунктуация в неформальном контексте
В Telegram-каналах, личных блогах, ответах на Stack Overflow, комментариях, коротких заметках — реальные авторы регулярно пропускают:

- Запятые перед длинными причастными оборотами
- Запятые в сложных предложениях с «который» / «что» в потоке
- Точки в концах коротких реплик («Ок», «Да», «Понял»)

| Было (AI-чисто) | Стало (живой) |
|---|---|
| «Сделал, как ты сказал. Спасибо.» | «Сделал как ты сказал. Спасибо» |
| «Я думал, что это сработает, но ничего не вышло.» | «Я думал что это сработает но ничего не вышло» |
| «Это, конечно, странно.» | «Это конечно странно» |

#### 9.2. Идеальная типографика в онлайн-контенте
Длинное тире (—), правильные «ёлочки», неразрывные пробелы перед `%`, корректные `…` — всё это есть у AI и редко у живого автора в мессенджере или соцсети.

| Было (AI-чисто) | Стало (живой) |
|---|---|
| «Решил — и сделал.» | «Решил - и сделал» |
| «Согласен на 100 % с тобой.» | «Согласен на 100% с тобой» |
| «Подожди…» | «Подожди..» |
| «Сказал «привет»» | «Сказал "привет"» |

#### 9.3. Отсутствие «тся/ться» путаницы и опечаток
Разговорные тексты живых людей содержат хоть какие-то микро-огрехи: смешанная «-тся/-ться» в спешке, иногда пропущенный мягкий знак, опечатка в коротком слове. AI всегда чисто. Сильный AI-маркер для casual-формата.

#### Применение раздела 9

Этот раздел работает **только в комбинации с пресетом или флагом**, потому что он описывает паттерн «идеального текста как маркера», но не предписывает скиллу автоматически портить чужой текст.

- **Без флага `--rough`** скилл **диагностирует** излишнюю чистоту в неформальных контекстах и сообщает автору в audit-отчёте: «Для канала X (Telegram) текст слишком вылизан, рассмотрите 1-2 микро-неровности».
- **С флагом `--rough`** или при пресете с `allow_micro_imperfections: true` (по умолчанию это `telegram`) скилл активно реализует механику этого раздела — см. секцию «Намеренные неровности».

#### Чего скилл НЕ делает

- Никогда не вносит грубые орфографические ошибки.
- Никогда не путает падежи или согласования (это меняет смысл).
- Никогда не меняет имена, термины, числа, технические термины.
- Никогда не вносит более 2-3 микро-неровностей на текст в 5000 знаков.
- Никогда не применяет раздел 9 к пресетам `habr` / `vc` / `email` / `linkedin` / `docs`.

В пресетах, где идеальная грамотность ожидается аудиторией (статьи, документация, деловая переписка), правила раздела 9 **выключены** через `allow_micro_imperfections: false` в пресете.

---

## Намеренные неровности (`--rough`)

В неформальных контекстах (Telegram-канал, личный блог, соцсети) **идеальная грамотность сама становится AI-маркером**. Живой человек в мессенджере опускает запятые, ставит дефис вместо тире, иногда забывает пробел перед скобкой. Это естественное «человеческое разрешение».

### Как это работает

По умолчанию **выключено**. Скилл не вносит огрехи в чужой текст без явного запроса.

Включается одним из способов:

1. Флаг `--rough` в команде.
2. Поле в пресете `allow_micro_imperfections: true` (по умолчанию это есть только в `telegram`).
3. Параметр в паспорте `voice_features.imperfections: "allowed"`.

### Что делает скилл при `--rough`

**Сохраняет имеющиеся огрехи:**
- Если автор в исходнике пропустил запятую — оставляет.
- Если автор поставил дефис вместо тире — не меняет на тире.
- Если есть «тся/ться» в casual-контексте — не правит.

**Может вносить неровности (1-2 на текст, не больше):**
- Пропустить одну запятую перед причастным оборотом в неформальном предложении.
- Не поставить пробел перед скобкой в одном месте.
- Использовать дефис вместо тире в одном месте, где автор колебался бы.

**Никогда не вносит:**
- Грубые орфографические ошибки.
- Опечатки в именах, терминах, числах.
- Неверные падежи или согласования.
- Огрехи, меняющие смысл.

### В каких пресетах это уместно

| Пресет | Рекомендация |
|---|---|
| `telegram` | Да, явно (поднимает burstiness и снижает «AI-чистоту») |
| `habr` | Нет (модерация и техническая аудитория ждёт грамотности) |
| `vc` | Только если автор сам так пишет в образце |
| `email` | Нет |
| `linkedin` | Нет |
| `docs` | Категорически нет |

---

## Процесс работы (7 шагов)

### Шаг 1 — Контекст

Скилл определяет:

1. Есть ли `.humanizer/voice.json` в рабочей директории? Если да — читаем паспорт.
2. Передан ли явный `--preset=<имя>`? Если да — поверх паспорта применяем пресет.
3. Если ни паспорта, ни пресета — спрашиваем у пользователя или применяем дефолты `habr`.
4. Передан ли образец для калибровки? Если да — переходим к Шагу 2.

### Шаг 2 — Калибровка (если нужна)

В зависимости от уровня:

- **Уровень 1 (sample):** анализируем образец, заполняем/обновляем паспорт.
- **Уровень 2 (interview):** задаём 5-7 вопросов, собираем минимальный паспорт.
- **Уровень 3 (preset only):** используем дефолты пресета, отмечаем `calibration_mode: "preset_only"`.

Сохраняем `.humanizer/voice.json`.

### Шаг 3 — Структурный аудит (Слой 2)

Прогоняем диагностику S1-S7. Если есть критические маркеры — **сообщаем автору и спрашиваем**:

```
Структурный аудит выявил:
- 10 параллельных секций (критично)
- AI-цитаты 32% объёма (критично)
- Низкая burstiness (σ 3.1)

Эти маркеры скилл сам не правит — нужно структурное переписывание.
Хочешь:
[1] Получить только текстовые правки (Слой 1) и потом самому работать со структурой
[2] Получить чек-лист структурных правок и применить их вручную
[3] Продолжить без учёта структуры
```

При `--audit` — выдаём диагностику и останавливаемся.

### Шаг 4 — Светофорная разметка абзацев

Перед фразовым прогоном размечаем абзацы **по присутствию голоса автора** (это наша рамка, в отличие от детекторо-центричной у конкурента):

- **🟢 Зелёный** — голос автора слышен, AI-маркеров нет или мало (0-1 паттерн на абзац). **НЕ ТРОГАТЬ.** Переписывание чистого абзаца внесёт новые маркеры. Бонус: зелёные абзацы создают «mixed content», на котором классификаторы работают хуже.
- **🟡 Жёлтый** — голос частично присутствует, но AI-маркеры заглушают (1-2 голосовых элемента + 2-3 паттерна). **Точечная правка** маркеров с сохранением голосовых элементов.
- **🔴 Красный** — голос отсутствует, AI-стандарт без личных меток (0 голосовых элементов + 3+ паттернов). **Полностью переписать** в Шаге 5 + 6.

#### Как размечать

Для каждого абзаца проверить:

1. **Voice features из паспорта.** Считать вхождения:
   - Идиолект из `preferred_phrases`: 1+ вхождение → +1 voice point
   - Голосовые маркеры (ирония, риторические вопросы, личные обороты, конкретные имена/цифры) → +1 каждый
   - Авторские отступления и комментарии → +1
2. **Layer 1 паттерны** из 38 правил → подсчитать вхождения
3. **Структурные маркеры** в абзаце (parallelism, listicle entry, цепочки) → +1 каждый

**Решение:**
- voice_points ≥ 2 и patterns ≤ 1 → 🟢
- voice_points 1-2 и patterns 2-3 → 🟡
- voice_points 0 и patterns ≥ 3 → 🔴

В режиме `--audit` светофор выдаётся как часть отчёта — без правок.

### Шаг 5 — Фразовый прогон (Слой 1)

Применяем правила к 🟡 и 🔴 абзацам. 🟢 не трогаем.

Порядок применения определяется **активным пресетом** (см. «Динамические приоритеты по пресету»):

1. Сначала `always`-правила пресета — обязательная очистка.
2. Потом `context`-правила — с оговорками.
3. `ignore`-правила пропускаем.

Внутри каждой группы порядок:

1. Чатботные артефакты (5.1-5.4) — убираем сразу.
2. Штампы и пустые открытия (1.1-1.7).
3. Канцелярит, «является», «данный» (2.1-2.4).
4. Кальки, преувеличения, правило трёх (2.8-2.14, 7.* для расширенной идиоматики).
5. Морфология (6.* — падежи, деепричастия, виды, pro-drop).
6. Стилевые и типографические правки (3-4) — по паспорту/пресету.
7. Филлеры (8) — последняя зачистка.

После каждого прохода сверяемся с `preferred_phrases` / `banned_phrases` паспорта.

### Шаг 6 — Принцип жеста

После фразового прогона на 🔴 и 🟡 абзацах: пройти ещё раз и **в каждом предложении** обеспечить хотя бы один из трёх элементов:

1. **Авторский выбор слова** — там, где AI выбрал бы статистически вероятное, автор выбирает менее вероятное, но характерное. «Решение» → «лазейка», «костыль», «выход». «Эффективный» → «работающий», «годный», «не бесит».
2. **Конкретика** — точное имя, цифра, факт, дата, название инструмента. Не «многие компании», а «семь команд из десяти». Не «недавно», а «в марте».
3. **Неожиданный поворот** — оборот, который сбивает ритм AI-предсказуемости. Шутка, самокритика, контр-пример, скобка с реминисценцией.

Если предложение не содержит ни одного жеста — оно «никакое», AI-нейтральное. Кандидат на удаление или переписывание.

Это наш аналог контрастного вычитания, но через characterization (характер автора), а не через статистику. AI-предложение нейтрально по характеру; человеческое несёт следы конкретного автора.

#### Применение по светофору

- **🟢 абзац** — жесты уже есть, не трогать.
- **🟡 абзац** — проверить, что после фразовых правок жесты не пропали; усилить, если нужно.
- **🔴 абзац** — после фразовой чистки **активно добавлять** жесты, опираясь на паспорт автора (его регистр, идиолект, типичные приёмы).

Если автор есть в паспорте, выбирать жесты в его регистре. Если паспорта нет — использовать дефолты пресета.

### Шаг 7 — Финальная проверка и сохранение

Чек-лист:

- [ ] Нет ли «является» больше одного раза?
- [ ] Нет ли штампов «современной эпохи»?
- [ ] Нет ли цепочек из 3+ существительных в родительном?
- [ ] Нет ли отрицательных параллелизмов «не просто X, это Y»?
- [ ] Нет ли правила трёх с абстрактными элементами?
- [ ] Нет ли «данный / указанный / вышеупомянутый»?
- [ ] Нет ли AI-словаря (безусловно, действительно, стоит отметить...)?
- [ ] Нет ли перегруза тире в одном предложении?
- [ ] Нет ли точки с запятой в онлайн-тексте (правило 4.6)?
- [ ] Нет ли одиночных двоеточий без перечисления (правило 4.7)?
- [ ] Нет ли преувеличений без факта?
- [ ] Нет ли калек с английского?
- [ ] Нет ли чатботных артефактов?
- [ ] Соответствует ли тон паспорту/пресету?
- [ ] Соответствует ли типографика паспорту/пресету?
- [ ] Не появилось ли запрещённых оборотов из `banned_phrases`?
- [ ] Сохранены ли любимые обороты автора (`preferred_phrases`), если они были в исходнике?

Если есть нарушения — третий проход, точечный.

**После прогона:**
1. Сохраняем снапшот в `.humanizer/sessions/<YYYY-MM-DD>-<slug>.md`.
2. Увеличиваем `usage_count` в паспорте.
3. Обновляем `updated` дату.

### Что не трогать

**Не трогать:**
- Прямую речь и цитаты (даже если там AI-стиль — это чужой голос)
- Технические термины и профессиональный жаргон в контексте
- Кодовые блоки, JSON, команды
- Юридические формулировки, если это договор/политика
- Фрагменты в `context_exceptions` паспорта

**Когда нарушить правило можно:**
- Паспорт явно использует этот паттерн (его стиль)
- Это цитата или ирония
- Без этого теряется смысл (редкий случай)

---

## Полный пример

**Контекст:** канал — Habr, паспорт — `--preset=habr`, образца нет.

**До:**
> В современном мире, где технологии не стоят на месте, AI-ассистенты являются неотъемлемой частью процесса разработки, знаменуя собой важный этап в эволюции индустрии. Данные инструменты — расположенные на пересечении исследований и практики — кардинально трансформируют подходы инженеров, подчёркивая их ключевую роль в современных workflow.
>
> В своей основе ценность предложения очевидна: осуществление оптимизации процессов, улучшение качества взаимодействия, обеспечение согласованности команды. Это не просто автокомплит — это раскрытие творческого потенциала в масштабе, гарантирующее, что организации могут оставаться гибкими, предоставляя при этом бесшовный, интуитивно понятный и мощный опыт пользователям.
>
> - 💡 **Скорость:** Генерация кода значительно быстрее.
> - 🚀 **Качество:** Качество вывода было улучшено.
> - ✅ **Внедрение:** Использование продолжает расти.
>
> Несмотря на вызовы, характерные для развивающихся технологий, экосистема продолжает процветать. В заключение, будущее обещает быть светлым. Надеюсь, это было полезно!

**Структурный аудит:**

| Метрика | Значение | Норма Habr | Статус |
|---|---|---|---|
| Listicle с эмодзи | 3 пункта | 0 | МАРКЕР |
| Длинных тире | 2 | 0 | МАРКЕР |
| Чатботное закрытие | 1 («Надеюсь, помогло!») | 0 | КРИТИЧНО |
| AI-словарь | 8+ вхождений | мало | ПЕРЕГРУЗ |

**После (пресет `habr`, тон «ты», короткое тире):**
> AI-ассистенты помогают в рутине: шаблонный код, конфиги, тесты-заготовки. Хорошо работают там, где ты всё равно не хотел бы писать руками.
>
> Опасность в том, как уверенно выглядят подсказки. Я принимал код, который компилировался и проходил линтер, а через неделю замечал – он мимо задачи, потому что я перестал читать.
>
> Если относиться к этому как к автокомплиту и читать каждую строку – инструмент полезный. Если использовать, чтобы не думать – получишь баги быстрее.
>
> Страховка только одна: тесты. Без них ты судишь по ощущениям.

---

## Что скилл НЕ делает

Честное позиционирование (см. README): скилл работает на уровне **фраз и документной структуры**. Он не гарантирует прохождение статистических детекторов LLM-текста (GPTZero, Originality.ai, Хабровский НЛО и подобные классификаторы — детали реализации публично не задокументированы).

Если задача — пройти классификатор:

1. Запусти `--audit` — получи диагностику структурных маркеров.
2. Применяй чек-лист структурных правок **руками** (поломать listicle, инлайн вместо блоков AI-цитат, разнообразить ритм).
3. Только после этого делай фразовый прогон.

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

---

## Источники

- [blader/humanizer](https://github.com/blader/humanizer) — оригинальный английский скилл (MIT)
- [Wikipedia: Signs of AI writing](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) — методологическая основа

## Дополнительное чтение

Для самостоятельного изучения русской стилистики:

- [Нора Галь. «Слово живое и мёртвое»](https://ru.wikipedia.org/wiki/Слово_живое_и_мёртвое) — про канцелярит и кальки с иностранных языков
- [Максим Ильяхов, Людмила Сарычева. «Пиши, сокращай»](https://ilyahov.ru/) — школа инфостиля
- [Дитмар Розенталь. Справочник по правописанию и стилистике](https://www.rosental-book.ru/) — нормативная типография

> Авторы перечисленных книг не связаны с проектом humanizer-ru и не участвовали в его создании. Ссылки приведены исключительно в образовательных целях.

## История версий

- **0.2.0** — трёхслойная архитектура: голосовой паспорт `.humanizer/voice.json`, audit-режим (структурная диагностика), жанровые пресеты (habr/telegram/email/vc/linkedin/docs), три уровня калибровки (sample/interview/preset) с явным алгоритмом извлечения voice features, auto-evolve механизмы (sample-driven / inline-feedback / post-hoc-reflection), опт-ин на намеренные неровности (`--rough`). Добавлены морфологический раздел (раздел 6: падежи, деепричастия, виды, pro-drop) и расширенная идиоматика (раздел 7: маркетинговый/академический/корпоративный/метафорический английский). Светофорная разметка абзацев и принцип жеста как часть процесса. Динамические приоритеты по пресету (always/context/ignore). Custom presets через `.humanizer/presets/<имя>.yaml`. Сохранены все 38 фразовых правил из v0.1, добавлено 12+ новых.
- **0.1.0** — черновик, 38 паттернов, адаптация `blader/humanizer` под русский.