«Второй мозг» проекта: как ИИ пишет ТЗ по записям встреч с заказчиком

Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.

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

Проблема

Команда SellOut+ внедряла у крупного клиента систему планирования: автоматиизировала работу с розничными сетями, контракты, инвестиции, коммерческие условия и связанную финансовую логику. У заказчика уже была старая система, и проект стартовал с формулировки: «Сделайте так же, но лучше».

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

На практике рядом с документами всегда остаются:

• Старая система

• Показы заказчика на звонках

• Устные пояснения

• Исключения, которые «и так понятны» тем, кто давно работает в процессе

• Решения, которые всплывают между делом на демо или в обсуждении спорного сценария

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

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

С чего началось решение

Незадолго до этого вышел материал про подход LLM Wiki от бывшего директора по ИИ в Tesla и сооснователя OpenAI Андрея Карпаты. Это идея о том, что можно брать исходные записи, прогонять их через языковую модель, раскладывать по нормализованной структуре и потом работать уже не с хаосом источников, а с упорядоченной базой знаний.

Эта идея вдохновила команду. Под базу знаний проекта завели отдельный репозиторий. Сначала в него складывали исходные записи: аудио со встреч. Потом — транскрибации. Идея была простой: не заменить задачи и проектные документы, а собрать под ними полный слой проектной памяти. Уже из него можно было уточнять ТЗ, проверять спорные места и обновлять основные статьи без гадания по воспоминаниям. Первая структура проектной памяти представлялась так:

Ключевой момент для этого кейса: вся цепочка должна быть спроектирована под локальный контур. Чтобы команда вообще могла применять такой подход на проекте.

Где работали

Уже на этом уровне у кейса было две среды работы. Сам конвейер сначала собирался локально: через VS Code, скиллы и скрипты. А когда из него начинала получаться живая база знаний, в игру входил Gramax — место, где ее удобно читать, править, обсуждать и показывать другим.

Чем обрабатывали

Что подавали на вход

1 этап. Собрать исходные материалы

На старте пайплайн выглядел так:

1. Берем запись встречи

2. Получаем транскрибацию

3. Складываем ее в каталог с исходными записями

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

В репозитории сохранился и отдельный скрипт превращения аудио в транскрибацию. Он был довольно приземленным, но именно поэтому полезным для повторения:

1. Читает аудиофайлы из каталога с исходными материалами

2. Пропускает дубликаты по хешу

3. Не трогает то, что уже транскрибировано

4. Передает локальному распознавателю список проектных терминов

5. Сохраняет результат в Markdown с таймкодами по сегментам

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

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

Этот словарь в репозитории тоже лежит обычным Markdown-файлом. В нем собраны группы вариантов вида:

• СКЮ, ISKU, ИСКОМ → SKU

• PNL, ПНЛ, PML → P&L

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

Один из участников проекта сформулировал это так:

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

Иначе говоря: неидеальные исходные материалы не означают бесполезные исходные материалы.

2 этап. Превратить архив встреч в базу знаний

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

2.1. Научить агента разбирать одну встречу

Здесь хорошо сработал простой инженерный принцип: скиллы были короткими. Не на 300 строк инструкций, а на 50-70. Чем короче и конкретнее инструкция, тем надежнее работала цепочка.

«Все скиллы по 50-70 строк. Мы специально делали их короткими, чтобы не перегружать контекст. Так надежнее работает»

Один проход по одной встрече выглядел примерно так:

1. В docs/raw/YYYY/ появляется транскрибация или конспект встречи.

2. Файл проходит нормализацию: механические замены, исправление терминов по словарю и минимальную починку явных артефактов распознавания.

3. В docs/raw/_index.md и корневой index.md добавляется новая запись, чтобы источник появился в общей карте репозитория.

4. Запускается ingest-source. Он режет встречу на темы, присваивает им T001, T002 и так далее и создает processing/<source>.ingestion.md.

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

6. Каждая тема направляется в свою основную статью по правилу «один факт — одно место».

7. Если источник меняет существующее правило, расчет, поле, рабочий процесс или срок, это не перетирается молча: в журнале появляется блок с противоречиями и вопросами для ручной проверки.

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

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

2.2. Зафиксировать промежуточные артефакты

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

1. Исходная транскрибация. В docs/raw/ лежит очищенный текст с таймкодами по сегментам. Это не краткий пересказ, а источник, к которому можно вернуться, если в нормализованной базе что-то не нашлось или есть спор по формулировке.

