И снова привет!

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

В статье речь пойдёт об использовании редактора кода VS Code и его расширений для работы над текстом и кодом в проектах.

Переход в VS Code

Когда я только начинал работать над своими проектами, я перепробовал массу инструментов — от простых текстовых редакторов до полноценных IDE. Каждый из них решал свои задачи, и в целом меня всё устраивало, пока я не наткнулся на упоминание о работе в VS Code с помощью ИИ-агента. Решил попробовать — и этот эксперимент неожиданно мне понравился.

Сначала VS Code показался мне немного громоздким и непривычным. Но после нескольких дней настройки я понял, что его можно превратить в по-настоящему удобное и гибкое рабочее пространство: всё под рукой, стабильно работает и имеет множество расширений.

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

Со временем я начал пробовать и добавлять всё больше расширений для улучшения своей работы. Каждое из них решало маленькую задачу, но вместе они превратили VS Code в удобный инструмент, который подстраивается под меня, а не наоборот.

Ниже расскажу подробнее о некоторых расширениях, которые я использую.

Голосовой ввод в VS Code

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

1. VS Code Speech

Самый простой вариант — это установка расширения VS Code Speech, которое позволяет надиктовывать текст прямо в редактор. Поддержка русского языка включается через установку пакета Russian Language support for VS Code Speech.

Активировать работу расширения можно комбинацией клавиш Ctrl+Alt+V, после чего в поле ввода появится значок микрофона, а распознанный текст будет сразу отображаться в редакторе.

Минус этого расширения — не слишком высокая точность.

2. Whisper Assistance

Более качественный результат выдает расширение Whisper Assistance. Оно и не мудрено, ведь для распознавания голоса расширение использует модель Whisper от OpenAI. Для его работы потребуется немного DevOps-подхода, а именно развернуть модель локально, для того чтобы расширение могло использовать ее в своей работе.

Вся информация по развертыванию модели есть в Readme расширения, там описаны различные варианты, в том числе и запуск в docker. Docker у меня был как на локальной машине, так и на отдельной машине, где запущены различные сервисы и развернута LLM. Поэтому мне казалось, что запуск модели Whisper в Docker - это самый простой способ. Но как всегда, с первого раза у меня не все получилось, пришлось немного повозиться, чтобы настроить все это дело. Привожу краткие заметки по этому поводу на всякий случай.

git clone https://github.com/martin-opensky/whisper-assistant-vscode.git
cd whisper-assistant-vscode

...
@app.post("/v1/audio/transcriptions")\n\
async def transcribe_audio(\n\
    file: UploadFile = File(...),\n\
    model_name: str = "whisper-1",  # Renamed parameter to avoid conflict\n\
    language: str = "en"\n\
):\n\
...

docker build -t whisper-assistant:latest .
docker run -d -p 4444:4444 --gpus all --name whisper-assistant whisper-assistant:latest

В Windows версии я ставил sox.portable --version=14.4.1

После установки и настройки расширения в правом нижнем углу VS Code можно использовать команду расширения Whisper Assistance. Распознанный текст попадает в буфер обмена, и его остаётся только вставить в окно редактора или другое поле ввода.

Агенты и ассистенты на базе LLM

Когда черновик текста уже готов, можно подключать к работе ИИ.

Cline агент

Cline — расширение, которое умеет работать как с кодом, так и с текстами. Главный плюс — гибкость: можно подключить облачные LLM или локальные модели (например, запущенную через LM Studio). К слову, недавно вышла интересная статья Как с помощью локальной LLM автоматизировать рутину и облегчить жизнь себе и коллегам, где подробно показан процесс работы с API в LM Studio.

Cline подходит мне для решения различных задач от генерации и структурирования технической документации до написания кода прототипов.

Правила в Cline

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

• Локальными — действующими только в рамках текущего рабочего пространства

• Глобальными — применимыми ко всем проектам.

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

Этот файл служит отправной точкой для Cline (или другого агента). На основе описания из info.md агент может автоматически сгенерировать структуру проекта, создать базовые файлы и даже предложить начальные реализации алгоритмов в коде. Таким образом, чётко сформулированное описание значительно ускоряет и упрощает последующую разработку.

MCP в Cline

Современные языковые модели уже давно вышли за рамки просто «умных собеседников». Один из ярких примеров — поддержка Model Context Protocol (MCP).

MCP — это стандарт, который позволяет напрямую подключать к модели внешние источники данных, инструменты и API. По сути, это универсальный мост между LLM и каким-то технологическим стеком.

В ходе тестирования я подключал несколько провайдеров: Fetch-mcp, SearxNG-mcp, Redis-mcp и n8n-MCP. Удобно, что модель может сама найти информацию в интернет и сгенерировать цепочку или ее часть в n8n на основе задания.

Koda - умный автокомплит

Для меня Koda — это не просто инструмент для автодополнения, а ассистент по письму и контенту. В отличие от Cline, который позиционируется как интеграционная платформа на базе LLM, Koda делает ставку на умное автодополнение и помощь в формулировке мыслей. Проект форкнут от Continue, и более подробно о нем можно почитать в статье Koda: AI-помощник разработчика – бесплатно, без VPN, с поддержкой русского языка

