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

Второй мозг начинается не с нейросети

В понедельник в 8:42 Анна открыла рабочую почту и увидела девять непрочитанных писем. В корпоративном чате мигали уведомления в трёх ветках: в одной Марина, внутренний заказчик проекта, спрашивала, можно ли уже сегодня дать финальную версию; в другой Илья просил подтвердить, какой из двух вариантов требований считать действующим; в третьей коллеги обсуждали время встречи, которая начиналась через двадцать минут.

На экране рядом стояли два документа с почти одинаковыми названиями. Один был создан в пятницу вечером, второй — в субботу утром. В обоих оставались комментарии, но часть замечаний относилась к уже отменённому варианту.

В 9:05 к Анне заглянул Павел.

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

Анна посмотрела на календарь. До совещания оставалось пятнадцать минут.

— Всё — это что именно?

— Ну, всё по проекту.

— А если в письме от пятницы написано одно, а в документе от субботы — другое?

— Она же умная. Наверняка поймёт.

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

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

Вечером Анна пыталась собрать из переписки документ для Марины. В 20:47 она отправила черновик. В 21:16 пришёл ответ: «Кажется, это не совсем то, о чём мы договорились». Анна перечитала файл и увидела, что перенесла в него старое ограничение, хотя на встрече его сняли.

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

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

Что Анна на самом деле хотела автоматизировать

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

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

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

У второго мозга есть четыре свойства.

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

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

В-третьих, второй мозг не отменяет необходимость выбора. Он помогает увидеть варианты, сгруппировать сведения и подготовить черновик, но не решает, каким компромиссом команда готова пожертвовать ради срока.

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

Где машина действительно усиливает работу

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

Прежде всего, это поиск связей.

Анна может попросить найти все упоминания срока запуска, собрать их по датам и отдельно показать противоречия. Такой запрос полезнее, чем вопрос «Что мне нужно знать о проекте?». В первом случае задано конкретное действие и понятен результат. Во втором нейросеть вынуждена сама решать, что считать важным.

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

Другая подходящая задача — подготовка черновика.

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

Ещё одна сильная сторона — сравнение.

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

Наконец, нейросеть хорошо структурирует неаккуратный материал.

Из заметок можно получить таблицу с колонками «решение», «задача», «ответственный», «срок», «открытый вопрос». Из переписки — список тем, которым не хватает ответа. Из набора комментариев — перечень замечаний, сгруппированных по разделам.

В таких случаях нейросеть усиливает мышление, потому что берёт на себя механическую часть работы: поиск, сортировку, сравнение и черновое оформление. Человек получает больше времени на анализ и выбор.

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

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

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

Что остаётся у человека

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

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

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

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

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

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

Мысленный эксперимент: передать машине весь рабочий день

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

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

В 10:20 в систему попадают документы с разными датами. Нейросеть находит противоречие и пытается сделать текст связным. Если ей не запретить додумывать, она может выбрать одну формулировку как актуальную просто потому, что та стоит в более новом файле или встречается чаще.

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

В 15:30 нейросеть готовит ответ Марине. Она видит, что в предыдущих письмах Анна обещала «вернуться с вариантом сегодня», и формулирует уверенный ответ. Но за это время выяснилось, что команда не получила данные от аналитиков. Текст получается гладким, а обещание — невыполнимым.

В 18:00 нейросеть собирает итоговый документ. В нём аккуратно соединены старые и новые сведения, но не отмечено, где именно они расходятся. Получается не хаос, а связная версия хаоса. Это опаснее: очевидную ошибку легче заметить, чем правдоподобный вывод без основания.

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

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

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

Аудит рабочего дня Анны

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

Анна решила считать отдельной операцией действие со схожими исходными данными и результатом. «Работа над запуском» — слишком широкая формулировка. «Свести протокол встречи в список решений и задач» — уже конкретная операция.

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

Результаты выглядели так.

Сведение записей встреч в решения и задачи. Четыре встречи в неделю, 2 часа 40 минут, пять возвратов. Цена ошибки высокая: потерянное решение задерживает проект. Контекст частичный — заметки и письма разбросаны. Результат можно измерить по времени до утверждения и числу пропущенных решений.

Поиск прежних договорённостей и версий требований. Семь поисковых операций, 2 часа 20 минут, три возврата. Цена ошибки средняя или высокая: можно случайно использовать старое условие. Контекст низкий, потому что материалы хранятся в нескольких местах. Результат измерим по времени поиска и числу найденных подтверждений.

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

