Якщо після переходу на нову модель відповіді стали гіршими, причина найчастіше у вашій інструкції, а не в самій моделі. OpenAI просить скорочувати промпти й файли правил під GPT-6 Astra: розлогі описи вмінь, обов'язкове читання файлів і жорсткі узгодження заважають новій моделі відповідати якісно. Нижче п'ять правил і чек-лист, що саме вирізати зі своїх файлів.
Звичка писати величезні інструкції для нейромережі застаріла. Два роки всіх вчили протилежного: опиши роль, перелічи вміння, додай чек-лист, попроси нічого не робити без підтвердження. На нових моделях цей набір починає заважати.
OpenAI радить чистити інструкції при переході на GPT-6 Astra: вузькі тригери замість описів умінь скіла, короткий кореневий файл-маршрутизатор із точковими посиланнями замість обов'язкового читання всієї документації, явні дозволи замість заборон і чіткий критерій готовності. Причина у двох ефектах: роздута інструкція з'їдає вікно контексту і провокує модель зупинитися раніше, ніж задача доведена до кінця. Механіка однакова для GPT-6 Astra, Claude Code і звичайного чату без агентів, бо всюди правила конкурують за те саме місце, що й сама задача. Найпростіша перевірка займає пів години: скоротіть промпт у кілька разів і прогоніть ту саму задачу ще раз.
Що сталося: OpenAI просить скорочувати інструкції
У блозі для розробників OpenAI вийшла нотатка про переосмислення скілів і промптів для GPT-6 Astra. Суть в одному реченні: інструкції, які накопичувалися під старі моделі, на новій працюють проти вас. Формулювання з тексту пряме: більш здібним моделям потрібно менше опіки.
Автор нотатки просить проводити ревізію скілів, файлів правил проєкту і промптів щоразу при зміні моделі. І додає неприємне: надто конкретні вказівки тепер можуть заважати там, де раніше допомагали.
Окрема думка, яку легко пропустити. GPT-6 Astra при всій своїй силі може зупинитися раніше за попередню модель. Не тому, що вона слабша. Тому що у вашій інструкції накопичилися чек-листи й вимоги спитати дозвіл, а модель чесно їх виконує і завмирає на першому пункті.
порада стосується саме переходу на нову модель. Якщо ви давно не міняли модель і все працює, зривати робочий промпт немає сенсу. Ревізія потрібна тоді, коли змінився той, хто читає ваші правила.
Коротко: слова, які знадобляться далі
Далі трапиться кілька слів з агентського жаргону. Якщо все знайоме, гортайте до першого правила.
| Термін | Що це простими словами |
|---|---|
| Скіл | Папка з інструкцією в Markdown, яку агент підвантажує сам, коли задача підходить під опис |
| Файл правил проєкту | Файл на кшталт CLAUDE.md чи AGENTS.md, який модель читає на початку сесії й тримає в пам'яті всю роботу |
| Прогресивне розкриття | Прийом, коли короткий кореневий файл відправляє агента в потрібний документ замість того, щоб вивалювати все одразу |
| Гардрейл | Правило-обмежувач на кшталт «нічого не змінюй без мого підтвердження» |
| Критерій готовності | Опис того, що вважається виконаною задачею |
Чому сильна модель гірше працює з довгою інструкцією
Тут працюють два незалежні механізми. Розрізняти їх варто, бо лікуються вони по-різному.
Два різні наслідки роздутої інструкції
- Довга інструкція
- З'їдене вікно контексту
- Менше місця під саму задачу
- Поверхнева відповідь
- Довга інструкція
- Чек-листи й вимоги спитати дозвіл
- Модель завмирає на першому пункті
- Задача недороблена
Перший збій: правила з'їдають місце під саму задачу
Вікно контексту у моделі скінченне. Усе, що ви залили туди правилами, віднімається від місця під саму задачу: під ваш текст, ваші дані, вашу історію діалогу. Роздута інструкція працює як податок, який ви платите з кожної відповіді.
Помітити це просто. Якщо модель відповідає поверхово саме на довгих задачах, а на коротких тримається добре, справа радше в об'ємі правил, ніж у складності запиту. Та сама механіка стоїть за тим, чому нейромережа забуває правила в довгому чаті.
Другий збій: модель завмирає, не дійшовши до кінця
Другий механізм інший. Модель не забуває правила, вона їх виконує. Ви написали «спитай підтвердження перед кожною зміною» — вона питає. Ви додали довгий чек-лист, і вона зупиняється після першого пункту й доповідає. Задача при цьому не доведена до кінця, а зовні це виглядає як слабка модель.
Різниця між двома збоями практична. Перший лікується скороченням об'єму: вирізати все, що модель і так знає. Другий лікується переписуванням формулювань: зняти зайві узгодження й дати явний критерій готовності.
Правило перше. Прибираємо описи вмінь моделі й лишаємо тригер
Найтовстіший шар у старих інструкціях — перелік того, що модель уміє. «Ти досвідчений редактор, ти вмієш аналізувати структуру тексту, знаходити повтори, перевіряти факти.» Нова модель усе це вміє без вашого нагадування.
Замість опису вмінь лишіть тригер: коротку відповідь на питання, коли цю інструкцію взагалі треба брати. У скіла це один-два рядки опису, за якими агент розуміє, що задача його. У промпті це перше речення, яке називає задачу.
перевірте свій промпт на речення, які описують модель, а не задачу. Якщо речення лишається правдивим для будь-якої вашої задачі, воно зайве.
Правило друге. Не змушуємо читати файли без потреби
Вимога «перед початком роботи прочитай усі файли в папці документації» колись рятувала. Тепер вона витрачає токени й плутає контекст: модель тягне у вікно десятки сторінок, з яких для задачі потрібен один абзац.
Замініть обов'язкове читання точковим посиланням. «Правила іменування лежать у файлі з конвенціями» працює краще, ніж «прочитай усе й тримай у голові», бо модель зайде туди тільки тоді, коли назви справді знадобляться.
Кореневий файл правил стає коротким маршрутизатором
Кореневий файл правил проєкту має бути маршрутизатором: коротким документом, який відправляє в потрібне місце. Назвіть у ньому, що де лежить, і лишіть посилання. Деталі нехай живуть у тих документах, куди модель зайде лише за потреби.
Такий підхід і називають прогресивним розкриттям. Кореневий файл дає карту, а вміст кімнат модель дивиться тоді, коли туди заходить.
Правило третє. Знімаємо жорсткі узгодження й розподіл ролей
Жорсткі узгодження — це рядки на кшталт «нічого не роби без мого підтвердження» чи «після кожного кроку звітуй і чекай».
Розподіл ролей — це спроба розписати модель по ролях: спочатку аналітик, потім редактор, потім критик.
Обидва прийоми новим моделям радше шкодять. Узгодження перетворюють роботу на ланцюжок зупинок. Розподіл ролей змушує модель витрачати увагу на виконання сценарію замість самої задачі.
Залишіть узгодження там, де крок справді незворотний: видалення даних, відправка листа клієнту, публікація. Скарги на те, що модель замучила уточнюючими питаннями, найчастіше приходять саме від таких рядків у профілі.
Заборони переписуємо явними дозволами
Заборона описує нескінченну множину. «Не пиши канцеляритом», «не вигадуй фактів», «не використовуй складні терміни» — модель мусить утримувати весь цей список і звіряти з ним кожне своє речення.
Дозвіл описує скінченну множину і працює як ціль. «Пиши короткими реченнями, терміни пояснюй при першій згадці, факти бери лише з наданих матеріалів» дає ту саму поведінку без постійної самоперевірки.
Правило четверте. Приклади «до і після» замість загальних вимог
Абзац загальних вимог модель розуміє приблизно. Пара конкретних прикладів знімає різночитання за два рядки.
Пиши живою мовою, уникай штампів і канцеляриту, зроби текст природним і легким для сприйняття, дотримуйся дружнього тону.
Було: «Здійснення оплати можливе після підтвердження замовлення». Стало: «Оплатити можна, коли підтвердите замовлення».
Той самий прийом працює і в інший бік. Покажіть приклад відповіді, яку ви отримувати не хочете, і одразу поряд поставте виправлений варіант.
Правило п'яте. Тестуємо коротшу версію промпту
Останнє правило найпростіше і найнеприємніше: коротшу версію треба перевірити руками. Заздалегідь опишіть критерій готовності, тобто те, що ви вважаєте виконаною задачею. Без нього ви просто не зрозумієте, яка з версій краща.
Що саме міряти, щоб зрозуміти, чи скорочення допомогло
Беріть одну реальну задачу, а не синтетичний приклад. Прогоніть її на старому й на новому промпті по кілька разів кожен, бо одна відповідь нічого не доводить.
Порівнюйте три речі: чи доведена задача до кінця, чи витриманий формат, скільки разів довелося перепитувати. Відчуття «відповідь якась краща» до уваги не беріть.
якщо коротка версія програє, не повертайте весь вирізаний текст одразу. Поверніть один фрагмент, прогоніть ще раз і подивіться, чи він і був причиною.
Приклад: промпт скоротили в рази, а відповідь стала кращою
У розборі OpenAI є показовий приклад: промпт скоротили в кілька разів, і якість відповіді при цьому зросла. Вирізали не суть задачі, а обгортку навколо неї.
| Правило | Що було в старому промпті | Що лишається після скорочення |
|---|---|---|
| Опис умінь | Перелік того, що модель уміє робити | Короткий тригер: коли брати цю інструкцію |
| Читання файлів | Вимога прочитати всю документацію перед стартом | Точкове посилання на потрібний документ |
| Узгодження | Підтвердження після кожного кроку | Підтвердження тільки на незворотних кроках |
| Формулювання вимог | Абзац загальних побажань до стилю | Пара прикладів «до і після» |
| Фініш роботи | Довгий чек-лист із пунктами на кожен випадок | Один критерій готовності |
Подивіться на праву колонку. Там немає жодного нового правила: усе, що лишилося, було й у старій версії, просто потонуло в обгортці.
Як це виглядає у звичайному чаті, без агентів і скілів
Якщо ви не працюєте з агентами, роль роздутого файлу правил у вас виконують кастомні інструкції та налаштування профілю. Механіка та сама: написане в профілі приїжджає у вікно контексту разом з кожним вашим запитом.
Перевірте свій профіль тими самими правилами. Опис того, який ви фахівець, моделі майже нічого не дає. Опис того, що вміє вона сама, не дає нічого взагалі. Натомість цінне те, чого модель знати не може: ваша сфера, формат відповіді, мова, обмеження вашого ринку.
Побічний ефект приємний. Коротший профіль легше підтримувати, і ви нарешті бачите, що саме в ньому написано. Окремий розбір того, як налаштувати ChatGPT під власний стиль, показує, які рядки в профілі справді впливають на відповідь.
Ревізія власних файлів: чек-лист на пів години
Ревізія не одноразова. Вона запускається щоразу, коли ви міняєте модель.
Ревізія інструкцій при зміні моделі
- Зміна моделі
- Відкрити свої промпти й файли правил
- Вирізати зайве
- Прогнати ту саму задачу
- Порівняти відповіді
- Порівняти відповіді
- стало гіршеПовернути одне вирізане обмеження
- Прогнати ту саму задачу
- Порівняти відповіді
- стало кращеЗберегти коротку версію
Зібрати свої інструкції≈ 5 хв
- промпти, якими користуєтесь щодня
- файли правил проєкту
- кастомні інструкції в профілі
Вирізати опіку≈ 10 хв
- описи вмінь моделі
- вимоги прочитати всі файли
- узгодження на кожному кроці
- розподіл ролей
Переписати заборони≈ 5 хв
- кожне «не роби X» замінити на «роби Y»
- лишити один критерій готовності
Прогнати ту саму задачу≈ 5 хв
- стара й нова версія промпту, по кілька прогонів кожна
Порівняти результат≈ 5 хв
- доведена до кінця
- формат витриманий
- кількість перепитувань
Якщо після скорочення стало гірше, повертайте вирізане по одному фрагменту. Так ви знайдете рядок, який справді тримав якість, і не відкотите заразом усе інше.
Де ця порада ламається
Скорочувати можна не все. Є речі, яких модель знати не може, і вони лишаються в промпті, навіть якщо від цього він довший.
Що зробити з цим рядком вашої інструкції?
- Опис умінь моделіВирізати: вона і так знає, що вміє робити
- Вимога прочитати всі файлиЗамінити точковим посиланням на потрібний документ
- Заборона «не роби X»Переписати явним дозволом: назвати, що робити можна
- Узгодження на кожному кроціКрок незворотний?
- Таклишити одне узгодження
- Нізняти
- Розподіл ролей у промптіВирізати: новій моделі це радше шкодить
- Приклад «до і після»Лишити: працює краще за абзац загальних вимог
- Критерій готовностіЛишити: без нього модель не знає, де фініш
- Юридичне, фінансове чи безпекове обмеженняЛишити: тут скорочення ламає результат
Це ваші дані й доменні факти, вимоги до формату результату, юридичні та фінансові обмеження вашого ринку, правила безпеки й доступу. Гардрейл на незворотній дії теж лишається: зайве підтвердження перед видаленням коштує дешевше, ніж акуратно скорочена інструкція і втрачені дані.
Друга межа стосується задач з високою ціною помилки. Там, де перевірка коштує дорожче за зайвий абзац у промпті, чек-лист залишайте. Порада про менше опіки написана для типової роботи, а не для випадків, коли модель ухвалює рішення без людини.
І остання річ, про яку легко забути. Ревізія має сенс разом зі зміною моделі. Якщо ви скоротили промпт і залишилися на старій моделі, результат може просісти: стара модель опіку любила.