Второй мозг: Как превратить нейросети в личного помощника

Память проекта: как собрать контекст в одну рабочую картину

Анна уже не ждала от нейросети волшебной кнопки. Повторяющуюся работу можно передать машине, но приоритеты, ответственность и последнее решение по-прежнему остаются за человеком. Теперь ей предстояло проверить другую часть системы: есть ли у проекта память, с которой вообще можно работать.

В 8:47 утра Анна открыла окно нейросети и написала первую строку: «Помоги подготовить план запуска внутреннего сервиса». На слове «запуска» она остановилась. Для самой Анны оно означало сразу несколько вещей: показать прототип, провести пилот, открыть доступ сотрудникам или начать сбор заявок в ограниченной группе. В письмах, таблицах и заметках все эти этапы назывались одним словом.

Анна закрыла окно запроса и открыла папку проекта.

Там лежали протокол встречи, таблица с бюджетом, документ с требованиями, цепочка писем и несколько личных заметок. Один файл назывался «Бюджет_финал», второй — «Бюджет_финал_новый», третий — «Расчёт_последняя_версия». В письме от заказчика упоминалось 25 марта. В протоколе — 29 марта. В собственной заметке Анна записала: «Марина сказала: после закрытия квартала». Для финансовой службы закрытие квартала могло означать 31 марта, а для Марины — первую неделю апреля.

Нейросеть здесь была ни при чём. Путаница уже существовала в человеческих материалах. Если передать ей весь архив, она не обнаружит порядок, которого там не было. Зато быстро соберёт из разрозненных сведений убедительный, но ненадёжный план.

Пять мифов о рабочем контексте

Миф первый: нейросети нужен весь архив

Когда человеку кажется, что он «даёт максимум информации», он часто прикладывает всё подряд: длинную переписку, старые документы, несколько редакций таблиц, стенограммы встреч и собственные комментарии. Такой подход выглядит осторожным, но у него есть три слабых места.

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

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

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

Миф второй: самый новый файл автоматически самый актуальный

Дата изменения файла отвечает только на один вопрос: когда его в последний раз сохраняли. Она не говорит, согласованы ли содержащиеся в нём сведения.

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

Актуальность материала определяется не одной датой. Важно учитывать как минимум четыре вещи: когда его создали или изменили, кто внёс изменения, на основании чего они появились и получили ли подтверждение.

Поэтому фразы «возьми последнюю версию» недостаточно. Надёжнее сказать: «Используй расчёт от 16 марта, подтверждённый финансовой службой, а таблицу от 7 марта пометь как историческую».

Миф третий: если фраза записана, это уже факт

Документ может фиксировать факт того, что кто-то что-то написал, но не обязательно — факт о проекте.

Фраза «пилот начинается 29 марта» в протоколе означает как минимум следующее: в протоколе от определённой даты указана эта дата. Если протокол согласовали все участники, перед нами действующее решение. Если его разослали без подтверждения, это зафиксированное предложение. Если Анна записала фразу в блокнот по памяти, она свидетельствует об устной договорённости, которую ещё нужно проверить.

Одна и та же формулировка меняет управленческий смысл в зависимости от категории и источника.

«Пилот начинается 29 марта» как факт: в утверждённом протоколе указана дата 29 марта.

«Пилот начинается 29 марта» как предположение: Анна считает, что дата остаётся действующей, потому что не видела новых указаний.

«Пилот начинается 29 марта» как решение: участники выбрали эту дату, назначили ответственных и договорились о действиях до неё.

«Пилот начинается 29 марта» как вопрос: «Подтверждаем ли 29 марта после изменения состава работ?»

«Пилот начинается 29 марта» как ограничение: «Если запуск не состоится 29 марта, компания не успеет к обязательному внутреннему мероприятию».

Слова одинаковые, а управленческий смысл разный.

Миф четвёртый: противоречие надо убрать до передачи материалов

Попытка заранее «причесать» документы часто превращает неопределённость в скрытую ошибку. Человек выбирает одну дату, удаляет вторую и забывает, что решение было принято без достаточного основания.

