Эффективная схема, как собрать свои (и не только) знания в виде документа, потратив на это меньше времени.

Я уже как-то писал, что в некоторых случаях мне гораздо проще "наговорить" мысли, чем их писать. Так работает не во всех ситуациях (я же сейчас как-то пишу этот текст), но могу поймать ступор при работе с новыми задачами на самом старте. Особенно если задача связана с оформлением документа.

Как я этот ступор преодолеваю?

Провожу задачу через следующие этапы:

1. Запускаю мастер-промпт для подготовки Deep Research по заданной теме.

2. Запускаю Deep Research в ChatGPT. Читаю собранный материал.

3. Конкретизирую то, чего не хватило в первом исследовании, запускаю ещё одну итерацию Deep Research.

4. Получаю больше конкретики и структуры в ответе от LLM.

5. В этом же чате запускаю голосовой режим с моделью o3. Она уже в курсе контекста, поэтому в режиме диалога можно итеративно сформировать итоговый документ.

6. Получаю нужный мне документ в фомате markdown и, при необходимости, конвертирую его в pdf.

Очень мне понравилось общаться в голосовом режиме с моделью по результатам Deep Research. В таком режиме удобнее расставлять акценты и собирать документ "по частям".

Самое приятное – данный кейс не требует никаких дополнительных настроек с агентами. Всё работает в ChatGPT, на который у многих уже имеется подписка за $20/месяц.

А вы используете голосовой режим в ChatGPT? В каких ситуациях он вас выручал?

У Goose есть очень удобная функция, позволяющая создать пресет AI-агента, доступный по ссылке.

Помимо имени и описания, агенту можно задать специализированный набор расширений, а также задать кнопки быстрых действий (Activities) и кастомные инструкции.

Создаётся он на базе уже существующей сессии Goose. Так что из сессии агент также подтянет выбранную в ней LLM и историю сообщений.

Таким образом, на базе одного приложения Goose можно собрать целую группу AI-агентов с MCP и специальными инструкциями, каждый из которых выполняет определённые задачи.

Как создать такого AI-агента – смотрите на видео в данном посте.

Если вы ещё не знаете, что за Goose такой, то здесь я писал инструкцию о том, как его установить и настроить.

Немного мыслей критического характера относительно технологии MCP.

MCP – отличный инструмент для того, чтобы разработчик мог привлечь к себе много внимания.

Рецепт очень прост. Найти популярную программу или платформу и сделать для неё собственный MCP-сервер. После чего – рассказать об этом в Твиттере X или LinkedIn.

Готово! Вы восхитительны. У твита тысячи лайков и комментариев, а на GitHub сотни звёзд.

Думаю, что некоторые разработчики, благодаря собственным MCP-серверам, даже получали вкусные предложения от рекрутеров. Или даже устраивались на работу...

Иначе я не могу объяснить тот факт, что многие MCP-сервера обновлялись ровно один раз – в момент создания. И потом попросту останавливались в развитии. Никаких новых версий, обновления кода, увеличения стабильности и обеспечения дальнейшей работоспособности (да и у самого рыльце в пушку).

Ещё один момент, связанный с MCP-серверами. Зачастую, в них слишком много инструментов. Настолько много, что AI-агент начинает между ними путаться и без точных инструкций не всегда в состоянии понять, что и когда использовать. А ведь даже Cursor просит добавлять не более 45 tools одновременно.

И последнее. Качество. Многие MCP-сервера просто "навайбкожены" за три команды и выложены в сеть. И это вполне может быть единственный MCP для нужной вам платформы.

Выводы:

1. Лучший MCP-сервер – это тот, который пишешь себе сам. Можно и инструменты только нужные под задачу подобрать, и обновить, когда необходимо. Ещё и код у него такой знакомый и родной!

2. Хорошо, когда большие компании сами выпускают MCP-сервера для своих платформ. Как пример – GitHub MCP-сервер.

3. Если интегрировали в рабочий процесс MCP-сервер от разработчика-одиночки, будьте готовы самостоятельно его дописывать или даже переписывать.

Если у вас есть в подборке качественные (и проверенные временем) MCP-сервера – делитесь ссылками в комментариях. Будем собирать общую качественную базу.

Попробовал вышедший сегодня Claude Sonnet 4. Благо, его сразу же завезли в Cursor. Opus 4 пока протестировать не удалось, так как Cursor уже съел все предоставленные им от Anthropic лимиты.

Sonnet 4 стал заметно лучше кодить и подходит к задачам более комплексно. Пишет тесты, развёрнутую документацию (другие модели, не только от Anthropic, очень часто отделываются отписками), скрипты для упрощённого запуска.

