Коротко
Что на самом деле теряется при переходе?
Вопрос звучит на каждом втором обучении: «я полгода работал в одном сервисе, он меня уже знает. Если перейду на другой - всё насмарку?»
Ответ короткий: нет, если ты работал через файлы. Да, если вся работа жила внутри переписки.
Формулирую это правилом, которое даю ученикам: значение имеет не чат, а файлы. То, что беседа велась в конкретном сервисе, само по себе ничего не значит. Значение имеет, какие файлы созданы и где они лежат.
Из этого следует практический вывод, полезный ещё до всякого переезда: всё важное, что рождается в разговоре с нейросетью, должно оседать в файле. Не в закладке на чат, а в документе на твоём диске.
Про то, как устроен этот принцип целиком, писал в материале про контекст-инжиниринг: работа с ИИ - это работа с контекстом, а контекст живёт в файлах.
Как забрать то, что сервис помнит о тебе?
Приём, который я показываю на обучениях и которым пользуюсь сам.
Современные сервисы ведут о тебе заметки: чем ты занимаешься, какие у тебя проекты, как ты любишь получать ответы. Обычно эти заметки лежат где-то в настройках и выглядят как список коротких фраз.
Забрать их можно двумя путями:
Посмотри раздел с памятью в настройках
У большинства сервисов есть страница, где видно, что именно о тебе запомнено. Часто там же можно всё это скопировать.
Попроси собрать выгрузку прямо в чате
Формулировка: «собери всё, что ты обо мне и моих проектах запомнил, в один структурированный текст: кто я, чем занимаюсь, над чем работаю, какие у меня предпочтения в ответах».
Дополни своими словами
Модель знает не всё. Допиши то, что она не назвала: контекст компании, ограничения, привычные форматы.
Сохрани в файл
Обычный текстовый файл на диске. Это и есть твой переносной багаж.
Отдай новому инструменту
На первом же разговоре: «вот описание меня и моей работы, учитывай это дальше».
Выгрузка полезна ещё и сама по себе: люди регулярно обнаруживают в памяти сервиса устаревшие факты о себе. Старая должность, закрытый проект, гипотеза, от которой давно отказались - и всё это продолжает влиять на ответы.
Что перевозить, а что бросить
| Перевозить | Почему | Бросать | Почему |
|---|---|---|---|
| описание себя и компании | без него любая модель отвечает общими словами | история переписки | пересказывать месяцы разговоров дороже, чем начать заново |
| правила и предпочтения по ответам | иначе заново объяснять формат каждой задачи | промежуточные варианты | они устарели вместе с задачей |
| наработанные материалы и шаблоны | это и есть результат работы | неудачные ветки обсуждений | переносят в новый инструмент чужие тупики |
| список текущих задач и договорённостей | чтобы не терять нить | закреплённые настройки конкретного сервиса | в другом инструменте они называются иначе |
Отдельно про честную оговорку, которую я всегда добавляю: перед переносом прочитай, что внутри. Иногда выясняется, что накопленное - это гора черновиков, и собрать заново дешевле, чем перевозить.
Как собирать профиль себя и своей работы, чтобы он был полезным, а не анкетным, разбирал в материале про то, как рассказать нейросети о себе.
Формат, который читают все
Практический ответ на вопрос «в чём хранить». В обычном тексте.
Почему именно так:
- Любая модель это читает. Текст - универсальный вход для всех инструментов, без исключений.
- Ты сам это читаешь. Открыл, посмотрел, поправил. Никаких особых программ.
- Не зависит от сервиса. Файл лежит у тебя. Сервис может закрыться, подорожать или разонравиться - файл останется.
- Хорошо ложится в папку проекта. Рядом с материалами, а не в отдельной вселенной.
Отдельно отвечу на вопрос, который на обучениях звучит регулярно: папка с файлами - это не собственность одного агента. Любой инструмент, у которого есть доступ к твоему компьютеру, прочитает ту же папку и те же файлы. Разница между инструментами не в том, какие файлы они понимают, а в том, как они с ними работают дальше.
Отсюда же ответ на второй частый вопрос: файл-память проекта - это обычный текстовый файл, и другой инструмент его прочитает так же спокойно, как и первый. Ничего волшебного в нём нет. Что писать внутрь такого файла, разбирал подробно - что писать в CLAUDE.md.
Такой набор файлов и есть твой второй мозг: он не принадлежит ни одному сервису и переезжает вместе с тобой.
Как проверить, что переезд состоялся?
Проверка «помнишь ли ты меня» бесполезна: модель бодро перескажет то, что ты сам ей только что дал.
Рабочая проверка выглядит иначе. Возьми задачу, которую недавно решал в старом сервисе, и поставь её в новом. Сравни два ответа.
На что смотреть:
- Учитывает ли контекст. Упоминает твою отрасль, ограничения, привычный формат - или отвечает общо.
- Задаёт ли правильные вопросы. Хороший признак: спрашивает про то, чего действительно не хватает.
- Попадает ли в формат. Если ты годами получал ответы в определённом виде, это должно перенестись через файл с правилами.
- Не выдумывает ли факты. Если новый инструмент уверенно называет то, чего ты не переносил, - контекста ему не хватило, и он достроил сам.
По итогам проверки допиши файл. Обычно после первого прогона добавляется два-три абзаца - те самые вещи, которые ты считал очевидными.
Когда переезжать не стоит?
Честно про обратную сторону: переезд стоит времени, и не каждый повод его оправдывает.
Когда переезд оправдан:
- Изменились требования компании. Например, к тому, где могут обрабатываться данные.
- Инструмент не тянет твой класс задач. Не разово, а системно.
- Цена перестала сходиться с пользой.
Когда не оправдан:
- Один плохой ответ. Это ничего не говорит про инструмент.
- Кто-то посоветовал. Чужой сценарий работы не равен твоему.
- Хочется попробовать новое. Пробуй - но параллельно, а не переездом.
Нормальная зрелая конфигурация - два-три инструмента под разные типы задач. У меня это именно так: один для длинной работы с проектом, другой для быстрых вопросов, третий для документов. Как их выбирать, разбирал в материале про то, какую нейросеть выбрать под задачу.
Тогда и вопрос переезда стоит иначе: не «куда мне перейти», а «что из моего багажа нужно каждому из них». Ответ - один и тот же набор файлов.
Частые вопросы
Частые вопросы
Главный вывод
Главное, что стоит запомнить: привязка к сервису возникает не из-за качества модели, а из-за того, что твоя работа осела внутри его интерфейса. Лечится это заранее, а не в момент переезда.
Практический минимум: выгрузи из сервиса всё, что он о тебе помнит, дополни своими словами, сложи в текстовый файл рядом с проектом и проверь новый инструмент реальной рабочей задачей.
Посмотри на свою работу за последний месяц. Что из неё останется, если завтра исчезнет доступ к сервису, в котором ты её вёл?
Источники
- Vendor lock-in - привязка к поставщику и как она возникает, Википедия
- Data portability - переносимость данных между сервисами, Википедия
- Markdown - простая текстовая разметка, Википедия
- Plain text - почему обычный текст читается везде, Википедия
- Файл-память проекта - как агент читает контекст из файлов, документация Claude Code