Я пользуюсь как подсказками для автодополнения текста, так и пунктом контекстного меню "Fix Grammar / Spelling", но результаты обработки не всегда меня устраивают. Было бы здорово, если бы появилась возможность дополнения контекстного меню своими пунктами, для того чтобы можно было обрабатывать текст по нужным мне правилам.

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

Инфраструктура и организация окружения

Важно подчеркнуть, что и Cline, и Koda поддерживают работу не только с облачными LLM, но и с локально развернутыми моделями. Это особенно полезно для проектов, где критична приватность данных или важно, чтобы была возможность тонкой настройки окружения под специфические задачи.

В моём случае на отдельной машине запущена модель Qwen/Qwen3-Coder, работающая на двух видеокартах RTX 50XX с 16 ГБ VRAM каждая. Такая конфигурация позволяет получать ответы от модели с хорошей скоростью, но не может одновременно обслуживать запросы нескольких клиентов.

На той же машине, через Docker, развернуты сервисы, обеспечивающие дополнительные возможности для работы и автоматизации:

• Open WebUI — для взаимодействия с моделью в форме чата и визуализации результатов

• n8n — для оркестрации workflow и автоматизации процессов

• SearXNG — приватный поисковый агрегатор для выполнения поиска в задачах аналитики.

• Базы данных: Qdrant, Redis, MongoDB, PostgreSQL.

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

Пример организации моего рабочего процесса

Комбинируя описанные выше инструменты, я выстроил следующий подход к работе:

• Структура проекта: Я начинаю с создания новой папки и файла info.md. Прошу агента сформировать типовую структуру документа для описания требований к проекту. Этот файл создается на основе правила, которое указано в info.md и располагается в папке с общими или локальными правилами.

   # Правило составления info.md
   
   ## Общие положения
   1. Для проекта может создаваться файл `info.md` в корне или в указанной папке с документацией.
   2. Файл предназначен для описания требований к проекту и может быть использован в виде инструкции для агента.
   
   ## Структура файла
   Файл должен содержать следующие разделы:
   
   ### 1. Название проекта
   - Краткое и уникальное название проекта.
   
   ### 2. Краткое описание
   - Опишите цель проекта, его назначение и ключевые функции.
   - Не более 3-5 предложений.
   
   ### 3. Цели и задачи
   - Основная цель проекта.
   - Второстепенные задачи, которые необходимо выполнить для достижения цели.
   
   ### 4. Требования к функционалу
   - **Функциональные требования**: что проект должен выполнять.
   - **Нефункциональные требования**: производительность, безопасность, совместимость, ограничения.
   
   ### 5. Входные и выходные данные
   - Форматы и примеры входных данных.
   - Форматы и примеры выходных данных.
   
   ### 6. Ограничения и предположения
   - Технические и организационные ограничения.
   - Предположения относительно среды, ресурсов и зависимостей.
   
   ### 7. Порядок действий агента
   - Какие разделы читать.
   - Какие данные извлекать.
   - Как использовать информацию для принятия решений или генерации действий.
   
   ## Правила оформления
   - Использовать Markdown для структуры (заголовки, списки, таблицы при необходимости).
   - Каждый пункт должен быть кратким, ясным и информативным.
   - Не оставлять пустых разделов — если информации нет, указать `Не применяется` или `Отсутствует`.
   
   ## Пример заполнения
   - Название проекта: "Агент для автоматизации отчетов"
   - Краткое описание: "Проект позволяет автоматически собирать данные из источников и формировать отчеты в нужном формате."
   - Цели и задачи: ...

• Голосовой ввод: Далее для быстрого уточнения и дополнения разделов документа с информацией я активно использую голосовой ввод. Надиктовываю основные мысли и идеи, которые сразу попадают в документ.

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

• Генерация проекта на основе info.md: Когда документ с общей информацией по проекту готов, я обращаюсь с запросом к агенту для того, чтобы начать генерировать сам проект.

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

Далее покажу на примере, как это может работать.

Задача автоматизации обработки данных

Для демонстрации практического применения описанных инструментов рассмотрим задачу автоматизации обработки информации о модели данных, полученной из системы управления инженерными данными ЛОЦМАН:PLM.

Цель работы — подготовить данные для организации RAG.

Исходный файл, экспортируемый из ЛОЦМАН:PLM-Конфигуратора, представляет собой ZIP-архив, внутри которого находится XML-документ с описанием настроек и конфигурации модели данных. Для стандартной конфигурации объём этого документа может превышать 12 МБ. При попытке обработать столь крупные файлы в цепочках n8n возникали ошибки и зависания, что значительно осложняло построение и отладку рабочих процессов.

Поэтому возникла задача в сократить размер файла с информацией о модели данных. XML-документ содержит большое количество служебных данных, необходимых для функционирования комплекса ЛОЦМАН:PLM, но они являются избыточными для моих задач. Для анализа модели данных — например, получения сведений об объектах, их атрибутах и связях — требуется лишь ограниченный набор информации.

