Мы работаем на крупном проекте, где присутствует десятки интеграций, сотни бизнес‑сценариев, документация в 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% — большая часть данных проходит через выжимку и перекрёстную проверку.

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

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