Большинство пользователей Claude работают в режиме «новый диалог на каждую задачу» и каждый раз заново описывают контекст: что за продукт, кто аудитория, какой тон. Projects снимают эту рутину: контекст описывается один раз и применяется автоматически. Разбираем, как собрать проект правильно.
Что такое проект и чем он не является
Проект в Claude — это контейнер с постоянной памятью: набор инструкций и файлов, которые модель учитывает в каждом диалоге внутри него. Формально это выглядит как папка с чатами, но смысл другой: папка ничего не знает о своём содержимом, а проект — знает.
Что проект не решает: он не делает модель умнее и не отменяет лимиты. Он убирает повторное объяснение контекста и снижает разброс в ответах между диалогами.
Как это работает внутри
Инструкции проекта подмешиваются к каждому вашему сообщению как системный контекст. Файлы проекта доступны модели для чтения — она обращается к ним, когда задача требует деталей. Диалоги при этом остаются изолированными: история одного чата не попадает в другой, общий у них только контекст проекта.
Практическое следствие: чем точнее инструкции, тем меньше уточняющих вопросов. И наоборот — расплывчатое «пиши хорошо и по делу» не даёт ничего, кроме расхода токенов.
Инструкции проекта: что писать
Рабочая структура состоит из пяти блоков. Каждый отвечает на вопрос, который иначе вам придётся повторять вручную.
| Блок | Что описываете | Пример формулировки |
|---|---|---|
| Роль | кем модель работает в этом проекте | «Ты технический редактор документации» |
| Продукт | что вы делаете и для кого | «B2B-сервис учёта для小 производств» — своими словами, кратко |
| Аудитория | кто читает результат | «Инженеры, знают предмет, не любят маркетинг» |
| Правила формата | структура и запреты | «Абзацы 3–4 предложения, без вводных, цифры сохранять» |
| Терминология | как называть вещи | «Пишем “партия”, не “батч”» |
Файлы: что грузить, а что нет
В проект стоит загружать то, к чему модель будет обращаться регулярно: документацию, бренд-гайд, прайс, шаблоны договоров, описание архитектуры. Не стоит — архивы переписки и всё «на всякий случай»: чем больше мусора, тем выше шанс, что модель зацепится за неактуальную деталь.
- Дробите большие файлы. Один документ на 200 страниц хуже пяти тематических.
- Помечайте версии в названии. «Прайс-2026-07» вместо «прайс финальный».
- Убирайте устаревшее сразу. Модель не знает, что документ отменён, если этого нет в тексте.
- Не грузите персональные данные клиентов — это вопрос не удобства, а политики обработки данных в вашей компании.
Три сценария, которые оправдывают проект
Клиентский проект. Один проект на клиента: бриф, гайд, история правок. Любой в команде открывает и получает те же формулировки, что и вы.
Кодовая база. Описание архитектуры, соглашения об именовании, стек. Модель перестаёт предлагать решения, которые не вписываются в проект.
Регулярная отчётность. Шаблон, прошлый отчёт, правила расчёта. Из сырых данных получается документ в нужном формате с первого раза.
Проекты и лимиты: честный расчёт
Инструкции и релевантные фрагменты файлов входят в контекст каждого сообщения, а значит расходуют квоту окна. Экономия при этом всё равно есть: вы не пишете вводные вручную и не проходите два-три круга правок. Но если проект разросся до сотен страниц, окно будет заканчиваться быстрее обычного — это нормальная плата за автоматический контекст.
Пять ошибок
- Инструкции вместо задачи. В инструкции — правила, в сообщении — что сделать сейчас.
- Один проект на всё. Контексты смешиваются, и модель тянет чужую терминологию.
- Файлы без чистки. Устаревший прайс страшнее отсутствия прайса.
- Оценочные требования. «Пиши живо» ничего не значит; «без вводных конструкций» значит.
- Отказ от правок. Проект — живой документ: после каждой десятой правки одного и того же переносите правило в инструкции.