humanize-ai-text · git:20260819.4d0ff77 · 2026-08-19 · sha256 be09289855eb065e
humanize-ai-text git:20260819.4d0ff77A
Immutable. This exact content is served forever at /api/v1/blob/be09289855eb065e.
--- name: humanize-ai-text description: "Применять при переписывании текстов, сгенерированных LLM-агентами (отчеты, README, доки, письма, посты), в живой человеческий стиль. Триггеры - пользователь пишет «убери AI-стиль», «перепиши по-человечески», «сделай естественно», «убери воду», «не как ChatGPT», «убери LLM-штампы»; либо на входе текст с явными маркерами генерации: H2/H3 на каждый абзац, буллеты вместо прозы, штампы «в современном мире», «давайте погрузимся», избыток длинных тире, эмодзи-заголовки, обязательные «надеюсь, это поможет!». Не применять к структурированным форматам, где списки и заголовки уместны по существу: API-документация, чек-листы, табличные данные, бенчмарки, юридические документы." argument-hint: "[текст | путь к .md файлу]" allowed-tools: - Read - Write - Edit --- # /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 (аргумент целиком как текст). ## Базовый принцип Хороший человеческий текст имеет ритм, неровность и точку зрения. 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. Прогнать скрипт ```bash python scripts/humanize_scan.py <файл> # отчет, файл не меняется python scripts/humanize_scan.py <файл> --fix # плюс механические замены на месте ``` Скрипт находит и с `--fix` чинит сам: букву е с диакритикой, длинное и короткое тире, кавычки-елочки, символ многоточия. Находит, но НЕ чинит: текстовые стрелки (на их месте нужно слово по смыслу), стоп-фразы из таблиц, эмодзи-маркеры в начале строк, слишком плотные заголовки. Блоки кода и 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-документация с эндпоинтами и параметрами - структура нужна. - Чек-листы для исполнения, 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, собранным на тысячах случаев генерации в статьях. Полезная оттуда мысль: модель выбирает статистически наиболее вероятное продолжение, поэтому тяготеет к формулировке, подходящей самому широкому числу случаев - отсюда и обтекаемость, и одинаковость.