/humanize-ai-text - переписывание AI-текста в живой стиль

Превращает текст с маркерами LLM-генерации (ровный ритм, лестница H2/H3, буллеты вместо прозы, дежурные вступления и заключения) в текст с человеческой интонацией, не теряя смысл, числа и термины.

Когда использовать

Триггерные фразы пользователя:

• "убери AI-стиль", "не как ChatGPT", "не как нейросеть"
• "перепиши по-человечески", "сделай естественно", "сделай живым"
• "убери воду", "убери штампы", "убери LLM-маркеры"
• "причеши текст", "оживи текст"

Автотриггер при анализе входного текста:

• Заголовки H2/H3 на каждый второй абзац в коротком документе.
• Буллеты с симметричной структурой и одинаковой длиной пунктов.
• Стоп-фразы из таблицы ниже ("в современном мире", "давайте погрузимся" и т.п.).
• Эмодзи-маркеры в начале пунктов (галочки, ракеты, стрелки).
• Дежурные "надеюсь, это поможет!" / "дайте знать, если есть вопросы!".
• Серия предложений одинаковой длины подряд (4+).

Режимы работы

Режим	Триггер	Что делает
Inline	аргумент - произвольный текст	Переписанный текст выводится в чат
File	аргумент - путь к существующему .md файлу	Результат сохраняется рядом с суффиксом -human.md
Interactive	аргумент пустой	Спросить у пользователя текст или путь
Встроенный	скил вызван другим агентом как шаг задачи	Отдать ТОЛЬКО итоговый текст

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

Алгоритм определения режима - как в /prompt-enhancer:

1. Пустой аргумент - Interactive.
2. Read удалось прочитать аргумент - File.
3. Read вернул "не найден" - Inline (аргумент целиком как текст).

Технический регистр: включен по умолчанию

Сверх поиска признаков генерации скил проверяет ТЕХНИЧЕСКИЙ РЕГИСТР. Проверка включена всегда, отключается ключом --no-technical либо словами пользователя "без проверки регистра".

Что проверяется. В техническом тексте бытовая метафора вместо действия и предмета - дефект. Не "досыпает элементы", а "добавляет N элементов в конец коллекции". Не "копит ошибки", а "накапливает список диагностик до вызова X". Не "схлопывая пробелы", а "заменяя последовательность пробелов одним". Не "ядро библиотеки", а конкретный модуль. Не "подсистемы узнают друг о друге", а "подсистема A вызывает экспортный метод подсистемы B". Так же исключаются "кладет", "забирает", "внутренняя кухня", "под капотом", "на лету", "магия", "умеет", "дружит с", "из коробки", "грабли", "ловушки", "костыль". В английском тексте - under the hood, out of the box, the heart of, knows how to, magic, seamless.

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

Где проверка НЕ применяется. Текст произвольного жанра - письмо, ответ, сообщение, эссе, поздравление - живет по своим правилам, и разговорный оборот там не дефект. Скрипт распознает такой текст по приветствию в начале и подписи в конце и сам пропускает проверку, сообщая об этом. Если жанр распознан неверно, проверка включается принудительно ключом --technical.

Приветствие засчитывается только целым словом и только в короткой строке, до 60 символов. Иначе заголовок "Приветственный экран" выключал бы проверку для всей статьи, и молча.

Границу проводить по жанру, а не по теме: письмо про устройство обмена данными остается письмом.

Список в скрипте узкий и точный. Оценочные слова ("просто", "легко", "удобно", "мощный") в него не входят: они слишком часто законны. По ним решение принимает модель проверочным вопросом выше.

Базовый принцип

Хороший человеческий текст имеет ритм, неровность и точку зрения. AI-текст ровный, симметричный, гипер-структурированный, без личной интонации. Цель скила - вернуть тексту неровность, не теряя смысл.

Жесткие правила

