Я не разработчик. У меня есть лишь базовые знания программирования, и я могу читать простой код.
Недавно я создал плагин, в основном полагаясь на бесплатную версию Gemini. 95% кода было сгенерировано ИИ.
Хотя плагин определённо работает, а интерфейс и опыт администрирования вполне приемлемы, у меня есть обоснованные опасения относительно чистоты кода. Несмотря на мои усилия по составлению промптов[1] (и ручную подачу ИИ фрагментов официального кода), я уверен, что код не использует возможности среды Discourse должным образом: помощники, компоненты, классы и так далее. Именно поэтому я время от времени давал ИИ куски официального кода.
Я слышал, что сейчас многие разработчики используют ИИ в своей работе. Мне интересно, насколько лучше был бы код плагина Discourse, сгенерированный ИИ, если бы тот был осведомлён об экосистеме Discourse.
Мне посоветовали попробовать Claude, а точнее модель Opus. Мне также сказали, что она потребляет много токенов и поэтому дорога.
У моих проектов нет серьёзных амбиций — это просто хобби. Мне интересно посмотреть, как плагин, который я представляю, будет выглядеть в реальном мире, а ИИ неплохо справляется с такими задачами.
Вы пробовали использовать ИИ при разработке плагинов или компонентов? Пробовали ли вы интегрировать Claude Opus в свою IDE? Насколько это было полезно?
Правильно ли он использует существующую кодовую базу для генерации нового кода?
Насколько это дорого? Какой тарифный план вы выбрали?
Фраза «усилия по составлению промптов» заставляет меня чувствовать себя неловко ↩︎
Я обнаружил, что работать с ИИ в контексте Discourse значительно эффективнее, если у него есть примеры для ориентира. Claude Code особенно хорош в этом (также CLI от Google Gemini!).
Для энтузиаста тарифный план за 20 долларов в месяц, вероятно, позволит продвинуться довольно далеко… Хотя дневные лимиты превысить несложно, в таком случае можно просто подождать их сброса или докупить кредиты.
Кажется, я ошибся насчёт цены. Бесплатные/про/макс-планы предназначены для использования Gemini через их веб-интерфейс (https://claude.com/pricing). Цена API зависит от количества токенов (https://claude.com/pricing#api); у них нет ежемесячных подписок для использования API, верно?
Если использование ИИ, скажем, в VSCode, требует обращения к их API.
редактирование: ладно, в следующий раз сначала прочитаю несколько уроков
На прошлой неделе я потратил время на попытку написать плагин для Discourse, используя ask.discourse. Меня поразило, как я мог описать функцию желаемого плагина, и система выдавала множество советов и фрагментов кода, некоторые из которых действительно работали.
Я программист-любитель. Помимо моего экземпляра Discourse я запускаю другой сервер с базой данных MySQL, бэкендом на PHP и фронтендом на Jquery/Javascript, но я не профессиональный программист. Чаще всего при разработке этого сайта я просто говорю обычному Google, что мне нужно, и он (полагаю, Gemini?) выдаёт примеры кода. Большинство из них работают сразу «из коробки», и я достаточно хорошо знаю JavaScript, чтобы разобраться, если что-то не работает.
За годы я использовал множество языков программирования. В прошлом я проводил часы за чтением, поиском и экспериментами, чтобы понять то, что сейчас я просто ввожу в Google, и завершаю за минуты то, что раньше занимало часы или даже дни.
Меня поразило, насколько хорошо сработал ask.discourse, и в итоге я получил работающий плагин, который примерно выполнял то, что я хотел. С некоторой стилизацией (CSS) он мог бы стать полезным плагином. Меня интригует возможность того, что сервис с поддержкой ИИ может упростить процесс создания кода.
Я написал плагин для моей страницы Discourse с использованием Antigravity, который отображает самые популярные аниме-сериалы. Также я создал список для просмотра. Иногда возникают сбои, и приходится вносить много исправлений, но в целом я доволен.
Интересным могло бы быть описание того, что следует настроить, или что следует сообщить Claude при создании плагина или компонента темы для Discourse (исходя из скелета).
Какие инструкции следует записать в CLAUDE.md, чтобы максимизировать его эффективность?
Следует ли отдавать приоритет определенным директориям Discourse, когда ИИ ищет информацию в кодовой базе (я думаю о контроллерах, моделях, сериализаторах, сервисах…)?
Как сделать его осведомленным о стандартной иерархии файлов, именовании и соглашениях?
НИКОГДА не сохраняйте результаты find() — это приводит к устаревшим ссылкам на элементы после повторного рендеринга
ВСЕГДА проверяйте любые внесённые вами изменения с помощью линтера
Понимают ли ИИ-модели акцент, сделанный заглавными буквами? Повели бы они себя иначе, если бы было написано «Никогда» и «Всегда»?
Становятся ли такие формулировки, как «режим архитектора» или другие промпты в стиле «режим xxx», мягкими стандартами в разработке ИИ? Оказывают ли они реальное влияние на поведение модели? Или это просто условные соглашения?
Не пишите очевидные тесты
Я понимаю, что такое очевидный тест, но понимают ли ИИ-модели, что имеется в виду под «очевидным тестом» (или вообще «очевидным» чем-либо)?
Несколько дней я экспериментировал с Claude в VSCode. Удивительно наблюдать, как всё работает само по себе: чтение, создание и изменение файлов, выполнение команд bash и т. д…
Что касается работы Claude по созданию плагинов, вот что я заметил:
При итеративной работе с одними и теми же фрагментами кода и решении проблем он склонен использовать чрезмерно специфичные имена переменных. Например, он может назвать переменную original_url вместо простого и лаконичного url, словно пытаясь подчеркнуть внесённые изменения, хотя в этом нет необходимости.
Итерации часто приводят к запутанному коду и иногда к излишне сложным запросам. Периодически просить ИИ проанализировать код и указать части, которые можно рефакторить, — это проверенный способ избежать такой ситуации
При запросе решений для конкретной проблемы я был доволен полученными ответами.
Предложения кажутся точными. Когда он предлагает несколько вариантов, он может грамотно взвесить плюсы и минусы каждого из них.
В SCSS он (редко) использует жёстко заданные цвета там, где это не рекомендуется, вместо использования переменных цветов Discourse.
После выполнения нескольких задач я люблю просить ИИ проанализировать код и посмотреть, можно ли оптимизировать некоторые части без ущерба для поддерживаемости. С результатами у меня не было серьёзных проблем. Иногда он вносит слишком много изменений и ломает код.
Иногда, похоже, он создаёт избыточные условия ради безопасности и надёжности, но для ситуаций, которые, насколько я понимаю, в реальных условиях не возникают.
Например, в моём плагине, связанном с поиском, он проверяет, есть ли у поста какие-либо темы. Но посты без темы в Discourse, как мне кажется, существовать не должны. Если такой пост появился, значит, где-то в вашем экземпляре произошло что-то серьёзно не так, верно? Мне кажется, что проверка этого в моём плагине бессмысленна.
Он неплохо справляется с созданием заготовок для тестов!
В целом, опыт пока положительный, даже без использования продвинутых настроек ИИ.
Я потратил свою недельную квоту за четыре дня, что отлично, потому что это вынуждает меня сделать трёхдневный перерыв
Любопытно посмотреть, как всё изменится, когда к Discourse будут добавлены специализированные навыки для ИИ.
Я провёл день, привыкая к Claude (отделившемуся от ChatGPT), и с нетерпением жду возможности попробовать Claude Code, чтобы хотя бы сделать прототипирование или решить свои задачи в Discourse! Если где-то есть навыки, которые ждут своего часа, я с радостью попробую их применить.
После экспериментов с разработкой плагинов я попробовал создавать темы с помощью Claude. Результаты были катастрофическими, но я не был сильно удивлён, так как он часто выдавал бессмыслицу даже при простых запросах на CSS. Похоже, он не улавливает контекст, в котором находится каждый элемент, что приводит к плохо сделанным или неверно размещённым элементам и часто к набору бесполезных атрибутов.
До тех пор пока не появятся специфические инструкции по разработке тем, я считаю его крайне ненадёжным для таких задач.
Если коротко, то всем моделям требовались жёсткие ограничения (guardrails) при разработке тем и компонентов для Discourse!
Материалы для обучения устарели — в основном им уже два года, поэтому все модели требуют очень конкретных инструкций для разработки плагинов и тем.
Что я делал тогда:
Я просто скачивал документацию по разработке для компонентов тем Discourse, сжимал её в файлы инструкций на Markdown и добавлял их в каждый проект.
Но это было ещё до того, как появились SKILLS…
Это было бы отличным дополнением!
Возможно, имеет смысл создать отдельные SKILLS для разработки плагинов, разработки тем и, возможно, общие специфичные для разработки под Discourse навыки.
@sam, почему документация по разработке для Discourse больше не размещена на GitHub? Разве её теперь поддерживают напрямую в Discourse Meta?