Эта статья о том, как создать новую статью на основе старой и использовать Obsidian как рабочую среду для текста. Тут описан весь процесс: от анализа материалов до публикации.
Сначала — общие вводные о том, как собирать и переиспользовать информацию, как связать заметки с контекстом модели и где может пригодиться RAG. Затем конкретнее о написании и редактуре: как превратить старый материал в основу новой статьи, уточнить структуру, усилить аргументацию и использовать Copilot для рутинных правок. В конце — о подключении Git к текстам для отслеживания изменений, безопасного экспериментирования с разными версиями и подготовки статьи к публикации.
Главная идея: Obsidian — это не просто цифровой блокнот, а удобное пространство для сбора материалов, общения с ИИ, редактирования текста и управления процессом создания статьи. В конце будет ссылку на готовую статью, созданную именно таким способом.
Автоматизация редактуры и создания контента: использование локального контекста и LLM
Obsidian ценен не только как хранилище заметок. Вместе с Copilot он становится полноценной средой для работы с текстом: тут удобно размещать черновики, архивные публикации, справочные материалы, стандарты оформления и рабочие заметки.
От рабочих заметок к единой среде
Главная польза ощущается не в намерении «попросить ИИ написать текст», а раньше — когда модель получает доступ к уже собранному контексту. В Obsidian это можно сделать через [[ссылки]], отдельные заметки, папки или всё хранилище.
Таким образом, Obsidian постепенно превращается в полноценную среду разработки текстов. Здесь же накапливается контент, дорабатывается композиция, формируется первоначальный вариант, правятся отдельные куски и выверяется последовательность изложения.
Подключение модели
Для чата в Copilot можно использовать любую модель, к которой у вас есть доступ через API. Для экспериментов использовались наиболее доступные варианты — Gemini, OpenRouter или локальные модели через Ollama, но в этом сценарии основной фокус будет на Gemini API.
Схема подключения простая: в Google AI Studio создаётся API-ключ, затем он добавляется в настройки Copilot, после чего в плагине выбирается нужная модель. После этого Copilot отправляет запросы через выбранный провайдер.
Есть важный момент: доступ к Gemini API может зависеть от региона и конфигурации. Если ключ не создается, модель не появляется в списке, а запросы завершаются ошибкой 400, возможно, потребуется VPN, прокси, OpenRouter или другой метод подключения. Это лучше учесть заранее, чтобы избежать путаницы с настройками Obsidian.
Выбор модели
Для рабочих текстов важна не только «мощь» модели, но и соответствие задаче. Быстрая модель подойдёт для черновиков, переформулирования и простых правок. Более сильная — для анализа структуры, редактуры сложных фрагментов и работы с большим контекстом.
Диалог с хранилищем: RAG в Obsidian
Когда Copilot просто отвечает в чате, ему достаточно LLM: модели, которая пишет, объясняет, редактирует и собирает ответ. Но помимо этого в Obsidian есть режим Vault QA, когда нейросеть отвечает на основе ваших записей, и для него нужна ещё одна часть — embedding-модель.
Vault QA использует технологию RAG, которая дополняет выборку, на которой обучена модель, внешними ресурсами данных. Эти ресурсы обрабатываются иначе, чем обычный ввод модели: слова, предложения или куски текста превращаются в векторы в многомерном пространстве, чтобы смысловую близость можно было представить, как расстояние между векторами. Это и делают специальные embedding-модели.
Схема выглядит так:
заметки → эмбеддинги → поиск по смыслу → контекст → ответ
Copilot сначала индексирует хранилище, разбивая заметки на фрагменты и создавая для них векторные представления. Когда поступает вопрос, он также переводится в вектор. Затем система ищет близкие фрагменты в заметках и передаёт их чат-модели, которая формулирует ответ на обычном языке.
Что довольно удобно — это возможность проследить, какие источники используются при генерации, т.к. остаются сноски со ссылкой на материал.
Качество ответов в Copilot зависит от связки двух моделей: эмбеддинги определяют состав контекста, а чат-модель — качество рассуждений. Для Gemini-сценариев рекомендуется использовать gemini-embedding-001.
Практическая логика связки
В итоге процесс выглядит не как разовая генерация текста, а как цепочка:
старые статьи и заметки → индексация → поиск нужного контекста → черновик → редактура → финальная версия
Obsidian хранит материалы и связи между ними. Copilot помогает доставать нужный контекст и работать с фрагментами. Gemini или другая LLM превращает найденные материалы в связный текст, предлагает правки и ускоряет рутинную редактуру.
Такой метод подходит именно для статей: он не заменяет автора, а убирает часть механической работы. Автор остаётся ответственным за смысл, факты и финальное решение, а ИИ помогает быстрее пройти путь от разрозненных заметок к собранному тексту.
Про саму работу с текстом в Obsidian на примере рерайта
Процесс превращения старой статьи в более актуальный материал в среде Obsidian напоминает работу в IDE для текста, где ИИ-ассистент берёт на себя механическую рутину, оставляя автору роль архитектора и главного редактора.
Важно именно Качество, поэтому работа выполняется последовательно и каждое следующее действие определяется на основе прежнего результата.
Вот как выглядит этот путь, интегрированный с функционалом Obsidian Copilot:
I. Этап «раскопок»: анализ и экстракция смыслов
Работа начинается с деконструкции исходного материала, текст которого ранее был написан автором самостоятельно по другому методу и имеет относительно неплохие метрики просмотров и кликов. Тут годится режим Vault QA или добавление нужной заметки в контекст Copilot напрямую.
Действие автора: Ручная верификация извлеченных идей и отбор наиболее актуальных смыслов.
На этом этапе в фокусе выдача ИИ через призму авторского видения, можно назвать этот процесс "экспертной курацией": здесь сравниваются предложенные идеи с собственным опытом, отсекается лишнее и добавляются важные нюансы, исходя из конкретных целей и задач текста.
Что важно отметить: в этом процессе обычно сталкиваются два подхода. Либо автор вручную собирает и вычитывает все материалы, либо доверяет первичный отбор алгоритмам LLM. В данном случае был выбран второй путь — чтобы максимально упростить и ускорить создание контента. Стоит отметить, что такая автоматизация будет эффективной лишь при соблюдении одного важного условия: поскольку необходим рерайт, понимание причин этого рерайта уже заложено в выборе источников. Таким образом, уже есть достаточное понимание темы, предварительно собраны данные и можно профессионально оценить качество решения, предложенного ИИ.
С другой стороны, если речь идёт о совершенно новом тексте, который требует более глубокого, почти личного исследования — когда автор буквально напитывает свой мозг новыми данными прямо в процессе подбора «почвы» для будущего материала, — тогда чаша весов склоняется к первому подходу. А это уже полностью меняет весь алгоритм действий. Но об этом как-нибудь в другой раз.
Действие ИИ: > Анализ структуры старой статьи, выделение главных тезисов и фильтрация устаревшей информации. Для качественной работы ИИ нужен не общий запрос, а точная рамка. Результат определяется тремя компонентами: промптом, контекстом и настройками модели.
Начиная с настройки модели, где определяется характер ответа: свободный и творческий или строгий и фактологичный. Для технического аудита и редактуры особенно важен второй вариант — сдержанный, точный и проверяемый. Затем контекст помогает модели опираться не на общие знания, а на проверенные материалы из базы — так легче отделить подтверждённые факты от сомнительных утверждений и вовремя заметить расхождения с документацией. И. наконец, сами инструкции, задающие логику анализа: что сохранить, удалить, сократить или перестроить. Чем точнее критерии, тем яснее и профессиональнее итоговый текст.
II. Этап «наведения»: SEO-стратегия
Чтобы текст был востребован, он должен говорить на языке поисковых запросов.
Действие автора: Финальный отбор ключей и проверка их релевантности через внешние SEO-инструменты. Отобранные фразы добавляются в отдельную заметку и в дальнейшем пригодятся при рерайтинге. От прошлой публикации у меня уже есть готовая семантика, так что заново генерировать ничего не нужно. Но вот что касается дополнения и замены ключевых слов, то это лучше всего чувствует сам автор, находясь в инфополе, отслеживая тренды и динамику запросов. Всё это зависит от рабочих целей и задач, которые определяют необходимость создания материала, а также от новых идей, лежащих в основе такого рерайта.
Действие ИИ: с добавлением списка ключей в контекст, на основе извлеченных смыслов Copilot генерирует семантическое ядро — набор ключевых слов и фраз, которые должны быть органично вплетены в текст.
III. Этап «архитектуры»: композиция и структура.
Любой текст нуждается в логике, которая ведёт читателя от общего к частному: сначала объясняет тему, затем раскрывает проблему, показывает решение и подводит к выводу. На этом этапе статья превращается из набора разрозненных мыслей в цельный материал с понятным маршрутом чтения.
Действие автора: автор проектирует структуру будущей статьи: определяет H1, порядок H2 и H3, расставляет смысловые акценты и решает, какие блоки должны идти первыми, а какие — работать как уточнение. В отдельной части промпта автор прописывает каркас текста: например, сначала определение темы, затем польза для читателя, после этого практические шаги, примеры, ошибки, блок про ТестОпс и заключение. Дополнительно автор указывает, какие смыслы нельзя повторять, какие разделы нужно сократить, а какие — раскрыть подробнее на основе прежней статьи и нового набора ключевых слов.
Действие ИИ: ИИ проверяет, насколько предложенная структура логична, полна и удобна для чтения. Он сверяет статью с чек-листом структуры: есть ли вводный ответ на главный запрос, соблюдается ли порядок разделов, не нарушена ли иерархия H2 и H3, нет ли смысловых провалов, повторов и резких переходов. Также ИИ контролирует объём смысловых блоков: каждый раздел должен раскрывать одну задачу, не расползаться на соседние темы и не дублировать уже сказанное. В результате ИИ помогает выстроить статью так, чтобы каждый блок занимал своё место и последовательно усиливал общий смысл материала.
IV. Этап «трансформации»: римейк прежнего текста.
Это не совсем рерайт, здесь процесс идёт дальше: меняется структура, мнение и другие важные аспекты статьи, а не только замена слов и внесение мелких правок. Для этого создается кастомный промпт в Copilot, куда передаются: {activeNote} (исходная статья), план новой статьи и список утвержденных SEO-ключей. Кроме того туда же идут и стайлгайд с ToV’ом и связанные с текстом заметки.
Действие автора: На этом этапе связность текста обеспечивается вручную. Модель может хорошо переформулировать отдельные фразы, но в большом материале иногда теряет нить, повторяет один и тот же тезис или уводит второстепенную мысль на первый план. Поэтому нужно вернуть тексту фокус: сверить факты с первоисточниками, проверить технические детали, убрать возможные галлюцинации и посмотреть, не сломалась ли структура H2–H3. Если ИИ объединил разные разделы, раздул лишний блок или начал ходить кругами, то эту логика пересобирается вручную. После этого дорабатывается язык: вырезаются повторы, убираются нейросетевые штампы, уточняются формулировки и добавляются профессиональные нюансы. В итоге текст перестаёт быть просто "правильным" и начинает звучать как осознанная авторская статья.
Действие ИИ: глубокая трансформация и синтез. Агент анализирует весь переданный контекст: исходную статью, новую структуру, связанные заметки, стайлгайд и ToV. На этой основе он не просто переписывает текст, а пересобирает его архитектуру: распределяет смысловые блоки по новому плану, сохраняет логические связи, органично внедряет SEO-ключи и приводит материал к единой структуре, тону и цели.
V. Этап «шлифовки»: стиль и финальный лоск.
Чтобы текст соответствовал моему авторскому замыслу, применяется метод Руководства по стилю. В Copilot задается команда, которая проверяет текст на соответствие заданному ToV (Tone of Voice) — эти документы также были созданы ранее вручную. Грамотность тоже важна, поэтому весь текст проверяется при помощи плагина Language Tool.
Действия автора: экспертный контроль и оживление текста. Задаётся смысловая рамка, проверяются факты, технические детали и цифры, отсеиваются глюки и возможные ошибки ИИ. В общем, выполняется всё, чтобы довести текст до естественного звучания: усиливается ритм, убирается «нейросетевая» однообразность, добавляются профессиональные нюансы, точные акценты и живая интонация, чтобы статья оставалась достоверной, ясной и по-настоящему «человеческой». После этого статья готовится к публикации: добавляется визуальный контент (обложка, скриншоты), прописываются alt-тексты для изображений, при необходимости задаются якоря, расставляются внутренние и внешние ссылки, проверяются уровни H1–H3 и сами заголовки, указываются TL;DR и мета-описание. Так текст становится полноценным SEO-материалом для блога.
Действие ИИ: проверка текста на соответствие нормам стиля, исправление синтаксических ошибок и унификация терминологии. Предотвращение стилистических разрывов и приведение всех фрагментов к единому Tone of Voice (ToV), чтобы итоговый материал выглядел целостным и полностью соответствовал авторскому руководству по стилю.
Чтобы воспользоваться плагином, нужно завести аккаунт на Language Tool (это бесплатно). Дальше в настройках плагина достаточно указать e-mail, на который зарегистрирован аккаунт.
Для автоматической проверки можно включить опцию Autocheck text:
Это действие можно привязать к новой кнопке на интерфейсе:
VI. Этап «релиза»: публикация
Завершающий аккорд, где текст покидает среду Obsidian и отправляется к читателю. На данном этапе взаимодействие с ИИ прекращается, так как модель не имеет прямого доступа к Git и внешним системам публикации. Все действия на этом шаге выполняются автором вручную, однако процесс можно максимально упростить с помощью плагина Obsidian Git, который позволяет делать коммиты и пушить изменения в репозиторий прямо из редактора (как показано на скриншоте ниже):
Публикация в блоге: перенос финального текста в CMS, финальная верстка и выпуск статьи.
Обновление базы знаний: выполнение
git pushобновленной версии статьи в репозиторий знаний. Это позволяет другим авторам видеть актуальную базу и продолжать работу по той же схеме.Гигиена репозитория: ручная настройка файла
.gitignore. Важно добавить в него логи Copilot и другие временные или служебные файлы, чтобы поддерживать чистоту репозитория и не засорять его ненужными данными.
Заключение: от «чата с нейронкой» к конвейеру смыслов
Переход от разовых промптов к связке «База знаний + RAG + Структурированный пайплайн» меняет саму роль автора. Вы перестаете быть просто писателем и становитесь архитектором и главным редактором. ИИ забирает на себя всю механическую рутину — поиск по заметкам, первичную сборку структуры и технический рерайт, — но оставляет за человеком самое важное: смысловые акценты, экспертную верификацию и финальный стиль.
При работе над этим текстом, что вы читаете здесь, и статьей, которая получилась в результате всех вышеописанных манипуляций, использовались следующие плагины:
В итоге Obsidian превращается из хранилища заметок в полноценную IDE для текстов, где путь от разрозненных идей до готового материала сокращается в разы без потери качества и авторской идентичности.