1. Ничего не выдумывать. В переписанном тексте не должно появиться ни одного факта, имени, числа, даты или цитаты, которых не было в исходнике. Заменить расплывчатое на конкретное можно, только если конкретика взята из источника или дана пользователем: "заметно ускорилось" станет "стало вдвое быстрее" лишь тогда, когда "вдвое" где-то сказано. Если фразе не хватает детали - спросить или написать без нее. Мнение и оценка фактами не считаются: там, где жанр допускает голос, отношение добавлять можно, новые утверждения о мире - нельзя.
2. Списки только когда элементы реально параллельны и независимы. Если соседние пункты связаны логикой ("сначала X, потому что Y, иначе Z") - это абзац, а не буллеты.
3. Заголовки только при смене темы. Не на каждые 2 абзаца. Документ из 400 слов с 6 H2 - это AI-текст, переписать в прозу с 1-2 разделами.
4. Длина предложений варьируется. Если идут 4 предложения по 15-20 слов подряд - ломать ритм. Короткое. Потом длинное, с придаточным. Потом среднее.
5. Никаких буферных вступлений и заключений. Не "В этой статье мы рассмотрим...", не "Подводя итог...". Сразу к делу, в конце - последняя содержательная мысль, без обертки.
6. Никаких финальных "надеюсь, это поможет!", "дайте знать, если есть вопросы!". Если уместен призыв к действию - он конкретный ("скажи, какой вариант - соберу пример"), а не дежурный.
7. Bold для терминов при первом введении и для реальных акцентов, не для каждой второй фразы. Если в абзаце 4+ выделения жирным - убрать половину.
8. Длинные тире лучше заменить на обычный дефис, запятую или скобки. Часто длинное тире - тоже маркер LLM-стиля. Если оставлять - то редко и осознанно, не подряд в каждом втором предложении.
9. Буква Cyrillic Letter Yo (U+0451) - тоже маркер AI или официального документа. Люди в неформальных текстах эту букву печатают редко: пишут "все", "еще", "вообще", "отчет", "нашел". Если в исходнике диакритическая "е" расставлена везде - заменить на обычную "е". Сохранять только в текстах, где это требование жанра (учебники, словари, имена собственные если автор настаивает на точном произношении).
10. Текстовые стрелки ->, =>, → - убрать. Запись через стрелку - маркер технической AI-генерации, в живом тексте так не пишут. Заменять словом по смыслу ("становится", "переходит в", "дает", "ведет к") или переписывать фразой. "складская накладная -> расходный ордер" становится "из складской накладной собирается расходный ордер". Это касается всех стрелок: ASCII -> и =>, юникод →.

Голос: где он нужен, а где вредит

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

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

Калибровка по образцу

Если пользователь дал образец своего письма (прежний пост, письмо, кусок документации), разобрать его до того, как переписывать:

1. Прочитать образец. Отметить длину предложений, лексику, чем начинаются абзацы, какая пунктуация в ходу, какие обороты повторяются, как делаются переходы.
2. Подстраиваться под эти привычки, а не просто вычищать маркеры. Не "улучшать" разговорные слова и не выравнивать намеренные странности - они и есть авторский почерк.
3. Образца нет - работать по умолчаниям этого скила.

Образец главнее правил скила. Если автор любит длинные тире и они есть в образце - оставить их с его частотой, а не вычищать по общему правилу. Совпасть с автором важнее, чем убрать признак.

Структурные антипаттерны

• Триплеты-пулемет. "Быстрый, надежный и масштабируемый". "Анализ, синтез и применение". Если в тексте 3+ триплета - сломать половину в пары или одиночные.
• Симметричные буллеты одинаковой длины. Признак шаблона. Либо переписать в прозу, либо сознательно сделать пункты разной длины и структуры.
• Эмодзи-маркеры в списках и заголовках. Удалить все, если только это не маркетинговый пост, где это сознательный выбор.
• Параллельные подзаголовки в духе "Преимущества / Недостатки / Применение / Заключение". Признак шаблона из тренировочных данных. Переписать структуру под конкретный материал.
• Перевернутая пирамида с TL;DR + повторением + резюме. Достаточно одного из трех.
• Хеджирование на каждом шагу: "может быть", "возможно", "в некоторых случаях", "как правило". Оставить только там, где есть реальная неопределенность.
• Длинные тире через предложение. Маркер ровного LLM-ритма. Заменять на запятые, скобки, точки или обычный дефис.

Что сохранять буквально

• Технические термины - не упрощать ради "человечности".
• Числа, версии, имена файлов, флаги CLI, идентификаторы - без изменений.
• Цитаты, код, команды - не трогать.
• Если в исходнике есть обоснованная структура (нумерованные шаги установки, список зависимостей, таблица параметров API) - оставить.
• Имена людей, организаций, продуктов - точно как в оригинале.

Справочники

