Мой знакомый, Прохор, однажды обнаружил, что его аккаунт OpenAI заблокирован. До окончания подписки Plus оставалось два-три дня, он собирался её продлевать, но сеанс внезапно завершился. При повторном входе вместо привычного чата появилось сообщение о блокировке.
Сначала Прохор решил, что это какой-то сбой и утром всё восстановится. Но утром ничего не изменилось, а на апелляцию пришёл отказ без объяснения причин.
За его аккаунтом стояло больше двух лет работы с ИИ. Обсуждения ИТ проектов, поиск решений, разработка, повседневные задачи. Постепенно сложилась привычка: ИИ-помощнику можно было задать короткий вопрос, не объясняя предысторию и получить ответ, по делу. Термины уже разобраны, ограничения обсуждены, некоторые подходы проверены и отброшены. В любой момент можно было двигаться дальше!
При этом Прохор вполне допускал, что однажды доступ может пропасть. Более года назад он написал ClipKeeper — приложение под Windows, которое сначала упрощало работу с буфером обмена в ChatGPT, а затем научилось сохранять переписку в локальное хранилище на OpenSearch. Появились поиск, рубрикатор, другие удобства. Пока Прохор работал, ClipKeeper исправно складывал все сообщения в архив.
Казалось бы, к неприятности он подготовился. Переписка сохранилась.
Прохор создал новый аккаунт и снова получил доступ к ИИ. Но вскоре выяснилось, что вернуться к привычной работе гораздо сложнее, чем создать новый чат.
Что осталось между сообщениями?
Представьте: вы несколько недель обсуждали с ИИ-помощником устройство будущей системы. Начали с одного подхода, обнаружили ограничение, попробовали другой. По ходу уточнили саму задачу. Выяснили, что некоторые первоначальные требования вообще не нужны, зато одно незаметное условие меняет всю архитектуру.
Теперь вы открываете новый разговор и просите продолжить работу над этим проектом. ИИ-помощник предлагает разумное решение. Возможно, то самое, с которого вы начинали несколько недель назад. И приходится объяснять ему, почему это не подходит. Затем — откуда взялось ограничение. Потом — что вы подразумеваете под термином, который используете в объяснении. За одним уточнением тянется другое и на это уходит время.
Вчера достаточно было нескольких слов. Сегодня нужно заново развернуть целую историю. Именно с этой трудностью столкнулся Прохор. В его работе с ИИ было множество разных занятий и тем, и восстановить их оказалось неодинаково сложно.
- С разработкой ПО (вайбкодинг) было понятнее всего: код лежит в репозиториях, рядом документация, история изменений. Новому ИИ-помощнику есть что изучить.
- С собственным harness и скиллами Hermes похожая ситуация: инструкции сохранены, можно передать их и объяснить текущую задачу. Это не возвращает все прежние обсуждения, но даёт основу для продолжения.
- А вот значительная часть проектов, ещё не дошли до реализации или реализацией занимаются другие люди. Их главным результатом было понимание того, что и зачем предстоит создавать. Оно складывалось в разговорах и лишь частично попадало в документы.
Там оставались причины решений. Различия между похожими понятиями. Гипотезы, которые выглядели убедительно, пока не состоялась проверка. Условия, при которых отложенный подход стоило бы рассмотреть снова.
Всё это влияло на следующий шаг, хотя не обязательно превращалось в отдельный артефакт.
Сохранить разговор ещё не значит подготовить продолжение
Архив Прохора оказался полезен: к обсуждениям можно вернуться, найти нужные фрагменты, попытаться восстановить ход работы. Но теперь эту работу нужно проделать.
В переписке соседствуют предложенное и принятое, проверенное и предполагаемое. Решение из одного разговора могло быть пересмотрено в другом. Иногда темы перемешивались, потому что Прохор забывал переключить рубрику. А некоторые выводы были понятны участникам обсуждения настолько, что их никто отдельно не сформулировал.
Допустим, поиск нашёл сообщение: «Останавливаемся на варианте Б». Для продолжения проектирования полезно знать ещё несколько вещей. Почему на нём? Какие ограничения определили выбор? Остались ли они в силе? Что должно измениться, чтобы решение пришлось пересмотреть?
Без этих оснований новый помощник может аккуратно соблюдать старую договорённость, но не понимать, когда она перестаёт подходить.
Поэтому проблема шире потери одного аккаунта. Поменять сервис можно и по собственному желанию. Можно перейти к другой модели, передать проект коллеге или вернуться к нему после долгого перерыва. Во всех этих случаях возникает один вопрос: насколько легко восстановить понимание ИИ-помощника, необходимое для следующего шага?
Прохор позаботился о сохранности разговоров. Теперь ему предстоит научиться сохранять и результат этих разговоров — так, чтобы их можно было передать дальше.
Для этого придётся немного изменить саму работу с ИИ. По ходу обсуждений фиксировать, к чему пришли и на каких основаниях. Сохранять нерешённые вопросы. Оставлять новому помощнику понятную точку входа и проверять, может ли он действительно продолжить задачу.
Главный вопрос здесь вполне практический: как изменить ежедневную работу так, чтобы подготовка к возможной потере контекста не стала ещё одной полноценной работой?
Что должно оставаться после разговора?
Здесь легко впасть в другую крайность: завести десяток документов и после каждого разговора с ИИ тратить ещё час на их заполнение. Такая практика продержится недолго. Особенно на этапе проектирования, когда мысль движется быстро, а преждевременная формализация скорее мешает.
Начать можно с одного документа — условного project_design_state.md. Название не принципиально. Важно, чтобы по нему можно было понять, где проект находится сейчас и почему оказался именно здесь.
Обычный пересказ последнего разговора для этого подходит плохо. «Обсудили варианты хранения, рассмотрели ограничения, выбрали подход» — запись о том, что работа состоялась. Но продолжить её по такой записи трудно.
Полезнее сохранить содержание выбора. Например, в условном проекте системы согласования документов запись могла бы выглядеть так:
Решение. После автоматических проверок документ передаётся сотруднику для утверждения.
Основание. Проверки устанавливают комплектность документа и соответствие формальным требованиям. Они не устанавливают, остаётся ли заявленная потребность актуальной. Документ может быть заполнен правильно, хотя закупка уже не нужна.
Отвергнутый вариант. Автоматическое утверждение после успешных проверок. Сейчас оно позволило бы одобрять формально корректные, но уже неактуальные заявки.
Условие пересмотра. Вернуться к автоматическому утверждению отдельных категорий можно, если появится надёжный способ проверять актуальность потребности и будут определены полномочия системы.
Открытый вопрос. Какие категории документов вообще допускают такую проверку?
В этой записи есть материал для следующего шага. Новый ИИ-помощник сможет объяснить, зачем в процессе человек, и оценить новое предложение относительно причины прежнего решения.
Причём здесь сохранён и путь, к которому можно вернуться. Отвергнутая идея не обязательно плоха навсегда. Иногда она просто не подходит при текущих условиях. Если оставить только «автоутверждение запрещено», временное ограничение постепенно превратится в необъяснимую догму.
В документе состояния также нужны цель проекта, существенные ограничения, используемые понятия и ближайший шаг. Но его ценность определяется не количеством заполненных разделов. Главное — сохранить то, без чего следующий участник работы будет вынужден заново выяснять уже выясненное.
Проектирование тоже нуждается в истории изменений
В ситуации Прохора есть подсказка: к разработке оказалось проще вернуться потому, что её результаты уже существовали за пределами разговоров. Код, документация, история изменений давали новому ИИ-помощнику материал, по которому можно восстановить хотя бы значительную часть текущего положения дел.
Ту же дисциплину имеет смысл распространить на работу, которая происходит до появления кода.
На этапе концептуализации проект тоже развивается. Уточняется проблема, меняются границы системы, появляются понятия и связи между ними. Гипотезы проходят проверку, решения принимаются и пересматриваются. У этой работы есть результаты, хотя их пока нельзя запустить или развернуть на сервере.
Почему бы не обращаться с ними так же последовательно, как с изменениями программы? Подготовить предложение, рассмотреть последствия, проверить доступные предположения, принять изменение и сохранить его вместе с основаниями.
Для этого уже существуют подходы, на которые можно опереться. Docs as Code переносит в работу с документацией привычные инструменты разработки: контроль версий, ревью, автоматические проверки. Architecture as Code позволяет представлять архитектурные модели в форме, которую могут обрабатывать инструменты: например, получать диаграммы из текстового описания модели. Записи архитектурных решений — ADR — сохраняют контекст выбора и его последствия. Docs as Code, Structurizr DSL, Documenting Architecture Decisions.
Эти практики появились задолго до нынешнего распространения ИИ. В совместном проектировании с ИИ-помощником они приобретают дополнительный смысл: проектные артефакты становятся основой следующего разговора.
Сегодня мы зафиксировали, почему отказались от определённого подхода. Завтра помощник прочитал эту запись и учёл её при проработке новой задачи. Если условия изменились, он может предложить пересмотр — с явным указанием, какое прежнее основание больше не действует.
Так документация участвует в работе постоянно. От её актуальности зависит, с какими предпосылками помощник начнёт рассуждать и насколько полезным окажется его следующий ответ.
От обсуждения к принятой версии проекта
Практически это может выглядеть как знакомый разработчикам цикл изменений. В начале работы помощник получает актуальную версию проектных материалов и конкретную задачу. В ходе обсуждения появляются предложения. Когда решение принято, ИИ-помощник готовит изменения в затронутых артефактах: уточняет концепцию, обновляет модель, дополняет словарь, записывает основания выбора и условия его пересмотра.
Человек проверяет эти изменения. После принятия они становятся новой отправной точкой проекта — для следующего разговора, другого ИИ-помощника или коллеги.
Здесь важно не путать предложение с принятой версией. Во время проектирования мы можем одновременно исследовать несколько подходов, и ни один из них ещё не обязан становиться действующим решением. История изменений должна позволять увидеть, что рассматривалось, что было принято и почему.
Часть проверок можно автоматизировать: корректность описания модели, существование ссылок, заполнение обязательных полей. Однако успешно пройденная проверка структуры документа не доказывает, что архитектурное решение подходит задаче. Его основания по-прежнему требуют профессионального суждения, а иногда — отдельного эксперимента.
Для Прохора такой подход означал бы, что даже у проекта без единой строки кода уже есть принятая версия: описание задачи, модель, решения и открытые вопросы. Потеря привычного ИИ-помощника всё ещё потребовала бы времени на восстановление работы, но начинать можно было бы с этой версии, обращаясь к архиву за подробностями.
Необязательно сразу создавать сложный процесс с отдельными инструментами и большим набором документов. Начать можно с одного файла. Важно, чтобы он постепенно отражал развитие проекта и служил надёжной точкой входа для продолжения работы.
Пусть помощник готовит изменения, а человек проверяет смысл
Большую часть работы по фиксации можно поручить тому же ИИ, с которым идёт обсуждение.
Разговор дошёл до решения — ИИ-помощник предлагает, что изменить в состоянии проекта. Человек проверяет формулировку, поправляет её при необходимости, после чего изменение сохраняется. Это может происходить в конце содержательной сессии или прямо в момент важного выбора.
Запрос может быть простым:
Посмотри, что изменилось в нашем понимании проекта за этот разговор. Подготовь изменения к документу состояния: принятые решения и их причины, отклонённые варианты, новые ограничения, результаты проверок и открытые вопросы. Отдельно покажи предложения, которые мы ещё не утвердили. Если неясно, приняли ли мы решение, спроси.
Особенно важна последняя часть. В живом разговоре «интересно, давай рассмотрим» легко превратить при пересказе в «решили использовать». А уверенно написанный документ придаёт такому превращению видимость достоверности.
Поэтому проверять стоит прежде всего смысловые переходы: действительно ли мы это приняли? По этой ли причине? Был ли эксперимент проведён или мы только собирались его провести? Отказались от подхода окончательно или отложили до появления новых данных?
Удобно просить показать именно изменения к существующему документу. Тогда для проверки не нужно каждый раз перечитывать несколько страниц. Видно, какое решение добавлено, какая гипотеза получила подтверждение, какое ограничение перестало действовать.
Сам документ лучше хранить там, где уже живёт проект и где доступна история изменений. Для программного проекта естественным местом может быть репозиторий, даже если кода в нём пока нет. Для другой работы подойдёт привычное хранилище документов с версиями и независимой резервной копией.
Если ИИ-помощник умеет работать с файлами, предложение изменений и их сохранение можно встроить в его инструкции или отдельный скилл. Если не умеет — начать с обычного переноса согласованного фрагмента вручную. На первом этапе важнее наладить саму привычку и понять, какие записи помогают продолжению работы.
Фиксировать тогда, когда меняется понимание
Не каждый разговор должен заканчиваться новым документом. Иногда мы перебираем варианты, задаём уточняющие вопросы или возвращаемся к уже известному. Попытка обязательно извлечь из каждой сессии «три решения и пять выводов» быстро наполнит состояние проекта вымышленным прогрессом.
Повод для записи возникает, когда меняется основание дальнейшей работы.
Мы выяснили, что требование было понято неверно. Договорились о значении термина. Проверили гипотезу и получили результат. Выбрали подход. Обнаружили обстоятельство, из-за которого прежний выбор больше не подходит.
Бывает и другой полезный результат: вопрос пока не решён, но теперь понятно, чего именно не хватает для решения. Это тоже стоит сохранить. Иначе в следующем разговоре помощник снова начнёт предлагать варианты, хотя следующим действием должен быть сбор данных.
Перед завершением работы достаточно спросить: что из сегодняшнего разговора изменит наши действия завтра? Ответ и есть кандидат на фиксацию.
Для проекта на стадии замысла такая запись сама становится небольшим результатом работы. В репозитории ещё может не быть ни одной функции, но уже появляется проверяемое описание того, какую систему мы собираемся построить и на каких основаниях.
Как не превратить документ состояния в ещё один архив?
Через несколько месяцев один файл тоже может разрастись настолько, что его перестанут читать. Поэтому полезно разделять актуальную точку входа и подробную историю.
В точке входа остаётся то, что нужно для начала работы: цель, текущий подход, важные ограничения, основные понятия, открытые вопросы и следующий шаг. Подробные обсуждения решений, результаты экспериментов и исходная переписка доступны по ссылкам.
Например, новому помощнику достаточно сначала узнать, что утверждение документа остаётся за сотрудником, и прочитать короткое объяснение причины. Если задача касается автоматизации утверждения, он обращается к подробной записи: какие варианты рассматривались, что проверяли, какие условия пересмотра определили.
Так можно постепенно углублять контекст под конкретную задачу. Не нужно заранее загружать всё, что когда-либо относилось к проекту.
При пересмотре решения меняются оба уровня: актуальный документ отражает новый подход, а история сохраняет прежний выбор и причину его отмены. Дата и статус записи помогают отличить действующее решение от материала, который объясняет, как к нему пришли.
Архив разговоров при этом остаётся полезным. К нему можно обратиться, если краткая запись вызывает сомнение или в ней не хватает основания. Просто теперь поиск в архиве становится способом уточнения, а не обязательным первым этапом каждого возвращения к проекту.
Как проверить, что работу действительно можно продолжить?
Допустим, документы подготовлены. Новый помощник прочитал их и сообщил, что всё понял. Пока это подтверждает только готовность отвечать. Первую проверку можно сделать через краткое изложение: какую задачу решаем, какие ограничения действуют, какие вопросы пока открыты. Это помогает быстро обнаружить очевидные пропуски. Но пересказать написанное проще, чем использовать его в новой ситуации.
Вернёмся к условной системе согласования. В документе записано, что автоматические проверки не устанавливают актуальность потребности, поэтому утверждение остаётся за сотрудником.
Теперь дадим новому помощнику задачу:
Мы подключили систему, в которой есть актуальный статус потребности. Достаточно ли этого, чтобы автоматически утверждать документы? Что нужно выяснить перед изменением процесса?
Здесь уже недостаточно повторить старый запрет. Помощнику предстоит заметить, что одно из оснований решения могло измениться. При этом наличие статуса ещё требует уточнений: кто его обновляет, насколько он свежий, может ли потребность измениться между проверкой и утверждением, какие полномочия переданы системе.
По такому ответу лучше видно, используются ли сохранённые основания при анализе новой задачи. Если помощник сразу предлагает убрать сотрудника или, наоборот, отказывается обсуждать изменение, потому что «в документе запрещено», материала или понимания пока недостаточно. После этого стоит дать небольшую реальную задачу: уточнить участок процесса, подготовить вариант изменения, спланировать проверку гипотезы. И оценить, сколько пришлось объяснять дополнительно, какие ограничения были упущены и можно ли использовать результат.
Одного удачного ответа недостаточно для уверенности во всех будущих задачах. Но такая проба уже показывает, где пакет контекста помогает, а где в нём остаются пробелы.
Её можно проводить заранее, открывая новую сессию без прежней переписки и, насколько позволяет среда, без влияния накопленной памяти. Необязательно ждать блокировки. Переход к новому этапу проекта или завершение большого обсуждения — хороший повод проверить, сможет ли свежий помощник включиться в работу по сохранённым материалам.
Что теперь делать Прохору?
Всё это легче организовать по ходу работы. У Прохора же уже есть большой архив, в котором нужные основания ещё предстоит найти.
Попытка сразу восстановить два года обсуждений может оказаться отдельным проектом без понятного срока завершения. Практичнее выбрать одну работу, которую нужно продолжить сейчас. Сначала Прохору стоит описать её текущее состояние так, как он сам его помнит, честно отметив сомнения и пробелы. Это даст направление поиску. Дальше можно искать в архиве ответы на конкретные вопросы: почему выбрали этот подход, где определили термин, чем закончилась проверка, действительно ли отменили прежнее решение.
ИИ может помогать находить связанные фрагменты, сопоставлять версии и собирать черновик состояния. Важно сохранять ссылки на сообщения и различать найденное в переписке, восстановленное по памяти Прохора и предположенное помощником. Эти основания имеют разную надёжность.
Если причина старого решения не обнаружилась, иногда разумнее рассмотреть вопрос заново с учётом текущих условий. Такое решение следует записать как новое, принятое сейчас. Не нужно выдавать правдоподобное объяснение за восстановленную историю. Первый результат этой работы — документ, достаточный для продолжения выбранной задачи. Затем его можно проверить с новым помощником, обнаружить недостающие связи и вернуться в архив уже за ними.
Так ценность ClipKeeper станет вполне конкретной: сохранённая переписка поможет восстановить основания, которые иначе пришлось бы искать заново или проверять повторно. А новые обсуждения уже будут оставлять после себя более удобную отправную точку.
Подготовить следующий разговор
История Прохора показывает, насколько много работы постепенно оказывается скрыто за коротким запросом к ИИ. Мы привыкаем к этой лёгкости и замечаем её настоящую стоимость, когда объяснять приходится заново.
Сохранённое состояние проекта не вернёт буквально прежнего ИИ-помощника и не гарантирует одинаковое качество работы с любой моделью. Но оно позволит передать дальше то, что удалось выяснить: задачу, основания решений, ограничения и вопросы, с которых следует продолжить.
Начать можно с одного проекта и одного запроса в конце сегодняшнего разговора: «Что нам нужно сохранить, чтобы завтра продолжить эту работу с новым ИИ-помощником?»
А затем — действительно попробовать продолжить.