Проекты: контекст, который не нужно повторять

Если вы работаете с Claude больше недели, вы наверняка замечали, что каждый чат начинается с одного и того же: «мы делаем приложение для..., аудитория..., используем такой-то стек...». Проекты убирают это повторение. К концу урока вы будете уметь собрать проект под рабочую задачу, написать для него инструкции и понимать, где кончается проект и начинается память.

Что такое проект

Проект — это контейнер, в котором живут три вещи:

1. Чаты. Все разговоры, начатые внутри проекта, собраны в одном месте.
2. Знания проекта. Документы, тексты, фрагменты кода, которые вы загрузили. Claude видит их в каждом чате проекта, не нужно прикладывать заново.
3. Инструкции. Текст, который применяется к каждому разговору: кто вы, как отвечать, каких правил придерживаться.

Механика простая: при каждом сообщении внутри проекта модель получает ваш запрос вместе с инструкциями и содержимым знаний. Именно поэтому она «помнит» контекст — он приходит с каждым сообщением, а не хранится в модели.

Проекты доступны на всех планах, включая бесплатный (с ограничением на количество). На командных и корпоративных планах их можно делить с коллегами.

Что положить в знания проекта

Знания — это то, что вы сказали бы новому человеку в команде в первый день, оформленное файлами. Хорошие кандидаты:

• Описание продукта и аудитории, бриф, концепция.
• Техническое задание или его актуальная версия.
• Глоссарий: как в проекте называют сущности («заявка», а не «лид»; «партнёр», а не «продавец»).
• Гайдлайны: тон коммуникации, дизайн-система, соглашения по коду.
• Примеры эталонных документов: хороший баг-репорт, хорошее ТЗ на экран, хорошее письмо клиенту.
• Список участников и ролей (без личных данных).

Чего класть не стоит: всё подряд. Знания подаются модели целиком при каждом сообщении, и чем их больше, тем меньше внимания достаётся вашему конкретному вопросу. Когда объём знаний приближается к пределу, на платных планах включается режим поиска по знаниям (RAG): модель получает не всё, а только фрагменты, релевантные запросу. Это работает, но менее предсказуемо, чем полный контекст. Правило: лучше три актуальных документа, чем тридцать разной свежести.

Отдельно про актуальность. Знания не обновляются сами. Если ТЗ поменялось, файл в проекте надо заменить. Заведите привычку: изменилось что-то важное — обновили проект.

Как писать инструкции

Инструкции проекта — это постоянная часть каждого запроса. Они отвечают на вопросы: кто вы, для кого результат, в каком формате отвечать, чего избегать. Вот пример для проекта аналитика:

Ты помогаешь бизнес-аналитику Amiga на проекте мобильного приложения
для сети автосервисов. Аудитория продукта — владельцы автомобилей,
которые записываются на обслуживание.

Правила:
- Юзер-стори — в формате «Как <роль>, я хочу <действие>, чтобы <ценность>»,
  к каждой — критерии приёмки в формате Given/When/Then.
- Термины бери из глоссария в знаниях проекта. Если термина нет — предложи
  и пометь как новый.
- Если в запросе не хватает данных, сначала задай вопросы, потом пиши.
- Не придумывай числа, сроки и названия функций, которых нет в ТЗ.
- Отвечай по-русски, без вводных фраз и без пересказа вопроса.

Несколько принципов. Инструкции должны быть короткими и конкретными: пять правил, которые действительно нужны, лучше двадцати общих. Не дублируйте в инструкциях содержимое знаний — ссылайтесь на него. И проверяйте: после написания инструкций задайте два-три типичных вопроса и посмотрите, соблюдаются ли правила. Если нет — формулируйте жёстче или переносите правило выше.

Инструкции проекта не отменяют приёмы из урока «Как получать результаты лучше»: контекст задачи в конкретном запросе всё равно нужен. Проект берёт на себя то, что не меняется, а запрос — то, что меняется.

Память проекта

У каждого проекта своя память, отдельная от общей памяти аккаунта. Это значит, что факты, которые Claude запомнил в чатах проекта «Автосервис», не всплывут в чатах проекта «Фитнес-клуб», и наоборот. Чаты можно переносить в проект и из него — так вы управляете тем, что войдёт в память проекта.

На практике это удобно для изоляции клиентов: проект на клиента — и контекст одного не перемешивается с другим. Настройками памяти управляют в настройках аккаунта; на корпоративных планах — если функцию включил владелец.

Проекты для команды

На командных и корпоративных планах проект можно сделать видимым для организации или конкретных людей, с правами «просмотр» или «редактирование». Это превращает проект из личной папки в общий инструмент.

Что это даёт в агентстве:

• Проект клиента. Аналитик собирает знания, дизайнер и разработчик пользуются тем же контекстом. Все чаты в одном месте — новому участнику проще войти.
• Проект стандарта. «Как мы пишем ТЗ», «Как мы оформляем баг-репорты», «Тон писем клиентам». Один человек поддерживает, все пользуются.
• Проект отдела. Общие инструкции и глоссарий для тестировщиков или для продаж.

Когда делите проект, помните: все, у кого есть доступ, видят знания и инструкции. Не кладите в общий проект то, что предназначено не всем.

Три проекта, с которых можно начать

«Мой проект <название>». Бриф, ТЗ, глоссарий, инструкция с вашей ролью. Все рабочие чаты по проекту — здесь.

«Мои документы». Два-три образца документов, которые вы пишете регулярно, и инструкция «пиши в этом стиле». Без привязки к клиенту.

«Разбор и обучение». Проект без знаний, с инструкцией «объясняй как коллега-наставник, задавай проверочные вопросы». Для вопросов вида «объясни, что такое OAuth» — чтобы они не засоряли рабочие проекты.