Коли YouTube‑креатор і консультант з продуктивності Джефф Су вирішив буквально «поставити життя на Claude Cowork», це не була метафора. Понад п’ять місяців він щодня керував через Cowork і бізнесом, і особистими справами — аж до того, що, за його словами, «заліз у борги за токени». Такий режим швидко виявив слабке місце: неправильно спроєктований кореневий файл інструкцій CLAUDE.md тихо спалює гроші й погіршує якість відповідей.
З цього досвіду народилося кілька практичних правил, головне з яких — так зване «правило 300 рядків». Воно перетворює CLAUDE.md з безформного звалища інструкцій на компактний, керований «операційний маніфест» для Claude Cowork, який завантажується щоразу, коли ви відкриваєте workspace.
Чому саме CLAUDE.md вирішує, скільки ви платите за AI
Архітектура Claude Cowork побудована навколо markdown‑файлів. Інструкції для моделі й довгострокова пам’ять зберігаються в таких файлах, як CLAUDE.md та MEMORY.md. Кожен раз, коли користувач запускає сесію в Cowork, кореневий CLAUDE.md підтягується в контекст — разом з усіма своїми рядками, правилами, ремарками й історичними артефактами, які ви колись ліньки було прибрати.
Це означає дві речі.
По‑перше, будь-який зайвий текст у CLAUDE.md автоматично конвертується в зайві токени. Коли файл розростається до сотень рядків, кожна сесія стає дорожчою, навіть якщо ви ставите моделі просте запитання.
По‑друге, надмірний обсяг інструкцій розмиває фокус моделі. Claude має одночасно «тримати в голові» всі правила, уточнення й винятки, які ви туди записали. Чим більше шуму, тим вищий ризик, що важливі вказівки загубляться серед другорядних деталей.
Су відчув це на власному гаманці. Його кореневий CLAUDE.md розрісся більш ніж до 600 рядків. Після радикальної «дієти» — скорочення до приблизно 250 рядків — загальне споживання токенів впало орієнтовно на 25%. Це не теоретична оптимізація, а прямий, вимірюваний ефект: менше тексту в базовому файлі — менше грошей за кожну взаємодію з Cowork.
Саме тому він формулює жорстке, але просте правило: кореневий CLAUDE.md має залишатися в діапазоні 200–250 рядків, а 300 рядків — це абсолютна стеля, яку не можна піднімати.
Правило 300 рядків: не просто про економію, а про ясність
На перший погляд, обмеження в 300 рядків здається довільним. Але в контексті Cowork воно виконує одразу кілька функцій.
Передусім це дисципліна. Коли є чітка межа, кожен новий пункт у CLAUDE.md змушує замислитися: чи справді ця інструкція потрібна в кожній сесії? Чи це щось, що можна завантажувати лише за потреби? Су пропонує простий тест: якщо правило не потрібне щоразу, коли ви відкриваєте Cowork, йому не місце в кореневому файлі.
Далі — передбачуваність вартості. Оскільки CLAUDE.md завжди завантажується повністю, його розмір фактично задає «базову ставку» токенів на кожну сесію. Тримати файл у межах 200–250 рядків означає мати стабільний, контрольований мінімальний чек, незалежно від того, наскільки складним буде конкретний запит.
Нарешті, компактний CLAUDE.md допомагає самій моделі. Замість того щоб розбиратися в хаотичній суміші правил, історичних нотаток і напівзабутих експериментів, Claude отримує чіткий набір актуальних інструкцій, які описують, як поводитися, що пам’ятати й куди звертатися за деталями. Це зменшує когнітивне навантаження моделі й підвищує стабільність відповідей.
Су демонструє це на власному прикладі: скорочення з 600+ до ~250 рядків не лише зменшило витрати на токени, а й зробило Cowork більш керованим. Коли кореневий файл стає «легким», будь-які зміни в поведінці моделі легше відстежити й пояснити — вони більше не губляться в гігантському масиві суперечливих вказівок.
Шість розділів, що тримають Cowork під контролем
Щоб утримати CLAUDE.md в межах 300 рядків і водночас не втратити функціональність, Су структурував свій шаблон у шість чітких розділів. Кожен із них відповідає за окремий аспект поведінки Cowork і допомагає уникнути дублювання або хаосу.
Перший розділ — система пам’яті. Тут описано, як Cowork має працювати з MEMORY.md. Ключова інструкція: на початку кожної сесії Claude повинен завжди читати MEMORY.md. Це гарантує, що модель одразу підтягує контекст попередніх дій, активних проєктів і важливих фактів, не покладаючись лише на історію чату. Така явна вказівка перетворює MEMORY.md на офіційне джерело правди про поточний стан справ, а не на випадковий склад нотаток.
Другий розділ — уподобання. Тут задається стиль комунікації: тон, довжина відповідей, формат. Саме в цьому блоці можна визначити, наскільки формально має писати Claude, чи потрібні розгорнуті пояснення чи радше стислі резюме, як оформлювати списки, заголовки, підсумки. Замість того щоб повторювати ці вимоги в кожному запиті, користувач один раз формулює їх у CLAUDE.md, і модель застосовує їх за замовчуванням.
Третій розділ — правила. Це набір поведінкових «рейок», які визначають, що Cowork повинен завжди робити, а чого ніколи не робити. Сюди потрапляють інструкції на кшталт «завжди ставити уточнювальні запитання перед початком складного завдання» або «ніколи не редагувати файли в workspace без пояснення, що саме змінено і чому». Ці правила не описують факти чи контекст, вони задають етичні й операційні межі, в яких має працювати модель.
Четвертий розділ — routing map. Це таблиця, яка відповідає за «маршрутизацію» завдань усередині Cowork. Коли користувач просить написати листа, система має зрозуміти, що слід активувати workstation Email HQ. Якщо мова йде про китайські проєкти, в роботу вступає China Desk. Для брейнштормінгу — Clarity Partner. Routing map перетворює розрізнені робочі середовища на узгоджену систему, де кожен тип задачі автоматично потрапляє до правильного «відділу».
П’ятий розділ — references. Це, по суті, каталог посилань на додаткові файли, які Cowork завантажує лише за потреби. Кожен запис — це однорядковий покажчик: назва файлу й коротке пояснення, коли його слід читати. Наприклад, файл voice_principles.md, який описує детальні принципи тону та стилю контенту, не завантажується в кожній сесії. Він підтягується лише тоді, коли користувач працює над текстами, де ці нюанси мають значення. Такий підхід дозволяє винести об’ємні довідкові матеріали за межі CLAUDE.md, не втрачаючи до них доступу.
Шостий розділ — створення нових workstations. Тут описано, як саме Cowork має генерувати нові робочі середовища всередині workspace: які файли створювати, як їх структурувати, які правила наслідувати. Це важливий блок для масштабування системи, але він не потрібен у кожній сесії. Су показує, як цей розділ можна винести в окремий reference‑файл і залишити в CLAUDE.md лише короткий вказівник, тим самим зменшивши розмір кореневого файлу без втрати функціоналу.
Разом ці шість розділів утворюють каркас, який дозволяє тримати CLAUDE.md компактним, але повноцінним. Кожен блок має чітке призначення, а все, що не вписується в цю структуру, автоматично стає кандидатом на винесення в окремий файл.
Система пам’яті та уподобань: як навчити Claude пам’ятати головне й говорити по‑людськи
Окремої уваги заслуговують два перші розділи — система пам’яті та уподобання. Вони визначають, як Cowork сприймає час і як звучить у взаємодії з користувачем.
У системі пам’яті ключовою є інструкція завжди читати MEMORY.md на старті сесії. Це не просто технічна деталь. Такий підхід розмежовує «вічні» правила (у CLAUDE.md) і змінні факти (у MEMORY.md). Наприклад, фраза «моя компанія використовує Microsoft Copilot» — це факт, який може змінитися завтра. Він не повинен жити в CLAUDE.md, де зберігаються стабільні поведінкові інструкції. Натомість йому місце в MEMORY.md, який описує поточний стан речей.
Су пропонує навіть формалізувати це у вигляді тестів. Якщо запис є приписом і містить слова «завжди» або «ніколи», це правило йому місце в CLAUDE.md. Якщо ж він описує факт або статус, який потенційно може змінитися, він має жити в MEMORY.md. Така розмежувальна лінія допомагає уникнути типового хаосу, коли користувачі плутають, куди записувати що, і в результаті отримують або перевантажений CLAUDE.md, або неструктуровану пам’ять.
Уподобання, своєю чергою, відповідають за «людське обличчя» моделі. Тут можна задати, наприклад, чи має Claude відповідати розмовно чи формально, чи потрібні йому жарти, наскільки детально він має розписувати кроки, чи варто завжди додавати короткий підсумок наприкінці відповіді. Су демонструє, як легко змінити ці параметри, редагуючи відповідний блок у CLAUDE.md через markdown‑редактор: достатньо замінити один рядок у розділі preferences — і модель починає говорити інакше в усіх наступних сесіях.
Ці два розділи працюють у парі. Система пам’яті забезпечує, щоб Claude завжди був у курсі того, над чим ви працюєте й які факти залишаються актуальними. Уподобання гарантують, що, маючи цей контекст, модель спілкуватиметься з вами в комфортний спосіб. Разом вони перетворюють Cowork із абстрактного інструмента на персоналізованого асистента, який пам’ятає важливе й говорить «вашою мовою».
Правила, MECE‑принцип і керована складність
Розділ правил у CLAUDE.md — це місце, де користувач задає поведінкові обмеження для Cowork. Але коли таких правил стає багато, виникає ризик суперечностей і дублювань. Щоб цього уникнути, Су вбудував у свій кореневий файл ще один, метарівень управління — принцип MECE.
У його CLAUDE.md є окремий пункт «governance MECE principle», який формулює вимогу: усі інструкції й правила в workspace мають бути взаємовиключними (mutually exclusive) й разом вичерпними (collectively exhaustive). Інакше кажучи, правила не повинні перекривати одне одного, але в сукупності мають покривати весь простір ситуацій, для яких вони призначені.
Це не просто красива фраза. Такий принцип задає стандарт для всієї подальшої еволюції workspace. Коли користувач додає нове правило, він має перевірити, чи не дублює воно вже існуюче, чи не суперечить йому, і чи не залишає «білих плям» у поведінці моделі. Саме тому цей MECE‑принцип Су залишає в кореневому CLAUDE.md, а не виносить у довідкові файли: він стосується всієї системи й має застосовуватися завжди.
Поруч із цим принципом живуть і більш прикладні правила. Наприклад, інструкція «перед тим як писати новий лист, перевір, чи існує пов’язаний тред із цим адресатом» — це типовий приклад поведінкового правила «перед X завжди роби Y». Воно не описує факт, а задає послідовність дій, тому йому місце саме в CLAUDE.md, а не в MEMORY.md.
Разом із routing map і references цей розділ формує «операційну конституцію» Cowork. MECE‑принцип не дозволяє їй перетворитися на хаотичний набір випадкових вказівок, а чіткі поведінкові правила гарантують, що модель діятиме послідовно в повторюваних сценаріях.
Lean‑дизайн як стратегія, а не разова чистка
Ключова ідея, яку просуває Су, полягає в тому, що оптимізація CLAUDE.md — це не одноразове «прибирання», а постійна стратегія lean‑дизайну workspace. Правило 300 рядків змушує мислити категоріями «що справді потрібно завжди», а що можна винести в окремі файли й завантажувати за запитом.
Саме тому в його шаблоні з’являється розділ references з однорядковими покажчиками на додаткові файли, а такі блоки, як «створення нових workstations», переносяться в окремі markdown‑документи. Детальні правила створення файлів теж не залишаються в CLAUDE.md у вигляді довгого списку з 22 пунктів — натомість у кореневому файлі залишається лише коротка вказівка «прочитай це перед створенням нового файлу», а самі правила живуть у спеціальному reference‑файлі.
Цей підхід дозволяє одночасно зберігати глибину налаштувань і тримати базовий контекст легким. Cowork завжди стартує з компактного набору ключових інструкцій, але за потреби може «пірнути глибше», підвантаживши додаткові правила чи довідкові матеріали.
Су навіть автоматизує частину цієї роботи, доручаючи самому Cowork аналізувати CLAUDE.md і MEMORY.md на предмет неправильних записів. Модель може проходитися по файлах, позначати пункти, які радше описують факти, ніж правила, або навпаки, і пропонувати, куди їх перемістити. Таким чином, система поступово самоочищається, а користувачеві залишається лише підтверджувати зміни.
Результат — workspace, який не розвалюється під вагою власної історії. Навіть після місяців або років активного використання кореневий CLAUDE.md залишається компактним, структурованим і зрозумілим, а витрати на токени — прогнозованими.
Висновок: CLAUDE.md як головний важіль керування Cowork
Досвід Джеффа Су з Claude Cowork показує, що справжня потужність цього інструмента розкривається не стільки в окремих промптах, скільки в архітектурі workspace. Кореневий файл CLAUDE.md, який завантажується в кожній сесії, фактично є операційною системою вашого AI‑асистента. Від того, наскільки він компактний, структурований і логічний, залежить і вартість, і якість роботи Cowork.
Правило 300 рядків, шість чітко визначених розділів, явна система пам’яті, блок уподобань, поведінкові правила з MECE‑принципом, routing map і references — усе це елементи одного підходу: тримати базовий контекст легким, а деталі — доступними за запитом.
У світі, де великі мовні моделі стають невід’ємною частиною щоденної роботи, така «гігієна контексту» може виявитися не менш важливою, ніж вибір самої моделі. І якщо досвід Су з падінням витрат на токени на чверть після «схуднення» CLAUDE.md щось демонструє, то це те, що добре спроєктований markdown‑файл іноді цінніший за ще один «чарівний промпт».
Джерело
YouTube: Top 5 Claude Cowork Tips I Wish I Knew from Day One