Самый простой пример из моей практики. Есть микроконтроллер GD32F407VE и устройство на его базе, есть CMSIS DAP. Задача собрать прошивку под устройство, да так, чтобы не надо было заниматься танцами с бубном с IDE, а достаточно запустить пару скриптов по инструкции. Стоит учесть, что до этого приходилось работать с этим всем, через призму магии IDE(CubeIDE, Eclipse, Keil, ...). Однако, я оказался на маке, с ARM64, где тот же куб не жует этот мк(хоть тот и является клоном), кейл не работает, а как запустить шарманку, я не нашел. И самое главное, я не хотел работать с виртуалками.
Было принятно волевое решение, собрать и скомпилировать все самому, чтоб прям в VSCode, используя make и tools. потратил день на чтение статьей, как это сделать, документации, составление "бутстрапа"(линковочник, инициализация, сборка). Потом пару часов, чтобы разобраться с OpenOCD, DAPlink, коммандами.
Потом ещё пол дня на добавление CMSIS библиотек и понимания, как оно работает(не юзал ни разу).
Как итог, за пару дней, я собрал себе среду, в которой можно работать с МК как обычно, но из удобной для себя IDE. Причем, можно это все адаптировать под другой МК(что собственно я и буду делать для пары китайцев, что валяются под рукой). Это оказалось эффективнее для меня лично и проще, чем по крупицам собирать информацию, ковыряться в старых и крякнутых версиях IDE, чтобы просто начать писать код... А потом мучаться с виртуализацией и эмуляцией всего, а потом бороться с проблемами, из-за этих же IDE для конкретных МК и пробросом портов, поиском драйверов, их патчем...(ноут на arm64, большинство драйверов на x86_64 и не встанут на винду arm64, без патча винды и драйвера).
Мне же проще, иметь все под рукой и понимать как оно работает, чтобы в случае проблем самому все исправить и иметь четкое понимание, что ошибка на моей стороне и я могу её осознать(когда знаю большинство процессов, что происходят с кодом). ИМХО.
При таком случае, обычно модели мне отлично отвечают. В system_prompt пишем кто будет ИИ, обычно достаточно написать:
Ты Senior developer GOlang/Python, программируешь больше 10 лет. Твоя задача писать только оптимальные решения, не применяя мусорные. Ты любишь лишь чистую архитектуру, тебе нравиться правильно реализовывать функции и предполагать, что они будут расширены. Значит, ты не должен писать что-то, что может быть не маштабируемым. Ты пишешь модулями, которые просто достаточно внедрять в проект и имеешь ввиду и помнишь структуру проекта. Каждый твой модуль самодостаточен и может быть отмаштабирован. Пиши в стиле ООП.
Учитывай чистую архитектуру и разделение на слои(инкапсуляция данных). Пример: база данных <-> репозиторий(работа с базой данных и функции работы с ней) <-> сервисный слой(бизнес логика) <-> хендлер запроса(api или что-то иное).
Так же помни другие принципы ООП и SOLID.
У user_prompt тоже есть особенность составления запроса. сначала пишете проблематику, потом что вы пробовали, потом что вам надо от модели(можно капсом выделить важные слова), и в конце пишем что модель не должна делать или каким правилам следовать. Можно тупо сказать, чтобы следовала вашей архитектуре проекта), ну и приложить содержимое комманды tree, чтобы ИИ видел проект и структуру.
А в user_context передаете файлы или что, вы хотели, заключая их в ```/path/to/file.go ``` В целом это мне помогало всегда, особенно с reasoning моделями. Ну и отвечают чаще всего и правильно, если правильную задачу им поставить.
Хмм, попробуй дать ему текст песни какой-то или научную статью и попроси посчитать количество букв "б". Это как один из тестов, что проводят с такими моделями, что "думают".
Ну или можно попробовать просить про свиные крылышки, как их приготовить лучше всего(тоже модели фейлят этот запрос).
Вроде как нет, нельзя. Проблема в чипах, а точнее в их объеме. Количество слотов на которые можно выставить чипы ограничены, на Air m1 это 2 слота, т.е максимум 2 чипа по 1Тб. когда как на pro m1 max это 8 слотов, 8 чипов по 1 тб - 8ТБ максимум. Если вдруг будут чипы поддерживаемые apple обьемами больше 1ТБ, например по 4ТБ на чип, то получиться сделать в air 8ТБ, в ином случае увы
Самый простой пример из моей практики.
Есть микроконтроллер GD32F407VE и устройство на его базе, есть CMSIS DAP. Задача собрать прошивку под устройство, да так, чтобы не надо было заниматься танцами с бубном с IDE, а достаточно запустить пару скриптов по инструкции. Стоит учесть, что до этого приходилось работать с этим всем, через призму магии IDE(CubeIDE, Eclipse, Keil, ...).
Однако, я оказался на маке, с ARM64, где тот же куб не жует этот мк(хоть тот и является клоном), кейл не работает, а как запустить шарманку, я не нашел. И самое главное, я не хотел работать с виртуалками.
Было принятно волевое решение, собрать и скомпилировать все самому, чтоб прям в VSCode, используя make и tools.
потратил день на чтение статьей, как это сделать, документации, составление "бутстрапа"(линковочник, инициализация, сборка). Потом пару часов, чтобы разобраться с OpenOCD, DAPlink, коммандами.
Потом ещё пол дня на добавление CMSIS библиотек и понимания, как оно работает(не юзал ни разу).
Как итог, за пару дней, я собрал себе среду, в которой можно работать с МК как обычно, но из удобной для себя IDE. Причем, можно это все адаптировать под другой МК(что собственно я и буду делать для пары китайцев, что валяются под рукой). Это оказалось эффективнее для меня лично и проще, чем по крупицам собирать информацию, ковыряться в старых и крякнутых версиях IDE, чтобы просто начать писать код... А потом мучаться с виртуализацией и эмуляцией всего, а потом бороться с проблемами, из-за этих же IDE для конкретных МК и пробросом портов, поиском драйверов, их патчем...(ноут на arm64, большинство драйверов на x86_64 и не встанут на винду arm64, без патча винды и драйвера).
Мне же проще, иметь все под рукой и понимать как оно работает, чтобы в случае проблем самому все исправить и иметь четкое понимание, что ошибка на моей стороне и я могу её осознать(когда знаю большинство процессов, что происходят с кодом).
ИМХО.
Используйте шаблон из разряда:
При таком случае, обычно модели мне отлично отвечают.
В system_prompt пишем кто будет ИИ, обычно достаточно написать:
У user_prompt тоже есть особенность составления запроса. сначала пишете проблематику, потом что вы пробовали, потом что вам надо от модели(можно капсом выделить важные слова), и в конце пишем что модель не должна делать или каким правилам следовать. Можно тупо сказать, чтобы следовала вашей архитектуре проекта), ну и приложить содержимое комманды tree, чтобы ИИ видел проект и структуру.
А в user_context передаете файлы или что, вы хотели, заключая их в
```/path/to/file.go
```
В целом это мне помогало всегда, особенно с reasoning моделями. Ну и отвечают чаще всего и правильно, если правильную задачу им поставить.
Хмм, попробуй дать ему текст песни какой-то или научную статью и попроси посчитать количество букв "б". Это как один из тестов, что проводят с такими моделями, что "думают".
Ну или можно попробовать просить про свиные крылышки, как их приготовить лучше всего(тоже модели фейлят этот запрос).
Вроде как нет, нельзя. Проблема в чипах, а точнее в их объеме. Количество слотов на которые можно выставить чипы ограничены, на Air m1 это 2 слота, т.е максимум 2 чипа по 1Тб. когда как на pro m1 max это 8 слотов, 8 чипов по 1 тб - 8ТБ максимум.
Если вдруг будут чипы поддерживаемые apple обьемами больше 1ТБ, например по 4ТБ на чип, то получиться сделать в air 8ТБ, в ином случае увы