Comments 26
Чистое любопытство. Автор, в каком IDE и каким ИИ-помощником пользуетесь обычно и, если платно, то сколько за подписку?
Я сижу в обычном редакторе far2l и пользуюсь Gemini 2.5 Pro через браузер. Пробовал разное, не прижилось. Простые задачки IDE с ИИ плагином решают на отлично, а вот фикс багов в чужом запутанном коде им уже не по зубам, там прям промпт-инжиниринг нужен, итеративность и постоянные откаты неудачных веток диалога. Всё ещё не вижу способа делать это удобнее чем через чат, особенно, в режиме мышления модели.
Был бы рад сравнительному обзору разных инструментов не на обычных для таких обзоров тасках типа напиши с нуля очередное никому не нужное мобильное приложение, а на производственных и сложных
Сама необходимость копировать из чата и в чат уже убивает любые преимущества. Тот же Gemini CLI и aider позволяют контролировать какие файлы добавляются и какие правки применяются. Для чата тоже есть точки сохранения /chat save и /chat resume в гемини кли. Изменения тоже можно либо чекпоинтами, либо гитом откатывать
Нифига себе что я вспомнил: Opencart OCMOD. Спасибо за статью, автор. А как вообще это применять? Я до сих пор не использую модные Cursor и пр - только neovim и генерацию кода в окне браузера и переношу все вручную. Кто-нибудь знает с чего начать, не выбрасывая из этого уравнения любимый редактор?
Рад слышать!
Прикладываем ap.md из репозитория к промпту и просим модель дать ответ в формате ap. Потом применяем с помощью ap.py
Хм, пока непонятен процесс. В каждом промпте нужно заново вводить актуальный код из файлов?
ИИ может отслеживать состояние, но через некоторое время начинает путаться. Я в таких случаях обычно прошу «дай новый патч относительно исходной версии». Были мысли включить это требование в спеку, но в итоге решил оставить больше пространства для гибкости, пусть каждый работает так как ему удобно. Ещё были мысли сделать --revert для возможности легкого отката неудачных патчей, но это сильно усложняло формат и повышало число ошибок генерации, так что отказался. git справляется
Сейчас та же Ollama умеет отдавать форматированный ответ - т.е. формат ответа достаточно жестко задается. Не пробовали использовать для генерации ответов? По идее, будет жестко следовать нужному формату - удобнее использовать будет.
Не, не пробовал. А в каком формате задаётся?
Описание и примеры есть тут: https://ollama.com/blog/structured-outputs
Как понимаю, в поле format задается JSON-схема ответа - и этого достаточно.
Судя по всему, с JSON в основном и работает (есть поддержка у многих провайдеров LLM).
В llama.cpp можно и с другими форматами работать - но надо грамматику для них писать (см https://github.com/ggml-org/llama.cpp/blob/master/grammars/README.md). Но не факт, что ollama передает этот параметр в llama.cpp (я не пробовал с этим играться).
Эм.. кажется делаешь велосипед)
Ведь можно заюзать, ИИ CLI варианты у которых будет доступ к проекту и всем файлам, и они сами всё будут "патчить") сравнивать и создавать файлы, редачить, удалять в общем с полным доступом.
Уже без этого гемора с копипастом туда сюда.
Работая как с онлайн нейронками таки локальными моделями ( https://LMStudio.ai ).
https://SourceCraft.dev
https://qwenlm.github.io/qwen-code-docs/ru/
https://www.geminicli.app
и тд
Это очередной виток споров из предыдущего поста, мол есть же редакторы и агенты. Я в курсе. Это всё эффективно только на тривиальных задачах. Когда нужно искать ошибки в чужом запутанном легаси коде, которого тонны, это всё бесполезно. Только обычный чат, режим thinking, промпт-инжиниринг, точный ручной выбор, что именно экспонировать модели, и постоянные откаты неправильных веток рассуждений.
Чтоб постоянно об это не спотыкаться, я специально прописал в ридми, чем ap не является: «убийцей» вашего любимого редактора или ИИ агента. Если вам инструмент подходит и задачи ваши решает — это отлично же!
Мне кажется, что файл ap.md, который нужно прикладывать к каждому промпту, -- длинноват. Это особенно актуально для локально запускаемых моделей, длину контекста которых часто приходится ограничивать из-за недостаточного объёма памяти на GPU. Было бы полезно попытаться сократить этот файл, даже за счёт того, что формат станет не настолько красивым.
Да, для моделей с маленьким окном это не годится, вы правы абсолютно. Я-то его на 1кк модели использую в основном, там это мизер на фоне мегабайт кода, которые модель анализирует. Некоторое время назад я думал, не сократить ли спеку, чтоб не усложнять модели генерацию, но практика (и сами модели) говорят, что это работает наоборот: чем подробнее спека, тем строже рамки и легче генерировать. А вот ужать её именно для локальных моделей — задачка интересная! Поделитесь, если получится
Кстати, а вам приходилось видеть, чтобы модель использовала start_snippet и end_snippet? А то пример из ap.md не использует эти возможности, и у меня есть подозрение, что в результате они должны быть значительно менее популярны, чем snippet.
Вовсю использует! Живой пример — исправление ошибок в справке far2l, там таких конструкций сгенерировалось аж 8 на патч (там патчик уже в формате третьей версии, чуть позже о нём отдельно напишу)
Если в системный промт закинуть - то он в кеш попадет один раз и не будет несколько раз обрабатываться (в идеале).
Проблема не в том, что что-то будет несколько раз обрабатываться, а в том, что оно занимает место в контекстном окне.
Если задействовать structured output, то вероятно, размер промта можно будет значительно сократить.
Но в чате уже не отправить вопрос (хотя может есть какой софт с поддержкой задания формата ответа). И, вероятно, на формат JSON придется перейти.
Формат JSON плох тем, что модели придётся засовывать строки в кавычки, добавляя escape-последовательности. Кроме того, диффы станут нечитаемыми человеком, потому что многострочные фрагменты будут записываться в одну строку с разделителями \n.
В идеале, поддержку формата AP нужно было бы добавить в код инференса модели. Дело в том, что для качественного структурированного вывода нужно проверять формат на лету и не давать модели порождать токены, не соответствующие формату. К сожалению, это осуществимо разве что с локальными моделями (можно, скажем, разобраться и подредактировать исходники ollama).
Согласен, JSON далеко не идеален, хотя LLM достаточно неплохо с ним дружит.
Да и от формата ответа многое зависит - тот же "массив строк кода" останется человеко-читаемым (и экранировать надо будет по минимуму).
Вообще, в llama.cpp можно задать свой формат вывода - но надо определять грамматику в формате GBNF (GGML BNF). Но это не самый общепринятый формат, как я понимаю - у JSON-схемы поддержка гораздо шире.
AP 2.0: Учим ИИ думать, прежде чем патчить