Как я создал сервис по написанию формальных документов

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

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

Сервис вот https://docsfactory.ru/

Краткая историческая справка

Если позволите, начну с краткой исторической справки.

В ноябре 2025-го, кажется, мы на работе в очередной раз закрывали в РГЖ (режиме горящей жопы) один из этапов госконтракта с полным пакетом документов. Я знаю, есть люди, которые любят рутинную работу (ну и подход типа день прошел — денюжка капнула), но для меня это просто треш: я уже в голове этот этап прокрутил и вижу следующую цель продукта, к которой надо идти, а тут какая-то нудятина с кучей согласований и формальностей, которая мне мешает. Это как в Dark Souls на хардах биться с боссом, который тебя постоянно выносит раз за разом, хотя ты пришел за сюжетом. Бесит в общем.

По опыту могу сказать, что на написание полного пакета документов под ключ уходит около 2.5 человеко-месяцев. Изначально всем (и менеджерам в особенности) этот объем видится меньше:

• неделя на ЧТЗ;

• неделя на пояснительную записку к тех. проекту;

• неделя на рук-во пользователя/администратора;

• неделя на ПМИ-шки;

• неделя на всякие прочие бумажки, акты-херакты и т.д.

Казалось бы.

В реальности объем раздувается примерно в 2 раза, тк начинаются согласования, какие-то вопросы/неточности, переделки. Приходится задействовать помимо техписа еще и аналитиков (иногда и не одного), чтобы они писали свой кусок функционала, с которым техпис не справляется, он может только стили поправить, но не шарит в технических деталях. В итоге потрачено много сил, и ладно бы, если можно было бы распараллелиться всей командой и закрыть это говнище за календарную неделю. Хрен с ним, по деньгам вышло бы также, но хотя бы по срокам это можно было бы «проглотить» и пойти дальше. Но нет, если накосячили в ЧТЗ — потом надо переделывать последовательно в пояснительной записке, рук-ве пользователя и ПМИ-шках. Что-то пропустил — куча времени потрачено, пока цикл согласования пройдет, пока тебе комменты накидают. Короче нудятина, я это уже говорил.

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

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

Концепция

Прежде чем описать суть решения, давайте я вначале вкратце расскажу, что такое закрывающие док-ты ГК (госконтракта). Без деталей, чисто суть в объеме, необходимом для дальнейшего материала.

Матчасть

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

На вход дается ТЗ (техническое задание)

На выходе образуется набор из 10+ документов, но основные — это:

• ЧТЗ (частное техническое задание);

• ПЗ (пояснительная записка);

• РП (рук-во пользователя);

• ПМИ (программа и методика испытаний). Их обычно 3 штуки — предварительные, приемочные, опытная эксплуатация.

Эти документы связаны между собой по формальным критериям — в ТЗ обозначаются требования к системе. Для простоты считаем, что каждое требование — это «объект». В ЧТЗ мы должны дать детализацию требований — написать по абзацу для каждого требования из ТЗ — по сути описать свойства этого объекта. В ПЗ описывается реализация требований ЧТЗ, это, своего рода, маппер между кодом и ЧТЗ, а в ПМИ — то, как требование правильно тестировать. В РП описывается то, как пользователь работает с запрашиваемой в ТЗ функцией (обращаю внимание, в РП не пишется рук-во пользователя по факту реализации, а именно то, как пользователю закрыть требование). Ниже я представляю сгенерированную схему, тк самому рисовать лень, а инструмент справляется не хуже:

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

• привести детализацию;

• описать реализацию;

• описать сценарии проверки;

• и описать, как пользователю с ним работать.

И все это в разных документах.

В каждом документе есть шаблонная часть и сутевая. Шаблонная часть обычно не меняется для данного заказчика от проекта к проекту, меняется только наполнение (сутевая часть).

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

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

Продуктовая гипотеза

Суть гипотезы, которую я хотел проверить сразу по выходу из больницы — а что будет, если llm скормить согласованные с заказчиком документы (да-да, NDA и все дела, но есть локальные модели или, на крайняк, обезличивание, с которым справляется даже Qwen 3.5: 4b), формат ЧТЗ и попросить написать требования в заданном формате. И знаете что?

Результат меня ошеломил, при том, что я скептик тот ещё и сделал задачу «в лоб» — я обезличил постановку, убрав из нее специфичные детали, заказчика, ФИО и т.д, скормил Chat GPT вместе с примером формулировок требований из ЧТЗ и написал довольно тупой промпт типа — вот пример, напиши мне результат. И он это сделал.

Моя стандартная оценка — примерно 20 минут на детализацию требования для ЧТЗ (в среднем). Модель мне детализировала 8 требований ЧТЗ за +- 10 минут с учетом подготовительных работ, с результатом, который в принципе я мог просто скопировать в документ, подогнав стили. Да, не все из них я писал бы 20 минут, но всё же. По итогу можно собрать пакет закрывающих документов как минимум в 5 раз быстрее. Конечно, согласование этим не ускорить, но непосредственно первичное наполнение — можно (и нужно, тк это нудятина).

Собственно, концепция

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

В рамках реализации функции «Фильтрация в списке задач на странице релиза» должно быть обеспечено:

• {{f1_detail_requirements}}

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

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

Понятное дело, что дьявол кроется в деталях (edge case в данном случае), но сама идея лежит на поверхности и довольно простая.

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

Чем это отличается от того, чтобы вкинуть все доки в Chat GPT и получить результат?