Лежат рядом в references/, грузятся по требованию, а не каждый раз:

Файл	Когда читать
stop-phrases.md	Скрипт нашел стоп-фразу и нужно решить, чем ее заменить
language-antipatterns.md	Идет переписывание: обход глагола "быть", синонимическая карусель, ложные диапазоны, формулы-афоризмы
false-positives.md	Перед правкой: что НЕ считать признаком AI и какие приметы живого текста беречь
examples.md	Нужен образец "до и после"

Алгоритм работы

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

Шаг 1. Прогнать скрипт

Замысел подготовки текста перед проверкой - исключать области, где находка не находка, - взят из humanizer_ru/textprep.py проекта comol/Humanizer_RU (MIT, версия 0.3.0). Реализация здесь своя и решает другую задачу: тот линтер меряет читаемость русского текста вообще, а этот сканер сторожит правила набора. Пользоваться ими имеет смысл вместе: сканер обязателен и падает в сборке, линтер запускают отдельно, когда пишут длинный текст наружу.

python scripts/humanize_scan.py <файл>                    # отчет, файл не меняется
python scripts/humanize_scan.py <файл> --fix              # плюс механические замены на месте
python scripts/humanize_scan.py <файл> --genre reference  # задать жанр явно
python scripts/humanize_scan.py <файл> --json             # машиночитаемый отчет
python scripts/humanize_scan.py <файл> --no-technical     # без проверки технического регистра
python scripts/humanize_scan.py <письмо> --technical      # проверять регистр и в письме

Скрипт находит и с --fix чинит сам: букву е с диакритикой, длинное и короткое тире, кавычки-елочки, символ многоточия. Находит, но НЕ чинит: текстовые стрелки (на их месте нужно слово по смыслу), стоп-фразы из таблиц, эмодзи-маркеры в начале строк, слишком плотные заголовки и бытовые обороты вместо технических - категория [регистр].

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

Жанр	Когда	структура	регистр	остальные
reference	README, правило, SKILL.md, справочник, журнал изменений	ВЫКЛ	вкл	вкл
prose	отчет, статья, пост, эссе (по умолчанию)	вкл	вкл	вкл
letter	письмо, ответ	вкл	ВЫКЛ	вкл

Жанр берется из --genre, иначе определяется сам: сначала по пути и имени файла, затем по содержимому. README с приветствием это справочник, а не письмо - порядок именно такой.

Плотные заголовки в справочном документе уместны по существу, и до введения жанров сканер штрафовал за них всю документацию набора: из 40 правил чисто проходило НОЛЬ, а после - 22.

Часть находок снимается по области, а не по жанру. Стрелка в таблице это обозначение соответствия, слово в кавычках упоминается, а не употребляется, а адрес ссылки не проза. Все это маскируется адресно, но механическое не маскируется нигде кроме кода: запрещенный символ остается запрещенным и в таблице, и во frontmatter, потому что EDT рубит его одинаково.

Ограничение названо явно: кавычка, открытая на предыдущей строке, читается как открывающая, и в такой строке границы цитат смещаются. Абзац с цитатой, перенесенной через строку, даст находку на упоминании.

Категория [регистр] не чинится механически по определению: замена зависит от того, что код делает на самом деле. Скрипт называет найденное слово целиком и номер строки, формулировку подбирает модель.

Совпадение идет по границе слова: "копит" не находится внутри "накопитель", "умеет" - внутри "умелый". Часть записей - основы (досып, схлопыв, ловушк), они ловят любое окончание, но только с начала слова.

Блоки кода и inline-код исключены из поиска: внутри них тире и стрелка - часть синтаксиса, а метафора в комментарии к примеру кода правится вместе с примером, а не отдельно.

Код возврата 0, если находок нет. Это позволяет ставить скрипт в проверку перед коммитом.

Шаг 2. Решить, нужно ли переписывание вообще

Скрипт не нашел ничего и текст не вызывает подозрений - работа закончена. Сказать об этом и НЕ создавать выходной файл: копия, идентичная исходнику, вводит в заблуждение.

Проверить жанр по разделу "Когда НЕ применять". API-документация, чек-лист, регламент, таблица бенчмарков - там структура не дефект, и переписывать нечего.

Есть образец авторского стиля - разобрать его до правок, см. "Калибровка по образцу". Образец главнее правил этого скила.

Шаг 3. Переписать то, что осталось

