Аналитик и ИИ: три инструмента, которые превращают хаос в требования

Мы работаем на крупном проекте, где присутствует десятки интеграций, сотни бизнес-сценариев, документация в Confluence, а теперь ещё и описания бизнес-сценариев с помощью ИИ прямо в репозиториях. Это здорово выручает для погружения в проект, но всё равно не покрывает всю картину при работе над конкретной доработкой. Поэтому в команде аналитиков мы начали заводить собственных ИИ-агентов: собираем в папку нужные репозитории из Git, БФТ от заказчика, заметки со встреч, и вместе с агентом проектируем и анализируем.

Дальше в статье мы разберём полный конвейер: как готовим данные для ИИ-агента, передаём ему контекст и затем превращаем результат анализа в готовое ЧТЗ. Без нормальной подготовки на входе даже самый умный агент выдаст ерунду, а Markdown-результат на выходе ещё нужно оформить в корпоративный .docx.

Что у нас на входе?

Если посмотреть на рабочий день аналитика, на него сыплется:

• Если посмотреть на рабочий день аналитика, на него сыплется:

• Устные договорённости с созвонов. «Мы тут обсудили… надо поправить логику обработки статусов, ну ты понял – Ага, понял».

• Формальные БФТ от заказчика в .docx. Иногда на 10-20 страниц с таблицами и вложенными списками.

• Заметки самого аналитика, комментарии из документов или просто мысли из головы.

• Историческая документация в Confluence, которая обновлялась последний раз года два-три назад.

• Описание бизнес-сценариев в репозиториях в гите – вот это золото, которое с недавнего времени начали писать разработчики при создании и изменении кода, и которое мы потом ревьюим.

Теперь представьте, что вы открываете проект, а там уже лежит пачка репозиториев, БФТ на N страниц, итоги трёх встреч и ваши собственные заметки. И как это скормить AI-агенту, чтобы он все смог корректно обработать?

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

Инструмент 1. Транскрайбер: от голоса к смыслу

Для начала, что вообще такое транскрайбер и зачем он аналитику. Транскрайбер (от английского transcribe – расшифровывать) – это инструмент, который переводит аудио в текст. Бывают облачные решения: те же Otter.ai, Sonix, встроенные движки в Zoom/Teams. Бывают локальные – и вот тут главный герой последних пары лет: Whisper от OpenAI. Он умеет гонять аудио в текст прямо на вашем железе, без интернета, и качество расшифровки для русского языка в последних версиях очень приличное.

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

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

Чтобы AI-агент понял суть, мы делаем второй шаг – смысловую выжимку. Берём LLM и просим: «Выдели из этого разговора договорённости, решения и требования, оформи в Markdown». На выходе получаем готовый конспект встречи с решениями и требованиями.

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

Итак, со встречами разобрались, теперь про документы.

Инструмент 2. Pandoc: всё приводим к Markdown

Pandoc – это бесплатная консольная утилита с открытым исходным кодом. Она конвертирует документы между множеством форматов: из Word в Markdown, из Markdown в Word, из LaTeX в HTML и так далее. Проще всего представить Pandoc как одну команду, которой почти любой документ превращается в Markdown – и обратно в нужный формат.

Установка простая: для Windows скачиваете установщик с официального сайта, для Linux – «sudo apt install pandoc» или через brew на macOS. И всё, можно работать. Кстати, в VS Code есть отличное расширение Pandoc (ищется по имени, автор – DougFinke), которое позволяет конвертировать документы прямо из редактора по правому клику. Удобно, если вы не любите терминал.

Заказчик присылает БФТ в .docx, иногда в PDF, иногда вообще Excel с таблицами требований. Современные модели могут открывать эти форматы, но при извлечении часто теряются таблицы, списки, изображения и связи между разделами. Результат получается нестабильным – агент может пропустить важное или сделать неверный вывод.

В этом деле нас спасает Pandoc. Мы просто написали скрипт, и наш исходный файл успешно конвертировался в необходимый формат для AI-агента:

bash 
pandoc "ctz.docx" -o "ctz.md" --from docx --to gfm --wrap=none --extract-media=./media

Но тут у нас возникает проблема, что Pandoc не умеет форматировать под необходимые стили, принятые по ГОСТ. Мы много раз пробовали настроить конвертацию, но результат всё равно требовал ручной доработки.

Разберу флаги:  «--from docx» – исходный формат, «--to gfm» – целевой формат (GitHub-Flavored Markdown, умеет таблицы и всё что надо), «--wrap=none» – не разрывать строки по ширине (AI-агенту это только мешает), «--extract-media=./media» – картинки вытаскивает в отдельную папку и прописывает пути в Markdown. Если таблиц нет – хватит и «-t markdown».

Что особенно приятно – Pandoc можно встроить в CI/CD или просто запускать по кнопке.

