Почему решения из чатов с ИИ теряются и где их хранить

Решения, принятые в разговоре с ChatGPT или Claude, теряются, потому что у чата нет состояния. Ничто в нём не помечает строку как «вот что мы решили», ничто не связывает эту строку с работой, на которую она влияет, а новый чат начинается с чистого листа. Лечится это так: пусть ИИ записывает решение туда, где живёт работа, — короткой записью с причинами, — а следующая сессия читает эти записи, прежде чем действовать.

Weft делаем мы. Факты о других продуктах взяты с их официальных страниц и проверены 27 октября 2026 года. Мысль о том, что у треда «нет состояния», взята из статьи Hypertask о тредах в Slack. Здесь мы применяем её к чатам с ИИ.

Почему решения, принятые с ChatGPT или Claude, пропадают?

Ты сорок минут взвешиваешь с ассистентом двух поставщиков базы данных, две модели ценообразования или два способа устроить API. Останавливаешься на одном. Рассуждение хорошее, ассистент согласен, и ты переходишь к следующему делу.

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

Дело не в дисциплине. Разговор — это последовательность сообщений. В нём нет поля «решено», нет владельца, нет связи с задачей и нет способа сказать «это заменяет то, о чём мы договорились во вторник». Когда сообщения уезжают вверх, решённый вопрос и брошенный выглядят одинаково.

Разве память чата этого не решает?

Не для этой задачи. Многие ассистенты теперь умеют помнить что-то о тебе между чатами, и это полезно для предпочтений и контекста. Но эта память принадлежит одному продукту и одному аккаунту. Она написана для того, чтобы ей пользовался этот ассистент, а не как запись, которую человек может просмотреть построчно, и другой ИИ-клиент прочитать её не может. И она не говорит, к какой задаче относился выбор и какой прежний выбор он заменил.

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

Какое решение стоит записывать?

Записывай выбор, если кто-то вполне мог выбрать иначе и этот выбор определит дальнейшую работу. Хорошие примеры:

• Выбор одного инструмента, поставщика или библиотеки вместо другого.
• Сознательный отказ от чего-то («в этом квартале без реферальной программы»).
• Правило, которому должна следовать работа («в ЕС все цены показываем с НДС»).
• Изменение прежнего выбора — с причиной.
• Урок, усвоенный на собственном опыте («не запускать миграцию в рабочее время»).

Не записывай:

• Идеи, которые обсуждали, но не приняли.
• Шаги самой работы (им место в задаче и её результате).
• То, на что человек ещё не согласился, если это не помечено явно как предложение.
• Факты, которые любой найдёт заново за минуту.

Полезная проверка: если бы новая сессия ИИ собралась отменить этот выбор, хотел бы ты, чтобы она остановилась и прочла почему? Если да — запиши.

Как выглядит хорошая запись о решении?

Пиши коротко и сохраняй причины. Формат ниже — облегчённая версия MADR (Markdown Architectural Decision Records); именно его использует инструмент record_decision в Weft:

Title:        Загрузка файлов: объектное хранилище, а не база данных
Outcome:      Загруженные файлы идут в объектное хранилище; в базе
              хранятся только ключ файла и метаданные.
Status:       accepted
Context:      Пользователи прикладывают файлы до 50 МБ. Если хранить
              их в базе, бэкапы станут медленными и большими.
Options:      1. Объектное хранилище + дёшево, бэкапы остаются маленькими
                                      - ещё один сервис в настройке
              2. Колонка в базе       + всё в одном месте
                                      - бэкапы растут с каждой загрузкой
Consequences: Для скачивания нужны подписанные URL.
              Удаление задачи должно удалять и её файлы.
Revisit when: Понадобится поиск по содержимому файлов.
Task:         Загрузка файлов

• Title называет решение, чтобы его можно было найти беглым просмотром.
• Outcome — одно предложение, по которому новичок может действовать.
• Context — что было верно на тот момент. Именно эта часть первой стирается из памяти.
• Options перечисляет только то, что действительно взвешивали, а не альтернативы, придуманные задним числом.
• Consequences включает принятые минусы, чтобы потом никто не «обнаружил» их как баги.
• Revisit when говорит, что сделало бы этот выбор неверным.

Как Weft хранит записи о решениях?

Weft — это доска задач, к которой твои ИИ-клиенты подключаются по MCP по адресу https://letsweft.com/api/mcp. Решениями занимаются три из 32 его инструментов:

• record_decision принимает заголовок и итог, а также контекст, до пяти вариантов с плюсами и минусами, последствия и условие пересмотра. Запись можно привязать к задаче (taskId) или проекту. Записи неизменяемы: чтобы поменять одну, ИИ записывает новое решение с supersedesId, указывающим на старое, а старая запись остаётся с пометкой superseded.
• get_context возвращает действующие решения и уроки рабочего пространства, сначала новые, упакованные в бюджет токенов (по умолчанию 800). Его можно сузить до проекта или задачи. У каждой строки есть дата, заменённое решение не появляется никогда, а строки, которые не поместились, подсчитываются, а не скрываются.
• get_task_history в режиме decisions перечисляет все решения, записанные по одной задаче, включая вердикты после просмотра и их причины.

У record_decision есть и второе применение: передать вердикт, который человек вынес в разговоре по работе, ждущей его просмотра (accepted, rework, dropped или deferred). Описание инструмента говорит ИИ, что здесь он посыльный, а не тот, кто решает, поэтому никогда не должен так принимать собственную работу.

