Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install humanizer-rugit clone https://github.com/SergeNS-mne/humanizer-ru.gitcp humanizer-ru/SKILL.md ~/.claude/skills/humanizer-ru/SKILL.md---
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` под русский.