AI review бот на lm-studio и локальных llm

Я- фанат и энтузиаст локальных нейроночек, а так же фанат lm-studio, как самого юзерфрендли интрефейса до этих самых нейронок. А ещё я люблю, чтобы нейронки экономили моё время, а не отнимали. Именно по этому, я всё ещё не пишу код с их помощью. Но у меня получилось построить очень простого и экономящего время review бота.

А в чём проблема то?

А проблема с такими исходными очень много:

1. lm-studio не позволяет выстраивать цепочки вызовов агентов, как это позволяет crewai или openclaw.

2. lm-studio фактически не умеет работать одновременно с несколькими mcp-серверами. Если включить больше 1 сервера то она постоянно крашится.

3. Локальные модели очень сильно ограничены по железу, а именно по размеру контекста, например у меня на моих radeon 9070 16Gb + Ryzen 9700x 32Gb размер контекста ограничен примерно 30-40к символов. А системный промт от официальных git+jira mcp серверов суммарно не помещается в 16к контектста.

Как я обычно делаю ревью?

Среднестатистическое ревью проходит так:

• открываю задачу, читаю постановку
• если к задаче привязана ссылка на документацию(конфа) то открываю и читаю
• открываю мерж-реквест, и быстро верхнеуровнево смотрю что в нём происходит
• открываю каждый дифф, и внимательно смотрю какие внесены изменения, придумываю способы, как они могут сломать код, проверяю решают ли они поставленную бизнес задачу
• если дифф нетривиальный то открываю файл целиком через ide и смотрю изменения уже в самом файле
• по результатам ревью пишу комменты на все найденные проблемы с пояснениями и иногда примерами как оно можно пофиксить

Подобный review-flow мне нужен и от бота.

Как устроен мой review бот?

Это обычная lm-studio со специально написанным mcp-сервером, в котором с одной стороны реализованы инструменты и для jira и для gitlab, а с другой реализован только самый минимально необходимы набор инструментов, только для ревью:

• list_mr_files - список изменённых файлов в мерж-реквесте
• get_mr_diff - дифы конкретного файла
• ls_project_tree - получить список файлов из какой-либо папки проекта именно из текущего мр
• read_full_file - прочитать файл целиком, но из текущего мр
• mr_info - получить базовую информацию по мр(название, пайпы, привязанная таска в jira итд)
• jira_get_issue - прочитать таску из jira по готовому урлу
• confluence_get_page - прочитать страницу из конфы, по готовому урлу

В итоге системный промт по инструментам съедает меньше 1к токенов, и обходит проблему lm-studio по работе с несколькими серверами.

Ссылка на lm-studio-review-mcp-server. Инструкция по подключению лежит в README.md.

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

Ты — опытный Senior Node.js разработчик. Твоя цель — проводить глубокое и конструктивное код-ревью

ТВОЙ АЛГОРИТМ СБОРА ИНФОРМАЦИИ (строго используй доступные инструменты):
1. Открой информацию по МР через инструмент mr_info
2. Если к таске привязана задача из Jira — обязательно изучи её через jira_get_issue, чтобы понять бизнес-требования
3. Если в описании таски есть ссылка на Confluence — прочитай постановку через confluence_get_page
4. Получи список изменённых файлов через list_mr_files. Сразу отфильтруй и игнорируй файлы без полезного кода (package-lock.json, yarn.lock, .gitignore, автосгенерированные файлы)
5. Получи дифы изменений через get_mr_diff
6. Если контекста в дифе недостаточно (например, непонятно, откуда импортируется функция или как используется класс) — читай файл целиком через read_full_file. При этом само ревью делай **только** для измененных строк.
7. Для понимания связей между компонентами используй комбинацию ls_project_tree и read_full_file

НА ЧТО ОБРАЩАТЬ ВНИМАНИЕ ПРИ РЕВЬЮ (NODE.JS СПЕЦИФИКА):
- Безопасность: SQL/NoSQL инъекции, XSS, ReDoS (уязвимые регулярки), утечки чувствительных данных в логи
- Производительность: блокировка Event Loop (тяжелые синхронные операции), отсутствие лимитов при работе с массивами/БД (необходимость пагинации)
- Асинхронность: забытые await, неправильная обработка ошибок (отсутствие блоков try/catch или `.catch()`, "проглоченные" ошибки), Race conditions
- Утечки памяти: незакрытые соединения, глобальные переменные, бесконтрольно растущие кэши, висящие обработчики событий (EventEmitters)
- Архитектура: дублирование кода (DRY), нарушение SOLID, понятность именования переменных и функций

ФОРМАТ ТВОЕГО ОТВЕТА (всегда структурируй ревью так):

### Суть изменений
[Кратко: выполняет ли MR то, что заявлено в Jira/Confluence? Решает ли он поставленную бизнес-задачу?]

### Критические замечания (Blockers)
[Гарантированные баги, утечки памяти, SQL-инъекции, уязвимости, падения приложения. Если их нет, напиши "Не обнаружено".]

### Предупреждения и потенциальные проблемы
[Маловероятные баги, Race conditions, неоптимальные запросы к БД, риск блокировки Event Loop, отсутствие обработки крайних случаев.]

### Архитектура и стиль (Best Practices)
[Рекомендации по улучшению читаемости, неймингу, применению паттернов, рефакторингу.]

### Вердикт
[Вынеси итоговое решение:
- 🟢 Approve (можно вливать),
- 🟡 Needs Work (есть некритичные замечания, на усмотрение автора),
- 🔴 Request Changes (вливать нельзя, нужны исправления).]

Для каждого замечания приводи конкретное имя файла, номер строки (если возможно) и пример того, как лучше переписать код.

И последний очень важный момент. Локальные нейронки очень любят уходить в бесконечный цикл рассуждений, особенно с низкой кванитизацией (q4 и ниже). По этому придётся подкрутить параметры её работы, а именно, параметр "штраф за повторение", у меня он стоит в 1.3 и переключить "переполнение контекста разговора" в "скользящее окно" на случай, если не хватит памяти.

Как использовать?

Закидываешь в окошко чата запрос вида:

Привет, сделай плз ревью: https://gitlab.XXX/YYY/III/-/merge_requests/454

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

И это при том, что в самой мр была изменена всего 1 строчка:

Но даже такой простой бот, работающий на маленькой gemma4-26b раскопал проблемы которые были незамеченными в проекте ранее:

Ну и на всякий позитивный репорт по фронту (который я совсем не понимаю):

Почему не openclaw/crewai ??

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

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