1. У меня типовой этап содержит около 50 требований и где-то 20-30 многостраничных (10+) документов, описывающих алгоритмы, экранные формы, сценарии использования, ролевку и так далее. Закинуть все в интерфейс чата можно, но тогда на выходе получится довольно урезанный результат, который нельзя без дополнительных правок отдать на проверку.
   Можно, конечно, в чат кидать по одному документу, но это все равно геморр, тк связь между документами и требованиями может быть многие-ко-многим.

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

3. Чат GPT(или любая другая модель, даже claude), пока еще плохо выдает результат в заданном шаблоне, он по сути собирает свой док, близкий к тому, что вы ей дали на вход. А в случае с закрывающими документами ГК нельзя выдать «близкий по формату» документ — вас попросят переделать.

При этом, я не говорю, что задачу нельзя решить через интерфейс чата — можно, но дольше.

Изначально я наговнякал на Python какое-то рабочее решение чисто для себя, потом прикинул, что у меня намечается свадьба, пополнение в семье, и надо искать альтернативные источники пополнения бюджета xD. Поэтому, надо думать не только о себе, но и о «среднестатистическом пользователе».

Пользовательский путь

С точки зрения пользователя, путь выглядит так:

1. Создать шаблон документа. Это можно сделать либо в текстовом редакторе (например, Word), либо в самом сервисе, я потратил довольно много ресурсов на внутрисистемный редактор, но сейчас это еще довольно сырая функция, могут быть баги.

2. Прицепить материалы

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

4. Написать промпт — что вы хотите получить на выходе. Можно воспользоваться шаблонами промптов и подправить только суть.

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

   

Функции для удобства

Что еще я в этот сервис постепенно добавляю:

1. Типовые шаблоны документов. Начал с ТЗ и ЧТЗ, постепенно добавляю все остальные шаблоны для того, чтобы пользователям не надо было с абсолютного нуля начинать знакомство с сервисом

   

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

   

   

3. Внутрисистемные конфиги промптов. Мне впадлу каждый раз писать один и тот же промпт (а в этом вся суть подобных решений – чем чётче вы напишете, что вы хотите получить – тем лучше будет результат), поэтому я сделал сохраняемые конфиги, в которых вы можете описать, что вы хотите от llm и потом многократно их переиспользовать.

4. Инфраструктурный сюрприз (пока не отладил его, но это точно будет работать – я арендовал зарубежный VPS и заверну через него трафик для работы с Claude или ChatGPT). Этого пока еще не сделано.

5. Поддержка локальных моделей. Уже сейчас можно развернуть у себя локальную модель и прогонять все вычисления через нее. Проверял на своем ноуте и как раз на Qwen 3.5:4b.

6. Использование MCP. Сделал и проверил на примере youtrack пока что — кидаешь в промпт ссылку на запрос задач и говоришь типа «вот список тикетов, вычлени из них функциональные требования для ТЗ».

Сценарии использования

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

1. Генерация закрывающих документов по ГК на основании имеющихся шаблонов и разнородного набора входных данных.

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

2. Наполнение сути ТЗ по тикетам.

   Еще один из типовых «болезненных» сценариев, которые обычно геморройно реализуются. Обычно в ходе работ заказчик то и дело просит вас сделать какие-то функции «авансом». Иногда они делаются ради исправления бага. Вначале вы по-пацански договариваетесь, что он получает результат сейчас, а потом вы эти фичи включаете в след ГК и получаете за них деньги в будущем. Проблема тут в том, что перебирать тикеты и вычленять из них ФТ – нудно. Сервис решает эту задачу так:

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

3. Отчет о проделанной работе

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

Заключение

В заключение хочу сказать пару слов, так сказать

Во-первых, что пользователь получает за свои деньги. Это набор шаблонных документов, которые используются для закрывающих документов ГК. Плюс ко всему, они еще и связаны между собой (сейчас полного набора документов нет, тк мне надо их шаблонизировать и обезличить, чтобы их можно было безопасно публиковать). Я сам, например, использую похожий пайплайн в работе. Плюс я ТОЧНО знаю, какие боли испытывают техписы и аналитики, потому что это моя специализация

Во-вторых, про llm. Пишу это, тк в России большое сообщество профильных специалистов с огромным опытом, которые все ещё считают, что llm делает шлак. Еще осенью 25го наш коллега показывал нам, как можно с помощью Claude Code, кажется, прогать. Показывал, что она верстает кнопочку. Модель в ходе демки накосячила и сделала какую-то хероту, но результат какой-то выдала. Я сам пробовал ее для своего симулятора, в котором на тот момент было что-то около 30к строчек кода. Модель нихера толком не сделала, контекста не хватало, галлюционировала и делала кривые решения. Даже тесты не могла нормальные написать, старалась подогнать их под «зеленый прогон». Хрень, одним словом.
Прошло чуть более полугода и ситуация кардинально поменялась. Если раньше я сам был против вайб-кодинга и писал об этом еще вот тут, то сейчас я перешел на другую сторону (переобулся, можно сказать). В какой-то момент я поймал себя на мысли, что мне проще написать запрос в модель и получить результат за 15 минут, чем давать задачу сотрудникам. И это касается не только написания кода, даже тупо по аналитике. Мы писали внутренние регламенты и надо было прошерстить пачку старых документов и натянуть их на новый процесс. Аналитик оценил задачу в 6 часов, делал ее по факту почти 2 дня, выдал просто кал, который я переписывал потом.
Аналогичный запрос байт-в-байт я положил в модель и она выдала намного более приемлемый результат.
Это же касается и кодинга.
Я это все к чему говорю. Этот сервис сделан с помощью вайб-кодинга (да, не на 100%, но все же). И если ещё пол-года назад я бы посмотрел на это со скепсисом, то сейчас я вынужден признать, что мои разрабы в моей компании сделали бы аналогичное решение слегка хуже.

Такие дела вот.