Здравствуйте, bnk, Вы писали:

bnk>Выглядит очень круто
спасибо

bnk>практический вопрос — как ты строишь промпт (запросы) к моделям, т.е. как именно ты добавляешь "контекст"?
bnk>Просто дополняешь текст и посылаешь его снова, или как-то по-другому? Размечаешь ли как-то релевантные фрагменты в этом случае?
bnk>Как ты "разбираешь" ответ, т.е. понимаешь в какие файлы нужно внести какие правки?
Первый вариант. Основная идея в том, чтобы с точки зрения модели это выглядело, как 2 кожаных программиста, обсуждающих код. И задача моего движка — разбивать рабочие задачи на подобые обсуждния, давать моделям их дополнить, и встраивать обратно.
Технически это реализовано через высокоуровневый merge. Скажем, ты отправил модели класс с кучей всего, и попроил разбить метод X. Модель в ответ выдала отредактированный X, добавленный X_Auxiliary() и новый конструктор. Движок это дело распарсит, заменит оригинальный метод, и добавит рядом вспомогательный + конструктор. Это не работает с переименовыванием, не в большинстве случаев просто в разы быстрее классического пофайлового подхода. Вещи типа прокинуть новую переменную в дерево конструкторов делаются за секунду-две с минимальным промптом.

Кстати, если хочешь поиграться, шаблоны промптов лежат в папке PromptTemplates, а сами промпты и ответы модели со счетчиком токенов есть в AI->Windows->Diagnostics.

bnk>В качестве ответа ты получаешь новое содержимое фрагментов, или список операций по редактированию (action list)?
Пока фрагменты, но руки чешутся сделать прогрессивное редактирование. Когда модель сначала даст высокоуровневый список типа "добавлю переменную X в класс Y", потом отдельные фрагменты кода, потом отредактированные куски. Теоретически, последний этам можно распараллелить, или дать на откуп более простой модели, чем еще выше поднять скорость. Но текущий вариант уже неплохо работает.

bnk>Еще, как ты думаешь, чем твой подход отличается от того, что использует GitHub Copilot (в агентском режиме) или Cursor например?
bnk>В смысле, разве они не точно так же собирают контекст перед выполнением операции?
Там, ЕМНИП, используется RAG с векторными базами данных. Т.е. если у тебя код зависит от 20 разных символов, то все соответствущие файлы будут статически подтянуты в контекст. CodeVROOM же работает динамически. Т.е. модель получит неполный кода с вопросом "дай список релевантных, но не указанных символов". Модель выберет, скажем, 5 из них символов. CodeVROOM отактит шаг обратно и повторит все в этими символами.

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

bnk>Из моего опыта с copilot --
bnk>Может ли твой редактор искать решение (дополнять контекст) из интернета (GitHub issues/discussions например)
bnk>или просто "смотреть" (добавлять в контекст) исходный код или документацию используемых в проекте библиотек, если они доступны в открытом доступе?
bnk>Может ли редактор использовать другие инструменты для дополнения контекста, кроме исходных фалов, такие как терминал
bnk>(вывод компилятора или других утилит командной строки, логгирование — т.е. самостоятельно добавить логи в нужных местах и потом на них смотреть)
bnk>или браузер, т.е. вывод DOM например (в случае HTML)? Понимает ли скриншоты?
bnk>Это я просто с Copilot сравниваю. Ну и идеи накидываю
Терминала пока нет, но будет очень скоро. Поиск и скриншоты пока не планируется, т.к. это сложно сделать лучшего того же Codex или Claude CLI. Здесь ниша — сверхбыстрая реализация мелких и муторных задач. Когда в голове есть четкое представление, что и куда надо добавить, но руками это займет несколько минут, но объяснять в чате обычной модели и потом перероверять, не сильно меньше. А с промптом из 2-3 слов и несколькими итерациями получается реально быстрее, и сильно меньше отвлекает.

Кстати, с поиском, мне всегда интересно, насколько это работает на практике? Из моего опыта работы с LLM, они часто принимают неверное "решение" на уровне одного токена, и потом весь последующий ответ пытаются это решение воплотить. Когда ищешь руками, половина задачи — это интуиция понять, фигню ты сейчас нагуглил, или не фигню. У LLM с этим, по-моему, принципальная проблема. Если у тебя есть примеры, когда поиск из копилота делал что-то полезное, будет интересно почитать.

С логированием это будет отдельный высокоуровневый инструмент вместе с отладчиком. Можно будет давать задание типа "разберись, почему после X происходит Y", одобрять/отклонять идеи по инструментации кода, и шагать все это вперед-назад. Но это ближе к концу года, после интеграции с VisualGDB.

bnk>Я только скачал, обязательно посмотрю