Инструмент 3. Обратный путь: из Markdown в .docx

AI-агент отработал, выдал результат – например, проект ЧТЗ или анализ требований. Всё красиво, в Markdown. Но заказчику нужен полноценный ЧТЗ в формате .docx, потому что так принято.

Тут у нас два варианта:

Вариант А – простой

Pandoc и в обратную сторону умеет конвертировать файлы:

bash
pandoc output.md -f markdown -t docx -o result.docx

Но тут у нас возникает проблема, что Pandoc не умеет форматировать под необходимые стили, принятые по ГОСТ. Мы много раз пробовали настроить конвертацию, но результат всё равно требовал ручной доработки.

Вариант Б – для требовательных

Для ситуации, когда нужно тонко настроить шаблон, а именно шрифты, стили и колонтитулы,  мы написали простой макрос в Word, который конвертирует MD-формат под корпоративный шаблон. Этот инструмент был правда неожиданным решением для нас, но с конвертацией он прекрасно справляется. Вот, например, как выглядит обработка заголовков: ищем # и применяем стили Heading:

Sub ApplyHeadings()
    Dim para As Paragraph, level As Integer, i As Integer
    For Each para In ActiveDocument.Paragraphs
        level = 0
        For i = 1 To Len(para.Range.Text)
            If Mid(para.Range.Text, i, 1) = "#" Then
                level = level + 1
            Else
                Exit For
            End If
        Next i
        If level > 0 And level <= 6 Then
            para.Range.End = para.Range.Start + level
            para.Range.Delete
            Select Case level
                Case 1: para.Range.Style = wdStyleHeading1
                Case 2: para.Range.Style = wdStyleHeading2
                Case 3: para.Range.Style = wdStyleHeading3
                Case 4: para.Range.Style = wdStyleHeading4
                Case 5: para.Range.Style = wdStyleHeading5
                Case 6: para.Range.Style = wdStyleHeading6
            End Select
        End If
    Next para
End Sub

Полный макрос состоит из шести таких шагов:

Как устроен макрос (псевдокод)

1. NormalizeDocument

• мягкие переносы (^l -> ^p), убрать лишние пустые строки,  

• нормализовать пробелы, применить wdStyleNormal.

• Ведущие пробелы НЕ трогаем (они нужны для списков).

2. ApplyHeadings

• Найти строки с #, ## … ######, определить уровень, удалить #,

• применить Heading 1..6.

3. ApplyLists (ключевой)

• По количеству ведущих пробелов определить уровень (4 пробела = 1 уровень).

• Удалить пробелы и маркер (-, *, 1.),

• создать список через Word API, назначить стили

• “Маркированный список” / “Нумерованный список”.

4. ApplyCodeBlocksAsTable

• Найти блоки “`, заменить на таблицу 1×1,

• фиксированная ширина, без авто-подгона, стиль “Текст”.

5. ApplyInlineFormatting

• Find/Replace: жирный, курсив, код – шрифт с кавычками.

6. RemoveEmptyParagraphs

• Подчистить строки, которые остались пустыми.

• Списки и таблицы не трогаем.

Как установить за пару минут:

1. Открываете Word, Alt+F11 – VBA.

2. Вставляете модуль с макросом.

3. Копируете Markdown-текст и вставляете “Вставить только текст” в шаблон документа.

4. Запускаете макрос ConvertMarkdownToDocx – готово.

Можно, конечно, взять python-docx (Python-библиотека для работы с .docx) и написать скрипт – мы пробовали и так. Выбирайте, что вам ближе.

Контроль качества: что может пойти не так

ИИ часто ошибается, поэтому мы не отдаём результат агенту сразу. Вот что проверяем перед запуском:

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

• Выжимку – проверяем, что решения и требования не противоречат БФТ и коду.

• Конвертированный .docx – выборочно смотрим, не потерялись ли таблицы и списки.

• Источники – если требование было озвучено на встрече, помечаем его. Это помогает при разборе спорных моментов

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

Как это работает вместе

Вот наш конвейер целиком:

• описания бизнес-сценариев из гита,

• выжимки со вчерашних встреч,

• БФТ заказчика в читаемом виде.

Всё в Markdown. Можно открыть, почитать, дополнить и запустить AI-агента, а готовый результат отдать заказчику в .docx.

Что это нам дало

По нашим наблюдениям, после внедрения конвейера:

• Обработка часовой встречи сократилась с 1–2 часов до 10–20 минут, включая проверку выжимки.

• Подготовка .docx из Markdown занимает 5–10 минут вместо ручного форматирования документа.

• Количество ошибок в требованиях снизилось примерно на 30% – большая часть данных проходит через выжимку и перекрёстную проверку.

• Время написания итогового ЧТЗ сократилось с одного-двух дней до нескольких часов.

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