Но у противоречия есть полезная функция: оно показывает место, где проекту требуется человеческое решение. Нейросеть может сравнить сведения, выделить последствия и подготовить варианты. Она не должна молча назначать победившую версию.

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

Миф пятый: один длинный запрос экономит время

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

Короткие порции дают управляемость. Сначала передаётся паспорт проекта, затем — источники по конкретному вопросу, а после этого — список противоречий и правила работы с ними. Так становится видно, на каком слое возникла ошибка.

Пять категорий, которые удерживают порядок

Чтобы собрать память проекта, Анна разделила сведения на пять простых категорий.

Факт — проверяемое утверждение, привязанное к источнику и дате. Факт может быть не самым приятным или не самым новым, но его можно предъявить и перепроверить.

Предположение — рабочая версия, интерпретация или прогноз, для которых пока нет достаточного подтверждения. Предположение допустимо использовать при планировании, если оно так и обозначено.

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

Вопрос — то, что необходимо уточнить, выбрать или подтвердить. Вопрос не нужно маскировать под уверенное утверждение.

Ограничение — условие, которое нельзя нарушить или можно изменить только отдельным согласованием. Это может быть срок финансового закрытия, лимит бюджета, требование безопасности, доступность специалиста или запрет на передачу персональных данных.

К этим категориям полезно добавлять источник, дату и степень доверия. Для Анны степень доверия не означала субъективное «верю — не верю». Она отражала силу основания: утверждённый документ, подтверждённое письмо, рабочая запись, устное сообщение или собственное предположение.

Запись «Марина согласовала запуск после 31 марта» в личном блокноте Анны можно было разделить на три части.

Факт: 13 марта Анна записала, что Марина сказала о запуске после 31 марта.

Предположение: Марина считает датой запуска 5 апреля.

Вопрос: какую дату закрепить в паспорте проекта?

Такое разбиение не делает Анну формалистом. Оно не даёт памяти незаметно превратиться в решение.

Дело о пропавшем контексте

Анна руководила проектом запуска внутреннего сервиса для заявок сотрудников. Сервис должен был упростить обработку обращений в хозяйственную службу и отдел закупок. В пилот предполагалось включить два подразделения, но точный состав функций и дата старта пока оставались предметом обсуждения.

До этого Анна компенсировала отсутствие общей системы собственной памятью. Она помнила, кто что сказал на встрече, в каком письме появился новый срок и почему одна функция исчезла из документа. Пока участников было трое, это работало. Когда к проекту подключились финансовая служба, разработчики и представители двух подразделений, память стала узким местом.

Первым делом Анна не стала читать всё подряд. Она сформулировала вопрос: «Что нужно знать, чтобы подготовить план до пилота и не перепутать утверждённые решения с предложениями?»

Затем открыла реестр источников. Это была простая таблица с шестью полями: код материала, тип, дата, владелец или автор, статус и краткое содержание. Каждый источник получил свой код.

S-01 — письмо Марины от 6 марта с темой «Пилот сервиса — ориентиры». В нём названа дата 25 марта. Статус: рабочая переписка, окончательная дата не подтверждена.

S-02 — протокол встречи от 12 марта. В нём указано 29 марта, а отправка уведомлений сотрудникам включена в число первоочередных работ. Статус: рабочий протокол, подтверждение участниками не найдено.

S-03 — таблица «Бюджет_финал», изменённая 7 марта. Общая сумма — 480 тысяч рублей. Автор не указан. Статус: устаревший расчёт.

S-04 — письмо финансовой службы от 16 марта. В нём указана предварительная сумма 620 тысяч рублей после добавления интеграции. Статус: актуальная оценка, утверждение лимита не найдено.

S-05 — личная заметка Анны от 13 марта: «Марина: уведомления пока не включаем, запуск после закрытия квартала». Статус: запись устной договорённости, требует подтверждения.

S-06 — документ с требованиями, редакция 2 от 14 марта. В разделе о пилоте уведомления обозначены как функция первого этапа. Статус: рабочий документ, связь с протоколом неясна.

