Я вже писав про те, як краще промптувати нове покоління моделей Claude 5 та працювати з ними ітеративно, щоб визначити, що саме ви хочете створити.
Але коли ви надсилаєте повідомлення Claude, промпт — це лише невелика частина контексту, який він отримує. Більша частина вашого контексту збирається з системного промпту, навичок (Skills), файлів CLAUDE.md, пам'яті та інших джерел. Ми називаємо це контекстною інженерією, і вона суттєво впливає на результати, які ви отримуєте під час роботи з Claude Code або створення власних агентів.
На відміну від промпту, контекст використовується загалом для багатьох запитів, тому він не може бути таким конкретним. Як створювати ці загальні промпти та інструкції для Claude, особливо коли ви не знаєте, яким може бути промпт користувача?
Це може бути напрочуд складно, оскільки власні можливості Claude постійно розвиваються. Нещодавно ми помітили значний стрибок у тому, як ми промптуємо нове покоління моделей Claude. Ми видалили понад 80% системного промпту Claude Code для таких моделей, як Claude Opus 5 та Claude Fable 5, без жодних вимірюваних втрат у наших оцінках кодування.
Ось що ми дізналися про промптування цього нового класу моделей і як ви можете використати це для оновлення вашої контекстної інженерії. Ми включили ці найкращі практики в claude doctor — використовуйте команду /doctor у Claude Code, щоб оптимізувати ваші навички та файли CLAUDE.md.
Розгальмовування Claude
Загалом ми виявили, що надмірно обмежували Claude Code, як через наш системний промпт, так і через файли CLAUDE.md та навички.
Наприклад, коли ми читали транскрипти власного внутрішнього використання Claude Code, ми бачили кілька суперечливих повідомлень в одному запиті, як-от: «залишайте документацію там, де це доречно» або «НЕ додавайте коментарі», оскільки наш системний промпт, навички та запити користувачів суперечать один одному.
Загалом Claude може інтерпретувати наміри користувача, щоб знайти правильну відповідь, але йому доводиться ретельніше обмірковувати ці перекриття та суперечливі повідомлення, перш ніж вирішити, що робити.
І хоча колись ці обмеження були потрібні, щоб уникнути найгірших сценаріїв, тепер ми виявили, що можемо видалити багато з них і дозволити моделі використовувати навколишній контекст і власне судження.
Крім того, тепер Claude Code має набагато більше інструментів. Раніше Claude покладався на CLAUDE.md як на джерело пам'яті, інформації та інструкцій. Тепер у нас є пам'ять, артефакти та навички, які Claude може використовувати для створення нових способів завантаження та обміну контекстом між сесіями.
Тоді й тепер
Існувало кілька попередніх найкращих практик контекстної інженерії, які стали міфами. Серед них:
**
Тоді: Давати Claude правила
Тепер: Дозволити Claude використовувати судження
Коли ми вперше запустили Claude Code, нам потрібно було бути впевненими, що Claude уникає найгірших сценаріїв, наприклад, видалення файлів. Це означало, що ми давали дуже жорсткі інструкції, які не завжди могли бути правильними. Наприклад, у системному промпті ми раніше говорили:
У коді: за замовчуванням не пишіть коментарів. Ніколи не пишіть багатоабзацних докстрінгів або багаторядкових блоків коментарів — максимум один короткий рядок. Не створюйте документи з плануванням, рішеннями чи аналізом, якщо користувач не просить про це — працюйте з контексту розмови, а не з проміжних файлів.
Але для певної підмножини промптів ці інструкції були б неправильними. У випадку з документацією користувач може мати власні вподобання, або певні частини дуже складного коду можуть потребувати багаторядкових блоків коментарів.
Тим не менш, без цих запобіжників для старіших моделей коментарі, які писав Claude, у багатьох випадках були б неправильними, і нам доводилося миритися з цим компромісом. Але новіші моделі мають краще судження і можуть добре впоратися з цими рішеннями без явних правил.
У новому системному промпті ми говоримо: Пишіть код, який читається, як навколишній код: відповідайте його щільності коментарів, іменуванню та стилю.
Тоді: Давати Claude приклади
Тепер: Проєктувати інтерфейси
Найголовнішим правилом використання інструментів було давати Claude приклади їх використання. З нашими новітніми моделями ми виявили, що надання прикладів насправді обмежує їх певним простором досліджень.
Замість використання прикладів, подумайте більше про дизайн ваших інструментів, скриптів і файлів — які параметри має Claude і як вони можуть бути більш виразними?
Наприклад, у прикладі інструменту Todo, простий перелік статусу як переліку між pending, in_progress та completed натякає Claude, як його використовувати. Інструкція тримати один елемент у статусі in_progress допомагає визначити бажану поведінку.
Тоді: Розміщувати все на початку
Тепер: Використовувати прогресивне розкриття
Оскільки Claude Code був зосереджений на кодуванні, наш системний промпт включав детальну інформацію про те, як проводити рев'ю коду та верифікацію. Вони були потрібні не завжди, але коли були потрібні, це була критично важлива інформація.
З тих пір Claude Code став дуже вправним у використанні прогресивного розкриття — завантаженні правильного контексту в потрібний час. Наприклад, ми перенесли верифікацію та рев'ю коду в окремі навички, які Claude Code міг вибірково викликати.
Але прогресивне розкриття стосується не лише навичок, ми використовуємо його і для інструментів. Деякі наші інструменти мають «відкладене завантаження», що означає, що агент повинен знайти їхні повні визначення за допомогою ToolSearch перед використанням. Це дозволяє нам мати більше інструментів (наприклад, наші інструменти Task), які не займають контекст, доки вони не знадобляться.
Те саме можна застосувати до ваших власних файлів CLAUDE.md та Skill.md. Поширений міф полягає в тому, що ви хочете зробити їх центральним сховищем для всіх відомих практик, які вам можуть знадобитися, тому що інакше Claude їх не знайде. Натомість розгляньте можливість створення дерева файлів, які можна завантажувати в потрібний час.
Тоді: Повторювати себе
Тепер: Прості описи інструментів
Раніші моделі Claude іноді потребували повторюваних інструкцій або частіше слухалися інструкцій у кінці вікна контексту, ніж на початку. Це означало, що наш системний промпт іноді містив посилання на інструменти в основному системному промпті, а також інструкції в описі інструменту.
Ми виявили, що можемо видалити ці повторювані приклади та розмістити інструкції щодо використання інструментів у описах інструментів, а не в системному промпті.
Тоді: Пам'ять у файлах CLAUDE.md
Тепер: Автоматична пам'ять
Раніше ми заохочували користувачів зберігати речі в пам'яті Claude, використовуючи гарячу клавішу # для автоматичного запису в CLAUDE.md. Натомість тепер Claude автоматично зберігає спогади, які є релевантними для роботи та для вас.
Тоді: Прості специфікації
Тепер: Багаті посилання
У режимі планування Claude Code значною мірою покладався на файли markdown з планами. Зберігання цих файлів як планів допомагало Claude посилатися на них, коли це було потрібно. Іншою подібною найкращою практикою було зберігати специфікації в коді, щоб Claude міг на них посилатися під час роботи над довшими проєктами.
Але ми виявили, що Claude може працювати з дедалі складнішими посиланнями. Замість простих файлів markdown, Claude може посилатися на HTML-артефакти, створені нашою новою функцією артефактів.
Ви також можете давати Claude посилання у формі коду. Специфікація також може бути детальним тестовим набором або функцією в іншій кодовій базі, яку Claude може портувати.
Рубрики — це ще одна форма посилань. Рубрики дозволяють Claude спробувати перевірити ваш смак у певній галузі (наприклад, як виглядає хороший дизайн API), використовуючи динамічні робочі процеси та запускаючи агенти-верифікатори з цими рубриками.
Застосування цього до вашого контексту
Збираючи все це докупи, як це виглядає, коли ви формуєте свій контекст?
Системний промпт
Системний промпт тісно пов'язаний з контекстом продукту. Він повідомляє Claude, у якому продукті він працює і що робить. Для Claude Code ви, швидше за все, ніколи не будете його змінювати, але якщо ви створюєте власну оболонку агента, це те, на що варто витратити багато часу.
CLAUDE.md
Тримайте ваш CLAUDE.md легким і коротко описуйте, для чого призначений ваш репозиторій, але витрачайте більшість токенів на «підводні камені» всередині кодової бази. Наприклад, ви можете організувати свій код так, щоб зберігати типи в одному монолітному файлі і більше ніде. Уникайте опису «очевидних» речей, які Claude повинен знати, переглядаючи вашу файлову систему або репозиторій.
Використовуйте прогресивне розкриття для більш детальної інформації. Наприклад, якщо у вас є кілька унікальних інструкцій щодо перевірки вашої роботи, створіть навичку верифікації та посилайтеся на неї з вашого CLAUDE.md.
Навички (Skills)
Сприймайте навички як легкі інструкції, які дозволяють Claude знаходити інформацію, коли це потрібно. Уникайте робити їх надмірно обмеженими, за винятком дуже важливих сфер.
Для довгих навичок намагайтеся використовувати прогресивне розкриття якомога більше — розділіть їх на багато файлів і розподіліть.
Найкраще, коли навички кодують певні думки, знання або найкращі практики, які є специфічними для вас, вашої команди або продукту.
Посилання
Ви можете використовувати @ для згадування файлів, щоб включити їх як посилання. Посилання дозволяють Claude звертатися до поглибленої інформації про поточний план.
Це можуть бути файли специфікацій, макети або навіть цілі кодові бази. Загалом варто віддавати перевагу файлам, які є кодом, оскільки вони надають чіткі високоточні інструкції Claude мовою, яку він дуже добре знає. Наприклад, HTML-макет дизайну зазвичай дасть кращі результати, ніж опис дизайну або скріншот.
Спробуйте спростити
Перегляньте ваш системний промпт, навички та файли CLAUDE.md — можливо, вам також потрібно спростити, як це зробили ми. Ми запустили нову команду під назвою claude doctor, яка допоможе вам зробити це автоматично. Щоб дізнатися більше про промптування більш просунутих моделей, перегляньте наш польовий посібник з Fable.