2. Журнал разбора. Для каждого источника создавался отдельный файл в processing/. В нем были:

   • Topic Map — список тем встречи с таймкодами, целевой страницей, действием и итоговым статусом

   • Extracted Items — факты, правила, решения, требования и вопросы, уже разложенные по основным статьям

   • Cross-References — где надо было проставить ссылки между страницами

   • Contradictions — что в новом источнике расходится с текущей базой знаний

   • Escalations — где нельзя автоматически принять решение без человека

   • Verification — контрольный чек-лист качества

   • Completion Summary — сколько тем разобрано, сколько задокументировано и какие страницы поменялись

3. Протокол встречи. Из каждой встречи создавался отдельный компактный протокол в docs/project-management/meetings/YYYY/. Она не дублировала всю транскрибацию, а служила кратким индексом встречи. Фиксированная форма была такой:

   • Один абзац, что именно закрепила встреча

   • Основные темы

   • Открытые вопросы

   • Внизу свернутый блок Источники со ссылкой на raw-файл

4. Основные статьи. Нормализованная база знаний жила не во встречах, а в основных статьях. Например, правила прогноза шли в статью про прогноз, логика БС и УСТМ — в статьи про бюджеты, продуктовые договоренности — в project-management/decisions/product/.

5. Страницы решений. Если на встрече принималось отдельное решение, создавалась отдельная страница решения с блоками Решение, Контекст, Последствия, Утратило силу в пользу и Источники.

Именно такой набор артефактов сделал процесс воспроизводимым. Человек видел не только итоговую статью, но и весь маршрут, по которому агент к ней пришел.

2.3. Ввести ограничения, чтобы база не расползалась

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

Вот какие ограничения были зашиты в процесс:

• У каждой темы из источника должен быть ровно один финальный статус: documented, merged, duplicate, irrelevant, open-question или blocked

• Каждая содержательная тема обязана иметь целевую страницу или явную причину, почему она не легла в вики

• Один факт живет ровно в одной основной статье

• Обзорные страницы и _index.md не должны повторять деталь, а только объяснять границы и давать ссылки

• Противоречия нельзя затирать молча: старая и новая версии должны быть явно зафиксированы

• Открытые вопросы нельзя прятать на потом: они должны оставаться видимыми

• Каждая затронутая нормализованная страница должна иметь блок Источники, чтобы было понятно, из каких материалов она обновлялась

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

2.4. Понять, что первая структура не подходит

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

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

2.5. Перестроить базу по логике Diátaxis

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

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

• Быстрый старт и пользовательские сценарии

• Инструкции и рабочие действия

• Бизнес-процессы и правила системы

• Проектный контекст, решения и протоколы со встреч

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

2.6. Оформить зрелую структуру репозитория

Ниже я показываю уже итоговую, устоявшуюся структуру репозитория, к которой команда пришла после этой перестройки.

project-docs/
├── AGENTS.md
├── index.md
├── docs/
│   ├── .doc-root.yaml
│   ├── business-processes/
│   ├── project-management/
│   ├── quick-start/
│   └── raw/
├── processing/
├── references/
├── scripts/
└── .gramax/fragments/

Если подробнее

• docs/ — нормализованная вики, то есть не исходные материалы, а уже собранная картина проекта.

• docs/raw/ — слой источников только для чтения: очищенные транскрибации и конспекты встреч, разложенные по датам.

• processing/ — журнал разбора источников. Для каждого источника создается отдельный файл <source>.ingestion.md, где видно, что агент извлек, куда это положил, что счел дублем, где увидел противоречие и что осталось открытым вопросом.

• references/ — внешние справочники, которые помогают чистить и нормализовать контент: словарь замен для транскрибации, список клиентов, список брендов.

• .gramax/fragments/ — глоссарий проекта в виде переиспользуемых терминов.

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

• AGENTS.md — короткие правила поведения для агента внутри репозитория: откуда начинать чтение, какие каталоги считаются источниками, где лежит журнал разбора и когда надо обновлять index.md.

Второй мозг появляется из правильно разведенных слоев:

• Исходные материалы отдельно

• Нормализованные знания отдельно

• Журнал обработки отдельно

• Словари и термины отдельно

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

