Как ИИ меняет отношения к документам в работе

Помните момент, когда вы впервые попробовали ChatGPT или GitHub Copilot? У меня это было похоже на взрыв: привычные процессы рухнули, а на их месте начала формироваться новая реальность.

У меня был похожий опыт. Ещё в 2022‑м (как только был выход из бета‑тестирования и запуск по подписке), поставив эксперимент с GitHub Copilot среди сотрудников, я увидел, как меняется скорость разработки и как опытным разработчикам помогает а джунов ставит только в тупик. Но главное открытие ждало впереди: ИИ не просто ускоряет работу — он заставляет переосмыслить сам подход к хранению и обработке информации.

Раньше я, как и многие, хранил готовые документы: Word‑отчёты, PowerPoint‑презентации, схемы в графических редакторах. Потом пришёл момент, когда я поймал себя на мысли:

«Почему я трачу время на поддержание десятков копий одного и того же текста? Почему не хранить „исходники“, а документы генерировать по мере необходимости — как сборку кода?»

Так родилась концепция, о которой я хочу рассказать.

Данная статья написана человеком, отредактирован с помощью ИИ‑ассистента.

Старый подход: хранение готовых документов

Традиционно мы привыкли работать так:

• отчёты в формате Word;

• презентации в PowerPoint;

• схемы и диаграммы в графических редакторах.

Я сам так работал годами. Но со временем стали очевидны проблемы:

1. Дублирование данных. Изменил что‑то в одном месте — нужно править во всех копиях. Забыл где-то до править и потом долго и мучительно вспоминай какая редакции последняя и где осталась правда!

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

3. Потеря контекста. Через полгода уже не помнишь, зачем и как создавался документ. А самое главное к какой версии и чему его привязать.

4. Жёсткая привязка к формату. Сложно адаптировать документ под новые задачи без потери структуры. И очень сложно его скормить LLM, распарсив содержимое и не потерять сути.

Новый подход: «исходники» вместо документов

Мой опыт показал: эффективнее хранить информацию в исходном виде, а документы генерировать по мере необходимости — как «билды» из кода.

Концепция проста:

• Исходники — это структурированные данные в машиночитаемом формате.

• Документы — автоматически генерируемые «выводы» для конкретных задач через workflows.

Практические примеры из моей практики

Текстовые документы:

• Исходник: текст в формате LaTeX или Markdown.

• Билд: PDF или Word‑документ для отправки заказчику.

• Мой кейс: описание сервиса храню в LaTeX. Когда нужно отправить версию клиенту, генерирую Word за минуту. Одно изменение в исходнике — все версии актуализированы.

Схемы и диаграммы:

• Исходник: код на PlantUML или DrawIO (да, тоже можно в LLM скормить).

• Билд: PNG/SVG‑изображение схемы.

• Мой опыт: при изменении последовательности действий в сервисе правлю 2–3 строки кода PlantUML — и получаю обновлённую диаграмму. Никаких кликов в графических редакторах.

Техническая документация:

• Исходник: .md файлы + спецификации в YAML/JSON.

• Билд: HTML‑страница, PDF‑руководство или Word‑документ.

• Как я это использую: комментарии к API автоматически собираются в документацию через Sphinx.

Отчёты и аналитика:

• Исходник: Только HTML с кодом и данными.

• Билд: интерактивная веб‑страница или статичный PDF.

• Пример: ежедневные отчёты по метрикам проекта генерируются автоматически из логов.

Презентации:

• Исходник: LaTeX или Markdown‑файл с разметкой.

• Билд: PowerPoint или Google Slides через Pandoc.

• Мой сценарий: черновик презентации для митапа собираю за 10 минут из заметок в Markdown.

Роль ИИ в новой парадигме

ИИ‑ассистенты стали «сборщиками» документов из исходников. Вот как это работает на практике.

Задача: создать заявку на открытие доступов в разрабатываемом решении на основе шаблона и текущих данных проекта.

Мой рабочий процесс:

1. Формирую промт в LLM:

   «На основе шаблона template.tex и описания проекта project.md создай новый документ с заполненным описанием. Добавь данные из диаграммы последовательности diagram.puml в таблицу открываемых доступов. Оформи в стиле ГОСТ n.n.n».

2. Готом flow для LLM:

   • извлекает структуру из шаблона;

   • интегрирует данные из Markdown и PlantUML;

   • генерирует текст с соблюдением требований;

   • выдаёт готовый документ в нужном формате.

Результат: отчёт готов за минуты вместо часов ручной работы.

Какие Flow у меня получилось сделать в Directus

Я решил отказаться от облачных AI‑сервисов в пользу локального решения — и вот что получилось. Локальная LLM на базе DeepSeek, развёрнутая через Ollama, полностью исключает передачу данных наружу и даёт полный контроль над инфраструктурой. В качестве центрального хранилища и платформы автоматизации я выбрал Directus с возможностью low‑code‑платформа с элементами no‑code (n8n то-же очень хорошо, но было лениво настраивать отдельно хранилище). Через его механизм Flow настроил интеграцию с моделью: теперь система сама берёт данные из Directus и генерирует нужный контент. На практике это уже сэкономило массу времени. Автоматизировал генерацию документов и обработку заявок на учёту записей и предоставление доступов — всё работает на основе шаблонов и запускается парой кликов. Но покажу на примерах более интересные кейсы.