Уже на этом шаге стало понятно: проблема заключалась не в том, что Анна плохо искала файлы. Нужные материалы были найдены. Просто они не складывались в одну картину.

Илья, аналитик проекта, подошёл к её столу.

— S-05 лучше не использовать, — сказал он. — Это личная заметка. На неё нельзя опираться.

— На неё нельзя опираться как на утверждённое решение, — ответила Анна. — Но она показывает, что на встрече прозвучала другая позиция. Если выбросить заметку, мы потеряем сам факт разногласия.

Это различие оказалось полезным. Источник может быть слабым доказательством решения, но сильным сигналом для проверки.

Дальше Анна проверила не только сами файлы, но и цепочку их появления. Письмо с протоколом отправили на следующий день после встречи. В ответах не было явного «подтверждаю». Один участник написал: «По своей части возражений нет». Марина не ответила на письмо, но на более позднем созвоне назвала другую дату.

Таблица с бюджетом оказалась приложением к старому письму. Файл с названием «Бюджет_финал_новый» содержал дополнительные расходы, но не имел отметки о согласовании. В нём появилась новая сумма, однако не было объяснения, какие строки изменились и кто их подтвердил.

Анна не стала решать, какая сумма «правильная». Она записала:

Факт: в расчёте от 7 марта указано 480 тысяч рублей.

Факт: 16 марта финансовая служба сообщила предварительную оценку 620 тысяч рублей.

Вопрос: какой лимит бюджета утверждён для пилота?

Ограничение: до подтверждения лимита нельзя обещать закупку дополнительных работ.

Илья сначала предложил взять 620 тысяч:

— Это же свежая цифра.

Анна показала ему поле статуса.

— Свежая оценка не равна утверждённому бюджету. Мы можем планировать по ней резерв, но не сообщать команде, что деньги выделены.

В тот же день Анна написала Марине:

«Собрала расхождения перед подготовкой плана. В письме от 6 марта указан ориентир 25 марта, в протоколе от 12 марта — 29 марта. Сегодня вы сказали, что имели в виду другой срок. Подтвердите, пожалуйста, какую дату считаем целевой для пилота. До подтверждения сохраню все три сведения в реестре и не буду называть одну из них утверждённой».

Марина ответила почти сразу:

— Я имела в виду другой срок — 5 апреля. Просто на встрече мы говорили о подготовке, а не об открытии доступа сотрудникам.

Это объяснение не отменяло записи в протоколе. Оно показало, что участники использовали слово «пилот» для разных этапов. Для Анны 29 марта означало готовность системы к проверке. Для Марины 5 апреля — первый день, когда сотрудники должны получить доступ.

Спор о памяти превратился в уточнение терминов. Анна ответила:

«Тогда зафиксирую два события: готовность к внутренней проверке и открытие доступа сотрудникам. Прошу подтвердить: 29 марта — техническая готовность, 5 апреля — начало пилота для двух подразделений? Отдельно уточним, входят ли уведомления в первую версию».

Так появился не один новый срок, а более точная схема. Нейросеть позже могла помочь разложить задачи по этапам, но не должна была сама решать, какое значение вкладывать в слово «пилот».

Минимальный паспорт проекта

После инвентаризации Анна собрала короткий паспорт. Она сознательно не включала туда всю историю переписки. Паспорт должен был умещаться на одном экране и отвечать на пять вопросов.

Цель

Провести ограниченный пилот внутреннего сервиса для заявок сотрудников в двух подразделениях и проверить, можно ли перевести основные обращения в единый процесс.

Участники и роли

Анна — руководитель проекта, отвечает за координацию и итоговый план.

Марина — внутренний заказчик, подтверждает ожидания и критерии результата.

Илья — аналитик, проверяет требования и собирает обратную связь.

Команда разработки — готовит сервис и исправляет выявленные ошибки.

Финансовая служба — подтверждает оценку затрат и допустимый лимит.

Сроки

29 марта — дата технической готовности согласно рабочему протоколу.

