# Humanize AI Text > Применять при переписывании текстов, сгенерированных LLM-агентами (отчеты, README, доки, письма, посты), в живой человеческий стиль. Триггеры - пользователь пишет 'убери AI-стиль', 'перепиши по-человечески', 'сделай естественно', 'убери воду', 'не как ChatGPT', 'убери LLM-штампы'; либо на входе текст с явными маркерами генерации: H2/H3 на каждый абзац, буллеты вместо прозы, штампы 'в современном мире', 'давайте погрузимся', избыток длинных тире, эмодзи-заголовки, обязательные 'надеюсь, это поможет!'. Сверх того ВСЕГДА проверяет технический регистр: в README, журнале изменений, документации и описаниях заменяет бытовую метафору на действие и предмет ('досыпает', 'кладет', 'копит', 'под капотом', 'из коробки', 'ядро библиотеки'); в письме, ответе и эссе эта проверка сама выключается по жанру, ключ отключения - --no-technical. Переписывание в живой стиль не применять к структурированным форматам, где списки и заголовки уместны по существу: API-документация, чек-листы, табличные данные, бенчмарки, юридические док - Skill: `desko77/humanize-ai-text` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add desko77/humanize-ai-text` - Raw SKILL.md: https://api.skillmd.com/api/skills/desko77/humanize-ai-text/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Desko77 (https://skillmd.com/u/desko77) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/desko77/humanize-ai-text --- # /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](https://github.com/comol/Humanizer_RU) (MIT, версия 0.3.0). Реализация здесь своя и решает другую задачу: тот линтер меряет читаемость русского текста вообще, а этот сканер сторожит правила набора. Пользоваться ими имеет смысл вместе: сканер обязателен и падает в сборке, линтер запускают отдельно, когда пишут длинный текст наружу. ```bash 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](https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing) - каталогом WikiProject AI Cleanup, собранным на тысячах случаев генерации в статьях. Полезная оттуда мысль: модель выбирает статистически наиболее вероятное продолжение, поэтому тяготеет к формулировке, подходящей самому широкому числу случаев - отсюда и обтекаемость, и одинаковость.