Что это значит для нас? Правильно! Инструкции должны стать ещё более строгими, а на каждом из этапов заставляем модель делать самопроверку. Плюс – добавляем формальные внешние проверки, в которых не задействованы LLM.

Потому что чем мощнее инструмент мы используем, тем больше нужно навыка, чтобы с ним эффективно управляться.

Факт остаётся фактом. С четвёртой версией Opus и Sonnet AI-разработку можно будет вывести на ещё более высокий уровень.

Cursor rules адаптирую под них и совсем скоро начну делиться в канале.

Эффективный набор MCP-серверов должен быть заточен под конкретную задачу.

Более того. Не набор MCP-серверов, а даже набор инструментов у каждого из этих MCP-серверов.

Схема выглядит следующим образом:

1. Мы используем AI-агента, выполняющего ровно одну узкоспециализированную задачу (желательно – детерменированную).

2. Возможности и ограничения AI-агента описывает строгий детальный промпт.

3. У агента есть минимально-необходимый набор инструментов, по которым в промпте есть инструкция, какой из них на каком этапе использовать.

Ранее я писал про Figma MCP-сервер. У этого сервера 30+ инструментов. Большая часть из них позволяет при помощи AI-агента "самостоятельно рисовать дизайн". Получается занятно, но в реальных задачах применить этот инструмент не представляется возможным.

А реальная задача, для которой мне нужен Figma MCP-сервер, – это вёрстка по макету. И мне совсем не нужны инструменты для добавления кнопочек.

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

Ещё один нюанс – мне гораздо привычнее писать сервера на Python. Поэтому вчера я стартовал проект Python Figma MCP Server. С фокусом на задачи вёрстки. Завтра поделюсь его кодом и расширенной версией впечатлений от работы с Sonnet 4.

Первая альфа-версия MCP-сервера для вёрстки макетов из Figma.

Код сервера можете посмотреть здесь.

Я возложил на Claude Sonnet 4 достаточно интересную задачу. Переписать уже готовый MCP-сервер на Python, улучшив архитектуру и сохранив при этом функциональность. При этом намеренно в этой задаче его никак не ограничивал, кроме, разве что, требования по архитектуре.

С первого промпта Sonnet 4, ожидаемо, не справился. Основные проблемы были в запуске и авторизации у websocket-сервера.

Поэтому мы (с Claude Sonnet 4) итеративно доработали MCP-сервер до состояния "хотя бы работает". Для этого пришлось ещё несколько раз привести оригинал в пример и объяснить, что именно и как должно работать.

После чего я удалил из MCP-сервера все методы, которые не пригодятся для задачи вёрстки. Реализацию методов в плагине для Figma пока что оставил (он полностью перекочевал из оригинального репозитория).

Sonnet 4 работает иначе, чем 3.7. Он пробует быть гораздо более самостоятельным и при этом имитирует работу ответственного разработчика. Можно оценить старания по написанным тестам, а также по качеству оформления Readme-файла. Но работоспособность программы "с первого раза" это всё ещё не обеспечивает. Более того, я всё-таки попросил привести архитектуру программы к FastMCP Best Practice. Думаю, без этого поддерживать код проекта уже на текущем этапе не представлялось бы возможным.

p.s.: только при реализации своего сервера обратил внимание, насколько же плох код у исходного Figma-плагина. Просто полотно JS-кода почти на 4000 строк. Даже вспомнились убойные проекты на jQuery из прошлого... 🙂

Первый сайт на заказ я сделал в начале 2010 года.

Это был сайт для маленького бизнеса по установке пластиковых окон. Стесняясь и краснея, я обозначил стоимость создания сайта аж в целых 1600 рублей. Заплатили мне их тогда очень просто, даже без попыток сбить цену.

Сейчас я понимаю, что этому микробизнесу сайт на самом деле был не нужен. И за всё время существования, скорее всего, сайт не привёл в бизнес ни одного клиента.

Просто время тогда такое было. Вокруг витал нарратив, что каждому бизнесу нужен сайт. И без присутствия в интернете жить как-то "не солидно".

Тогда же было популярно сделать клиенту типовой сайт "бесплатно" и посадить его на ежемесячный платёж за поддержку (во времена, когда слово "подписка" ещё не стало модным...), чтобы зарабатывать на нём с течением времени.

С развитием в профессии, я стал чаще понимать, когда сайт полезен, а когда лучше отговорить клиента от попыток выкинуть деньги на ветер. Чтобы не стоял сайт особняком от работающих бизнес-процессов, как памятник всеобщей некомпетентности.

Сейчас становится очень модно делать "AI-интеграции" для бизнеса. Ведь если её не сделать, то можно бесконечно отстать от всего цивилизованного мира (на вас всегда должно "небо падать", чтобы не было возможности принять взвешенное решение).