5 апреля — предполагаемая дата открытия доступа сотрудникам по уточнению Марины; требуется письменное подтверждение.

25 марта — прежний ориентир из письма; считать его устаревшим до отдельного решения.

Критерии результата

В пилот включены два подразделения.

Сотрудники могут создать заявку и увидеть её статус.

Основные ошибки фиксируются и распределяются по ответственным.

Критерии по количеству заявок, времени обработки и составу уведомлений требуют подтверждения.

Текущий статус

Требования находятся в рабочей редакции. Прототип готовится к внутренней проверке. Дата открытия доступа, состав функций первой версии и лимит бюджета не подтверждены. Есть противоречие по уведомлениям: протокол и документ требований включают их в первый этап, а личная запись Анны отражает противоположную устную договорённость.

Такой паспорт не пытается выглядеть завершённым. Его сила как раз в видимых пробелах. Если параметр неизвестен, рядом стоит «не подтверждено», а не случайная дата, которую читатель может принять за решение.

Порции контекста вместо текстовой свалки

Для первого рабочего запроса Анна разделила материалы на три порции.

Первая порция задавала ориентацию: паспорт проекта и одна фраза о задаче — «Подготовить список действий до технической проверки и открытия доступа сотрудникам».

Во вторую вошли доказательства. Анна добавила только выдержки из S-02, S-04 и S-06, а также указала, что S-01, S-03 и S-05 имеют исторический или неподтверждённый статус. Вставлять весь десятистраничный протокол не требовалось. Достаточно было фрагментов, связанных со сроками, бюджетом и составом первой версии.

Третья порция содержала неопределённости. В ней были три вопроса:

Какую дату считать открытием доступа сотрудникам?

Входит ли уведомление о смене статуса заявки в первую версию?

Какой бюджет считать основанием для подготовки плана?

У каждой неопределённости был указан источник и человек, который мог её закрыть.

Для разных задач нужны разные порции. Если Анна попросит нейросеть подготовить вопросы к Марине, ей понадобятся список противоречий и история решений. Если нужно проверить полноту требований, важнее документ с функциями, критерии результата и ограничения команды разработки. Если необходимо составить финансовый сценарий, в запрос не стоит добавлять всю переписку о пользовательском интерфейсе.

Порцию определяет не объём текста, а один рабочий вопрос. Хорошая подборка материалов позволяет ответить на него, не заставляя нейросеть угадывать, какие сведения главные.

В начало каждого запроса Анна добавляла короткие правила:

«Разделяй факты, предположения, решения, вопросы и ограничения. Не считай дату или сумму утверждённой, если в материалах нет подтверждения. При противоречии покажи оба источника и предложи вопрос для уточнения. Не выбирай вариант самостоятельно. Для каждого вывода указывай код источника».

Эти правила не заменяют проверку, но удерживают модель от самой опасной ошибки — уверенного заполнения пробелов.

Версии, которые можно найти через месяц

Память проекта разрушается не только из-за противоречий. Она слабеет и тогда, когда человек не может ответить, откуда взялась текущая редакция документа.

Анна ввела простую схему именования:

ГГГГ-ММ-ДД_название_версия_статус

Например:

2025-03-18_Паспорт_проекта_v01_рабочий

2025-03-19_Паспорт_проекта_v02_на-согласовании

2025-03-20_Паспорт_проекта_v03_утверждено

Дата в имени показывает дату выпуска редакции, но не дату принятия решения. Статус «утверждено» появляется только после явного подтверждения. Файлы с названиями «финал», «финал новый» и «финал точно» Анна переименовала или перенесла в архив: такие слова не помогают восстановить историю.

К каждой новой версии она добавляла короткий журнал изменений:

18 марта, v01. Собран первый паспорт по источникам S-01—S-06. Добавлены противоречия по сроку, бюджету и уведомлениям.

19 марта, v02. Добавлено уточнение Марины о дате 5 апреля. Дата открытия доступа не утверждена. Раздел о технической готовности сохранён отдельно. В разделе бюджета 480 тысяч отмечены как устаревшая оценка, а 620 тысяч — как предварительная оценка финансовой службы.

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

