- BrainTools - https://www.braintools.ru -
Мы работаем на крупном проекте, где присутствует десятки интеграций, сотни бизнес-сценариев, документация в Confluence, а теперь ещё и описания бизнес-сценариев с помощью ИИ прямо в репозиториях. Это здорово выручает для погружения в проект, но всё равно не покрывает всю картину при работе над конкретной доработкой. Поэтому в команде аналитиков мы начали заводить собственных ИИ-агентов: собираем в папку нужные репозитории из Git, БФТ от заказчика, заметки со встреч, и вместе с агентом проектируем и анализируем.
Дальше в статье мы разберём полный конвейер: как готовим данные для ИИ-агента, передаём ему контекст и затем превращаем результат анализа в готовое ЧТЗ. Без нормальной подготовки на входе даже самый умный агент выдаст ерунду, а Markdown-результат на выходе ещё нужно оформить в корпоративный .docx.
Если посмотреть на рабочий день аналитика, на него сыплется:
Если посмотреть на рабочий день аналитика, на него сыплется:
Устные договорённости с созвонов. «Мы тут обсудили… надо поправить логику [1] обработки статусов, ну ты понял – Ага, понял».
Формальные БФТ от заказчика в .docx. Иногда на 10-20 страниц с таблицами и вложенными списками.
Заметки самого аналитика, комментарии из документов или просто мысли из головы.
Историческая документация в Confluence, которая обновлялась последний раз года два-три назад.
Описание бизнес-сценариев в репозиториях в гите – вот это золото, которое с недавнего времени начали писать разработчики при создании и изменении кода, и которое мы потом ревьюим.
Теперь представьте, что вы открываете проект, а там уже лежит пачка репозиториев, БФТ на N страниц, итоги трёх встреч и ваши собственные заметки. И как это скормить AI-агенту, чтобы он все смог корректно обработать?
Ответ простой, нужен конвейер. Три инструмента, которые мы для себя выстроили:
Для начала, что вообще такое транскрайбер и зачем он аналитику. Транскрайбер (от английского transcribe – расшифровывать) – это инструмент, который переводит аудио в текст. Бывают облачные решения: те же Otter.ai, Sonix, встроенные движки в Zoom/Teams. Бывают локальные – и вот тут главный герой последних пары лет: Whisper от OpenAI. Он умеет гонять аудио в текст прямо на вашем железе, без интернета, и качество расшифровки для русского языка в последних версиях очень приличное.
У нас встречи с заказчиком проходят регулярно, и часто именно там всплывают ключевые детали: «А давайте ещё вот этот функционал добавим», «А вот этот сценарий теперь работает по-другому», «А этот параметр мы сможем тут отображать?» В протокол это попадает не всегда: кто-то что-то записал, кто-то нет.
У нас с заказчиками запрещено использовать ботов, подключаемых к встречам, поэтому мы пошли по другому пути: пишем аудио встречи (с согласия участников, разумеется) и прогоняем через транскрайбер. Сейчас есть куча вариантов: от внешних ИИ-инструментов до локальных моделей. Главное, что на выходе текстовый файл с расшифровкой.
Чтобы AI-агент понял суть, мы делаем второй шаг – смысловую выжимку. Берём LLM и просим: «Выдели из этого разговора договорённости, решения и требования, оформи в Markdown». На выходе получаем готовый конспект встречи с решениями и требованиями.
У нас в компании есть собственные ИИ-инструменты, которые могут делать это чудо всё разом: конвертация разговора в текст, а потом сразу выжимка этого текста. Но даже без корпоративных решений связка Whisper + LLM собирается в локальный прототип за полчаса.
Итак, со встречами разобрались, теперь про документы.
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 или просто запускать по кнопке.
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
Подчистить строки, которые остались пустыми.
Списки и таблицы не трогаем.
Как установить за пару минут:
Открываете Word, Alt+F11 – VBA.
Вставляете модуль с макросом.
Копируете Markdown-текст и вставляете “Вставить только текст” в шаблон документа.
Запускаете макрос ConvertMarkdownToDocx – готово.
Можно, конечно, взять python-docx (Python-библиотека для работы с .docx) и написать скрипт – мы пробовали и так. Выбирайте, что вам ближе.
ИИ часто ошибается, поэтому мы не отдаём результат агенту сразу. Вот что проверяем перед запуском:
Стенограмму – выборочно сверяем с исходной записью, особенно места с техническими терминами.
Выжимку – проверяем, что решения и требования не противоречат БФТ и коду.
Конвертированный .docx – выборочно смотрим, не потерялись ли таблицы и списки.
Источники – если требование было озвучено на встрече, помечаем его. Это помогает при разборе спорных моментов
Мы построили процесс подготовки данных, который превращает разрозненные записи, документы и код в проверяемый контекст требований, но все равно финальное решение всегда за человеком.
Вот наш конвейер целиком:

Аналитик утром заходит в папку проекта, а там уже:
описания бизнес-сценариев из гита,
выжимки со вчерашних встреч,
БФТ заказчика в читаемом виде.
Всё в Markdown. Можно открыть, почитать, дополнить и запустить AI-агента, а готовый результат отдать заказчику в .docx.
По нашим наблюдениям, после внедрения конвейера:
Обработка часовой встречи сократилась с 1–2 часов до 10–20 минут, включая проверку выжимки.
Подготовка .docx из Markdown занимает 5–10 минут вместо ручного форматирования документа.
Количество ошибок в требованиях снизилось примерно на 30% – большая часть данных проходит через выжимку и перекрёстную проверку.
Время написания итогового ЧТЗ сократилось с одного-двух дней до нескольких часов.
Это не отменило ревью, но сократило рутинную часть работы примерно вдвое, так что главное правило остаётся простым: без нормальной подготовки данных на входе даже самый умный агент выдаст ерунду.
Автор: PPR
Источник [2]
Сайт-источник BrainTools: https://www.braintools.ru
Путь до страницы источника: https://www.braintools.ru/article/36730
URLs in this post:
[1] логику: http://www.braintools.ru/article/7640
[2] Источник: https://habr.com/ru/companies/ppr/articles/1092374/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1092374
Нажмите здесь для печати.