Пример 1. Генерация схем архитектуры

Подготовка схем для первичного обсуждения предлагаемого решения

Исходник: описание компонентов системы в .md или .tex файлах расположенных в Directus.

Мой сценарий:

1. Я меняю JSON‑описание (например, добавляет новый микросервис).

2. Directus запускает Flow.

3. Ollama генерирует код PlantUML: «На основе JSON‑описания создай диаграмму компонентов в синтаксисе PlantUML».

4. PlantUML компилируется в SVG.

5. SVG сохраняется в Directus и встраивается в Bookstack статью которую мы обсудим на дели. Если работаем с Confluence то сразу PlantUML вставляется

Пример 2. Персонализированные отчёты

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

Исходники: шаблон отчёта в LaTeX с кейсами по анализу (ключевое что в шаблоне уже есть нужные блоки и описания) в Directus только Flow вызывающий источник с логами. Да логи заранее обрадатываются полуручным способов и складываются в ELK

Мой Flow:

1. Directus извлекает данные из ELK.

2. Ollama создаёт отчёт: «Произведи расчёт утилизации RAM, CPU за период X. Сгенерируй отчёт обоснования увеличения ресурсов на основания расчёта. Используй шаблон LaTeX. Вставь данные: {{sales_data}}».

3. Ollama генерирует новый Markdown-файл с описанием из-за каких частных обращений API или запросов SQL произошла просадка.

4. Directus компилирует из Markdown файл PDF для обсуждения с командой т.к. в лоб решить одним отчётом не получится. Часто как обычно это просадка из-за не верного SQL запроса;

5. Создание встречу в календаре с обоснованием и вложением (нода Email).

Пример 3. Автоматическая документация к проекту

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

Исходники:

• комментарии в коде (Java/Python/JS) с тегами @param, @return, @example;

• OpenAPI‑спецификация в YAML (для REST API);

• файлы автоматизации и скрипты сборки (Dockerfile, docker‑compose.yml, Makefile);

• архитектурные схемы и диаграммы компонентов в PlantUML.

Мой Flow:

1. Триггер: коммит в GitLab (вебхук) на новый тег

2. Directus забирает код из репозитория и извлекает всё по группам, отдельно OpenAPI‑спецификацию, Dockerfile т.к. это разные под процессы анализа и описания;

3. Отправляет в Ollama в параллель несколько запросов: «На основе Dockerfile и конфигурационных файлов (.env, .ini, .yml) создай Markdown‑документацию описывающею процесс сборки и создаваемые решения. Раздели на разделы: „описание“, „подготовка“, „конфигурация“, „сборка“» и так-же «На основе OpenAPI‑спецификации создай Markdown‑документацию. Раздели на разделы: „API Reference“, „Code Examples“, „Architecture“. Добавь ссылки между разделами» таких запросом может быть n, но итоговой всегда будет «Сделай Readme.md из Markdown‑документации».

4. Ollama генерирует структурированный Markdown.

5. Directus и встраивается в Confluence

Пример 4. Roadmap запланированных работ

Раньше roadmap я делал в Excel или Miro — красиво, но статично. При любом изменении нужно было перерисовывать, обновлять статусы вручную. Теперь использую подход «исходник → билд».

Исходник: Markdown‑файл с разметкой roadmap в формате таблицы или списка задач с метками приоритета и сроков.

Мой Flow:

1. Правлю Markdown‑файл — добавляю задачи, меняю сроки, отмечаю выполненные.

2. Запускаю flow в Directus и он отправляет в Ollama запрос: «На основе Markdown‑roadmap создай PlatUML доиграмму ганта. Добавь цветовые метки для приоритетов (красный — высокий, жёлтый — средний, зелёный — низкий). Покажи прогресс‑бар по каждому кварталу».

3. PlantUML компилируется в SVG и сохраняет .

4. SVG сохраняется в Directus и встраивается в Bookstack статью которую мы обсудим на дели. Если работаем с Confluence то сразу PlantUML вставляется

Выводы

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

• превратить информацию в «сырьё» для автоматической сборки;

• избавиться от рутинного форматирования и копирования;

• сосредоточиться на сути задачи, а не на оформлении.

Дополнительно локальная экосистема на базе Ollama + Directus превращает ИИ в персонального ассистента для работы с информацией. Вы:

• храните данные в структурированном виде («исходники»);

• используете LLM для «сборки» документов под конкретные задачи;

• автоматизируете процессы от начала до конца.

Что делать дальше?

• Начните с малого: выберите один тип документа (например, отчёт или схему) и переведите его в формат исходника.

• Настройте автоматическую генерацию «билдов» простом промтом для онлайн чатов.

• Постепенно расширяйте подход на другие виды информации и объединяйте кейсы.

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

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

Если будет интересно готов расписать мой кейс в Туториал про настройку Ollama + Directus 🙂