Оптимальным решением является предварительная фильтрация содержимого XML-файла — удаление лишних узлов и атрибутов, это позволит существенно уменьшить размер файла и повысить стабильность его обработки в n8n.

Постановка задачи агенту для генерации info.md

После создания папки проекта и выбора ее в VS Code, делаем следующий запрос в Cline:

Исходные данные хранятся в базе данных PLM-системы и могут быть экспортированы 
в виде Zip-архива, содержащего XML-документ с полной информацией о модели данных. 
Требуется сформировать проект по извлечению и очистке данных для сохранения 
сведений о документах и типах объектов, остальная информация 
должна быть отфильтрована. Предполагается формирование отдельного python 
скрипта для извлечения xml файла (Extractor) и 
скрипта для очистки xml файла (Cleaner). 
Сформируй info.md.

После чего будет сгенерирован файл с общей информацией по проекту. Далее нужно уточнить информацию в info.md, поскольку модель некоторые моменты прописывает по своему, и это видение отличается от того, которое нужно мне.

Этапы реализации

Extractor

Ставим первую задачу агенту: на базе @/info.md разработай скрипт Extractor

С первого раза с задачей агент не справился, так как имя файла zip - архива и имя файла с xml данными совпадали, пришлось уточнить задачу: переделай @/Extractor.py он должен искать внутри архива файл с именем, равным имени архива, извлекать его во временную папку, а далее копировать рядом с архивом, добавляя к имени расширение .xml

Со второй попытки экстрактор заработал.

Cleaner

Ставим вторую задачу агенту: на базе @/info.md разработай скрипт Cleaner, он должен оставлять указанные теги и удалять остальные теги. В оставленных тегах скрипт должен удалять указанные атрибуты.

В этот раз скрипт получился совсем нерабочим и в добавок с комментариями на английском языке. Просим вернуть все на русский язык: перепиши все текстовые сообщения и комментарии в @/Cleaner.py На русcкий язык.

Правим немного Cleaner.py, добавляем в начало скрипта массивы с информацией о том, что оставить, что удалить и просим переписать скрипт: переделай @/Cleaner.py. Внутри Root в файле cleaned.xml должны оставаться только узлы, с указанными в ROOTNODES_TO_KEEP наименованиями и содержимое этих узлов. Далее у оставшихся узлов должны быть удалены ненужные узлы из NODES_TO_DEL, а далее у всех узлов должны быть удалены ненужные атрибуты из ATTR_TO_DEL.

Со второго раза это не сработало, так как модель пыталась прочесть файл md_extract.xml и на этом зависала, пришлось добавить уточнение: ВАЖНО! Не открывай файл @/data/md_extract.xml для исследования, так как он большой и в твой контекст не поместится!

После этого скрипт был написан и протестирован, все работало как и ожидалось. Итоговый размер файла из 12 превратился в 3 мб.

n8n

Ради эксперимента просим агента сделать цепочку для загрузки очищенного файла в цепочку и преобразования файла из XML в JSON. Дальше удобнее будет работать в интерфейсе n8n: Создай цепочку n8n, которая на ручной вызов события загружает файл ./files/md_extract_cleaned.xml получает из него xml данные и далее преобразует их в JSON

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

Вместо заключения: немного о том, зачем всё это

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

Зачем это нужно? Всё просто: эти данные станут основой для экспериментов с ИИ-агентом, который по пользовательскому запросу сможет формировать специальные поисковые сценарии и искать нужную информацию в базе данных ЛОЦМАН:PLM.

Сложный поиск в ЛОЦМАН:PLM

Система ЛОЦМАН:PLM поддерживает расширенный поиск объектов, который может быть многоступенчатым. Алгоритм поиска состоит из последовательных шагов, каждый из которых выполняет определённую функцию: фильтрацию, выбор связанных объектов и объединение результатов. Вся эта последовательность может быть описана XML-сценарием — своеобразным «рецептом» поиска. И вот тут хочется, чтобы ИИ-агент умел генерировать эти XML-сценарии сам, опираясь лишь на текстовое описание пользователя.

Например:

• найди все требования, которые ещё не согласованы,

• покажи все детали, которые разработал Еремин,

• или выведи все изделия, где использованы детали из алюминия.

То есть, по сути, мы хотим научить модель переводить естественный язык в формальный XML-сценарий запроса к системе. Для того чтобы XML-сценарий был валидным, он должен использовать значения типов, связей и атрибутов из модели данных и здесь как раз будут использовать данные из векторного хранилища. Если это получится — можно будет упростить работу инженеров, аналитиков и менеджеров проектов, которые ежедневно взаимодействуют с ЛОЦМАН:PLM.

А что насчёт n8n?

Экспериментировать с ИИ-агентами оказалось очень удобно в n8n, поэтому все свои эксперименты по организации агента или цепочки агентов для составления поисковых запросов я буду делать там — но это уже совсем другая история.