Короче, история такая. Я сижу в AI-инструментах по 12 часов в день. Не «попробовал и ушёл», а реально работаю — пишу код, разбираю баги, делаю автоматизацию. За год накопил кучу таких штук, которые называются «скиллы» и «агенты» — это, грубо говоря, инструкции для AI: как именно ты хочешь, чтобы он что-то сделал.
Логика была железная: чем точнее опишу — тем меньше шансов, что AI напортачит. И я писал. Долго писал.
Один из моих скиллов — обработка логов ошибок. Берёт ошибки из админки, классифицирует, заводит задачи в трекере, ищет причину, чинит, закрывает. Полезная штука. Я её писал три месяца назад.
663 строки. 36 блоков с КАПСОМ: «CRITICAL REQUIREMENTS», «YOU MUST FOLLOW THESE RULES. NO EXCEPTIONS», «MANDATORY», «ALWAYS run this FIRST», «NEVER ignore errors». Каждый второй раздел начинается с приказа. Я был доволен — казалось, что закрыл все возможные сценарии.
А неделю назад OpenAI выкатил новый гайд по промтингу для GPT-5.5. И там написано прямым текстом: ребят, вы делаете не так. Чем подробнее ваши инструкции — тем хуже модель работает.
Открыл свой скилл, перечитал. Закрыл. Открыл. Посидел.
Что говорит OpenAI (по-человечески)
Если совсем коротко — пять идей:
Первая. Короткие инструкции, описывающие результат, работают лучше длинных, описывающих процесс. Не «иногда лучше». Обычно лучше.
Вторая. Не тащи старые промты в новую модель. Старые писались под старые модели, которые плохо держали контекст и нуждались в постоянных подсказках. Новые модели в подсказках уже не нуждаются.
Третья. «ВСЕГДА» и «НИКОГДА» оставляй только для того, что реально нельзя нарушать. Если ты пишешь «всегда сначала проанализируй» — модель решит сама, нужен ли анализ. Если ты пишешь «никогда не удаляй файлы без подтверждения» — это уже invariant, нарушение приведёт к катастрофе. Чувствуешь разницу?
Четвёртая. Скажи модели, когда остановиться. Иначе она будет копать вглубь даже там, где задача давно решена.
Пятая. Если результат плохой — не крути reasoning effort. Перепиши промт.
Ну ничего себе, подумал я. Большая часть моих скиллов — мимо.
Открыл свой 663-строчный шедевр и стало стыдно
Конкретно одна секция — про принципы фикса багов. 134 слова. Четыре блока с буллетами. Вот что я там понаписал тремя месяцами раньше:
«Найди корневую причину, не симптомы. Если ошибка в функции X, но причина в функции Y — чини Y. Не делай костыли, которые маскируют проблему. Спрашивай "почему это произошло?" пока не дойдёшь до настоящей причины.»
Дальше — про то, что нельзя игнорировать ошибки. Дальше — про то, что качество важнее скорости. И ещё немного про то же самое, но другими словами.
Перечитал по новым правилам OpenAI и обнаружил четыре проблемы.
Проблема первая. «Найди причину», «не симптомы», «не костыли», «не патчи» — это четыре формулировки одной и той же мысли. Я её повторил четыре раза. AI получает одну идею в четырёх вариациях и начинает её переусиливать — копать вглубь даже там, где причина очевидна.
Проблема вторая. «Качество важнее скорости» звучит круто, но это рекомендация, а не закон. Иногда быстрый патч важнее идеального решения — продакшн горит, надо хоть как-то заткнуть до утра. А я зашил это императивом.
Проблема третья. Когда фикс готов? По моему промту — никогда. «Проверь, что ещё могло сломаться» можно делать бесконечно. Модель не понимает, в какой точке остановиться. Либо недокапывает, либо перекапывает.
Проблема четвёртая, самая ироничная. Я написал «никогда не игнорируй ошибки». А в этом же скилле через две страницы — таблица из 60 паттернов, которые надо игнорировать автоматически. Промт сам себе противоречит. Бесит.
Переписал по новым правилам. Получилось 50 слов вместо 134. Без приказов. Просто описание — что значит «фикс готов» и где границы. И знаешь что? На том же тестовом баге обе модели — ChatGPT и Claude — выдали лучший результат именно по короткому варианту. Длинный вариант гнал их в overthinking: лезли чинить соседние модули, предлагали рефакторинг. Короткий — фикс по делу и стоп.
Эксперимент, который ты можешь повторить за 5 минут
Не верь мне на слово. Загугли Google Stitch — это инструмент от Google, генерирует UI по описанию. Открой и попробуй два промта на одной задаче.
Промт А, технически зажатый:
«Создай экран онбординга для AI-приложения. Карточки 16:9 с тенью. Заголовок 32 пикселя, подзаголовок 18, отступы 24. Цвета primary такой-то, secondary такой-то. Кнопка справа внизу, hover с тенью. Анимация slide-in 300мс. Иконки Lucide 24px. Прогресс-индикатор сверху, 4 шага.»
«Экран онбординга для AI-приложения. Должен ощущаться лёгким, дружелюбным, без бюрократии. Цель — чтобы новичок захотел дойти до конца за 30 секунд.»
У меня — десятки прогонов за месяц — короткий вариант почти всегда побеждает. Не потому что я плохо подобрал длинный. А потому что когда зажимаешь модель в техническую решётку с миллиметрами, она перестаёт делать дизайн. Она начинает заполнять решётку. Получается аккуратно. И мёртво.
И вот тут пикантный момент. Если ты попросишь одну модель написать промт для другой — она тебе выдаст ровно такого монстра типа А. Длинный, технический, с приказами. Потому что её саму так учили: чем точнее — тем лучше. И этот её промт другая модель потом получает — и работает по нему хуже, чем работала бы по короткому от человека.
Я теперь промты пишу руками. Серьёзно. AI-моделям делегирую исполнение, но не написание промтов. Кросс-модельная генерация ломается.
А что с Claude? Та же история
Я больше работаю в Claude, чем в ChatGPT. Полез смотреть, что про промты говорит Anthropic — это компания, которая Claude делает.
Там тон чуть другой. Anthropic не говорит «выкиньте инструкции». Anthropic говорит «используйте структуру». XML-теги, чёткое разделение между «вот данные» и «вот задача», длинные документы класть в начало, инструкции — в конец.
Но если посмотреть их примеры хороших промтов — там нет «ВСЕГДА» и «НИКОГДА». Там описание результата плюс структура. По духу — то же самое, что у OpenAI. Различие в букве: Claude любит чуть больше структуры, GPT-5.5 — чуть больше доверия модели.
Короче — да, применимо. Принцип «не зажимай модель в рамки» работает на обеих.
Где КАПС-приказы реально нужны
Чтобы ты не подумал, что я зову всё писать в три строки — это не так. Есть три категории, где императивы остаются.
Первая — там, где ошибка стоит дорого. В моём kit есть агент, который удаляет неиспользуемый код. Там написано: «КРИТИЧЕСКОЕ ПРАВИЛО БЕЗОПАСНОСТИ: НИКОГДА не удаляй файлы автоматически». Это не «как лучше», это «нарушишь — потеряешь работу без бэкапа». Императив остаётся.
Вторая — контракты с другими системами. Если AI пишет JSON-ответ для API, и схема жёстко задана — поле id всегда строка, статус из перечня — это не judgment, это технический контракт. Без императива модель будет «творчески» интерпретировать схему, и через час ты получишь 500-е на проде.
Третья — детали, которые буквально парсятся машинами. Имя файла миграции в формате YYYYMMDD_HHMMSS_описание.sql — порядок применения определяется по таймстампу. Любое отклонение, и накат на новой среде сломается. Императив — единственный надёжный способ.
Принцип, который я для себя вывел: КАПС-приказы — для invariants (нарушение = катастрофа). Не для preferences (нам так больше нравится). До этой недели я не отличал одно от другого. Теперь буду.
Что я делаю прямо сейчас
Открыл свой kit и сел чистить.
В скиллах для написания промтов уже добавил правило — не переусложняй. Когда я прошу AI сгенерировать новый скилл, она теперь не уходит в простыню инструкций.
Дальше пройдусь по самым жирным наработкам. Дзеновский скилл для написания статей — 758 строк. Тот самый process-logs — 663. Ещё пара по 400-500. Каждый — пачка КАПС-блоков и дублирующихся приказов. План — один за раз, с прогоном на реальной задаче «до и после». Не быстро, но окупится.
Где я могу быть не прав
Честно: я не учёный, я практик. Мерил «на глаз» и на одном-двух тестовых прогонах. Это не строгое исследование, это рабочее наблюдение. Если у тебя по-другому — может, ты прав. Но направление, мне кажется, очевидное: длинные промты с приказами на каждом шагу — это след времён, когда модели были тупее.
Те модели ушли. Те промты — пора.
Знаю, минусы прилетят (особенно от тех, кто только-только купил курс по prompt engineering на 100К рублей). Готов снять панамку, если у тебя реальный контр-кейс.
Критика
Звучит, наверное, как «я тут гуру, слушайте меня». Это не так. Я разбираюсь со своим кодом и пишу о том, что вижу. OpenAI — публичный гайд, можешь сам прочитать (developers.openai.com/api/docs/guides/prompt-guidance). Anthropic — открытый курс на гитхабе. Stitch — публичный сервис, эксперимент любой повторит.
Если облажаюсь и через месяц выяснится, что я неправильно понял гайд — приду и напишу пост-опровержение. Это нормальная история.
Если кратко: меньше приказов — больше доверия модели. Больше outcome — меньше процесса. И не забудь stop condition: без него модель будет копать, пока не выдохнется. Императивы — только для того, что реально нельзя нарушать.
Канал, где я редко, но по делу пишу про AI и автоматизацию — t.me/maslennikovigor. Если хочется поспорить или у тебя свой опыт — в личку @maslennikovig, отвечаю.
