- Регистрация
- 10.12.2015
- Сообщения
- 618
- Благодарностей
- 304
- Баллы
- 63
Всем привет. Данная статья вряд ли станет откровением для тех, кто давно в теме вайбкодинга, однако на форуме регулярно возникают вопросы от новичков: как правильно генерировать C# код с помощью нейросетей, чтобы он сходу запускался в Зенке без танцев с бубном? Стандартные кубики в ZP закрывают большинство потребностей, но часто нужно сделать что-то уникальное или компактно упаковать сложную логику, которая в виде кубиков превратит шаблон в нечитаемый вид.
Исторически сложилось так, что моей основной рабочей средой стала IDE Cursor. Однако описанный ниже подход универсален и отлично подойдет для VSCode или других редакторов.
В чем главная проблема генерации под ZP? Те, кто пытался вайбкодить экшены через чат, знают главную боль: код от нейросети часто отказывается компилироваться в ZP. ИИ упорно пишет директивы using прямо в начале сниппета, оборачивает логику в class Program и static void Main (для работы с таким кодом уже нужно лезть в «Общий код» и иметь более глубокие знания) или вообще галлюцинирует несуществующими методами.
Ниже я привожу структуру своего рабочего пространства. Это не истина в последней инстанции, а рабочий каркас, который каждый может допилить под себя.
Как сделать так, чтобы нейросеть выдавала максимально релевантный код с минимумом правок?
1. Изолированная рабочая среда (Контекст) Создаем на локальном компьютере отдельную папку, например, zennoposter_cursor. Именно её мы будем открывать в IDE как проект. Здесь будет храниться весь контекст, который поможет нейросети понимать специфику работы с нашим софтом.
2. Системные правила (.cursor/rules) В корне проекта создаем папку .cursor/rules и кладем туда файл system-prompt.md (приложил к статье). Cursor считывает его при каждой генерации и сверяет ответы с вашими требованиями. В этот файл я выписал основные «косяки» нейросетей, с которыми сталкивался. Правила можно пополнять по мере работы, либо просто просить нейросеть в чате: "Запомни этот подход и добавь его в правила".
Сейчас в моем промпте заложены следующие принципы:
4. Разделение по проектам (папка Projects/) Внутри воркспейса создайте папку Projects/ и разбивайте логику по подпапкам (один сайт/шаблон — своя папка). Туда же складывайте вспомогательные скрипты. Когда вы просите IDE дописать логику, модель анализирует соседние файлы в этой подпапке, берет оттуда актуальные селекторы или паттерны и выдает код, который идеально вписывается в проект.
Типичный рабочий цикл теперь выглядит так:
Исторически сложилось так, что моей основной рабочей средой стала IDE Cursor. Однако описанный ниже подход универсален и отлично подойдет для VSCode или других редакторов.
В чем главная проблема генерации под ZP? Те, кто пытался вайбкодить экшены через чат, знают главную боль: код от нейросети часто отказывается компилироваться в ZP. ИИ упорно пишет директивы using прямо в начале сниппета, оборачивает логику в class Program и static void Main (для работы с таким кодом уже нужно лезть в «Общий код» и иметь более глубокие знания) или вообще галлюцинирует несуществующими методами.
Ниже я привожу структуру своего рабочего пространства. Это не истина в последней инстанции, а рабочий каркас, который каждый может допилить под себя.
Как сделать так, чтобы нейросеть выдавала максимально релевантный код с минимумом правок?
1. Изолированная рабочая среда (Контекст) Создаем на локальном компьютере отдельную папку, например, zennoposter_cursor. Именно её мы будем открывать в IDE как проект. Здесь будет храниться весь контекст, который поможет нейросети понимать специфику работы с нашим софтом.
2. Системные правила (.cursor/rules) В корне проекта создаем папку .cursor/rules и кладем туда файл system-prompt.md (приложил к статье). Cursor считывает его при каждой генерации и сверяет ответы с вашими требованиями. В этот файл я выписал основные «косяки» нейросетей, с которыми сталкивался. Правила можно пополнять по мере работы, либо просто просить нейросеть в чате: "Запомни этот подход и добавь его в правила".
Сейчас в моем промпте заложены следующие принципы:
- Специфика C# в ZP: Код должен писаться исключительно для выполнения внутри кубика. Никаких классов Program и методов Main. Обращение к переменным строго через project.Variables["name"].Value.
- Проблема с using: Прямой запрет писать рабочие директивы using в теле кода (это классическая причина ошибок компиляции). ИИ должен выводить их в самом начале файла в виде закомментированного списка. Вы просто берете их и переносите в настройки проекта ZP («Директивы using и общий код»).
- Обязательный return: Никаких пустых возвратов. Код должен возвращать строку (например, "success", "error" или спарсенные данные), чтобы кубик корректно направлял шаблон по зеленой или красной ветке.
- Единое логирование: Задаем жесткий стандарт вывода кириллицы в лог Зенки через project.SendInfoToLog().
4. Разделение по проектам (папка Projects/) Внутри воркспейса создайте папку Projects/ и разбивайте логику по подпапкам (один сайт/шаблон — своя папка). Туда же складывайте вспомогательные скрипты. Когда вы просите IDE дописать логику, модель анализирует соседние файлы в этой подпапке, берет оттуда актуальные селекторы или паттерны и выдает код, который идеально вписывается в проект.
Типичный рабочий цикл теперь выглядит так:
- Открыли папку zennoposter_cursor в IDE.
- Попросили сгенерировать логику, напомнив, что это сниппет для ZP.
- Пробежались глазами по ответу: проверили, закомментированы ли using, на месте ли return, нет ли отсебятины в методах.
- Скопировали код в кубик C#. Если ИИ оставил комментарии с нужными пространствами имен — перенесли их в настройки проекта.
Вложения
-
3,2 КБ Просмотры: 5
-
161,3 КБ Просмотры: 4