Здесь также могут быть ситуации, когда конкретной компании не нужно внедрять AI.

Встречал, как минимум, три кейса, когда AI внедрять НЕ следует:

1. Вы пытаетесь создать новый бизнес-процесс с помощью AI-интеграции. Это, как правило, дорого и у вас нет понимания, окупится ли внедрение когда-нибудь. Хуже всего, с точки зрения расходов, попытаться запустить этот бизнес-процесс при участии конечного пользователя. В таком случае неопределённость только увеличивается. А за ней неизбежно придут убытки.

2. Попытки улучшить, с помощью AI, большой и сложный процесс, о котором вы вообще ничего не знаете. То есть у вас нет данных о том, сколько денег процесс съедает и приносит. В таком случае у вас большие шансы начать терять деньги на AI вместо того, чтобы зарабатывать. Причём начнёте вы их терять ещё до запуска, так как внедрение AI – штука далеко не бесплатная.

3. К вам приходят "специалисты по внедрению искусственного интеллекта" и пытаются вам впарить дорогое "пакетное" предложение, даже не интересуясь данными о ваших бизнес-процессах. Такие ребята бьют массово по всему рынку, особо не заботясь о том, чтобы их решение потом работало и зарабатывало.

В сухом остатке, правило: сначала всё посчитать и оценить финансовый эффект от внедрения AI, а лишь потом маленькими шагами с максимальным контролем приступать к поэтапному внедрению искусственного интеллекта в бизнес.

Я достаточно давно знал о существовании сервиса context7.com, но добрался до тестов только сегодня.

На сайте опубликована актуальная документация по большому количеству (более 13000, ага) библиотек и языков.

Но дело не в сайте. Кого интересуют веб-морды во времена AI? 🙂

У них есть MCP-сервер. Код тут. Он решает извечную боль при написании кода через LLM. Когда библиотека обновилась, а база знаний о ней в LLM – нет. И AI-агент пытается использовать устаревшие интерфейсы в новых библиотеках. Потом ещё и версию пакета пытается понизить, "подогнав" под свой код.

Чтобы поставить MCP-сервер от context7 в Cursor, достаточно добавить в настройки mcp-серверов следующее:

"context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }

Готово. MCP-сервер установлен и готов к работе.

Самое крутое – у него всего два инструмента. То есть он не забивает, как многие другие, весь контекст LLM всеми возможными инструментами, 90% из которых никогда не будут использованы.

Можно в инструкции для AI-агента сразу прописать, что валидность любого используемого интерфейса библиотек обязательно проверять через Tools.

В общем, ещё один MCP-сервер, который сразу можно брать в работу без переделывания "под себя".

У LLM в режиме чата есть интересная особенность. С каждым следующим символом вероятность того, что символ окажется последним, возрастает.

Потому что, на этапе обучения модели, у ответов, как правило, была некая средняя длина. Которой достаточно для решения большинства задач. Поэтому вероятность получить очень длинный ответ от модели не очень высока.

Рубрика "Кейс от подписчика".

Сегодня меня попросили разбить длинный документ на заметки по методу Zettelkasten. Потому как используемая LLM в режиме чата из PDF документа объёмом 8Мб создала всего лишь 10-15 карточек.

Отличная возможность потратить очередные 300-400 токенов от Manus!

Берём мастер-промпт, создаём промпт для Manus, чтобы он разбил документ на Zettelkasten-карточки в формате Markdown, адаптированные под Obsidian.

Количество карточек при этом задаёт пользователь.

30 минут работы агента – и готово. У меня получилось выжать из документа целых 400(!) карточек! Можно было даже не настолько сильно дробить документ.

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

В качестве продолжения ко вчерашнему посту – встречайте интерактивный проект с карточками Zettelkasten по "The 2025 AI Index Report" (PDF есть в комментариях).

Посмотреть веб-версию проекта можно здесь: https://xpqngsvk.manus.space/

Там 50 карточек по основным темам, распределённые по тегам и иерархии. Есть представление карточек в виде графа, а также не работающий поиск (решил не тратить токены на его починку).

Самое крутое – всё переведено на русский язык самим Manus! Правда, он дважды спросил "Тут объёмная задача. Мы точно хотим её делать?".

Заработало всё не с первого промпта. В первой версии не работал граф, а также отсутствовали страницы тегов. Добавлял их отдельными запросами.

Также Manus в процессе работы создал дополнительный чат, так как первый быстро переполнился контекстом (ни разу не виню. Он 400+ страниц PDF-документа перевёл).

Суммарно на эту задачу у меня ушло 2200 токенов. Большая часть из них потрачена на перевод, а также на создание сайта.