2.7. Решить, что делать с противоречиями и открытыми вопросами

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

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

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

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

Оставшиеся вопросы отправляли коллегам маленькими порциями: не сто вопросов сразу, а по три-пять за раз. Так команда не теряла интерес к этим нюансам.

3 этап. Показать заказчику

Базу знаний отдали заказчику на ревью в виде портала документации с поиском.

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

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

4 этап. Отладить текучку

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

1. Проходит новая встреча с заказчиком

2. Появляется транскрибация

3. Агент сохраняет ее в папку с сырыми источниками

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

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

6. Обновленная база знаний становится доступна всей команде

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

1. Загружали готовую транскрибацию в агента Gramax

2. Агент раскладывал смысловые блоки по статьям

3. Человек смотрел дифф, принимал изменения, отклонял их или правил руками

Что это изменило в работе команды

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

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

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

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

В чем здесь помог Gramax

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

• Чтение и правка без боли от Markdown. Большой объем Markdown неудобно читать в текстовом виде. Особенно таблицы. Gramax стал способом смотреть на ту же базу знаний в нормальном, читаемом виде, спокойно ее вычитывать и при необходимости править через визуальный редактор. Это особенно важно в команде, где не все хотят жить в VS Code.

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

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

• Совместная работа и публикация без лишней инфраструктуры. Не нужно было идти в GitLab, поднимать отдельный портал или придумывать обходной путь: можно было просто отправить ссылку на редактор Gramax коллеге, попросить комментарий, а заказчику отдать читаемый портал с поиском и понятной структурой. Это снимало типичный конфликт между «нам удобно хранить знания в репозитории/заказчику нужно видеть нормальную документацию».

Если смотреть на это уже с продуктовой стороны, то здесь особенно хорошо сработали несколько архитектурных особенностей Gramax:

• Открытый текстовый формат, поверх которого вообще можно строить агентную работу

• Возможность работать с локальным каталогом как с обычным репозиторием

• Визуальный редактор поверх Markdown, который делает такую базу пригодной не только для разработчиков

• Наглядный дифф и история коммитов для отслеживания эволюции базы знаний

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

Где человек все еще незаменим

Помните, в начале статьи я показала предполагаемую структуру проектной памяти? Вот такой она стала по факту:

В этом кейсе ИИ не заменил аналитика. Человек все равно:

• Оценивал удачность структуры

• Решал, когда статья слишком длинная

• Принимал решения по спорным трактовкам

• Вычитывал результаты

• Корректировал стиль и плотность текста

• Проверял, что агент не придумал лишнего

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

Как видите, магии в духе «ИИ ведет проектную документацию сам» нет. Я бы сказала: 

«ИИ превращает десятки часов исходных материалов в черновик проектной памяти, который человек может быстро довести до рабочего состояния»

Что за MVP агента Gramax

Как я уже писала в начале статьи, мы сейчас строим ИИ-агента Gramax. Который сможет делать все то, что и локальные агенты, но в визуальном интерфейсе. В первой версии уже закрывается важная часть сценария команды, но не весь контур целиком.

• Агент работает в визуальном редакторе

• Можно подключить локальную модель для NDA-проектов

• Агент может дополнять существующие статьи, создавать новые, менять структуру документации

• Можно загружать в агента файлы как источники новых знаний

• Вести термины и переиспользуемые определения через фрагменты

• Разделять типы страниц и метаданные через свойства каталога

• Принимать изменения через понятный интерфейс визуального диффа

• Публиковать порталы для заказчиков или экспортировать доки в PDF или DOCX

Что пока остается за пределами идеального сценария:

• Встроенная транскрибация длинных встреч как часть продукта

• Совсем бесшовная загрузка и разбор исходных материалов

• Встроенный журнал разбора как объект продукта, а не только как пользовательский прием

• Полная стабильность сложных многошаговых агентных пайплайнов

• Нативная интеграция со связанными системами вроде таск-трекера.

Вместо итога

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

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

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

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

Если у вас уже есть похожий сценарий работы с документацией через агентов, Cursor, Claude Code, локальные модели или Markdown-репозитории — пишите! Просто обсудим или отгрузим вам Gramax для пилота:)

Открыто, бесплатно, и с сообществом

• Смотрите наш сайт — https://gram.ax

• Проверяйте исходники в GitHub и GitVerse

• Вступайте в комьюнити — https://t.me/gramax_chat