Сверка версий требований. Три сравнения, три часа, четыре возврата. Цена ошибки высокая: неверный пункт попадёт в разработку. Контекст частичный, поскольку не все комментарии привязаны к версиям. Измерить результат можно по числу найденных расхождений и непросмотренных пунктов.

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

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

Всего набралось 34 операции, 16 часов 40 минут и 23 возврата к уже выполненной работе.

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

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

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

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

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

Выбор первого сценария

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

Для выбора Анна оставила четыре фильтра.

Частота. Если операция выполняется раз в квартал, на ней трудно быстро увидеть эффект. Повторяющееся действие даёт больше материала для сравнения.

Цена ошибки. Чем дороже ошибка, тем уже должна быть роль нейросети. Для внутреннего черновика можно разрешить широкий диапазон предложений. Для письма заказчику или документа, на основании которого начнут работу другие специалисты, нужна строгая проверка.

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

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

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

Анна и Илья обсудили несколько вариантов.

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

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

«Сверка требований» имела высокую ценность, но часть версий была неполной. Сначала требовалось установить, какие документы считать исходными.

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

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

Это уже совсем не то же самое, что «пусть нейросеть ведёт проект».

Граница пилота

Анна записала, что входит в процесс. На входе — повестка, заметки или расшифровка встречи, список участников и предыдущий реестр решений. На выходе — четыре раздела: принятые решения, обсуждавшиеся, но не принятые предложения, задачи с ответственными и сроками, открытые вопросы.

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

Для первого теста Анна подготовила рабочую рамку:

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

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

Илья добавил ещё одно условие:

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

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

Базовая точка до старта

До запуска Анна зафиксировала три числа, чтобы не подменять сравнение общим впечатлением «стало удобнее».

Первое — время. На обработку одной встречи уходило в среднем сорок минут, то есть 2 часа 40 минут на четыре встречи в неделю.

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

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

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

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

Проверка реальности для читателя

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

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

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

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

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

Выбирайте не более одного пилота. Его формула должна звучать так: «Из материала X получить результат Y, используя нейросеть для действий A и B; решение C остаётся за человеком». Для Анны это выглядело именно так: «Из материалов встречи получить черновик реестра; нейросеть ищет и структурирует, Анна проверяет статус решений и утверждает итог».

Ошибки, из-за которых пилот превращается в хаос

Самая частая ошибка — начинать с максимального объёма. «Загрузить всё по проекту» звучит энергично, но не задаёт ни результата, ни границ. Даже если система технически принимает много материалов, это не означает, что их можно смешивать.

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

Третья ошибка — принимать резюме за решение. Хорошая сводка может перечислить всё, что прозвучало на встрече. Но решение возникает только тогда, когда кто-то его принял. В реестре должны быть разные поля для принятого, предложенного и нерешённого.

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

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

Павел по-прежнему считал, что Анна слишком усложняет задачу.

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

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

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

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

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

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

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

В 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. Нейросети запрещено самостоятельно закрывать спорные вопросы.

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

«Используй паспорт проекта и выдержки из источников S-02, S-04 и S-06. Подготовь план действий до технической проверки и открытия доступа сотрудникам. Для каждого шага укажи основание. Разделяй подтверждённые сведения, предположения и открытые вопросы. Не выбирай дату запуска, бюджет или состав уведомлений самостоятельно. Если данных недостаточно, покажи, какое уточнение нужно получить и у кого. В результате дай последовательность действий на ближайшие две недели и отдельный список рисков».

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

Контекст, который переносится за пределы работы

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

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

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

Контекстный пакет Анны

Перед первым разговором с нейросетью Анна собрала финальный пакет из четырёх частей.

Первая часть — паспорт проекта на одну страницу.

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

Третья — реестр противоречий C-01—C-03 с датами, источниками, ответственными и влиянием на план.

Четвёртая — инструкция по работе с материалами и текущая задача.

В заголовке пакета она написала: «Актуально на 19 марта, 16:30. Дата открытия доступа, лимит бюджета и включение уведомлений не подтверждены».

Эта строка сделала больше, чем десятки пояснений в переписке. Она задала временную границу памяти. Если на следующий день Марина подтвердит 5 апреля, Анна не станет молча исправлять старый пакет. Она создаст новую версию, добавит источник и перенесёт один вопрос в раздел решений.

Илья посмотрел на собранные материалы и сказал:

— Раньше я думал, что нейросети нельзя доверять, потому что она иногда ошибается в фактах.

— Она ошибается не только из-за собственных знаний, — ответила Анна. — Иногда мы сами даём ей три несовместимые версии и просим говорить уверенно.

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

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