Для каждого существенного изменения полезно фиксировать четыре элемента: что изменилось, почему, кто сообщил или подтвердил это и в какой источник внесено изменение.

Короткая формула для разговора с участником проекта звучит так:

«Я не меняю старую запись задним числом. Добавляю новое уточнение с датой и источником, а после подтверждения обновлю текущую версию».

Это особенно полезно, когда кто-то говорит: «Мы же давно договорились иначе». Вместо спора о памяти появляется проверяемая последовательность записей.

Как работать с противоречиями

Анна создала отдельный реестр противоречий. Для каждого пункта она указывала тему, версии, влияние и следующий шаг.

Противоречие C-01. Срок открытия доступа.

Источник S-01: ориентир 25 марта.

Источник S-02: техническая готовность 29 марта.

Уточнение Марины от 19 марта: открытие доступа 5 апреля.

Текущий статус: требуется письменное подтверждение разделения двух этапов.

Влияние: нельзя окончательно составить календарный план обучения и коммуникаций.

Ответственные за уточнение: Марина и Анна.

Противоречие C-02. Бюджет.

Источник S-03: 480 тысяч рублей, расчёт от 7 марта.

Источник S-04: 620 тысяч рублей, предварительная оценка от 16 марта.

Текущий статус: лимит не утверждён.

Влияние: нельзя подтверждать дополнительные работы и выбирать вариант с интеграцией.

Ответственный за уточнение: финансовая служба.

Противоречие C-03. Уведомления.

Источник S-02 и S-06: уведомления входят в первую версию.

Источник S-05: в устной договорённости уведомления отложены.

Текущий статус: содержание устной договорённости нужно подтвердить.

Влияние: меняются требования к разработке и критерии готовности.

Ответственные за уточнение: Марина и команда разработки.

Такой реестр полезнее, чем фраза «надо всё проверить». В нём видно, что именно проверять, у кого спрашивать и почему это влияет на план.

Чего делать не следует

Не объединяйте две даты в расплывчатое «конец марта — начало апреля». Такая формулировка выглядит осторожной, но не помогает назначить работу.

Не удаляйте старый бюджет только потому, что появилась новая сумма. Старая версия может понадобиться, чтобы понять, какие расходы изменились.

Устное сообщение фиксируйте как сигнал, а не как утверждённое решение. Его можно сохранить в реестре, но нужно запросить подтверждение.

Не просите нейросеть «выбрать правильную версию». Правильность в таких вопросах определяется полномочиями, договорённостями и последствиями, а не вероятностью текста.

Наконец, не передавайте в рабочий пакет лишние персональные данные, пароли и внутреннюю информацию, которая не нужна для задачи. Если в документах есть данные сотрудников или клиентов, их нужно обезличить и использовать только разрешённую компанией среду.

Мастерская сборки паспорта

Этот процесс можно повторить на любом текущем проекте за один рабочий подход.

Сначала создайте реестр источников и в течение десяти минут перечислите материалы, которые действительно участвуют в проекте: письма, документы, протоколы, таблицы, записи встреч, личные заметки. Не пытайтесь сразу читать всё. Зафиксируйте название, дату, автора, статус и тему.

Затем выберите пять—десять утверждений, без которых невозможно принять ближайшее решение. Рядом с каждым укажите категорию: факт, предположение, решение, вопрос или ограничение. Если категорию определить не удаётся, это не ошибка классификации, а сигнал, что утверждение плохо зафиксировано.

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

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

Перед передачей контекста нейросети проведите короткую проверку.

1. У каждого ключевого факта есть источник и дата.

2. Предположения не оформлены как решения.

3. У решений указан статус: действующее, выполненное, отменённое или требующее подтверждения.

4. Старые версии не удалены, но явно помечены как исторические.

5. Противоречия вынесены в отдельный список.

6. В пакет попали только материалы, связанные с текущей задачей.

7. Понятно, что считать актуальным на момент запроса.

8. Нейросети запрещено самостоятельно закрывать спорные вопросы.