Читать references/false-positives.md ДО правок: половина признаков AI встречается у аккуратного человека. Дальше по жестким правилам:

• убрать буферные вступления и дежурные заключения;
• слить связанные пункты в прозу, оставить списками только параллельное и независимое;
• сократить заголовки до числа реальных смен темы;
• сломать ровный ритм, чередуя длину предложений;
• разбить триплеты-штампы на пары и одиночные формулировки;
• заменить стрелки словом по смыслу, стоп-фразы - по таблице в references/stop-phrases.md;
• убрать эмодзи-маркеры, если жанр их не требует;
• переписать бытовые обороты из категории [регистр] на действие и предмет: что именно делается, с чем и в каком количестве. Пройти по тексту и тем же проверочным вопросом снять декоративные фразы, которых в списке скрипта нет. В произвольном жанре этот пункт не выполняется.

Тонкие приемы уровня фразы - в references/language-antipatterns.md.

Шаг 4. Проверить себя

Прогнать скрипт повторно, затем пройти чек-лист ниже и ответить на два вопроса:

• что в получившемся тексте все еще очевидно машинное?
• появился ли факт, имя, число, дата или цитата, которых не было в исходнике? Выдумка - дефект, даже если звучит человечнее расплывчатого оригинала.

Шаг 5. Отдать результат

Режим File - сохранить в <имя>-human.md рядом с исходником и сообщить путь. Режим Inline - вернуть текст в чат. Встроенный режим - отдать ТОЛЬКО текст, без разбора правок.

Чек-лист перед сдачей текста

• Вступление начинается с сути, а не с "в современном мире".
• Финал - содержательная мысль, а не "надеюсь, это поможет".
• Заголовков ровно столько, сколько реальных смен темы.
• Буллеты только для параллельных независимых пунктов.
• Длина предложений неровная.
• Нет триплетов-штампов.
• Нет стоп-фраз из таблицы выше.
• Bold на терминах и акцентах, не на каждом абзаце.
• Нет эмодзи-маркеров (если жанр их не требует).
• Нет длинных тире через предложение.
• Нет диакритической "е" (Cyrillic Letter Yo, U+0451), кроме случаев когда это требование жанра.
• Хеджирование осталось только там, где есть реальная неопределенность.
• Числа, термины, имена, код не пострадали.
• В техническом тексте нет бытовых оборотов вместо действий и предметов: по каждому глаголу и образу можно назвать метод, поле, код ошибки или измеренную величину.

Когда НЕ применять

Разделы ниже - про переписывание в живой стиль. Проверка технического регистра здесь действует наоборот: в API-документации, регламенте и отчете с метриками она нужна БОЛЬШЕ всего, а отключается только на произвольных жанрах - письме, ответе, эссе.

• API-документация с эндпоинтами и параметрами - структура нужна.
• Чек-листы для исполнения, runbook - буллеты по делу.
• Юридические и официальные документы - стиль регламентирован.
• Регламенты, инструкции по технике безопасности - формальная структура обязательна.
• Табличные данные, бенчмарки, отчеты с метриками - таблицы и заголовки уместны.
• Когда пользователь явно просит "структурируй", "оформи в виде списка", "сделай TOC".

DO / DON'T

DO:

• Сохранять смысл, числа, термины, цитаты буквально.
• Ломать ровный ритм предложений и абзацев.
• Удалять буферные вступления и дежурные заключения.
• Сводить связанные пункты в прозу, оставлять списки только для реально параллельных вещей.
• Сокращать количество заголовков до реальных смен темы.

DON'T:

• Упрощать технические термины ради "человечности".
• Менять числа, версии, имена файлов, идентификаторы.
• Добавлять разговорные элементы там, где пользователь хочет деловой регистр.
• Переделывать обоснованную структуру (API-доки, чек-листы) - сначала проверить раздел "Когда НЕ применять".
• Заменять стоп-фразы на синонимы-штампы (вместо "давайте погрузимся" писать "давайте рассмотрим").

Источник каталога признаков

Часть признаков сверена с Wikipedia:Signs of AI writing - каталогом WikiProject AI Cleanup, собранным на тысячах случаев генерации в статьях. Полезная оттуда мысль: модель выбирает статистически наиболее вероятное продолжение, поэтому тяготеет к формулировке, подходящей самому широкому числу случаев - отсюда и обтекаемость, и одинаковость.