Работа в GPT: как не потерять решения между чатами
Работа в GPT над длинным проектом требует порядка: где хранить исходники, как разделять диалоги и что записывать после решения. Шпаргалка на одном рабочем примере.
М
Марина
Контент-маркетолог LibraChat
6 мин чтения
Во вторник я согласовала тему рассылки. В четверг открыла новый диалог и снова получила старую версию предложения: решение осталось в другом чате. Если для тебя «работа в GPT» — это несколько дней над одной задачей, проблема знакомая: сам по себе длинный поток сообщений не становится надёжным рабочим документом. Помогает короткая карточка проекта, отдельные диалоги по назначению и журнал принятых решений. Покажу, как я организую их на примере подготовки рассылки.
Работа в GPT начинается с карточки, а не с первого промпта
В справке OpenAI о проектах ChatGPT описана возможность держать связанные чаты, файлы и инструкции вместе; доступные настройки зависят от тарифа и рабочей среды. Для нашего примера важен сам принцип: постоянные сведения о задаче не должны прятаться на двадцатой странице переписки. Они нужны под рукой. В LibraChat проект тоже собирает свои чаты, инструкции, базу знаний и файлы; контекст проекта учитывается в разговорах внутри него. Это удобно для работы, которая длится больше одного сеанса.
Я собрала карточку в пять строк. Например:
Задача: подготовить письмо о новой функции для действующих клиентов. Адресат: те, кто уже пользуется продуктом. Подтверждённые факты: функция доступна в браузере; дата запуска — 12 ноября. Ограничение: не обещать работу в мобильном приложении. Открытый вопрос: кто утвердит формулировку условий.
Это учебный пример, а не сведения о реальном запуске LibraChat. Он нужен, чтобы увидеть разницу между известным фактом и вопросом. Когда я раньше писала «сделай рассылку о новой функции», модель заполняла пробелы привычными формулировками. Теперь в карточке есть строка, которую нельзя додумывать. Если дата или ограничения меняются, я исправляю карточку до следующего запроса.
Три чата для разных видов работы
Для маленькой задачи хватит одного разговора. Для рассылки с несколькими согласованиями я завожу три: источники отдельно от черновика и контроля. Так я быстрее нахожу, на каком этапе появилось спорное утверждение. И не путаю версии. Названия чатов — моя организация, а не специальная функция модели.
Чат · Что в нём делаю · Что забираю в карточку проекта
Источники — Уточняю факты из разрешённых материалов — Подтверждённые даты, условия, ссылки на исходник
Черновик — Пробую варианты темы и письма — Выбранную формулировку и причину выбора
Проверка — Ищу пропуски и двусмысленность; отдельно отмечаю лишние обещания — Список исправлений и открытых вопросов
Я не копирую между ними всё подряд. После каждого согласования переношу только утверждённое решение. Иначе в проекте остаются четыре версии одного срока, и новый диалог может опереться на устаревшую. Однажды я сохранила красивую тему письма, но не записала, почему отказались от второго варианта. Через неделю мы снова обсуждали то же ограничение. Снова по кругу. Пять слов в журнале решений сэкономили бы этот разговор.
Я проверила свою старую папку с 14 черновиками за 20 минут: в названиях были номера версий, но не было статуса. Файл «финал-3» оказался вовсе не отправленным вариантом. После этого записываю выбранную формулировку и имя того, кто её утвердил. Статус «на проверке» я не заменяю словом «готово» ради удобства. Это мелочь. До первого спорного письма.
Для журнала хватает такой записи: «12 ноября; тема письма А; выбрана потому, что точно называет функцию; утвердила Марина; исходник — карточка продукта». Если решение предварительное, пометь это явно. Не превращай предположение в правило проекта.
Что класть в инструкции, а что оставлять в запросе
Инструкция проекта подходит для повторяющихся правил: тон, аудитория, запреты на неподтверждённые утверждения, формат ответа. Конкретную тему письма и свежие условия я даю в запросе к текущей задаче. Так не приходится править постоянные инструкции каждый раз, когда меняется дата кампании.
Моя короткая инструкция звучала бы так: «Пиши для действующих клиентов без преувеличений. Если в материалах нет подтверждения функции или условия, задай вопрос. Не выводи дату из контекста прошлых кампаний». В новом диалоге я добавлю: «Нужно письмо о функции X; вот три подтверждённых факта и ограничение». Эту связку можно подставить под свою задачу, если её факты собраны заранее.
Перед тем как поместить рабочие файлы в любой облачный чат, я проверяю право их передавать. Для учебной настройки возьми вымышленные данные. Даже когда сервис может разобрать документ, окончательную версию письма и условия отправки утверждает ответственный сотрудник.
Ниже мой список для проверки устройства проекта:
Есть ли одна короткая карточка с действующей версией фактов?
Ясно ли, какие решения утверждены, а какие ещё обсуждаются?
Можно ли от каждого важного утверждения вернуться к источнику?
Не лежат ли личные или внутренние данные там, где их размещать нельзя?
Если на третий вопрос ответ «надо искать по всем чатам», журнал пока не работает.
Я отдельно отмечаю источник для числа или условия. В нашем учебном письме дата запуска лежит в карточке продукта, а не «помнится из разговора». Если руководитель меняет срок, я правлю исходник и журнал, затем прошу обновить черновик. Старый ответ не становится новым только потому, что его переслали в другой чат. При такой дисциплине легко увидеть, кто принял решение, а где модель лишь предложила фразу.
Шпаргалка перед новым сеансом
Работа в GPT с продолжающимся проектом не заканчивается удачным первым ответом. Перед новым сеансом я делаю минутную сверку: обновляю карточку, перечитываю последнее решение, выбираю чат по задаче. Встречи и письма меняются быстрее, чем общий стиль команды, поэтому их условия держу отдельными строками. Один проект не должен становиться свалкой всех задач отдела.
Если потерялся факт, возвращаюсь к исходному документу, а не прошу чат восстановить его по памяти.
Если версии спорят, ищу запись об утверждении и дату; старую помечаю как отменённую.
Если нужен новый формат, создаю отдельный запрос с теми же подтверждёнными сведениями.
Я пробовала держать черновики вместе с вопросами и утверждениями в одном диалоге. Он был удобен первые два дня. На третий выяснилось, что ссылка на исходник затерялась среди вариантов темы письма. Я поймала ошибку до отправки. Разделение на три потока окупилось, когда нужно было объяснить коллеге, почему мы не обещаем функцию в приложении. Нашли строку ограничения за минуту. Сам чат не устанавливает истинность фактов.
Открой LibraChat и попробуй создать карточку одного своего безопасного проекта: цель, адресат и три факта. Отдельно запиши запрет и открытый вопрос. Затем реши, нужен ли ему один чат или несколько. О том, как формулировать отдельные запросы, есть разбор промпта на примере объявления; условия проектов и других режимов смотри в действующих тарифах. Начни с карточки. Если через неделю по ней можно восстановить принятое решение, структура выполнила свою задачу.
