Humanize AI Text

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

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

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

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

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

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

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

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

Встроенный режим - когда результат идет дальше в чужую работу: описание 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/, грузятся по требованию, а не каждый раз:

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

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

Шаг 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 чинит сам: букву е с диакритикой, длинное и короткое тире, кавычки-елочки, символ многоточия. Находит, но НЕ чинит: текстовые стрелки (на их месте нужно слово по смыслу), стоп-фразы из таблиц, эмодзи-маркеры в начале строк, слишком плотные заголовки и бытовые обороты вместо технических - категория [регистр].

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

Жанр берется из --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, собранным на тысячах случаев генерации в статьях. Полезная оттуда мысль: модель выбирает статистически наиболее вероятное продолжение, поэтому тяготеет к формулировке, подходящей самому широкому числу случаев - отсюда и обтекаемость, и одинаковость.