NABI NOTE
Документация

Вайб-кодинг с ИИ ​

У NABI NOTE есть llms.txt для ИИ и средств автоматизации. Вместо того чтобы заставлять агента угадывать всю библиотеку, сначала дайте ему прочитать этот индекс, а затем перейти только к нужным тематическим документам — так точнее будут и ответ, и реализация.

Готовый prompt ​

Заполните в примере ниже только используемый фреймворк и нужные возможности.

text
Реализуйте редактор с NABI NOTE (nabi-note).
Сначала прочитайте https://nabi.saro.me/llms.txt, затем прочитайте только документы, нужные для этой задачи.

Среда: Vue 3 + TypeScript
Нужные возможности: базовое форматирование, таблицы, изображения, загрузка
Сохраняемый источник: NABI TREE JSON
Публикация: рендерить сохранённый JSON в HTML на сервере

Используйте только API, которые действительно есть в публичных export и установленных типах.
После реализации выполните проверку типов и сборку, затем сообщите изменённые файлы и результаты проверки.

Если агент не может прочитать URL, добавьте в разговор содержимое llms.txt и относящихся к задаче вложенных документов.

Предлагайте только нужные документы ​

llms.txt — это короткий справочный индекс. Лучше указать документы, соответствующие задаче, чем помещать сразу все документы в контекст.

  • При сборке редактора через npm дайте прочитать quickstart-npm.md.
  • Для примера CDN используйте quickstart-cdn.md.
  • Выбор и сочетание wings описывает wings.md.
  • Сохранённый JSON, HTML и уведомления об изменениях — в document-model.md.
  • Импорт HTML, вставка и границы загрузки — в io-security.md.
  • Для новой wing используйте custom-wing.md, для серверного рендеринга — ssr.md.
  • Viewer и diff описаны в viewer-diff.md, стили и drop cap — в styling.md.
  • Точные import и типы ищите в api-reference.md.

Передавайте требования вместе с задачей ​

Агент не узнает по одному экрану редактора способ хранения или политику безопасности. Сообщите вместе с задачей реальный фреймворк, нужные и исключённые wings, границы хранения JSON и HTML, формат запросов и ответов сервера загрузки и ограничения файлов, а также нужны ли SSR, viewer и diff на опубликованном экране.

Если часть решений ещё не принята, лучше попросить не выбирать их произвольно и не реализовывать, а сначала объяснить варианты и последствия, а затем задать вопрос.

Как проверять результат ​

Сгенерированный код нужно проверять как обычный код. Особенно проверьте следующее.

  • На экранах редактирования и публикации загружен nabi-note/nabi.css
  • Выбранные wings и все mount используют один registry
  • Источник сохранения — getJson(), а не getEditorHtml()
  • innerHTML редактируемого .nabi-content не изменяется напрямую
  • При закрытии экрана созданный mount вызывает unmount()
  • Сервер загрузки проверяет MIME, размер, права и место хранения
  • SSR и браузер используют одинаковый порядок wings и параметры, влияющие на HTML
  • Точные имена export подтверждены проверкой типов, тестами и сборкой

Особенно IME, каретка и формат хранения нельзя считать безопасными лишь потому, что экран один раз выглядит правильно. Проверьте реальный ввод с мобильной композицией, а также сохранение и повторную загрузку.

Сначала проверяйте установленную версию ​

Если nabi-note уже установлен в проекте, exports из package.json и объявления типов установленного пакета служат для текущего кода более прямым ориентиром, чем веб-документация. Документация и установленная версия могут различаться, поэтому попросите агента сначала проверить эту разницу.