Раз записи никогда не правятся на месте, история остаётся честной. Если в марте ты сменишь поставщика, январское решение никуда не денется — оно будет помечено как заменённое, а мартовская запись объяснит почему.

Как попросить ИИ записывать решения?

Подключи Weft к своему ИИ-клиенту и вставь в начале чата — или в пользовательские инструкции клиента либо файл проекта, если они есть, — примерно такую инструкцию:

Когда мы в этом чате делаем настоящий выбор (выбираем один вариант вместо другого,
от чего-то отказываемся или меняем прежний выбор), запиши его в Weft через
record_decision, прежде чем идти дальше:
- title: решение, названное в нескольких словах
- outcome: выбор одним предложением
- context: что было верно и вынудило этот выбор
- options: только те варианты, которые мы действительно взвешивали, с плюсами и минусами
- consequences: что из этого следует, хорошее и плохое
- confirmation: когда нам стоит к нему вернуться
- taskId или project: задача или проект, к которым это относится
Если решение меняет прежнее, передай supersedesId вместо правки.
Не записывай болтовню, догадки и то, на что я не согласился.
Если я ещё не определился, используй статус "proposed".
Перед любой нетривиальной работой сначала вызови get_context и скажи мне,
какие прошлые решения к ней относятся.

Подключение занимает минуту. В ChatGPT Weft — опубликованное приложение в каталоге плагинов, доступное на любом тарифе, включая Free (настройка). В Claude Code это одна команда (настройка). В Claude.ai и Claude Desktop его добавляют как собственный коннектор. Вход — через OAuth в браузере, так что копировать ключ не нужно, а Weft выдаёт refresh-токены, поэтому клиент сам продлевает вход. Страницы настройки для других клиентов, включая Cursor и Codex, есть в документации.

Что будет, если на следующий день я перейду из ChatGPT в Claude Code?

Вот случай, ради которого написана эта инструкция.

1. В понедельник ты планируешь фичу в ChatGPT. Ты решаешь хранить загрузки в объектном хранилище, а не в базе, и ChatGPT вызывает record_decision с контекстом, обоими вариантами и последствиями, привязав запись к задаче «Загрузка файлов».
2. Во вторник ты открываешь Claude Code в репозитории. Если ещё не подключил его: claude mcp add --transport http weft https://letsweft.com/api/mcp.
3. Ты просишь его взяться за задачу с загрузками. Прежде чем писать код, он вызывает get_context для этой задачи или get_task_history в режиме decisions и получает понедельничную запись.
4. Он строит работу на объектном хранилище, а не открывает вопрос заново. Если он находит настоящую причину, почему выбор неверен, он может предложить новое решение, заменяющее понедельничное, а решать будешь ты.

Оба клиента читают одну доску и одни решения, потому что запись живёт в Weft, а не в каком-то из чатов. Каждое OAuth-подключение — отдельный участник, и доска показывает имя, под которым зарегистрировался каждый клиент, так что видно, какое подключение создало какую задачу. Как запускать несколько агентов на одной доске без столкновений — в статье несколько ИИ-агентов, одна доска.

Куда в итоге должны попадать решения из ChatGPT?

Четыре привычных места — в сравнении по тому, что нужно журналу решений:

Смысл не в том, что чат или документы плохи. В чате ты думаешь. Решение нужно скопировать из чата во что-то с состоянием — в момент, когда оно принято, и силами того, кто уже участвует в разговоре: ИИ.

Это заменяет нашу документацию или вики?

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

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

Сколько это стоит?

Запись и чтение решений работают на бесплатном тарифе (Free), в который входят 50 активных задач и 200 вызовов ИИ-инструментов в месяц. Каждый вызов record_decision или get_context считается одним вызовом. Pro стоит $7 за место в месяц или $60 за место в год, с неограниченными задачами и вызовами (цены). В Weft нет ИИ-кредитов: думает твой собственный ИИ-клиент, а Weft только хранит доску и её записи.

Разве нельзя просто попросить ChatGPT подвести итоги решений в конце чата?

Можно, и это помогает. Но итог всё равно остаётся в этом чате или там, куда ты его вставишь. Он не привязан к задаче, другой ИИ-клиент не может его прочесть, а когда решение меняется, не остаётся записи о том, что оно заменило. Запись каждого решения в момент принятия снимает все три проблемы.

Будет ли ИИ записывать решения без просьбы?

Описание инструмента record_decision говорит ИИ использовать его каждый раз, когда пользователь делает в разговоре настоящий выбор, так что некоторые клиенты будут. Не полагайся на это. Вставленная инструкция делает это явным, и ты всегда можешь сказать «запиши это решение».

Можно ли исправить решение, если оно записано неверно?

Не на месте. Записи неизменяемы. Запиши исправленное решение с supersedesId, указывающим на неверное. Старая запись останется с пометкой superseded, и get_context перестанет её показывать.

Решению обязательно нужна задача?

Нет. Решение можно привязать к задаче, к проекту или ни к чему. Если привязать его к задаче, get_task_history покажет его рядом с этой работой, а get_context можно сузить до неё.

Это то же самое, что рабочая память Weft?

Нет. Рабочая память (короткие усвоенные заметки) — отдельная функция Pro. Записи о решениях создаёт record_decision, и в коде они Pro не ограничены.

А если я пользуюсь несколькими ИИ-клиентами?

Это и есть главная причина так делать. ChatGPT, Claude Code, Cursor или Codex, подключённые к одному рабочему пространству Weft, читают одни и те же решения через get_context, поэтому второй клиент не открывает заново вопросы, которые закрыл первый.