Comments 15
Хм...спасибо, весьма интересная идея.
Натолкнуло на размышления....
Читал, что модели лучше понимают запрос, контекст, если им давать в json виде.
Если развить идею, то сам кодинг/вайбкодинг можно начинать с просьбы сформировать структуру проекта в виде json, в котором описать не только файловую структуру, но функции, параметры вызовов, переменные и т.д.
Ни разу не программист, может это так и делается во взрослых проектах, но описанную выше логику еще не встречал, попробую применить, ибо даже в курсоре млдель часто задваивает функции, или вызывает их с отсутствующими переменными, ну и, соответственно, просить модель перед самим кодированием сверять мысли со структурой, описать изменения сначала в json и после одобрения, уже непосредственно кодить, дополняя json.
Вы очень точно нащупали идею «сначала структура, потом код».
В этом посте я показываю более низкий уровень — как дать модели снимок проекта в виде JSON/JSONL. А дальше поверх этого хорошо ложится как раз то, о чём вы пишете: формализованная модель в файлах, с которыми ИИ сверяется перед изменениями.
В отдельной статье я как раз разбираю подход, где перед кодом мы строим для Copilot набор структурированных артефактов: ТЗ, домен, архитектуру, план батчей, pipeline в JSON/YAML, и только потом подключаем «строителя кода». Это вот здесь: https://habr.com/ru/articles/972648/
Так что ваше «пусть модель сначала описывает структуру/изменения в JSON, а потом кодит» — это очень в том же духе, просто я раскладываю это на несколько файлов и этапов вместо одного большого JSON.
сколько токенов у вас уходит на то, чтобы ИИ сделал работу этого скрипта за вас?
Сам скрипт как раз работает без участия ИИ и без токенов. Это обычный PHP: он локально проходит по файловой системе и сохраняет срез проекта в JSON/JSONL.
Модель подключается уже на следующем шаге, когда я готовый снимок передаю в чат. Чат у меня по подписке, обычно использую gpt-5.1 thinking (extended) — её хватает, чтобы спокойно переваривать довольно большие объёмы кода.
То есть ИИ не «делает работу скрипта». Наоборот: скрипт снимает рутину по обходу файлов, чтобы токены тратились уже на анализ и планирование, а не на то, что проще и дешевле сделать на стороне PHP.
ничего не понял. Человек предлагает работу вашего скрипта заменить на запрос к нейросети. Я спрашиваю, сколько на это понадобится токенов, а вы пишете так, как будто это моя идея была использовать нейросети
Кажется, я ваш вопрос в прошлый раз немного не так понял, сорри.
Если речь про вариант "вообще не писать скрипт, а просить нейросеть самой пройтись по проекту и собрать JSON", то я так просто не делаю из-за большого расхода токенов, поэтому прям точных цифр у меня нет. Я как раз пошёл от обратного: локальный PHP-снимок без токенов, а уже потом ИИ для анализа.
Если вы имели в виду что-то другое, напишите, пожалуйста, чуть точнее, чтобы я ответил по делу.
Так, идея хорошая. Применима когда внутренний проектный индекс вацбкодера не справляется.
Но обычно они неплохо работает в этом направлении.
1) Будут ли сравнения?
2) Будет ли плагин для популярных IDE?
Спасибо за вопросы.
У меня сейчас два разных сценария вайб-кодинга. В первом — работа через VS Code и агентов Копилота, там дополнительный скрипт не нужен: агенты и так видят проект и работают по своим правилам. Про это у меня уже есть отдельная статья: https://habr.com/ru/articles/972648/.
Во втором сценарии я разделяю роли: GPT в браузере разбирает архитектуру, формулирует ТЗ и план действий, а Codex в VS Code этот план уже реализует. Codex видит репозиторий, а вот GPT нужно как-то дать такой же контекст — здесь как раз пригождается scan2json, который превращает проект в JSON/JSONL и становится «мостиком» между GPT (планирует) и Codex (пишет код по ТЗ).
Сравнения с «чистым» IDE-подходом как раз планирую вынести в отдельную статью по связке GPT + Codex, там будет больше практики именно в этом разрезе.
Отдельный плагин для популярных IDE пока не планирую: сами IDE-помощники (Copilot, Codex и т.п.) хорошо закрывают сторону «видеть код и помогать писать». Задача scan2json другая — дать внешний переносимый снимок проекта, с которым удобно работать уже вне IDE (GPT, свои сервисы, RAG и т.д.), поэтому поверх существующих плагинов городить ещё один не вижу большого смысла.
Чем это лучше, чем repomix?
Хороший вопрос, я бы сказал, что это не "лучше", а просто под другой стек и сценарий.
repomix классный, если живешь в мире git + Node + CLI, и нужен инструмент "упаковать репозиторий для ИИ".
У меня немного другой контекст - мы делаем готовые веб-решения на Bitrix и Laravel и сознательно живем в php-стеке без Node/SSR. Частый кейс - прод или стейджинг, где есть только php и браузер, без node, без удобного терминала.
Под это я и делал scan2json:
это обычный php-скрипт, который можно закинуть прямо на сервер и снять снимок именно "живого" проекта, а не только того, что лежит в git
управляется через веб-интерфейс - можно выбрать корень, отрезать лишние папки, скачать json/jsonl, не заходя в консоль
плюс есть обратная сторона с restore.php - можно из снимка собрать отдельную копию модуля или проекта для экспериментов или передачи подрядчику
То есть если у вас уже выстроен процесс вокруг repomix и Node - вообще ок, он решает свою задачу. scan2json я делал под другой мир - php/Bitrix/Laravel без Node, когда нужно снять и отдать срез кода прямо с сервера через браузер.
Что-то мне кажется, что лучше так не делать. Безопасность, это во первых. У вас даже защиты от брутфорса нет, я молчу про двухфакторку и всякие otp ... Но это оставим в стороне, кого я тут лечить собрался.
Во всех ide уже есть решение вашей проблемы. Любая система, когда вы откроете проект и скажете "давай поменяем класс Х" или "давай передаём компонент У" сама grep'нет по всему проекту упоминания класса. А если у вас прямо в проекте есть файл agents.md, то ещё и поймет по какому принципу с вашим кодом работать. А если есть ещё и документация в md файлах... ой ладно, совсем я размечтался...
В общем то что агенты умеют делать автоматически, вы зачем-то превратили в ручную работу. То, что есть скрипт, который не облегчает - хорошо, но всё-таки лучше использовать именно агентский подход.
Мой совет:
Фронт, бэк, бд, очереди, докерфайлы... Это все должно быть одним проектом, даже если деплоится все совершенно по отдельности.
Документация должна быть. И быть актуальной. И актуализироваться после любого изменения кода. Обычно это кучка md файлов как в корне проекта, так и в отдельных его частях. От первого readme до последнего описания структуры какой-то таблички должны быть ссылки, чтобы агент понял, какой файл читать перед внесением изменений.
Файл agents.md очень важен. Вот прям в разы улучшает ответы. Без него 4 раза из 5 ИИ может отдать полную дичь, и на 5й раз что-то, что уже есть смысл допиливать ручками. С ним 4 раза из 5 отдаст что-то что можно допиливать, а 1 раз может и вообще отдать годный код который не требует полировки. Сильно зависит от кода, размера задачи, промпта, так что цифры условные, разумеется.
Спасибо за развёрнутый коммент, реально есть с чем согласиться.
По безопасности: этот скрипт я вообще не подразумеваю как штуку "повесили на прод и пусть все ходят". В реальной жизни я им пользуюсь на локалке или на сервере разработки. На боевых проектах не запускаю. Плюс там есть защита от совсем уж классического косяка: с паролем по умолчанию авторизоваться нельзя, он просто не пустит, пока не поменяете. Для битрикс-проектов ещё и используется стандартная авторизация Битрикса, то есть сам скрипт доступен только админам. А дальше уже по ситуации можно хоть за VPN его прятать, хоть под http-auth.
Про IDE/агентов я с вами в целом не спорю. В идеальном мире, который вы описываете, я тоже за то, чтобы был один проект, нормальная структура, живая дока в md и agents.md, а Copilot/Cursor всё это видел и сам грепал. Под такой сценарий у меня есть отдельная линия статей и репозиторий с workspace и кастомными агентами.
scan2json решает другую, более приземлённую задачу. Мы много работаем с php-проектами (Bitrix, Laravel) в окружениях без Node и без нормального CLI, где до "агентского рая" ещё далеко, а вот живой код на сервере уже есть. В таких случаях удобно один раз "щёлкнуть" проект этим скриптом, получить JSON/JSONL со срезом именно того, что реально крутится, и уже этот снимок отдать GPT/агентам/своим сервисам. То есть он не заменяет автоматизм агентов, а даёт им сырьё там, где никакого agents.md и репомикса пока просто нет.
Автор, попробуй Claude Code, вряд ли что то лучше него сейчас есть
Я пробовал Claude Code, да, он вполне ок и местами, возможно, даже ощущается поудобнее.
Но у меня сейчас всё крутится вокруг продуктов OpenAI: корпоративный тариф уже оформлен, настроена куча ассистентов, есть обвязка под проекты, интеграции, свой опыт работы именно с их стеком. В такой ситуации брать ещё отдельную подписку под Claude Code, чтобы по сути дублировать те же сценарии в другом интерфейсе, я для себя смысла не вижу.
Скорее углубляюсь дальше в экосистему OpenAI – assistants, инструменты, интеграцию во внутренние процессы – чем развожу зоопарк из нескольких платных решений, которые делают примерно одно и то же. Но если человек живёт в антропиковском стеке, то для него Claude Code, скорее всего, и правда будет самым удобным вариантом.
Как я делаю «снимок» проекта в JSON для ИИ и разворачиваю его обратно