Как не потерять накопленные знания в чатах с AI
Работодатели сейчас всё активнее думают, как заменить часть работы сотрудников нейросетями.
Мне кажется, самим людям тоже стоит подумать в обратную сторону: как не оставить весь накопленный с AI опыт внутри чужих сервисов. Потому что полезные знания очень быстро расползаются по ChatGPT, Claude, Grok, Gemini, DeepSeek, Codex, IDE-агентам и десяткам отдельных чатов.
Где-то ты несколько часов разбирал архитектуру. Где-то настраивал сервер. Где-то искал рабочую схему деплоя. Где-то доводил до ума процесс ревью. Где-то просто в ходе длинного разговора выработал хороший рабочий подход. А через полгода попробуй всё это найди.
И тут не обязательно сразу городить RAG и отдельную AI-платформу. Можно начать вообще без скриптов. Самая простая схема:
чат → Markdown → своё хранилище
Например, создать закрытый репозиторий на GitHub:
my-skills
И после каждого действительно полезного разговора просить нейросеть не просто оставить всё в истории, а оформить результат в отдельный .md.
Например:
Оформи результат этого разговора как универсальную инструкцию в Markdown и сохрани в my-skills. Если такая инструкция уже есть: Обнови существующий файл новыми знаниями из этого разговора, без повторов.
Структура может быть совсем простой:
my-skills/
__ development/ ____ laravel-deploy md ____ github-pr-review md ____ remote-dev md
__ infrastructure/ ____ cloudflare-access md ____ nginx-reverse-proxy md ____ ubuntu-server-setup md
__ projects/ ____ project-a/ ____ project-b/
У многих AI-инструментов уже есть работа с GitHub, поэтому для базового варианта даже отдельную автоматизацию писать не обязательно. GitHub при этом тоже не принципиален.
Можно сделать обычную папку AI-Skills на компьютере и держать копию в Яндекс Диске, Облаке Mail ru, на своём сервере или в любом другом хранилище, чтобы полезный результат разговора не оставался навсегда внутри конкретного AI-провайдера.
Причём сохранять лучше не пересказ чата, а уже нормальную рабочую инструкцию:
* что решаем; * когда этот способ подходит; * последовательность действий; * команды; * конфиги; * типичные ошибки; * как проверить результат.
Тогда через какое-то время получается уже не архив переписок, а собственная библиотека рабочих решений.
Сейчас активно развиваются OpenClaw, Claude Code, Codex и другие агентские системы, которые умеют работать не просто с одним промптом, а с постоянными инструкциями, файлами проекта, skills и дополнительным контекстом. То есть папка my-skills постепенно может стать не просто архивом заметок, а реальным рабочим слоем поверх разных моделей.
Например:
my-skills/
__ remote-dev/ ____ SKILL md ____ scripts/ ____ examples/
__ code-review/ ____ SKILL md
__ deploy/ ____ SKILL md ____ scripts/ ____ references/
Где SKILL md — основная инструкция, а рядом лежат готовые скрипты, примеры конфигов и дополнительные материалы.
И тогда сегодня этот набор использует один агент, завтра другой. Сегодня ChatGPT. Завтра Claude Code. Потом Codex, OpenClaw или какая-нибудь локальная модель. А твои инструкции при этом остаются у тебя. Не у OpenAI. Не у Anthropic. Не у Google. Не внутри одного конкретного чата. А в собственной базе, которую можно подключать к разным инструментам.
По сути, со временем получается примерно такая схема:
AI-чаты ↓ полезные результаты ↓ Markdown ↓ собственная база знаний ↓ универсальные инструкции / skills ↓ любые AI-агенты
Cобственные рабочие инструкции, решения и накопленный за годы опыт лучше хранить всё же у себя в структурированном виде.
🔗 Полная статья: https://msk.onl/blog/ai-chat-md-export
· 5 ч
Markdown в Git удобнее архива чатов, но при экспорте легко превратить гипотезу модели в постоянную инструкцию. Я бы сохранял рядом дату последней проверки и версии инструментов, а непроверенное помечал отдельно. Иначе следующий агент уверенно повторит старую ошибку. Как отделяете рабочие рецепты от предположений?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 4 ч
Мне в этом плане несколько проще, я выгружаю в основном готовые рецепты в веб-разработке. И чаще всего сразу со скриптами для деплоя и тестирования. Те там очень мало вариативности по специфике работы.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён