# Alejandro Rioja — RU > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/ru/ Author: Alejandro Rioja Language: ru --- ## ИИ-агенты с контролем человека: когда строить ворота одобрения (и когда нет) Source: https://alejandrorioja.com/ru/human-in-the-loop-ai-agents-when-to-build-an-approval-gate/ Published: 2026-07-23 Tags: AI Agents, Operations TL;DR: Ворота одобрения имеют смысл, когда ошибка дорогостоящая, необратимая или затрагивает клиентов — и когда человек может её поймать вовремя. Нет смысла, когда объём слишком велик для проверки, ошибка дёшево исправляется или люди одобряют не читая. Я использую четыре вопроса для решения, и у большинства моих 30+ производственных агентов нет никаких ворот одобрения. ## Оглавление _Опубликовано в июле 2026 года._ **TL;DR:** Ворота одобрения имеют смысл, когда ошибка дорогостоящая, необратимая или затрагивает клиентов — и когда человек может её поймать вовремя. Нет смысла, когда объём слишком велик для проверки, ошибки дёшево исправляются или люди одобряют не читая. Я использую четыре вопроса для решения, и большинство моих 30+ производственных агентов работают полностью автоматически. **Заметка оператора:** Я запускаю агентов в двух бизнесах — консалтинговый бренд и Pickleland, площадка для пиклбола в Пфлугервилле, Техас. Поначалу я везде ставил ворота одобрения, потому что это казалось «безопасным». Через несколько недель у меня был Slack-канал, заполненный уведомлениями, которые никто не читал, и агенты, технически находящиеся под наблюдением, но практически бесконтрольные. Это хуже, чем никаких ворот: иллюзия надзора без существа. Эта статья объясняет, как я сейчас думаю об этом решении. ## Что такое ворота контроля человека на самом деле В простейшем виде ворота одобрения — это пауза в рабочем процессе агента, где человек должен подтвердить, прежде чем агент продолжит. Агент составляет черновик письма — человек одобряет его перед отправкой. Агент помечает транзакцию — человек проверяет, прежде чем обработать возврат. Ворота могут быть синхронными (агент блокируется, пока кто-то не одобрит) или асинхронными (агент ставит действие в очередь, отправляет уведомление, и человек одобряет из дашборда или Slack-сообщения в своём темпе). Асинхронный вариант почти всегда лучше для всего, что не является критически важным по времени, так как синхронные ворота создают противодавление в очереди и нарушают гарантии надёжности агента. Чем ворота не являются: цикл повторных попыток, порог уверенности или откат к более простой модели. Это механизмы обработки ошибок внутри агента. Ворота одобрения — это о человеческом суждении, входящем в петлю — намеренно, в конкретной точке, по причине. ## Четыре вопроса, которые я задаю Перед добавлением ворот я прохожу через четыре вопроса. «Да» на любой из них — сигнал рассмотреть ворота. «Да» на все четыре означает, что ворота структурно необходимы. **1. Является ли действие необратимым (или дорогостоящим для отмены)?** Отправить письмо 10 000 людям нельзя отозвать. Отправить платёж нельзя легко вернуть. Удалить запись в базе данных без резервной копии — это навсегда. Необратимость — наиболее веский аргумент в пользу ворот, потому что агент не может отменить то, что сделал. Сравните с: отметить входящий запрос категорией. Если метка неверна, исправите за два клика. Ворота не нужны. **2. Если агент ошибается, кто платит?** Внутренняя метка неверна — трачу несколько секунд на исправление. Клиентское письмо неверно — клиент платит плохим опытом, я плачу потерей доверия. Финансовая транзакция неверна — плачу реальными деньгами и потенциальным риском соответствия. Агенты, затрагивающие только внутренние системы, могут допускать больше ошибок без ворот. Агенты, касающиеся клиентов или денег, должны заработать право работать без контроля. **3. Может ли человек реально обнаружить ошибку до того, как она будет важна?** Это вопрос, который большинство людей пропускают, и он устраняет больше ворот, чем любой другой. Если агент обрабатывает 500 элементов в час и вы получаете одно Slack-уведомление на элемент, никто не прочитает все 500. Вы создаёте усталость от оповещений, а не надзор. Расчёт прост: ворота добавляют ценность только тогда, когда человек может реалистично проверить помеченный элемент в доступном временном окне. **4. Читают ли люди надёжно то, что представляет агент?** Если ваша очередь одобрения заполняется и люди одобряют, не читая, ворота хуже, чем их отсутствие — создаётся ложная уверенность, что человек проверил работу. ## Когда ворота явно имеют смысл Это паттерны, где я всегда добавляю ворота, без исключений: - **Необратимые внешние коммуникации** — письма, SMS, посты в соцсетях реальным людям. Агент составляет черновик; человек отправляет. В зависимости от объёма. - **Финансовые действия выше порога** — всё, что перемещает деньги, получает ворота, если превышает минимум в рублях/долларах, который я устанавливаю по контексту. - **Новые паттерны, которые агент не видел раньше** — если классификатор агента отмечает что-то как «неизвестное» или за пределами его обучающего распределения, это принудительная эскалация. - **Выходные данные, чувствительные к соответствию** — всё, что касается HIPAA, PCI, юридических уведомлений или регулируемого финансового контента, проверяется человеком. ## Когда ворота незаметно убивают продукт Это паттерны, где ворота кажутся безопасными, но незаметно ломают принятие: - **Высокообъёмные, обратимые операции** — если можно отменить за два клика и это происходит 200 раз в день, усталость от проверки победит. - **Срочные рабочие процессы** — агент, отвечающий на входящие запросы клиентов за 30 секунд, не должен иметь синхронных ворот. - **Задачи, где у человека меньше контекста, чем у агента** — если агент прочитал 50 страниц контекста для классификации, а рецензент получает однострочное резюме, проверка — это театр. - **Внутреннее обогащение и маркировка** — теги для записей CRM, категоризация расходов, суммирование заметок встреч. Ставки не оправдывают прерывания. ## Три паттерна ворот, которые я реально реализую Когда ворота оправданы, я выбираю одну из трёх реализаций: **1. Асинхронное одобрение через Slack/почту** Агент завершает черновик, публикует сообщение в назначенный Slack-канал с предложенным действием и кнопками одобрить/отклонить, и делает паузу. Я использую Cloudflare Queues для хранения ожидающего действия и отдельный Worker, который слушает веб-хук одобрения перед возобновлением. Хорошо работает для: черновиков писем, контента для соцсетей, важных обновлений CRM. **2. Эскалация на основе уверенности** Агент работает полностью автоматически для высокоуверенных выходных данных (скажем, ≥0,85 уверенности на структурированной схеме) и направляет низкоуверенные элементы в очередь к человеку. Человек видит только неоднозначные пограничные случаи. Хорошо работает для: классификации, маршрутизации, триажа. **3. Проверка в дашборде с пакетным одобрением** Вместо ворот на элемент, все выходные данные агента попадают в дашборд проверки. Человек проверяет пакетами — например, каждое утро — и одобряет или исправляет группами. Хорошо работает для: генерации контента, составления отчётов, запланированных резюме. ## Ловушка усталости от оповещений Каждые ворота, которые вы добавляете, — это постоянный налог на чьё-то внимание. Риск не только в том, что одни ворота игнорируются — в том, что трое ворот создают шумный Slack-канал, который обучает людей игнорировать все уведомления, что означает: будущие ворота, которые действительно важны, тоже игнорируются. Дисциплина, которую я выстроил: у каждых ворот есть явный владелец и явный SLA. Если никто регулярно не проверяет в рамках SLA, ворота удаляются и заменяются журналом аудита. Я ежемесячно провожу аудит всех очередей одобрения. ## Связь с надёжностью агента Ворота — это один слой стека надёжности, не весь стек. Мой полный стек надёжности для производственного агента: 1. **Оценочная система** — подтверждает правильные выходные данные перед развёртыванием. 2. **Структурированные выходные данные с валидацией схемы** — выходные данные агента ограничены типизированной схемой. 3. **Порог уверенности** — низкоуверенные выходные данные идут на проверку к человеку. 4. **Журнал аудита** — каждое действие агента записывается с входными данными, выходными данными и метаданными вызовов модели. 5. **Ворота одобрения человека** — только для действий, где вышеперечисленного недостаточно. ## Моё практическое правило Если я не хочу, чтобы младший сотрудник делал это, не посоветовавшись со мной сначала, агенту нужны ворота. Если я позволил бы младшему сотруднику делать это не задумываясь, агент должен работать без контроля. ## FAQ ### Как обращаться с агентом, которому нужно одобрение, но он работает с большим объёмом? Измените архитектуру: не требуйте одобрения на элемент — требуйте одобрения на паттерн. Пусть агент работает, но пусть он представляет статистические аномалии для проверки человека. ### Что если ошибка может нанести серьёзный вред, но я не могу позволить себе полную проверку человеком? Обычно это сигнал не развёртывать агента для этого действия ещё. Или используйте порог уверенности. Если вы используете [Claude](/recommends/claude) как слой модели, паттерны использования инструментов Anthropic SDK позволяют легко определить инструмент «эскалации», который агент может вызвать, когда ему не хватает уверенности. --- ## Claude Tool Use: как я даю своим ИИ-агентам реальные возможности Source: https://alejandrorioja.com/ru/claude-tool-use-production-agents/ Published: 2026-07-21 Tags: AI Agents, Claude TL;DR: Claude tool use позволяет агенту выполнять действия — не только генерировать текст. Вы определяете инструменты в виде JSON-схем, Claude решает, когда их вызывать, а ваш код выполняет реальное действие. Цикл состоит из трёх шагов: отправить сообщение → получить блок tool_use → выполнить и вернуть результат. Я использовал этот паттерн в 15+ рабочих агентах на Cloudflare Workers. Точка отказа почти никогда не в ИИ — это неоднозначные результаты инструментов. ## Содержание _Обновлено июль 2026._ **TL;DR:** Claude tool use позволяет агенту выполнять действия — не только генерировать текст. Вы определяете инструменты в виде JSON-схем, Claude решает, когда их вызывать, а ваш код выполняет реальное действие. Цикл состоит из трёх шагов: отправить сообщение → получить блок tool_use → выполнить и вернуть результат. Я использовал этот паттерн в 15+ рабочих агентах на Cloudflare Workers. Точка отказа почти никогда не в ИИ — это неоднозначные результаты инструментов. **[Опыт оператора]** Я управляю 30+ рабочими ИИ-агентами в консалтинговом бренде и Pickleland — центре пикклбола в Пфлюгервилле, штат Техас. Примерно половина из них использует tool use — функцию API Claude, которая позволяет модели вызывать функции, определённые в вашем коде. Вот паттерн, к которому я пришёл после развёртывания и итерации в production. ## Почему tool use меняет то, что может делать агент Без инструментов агент может только генерировать текст. Это полезно для резюмирования, написания черновиков и классификации — но не то, что нужно большинству бизнес-автоматизаций. Им нужно искать информацию, писать в базы данных, вызывать API, отправлять сообщения. Tool use — это способ дать Claude такой доступ. Вы определяете набор инструментов в виде JSON-схем. Claude читает схемы, решает, какой инструмент вызвать и с какими аргументами, и возвращает структурированный блок содержимого `tool_use`. Ваш код выполняет реальную функцию. Claude получает результат и решает, что делать дальше — в том числе вызвать другой инструмент или создать окончательный текстовый ответ. Ключевой момент: **Claude решает, когда и нужно ли вызывать инструмент.** Вы определяете возможности. Модель рассуждает о том, когда их использовать. ## Как работает поток API Цикл tool use состоит из трёх шагов. Вы будете проходить этот цикл один или несколько раз в зависимости от того, сколько вызовов инструментов сделает модель. **Шаг 1: Отправьте сообщение с определёнными инструментами** ```typescript const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ { name: "check_court_availability", description: "Check if a court is available at a given date, time, and duration", input_schema: { type: "object", properties: { date: { type: "string", description: "Date in YYYY-MM-DD format", }, time: { type: "string", description: "Start time in HH:MM format (24h)", }, duration_minutes: { type: "number", description: "Duration of the booking in minutes", }, }, required: ["date", "time", "duration_minutes"], }, }, ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, ], }); ``` **Шаг 2: Проверьте, хочет ли Claude вызвать инструмент** ```typescript if (response.stop_reason === "tool_use") { const toolUseBlock = response.content.find( (block): block is Anthropic.ToolUseBlock => block.type === "tool_use" ); if (!toolUseBlock) throw new Error("Expected tool_use block"); // Run your actual function const toolResult = await checkCourtAvailability( toolUseBlock.input as CourtAvailabilityInput ); // Step 3: Return the result to Claude const finalResponse = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, tools: [ /* same tools as before */ ], messages: [ { role: "user", content: "Is a court available tomorrow at 2pm for 90 minutes?", }, { role: "assistant", content: response.content }, { role: "user", content: [ { type: "tool_result", tool_use_id: toolUseBlock.id, content: JSON.stringify(toolResult), }, ], }, ], }); // finalResponse.content now has the text answer } ``` Вот и весь паттерн. Три взаимодействия с API на один вызов инструмента: определить инструменты → получить блок `tool_use` → вернуть результат. ## Реальный пример: проверка доступности кортов Pickleland Pickleland — центр пикклбола. Мы получаем запросы на бронирование в Facebook Messenger, в комментариях и через чат-бот. Вопрос почти всегда является вариацией «вы открыты в субботу в 15:00?» или «могу ли я забронировать корт для группы из 8 человек?» Агент проверки доступности использует tool use для запроса реальной системы бронирования в режиме реального времени, а не для выдачи шаблонного ответа. Вот полный агент — упрощённый, но точный для production: ```typescript // workers/availability-checker.ts import Anthropic from "@anthropic-ai/sdk"; const anthropic = new Anthropic(); const AVAILABILITY_TOOLS: Anthropic.Tool[] = [ { name: "check_availability", description: "Check court availability for a date, time, and group size. Returns available courts and their prices.", input_schema: { type: "object", properties: { date: { type: "string", description: "YYYY-MM-DD" }, start_time: { type: "string", description: "HH:MM (24h)" }, duration_minutes: { type: "number" }, players: { type: "number", description: "Number of players" }, }, required: ["date", "start_time", "duration_minutes"], }, }, { name: "get_pricing", description: "Get current pricing for court rentals and open play sessions", input_schema: { type: "object", properties: { session_type: { type: "string", enum: ["court_rental", "open_play", "clinics"], }, }, required: ["session_type"], }, }, ]; export async function handleInquiry( userMessage: string, env: Env ): Promise { const messages: Anthropic.MessageParam[] = [ { role: "user", content: userMessage }, ]; // Agentic loop — keep going until stop_reason is "end_turn" while (true) { const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 512, system: "You are the booking assistant for Pickleland, a pickleball facility in Pflugerville, TX. " + "Use the tools to look up real availability and pricing. Never make up availability or prices. " + "If the customer wants to book, direct them to pickleland.com/book.", tools: AVAILABILITY_TOOLS, messages, }); // Push the assistant's response into message history messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const textBlock = response.content.find( (b): b is Anthropic.TextBlock => b.type === "text" ); return ( textBlock?.text ?? "I wasn't able to answer that — please call us directly." ); } if (response.stop_reason === "tool_use") { // Process ALL tool calls in this response (Claude can request multiple at once) const toolResults: Anthropic.ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; let result: unknown; switch (block.name) { case "check_availability": result = await checkAvailability( block.input as AvailabilityInput, env ); break; case "get_pricing": result = await getPricing(block.input as PricingInput, env); break; default: result = { error: `Unknown tool: ${block.name}` }; } toolResults.push({ type: "tool_result", tool_use_id: block.id, content: JSON.stringify(result), }); } // Return all tool results in a single user message messages.push({ role: "user", content: toolResults }); } } } ``` Два важных момента. **Агентический цикл.** Я продолжаю, пока `stop_reason === "end_turn"`. Claude может вызвать `check_availability`, решить, что ему также нужны цены, вызвать `get_pricing`, а затем выдать окончательный ответ — это три вызова API на одно сообщение пользователя. Цикл обрабатывает это без какой-либо специальной логики. **Несколько вызовов инструментов за ход.** Claude может вернуть несколько блоков `tool_use` в одном ответе. Я обрабатываю их все и возвращаю все результаты в одном сообщении `user`. Если обрабатывать их по одному и возвращать по отдельности, вы нарушите поток разговора и потратите токены впустую. ## Реальный пример: агент исследования лидов Мой консалтинговый бренд использует агента исследования, который обогащает входящие лиды до того, как я с ними разговариваю. Когда кто-то заполняет контактную форму, агент исследует компанию и извлекает то, что мне нужно знать перед звонком. Определения инструментов для него включают инструмент записи — и именно здесь паттерн становится интересным: ```typescript const RESEARCH_TOOLS: Anthropic.Tool[] = [ { name: "search_company", description: "Search for information about a company", input_schema: { type: "object", properties: { company_name: { type: "string" }, website: { type: "string", description: "Company website if known" }, }, required: ["company_name"], }, }, { name: "save_research", description: "Save the completed research summary to Airtable. Call this when all research is complete.", input_schema: { type: "object", properties: { company_summary: { type: "string" }, estimated_size: { type: "string", enum: ["1-10", "11-50", "51-200", "200+"], }, likely_use_case: { type: "string" }, priority: { type: "string", enum: ["high", "medium", "low"] }, notes: { type: "string" }, }, required: [ "company_summary", "estimated_size", "likely_use_case", "priority", ], }, }, ]; ``` `save_research` — это то, что я называю **инструментом записи**: его цель — не получить информацию, а зафиксировать вывод Claude в базе данных в структурированном виде. Я использую этот паттерн вместо попыток парсить JSON из текстового ответа. Claude знает, когда исследование завершено, и вызывает `save_research` с правильно типизированными полями. Я никогда не пишу парсер. Это самое чистое применение tool use: определите инструмент «финального действия» с точной схемой, которую вы хотите, и Claude предоставит структурированный вывод через вызов инструмента. Никакого парсинга текста, никакого regex, никакой JSONSchema-валидации свободного текстового вывода. ## Один инструмент или много Когда начинаешь работать с tool use, инстинктивно хочется создать один гигантский инструмент, который делает всё. Сопротивляйтесь этому. Небольшие целенаправленные инструменты лучше по трём причинам: 1. **Claude лучше рассуждает о небольших инструментах.** Инструмент под названием `get_court_status`, который возвращает доступность, проще для модели, чем инструмент `manage_facility`, принимающий параметр `mode` и ветвящийся внутри. 2. **Небольшие инструменты проще тестировать.** Каждый инструмент — это TypeScript-функция, которую можно юнит-тестировать независимо от LLM. Так и нужно делать — баги в инструментах сложно отлаживать внутри живого разговора. 3. **Claude может параллелизировать небольшие инструменты.** Если два инструмента не зависят друг от друга, Claude может вызвать их в одном ответе, и вы обрабатываете их параллельно. Это работает только если инструменты действительно независимы. Исключение: инструменты, которым нужен доступ к большому общему внутреннему состоянию. Если функции нужно 10 переменных из одного источника данных, один инструмент с более богатой схемой лучше, чем 10 инструментов, каждый из которых отдельно обращается к базе данных. Моё практическое правило: начинайте с одного инструмента на каждую отдельную возможность. Объединяйте инструменты только тогда, когда видите, что Claude вызывает их вместе при каждом запросе. ## Влияние на стоимость Tool use добавляет токены. Каждое определение инструмента входит в контекст системного промпта. Каждый блок `tool_use` и `tool_result` потребляет токены в истории разговора. Для многоходового агентического цикла это накапливается быстро. Для проверки доступности Pickleland типичный разговор выполняет 3–4 вызова API (начальное сообщение + 1–2 вызова инструментов + финальный ответ), каждый обрабатывает 600–900 токенов. По ценам Haiku это обходится менее чем в $0,001 за запрос. Как я объясняю в [посте о расчёте стоимости ИИ-агентов](/ai-agent-cost-math-when-haiku-beats-sonnet/), Haiku надёжно справляется с хорошо определёнными задачами вызова инструментов и в 10 раз дешевле Sonnet при том же объёме токенов. Агент исследования лидов работает на Sonnet, потому что суждения — приоритизация лида, оценка соответствия — требуют большей способности к рассуждению, чем Haiku надёжно обеспечивает на открытых входных данных. Расчёт всё равно работает, потому что он запускается редко (несколько раз в неделю, а не тысячи раз в день). Выбор модели определяется сложностью задачи, а не личными предпочтениями. ## Точка отказа, о которой никто не говорит Наиболее распространённая точка отказа в tool use в production — это не Claude, вызывающий не тот инструмент. Это инструмент, возвращающий что-то, о чём Claude не может ясно рассуждать. Если ваш инструмент возвращает сырой объект из базы данных с 40 полями, Claude запутывается в том, какие поля важны. Если ваш инструмент выбрасывает исключение (которое проявляется как сбой Worker, а не как результат инструмента), цикл молча прерывается. Если ваш инструмент возвращает `null`, подразумевая «нет результатов», Claude не знает, повторить попытку или сдаться. Три правила для результатов инструментов: **Возвращайте компактные, явные результаты.** `{ available: true, courts: ["Court 3", "Court 5"], price_per_hour: 20 }` — не всю строку из базы данных. **Перехватывайте ошибки внутри функции инструмента и возвращайте их как структурированные результаты.** `{ error: "booking system timeout", retry: true }` — не выброшенное исключение, которое роняет Worker. **Делайте «нет результатов» явным.** `{ available: false, next_available: "2026-07-23T14:00:00Z" }` — не `null` и не пустой массив без контекста. Claude гораздо лучше рассуждает о чётких сигналах, чем о неоднозначных возвращаемых значениях. Каждый час, который я потратил на отладку tool use в production, был связан с неясными результатами, а не с рассуждениями модели. ## Вывод оператора Tool use — это функция, которая превращает Claude из генератора текста в оператора. Определяйте целенаправленные инструменты с чёткими схемами ввода. Обрабатывайте все блоки `tool_use` в одном ответе модели. Выполняйте агентический цикл до тех пор, пока `stop_reason === "end_turn"`. Возвращайте чистые, компактные результаты из ваших функций инструментов — не сырые объекты данных, не выброшенные исключения, не неоднозначные nulls. Модель занимается рассуждением. Ваш код занимается реальными действиями. Сохраняйте чёткое разделение этих двух задач — и архитектура останется поддерживаемой даже по мере добавления инструментов. Если вы создаёте свой первый агент с tool use, начните с приведённого выше паттерна проверки доступности — один инструмент, одна цель, один агентический цикл. Запустите это в production. Затем добавьте второй инструмент. --- **По теме:** [Стек агентов, который я использую для запуска 30+ рабочих агентов](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Haiku vs Sonnet: расчёт стоимости для задач агентов](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Агенты, запускаемые по событию, vs. по расписанию: какой паттерн для какой задачи](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) **Создаёте агент с tool use и застряли?** [Свяжитесь со мной](/contact/) — я проектирую и создаю архитектуры рабочих агентов для команд операторов. ## FAQ ### Работает ли Claude tool use со всеми моделями? Да — tool use поддерживается всеми текущими моделями Claude. [Claude](/recommends/claude) Haiku надёжно обрабатывает хорошо определённые инструменты с чёткими схемами и является самым дешёвым вариантом для задач с высоким объёмом. Sonnet лучше справляется с более неоднозначными или открытыми решениями о вызове инструментов. Начните с Haiku; переходите выше, если качество вывода недостаточно. ### В чём разница между Claude tool use и OpenAI function calling? Механически идентичны. OpenAI придумал «function calling»; Anthropic называет это «tool use». В обоих случаях: вы определяете JSON-схемы, модель возвращает структурированные вызовы, ваш код выполняет функцию. Форма API различается, но концепция та же. ### Может ли Claude вызвать несколько инструментов в одном ответе? Да. Claude может вернуть несколько блоков `tool_use` в одном ответе `assistant`. Обработайте их все и верните все результаты в одном сообщении `user`. Смотрите паттерн агентического цикла в примере с Pickleland выше — цикл `for` по `response.content` корректно обрабатывает это. ### Сколько инструментов мне следует определить на одного агента? Я остаюсь в пределах 8–10 инструментов на агента. Сверх этого я видел, что Claude иногда выбирает не тот инструмент с первой попытки, что тратит токены на цикл исправления. Если вам нужно более 10 возможностей, разбейте агента на несколько агентов со специализированными наборами инструментов, а не создавайте одного агента, который знает всё. ### Стоит ли использовать tool use для получения структурированного вывода? Да — паттерн инструмента записи `save_research` чище, чем просить Claude вернуть JSON в текстовом блоке, а затем его парсить. Определите инструмент «финального действия» с точной схемой, которую вы хотите. Claude вызовет его с правильно типизированными полями, когда закончит. Парсер не нужен. --- ## Как Поисковые Системы На Самом Деле Оценивают Качество Контента в 2026 Году Source: https://alejandrorioja.com/ru/how-search-engines-evaluate-content-quality/ Published: 2026-07-20 Tags: SEO, GEO ## Содержание _Опубликовано в июле 2026 года._ **Кратко:** Поисковые системы и ИИ-движки перестали оценивать страницы по отдельности. Они оценивают сайты — глубину покрытия темы, сигналы доверия, которые выдерживают проверку, и постоянство на протяжении месяцев, а не одну отличную статью. Я веду 384 английских поста на 13 языках и еженедельно отслеживаю, цитируют ли меня ChatGPT, Perplexity и Google AI Overviews. Закономерность устойчива: изолированные посты выходят на плато, кластеры дают накопительный эффект, а сигналы доверия, влияющие на частоту цитирования, — скучные, структурные и дешёвые в реализации. **[Взгляд оператора]** Я не теоретизирую о качестве контента — я веду контент-движок этого сайта и наблюдаю, что происходит с показателями цитирования, когда я что-то меняю. Этот пост целиком построен на том, что я измерил на alejandrorioja.com: реальные размеры кластеров, реальный шестинедельный эксперимент с цитированием, реальные тесты schema-разметки. Здесь нет ничего, что было бы догадкой о том, как «вероятно» работают алгоритмы. ## Качество давно перестало быть вопросом отдельной страницы Ментальная модель, которой всё ещё придерживается большинство: напиши хорошую статью — она попадёт в топ. Это никогда не было полностью верно, а сейчас откровенно вводит в заблуждение для всего, что выходит за рамки узкого низкочастотного запроса. У меня есть прямой способ увидеть это на собственном сайте. Я публикую материалы в рамках нескольких реальных кластеров — кластер об ИИ-агентах и Claude из 29 постов, кластер объяснений бизнес-моделей «Как X зарабатывает деньги», который вырос до 20 постов (Google, OpenAI, Anthropic, Uber, Salesforce и другие), и большой кластер SEO/GEO — крупнейшая отдельная тема сайта по числу тегов. Отдельный пост по теме, которую я затронул лишь однажды, ведёт себя совершенно иначе, чем пост внутри одного из этих кластеров, даже если отдельный материал объективно написан лучше. Посты внутри кластеров цитируют чаще, они держат позиции стабильнее и быстрее восстанавливаются после обновления алгоритма. Изолированные посты либо дают всплеск, либо нет, а когда не дают — рядом нет накопленного авторитета, на который можно опереться. Именно этот механизм на самом деле стоит за тем, что часто продают как [стратегию тематического авторитета для ИИ](https://www.linkbuildinghq.com/blog/how-to-build-topical-authority-for-ai/) — не мистический показатель доверия, а простой факт: страница, стоящая рядом с 28 другими страницами на ту же тему, даёт и краулеру Google, и этапу поиска у LLM больше подтверждающего контекста, на который можно опереться. Я намеренно подробно описал [полный механизм этой структуры](/pillar-content/) — если коротко, кластер работает только тогда, когда каждый пост в нём ссылается на опорную страницу, а опорная страница ссылается обратно на каждый пост, так что тематическая карта становится явной, а не тем, что краулеру приходится восстанавливать самому. Практический тест, который я применяю перед публикацией чего-либо нового: расширяет ли этот пост кластер, которым я уже владею, или это разовая, отдельно стоящая публикация? Разовые публикации не под запретом — некоторым запросам действительно нужна лишь одна страница, — но я заранее знаю, что такая публикация конкурирует только за счёт сигналов уровня страницы, без какого-либо накопительного эффекта, который кластерный пост получает бесплатно. ## «Реальная ценность, а не наполнитель» — проверяемое утверждение, а не ощущение Обобщённая версия этого совета звучит так: «добавляйте глубину и контекст, не повторяйте общедоступную информацию». Верно, но бесполезно без способа это проверить. Вот мой реальный тест, выполняемый в реальном масштабе: у меня 384 английских поста. Каждый переводится на 12 других языков [агентом, которого я построил именно для этого](/how-to-translate-one-blog-post-into-13-languages-with-one-agent/). Перевод дёшев — весь бэклог из 341 поста обошёлся примерно в 1,70 доллара на вызовах API Haiku. Написание — нет. Если бы я мог наращивать объём, слегка переписывая одну и ту же идею в десяти разных формулировках, тот же агент позволил бы мне масштабировать дублирование так же легко, как он масштабирует перевод. Я этого не делаю, потому что дублирующая подача не проходит настоящий тест: отвечает ли эта страница на вопрос, на который ни одна другая страница моего сайта уже не отвечает так же хорошо или лучше? Именно этот фильтр важнее любой стилистической рекомендации. «Наполнитель» — это не проблема тона, это проблема избыточности: страница, которая повторяет соседнюю страницу, не добавляя нового угла, цифры или примера. Я проверяю это перед публикацией, задавая вопрос: не съест ли новый пост цитирования уже существующего, вместо того чтобы добавить новую поверхность для цитирования? Если два поста на моём сайте одинаково хорошо отвечают на один и тот же запрос, один из них — наполнитель, независимо от того, насколько хорошо он написан. ## Сигналы доверия, которые я реально построил и измерил «Надёжность» — самый расплывчатый термин в любой обобщённой статье по SEO, за которым обычно следует список вроде «цитируйте источники, показывайте экспертизу, будьте точны» — без какого-либо способа проверить, сдвинуло ли это хоть что-то. Конкретная версия, которую применяю я: schema-разметка, потому что это единственный сигнал доверия, который ИИ-движок разбирает механически, а не выводит логически. Я подробно изложил [полную реализацию](/schema-markup-for-geo/) в другом посте и глубже разобрал, [какие типы разметки действительно окупаются](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). Если коротко: `Article`/`BlogPosting` с реальным именованным автором и честной датой `dateModified` — это якорь авторства; `FAQPage` и `HowTo` дают наибольший эффект, потому что передают модели заранее готовый ответ на вопрос или заранее структурированную процедуру вместо того, чтобы заставлять её выводить это из прозы; схемы `Person` и `Organization` существуют, чтобы модель не путала меня с кем-то ещё, кто носит моё имя. Ничего из этого для меня не абстрактно — это вмешательство, стоящее за реальным результатом. Применение четырёхчастной структурной надстройки (блок с кратким содержанием, нумерованные шаги, раздел FAQ, ссылки на первоисточники) к 41 опорной странице, которые уже вызывали появление в Google AI Overviews, подняло частоту цитирования с 4 из 41 до 19 из 41 за шесть недель — [полный отчёт о шестинедельном тесте здесь](/google-ai-overview-citation-case-study/). Это не «добавь сигналы доверия и надейся». Это измеренное сравнение «до/после» на моих собственных страницах, с оговоркой, которая прямо указана в самом посте: это сработало только на страницах, у которых уже был базовый уровень авторитета — попадание в топ-5 в органической выдаче. Структура усиливает уже существующий сигнал; она не создаёт его из ничего. ## Постоянство даёт накопительный эффект, но «постоянство» — не значит постоянные обновления Обобщённое утверждение здесь обычно звучит как «свежесть важна, но не каждую статью нужно обновлять» — без привязки к реальной периодичности. Вот моя. Я не трогаю большинство постов после публикации. Я поддерживаю постоянный набор опорных постов и обновляю их каждые 6-12 месяцев, когда меняются базовые факты — выходит новая модель, меняется цена инструмента, статистика устаревает. `dateModified` меняется только тогда, когда контент действительно меняется; я тестировал подделку этой даты, и это не работает — движки видят насквозь обновлённую дату без содержательной правки, что, кстати, подтвердил и кейс с AI Overview. Сигнал постоянства, за которым я реально слежу еженедельно, — это не частота публикаций, а охват цитирований: я еженедельно прогоняю отслеживаемый список критичных для бизнеса запросов через ChatGPT, Perplexity и Google и записываю, цитируют ли меня — [методология здесь](/how-to-measure-ai-search-traffic/). Охват цитирований — опережающий индикатор: он сдвигается раньше, чем реферальный трафик или рост брендовых запросов, поэтому именно это число говорит мне, действительно ли кластер набирает авторитет со временем или просто стоит на месте. Сайт, который публикует один пост и замолкает, не получает второго шанса при этой еженедельной проверке; сайт, который продолжает расширять кластер, — получает. ## Что на самом деле вознаграждает оценка «на уровне сайта», по слоям Три движка, за которыми я слежу, не взвешивают одни и те же сигналы одинаково. Вот практическая таблица, которую я держу в голове, решая, куда вкладывать усилия: | Слой качества | Как это выглядит на практике | Где я это измерил | | --- | --- | --- | | Тематическая глубина | 20-30+ взаимосвязанных постов по одной теме, опорная страница ссылается на каждый пост кластера и обратно | Кластер ИИ-агентов (29 постов), кластер «Как X зарабатывает деньги» (20 постов) | | Структурная извлекаемость | Блок с кратким содержанием, нумерованные шаги, FAQ, соответствие реальным формулировкам пользователей | 4/41 → 19/41 цитирований в AI Overview за 6 недель | | Авторство/доверие | Именованный автор + точная `dateModified` + схема Person/Organization | Schema-разметка для GEO, разбор типов schema | | Постоянство во времени | Еженедельное отслеживание цитирований по движкам, а не постоянные переписывания | Методология измерения ИИ-поиска | Самая частая ошибка, которую я вижу в обобщённых советах, — это восприятие всего перечисленного как единого недифференцированного показателя «качества». Это не так. Страница может блестяще справляться со структурной извлекаемостью и всё равно проигрывать конкуренту с большей тематической глубиной. Страница может находиться внутри глубокого кластера и всё равно терять конкретное цитирование в пользу более свежего конкурента с лучшей schema-разметкой. Понимание того, какой именно слой является узким местом для конкретной страницы, — это большая часть работы. ## Где это ломается — честные оговорки Лучше обозначить границы, чем переоценивать закономерность: - **Авторитет домена всё ещё остаётся входным барьером.** Вмешательство с AI Overview сработало только на страницах, которые уже занимали топ-5 в органической выдаче. Структура усилила уже существующий сигнал; она не создала авторитет из холодной страницы. - **Движки расходятся в том, что вознаграждают.** Прогнав одни и те же 50 частотных запросов через ChatGPT и Google, я обнаружил лишь около 40% пересечения по тому, какие источники цитировались — [полный разбор здесь](/chatgpt-search-vs-google-50-term-test/). Оптимизация под «поисковые системы» как единую цель — уже неверный подход: вы оптимизируетесь под несколько движков, которые сходятся в базовых вещах и расходятся во всём остальном. - **Некоторым категориям кластер действительно не нужен.** Несколько моих самых результативных страниц — настоящие одиночные публикации. Глубина — это рычаг, а не универсальное требование: попытка искусственно собрать кластер там, где пространство запросов этого не поддерживает, порождает ровно тот тонкий, разбавленный контент, которого вся эта система призвана избегать. ## Часто задаваемые вопросы ### Может ли одна отличная статья когда-нибудь обойти посредственный кластер? Да, для достаточно узкого запроса с низкой конкуренцией. Но для любого частотного запроса с реальной конкуренцией страницы, удерживающие позиции долгосрочно, почти всегда опираются на кластер. Я наблюдал, как изолированные посты дают всплеск и затухают так, как посты внутри кластера не затухают. ### Сколько постов нужно теме, чтобы считаться настоящим кластером? Точного числа нет, но в моих собственных данных эффект становится явно заметен примерно на уровне 8-10 действительно различных постов по подтемам одной темы — этого достаточно, чтобы опорная страница осмысленно ссылалась вовне и чтобы у каждого поста кластера было конкретное место, куда отправлять читателей, которым нужна большая глубина. ### Действительно ли необходима schema-разметка, или достаточно хорошего текста? Хороший текст необходим, но недостаточен именно для цитирования ИИ-движками. Движки надёжнее извлекают структурированные факты из schema `FAQPage` и `HowTo`, чем из одной только прозы, потому что schema убирает шаг логического вывода. Я измерил прирост цитирования от однозначных до двузначных процентных пунктов после добавления её к ранее не размеченным постам. ### Как часто нужно обновлять старый контент вместо публикации новых постов? Я обновляю опорные посты каждые 6-12 месяцев, когда меняется реальный факт, и никогда не подделываю `dateModified` без содержательной правки. Большая часть моего контентного бюджета уходит на новые посты, расширяющие кластеры, а не на переписывание — свежесть важна, но это не доминирующий рычаг по сравнению с тематической глубиной и структурой. ### Что важнее всего исправить в первую очередь? Если страница уже неплохо ранжируется органически, но её не цитируют ИИ-движки, добавьте чистый блок с кратким содержанием, который прямо отвечает на частотный запрос. В моём собственном шестинедельном тесте это оказалось безусловно самым мощным отдельным рычагом — сильнее, чем FAQ-schema, сильнее, чем ссылки на первоисточники, сильнее, чем нумерованные шаги. ## Итог Оценка качества контента сместилась со страницы на сайт, и сигналы уровня сайта, которые реально влияют на результат, измеримы, а не мистичны: глубина кластера, которую можно посчитать, структурные надстройки, которые можно A/B-тестировать, schema, которую можно валидировать, и число охвата цитирований, которое можно отслеживать еженедельно. Ничто из этого не требует угадывать, чего «хочет» алгоритм. Это требует публикации внутри реальной тематической структуры, предоставления движкам чистого извлекаемого ответа вместо того, чтобы заставлять их выводить его самим, и достаточно частой проверки результата, чтобы понимать, работает ли это. Я применяю все четыре этих практики на этом сайте каждую неделю, и приведённые выше цифры — это то, что они реально дали, а не то, что обещает обобщённое руководство. --- ## Claude против ChatGPT для бизнеса в 2026 году: честный взгляд оператора Source: https://alejandrorioja.com/ru/claude-vs-chatgpt-for-business-2026/ Published: 2026-07-18 Tags: AI Agents, Productivity TL;DR: Claude побеждает в построении агентов, работе с длинными контекстами, программировании и всём, что работает в производстве в масштабе. ChatGPT побеждает в потребительских интеграциях, голосовом режиме и более широкой экосистеме плагинов, если ваш рабочий процесс живёт в интерфейсе чата. Если вы создаёте автоматизированные рабочие процессы или ИИ-агентов, Claude является лучшей основой. Если вам нужен способный чат-ассистент с большим количеством сторонних подключений, у ChatGPT есть преимущество. Для большинства предпринимателей настоящий вопрос таков: вы общаетесь с ИИ или строите с ИИ? Этот ответ определяет инструмент. ## Содержание _Опубликовано июль 2026._ **TL;DR:** Claude побеждает в построении агентов, работе с длинными контекстами, программировании и всём, что работает в производстве в масштабе. ChatGPT побеждает в потребительских интеграциях, голосовом режиме и более широкой экосистеме плагинов, если ваш рабочий процесс живёт в интерфейсе чата. Если вы создаёте автоматизированные рабочие процессы или ИИ-агентов, Claude является лучшей основой. Если вам нужен способный чат-ассистент с большим количеством сторонних подключений, у ChatGPT есть преимущество. Для большинства предпринимателей настоящий вопрос таков: вы общаетесь с ИИ или строите с ИИ? Этот ответ определяет инструмент. **[Взгляд оператора]** Я веду два бизнеса — консалтинговый бренд и Pickleland, площадку для пикклбола в Пфлюгервилле, штат Техас — с более чем 30 ИИ-агентами в производстве, обрабатывающими ответы в социальных сетях, продвижение мероприятий, отслеживание бронирований, черновики новостных рассылок и многое другое. Весь мой стек агентов построен на [Claude](/recommends/claude). Я также достаточно использовал ChatGPT, чтобы знать, где каждый терпит неудачу. Это не обзор бенчмарков. Это взгляд практика. ## Вопрос, который действительно важен Большинство сравнений спрашивают: «Какая модель умнее?» Это неправильный вопрос для бизнес-использования. Правильный вопрос: **что вы строите и что должно работать надёжно в масштабе?** Менеджер по маркетингу, желающий, чтобы ИИ помогал с написанием текстов, предъявляет иные требования, чем основатель, строящий автоматизированный конвейер квалификации потенциальных клиентов. Солопредприниматель, использующий ИИ для подготовки к встречам, имеет иные потребности, чем оператор, строящий агентов, обрабатывающих 500 запросов клиентов в неделю. Инструмент, который побеждает для одного, часто является неправильным для другого. Этот подход определяет всё, что следует ниже. ## Где Claude побеждает ### 1. Работа с длинными контекстами Нативное контекстное окно Claude — 200К токенов — обрабатывает вещи, которые ломают другие модели. Я регулярно передаю Claude полные истории разговоров с клиентами, целые черновики контрактов или многодокументные исследовательские резюме и прошу синтезировать или перекрёстно ссылаться. Он держит нить. Конкурирующие модели теперь технически поддерживают длинный контекст, но практическое ухудшение на сложных задачах всё ещё хуже, чем у Claude. Для бизнес-задач, включающих чтение длинных документов, анализ объёмных экспортов данных или поддержание согласованности в длинных рабочих процессах, у Claude есть реальное преимущество. ### 2. Поведение агента в производстве Когда вы запускаете Claude как агента — вызывая инструменты, принимая решения в цикле, записывая в базы данных, обрабатывая ошибки — он ведёт себя более последовательно, чем ChatGPT, по моему опыту. Он более надёжно следует инструкциям системного промта, производит структурированный вывод, который легче разбирать, и менее склонен отклоняться от задачи при увеличении контекста. Это имеет огромное значение для агентов. Модель, которая следует вашему системному промту 95% времени против 99% времени, звучит похоже. При 500 вызовах в день это 25 случаев отклонения в день, которые нужно обнаруживать и исправлять. Статья, которую я написал о [том, как писать системные промты для ИИ-агентов, которые не дают сбоев в производстве](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/), подробно освещает это, но краткая версия такова: следование инструкциям Claude на уровне системного промта — лучшее, что я тестировал. ### 3. Программирование и техническая работа Я строю почти всё на TypeScript в Cloudflare Workers. Claude Code — мой ежедневный инструмент разработки — и он действительно полезен, а не просто «достаточно хорош». Для архитектурных вопросов, отладки, рефакторинга и написания логики агентов с нуля Claude последовательно превосходит то, что я использовал в эквиваленте ChatGPT. Это не просто сравнение Claude Code против ChatGPT Chat. Даже сырой Claude Opus 4.8 через API пишет более чистый код с меньшим количеством галлюцинированных импортов, чем эквивалент GPT-4o на тех же задачах. ### 4. Опыт разработчика в API Если вы строите с API — не просто общаетесь в чате — опыт разработчика Claude лучше в 2026 году. Anthropic SDK чистый, конечная точка подсчёта токенов действительно полезна для оценки затрат, кэширование промтов хорошо реализовано и экономит реальные деньги на повторяющихся контекстах, а обработка ошибок предсказуема. Для тех, кто программно строит агентов, разрыв в качестве API важен. Он не большой, но последовательный. ### 5. Точность следования инструкциям в сложных промтах Claude лучше справляется с нюансированными системными промтами с несколькими условиями, чем ChatGPT. Когда мне нужен агент, следующий набору правил — «если комментарий является вопросом, сделайте X; если это жалоба, сделайте Y; если упоминаются конкуренты, отметьте для проверки человеком» — Claude более последовательно разбирает и применяет эти ветви. Для простых промтов разница минимальна. Для сложной условной логики, встроенной в системный промт, Claude более надёжен. ## Где ChatGPT побеждает ### 1. Потребительские интеграции и плагины Экосистема плагинов ChatGPT и спектр инструментов, доступных через нативный интерфейс, шире. Если ваш рабочий процесс уже живёт в инструментах с нативными интеграциями ChatGPT — определённых CRM, приложениях продуктивности, инструментах исследования — и вы в основном работаете через интерфейс чата, готовые подключения ChatGPT экономят усилия. Для продвинутых пользователей, желающих делать всё из интерфейса чата без построения пользовательских интеграций, это важно. ### 2. Голосовой режим Advanced Voice Mode ChatGPT действительно превосходен. Для мобильного использования, устного разбора идей или подготовки к звонкам за рулём — это лучший голосовой интерфейс ИИ, который я использовал. У Claude есть голосовой ввод, но ничего сопоставимого с полным разговорным голосовым режимом GPT-4o к середине 2026 года. Если голос является основным интерфейсом для вашего случая использования, ChatGPT явно побеждает. ### 3. Генерация изображений (через DALL-E) ChatGPT Plus включает генерацию изображений через DALL-E в той же подписке. Claude нативно не генерирует изображения. Если вам нужен единый инструмент для текстовой и визуальной работы без добавления Midjourney или другого сервиса, у ChatGPT есть преимущество. ### 4. Знакомость и принятие Больше людей использовали ChatGPT. Если вы вводите ИИ-инструменты команде без опыта работы с ИИ, начало с ChatGPT создаёт меньше трений — большинство людей хотя бы однажды его открывали. Это не преимущество в возможностях, но скорость интеграции является реальным операционным фактором. ## Сравнение затрат Именно здесь всё становится нюансированным, и большинство сравнений вводят в заблуждение. Обе платформы имеют многоуровневое ценообразование. На уровне API: - **Claude Haiku 4.5** и **GPT-4o mini** — недорогие рабочие лошадки для простых задач с большим объёмом. Они сопоставимы по ценовому диапазону, при этом выбор в основном определяется требованиями задачи. - **Claude Sonnet/Opus** и **GPT-4o** — средний и высший уровень. У Claude есть [кэширование промтов](/prompt-caching-cut-your-claude-costs-without-switching-models/), которое значительно снижает затраты на рабочие процессы с повторяющимся контекстом — если ваши агенты повторно используют одинаковый системный промт и контекстное окно между вызовами, кэшированная цена Claude может быть на 50–80% дешевле, чем некэшированная ставка. У ChatGPT нет прямого эквивалента. - На самом высоком уровне Claude Fable 5 и последние варианты GPT-4 находятся в одном диапазоне базовой стоимости, но разница в токенизаторе важна — у Fable 5 токенизатор считает токены иначе, чем в более ранних моделях, поэтому эталонные подсчёты токенов не переводятся напрямую. Вывод по затратам: **для производственных агентов с высоким объёмом вызовов кэширование промтов Claude делает его материально дешевле** для рабочих нагрузок, повторно использующих контекст. Для чистой оплаты за вызов на свежих контекстах они достаточно близки, чтобы производительность определяла выбор, а не прейскурантная цена. Система, которую я использую для оценки этого, описана в [статье о математике затрат ИИ-агентов](/ai-agent-cost-math-when-haiku-beats-sonnet/). ## Матрица принятия решений | Случай использования | Победитель | |---|---| | Построение ИИ-агентов в производстве | Claude | | Сложное программирование и архитектура | Claude | | Анализ документов с длинным контекстом | Claude | | Чат-ассистент с интеграциями плагинов | ChatGPT | | Рабочие процессы с голосом как основным интерфейсом | ChatGPT | | Изображения + текст в одном интерфейсе | ChatGPT | | Автоматизация на основе API в масштабе | Claude | | Адаптация команды без опыта работы с ИИ | ChatGPT | | Агенты, обращённые к клиентам, в производстве | Claude | | Экономическая эффективность в высокообъёмных конвейерах | Claude (с кэшированием) | ## Мой реальный ответ Я использую [Claude](/recommends/claude) для всего в производстве. Не потому что он выигрывает каждый бенчмарк — это не так — а потому что: 1. Мои агенты следуют инструкциям системного промта достаточно надёжно, что я почти не трачу время на исправление галлюцинированных или нецелевых выводов. 2. Стек Cloudflare Workers + Claude API обходится менее чем в $100/месяц для моей совокупной рабочей нагрузки, а кэширование промтов сократило затраты на мои самые тяжёлые рабочие процессы более чем вдвое. 3. Claude Code стал моим основным интерфейсом программирования, и наличие одной и той же модели как для разработки, так и для производства упрощает ментальную модель. 4. Для задач с длинным контекстом — чтение PDF, синтез по нескольким документам, поддержание согласованности в многоэтапных рабочих процессах — Claude обрабатывает полное окно 200К лучше, чем я испытывал в других местах. Если бы я руководил командой, которой нужны ИИ-инструменты без построения пользовательской инфраструктуры, я, вероятно, посадил бы их на ChatGPT Plus — ширина готовых плагинов и голосовой режим действительно полезны на потребительском уровне. Но для создания чего-либо, а не просто использования, Claude является правильной основой. ## Часто задаваемые вопросы ### Claude умнее ChatGPT? Ни один из них не является универсально умнее. Claude лучше в рассуждениях с длинными контекстами, следовании инструкциям и программировании. ChatGPT (GPT-4o) лучше в мультимодальных задачах с изображениями и голосом. Конкретные бенчмарки чередуются между ними с каждым выпуском модели. Более полезный вопрос — какая модель лучше для вашей конкретной задачи. ### Могу ли я использовать и Claude, и ChatGPT? Да, и для некоторых рабочих процессов вы можете захотеть этого. Claude API и OpenAI API оба просты в интеграции. Некоторые команды используют Claude для серверной части агентов и ChatGPT для пользовательских интерфейсов чата с интеграциями. Тем не менее, запуск двух провайдеров ИИ добавляет операционную сложность — управление учётными данными, отслеживание затрат, различия в поведении для управления. Начните с одного. ### Какой лучше для написания контента? Claude, по моему опыту. Он производит вывод, который звучит менее обобщённо, лучше поддерживает определённый стиль при наличии примеров и более последовательно обрабатывает длинноформатный контент. Для короткого социального контента или электронных писем, где любой подойдёт, разница невелика. ### Есть ли у Claude бесплатный уровень? Да — Claude.ai имеет бесплатный уровень с ограничениями на сообщения. [Подписки Claude Pro и Max](/recommends/claude) снимают ограничения и добавляют приоритетный доступ, загрузку файлов и полное контекстное окно. ChatGPT аналогично имеет бесплатный уровень с ограниченным по использованию доступом к GPT-4o. ### Стоит ли переходить с ChatGPT на Claude? Если вы используете ИИ преимущественно как интерфейс чата и довольны ChatGPT, затраты на переключение могут не стоить усилий, если у вас нет конкретной потребности, которую Claude решает лучше. Если вы создаёте автоматизации, агентов или выполняете программирование, я бы настоятельно рекомендовал попробовать Claude — поведение агента и опыт разработчика существенно влияют на производственные рабочие нагрузки. --- ## Как построить продуктизированный сервис: моя система для превращения экспертизы в масштабируемый доход Source: https://alejandrorioja.com/ru/productized-service-how-to-package-your-expertise/ Published: 2026-07-16 Tags: Entrepreneurship, Marketing TL;DR: Продуктизированный сервис — это предложение с фиксированным объёмом и фиксированной ценой, которое вы выполняете одинаково каждый раз. Четыре шага: найдите работу, которую клиенты уже регулярно заказывают у вас, жёстко определите границы объёма, установите цену на основе ценности результата (не часов), и постройте систему исполнения до продажи следующему клиенту. Большинство консультантов пропускают четвёртый шаг и продолжают менять время на деньги. Это единственный шаг, который реально создаёт масштаб. ## Содержание _Опубликовано в июле 2026 года._ **TL;DR:** Продуктизированный сервис — это предложение с фиксированным объёмом и фиксированной ценой, которое вы выполняете одинаково каждый раз. Четыре шага: найдите работу, которую клиенты уже регулярно заказывают у вас, жёстко определите границы объёма, установите цену на основе ценности результата (не часов), и постройте систему исполнения до продажи следующему клиенту. Большинство консультантов пропускают четвёртый шаг и продолжают менять время на деньги. Это единственный шаг, который реально создаёт масштаб. **[Заметка оператора]** Я провёл годы, выполняя индивидуальные консалтинговые проекты — каждый с разным объёмом, разной ценой, разным исполнением. Результатом был бизнес, требующий моего прямого внимания в каждом проекте. Продуктизация это исправила: превратить наиболее востребованную работу в чётко определённые предложения с понятными результатами, фиксированными ценами и повторяемым руководством по исполнению. Вот точная система и ошибки, которые я совершил при её построении. ## Что такое продуктизированный сервис на самом деле Продуктизированный сервис — это не ретейнер. Это не подписка. Это чётко определённое, повторяемое предложение с фиксированным объёмом, фиксированной ценой и процессом исполнения, достаточно хорошо задокументированным, чтобы работать одинаково каждый раз. Контраст с индивидуальным консалтингом: вместо «мы делаем стратегию ИИ-автоматизации за $X–Y в зависимости от объёма», вы продаёте «дорожную карту ИИ-автоматизации: письменный аудит 5 рабочих процессов, приоритизированные рекомендации по построению и 30-минутный звонок для передачи результатов, за $2500». Объём фиксирован. Цена фиксирована. Сроки фиксированы. Единственная переменная — скажет ли клиент да. Отличие от ретейнера в том, что это проектная работа. Чёткое начало. Чёткий конец. Никакой открытой ежемесячной оплаты, никакого расширения объёма, никаких разговоров «а можете ещё посмотреть вот это?» постфактум. Что делает его масштабируемым: система, а не предложение. Предложение с фиксированной ценой — это просто переоценённая индивидуальная работа. За продуктизированным сервисом стоит руководство по исполнению. ## Шаг 1: Найдите то, за чем клиенты уже обращаются к вам Самый простой продуктизированный сервис для построения — тот, который вы уже регулярно выполняете, но каждый раз воспринимаете как индивидуальную работу. Просмотрите последних 10–15 клиентов или проектов и ищите закономерности: - Какая проблема встречается чаще всего? - Какой результат вы производите наиболее часто? - Какой тип взаимодействия идёт наиболее гладко и получает лучшие отзывы клиентов? Для меня закономерность была очевидна: клиенты постоянно просили об одном и том же — помочь картировать их процессы, выбрать, какие автоматизировать, и подобрать правильные инструменты. Я делал это регулярно, но с разным объёмом каждый раз. Эта закономерность — ваша отправная точка. Не новый сервис, который, по вашему мнению, нужен рынку. То, что вы уже делаете. Один фильтр: продуктизируйте только работу, где результат в основном одинаков для всех клиентов. Если каждый клиент получает совершенно разный результат, работа ещё не готова к продуктизации — она всё ещё подлинно индивидуальная. Это нормально; это просто означает, что сначала идёт работа по определению. ## Шаг 2: Определите границы объёма — и соблюдайте их Именно здесь большинство консультантов терпит неудачу. Они определяют предложение расплывчато, оставляют объём открытым для интерпретации и оказываются в тех же разговорах о расширении объёма, что и раньше. Продуктизированный сервис требует жёстких границ объёма. Вы определяете, что включено, а что нет, в письменном виде, до первого разговора о продаже. Пример определения объёма для спринта по стратегии ИИ-автоматизации: **Включено:** - 60-минутный структурированный вводный звонок - Письменный аудит до 5 рабочих процессов - Приоритизированная дорожная карта автоматизации с рекомендациями инструментов - Оценка «строить vs. купить» для топ-3 кандидатов - 30-минутный звонок для передачи результатов **Не включено:** - Внедрение (построение агентов или интеграций) - Доработки после передачи - Более 5 рабочих процессов - Работа вне согласованного объёма автоматизации Список «не включено» важен не меньше списка «включено». Когда клиент просит что-то за пределами границ, у вас есть два варианта: сказать, что это выходит за рамки данного предложения, или создать дополнение с собственным объёмом и ценой. Что вы не делаете — это поглощаете запрос. Поначалу это кажется неудобным. Вы привыкли говорить да, чтобы клиенты были довольны. Продуктизация требует говорить «это отдельный проект» — и действительно это иметь в виду, последовательно. ## Шаг 3: Устанавливайте цену исходя из ценности результата, а не ваших часов Почасовая оплата и продуктизированные сервисы несовместимы. Как только вы начинаете рассчитывать исходя из своего времени, вы снова сделали это индивидуальной работой. Три переменные для ценообразования продуктизированного предложения: 1. **Стоимость для клиента нерешённой проблемы.** Дорожная карта ИИ-автоматизации, которая высвобождает $4000/месяц в операционной эффективности, стоит тысячи для покупателя. Ваши 8 часов работы — неверный ценовой ориентир. 2. **Что покупатели тратят на сопоставимые результаты.** Не то, что берут конкуренты — что клиенты реально тратят на похожие результаты у консультантов, дробных руководителей или программного обеспечения, частично решающего проблему. Это устанавливает ваш потолок. 3. **Ваш минимальный порог.** Сколько вам нужно заработать на этом предложении, чтобы оно стоило вашего внимания, с учётом времени исполнения, управления клиентами и накладных расходов? Это устанавливает ваш пол. Устанавливайте цену в этом диапазоне. Для ранних продуктизированных предложений начинайте с середины. По мере накопления отзывов и совершенствования скорости исполнения двигайтесь к потолку. Не делайте скидок. Если кто-то не может позволить себе предложение, он не тот клиент для него. Вы можете создать более дешёвое предложение для другого сегмента — но не разбавляйте основное предложение ситуативными скидками, иначе вернётесь к индивидуальному ценообразованию. ## Шаг 4: Постройте систему исполнения до следующей продажи Этот шаг определяет, есть ли у вас продуктизированный сервис или просто проект с фиксированной ценой. После первой передачи результатов — до продажи следующему — сделайте это: 1. **Задокументируйте каждый шаг по порядку.** Не расплывчатый план. Чеклист достаточно детальный, чтобы человек, знакомый с областью, мог выполнить 80% процесса по нему. Я храню их в [Notion](/recommends/notion) — одна страница на каждый шаг рабочего процесса, с шаблонами, примерами результатов и деревьями решений для сложных суждений. 2. **Определите, что заняло больше времени, чем должно.** Каждая первая передача медленнее, чем нужно. Найдите узкие места и систематизируйте их: формы для сбора информации, шаблоны результатов, готовые фреймворки. 3. **Постройте структурированный процесс сбора информации.** Получение информации от клиента в стандартизированной форме до звонка — это то, что делает исполнение предсказуемым. Звонок — для уточняющих вопросов, а не сбора информации. 4. **Создайте шаблон результата.** Каждый клиент получает одну и ту же структуру выходных данных. Содержание меняется; структура нет. Это делает исполнение быстрым, а результат — последовательным и профессиональным каждый раз. Если пропустить этот шаг и просто продавать следующему, вы всё ещё делаете индивидуальную работу — вы просто дали ей фиксированную цену. Система — вот что делает её по-настоящему масштабируемой. ## Что продуктизация реально открывает Главная выгода — не более высокий доход. Это лучший доход: предсказуемый спрос, более быстрое исполнение, меньше переговоров и возможность сказать нет клиентам, которым нужно что-то за пределами предложения. Второй плюс: документация по исполнению становится интеллектуальной собственностью. Руководство, которое вы создаёте для продуктизированного консалтингового предложения, составляет большую часть содержания курса или обучающей программы. Я сделал это с консалтингом по ИИ-автоматизации — руководство по исполнению стало прямым основой учебного плана моего курса AI Agents for Beginners. Третий плюс: рычаг. С задокументированной системой вы можете обучить кого-то выполнять части исполнения — аудит, исследование, составление документов — пока вы сосредоточены на вводных звонках и передаче результатов. Это начало выхода с конвейера «один к одному» времени в обмен на деньги. ## Инструменты, которые я использую для управления продуктизированными предложениями **[Airtable](/recommends/airtable)** — одна строка на клиентский проект, отслеживание статуса, ссылок на результаты и платежей. Масштабируется от одного до пятидесяти клиентов без сложностей. **[Notion](/recommends/notion)** — руководства по исполнению и клиентские рабочие пространства. Каждый клиент получает общее рабочее пространство Notion, построенное из шаблона, отточенного за счёт повторяющихся передач. **[ConvertKit](/recommends/convertkit)** — управление списком ожидания и последовательности follow-up. Когда предложение заполнено (мощности быстро занимаются при работе с фиксированным объёмом), последовательность списка ожидания поддерживает вовлечённость тёплых лидов до следующего открытия. ## Самые частые ошибки **Продуктизация до достаточного числа передач.** Если вы не выполнили эту работу 3–5 раз, вы ещё не знаете реального объёма. Сначала выполните её как индивидуальную работу. Узнайте, где находятся границы. Затем определяйте продукт. **Расплывчатый объём.** Продуктизированный сервис с неопределённым объёмом — это индивидуальный проект с фиксированной ценой, что является худшим из обоих миров. Определите, что включено, определите, что не включено, закрепите это письменно и разместите на странице продажи. **Согласие на запросы вне объёма.** Когда клиент просит большего, создайте дополнение с собственным объёмом и ценой. Не поглощайте это только в этот раз. **Пропуск системы исполнения.** Вы не закончили после первой передачи. Постройте руководство до продажи второго. Система — это то, что делает продукт. ## FAQ ### С какого количества продуктизированных предложений начать? Одного. Постройте его, передайте, отточите систему, соберите отзывы, затем рассмотрите второе. Большинство людей, запускающих сразу два, в итоге имеют два полупостроенных системы и никаких отзывов ни для одного. ### Нужна ли мне целевая страница перед началом продаж? Нет. Для первых 5–10 продаж достаточно одностраничного PDF или хорошо написанного письма. Не позволяйте созданию сайта быть причиной, по которой вы ещё ничего не продали. ### Что делать, если клиент хочет что-то вне объёма? Скажите, что это отдельный проект. Предложите дополнение прямо на месте или запланируйте звонок для согласования объёма. Не поглощайте это в текущий проект. Дисциплина соблюдения объёма — это то, что заставляет модель работать. ### Как получить первого клиента? Расскажите 10 людям, знающим вашу работу, о предложении — тёплые разговоры с теми, кто вам доверяет или знает кого-то, кому это нужно. Первая продажа почти всегда приходит из прямого разговора, а не с целевой страницы. Как только у вас есть один кейс, [подход к продажам, ведомым основателем](/founder-led-sales-how-to-reach-decision-makers/), начинает его масштабировать. ### Можно ли продуктизировать то, что я делал только один раз? Нет. Вы ещё не понимаете реального объёма. Выполните это ещё два-три раза как индивидуальную работу, затем формализуйте то, что узнали, в продукт. --- **Следующие шаги:** Мой [курс AI Agents for Beginners](/course/) охватывает системы автоматизации, которые делают продуктизированное исполнение масштабируемым. [Программа cowork](/cowork/) для операторов, строящих системно-управляемые бизнесы и желающих делать это в структурированной среде. --- ## Стратегия привлечения лидов через LinkedIn: как я получаю B2B-клиентов без платной рекламы Source: https://alejandrorioja.com/ru/linkedin-lead-generation-strategy/ Published: 2026-07-14 Tags: Marketing, Growth, Entrepreneurship TL;DR: LinkedIn — это бесплатный канал с наибольшим кредитным плечом для генерации B2B-лидов, если вы относитесь к нему как к двигателю доверия, а не как к машине для массового холодного охвата. Оптимизируйте профиль как лендинговую страницу, публикуйте контент последовательно с одного угла своей экспертизы и выстройте короткую последовательность контактов, которая начинается с ценности. Эффект сложного процента ощущается через 60–90 дней, после чего система работает почти сама. Платная реклама необязательна; чёткий профиль и полезный контент-поток — обязательны. ## Содержание _Опубликовано в июле 2026 года._ **TL;DR:** LinkedIn — это бесплатный канал с наибольшим кредитным плечом для генерации B2B-лидов, если вы относитесь к нему как к двигателю доверия, а не как к машине для массового холодного охвата. Оптимизируйте профиль как лендинговую страницу, публикуйте контент последовательно с одного угла своей экспертизы и выстройте короткую последовательность контактов, которая начинается с ценности. Эффект сложного процента ощущается через 60–90 дней, после чего система работает почти сама. Платная реклама необязательна; чёткий профиль и полезный контент-поток — обязательны. **Взгляд оператора:** Я использую LinkedIn для получения консультационных запросов, покупателей курсов и партнёрских разговоров — всё это без единого рекламного поста. То, что работает, — не хак и не инструмент. Это появление в пространстве, которое ваши покупатели уже населяют, как по-настоящему полезный человек. Перед вами точный плейбук, который я использую, и последовательность, которой я бы придерживался, начиная с нуля сегодня. ## Почему LinkedIn в 2026 году Органический охват LinkedIn удерживается лучше, чем на почти любой другой платформе. Пост человека с несколькими сотнями релевантных подписчиков по-прежнему может достичь тысяч целевых специалистов — то, что на большинстве других каналов стоит реальных денег. Алгоритм продолжает вознаграждать контент, насыщенный экспертизой, который генерирует сохранения и репосты, а не просто лайки. Для B2B в частности у LinkedIn нет достоверного конкурента: - Лица, принимающие решения, здесь доступнее, чем на любой другой платформе. - Сигнал намерения профессиональный — люди в «рабочем режиме», а не бездумно скроллят. - Комментарий или публикация создают публичную запись вашего мышления, которую потенциальные клиенты могут найти спустя недели или месяцы. - InMail и запросы на подключение по-прежнему входят в число механизмов охвата с наименьшими затратами на привлечение. Оговорка: та же открытость, которая делает LinkedIn ценным, наполняет его и массовым охватом, и общими публикациями «лидеров мнений», и едва замаскированными питчами. Планка, чтобы выделиться, невысока. Большинство людей её просто не преодолевают. ## Шаг 1: Исправьте профиль, прежде чем что-либо публиковать Ваш профиль в LinkedIn — первое, что читает потенциальный клиент, получив запрос на подключение или наткнувшись на ваш пост. Если он не сообщает немедленно, кому вы помогаете и как, всё остальное, что вы делаете, подрывается. Четыре наиболее значимых места: 1. **Заголовок** — не ваша должность. Рабочая формула: _[Что я делаю] для [кого] чтобы они могли [результат]_. «Помогаю основателям B2B SaaS закрыть первые 10 корпоративных сделок без команды по продажам» — это поисковый, конкретный и моментально самоквалифицирующий заголовок. 2. **Фоновый баннер** — используйте его для усиления того же послания. Чистый визуал с вашей нишей или короткой фразой-доказательством лучше, чем стандартный градиент. 3. **Раздел «О себе»** — пишите от первого лица. Два коротких абзаца: что вы делаете и для кого, затем одна-две точки доказательства (клиенты, результаты, достижения — реальные). Завершите чётким призывом к действию: «Напишите в личные сообщения, если пытаетесь сделать X». 4. **Раздел «Избранное»** — закрепите одно-два: лид-магнит, лучший пост, кейс, ссылку на бронирование. Это ценная площадь, которую большинство людей оставляют пустой. Тест: прочитайте свой профиль как незнакомец. За 10 секунд они могут узнать, что вы делаете, для кого и что делать дальше? Если нет — редактируйте дальше. ## Шаг 2: Публикуйте под одним углом, последовательно Самая распространённая ошибка в LinkedIn — публиковать хаотично: в понедельник маркетинговый совет, в среду мотивационная цитата, в пятницу продуктовый питч. Алгоритм вас игнорирует, и аудитория тоже. Работает выбор одного конкретного угла вашей экспертизы и его присвоение. Публикуйте с этого угла три-четыре раза в неделю на протяжении 90 дней. На ранних этапах объём и последовательность побеждают вдохновение и полировку. ### Контент-микс, создающий сложный эффект | Формат | Используйте для | Почему работает | | --- | --- | --- | | Короткий текстовый пост (3–5 строк) | Нестандартные взгляды, быстрые фреймворки, уроки из недавней работы | Высокий охват, низкий порог потребления, генерирует комментарии | | Пост-список | Пошаговые разборы, сравнения, инструменты | Сохранения и репосты; алгоритм любит | | Пост-история | Конкретная ситуация, с которой я столкнулся, что я сделал, что произошло | Выстраивает доверие быстрее любого другого формата | | Длинная статья | Глубокие руководства, вечнозелёные разборы | Индексируется поиском; позиционирует вас как эксперта со временем | | Карусель (документ) | Визуальные фреймворки, краткие изложения длинных постов | Самый высокий процент сохранений среди всех форматов | Мой микс: 70% короткие посты и списки, 20% истории, 10% длинные форматы или карусели. Длинные посты не дают большого охвата, но накапливаются месяцами в поиске и через личные сообщения. ## Шаг 3: Целенаправленно стройте базу контактов Растить правильную аудиторию в LinkedIn — не то же самое, что растить большую. Тысяча подписчиков, которые являются вашими целевыми покупателями, ценнее десяти тысяч коллег или случайных наблюдателей. Мои критерии таргетинга: - Лица, принимающие решения, в отраслях, которым я служу - Основатели и операторы в компаниях с нужным мне диапазоном выручки - Контакты второй степени от текущих клиентов и соратников (самый тёплый источник) - Люди, взаимодействующие с конкурентами или коллегами в моей нише Я отправляю 15–20 запросов на подключение в день, каждый с однострочной заметкой, объясняющей, почему я подключаюсь. Не питч — просто контекст: «Увидел ваш комментарий про [тему], пересекается с тем, над чем работаю — рад подключиться». Эта заметка поднимает процент принятия с ~30% (общий) до ~55–65% (конкретный). Заметка — максимум два предложения. Не подключайтесь ко всем подряд. Раздутый список контактов из неквалифицированных аккаунтов реально вредит: алгоритм LinkedIn частично распределяет ваши посты по контактам, поэтому аудитория низкого качества подавляет ваш охват. ## Шаг 4: Выстройте последовательность охвата — трёхкасательный подход Когда кто-то подключился, цель — не сразу питчить. Цель — начать разговор, который со временем может привести к встрече. Люди, воспринимающие подключение как разрешение вставить продающую презентацию, отравляют каждую последующую точку контакта. Последовательность, которую я использую: **Касание 1 (день 1, в течение 24 часов после подключения):** Отправьте короткое тёплое приветственное сообщение. Укажите, почему подключились, и поделитесь полезным ресурсом — постом, фреймворком, статьёй — релевантным чему-то, что они публиковали. Без просьбы. Завершите утверждением, а не вопросом. **Касание 2 (дни 5–7):** Искренне поучаствуйте в одном из их постов — не просто лайк, а настоящий вдумчивый комментарий, добавляющий к разговору. Это держит ваше имя на виду в их ленте без отправки ещё одного сообщения. **Касание 3 (дни 14–21):** Напишите в личку с мягкой конкретной просьбой. Чёткий вопрос, на который легко ответить, привязанный к чему-то релевантному, замеченному в их работе. Если момент подходящий и боль реальная — здесь бронируются встречи. Если нет — двигайтесь дальше: аккаунт прогрет, они знают ваше имя. Ошибка, которую я вижу постоянно: пропустить касания 1 и 2 и сразу перейти к призыву к действию в момент подключения. Это не лидогенерация; это налог на репутацию. ## Шаг 5: Переводите разговоры во встречи Хороший разговор в личных сообщениях нуждается в чистом выходе на приглашение в календарь. В момент, когда человек проявляет настоящий интерес, — задаёт уточняющий вопрос, прямо называет свою проблему или реагирует на ваше решение, — это момент для просьбы. Сообщение, которое конвертирует: > «Звучит так, будто [конкретное, что они сказали] для вас реально. Я помогал нескольким компаниям в похожих ситуациях — рад потратить 20 минут на разбор того, как мы подходили к этому, без питча, просто посмотреть, актуально ли. [ссылка на бронирование] — берите слот, если это полезно». Коротко, с низкими обязательствами, легко сказать «да». Ссылка на бронирование устраняет трение с планированием, которое убивает половину встреч, которые должны были состояться. ## Чего не стоит делать Поведение, из-за которого аккаунты игнорируют, жалуются на них или блокируют их: 1. **Массовые запросы на подключение без контекста** — LinkedIn ограничит аккаунт, и процент принятия упадёт. 2. **Личные сообщения с питчем в лоб** — первое сообщение не место для представления вашего продукта, цены или ссылки на календарь. 3. **Поды для взаимного взаимодействия** — фейковое взаимодействие раздувает метрики тщеславия и алгоритмически наказывается. 4. **Публикации каждый день без точки зрения** — объём без перспективы — это шум. Один пост в неделю с реальным инсайтом лучше семи «горячих мнений» в неделю без содержания. 5. **Автоматизация охвата** — обнаружение ботов в LinkedIn стало агрессивным. Автоматизированные инструменты подключения и написанные ИИ последовательности в личных сообщениях в масштабе помечаются. Последовательность из шага 4 занимает около 30 минут в день и имеет соотношение сигнал/шум, которого ни один инструмент не может достичь. ## Измеряйте то, что действительно важно Метрики тщеславия, которые можно игнорировать: показы, просмотры профиля, количество подписчиков. Цифры, которые говорят о том, работает ли система: - **Процент принятия подключений** — цель 50%+ с заметкой; если ниже 30% — переписывайте заметку. - **Процент ответов на сообщения с продолжением** — 20–30% — здорово для хорошо таргетированного списка. - **Входящие личные сообщения в месяц** — люди, обращающиеся к вам из-за вашего контента. Отслеживайте помесячно. - **Забронированные через LinkedIn звонки в месяц** — единственная цифра, коррелирующая с выручкой. Я отслеживаю это в простой таблице Notion. Цель первых 90 дней — достичь одного входящего личного сообщения в неделю и одного забронированного звонка в месяц только через LinkedIn. К третьему месяцу, если контент работает, эти цифры растут без пропорционально больших усилий. ## Итоговый вывод оператора LinkedIn работает для генерации B2B-лидов, потому что это единственная профессиональная сеть, где органический охват ещё имеет вес и где ваша репутация накапливается публично со временем. Механика проста: профиль, объясняющий, кому вы помогаете; контент, доказывающий, что вы знаете, о чём говорите; и последовательность контактов, начинающаяся с ценности, а не с питча. Делайте это последовательно 90 дней — и входящие запросы начнут поступать. Делайте год — и это станет одним из самых надёжных источников квалифицированных разговоров, без рекламного бюджета. --- **По теме:** [Продажи, которые ведёт основатель](/founder-led-sales-how-to-reach-decision-makers/) · [Как выстроить личный бренд](/how-to-build-a-personal-brand/) · [Стратегия охвата](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) --- ## Как я создал Courtlines: SaaS для управления клубами, разработанный вместе с Claude Source: https://alejandrorioja.com/ru/how-i-built-courtlines-a-club-management-saas-with-claude/ Published: 2026-07-11 Tags: AI Agents, Case Study TL;DR: Courtlines — это операционная система для клубов и студий ракеточных видов спорта: бронирование, членство, тренировки, точка продаж и мероприятия под одной фирменной крышей. Я построил её как оператор-одиночка, а Claude был моим инженерным партнёром. Урок: ИИ не просто ускорил моё кодирование — он изменил масштаб продукта, который один человек способен реально выпустить и поддерживать. ## Содержание _Обновлено в июле 2026 года._ **Коротко:** Courtlines — это операционная система для клубов и студий ракеточных видов спорта: бронирование, членство, тренировки, точка продаж и мероприятия под одной фирменной крышей. Я построил её как оператор-одиночка, а Claude был моим инженерным партнёром. Урок: ИИ не просто ускорил моё кодирование — он изменил масштаб продукта, который один человек способен реально выпустить и поддерживать. **[Взгляд оператора]** Я управляю более чем 30 продакшн-агентами в рамках консалтингового бренда и Pickleland — пиклбол-центра, который я веду в агломерации Остина, штат Техас. Управление настоящим объектом показало мне ровно то, насколько плох софт для таких клубов, как мой, — поэтому я построил тот софт, о котором мечтал. Это история [Courtlines](https://courtlines.com), рассказ о том, что она умеет и как опора на Claude позволила одному человеку создать то, что обычно требует целой команды. ## Почему клубу нужна операционная система, а не приложение Если вы никогда не управляли спортивным объектом, проблема с софтом для вас невидима. Со стороны кажется, будто «люди бронируют корты». Изнутри клуб — это маленький хаотичный бизнес с десятком подвижных частей, которые все должны согласовываться друг с другом. Участник бронирует корт. Это бронирование должно знать, есть ли у него абонемент, есть ли у него кредиты, не забронирован ли уже корт под клинику, назначен ли тренер и не переопределил ли цену администратор на ресепшене. Когда он приходит, кто-то пробивает на кассе банку мячей — это точка продаж. Он записывает своего ребёнка в юниорскую программу — это мероприятия и семейные аккаунты. Он покупает абонемент на 10 занятий — это тренировочный пакет со своей логикой выплат тренеру. Он приводит друга — это воронка привлечения участников. Большинство клубов ведут всё это на трёх-четырёх несвязанных инструментах плюс таблице плюс групповом чате. Система бронирования ничего не знает о кассе. Касса ничего не знает о членстве. В конце месяца ни у кого цифры не сходятся. **Courtlines — это ответ на вопрос «а что, если бы всё это было единой системой?»** Это не приложение для бронирования с прикрученными сбоку функциями — это единая операционная система, где календарь, членство, касса, тренерские выплаты и публичные страницы мероприятий — это одни и те же базовые данные. В этом вся суть, и это же слоган на сайте: операционная система для клубов и студий. ## Что Courtlines делает на самом деле На верхнем уровне [Courtlines](https://courtlines.com) даёт клубу: - **Сетку кортов с перетаскиванием** для ресепшена — каждое бронирование, клиника и резерв на одном экране, который администратор может перестраивать в реальном времени. - **Бронирование и открытую игру** для участников, включая неудобные, но обязательные пограничные случаи: повторяющиеся бронирования, листы ожидания, окна отмены и кредиты. - **Членство и биллинг** — тарифы, семейные аккаунты, юниорские/детские логины, привязанные к родителю, и работу с просроченными платежами, которая не даёт выручке тихо утекать. - **Тренировки** — пакеты занятий, расписание и автоматические выплаты независимым тренерам. - **Точку продаж** — настоящую кассу для про-шопа и кафе, привязанную к той же карточке клиента, что и всё остальное. - **Мероприятия и публичные страницы** — клиники, лиги и турниры с публичными страницами, которые люди могут найти и на которые могут записаться. Цель дизайна в том, чтобы платформа исчезала. Клуб ставит поверх свой собственный бренд, и для его участников это ощущается просто как «приложение нашего клуба», а не «какой-то SaaS, за который мы платим». Это осознанный контраст с игроками, уже занимающими эту нишу, — всеми этими CourtReserve и Skedda, — где брендом является софт, а клуб выступает лишь арендатором. Pickleland — арендатор №1. Мне не спрятаться за демо; эта штука должна реально управлять объектом, за который я лично отвечаю. Это ограничение стало лучшим продакт-менеджером, который у меня когда-либо был. Вы можете [посмотреть Pickleland здесь](https://pickleland.com) — это полигон в реальном мире, и каждая шероховатость, на которую натыкается участник, — это баг, который я чувствую в тот же день. ## Что меня удивило: что теперь может выпустить один оператор Вот честная версия истории, и именно она — причина, по которой я пишу этот пост, а не просто тихо запускаю продукт. Мультитенантный SaaS с биллингом, точкой продаж, ролевым доступом, тренерскими выплатами и публичной системой мероприятий — это не проект выходного дня. Десять лет назад это была бы команда из пяти-восьми инженеров с посевным финансированием на год работы. Это тот масштаб задачи, при котором фаундеру-одиночке обычно мягко советуют сузить всё до одной функции и привлечь деньги. Я построил это как один человек, с **Claude в роли моего главного инженерного партнёра.** Не «я иногда просил у ChatGPT сниппет» — я имею в виду, что Claude написал подавляющее большинство кода этой системы, работая по спецификациям и продуктовым решениям, которые принадлежат мне. Моя работа сместилась от *набора реализации* к *решению о том, что истинно*: какой должна быть модель данных, что разрешено делать той или иной роли, что значит «готово» для функции и что безопасно выпускать. Интересен здесь не сдвиг в скорости, хотя работа и правда идёт быстрее. Интересен сдвиг в **масштабе.** ИИ не сделал меня разработчиком «в 2 раза быстрее» на продукте того же размера. Он изменил размер продукта, который я могу достоверно построить и, что не менее важно, *эксплуатировать и поддерживать* в одиночку. Кодовая база, которую написал только один человек, рухнула бы под собственным весом. Кодовая база, где ИИ-партнёр держит в голове детали реализации, а я держу архитектуру и защитные ограждения, — это по-настоящему иная вещь, и именно поэтому оператор-одиночка теперь может замахнуться на категорию, которая раньше требовала компании. Я сознательно не публикую здесь свой точный операционный плейбук по Courtlines — эту часть я считаю конкурентным преимуществом и предпочту, чтобы мои конкуренты и дальше верили, что для этого нужна большая команда. Но если вы хотите увидеть *механику* того, как я гоняю Claude на реальном проекте, во всех деталях, — я расписал всё это для гораздо меньшей сборки: мобильной игры, которую я выпустил в магазины приложений. Смотрите [как я создал Quads, мобильную настольную игру, вместе с Claude](/how-i-built-quads-a-mobile-board-game-with-claude/) — тот же стиль работы, ничего не скрыто, все приёмы на столе. ## Принципы, которыми я не поступлюсь Даже держа плейбук в тайне, стоит проговорить несколько принципов, потому что они применимы к любому, кто строит серьёзный софт с ИИ: **Опасные ручки держит человек.** Есть небольшое число действий, где ошибка обходится дорого и трудно обратима, — изменения схемы, деплои, всё, что касается денег или продакшн-данных. Они жёстко остаются за мной. ИИ может их предложить; исполнять он их не вправе. Именно чёткое проведение этой границы делает безопасным то, что во всём остальном я даю ИИ много свободы. **Зелёные тесты необходимы, но недостаточны.** Флоу бронирования, который проходит каждый юнит-тест, всё равно может быть очевидно сломан в реальном браузере. Самая важная проверка для продукта с интерфейсом — это человек (или контролируемый процесс), который реально прокликивает его на реалистичных данных. Тесты — это градиент, не дающий вещам становиться хуже; они не доказательство того, что функция работает. Этот урок я усвоил дорогой ценой, и он навсегда изменил то, как я определяю «готово». **Спецификации — вот настоящий интерфейс.** Рычаг не в хитром промптинге, а в поддержании ясных, актуальных документов о том, что представляет собой система и что должна делать каждая её часть. Время, потраченное на то, чтобы держать их точными, окупается многократно в каждой будущей сессии. Если хотите более глубокую версию этой мысли — это та же дисциплина, которую я описываю в статье [как писать системные промпты для ИИ-агентов, которые не подводят в продакшене](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/). **Строй то, с чем тебе придётся жить.** Лучшим решением было заставить Courtlines управлять объектом, которым я владею. Легко выпустить впечатляющее демо; невозможно спрятаться от софта, от которого зависят твои собственные участники. Если вы строите с ИИ, направьте его на проблему, которую чувствуете лично, — проверка реальностью стоит больше любого набора тестов. ## Как это вписывается во всё остальное, что я строю Courtlines не существует в изоляции. Это часть небольшой экосистемы ракеточных видов спорта, которую я строю: [The Court Scout](https://thecourtscout.com) — это проверенный каталог пиклбол-кортов, созданный так, чтобы быть по-настоящему точнее спарсенных каталогов, с которыми он конкурирует, а Pickleland — флагманский объект, на котором всё тестируется. Каталог помогает игрокам находить корты; Courtlines помогает клубам, стоящим за этими кортами, реально работать. Связующая ткань всего этого — одна и та же операционная модель: оператор-одиночка, усиленный ИИ, охватывающий больше поверхности, чем оператор-одиночка мог исторически. Courtlines — самое амбициозное воплощение этой модели на сегодня: полноценная SaaS-платформа, за которую ещё несколько лет назад я просто не взялся бы в одиночку. Если вы управляете клубом или студией ракеточного спорта и устали сшивать вместе четыре инструмента, взгляните на [Courtlines](https://courtlines.com). А если вы разработчик, который задаётся вопросом, как далеко можно продвинуть ИИ на реальном продукте, — в этом весь смысл поста: дальше, чем вы, вероятно, думаете. ## Частые вопросы ### Что такое Courtlines? Courtlines — это мультитенантная операционная система для клубов и студий ракеточных видов спорта: пиклбол, теннис, падел и не только. Она объединяет бронирование, членство, тренировки, точку продаж и управление мероприятиями в одну фирменную платформу, так что клуб ведёт весь свой бизнес из единой системы вместо четырёх несвязанных инструментов. Посмотреть можно на [courtlines.com](https://courtlines.com). ### Claude правда написал большую часть кода? Да. Claude был моим главным инженерным партнёром и написал подавляющее большинство реализации, работая по спецификациям, архитектуре и продуктовым решениям, которые принадлежат и подконтрольны мне. За мной — схема, деплои и определение «готово»; за ИИ — детали реализации. Именно это разделение труда делает SaaS такого масштаба, построенный в одиночку, поддерживаемым в долгую. ### Может ли один человек и правда построить и вести настолько крупный SaaS с ИИ? Построить его теперь действительно реально — и это удивительная часть. Более серьёзный вызов — эксплуатировать и поддерживать его, потому что большой кодовой базе нужен тот, кто понимает архитектуру, даже если детали писал ИИ. Ключ — держать ясные спецификации и твёрдо удерживать за человеком то небольшое число высокорисковых действий, которые человек обязан оставить за собой. Если делать так, поддерживаемая поверхность для одного оператора оказывается куда больше, чем раньше. ### Зачем строить собственный клубный софт вместо использования CourtReserve или Skedda? Потому что управление Pickleland показало мне ровно то, где существующие инструменты не дотягивают: система бронирования, касса и членство не разделяют единый источник истины, поэтому ничего не сходится чисто. Мне нужна была система, где всё это — одни и те же базовые данные и где участники видят бренд клуба, а не поставщика софта. Именно этот разрыв Courtlines и призвана закрыть. ### Где можно узнать, как вы на самом деле работаете с Claude изо дня в день? Детальный плейбук по Courtlines я держу в тайне по конкурентным соображениям, но точно тот же стиль работы я задокументировал на меньшем, полностью открытом проекте — мобильной настольной игре под названием Quads. Читайте [как я создал Quads, мобильную настольную игру, вместе с Claude](/how-i-built-quads-a-mobile-board-game-with-claude/), чтобы увидеть механику, или [как я решаю, стоит ли строить автоматизацию](/ai-agent-roi-how-i-decide-whether-automation-worth-building/), чтобы понять логику ROI за всем, что я выпускаю. --- ## Как я создал Quads, мобильную настольную игру, вместе с Claude — от двухчасового хакатона до App Store Source: https://alejandrorioja.com/ru/how-i-built-quads-a-mobile-board-game-with-claude/ Published: 2026-07-11 Tags: AI Agents TL;DR: Quads — мобильная настольная игра, аккуратное прочтение классической абстрактной игры Quarto, — начавшаяся как двухчасовой хакатон с другом в Колумбии и выпущенная в магазины приложений. Это полностью открытая версия того, как я строю с Claude: параллельные worktree-агенты, настоящий (не-LLM) игровой ИИ, offline-first дизайн и конкретные подводные камни, стоившие мне часов. ## Содержание _Обновлено в июле 2026 года._ **Коротко:** Quads — мобильная настольная игра, аккуратное прочтение классической абстрактной игры Quarto, — начавшаяся как двухчасовой хакатон с другом в Колумбии и выпущенная в магазины приложений. Это полностью открытая версия того, как я строю с Claude: параллельные worktree-агенты, настоящий (не-LLM) игровой ИИ, offline-first дизайн и конкретные подводные камни, стоившие мне часов. **[Взгляд оператора]** Я управляю более чем 30 продакшн-агентами в рамках консалтингового бренда и Pickleland — моего пиклбол-центра в агломерации Остина. Большая часть того, что я строю, — это серьёзный бизнес-софт, плейбук по которому я держу в тайне. Quads — противоположность: весёлый сайд-проект, который я могу показать вам от и до. Если хотите увидеть, как именно я работаю с Claude, без единой зачищенной детали, — это тот самый пост. Найти игру можно на [playquads.com](https://playquads.com). ## Всё началось с двухчасового хакатона в Колумбии Происхождение почти неловко-обыденное. Я был в поездке в Колумбию, и мы с другом устроили себе двухчасовой хакатон: выбрать что-нибудь небольшое, построить с ИИ, посмотреть, как далеко продвинемся. Мы остановились на Quarto — красивой маленькой абстрактной стратегии, которую легко освоить и которая удивительно глубока. Два часа спустя у нас был играбельный прототип, и идея была слишком хороша, чтобы оставить её на ноутбуке. То, что начиналось как ограниченный по времени вызов, превратилось в настоящее, выпущенное мобильное приложение на iOS и Android. Именно эта дуга — *шуточный прототип превращается в карточку в магазине* — и есть вся причина, по которой я считаю этот проект достойным рассказа. Расстояние между «весёлой идеей» и «штукой, которую могут скачать незнакомцы» схлопнулось, и Quads — наглядный кейс о том, как именно. Сначала небольшое отступление про название. Игра — это переработка **Quarto**, а это игра с товарным знаком, принадлежащим Gigamic. Так что самым первым некодовым решением было *не* называть её Quarto нигде, где это увидит клиент. Она прошла путь от Quarto (механика) через пару промежуточных названий к **Quads** — названию, которым я вправе пользоваться. Если вы перерабатываете классику, разберитесь с вопросом товарного знака, прежде чем влюбитесь в название. ## Что такое Quads на самом деле Для непосвящённых: в Quads играют на доске 4×4 с 16 уникальными фигурами. У каждой фигуры четыре бинарных атрибута — высокая или низкая, тёмная или светлая, квадратная или круглая, сплошная или полая, — и 16 фигур покрывают каждую возможную комбинацию ровно один раз. Вы побеждаете, завершив линию из четырёх фигур, которые разделяют *любой один* атрибут. Изюминка, которая делает игру блестящей: **вы не выбираете фигуру, которую ставите. Её вручает вам соперник.** Затем вы вручаете фигуру ему. Так что каждый ход — это двойная ловушка: вы пытаетесь поставить доставшуюся вам фигуру, не подготовив победу сопернику, и при этом выбрать для передачи такую фигуру, которая не отдаст сопернику игру. Это изящно и по-настоящему сложно. Приложение поставляется с четырьмя способами игры, все полностью офлайн: против компьютера на пяти уровнях сложности, «передай устройство» на одном устройстве, ежедневная головоломка и асинхронный режим «бросить вызов другу». Ни аккаунта, ни сервера, ни логина. Это решение в пользу offline-first во многом определило инженерию и во многом объясняет, почему сборка в одиночку оказалась посильной. ## Игровая логика: целый свод правил, выпадающий из битовой математики Это моя любимая часть, потому что это та штука, которая приносит удовлетворение независимо от того, писал её ИИ или нет. Каждая из 16 фигур — это просто целое число от 0 до 15. Каждый из четырёх битов — один атрибут. Вот и всё — весь набор фигур это числа 0–15, потому что четыре бита дают ровно 16 комбинаций. Определение победы тогда становится почти тривиальным. Для любой линии из четырёх фигур вы держите два бегущих накопителя: биты, равные `1` у *каждой* фигуры, и биты, равные `0` у *каждой* фигуры. Если после всех четырёх любой из накопителей ненулевой, значит, фигуры совпадают хотя бы по одному атрибуту — это победа. Весь свод правил схлопывается в пару побитовых операций AND. Поскольку логика — это чистые функции над целыми числами (ни фреймворка, ни интерфейса, ни состояния), она напрямую тестируется юнит-тестами и её тривиально расширять. Quads даже поставляется с вариантом по домашним правилам, где девять квадратов 2×2 тоже считаются выигрышными фигурами, — это добавление в две строки поверх того же битового трюка. Когда вы и ИИ-партнёр держите ключевую логику настолько чистой, добавление функции становится радостью, а не риском. ## ИИ-соперник — не LLM (и это правильное решение) Вот обучающий момент, который мне важен: **не всякий «ИИ» должен быть большой языковой моделью.** Соперник в Quads — это чистый классический игровой ИИ, и так и должно быть. Каждый ход он принимает два решения — куда поставить доставшуюся фигуру и какую фигуру вернуть, — а сложность масштабирует, насколько усердно он думает: - **Новичок** играет практически случайно и подарит вам победу. - Средние уровни добавляют эвристики: брать немедленную победу, если она есть, и избегать передачи фигуры, которой соперник может выиграть, предпочитая ту фигуру, что вооружает наименьшее число будущих угроз. - **Мастер и Гроссмейстер** запускают ограниченный поиск negamax — настоящий поиск по дереву игры, — но с жёстким **бюджетом узлов**, чтобы ход никогда не мог подвесить основной поток телефона. В начале игры, где идеальный поиск невыполним, он откатывается к быстрым эвристикам; в конце игры, где дерево достаточно мало, он ищет по-настоящему. Отсюда стоит украсть две вещи. Во-первых, языковая модель была бы здесь *хуже* — медленнее, дороже, недетерминирована и обыгрываема, — чем пятьдесят строк negamax. Подбирайте инструмент под задачу. Во-вторых, настоящая инженерия — это бюджет узлов: на мобильном устройстве «правильно, но иногда подвисает на четыре секунды» — это проваленная функция. Ограничение поиска так, чтобы ход всегда был быстрым, пусть и иногда неоптимальным, — вот разница между игрушкой и продуктом. Понимание, *когда* тянуться за LLM, — то же суждение, что я применяю к каждой автоматизации, и это суть статьи [как я решаю, стоит ли ИИ-сборка того](/ai-agent-roi-how-i-decide-whether-automation-worth-building/). ## Как я на самом деле гоняю Claude: параллельные агенты в worktree Теперь та часть, которую на более крупных продуктах я держу в тайне, но здесь могу показать полностью. Я не строю по одной сессии Claude за раз. Я гоняю **несколько параллельно**, каждую в собственном git worktree на собственной ветке. Один агент добавляет интернационализацию, другой строит систему ежедневных головоломок, третий делает режим для дальтоников, четвёртый подключает звук — каждый изолирован в своей рабочей копии, так что они не могут затереть друг друга, и каждый вливается обратно, когда становится зелёным. История git у Quads — это стена коммитов `Merge branch 'worktree-agent-…'`, что как раз и есть то, как этот воркфлоу выглядит снаружи. Причина, почему worktree важны, проста: параллельные агенты, редактирующие один рабочий каталог, тут же наступают друг другу на ноги. Дайте каждому изолированный checkout — и вы действительно можете держать четыре функции в разработке одновременно, а потом сливать их, как любые другие ветки. Это единственное изменение с наивысшим рычагом в том, как я работаю: я перешёл от «одна беседа, одна функция» к небольшому флоту. Если вам нужна дисциплина, стоящая за промптами, на которых работают эти агенты, — это та же, что я описываю в статье [как писать системные промпты для ИИ-агентов, которые не подводят в продакшене](/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/): рычаг в ясных, актуальных спецификациях, а не в хитрой формулировке. ## Подводный камень, стоивший мне часа (чтобы он не стоил часа вам) Каждый проект учит одному глупому, дорогому уроку. На Quads он был таким: **инструмент предпросмотра не всегда показывает ту ветку, которую вы думаете, что он показывает.** Когда вы гоняете несколько агентов в нескольких worktree и смотрите предпросмотр их работы, предпросмотр может запуститься из *другого* каталога, чем тот, в котором находится ваша текущая сессия, — так что вы делаете скриншот приложения, не видите ни одного из своих изменений и начинаете отлаживать «пропавший» интерфейс, который никуда не пропадал. С функцией всё было в порядке; предпросмотр был нацелен на неверный checkout. Я потерял на этом реальное время, прежде чем понял, что происходит, и записал это в собственные заметки проекта, чтобы будущий я (и любой агент, которому я передам репозиторий) проверял цель предпросмотра *до* отладки фантомных багов. Смежная ловушка: конфигурационный файл, определяющий эти предпросмотры, общий для параллельных сессий, так что два агента, редактирующие его одновременно, могут молча перезаписать записи друг друга. Если собираетесь гонять флот, относитесь к общему конфигу как к оспариваемому ресурсу — он укусит вас ровно один раз, а затем никогда, если вы запишете урок. Эта привычка — фиксировать каждый добытый потом подводный камень в устойчивом файле, который прочитает следующая сессия, — тихий хребет строительства с ИИ на любом масштабе. Контекст испаряется между сессиями; записанные уроки — нет. ## Offline-first приёмы, которыми я горжусь Поскольку у Quads нет бэкенда, нескольким проблемам потребовались хитрые бессерверные ответы: - **Ежедневная головоломка** выбирается детерминированно из локального дня года, так что каждый игрок в мире получает одну и ту же головоломку при нулевой серверной координации. (Бонусный урок: я выпустил и тут же исправил ошибку на единицу из-за перехода на летнее время в этой арифметике дат. Даты всегда сложнее, чем кажутся.) - **«Бросить вызов другу»** кодирует головоломку в короткий текстовый код — что-то вроде `QC1-01-03-3`, — защищённый контрольной суммой, чтобы опечатка не могла породить валидный-но-неверный вызов. Ваш друг вводит его в собственную копию приложения и играет ровно ту же позицию, полностью офлайн. Ни аккаунтов, ни подбора соперников, ни сервера. - **Богатые превью ссылок** — единственное место, где я всё же использовал чуть-чуть серверного кода. Когда вы делитесь ссылкой на вызов, одна Cloudflare Pages Function рендерит теги Open Graph под конкретный код, чтобы ссылка красиво разворачивалась в iMessage или WhatsApp. Социальные краулеры не выполняют JavaScript, так что превью, отрендеренное на клиенте, выглядело бы одинаково для каждой ссылки, — одна маленькая функция чинит это без нужды в настоящем бэкенде. Ничего из этого не сложно, стоит только увидеть, но каждое — то место, где ленивый ответ звучит как «поднять сервер и базу данных», а ответ получше — «сделать хитрую офлайновую штуку». Полный отказ от бэкенда — вот почему один человек смог выпустить и поддерживать это. ## От хакатона до карточки в магазине Последний отрезок — та часть, о которой никто не рассказывает вам про «двухчасовой проект», — это всё, что между «работает на моём телефоне» и «незнакомцы могут это скачать». Интернационализация на восемь языков за один заход. Тексты для магазина, которые нигде не используют товарный знак. Инструментарий для сборки под магазины, версионирование и платформенные зачистки разрешений, которые не дают ревью в магазине отфутболить вас. Это негламурно, и именно здесь тихо умирает множество сайд-проектов. Делать это с Claude не сделало чек-лист короче, но сделало каждый пункт достаточно дешёвым, чтобы я реально дошёл до конца. В этом настоящая история Quads: не в том, что ИИ написал настольную игру — прототип такой может сделать множество людей, — а в том, что он снизил стоимость *последней мили* достаточно, чтобы хакатонная шутка стала выпущенным продуктом. Если у вас есть маленькая идея, на которой вы сидите, — в этом весь мой посыл. Начните двухчасовую версию. Вы удивитесь, насколько ближе сдвинулась финишная черта. А если хотите увидеть, как высоко по масштабу заходит тот же стиль работы, — я довёл его до полноценного мультитенантного SaaS: [как я создал Courtlines, платформу для управления клубами, вместе с Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). Играйте в Quads на [playquads.com](https://playquads.com). ## Частые вопросы ### Что такое Quads? Quads — мобильная настольная игра для iOS и Android, аккуратная переработка классической абстрактной стратегии Quarto. Вы играете на доске 4×4 с 16 уникальными фигурами, а изюминка в том, что фигуру, которую вам нужно поставить, выбирает соперник. Игра бесплатна, с режимами для одиночной игры, «передай устройство», ежедневной головоломки и асинхронных вызовов. Найти её можно на [playquads.com](https://playquads.com). ### Claude написал всю игру? Claude написал подавляющее большинство кода, работая по дизайну и решениям, которые принадлежат мне. Я гонял несколько сессий Claude параллельно, каждую в собственном git worktree, строя разные функции, которые я сливал вместе. Игровая логика, ИИ-соперник, интернационализация, звуки и система головоломок были во многом построены так и отревьюены мной. ### Внутриигровой ИИ-соперник работает на LLM? Нет — и это сделано намеренно. Соперник использует классический игровой ИИ: эвристики на низких уровнях сложности и ограниченный поиск negamax на верхних уровнях, с жёстким бюджетом узлов, чтобы ход никогда не подвешивал устройство. Языковая модель была бы медленнее, дороже и слабее для этой задачи. Выбор правильного вида ИИ под задачу важнее, чем вечное стремление тянуться за самой большой моделью. ### Сколько времени заняла разработка Quads? Первый играбельный прототип вышел из двухчасового хакатона с другом в поездке в Колумбию. Превращение этого прототипа в отполированное, готовое к выпуску приложение в обоих магазинах — с интернационализацией, настоящим ИИ-соперником, офлайн-вызовами и соответствием требованиям магазинов — заняло существенно больше, но каждый отдельный шаг был с ИИ достаточно дешёвым, чтобы проект реально дошёл до финишной черты. ### Какой самый главный урок из создания Quads с Claude? Два. Во-первых, гоняйте агентов в изолированных git worktree, чтобы строить несколько функций параллельно, не давая им затирать друг друга. Во-вторых, записывайте каждый подводный камень в устойчивый файл, который прочитает следующая сессия, — контекст испаряется между сессиями, а записанные уроки накапливаются. Для более широкой картины этого стиля работы смотрите [как я создал Courtlines вместе с Claude](/how-i-built-courtlines-a-club-management-saas-with-claude/). --- ## Как писать системные промпты для ИИ-агентов, которые не ломаются в продакшене Source: https://alejandrorioja.com/ru/how-to-write-ai-agent-system-prompts-that-dont-fail-in-production/ Published: 2026-07-11 Tags: AI Agents TL;DR: Продакшн-системный промпт имеет пять уровней: идентичность (кто агент и что он не может делать), контекст (что он знает об окружении), задача (как выглядит успех пошагово), формат вывода (самый недооценённый уровень) и пограничные случаи (что делать при проблемных входных данных). Большинство промптов ломается, потому что пропускают уровни 4 и 5. Пишите формат вывода первым — это заставляет вас быть точными в том, что вы действительно хотите. ## Содержание _Обновлено июль 2026._ **TL;DR:** Продакшн-системный промпт имеет пять уровней: идентичность (кто агент и что он не может делать), контекст (что он знает об окружении), задача (как выглядит успех пошагово), формат вывода (самый недооценённый уровень) и пограничные случаи (что делать при проблемных входных данных). Большинство промптов ломается, потому что пропускают уровни 4 и 5. Пишите формат вывода первым — это заставляет вас быть точными в том, что вы действительно хотите. **[Взгляд оператора]** Я управляю более чем 30 ИИ-агентами в продакшене для своего консалтингового бренда и Pickleland — площадки для пиклбола в Пфлюгервиле, Техас. Я переписал больше системных промптов, чем написал — обычно потому, что первая версия хорошо работала на тестах, а потом тихо деградировала в продакшене. Вот что я узнал о написании промптов, которые держатся. ## Проблема системных промптов, о которой никто не говорит Большинство системных промптов для агентов пишутся примерно за 20 минут, тестируются на двух-трёх примерах и больше никогда не трогаются. Модель выходит в прод. Некоторое время всё работает. Потом что-то меняется — входные данные становятся грязнее, модель обновляется, появляется новый пограничный случай — и агент начинает выдавать мусор. Тихо. В масштабе. Проблема не в том, что изначальный промпт был плохим. Проблема в том, что большинство промптов написаны для демонстрации счастливого пути. Они спроектированы под входные данные, которые вы представляли при создании агента, а не под полное распределение входных данных, которые агент увидит в реальности. ## Пять уровней продакшн-системного промпта Я думаю о каждом системном промпте, который пишу, в пяти уровнях. Им не обязательно появляться в таком порядке — но все они должны присутствовать. ### Уровень 1: Идентичность Идентичность говорит модели, кто она такая и каковы её операционные ограничения. Не персонаж ролевой игры — функциональное определение того, что этот агент делает и не делает. Сильный уровень идентичности отвечает на три вопроса: - За что отвечает этот агент? - За что он явно НЕ отвечает (и должен эскалировать или отказывать)? - Какие стандарты он соблюдает? Явный ограниченный охват — это часть, которую большинство операторов пропускают. Без неё модель будет пытаться быть полезной за пределами своей области — и именно здесь всё идёт не так. ### Уровень 2: Контекст Контекст — это то, что агент знает о своём окружении, чего нет в сообщении пользователя. Сюда входят текущие дата и время (вводить динамически — никогда не доверяйте внутреннему ощущению времени модели), актуальное состояние внешних систем и бизнес-правила, которые не очевидны из описания задачи. Большинство агентов, которые я просматриваю, бедны контекстом. Не предполагайте. Вводите. ### Уровень 3: Задача Уровень задачи описывает, что агент делает шаг за шагом. Не «помогать клиентам» — реальный поток принятия решений. Пишите его как блок-схему, а не как директиву. Блок-схемы более устойчивы, потому что уменьшают потребность модели в выведении того, что вы хотите, в неоднозначных случаях. ### Уровень 4: Формат вывода Это самый недооценённый уровень, и тот, что больше всего отвечает за тихие сбои. Если вы не укажете формат вывода точно, модель будет производить вывод, который выглядит правильным для человека-читателя, но достаточно непоследователен, чтобы сломать нижестоящий парсинг. Пишите формат вывода первым. Для структурированного вывода укажите точную схему. Для прозаического вывода укажите структуру, длину и ограничения тона. Для высокорисковых агентов я использую структурированный вывод [Claude](/recommends/claude) с определённой JSON-схемой. ### Уровень 5: Пограничные случаи Уровень пограничных случаев отвечает: что делает агент, когда входные данные неоднозначны, неполны, на неправильном языке, враждебны или явно неверны? Для каждого пограничного случая дайте модели явный путь ответа. ## Как я поддерживаю системные промпты со временем Продакшн-системный промпт — это живой документ: 1. **Еженедельная точечная проверка.** Я проверяю от пяти до десяти случайных выводов каждого высокорискового агента. 2. **Обзор после обновления модели.** Каждый раз, когда меняется версия базовой модели, я запускаю агента против полного золотого набора из моего [фреймворка оценки](/how-i-measure-whether-an-ai-agent-is-actually-working/). 3. **Журнал пограничных случаев.** Я веду журнал входных данных, с которыми агент справился плохо. Когда три или более записи разделяют паттерн, я добавляю явное правило. 4. **Версионирование промпта.** Каждое значимое изменение получает версионный комментарий. ## Часто задаваемые вопросы ### Насколько длинным должен быть продакшн-системный промпт? Достаточно длинным, чтобы охватить все пять уровней. Достаточно коротким, чтобы прочитать его за две минуты и обнаружить отклонение. Для большинства моих агентов это 200-600 слов. ### Когда мне следует разбить сложную задачу на несколько агентов вместо одного длинного промпта? Когда у задачи есть два или более различных режима, требующих разного контекста, разных форматов вывода или разной обработки ошибок. Смотрите [агенты на основе событий против запланированных](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) для паттерна. ### Какова наиболее распространённая причина, по которой промпт, работавший на тестах, ломается в продакшене? Тестовые входные данные не были репрезентативными для производственного распределения. Создавайте тестовый набор из реального продакшн-трафика, а не из воображаемых входных данных. --- ## ROI ИИ-агентов: Как Я Решаю, Стоит ли Строить Автоматизацию Source: https://alejandrorioja.com/ru/ai-agent-roi-how-i-decide-whether-automation-worth-building/ Published: 2026-07-09 Tags: AI Agents, Operations TL;DR: Прежде чем создавать любой ИИ-агент, я провожу четырёхэтапную проверку ROI: количественная оценка ручных затрат, оценка стоимости разработки, прогноз операционных расходов и учёт стоимости обслуживания. Результат — срок окупаемости. Если он превышает шесть месяцев для нестратегической задачи, я отказываюсь от идеи. Большинство идей агентов не проходят этот тест — и в этом весь смысл. ## Содержание _Обновлено июль 2026._ **TL;DR:** Прежде чем создавать любой ИИ-агент, я провожу четырёхэтапную проверку ROI: количественная оценка ручных затрат, оценка стоимости разработки, прогноз операционных расходов и учёт стоимости обслуживания. Результат — срок окупаемости. Если он превышает шесть месяцев для нестратегической задачи, я отказываюсь. Построить неправильную автоматизацию хуже, чем не строить ничего. **[Взгляд оператора]** Я управляю более чем 30 ИИ-агентами в продакшне — для консалтингового бренда и Pickleland, центра пиклбола во Флориде. Я отказался как минимум от стольких же агентов, сколько запустил. Отвергнутые не были плохими идеями — они были хорошими идеями, которые не прошли математическую проверку. ## Вопрос, который никто не задаёт первым В 2026 году все спрашивают: «Как автоматизировать это?» Лучший вопрос: «Стоит ли это автоматизировать, и когда это окупится?» ИИ-агент не бесплатен. Его создание требует времени, эксплуатация — денег, поддержка — постоянного внимания. Если автоматизация не возмещает эти затраты быстрее, чем ручной вариант, вы сделали операцию сложнее и дороже — не эффективнее. ## Шаг 1: Количественная оценка ручных затрат Первая цифра — сколько текущий процесс стоит в год. ``` ручные_затраты_в_год = (время_на_задачу × часовая_ставка × частота_в_год) + стоимость_ошибок_в_год ``` **Время на задачу** — это реальное рабочее время, а не календарное от начала до конца. **Часовая ставка** — полные затраты на человека, выполняющего работу. Если это ваше время — используйте целевую консультационную или альтернативную ставку, но не ноль. **Частота в год** — сколько раз эта задача реально выполняется. **Стоимость ошибок** — то, что большинство забывает. Реальный пример из Pickleland: ручная отправка промоакций мероприятий в Facebook занимала 45 минут в неделю. По моей альтернативной ставке это $45/неделя или $2340/год. Это исходная точка. ## Шаг 2: Честная оценка стоимости разработки Стоимость разработки почти всегда недооценивается. ``` стоимость_разработки = (часы_разработки × часовая_ставка) + настройка_инструментов + часы_тестирования × часовая_ставка + отладка_интеграций × часовая_ставка ``` Для промоутера мероприятий Pickleland: 6 часов на разработку, 3 часа на тестирование, 2 часа на отладку интеграций. По моей ставке это $990. ## Шаг 3: Прогноз операционных расходов ``` операционные_расходы_в_год = (вызовы_api_в_год × стоимость_вызова) + инфраструктура_в_год + часы_проверки_человеком × часовая_ставка ``` **API-вызовы** — вызовы Claude/LLM плюс сторонние API. **Инфраструктура** на Cloudflare Workers + Queues обычно менее $5/месяц при умеренном объёме. **Ручная проверка** — затраты, которые чаще всего забывают. Для промоутера Pickleland: ~1000 вызовов API Claude/год. Ручная проверка — ~$800/год. Итого: ~$810/год. ## Шаг 4: Налог на обслуживание Это наиболее недооцениваемый фактор в каждом расчёте ROI агента. Агенты ломаются. Я применяю фиксированную ставку 20% от стоимости разработки в год как налог на обслуживание. ``` стоимость_обслуживания_в_год = стоимость_разработки × ставка_обслуживания ``` Для промоутера Pickleland: $990 × 20% = $198/год. ## Формула окупаемости ``` чистая_годовая_экономия = ручные_затраты_в_год − операционные_расходы_в_год − стоимость_обслуживания_в_год месяцев_окупаемости = (стоимость_разработки ÷ чистая_годовая_экономия) × 12 ``` Для промоутера мероприятий Pickleland: - Ручные затраты: $2340/год - Операционные расходы: $810/год - Обслуживание: $198/год - Чистая годовая экономия: $1332/год - Стоимость разработки: $990 - **Окупаемость: 8,9 месяца** Это пограничное значение. Мой порог для нестратегических автоматизаций — шесть месяцев. ## Мои пороги окупаемости - **Менее 3 месяцев:** Строить немедленно. Такие случаи редки. - **3–6 месяцев:** Однозначно да. Это автоматизации, которые накапливаются. - **6–12 месяцев:** Строить, если стратегически важно. Иначе отказываться. - **Более 12 месяцев:** Почти всегда отказываться. ## Когда НЕ автоматизировать Самая дорогостоящая ошибка — автоматизация нестабильных процессов. Если процесс меняется каждые несколько недель, автоматизация фиксирует текущую сломанную версию. Перед автоматизацией спросите: этот процесс был стабильным хотя бы три месяца? Вторая ошибка — автоматизация редких задач с высокими ставками. Третья: не автоматизируйте, чтобы избежать разговора. ## Стек агентов для этих автоматизаций Большинство автоматизаций в продакшне работают на Cloudflare Workers + Queues с [Claude](/recommends/claude) в качестве LLM. ## Часто задаваемые вопросы ### Какую часовую ставку использовать для своего времени? Используйте альтернативную стоимость — что вы заработали бы, тратя это время на что-то другое. Не используйте ноль. ### Как оценить затраты на Claude API до разработки? Используйте эндпоинт подсчёта токенов Claude с репрезентативной выборкой реальных входных данных. ### Что считается "стратегической" автоматизацией? Стратегическая автоматизация (1) напрямую обслуживает клиентов так, что влияет на удержание или конверсию, (2) обеспечивает масштаб, недостижимый вручную, или (3) производит данные для лучших решений. ### Нужно ли считать время на мониторинг агента? Да. Время мониторинга — реальные текущие затраты. ### Что если задача — это то, что я просто ненавижу делать? Ненависть к задаче имеет реальную стоимость. Я принимаю более долгий срок окупаемости для задач, которые искренне ненавижу, но это не чистый чек. --- ## Продажи силами основателя: как найти нужного покупателя и выйти на него до того, как вы построите отдел продаж Source: https://alejandrorioja.com/ru/founder-led-sales-how-to-reach-decision-makers/ Published: 2026-07-09 Tags: Entrepreneurship, Growth, Marketing TL;DR: Прежде чем нанимать отдел продаж, вы должны доказать, что умеете продавать. Продажи силами основателя сводятся к трём вещам: определить единственного человека, который реально может сказать «да», собрать достаточно информации, чтобы заслужить ответ, и выстроить последовательность каналов — письмо для просьбы, звонок для срочного дожима, LinkedIn для тёплого знакомства. Большинство сделок буксует не потому, что питч был слабым, а потому, что он попал не в тот почтовый ящик. Обойдите это — и вы назначите встречи, которые не смог бы назначить оплачиваемый менеджер. ## Содержание _Опубликовано в июле 2026 года._ **Коротко:** Прежде чем нанимать отдел продаж, вы должны доказать, что умеете продавать. Продажи силами основателя сводятся к трём вещам: определить единственного человека, который реально может сказать «да», собрать достаточно информации, чтобы заслужить ответ, и выстроить последовательность каналов — письмо для просьбы, звонок для срочного дожима, LinkedIn для тёплого знакомства. Большинство сделок буксует не потому, что питч был слабым, а потому, что он попал не в тот почтовый ящик. Обойдите это — и вы назначите встречи, которые не смог бы назначить оплачиваемый менеджер. **[Взгляд оператора]** Каждый основатель, на глазах у которого я видел, как строится настоящая компания, первые сделки закрывал сам — сначала обычно плохо, потом хорошо. Обойти это никак нельзя. Вы не можете передать другому механику продаж, которую сами ни разу не запускали, потому что пока не знаете, на что именно реагирует ваш покупатель. Вот процесс, которым пользуюсь я и которому учу основателей: как найти нужного человека, собрать ровно столько информации, чтобы заслужить ответ, и выйти на него без рассылки незнакомцам и без покупки парсера. ## Почему основатели обязаны продавать первыми Нельзя делегировать механику, которую вы ни разу не запускали. Если вы наймёте продавца до того, как сами закроете хотя бы несколько сделок, вы не масштабируете процесс — вы отдаёте на аутсорс сам поиск этого процесса и платите зарплату за то, чему должны были научиться бесплатно. Продажи силами основателя — это не стадия, которую терпишь, пока не сможешь позволить себе менеджера. Это то, как вы узнаёте точные слова, которыми пользуется ваш покупатель, возражение, которое убивает девять сделок из десяти, и ту самую фразу, от которой человек подаётся вперёд. Это знание позже становится скриптом, плейбуком и планкой для найма. Пропустите его — и ваш первый продавец унаследует догадку. Хорошая новость: как у основателя у вас есть нечестное преимущество, которого у менеджера не будет никогда. Вы сами построили продукт. Вы можете ответить на любой вопрос, прогнуть дорожную карту прямо на звонке и говорить с убедительностью, которую не подделает ни один незнакомец с планом продаж. Ваша задача — достаточно часто оказываться перед нужным человеком, чтобы это преимущество имело значение. ## Шаг 1: Определите единственного человека, который может сказать «да» Самая частая причина провала обращений — они доходят до не той роли. Ваше сообщение не отклоняют — его получает тот, кто изначально не имел полномочий по нему действовать, и оно тихо умирает. В большинстве компаний между вами и сделкой стоят три типа людей: - **Чемпион** — чувствует ту боль, которую решает ваш продукт, и хочет её устранить. Часто не занимает высокую должность, но именно он будет продвигать ваше дело внутри компании. - **Экономический покупатель** — распоряжается бюджетом и может утвердить расходы. Именно он в итоге говорит «да». - **Блокер / привратник** — закупки, помощник руководителя, ИТ или скептически настроенный заместитель, чья работа — отфильтровывать шум. Не ваш враг, но и не ваша цель. Прежде чем связываться с кем-либо, решите, на кого из них вы нацелены и почему. Для первой встречи обычно нужен чемпион или экономический покупатель — а не случайный сотрудник, чьё имя вы нашли просто потому, что его было легко найти. Выход на не того человека не только тратит впустую сообщение — он может сжечь весь аккаунт, потому что теперь ваше имя связано с плохо нацеленным холодным питчем. Если вы не можете сформулировать, почему именно этот человек — правильный контакт, значит, вы ещё не готовы к обращению. ## Шаг 2: Соберите достаточно информации, чтобы заслужить ответ Исследование контакта — это не «найти адрес электронной почты». Это сбор достаточного контекста, чтобы ваше сообщение могло быть написано только этому единственному человеку. Именно это заслуживает ответа в почтовом ящике, куда приходит по пятьдесят питчей в неделю. Прежде чем что-либо писать, узнайте: 1. **Триггер** — почему именно сейчас? Раунд финансирования, найм на профильную должность, запуск продукта, публичная жалоба, вакансия, которая обнажает пробел. Причина, по которой время имеет смысл именно для *них*. 2. **Конкретную боль** — не «компании вроде вашей мучаются с X», а свидетельство того, что *эта* компания мучается. 3. **Соединительную ткань** — общий знакомый, клиент в их нише, что-то, что вы заметили и что не подделал бы шаблон. Публичные источники дают вам большую часть этого без всяких специальных инструментов: собственный сайт компании и страница вакансий, LinkedIn, свежие публикации в прессе, выступления в подкастах, звонки с инвесторами для публичных компаний и сообщества, где ваш покупатель реально проводит время. Если вы правильно провалидировали рынок, часть этой работы вы уже сделали — см. [Как проверить бизнес-идею до того, как её строить](/how-to-validate-a-business-idea/), где то же исследование спроса и конкурентов работает и как сейлз-разведка. Проверка того, достаточно ли вы сделали: могли бы вы написать первые два предложения сообщения так, чтобы они *не имели смысла*, будучи отправленными любой другой компании? Если да — вы готовы. Если ваше вступление подошло бы сотне компаний, продолжайте исследовать. ## Шаг 3: Выстройте последовательность каналов — письмо, звонок, LinkedIn Единственно лучшего канала не существует. Есть лучший канал для каждого момента. Ошибка — выбрать один и долбить в него. Мастерство — выстроить их так, чтобы каждый делал ту работу, в которой он действительно хорош. | Канал | Лучший сценарий использования | Риск при плохом использовании | | --- | --- | --- | | Письмо | Основная просьба, подробный дожим, всё, что покупателю нужно переслать внутри компании | Игнорируется мгновенно, если читается как шаблон | | Телефон | Срочный дожим, назначение встречи по сделке, которая забронирована, но уплывает, тёплая рекомендация, по которой вам сказали позвонить | Ощущается навязчивым без предыдущего контекста или причины | | LinkedIn | Мягкое первое касание, прогрев холодного контакта, поддержание видимости между письмами | Тесно, медленно, легко выглядеть как любой другой питч | | Тёплое знакомство | Что угодно, когда его можно получить | На кону репутация того, кто вас представляет — не растрачивайте её | Последовательность, которая работает на практике: начните с короткого, конкретного письма, привязанного к найденному вами триггеру. Если ответа нет — добавьте ценности в LinkedIn: искренний комментарий, полезный ресурс, запрос на добавление в контакты с контекстом — чтобы ваше имя не было холодной неожиданностью. Переходите к телефонному звонку только тогда, когда есть реальная причина: дедлайн, рекомендация, сделка, которая затихла после проявленного интереса. Звонок из ниоткуда человеку, который никогда не слышал вашего имени, — самый быстрый способ угодить в папку «спам». И всегда предпочитайте тёплое знакомство, когда можете его заслужить. Одно представление от того, кому покупатель доверяет, превосходит двадцать безупречно составленных холодных писем. Потратьте реальные усилия на то, чтобы понять, кто в вашей сети может открыть какую дверь, прежде чем идти вхолодную. ## Шаг 4: Напишите сообщение, на которое отвечают Как только вы заслужили право обратиться, держите сообщение коротким и сделайте так, чтобы сказать «да» было легко. Длинные питчи от незнакомцев не читают — их архивируют. Хорошее холодное письмо делает четыре вещи меньше чем в 90 словах: 1. **Называет триггер** — доказывает, что вы внимательны и это не веерная рассылка. 2. **Обозначает релевантную боль** — одним предложением, поданным как их, а не ваша. 3. **Содержит одну маленькую просьбу** — 15-минутный звонок, а не «давайте изучим возможности партнёрства». 4. **Даёт лёгкий выход** — «Если это не к вам, не подскажете, кто за это отвечает?» Вот форма: > «Здравствуйте, Priya — увидел, что вы только что открыли две вакансии в команду RevOps, а это обычно значит, что с отчётностью становится тяжело быстрее, чем найм успевает это исправить. Мы помогаем командам на стадии Series B сокращать время на ручную отчётность примерно на 60%, не выдирая при этом их стек. Стоит ли 15 минут на следующей неделе, чтобы понять, актуально ли это? А если это не ваша зона ответственности, буду благодарен за подсказку, кто за это отвечает.» Это конкретно, уважительно к их времени и тривиально легко для ответа — даже «нет» полезно, потому что оно направляет вас к нужному человеку. Та же дисциплина работает во всех каналах; если вам нужна более глубокая механика обращений на масштабе без попадания в спам и игнора, я разобрал это в материале [Как выстроить успешную стратегию обращений](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/). ## Шаг 5: Готовьтесь так, будто эта встреча — единственная, что у вас будет Доступ даёт вам возможность начать. Подготовка зарабатывает следующий шаг. Основатели неделями бьются за встречу, а потом приходят, не продумав мир покупателя — и сделка гибнет не от нехватки интереса, а от нехватки готовности. Перед любым звонком будьте готовы ответить, без запинки: - Как выглядит день этого человека и где в него встраивается мой продукт? - Какой единственный результат ему важен и на который я могу повлиять? - Какие два возражения он выдвинет и каков мой честный ответ? - Какой самый маленький следующий шаг я могу попросить, если ему интересно, но он ещё не готов? Вы сами построили продукт, так что демо — это легко. Трудное — держать в голове приоритеты покупателя, а не свои. Основатели, превращающие обращения в выручку, — это те, кто приходит и звучит так, будто уже понимает бизнес, потому что они сделали работу на Шаге 2. ## Когда не стоит обращаться Агрессивные обращения сжигают больше воронки, чем строят. Пропустите холодное касание — или притормозите, — когда: - Вы не можете назвать, почему именно этот человек — правильный контакт. - Вы уже написали более двух раз без ответа. (Двигайтесь дальше; рынок большой.) - Ваше вступление подошло бы сотне других компаний. - Вы бы звонили вне обычного рабочего времени или без какого-либо предыдущего контекста. - Единственная причина, по которой вы выбрали этого человека, — его контакты было легко найти. Хорошее обращение ощущается как своевременная, релевантная записка от того, кто сделал домашнюю работу. Плохое обращение ощущается как спам с более точным таргетингом. Разница целиком в исследовании и в сдержанности. ## Стек для продаж силами основателя Инструменты и привычки, на которые я опираюсь для этого, и ни один из которых не требует отдела продаж: - **Исследование:** собственный сайт компании и страница вакансий, LinkedIn, свежая пресса и сообщества, где ваши покупатели реально разговаривают - **CRM:** всё, что вы действительно будете обновлять — простая доска в Notion или Airtable лучше корпоративной CRM, которую вы игнорируете - **Последовательность:** лёгкий трекер того, кто на какой стадии и каким будет следующее касание, чтобы ничего не уплывало - **Почта:** реальный, прогретый адрес отправки и письма в чистом тексте — без картинок, без пикселей отслеживания, ничего, что кричит «кампания» - **Календарь:** ссылка для записи, чтобы «да» превращалось во встречу в один клик, а не в пять ответных писем ## Итог от оператора Вам не нужен отдел продаж, чтобы начать продавать. Вам нужно точно знать, кто может сказать «да», собрать достаточно информации, чтобы ваше сообщение могло быть написано только ему, и выстроить каналы так, чтобы каждый делал свою работу. Письмо несёт просьбу, LinkedIn прогревает почву, телефон закрывает срочный разрыв, а тёплое знакомство бьёт их все. Делайте подходы сами достаточно долго, чтобы понять, что реально срабатывает, — и тогда, и только тогда, передайте этот с трудом заработанный плейбук вашему первому сотруднику. --- **Похожее:** [Как выстроить успешную стратегию обращений](/crafting-a-successful-outreach-strategy-in-the-world-of-digital-marketing/) · [Как проверить бизнес-идею](/how-to-validate-a-business-idea/) · [Руководство по стратегиям growth-маркетинга](/growth-marketing-strategies-guide/) --- ## Как построить бизнес солопренёра: руководство 2026 Source: https://alejandrorioja.com/ru/how-to-build-a-solopreneur-business/ Published: 2026-07-07 Tags: Entrepreneurship, Growth TL;DR: Выберите одну бизнес-модель (контент, услуги, SaaS или цифровые продукты), создайте аудиторию вокруг конкретной ниши, а затем добавляйте вторичные источники дохода только после того, как основная модель начнёт приносить конверсии. Ловушка — начинать все четыре одновременно: выбирайте модель, соответствующую вашим уже имеющимся знаниям, а не ту, которая звучит наиболее пассивно. ## Оглавление _Обновлено июль 2026._ **TL;DR:** Выберите одну бизнес-модель (контент, услуги, SaaS или цифровые продукты), создайте аудиторию вокруг конкретной ниши, а затем добавляйте вторичные источники дохода только после того, как основная модель начнёт приносить конверсии. Ловушка — начинать все четыре одновременно: выбирайте модель, соответствующую вашим уже имеющимся знаниям, а не ту, которая звучит наиболее пассивно. **[Взгляд оператора]** Я веду этот сайт, продаю курсы и управляю партнёрскими доходами годами без штатных сотрудников. Ничего из этого не началось с грандиозного плана — всё началось с одной вещи, которая работала, а затем последовало намеренное расширение. Это руководство — то, что я хотел бы прочитать, прежде чем пытаться делать всё сразу. ## Что такое бизнес солопренёра на самом деле Солопренёр ведёт бизнес в одиночку — без со-основателей, без сотрудников, возможно с подрядчиками, когда объём этого требует. Цель — бизнес, работающий на экспертизе и системах, а не на численности персонала. Это отличается от фриланса. Фрилансер продаёт время. Солопренёр строит системы, которые генерируют доход, не требуя его времени за каждый заработанный рубль. ## 4 бизнес-модели солопренёра Каждый бизнес одного человека примерно вписывается в одну из них: 1. **Контент-бизнес.** Вы публикуете (блог, рассылка, YouTube, подкаст) и монетизируете через рекламу, партнёрский доход, спонсорство и собственные продукты. Самый низкий барьер, самый длинный разгон. 2. **Сервисный бизнес.** Вы поставляете конкретный результат клиентам — консалтинг, дробные роли, done-for-you услуги. Самый быстрый путь к $10K/месяц, наименее масштабируемый. 3. **Цифровые продукты.** Курсы, шаблоны, электронные книги, инструменты. Высокий рычаг после создания, сложно привлекать трафик без существующей аудитории. 4. **Микро-SaaS.** Небольшой программный продукт, решающий одну конкретную проблему. Самый высокий потолок, самая высокая техническая планка. Правильная модель зависит от того, что у вас уже есть: навыки, аудитория или капитал. ## Шаг 1: Выберите нишу с настоящей глубиной Широкие ниши (маркетинг, финансы, здоровье) имеют трафик, но жестокую конкуренцию. Узкие ниши (инструменты ИИ для основателей e-commerce, личные финансы для новых медсестёр) конвертируют лучше и ранжируются быстрее. Тест, который я использую: могу ли я написать 50 действительно полезных материалов на эту тему, не исчерпав идеи? Если да, у ниши есть глубина. Если мне сложно назвать 20, она слишком узкая или я знаю её недостаточно хорошо. Ваша ниша должна находиться на пересечении: - Того, что вы знаете из опыта, а не только из исследований - Аудитории с деньгами или временем для расходов - Проблемы, которая повторяется, а не разовой задачи ## Шаг 2: Создайте аудиторию до того, как она понадобится Самая большая ошибка, которую я вижу: запуск продукта для аудитории из нуля. Аудитория раньше продукта — таково правило. Вот что действительно работает: 1. **Выберите один канал распространения и углубитесь в него.** Блог + SEO медленный, но устойчивый. Рассылка монетизируется быстро. Короткое видео имеет высокий потолок, но зависит от алгоритмов. Не делите внимание на четыре платформы в первый год. 2. **Публикуйте последовательно до того, как появится что-то на продажу.** Аудитория, которую вы строите, когда продавать нечего, доверяет вам, когда вы наконец начинаете. 3. **Создайте список email с первого дня.** Подписчики в соцсетях — арендованная земля. Ваш список email принадлежит вам. Я использую [ConvertKit](/recommends/convertkit) — он справляется с последовательностями и рассылками, не мешая работе. Полезный ориентир: 1 000 настоящих поклонников (подписчики email, открывающие каждое письмо) достаточно для генерации $100K/год с цифровых продуктов. ## Шаг 3: Сначала оптимизируйте основной источник дохода Как только у вас есть аудитория (или клиент от услуги), сосредоточьтесь на основном источнике дохода, прежде чем добавлять вторичные. **Для контент-бизнеса:** партнёрский доход — это самый быстрый первый рубль. Вы пишете об инструментах, которые используете, ставите ссылки через страницу рекомендаций и зарабатываете процент. Никакого продукта для создания, никакой поддержки клиентов. Потолок реален — высокотрафиковый сайт в прибыльной нише может зарабатывать $5K–$30K/месяц — но это лучший механизм начального финансирования из тех, что я нашёл. **Для сервисного бизнеса:** берите больше, чем кажется комфортным. Занижение цены — самая распространённая ошибка солопренёра. Если у вас 100% показатель закрытия сделок, вы слишком дёшевы. **Для цифровых продуктов:** держите охват узким. Сфокусированный курс за $97 превосходит обширный за $497 по конверсии и показателю завершения. **Для Микро-SaaS:** создавайте для боли, которую вы лично ощущаете. Преимущество эмпатии реально, когда вы сами являетесь целевым клиентом. ## Шаг 4: Накапливайте вторичные источники дохода Как только ваша основная модель начнёт конвертировать, добавляйте источники дохода, не требующие пропорционального времени: - **Партнёрский доход** — даже сервисные бизнесы и операторы SaaS могут зарабатывать партнёрский доход с контента - **Цифровые продукты** — даже если вы в основном сервисный бизнес, курс или набор шаблонов может зарабатывать пока вы спите - **Спонсорство** — когда ваша аудитория превысит ~5 000 вовлечённых подписчиков - **Лицензирование** — если вы создали систему или инструмент, лицензируйте его другим в смежных нишах Накопление — это результат, а не стратегия. Сначала заставьте работать один поток. ## Технологический стек солопренёра Я веду всю эту операцию на шести инструментах: | Инструмент | Что делает | |---|---| | [Claude](/recommends/claude) | Первые черновики контента, писем и кода | | [ConvertKit](/recommends/convertkit) | Список рассылки, автоматизации и письма | | [Notion](/recommends/notion) | Редакционный календарь, документы клиентов и SOPs | | [Canva](/recommends/canva) | Графика для соцсетей и дизайн миниатюр | | [Airtable](/recommends/airtable) | Отслеживание партнёров, CRM, база данных контента | | [SEMrush](/recommends/semrush) | Исследование ключевых слов и отслеживание позиций | Общая месячная стоимость: менее $300. Команда, заменяющая этот стек, стоила бы $15K+ в месяц на зарплатах. ## 3 ошибки, убивающие бизнес солопренёра 1. **Преждевременное масштабирование.** Найм до того, как бизнес-модель доказана, сжигает ресурсы и добавляет управленческие накладные расходы до появления повторяемой выручки. 2. **Слишком ранняя диверсификация.** Четыре наполовину работающих источника дохода зарабатывают меньше, чем один полностью оптимизированный. В первый год идите глубже, не шире. 3. **Создание без дистрибуции.** Лучший продукт без аудитории не победит посредственный продукт с большим вовлечённым списком. Дистрибуция — это ров. ## Вывод оператора Бизнес солопренёра — это намеренный выбор обменять сложность команды на владение и маржу. Бизнесы, которые я стабильно видел успешными, разделяют одну модель: одна бизнес-модель, одна ниша, один канал дистрибуции, удерживаемые достаточно долго для компаундирования. Выберите модель, соответствующую вашим существующим навыкам. Создайте аудиторию до того, как она понадобится. Добавляйте источники дохода только после того, как основной начнёт конвертировать. Остальное — исполнение. --- **Связанные статьи:** [Как проверить бизнес-идею](/how-to-validate-a-business-idea/) · [Как монетизировать рассылку](/how-to-monetize-a-newsletter/) · [Как создать личный бренд](/how-to-build-a-personal-brand/) --- ## Как автоматизировать малый бизнес с помощью ИИ-агентов: практическое руководство Source: https://alejandrorioja.com/ru/how-to-automate-your-small-business-with-ai-agents/ Published: 2026-07-04 Tags: AI Agents, Entrepreneurship, Operations TL;DR: Автоматизация малого бизнеса с помощью ИИ-агентов — это не замена людей, а делегирование повторяющейся, основанной на правилах работы, чтобы вы могли тратить время на решения, которые можете принять только вы. Начните с одной задачи, записывайте всё, держите людей в петле для всего, что напрямую касается денег или клиентов, и расширяйтесь оттуда. Стек, который я использую в двух бизнесах, обходится менее чем в $100 в месяц. ## Содержание _Обновлено июль 2026._ **TL;DR:** Автоматизация малого бизнеса с помощью ИИ-агентов — это не замена людей, а делегирование повторяющейся, основанной на правилах работы, чтобы вы могли тратить время на решения, которые можете принять только вы. Начните с одной задачи, записывайте всё, держите людей в петле для всего, что напрямую касается денег или клиентов, и расширяйтесь оттуда. Стек, который я использую в двух бизнесах, обходится менее чем в $100 в месяц. **Заметка оператора:** Я управляю двумя бизнесами — крытым залом для пиклбола с девятью кортами в Пфлагервилле, TX (Pickleland) и консалтинговым брендом. В сумме у меня более 30 ИИ-агентов в продакшене, которые занимаются всем — от ответов на комментарии в соцсетях до продвижения мероприятий, черновиков рассылок и отслеживания бронирований. Это честный сценарий о том, что действительно работает, что тратит время впустую и как начать без найма разработчика. Честная оговорка: ИИ-агенты для малого бизнеса — не магия. Они не заменяют тяжёлую работу по выстраиванию клиентских отношений, качеству продукта или стратегическим решениям. Что они делают — избавляют от административной рутины, которая съедает два-три часа каждого оператора в день: сортировка входящих, копирование и вставка отчётов, ответы в соцсетях, форматирование данных. Этого достаточно, чтобы изменить картину. ## 4 типа работ, которые хорошо автоматизируются Прежде чем что-то строить, разбейте свою нагрузку на четыре категории. Только одна из них подходит для ИИ-агентов. ### 1. Основанные на правилах, повторяющиеся, текст на входе / текст на выходе Это оптимальная точка. Классифицировать клиентское письмо, составить ответ на комментарий в соцсети, обобщить неделю бронирований в список пунктов, переформатировать CSV в отчёт. На входе — текст; на выходе — текст; правила согласованы. Эти задачи автоматизируются с помощью одного промпта и тонкой обёртки вокруг API. **Примеры из Pickleland:** - Классификация входящих писем по запросу кортов (вопрос / жалоба / бронирование / прочее) - Составление постов для групп Facebook о предстоящих событиях - Генерация еженедельных сводок о заполняемости из системы бронирования ### 2. Многошаговые конвейеры с чёткими передачами Задача, состоящая из трёх шагов — получить данные, преобразовать их, отправить уведомление — где у каждого шага есть чёткий вход и выход. Это хорошо работает с лёгким слоем оркестрации (я использую Cloudflare Workers Queues). Ключевой момент: каждый шаг может завершиться неудачей независимо и быть повторён без переделки всей работы. **Примеры из Pickleland:** - Новое бронирование → обновление CRM → письмо-подтверждение → уведомление в Slack - Отправка формы → классификация → черновик направленного ответа → очередь проверки человеком ### 3. Мониторинг и оповещения Агенты, которые следят за условием и уведомляют вас, когда оно наступает. Это одни из ИИ-автоматизаций с наилучшим возвратом инвестиций, потому что они заменяют когнитивную нагрузку ручной проверки дашбордов. Они также одни из самых простых: логика — просто «X выше порога? Если да — оповестить». **Примеры из моего консалтингового бренда:** - Оповещения об аномалиях в Google Analytics (падение трафика, пики) - Процент отмены бронирований выше еженедельного базового уровня - Новый отзыв опубликован — отметить для ответа человека ### 4. Первые черновики контента (не финальный продукт) ИИ-агенты могут создавать посты для соцсетей, email-рассылки, планы блогов и описания продуктов приемлемого качества. Оговорка: они не могут заменить ваше редакционное суждение. Каждый черновик проходит этап проверки человеком. Возврат инвестиций — в том, что вы начинаете с 70%, а не с чистого листа. **Что плохо автоматизируется:** управление клиентскими отношениями, ценовые решения, продажные переговоры, найм и всё, где неверный результат имеет реальную цену для реального человека. Оставьте людей для этих задач. ## Стек, который я реально использую Для этого вам не нужно корпоративное ПО. Вот что обеспечивает мои автоматизации: 1. **[Claude](/recommends/claude)** — модельный слой для всех ИИ-задач. Я использую API напрямую, без GUI. Соотношение качества и стоимости — лучшее из протестированных мной, а [кэширование промптов](/prompt-caching-cut-your-claude-costs-without-switching-models/) ещё снижает расходы, когда системные промпты повторяются. 2. **Cloudflare Workers** — место, где живут агенты. Бессерверное, глобально распределённое, и бесплатный уровень покрывает большинство нагрузок малого бизнеса. Обработчик `scheduled` выполняет cron-задачи; обработчик `fetch` получает вебхуки для потоков, запускаемых событиями. 3. **Airtable** — основа данных. Каждый агент читает и пишет в таблицы Airtable. Здесь хранятся статус задач, очереди проверки и операционные данные. Люди без навыков разработки могут редактировать данные, не касаясь кода. 4. **Kit (ранее ConvertKit)** — автоматизация email и рассылок. Мой агент для составления рассылок пишет в черновик Kit; я проверяю и отправляю. Общая ежемесячная стоимость для 30+ агентов в двух бизнесах: менее $100. Главная статья — использование API Claude. Всё остальное — бесплатный уровень или почти бесплатно. ## Реальные примеры: автоматизации Pickleland ### Промоутер событий Каждое воскресенье запланированный агент проверяет систему бронирования на события ближайших четырёх дней. Он сопоставляет каждое событие с подходящими местными группами Facebook и составляет подходящий промо-пост для каждой. Черновики попадают в таблицу проверки Airtable. Я трачу пять минут на проверку и нажатие «Одобрить» — агент делает 40 минут составления. Ничто не публикуется автоматически без моего согласия. Это [шаблон запланированного агента](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — работает по расписанию, выполняет пакетную работу и представляет черновики для проверки человеком. ### Классификатор комментариев в соцсетях Когда на отслеживаемый пост в Facebook приходит новый комментарий, срабатывает вебхук, и агент классифицирует намерение: вопрос, жалоба, комплимент или спам. Для вопросов и жалоб выше порога уверенности он составляет ответ и отмечает его для проверки. Комплименты записываются. Спам подавляется. Цикл в 30 секунд от комментария до черновика. Без агента каждый комментарий был ручным переключением контекста; теперь очередь готовых ответов занимает пять минут вместо тридцати. Это [шаблон агента, запускаемого событиями](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) — активируется вебхуком, должен отвечать быстро. ### Еженедельная операционная сводка Каждое утро понедельника агент извлекает данные о бронированиях за прошлую неделю, процент отмен, заполняемость по типам кортов и любые замеченные аномалии. Он форматирует пятипунктную сводку и помещает её в страницу Notion. Я читаю её за кофе и за две минуты вместо двадцати получаю операционный контекст, необходимый мне на неделю. ## С чего начать: 4 шага ### Шаг 1: Выберите самую трудоёмкую повторяющуюся задачу, которую вы делаете каждую неделю Не самую гламурную, не самую стратегическую — ту, которая вызывает наибольший дискомфорт. Еженедельный отчёт, который вы копируете из трёх источников. Ответы в соцсетях, на которые уходит час. Письма для отслеживания, которые вы отправляете по одному. Это ваш первый агент. ### Шаг 2: Опишите задачу через входные и выходные данные Запишите: - Что запускает задачу (часы, событие, отправка формы) - Какие входные данные ей нужны (источники данных, текст, контекст) - Что является выходом (черновик, уведомление, строка базы данных) - Каков этап проверки человеком (у каждого первого агента должен быть такой) Если вы не можете чётко описать это, задача недостаточно хорошо определена для автоматизации. Сначала уточните процесс вручную. ### Шаг 3: Создайте минимально возможную версию Не систему. Один промпт, один вызов API, один выход. Функцию TypeScript, которая принимает ввод, вызывает Claude и возвращает черновик. Без базы данных, без вебхука, без очереди — только основная логика. Запустите её вручную пять раз. Держится ли качество выхода? Если да — у вас есть работающий агент. Затем добавьте инфраструктуру. ```typescript // Простейший первый агент: черновик промо-поста о событии async function draftEventPromo(event: PadklelandEvent, env: Env): Promise { const msg = await env.ANTHROPIC.messages.create({ model: "claude-opus-4-8", max_tokens: 400, system: `You write Facebook event promo posts for Pickleland, an indoor pickleball facility in Pflugerville, TX. Tone: friendly, local, community-focused. Max 150 words.`, messages: [ { role: "user", content: `Write a promo post for this event: ${JSON.stringify(event)}`, }, ], }); return (msg.content[0] as { text: string }).text; } ``` ### Шаг 4: Добавьте наблюдаемость до того, как добавлять новые функции Записывайте каждый запуск с trace-ID. Фиксируйте ввод, вывод и метку времени. Вам не нужен сложный инструмент — структурированный JSON в stdout достаточен для начала. Причина: ваш первый агент будет давать сбои способами, которые вы не предвидели. Когда это произойдёт, нужно видеть, что случилось, без воссоздания состояния из памяти. Это привычка, которая отличает операторов, масштабирующих свой стек агентов, от тех, кто сдаётся после одного плохого опыта. Я подробно рассматриваю это в [как отлаживать ИИ-агента в продакшене](/how-to-debug-an-ai-agent-in-production/). ## Распространённые ошибки (и как их избежать) **Автоматизация до понимания процесса.** Если вы не можете выполнять задачу сами последовательно, ИИ-агент будет делать её непоследовательно в масштабе. Сначала задокументируйте процесс вручную, потом автоматизируйте. **Слишком раннее удаление этапа проверки человеком.** Начинайте каждого агента с петлёй контроля человека. Дайте ему работать две недели, проверяйте каждый выход и набирайте уверенность, прежде чем позволить чему-либо работать полностью автоматически. Исключение — действия с низким риском, легко обратимые (например, запись черновика в папку). **Построение всей системы до валидации ядра.** Сначала создайте самую простую возможную версию. Если основное качество не достигается с одним промптом, больше инфраструктуры это не исправит. **Игнорирование затрат.** Расходы на ИИ API масштабируются с использованием. Знайте стоимость одного запуска до развёртывания в объёме. [Математика затрат Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) важна, когда вы делаете тысячи запусков в неделю. **Отношение к сбоям как к катастрофам.** Агенты дают сбои. Промпты регрессируют. API падают. Создавайте логику повторных попыток, [системы оценки](/the-eval-harness-i-use-to-ship-ai-agents/) и относитесь к сбоям как к данным, а не к катастрофам. ## Смена мышления, которая меняет всё Узким местом в малом бизнесе почти никогда не являются деньги — это время и внимание владельца. Каждый час, потраченный на задачи, которые агент может выполнить, — это час, который вы не посвятили клиентам, продукту или стратегии. Рамка, которую я использую: если задачу можно описать как повторяемый процесс с чёткими входами и выходами — она кандидат для агента. Всё, что требует суждения, отношений или творчества, остаётся за мной. Агент берёт на себя первое, чтобы я мог сосредоточиться на втором. Начало работы с ИИ-агентами не требует технического сооснователя, шестизначного бюджета на ПО или месяцев разработки. Нужно выбрать задачу с высоким трением, создать минимальную рабочую версию и учиться на выводе. Большинство операторов находят первого работающего агента за выходные. Дальше второй занимает послеобеденное время. ## FAQ ### Сколько стоит запуск ИИ-агентов для малого бизнеса? Мой стек запускает 30+ агентов менее чем за $100/месяц. Наибольшая статья — использование ИИ API (Claude). Cloudflare Workers бесплатен до 100 000 запросов/день и $5/месяц после. Airtable имеет бесплатный уровень, покрывающий большинство потребностей малого бизнеса в данных. Затраты масштабируются с использованием — один агент, запускаемый несколько раз в неделю, незначителен. ### Нужен ли мне разработчик для создания ИИ-агентов? Для базовых паттернов — запланированный cron, обработчик вебхука, простой промпт — вы справитесь с небольшим количеством JavaScript и готовностью читать документацию. Для более сложных конвейеров, оркестрации и наблюдаемости производственного уровня разработчик ускоряет работу. Мой курс ([ИИ-агенты для начинающих](/ai-agents-for-beginners-cowork-codex-guide/)) обучает путям без кода и с минимальным кодом для операторов. ### Какой первый ИИ-агент лучше всего подходит для малого бизнеса? Еженедельная операционная сводка. Работает по расписанию, имеет чёткие входные данные (ваши источники данных), производит согласованный вывод (отформатированную сводку) и имеет нулевой риск снижения — если черновик неверен, вы просто его не читаете. Он строит вашу интуицию о том, что агенты могут и не могут делать, без риска для клиентов или операций. ### Какую ИИ-модель использовать для автоматизации бизнеса? Я использую Claude для почти всей своей агентной работы. Качество API, надёжность и дружественное к оператору ценообразование (особенно с [кэшированием промптов](/prompt-caching-cut-your-claude-costs-without-switching-models/)) делают его правильным выбором для производственного использования. Для дешёвых, высокообъёмных задач классификации Claude Haiku 4.5 быстр и недорог. Для составления текстов и нюансированных задач — Claude Sonnet или Opus. ### Как не допустить ошибок ИИ-агентов, которые навредят моему бизнесу? Три практики: держите людей в петле для всего, что напрямую касается клиентов или денег; записывайте каждый запуск, чтобы отследить, что пошло не так; и создайте [систему оценки](/the-eval-harness-i-use-to-ship-ai-agents/), чтобы изменения в промптах не ломали продакшен молча. Начинайте с внутренних задач с низким риском и расширяйтесь только после того, как доверяете качеству вывода. --- ## Как создать личный бренд онлайн: Практическое руководство 2026 Source: https://alejandrorioja.com/ru/how-to-build-a-personal-brand/ Published: 2026-07-02 Tags: Entrepreneurship, Growth TL;DR: Личный бренд создаётся путём выбора конкретной аудитории, последовательной публикации полезного контента на одном канале и наличия чёткой точки зрения — а не оптимизации биографии в LinkedIn. Сузьте нишу, пишите из реального опыта, создайте список рассылки как единственный собственный канал и повторяйте, пока нужные люди не перестанут вас замечать. ## Содержание _Обновлено июль 2026._ **TL;DR:** Личный бренд создаётся путём выбора конкретной аудитории, последовательной публикации полезного контента на одном канале и наличия чёткой точки зрения — а не оптимизации биографии в LinkedIn. Сузьте нишу, пишите из реального опыта, создайте список рассылки как единственный собственный канал и повторяйте, пока нужные люди не перестанут вас замечать. **[Заметка практика]** Я строил в публичном пространстве через несколько предприятий — Pickleland, консультирование по ИИ-агентам, этот сайт — и паттерн, который я вижу снова и снова, один и тот же: люди, которые создают узнаваемые личные бренды, не самые талантливые. Они самые конкретные и самые последовательные. Вот фреймворк, который я использую и рекомендую. ## Что такое личный бренд на самом деле (и чем он не является) Личный бренд — это ответ на один вопрос: *Что говорят о вас люди, когда вас нет в комнате?* Это не ваш логотип. Это не ваша цветовая палитра. Это не количество подписчиков. Личный бренд — это ментальный ярлык, который люди формируют, когда слышат ваше имя — конкретная проблема, которую, по их мнению, вы можете решить, перспектива, которую они ожидают от вас. Ошибка, которую делает большинство: они пытаются создать бренд до того, как разработали точку зрения. Бренд — это то, что накапливается при выполнении реальных дел и конкретности в отношении того, что вы из этого узнали — а не то, что вы изготавливаете заранее. Что вы можете контролировать с самого начала: 1. С кем вы разговариваете 2. Какую проблему вы решаете для них 3. Где они вас находят 4. Насколько последовательно вы появляетесь Что накапливается со временем: - Репутация в определённой области экспертизы - Аудитория, которая доверяет вашему суждению - Входящие возможности, за которыми вам не пришлось гоняться ## Шаг 1: Выберите самую узкую нишу, в которой вы можете работать Наиболее распространённая ошибка в личном брендинге — быть слишком широким. "Эксперт по маркетингу." "Бизнес-консультант." "Технологический предприниматель." Это бессмысленные ярлыки в мире, где у всех они есть. Чем уже вы идёте, тем быстрее строите репутацию. Проверьте свою нишу по этому фильтру: - **Достаточно специфична для поиска.** Может ли кто-то найти вашу нишу в Google и найти реальное сообщество вокруг неё? - **Достаточно специфична для рекомендации.** Если кто-то встречает человека с вашей точной проблемой, думают ли они о вас первым? - **Достаточно широка для производства контента в течение 2+ лет.** Используйте инструмент ключевых слов, например [Semrush](/recommends/semrush), чтобы проверить, ищут ли вашу нишу. ## Шаг 2: Выберите один основной канал Попытка быть везде одновременно — это гарантированный способ быть посредственным везде. В начале выберите один канал и углубитесь в него. - **Письменный контент (блог/рассылка):** Лучше всего для аналитических аудиторий практиков. Накапливается со временем через SEO. - **LinkedIn:** Лучше всего для B2B и профессиональных аудиторий. - **YouTube / видео:** Лучше всего для тем, которые выигрывают от визуальной демонстрации. - **X / Twitter:** Лучше всего для идей, которые распространяются. ## Шаг 3: Найдите свою точку зрения Контент без точки зрения — это шум. То, что отличает личные бренды, которые цитируют, рекомендуют и ищут, — это чёткая перспектива — мнение о том, как устроен мир, основанное на реальном опыте. Сильная точка зрения имеет следующие свойства: - Она основана на чём-то, что вы действительно делали, а не просто читали - Она оспаривает хотя бы одно общепринятое предположение вашей аудитории - Она достаточно конкретна, чтобы некоторые люди с ней не согласились ## Шаг 4: Создайте собственную аудиторию Каждая платформа, на которой вы строите, может изменить свой алгоритм, заблокировать ваш аккаунт или закрыться. Единственный канал распределения, который вы действительно контролируете, — это ваш список рассылки. Начните создавать его с первого дня. Для рассылки я использую [ConvertKit](/recommends/convertkit) — разработан специально для рассылок создателей. Самый быстрый способ вырастить список рассылки: 1. **Создайте действительно полезный лид-магнит.** Контрольный список, шаблон или короткое руководство, которое решает конкретную проблему. 2. **Добавьте форму подписки выше линии сгиба на каждой странице контента.** 3. **Напишите приветственную последовательность из 3 писем.** 4. **Упоминайте список в каждом материале.** ## Шаг 5: Публикуйте последовательно — математика сложных процентов Если вы публикуете один длинный материал в неделю: - **Недели 1–8:** Почти никто не читает. Это нормально. - **Месяцы 3–4:** Некоторые материалы начинают получать органический трафик. - **Месяцы 6–9:** Поисковый трафик накапливается. Начинают появляться входящие запросы. - **Год 2:** У вас 100 материалов. Ваше имя появляется в поисках и ответах ИИ. Моё правило: посвятите 6 месяцев, прежде чем оценивать, работает ли это. ## Как я думаю о визуальном бренде Минимально жизнеспособный визуальный бренд: - Профессиональная фотография профиля, на которой ваше лицо чётко видно - Единообразная фотография профиля на всех платформах - Простой сайт с чётким слоганом и формой подписки [Canva](/recommends/canva) подходит для социальной графики и простого дизайна. ## Распространённые ошибки 1. **Пытаться нравиться всем.** Если вы пишете для "предпринимателей," вы пишете для никого. 2. **Публиковать без дистрибуции.** Написать пост и ждать трафика — не стратегия. 3. **Менять фокус каждый квартал.** Главный убийца импульса личного бренда. 4. **Измерять тщеславные метрики.** Измеряйте размер списка и коэффициент конверсии, а не лайки. 5. **Ждать, пока не станете "достаточно экспертом."** Вам не нужно быть мировым авторитетом в вашей теме. ## Стек личного бренда - **Email-платформа:** [ConvertKit](/recommends/convertkit) - **SEO-исследование:** [Semrush](/recommends/semrush) - **Создание контента:** [Claude](/recommends/claude) - **Дизайн:** [Canva](/recommends/canva) ## FAQ ### Сколько времени нужно для построения личного бренда? Реалистично — 12–24 месяца последовательных публикаций, прежде чем появится значительный входящий поток. ### Нужно ли мне быть на каждой социальной платформе? Нет. Глубина на одной платформе превосходит поверхностное присутствие на пяти. ### Что важнее: качество контента или частота публикаций? Оба, но не в равной степени. Качество устанавливает пол. Частота определяет, получаете ли вы повторения, необходимые для улучшения. ### Использовать своё настоящее имя или название бренда? Используйте своё настоящее имя. Личные бренды, привязанные к реальному человеку, лучше переживают изменения алгоритмов. ### Как монетизировать личный бренд? Четыре надёжных пути: (1) курсы / цифровые продукты, (2) консультирование и advisory, (3) партнёрские программы, и (4) спонсорский контент. --- **По теме:** [Как проверить бизнес-идею перед созданием](/how-to-validate-a-business-idea/) · [Как создать список рассылки с нуля](/how-to-build-an-email-list/) · [Как монетизировать рассылку](/how-to-monetize-a-newsletter/) --- ## Как добавить память ИИ-агенту: паттерны сохранения состояния для продакшена Source: https://alejandrorioja.com/ru/how-to-add-memory-to-an-ai-agent/ Published: 2026-06-30 Tags: AI Agents TL;DR: Агенты без состояния — те, что забывают всё при завершении Worker — подходят для разовых задач. Как только агент должен помнить, что произошло вчера, узнавать возвращающегося клиента или опираться на предыдущие результаты, нужна память. Есть три паттерна: рабочая память (контекст «в полёте», живёт в KV на время запуска), эпизодическая память (что произошло и когда, журнал для запросов) и семантическая память (что вы знаете, извлекается через векторный поиск или структурированные данные). Подключите нужный паттерн к нужной задаче. ## Содержание _Обновлено июнь 2026._ **TL;DR:** Агенты без состояния — те, что забывают всё при завершении Worker — подходят для разовых задач. Как только агент должен помнить, что произошло вчера, узнавать возвращающегося клиента или опираться на предыдущие результаты, нужна память. Есть три паттерна: рабочая память (контекст «в полёте», живёт в KV на время запуска), эпизодическая память (что произошло и когда, журнал для запросов) и семантическая память (что вы знаете, извлекается через векторный поиск или структурированные данные). Подключите нужный паттерн к нужной задаче. **[Взгляд оператора]** Я не раз упирался в стену безгосударственности. Агент ответов в соцсетях, который снова и снова представлялся клиентам, с которыми уже разговаривал 20 раз. Агент ежедневного брифинга, который четыре дня подряд сигнализировал об одной и той же проблеме, потому что не помнил, что уже делал это вчера. Добавление правильного типа памяти исправило оба случая. Вот что я использую. ## Почему агенты без состояния продолжают ломаться Агент без состояния начинает каждый запуск только с тем, что вы явно ему передаёте: системный промпт, сообщение пользователя и данные, которые вы получаете в момент вызова. У него нет осведомлённости о предыдущих запусках, предыдущих пользователях или предыдущих решениях. Для разовой задачи классификации — прочитать комментарий, вернуть категорию — без состояния правильно. Это быстро, дёшево и предсказуемо. Поверхность сбоя появляется в момент, когда вам нужна непрерывность: - Агент для клиентов, который не распознаёт историю клиента - Агент контента, который рекомендует статью, уже рекомендованную на прошлой неделе - Агент модерации, который продолжает эскалировать уже решённый кейс - Ежедневный брифинг, который бесконечно показывает один и тот же устаревший сигнал Всё это симптомы одной проблемы: у агента нет способа переносить контекст между запусками. ## Три типа памяти Фреймворк, который я нахожу полезным в продакшене: 1. **Рабочая память** — что агент знает _прямо сейчас_, в течение одного запуска. Хранится в KV или в оперативной памяти в течение жизни вызова. 2. **Эпизодическая память** — что произошло и когда. Структурированный журнал, который агент читает в начале каждого запуска для ориентации. 3. **Семантическая память** — что он знает о мире, клиентах или базе знаний. Извлекается через структурированные запросы или векторный поиск по необходимости. Вам не всегда нужны все три. Большинству агентов, которые я запускаю, нужны рабочая + эпизодическая. Семантическая память — самая сложная в построении и занимает своё место только тогда, когда база знаний слишком велика для контекстного окна. ## Рабочая память: контекст в полёте Рабочая память — это состояние, которое живёт в течение одного запуска агента. Простейшая форма — переменные в области видимости функции. Более интересная форма — общий ключ KV, который подзадачи в одном запуске читают и пишут. Мой агент ответов в соцсетях использует рабочую память для накопления контекста при обработке пакета комментариев в одном сообщении очереди. В начале он читает историю последних разговоров каждого клиента из KV, добавляет новый контекст по ходу обработки и записывает обратно в конце. ```typescript // workers/social-reply.ts async function processComment( comment: SocialCommentEvent, env: Env ): Promise { // Загрузить последнюю историю этого клиента из KV (рабочая память) const historyKey = `customer:${comment.userId}:history`; const rawHistory = await env.AGENT_KV.get(historyKey); const history: ConversationTurn[] = rawHistory ? JSON.parse(rawHistory) : []; // Построить контекстно-зависимый системный промпт из истории const systemPrompt = buildSystemPrompt(history); const response = await anthropic.messages.create({ model: "claude-opus-4-8", max_tokens: 512, system: systemPrompt, messages: [{ role: "user", content: comment.text }], }); const reply = response.content[0].type === "text" ? response.content[0].text : ""; // Обновить историю — хранить последние 10 ходов, TTL 30 дней const updatedHistory: ConversationTurn[] = [ ...history.slice(-9), { role: "assistant", content: reply, timestamp: comment.timestamp }, ]; await env.AGENT_KV.put(historyKey, JSON.stringify(updatedHistory), { expirationTtl: 60 * 60 * 24 * 30, }); await postReply(comment, reply, env); } ``` Два момента. История ограничена 10 ходами — используйте скользящее окно, не давайте ей расти безгранично. И TTL — 30 дней: если клиент молчит месяц, история истекает и агент начинает заново. Оба решения намеренные. ## Эпизодическая память: что произошло и когда Эпизодическая память — это журнал агента. Структурированная запись прошлых запусков, которую агент читает в начале каждого нового запуска, чтобы не повторяться. Мой агент ежедневного брифинга каждый день выводил одни и те же устаревшие оповещения, потому что каждый запуск не имел никакого представления о том, что уже было отмечено. Решение: структурированный журнал прошлых оповещений, который агент читает перед генерацией брифинга. ```typescript // workers/daily-brief.ts interface AlertLogEntry { id: string; surfacedAt: string; // ISO-временная метка resolvedAt?: string; summary: string; } async function buildDailyBrief(env: Env): Promise { const [emails, calendar, tasks] = await Promise.all([ fetchOvernightEmails(env), fetchTodayCalendar(env), fetchTopTasks(env), ]); // Загрузить эпизодическую память: что уже было отмечено const rawLog = await env.AGENT_KV.get("brief:alert-log"); const alertLog: AlertLogEntry[] = rawLog ? JSON.parse(rawLog) : []; // Фильтровать только недавние, нерешённые оповещения const sevenDaysAgo = new Date( Date.now() - 7 * 24 * 60 * 60 * 1000 ).toISOString(); const recentAlerts = alertLog.filter( (e) => e.surfacedAt > sevenDaysAgo && !e.resolvedAt ); const brief = await synthesizeBrief( { emails, calendar, tasks, recentAlerts }, env ); // Обновить журнал новыми оповещениями, отмеченными в этом запуске const newAlerts: AlertLogEntry[] = brief.newAlerts.map((a) => ({ id: crypto.randomUUID(), surfacedAt: new Date().toISOString(), summary: a, })); const updatedLog = [...alertLog, ...newAlerts].slice(-100); // хранить последние 100 await env.AGENT_KV.put("brief:alert-log", JSON.stringify(updatedLog)); await writeToWorkspace(brief.content, env); } ``` Теперь агент знает, что он уже говорил. Дублирующиеся оповещения не попадают в брифинг, пока основная проблема не изменится. Когда я отмечаю оповещение как решённое, оно исчезает из активного списка. Этот паттерн обобщается: любой агент, который производит решения, флаги или рекомендации, выигрывает от журнала. Журнал дёшев (несколько КБ в KV), выгода высока (никаких дублирующихся выводов). ## Семантическая память: что вы знаете Семантическая память — это база знаний. Она отвечает на вопрос «что ты знаешь о X?» во время запроса, а не набивает всё в системный промпт заранее. Простейшая форма — структурированный поиск в KV или базе данных. Мой агент бронирования Pickleland обращается к профилям клиентов и предпочтениям кортов перед составлением подтверждений: ```typescript // workers/booking-agent.ts interface CustomerProfile { userId: string; preferredCourts: string[]; experienceLevel: "beginner" | "intermediate" | "advanced"; specialNotes: string; } async function draftConfirmation( booking: BookingEvent, env: Env ): Promise { // Получить профиль клиента из KV (семантическая память — фактические знания) const profileKey = `customer:${booking.userId}:profile`; const rawProfile = await env.AGENT_KV.get(profileKey); const profile: CustomerProfile | null = rawProfile ? JSON.parse(rawProfile) : null; const systemPrompt = profile ? `Вы составляете персонализированные подтверждения бронирования. Этот клиент предпочитает ${profile.preferredCourts.join(", ")}, игрок уровня ${profile.experienceLevel}. ${profile.specialNotes}` : "Вы составляете подтверждения бронирования для площадки для пиклбола."; const response = await anthropic.messages.create({ model: "claude-haiku-4-5-20251001", max_tokens: 256, system: systemPrompt, messages: [ { role: "user", content: `Составьте подтверждение для: ${JSON.stringify(booking)}`, }, ], }); return response.content[0].type === "text" ? response.content[0].text : ""; } ``` Для больших баз знаний — документация продукта, база знаний поддержки, всё, что слишком велико для контекстного окна — нужно векторное хранилище. Схема работы: вложить запрос, извлечь k наиболее релевантных чанков, внедрить их в контекст. Cloudflare Vectorize обрабатывает это нативно, если вы уже на Workers. Для больших индексов я использовал Upstash Vector. Выбор зависит от масштаба, а не от принципа. Честная заметка о семантической памяти: это самая сложная из трёх для построения и поддержки. Индекс должен оставаться актуальным. Качество извлечения варьируется. Начните со структурированных поисков — KV, таблица в D1 — и переходите к векторному поиску только тогда, когда структурированный подход не может покрыть нужную поверхность знаний. ## Фреймворк принятия решений о памяти Прежде чем добавлять любую память агенту, ответьте на три вопроса: 1. **Нужно ли агенту помнить между запусками?** Если каждый вызов подлинно независим — перевод, классификация, разовая генерация — пропустите память. Без состояния проще и дешевле. 2. **Повторяется ли агент или действует слепо по отношению к своей истории?** Если да, сначала добавьте эпизодическую память. Это исправление с наименьшими усилиями и покрывает большинство жалоб «агент продолжает делать X». 3. **Обращается ли агент с каждым пользователем или сущностью одинаково, когда не должен?** Если да, добавьте рабочую память (история клиента, профиль пользователя) или семантическую память (система поиска или извлечения). Ошибка, которую я вижу чаще всего: кто-то добавляет огромную базу знаний (семантическая память) к агенту, который на самом деле давал сбой, потому что у него не было эпизодической памяти — никакого журнала того, что он уже делал. Сложность не соответствует проблеме. ## Что я реально использую в продакшене У 30+ агентов: - **Все** имеют по меньшей мере рабочую память — некоторую форму состояния внутри запуска, даже если это просто само контекстное окно. - **Около половины** имеют эпизодическую память — журнал прошлых запусков, решений или флагов. Это почти всегда стоит добавлять. - **Три-четыре** имеют настоящую семантическую память, поддерживаемую векторным хранилищем. Это агенты, которые отвечают на вопросы по большой, динамической базе знаний. Cloudflare KV — мой стандартный склад для рабочей и эпизодической памяти. Быстрый, дешёвый и нативно интегрированный в Workers — никакого дополнительного клиента, никаких отдельных учётных данных. Ограничение: KV в конечном счёте согласован и не подходит для частых записей. Для агентов, которые записывают состояние много раз в секунду, я использую Durable Objects или базу данных D1. Для семантической памяти на векторах я использую Cloudflare Vectorize для малых и средних индексов (менее ~100К векторов) и Upstash Vector для всего большего. Оба имеют первоклассные JavaScript-клиенты. ## Вывод оператора Добавляйте память агенту только тогда, когда безгосударственное поведение вызывает реальные проблемы — повторяющиеся выводы, слепые пятна в истории клиентов, игнорирование прошлых решений. Затем выберите правильный уровень: рабочая память для контекста текущего запуска, эпизодическая для того, что происходило исторически, семантическая для того, что вы знаете. Начните с эпизодической, если не уверены — она исправляет наиболее распространённый режим сбоя с наименьшей сложностью. Не обращайтесь к векторной базе данных, пока не исчерпаете структурированные поиски. Лучшая система памяти — самая простая, которая делает агента корректно работающим. --- **По теме:** [Стек агентов, который я использую для 30+ продакшн-агентов](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) · [Событийные vs. запланированные агенты](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [Как я измеряю, работает ли ИИ-агент на самом деле](/how-i-measure-whether-an-ai-agent-is-actually-working/) **Нужна помощь в проектировании памяти агентов для вашего случая?** [Свяжитесь со мной](/contact/) — я проектирую продакшн-системы агентов для операторских команд. --- ## Как создать список рассылки с нуля: Руководство 2026 Source: https://alejandrorioja.com/ru/how-to-build-an-email-list/ Published: 2026-06-27 Tags: Entrepreneurship, Growth TL;DR: Список рассылки — единственный канал дистрибуции, которым вы действительно владеете. Начните с лид-магнита, решающего конкретную проблему, разместите форму подписки в верхней части страницы и отправьте приветственную последовательность из 3 писем сразу после подписки. Качество всегда побеждает количество — 1 000 вовлечённых подписчиков превосходят 10 000 холодных. ## Содержание _Обновлено в июне 2026 года._ **TL;DR:** Список рассылки — единственный канал дистрибуции, которым вы действительно владеете. Начните с лид-магнита, решающего конкретную проблему, разместите форму подписки в верхней части страницы и отправьте приветственную последовательность из 3 писем сразу после подписки. Качество всегда побеждает количество — 1 000 вовлечённых подписчиков превосходят 10 000 холодных. **[Взгляд оператора]** В каждом бизнесе, в котором я участвовал и который создал устойчивый механизм доходов, было одно общее: список. Не подписчики. Не показы. Список людей, которые попросили услышать от вас. Вот как именно его построить с нуля. ## Единственный актив, которым вы действительно владеете Любой другой канал дистрибуции может исчезнуть. Обновление алгоритма Google уничтожает позиции в поисковой выдаче. Изменение политики платформы убивает ваш охват в Facebook. Рекламный аккаунт блокируется без предупреждения. Ваш список рассылки — исключение. Когда вы владеете списком рассылки, вы контролируете доставку. Ни один алгоритм не решает, кто увидит ваш контент. Ни одна платформа не взимает комиссию каждый раз, когда вы хотите достучаться до своей аудитории. Именно поэтому создание списка рассылки — первое, что я советую каждому основателю: до SEO, до платной рекламы, до социальных сетей. ## Шаг 1: Выберите платформу для email-маркетинга Прежде чем собрать хоть один адрес, вам нужна платформа для хранения и отправки. Не используйте Gmail. Не используйте корпоративную почту. Используйте специализированный инструмент с правильной инфраструктурой соответствия требованиям и доставляемости. Мои два выбора на 2026 год: **[ConvertKit](/recommends/convertkit)** — Лучший вариант для создателей контента и независимых операторов. Система тегирования и сегментации подписчиков по-настоящему превосходна. Бесплатно до 1 000 подписчиков. **[Moosend](/recommends/moosend)** — Лучший вариант для малого бизнеса, которому нужна автоматизация без ценника ConvertKit. Надёжный конструктор с перетаскиванием и стабильно хорошая доставляемость. Если начинаете с нуля, у обоих есть бесплатные тарифы, покрывающие первые несколько сотен подписчиков. Настройте аутентификацию DKIM, SPF и DMARC на вашем домене до начала отправки — с 2024 года Gmail и Yahoo требуют этого от массовых отправителей, и это защищает репутацию отправителя с первого дня. ## Шаг 2: Создайте лид-магнит, достойный скачивания Лид-магнит — это то, что вы предлагаете в обмен на email-адрес. Ошибка большинства: предлагать что-то общее. «Подпишитесь на нашу рассылку» — не лид-магнит. Это запрос доверия без ничего взамен. Ваш лид-магнит должен решать конкретную проблему конкретного человека. Чем конкретнее, тем лучше конвертирует. **Форматы, которые работают в 2026 году:** 1. **Шпаргалки и шаблоны** — Одностраничный ресурс, который кто-то может использовать немедленно. Чем ближе к «готово к использованию», тем лучше. 2. **Мини-курсы (3–5 писем)** — Короткая последовательность, обучающая одному навыку, доставляемая автоматически. Одновременно строит список и отношения. 3. **Калькулятор или таблица** — Высокая воспринимаемая ценность. Инструмент для оценки размера рынка, модель ценообразования, шаблон бюджета. Они конвертируют, потому что экономят реальный труд. 4. **Эксклюзивные данные или исследования** — Оригинальные результаты опросов или отраслевой бенчмарк. Сложно воспроизвести, высокое доверие. 5. **Свайп-файлы** — Коллекции реальных примеров (рекламные тексты, темы писем, заголовки лендингов). Практики платят за это. 6. **Вебинар или повтор обучения** — Перепрофилируйте существующую запись как opt-in. Настройка займёт 20 минут. Одно непреложное требование: лид-магнит должен быть напрямую связан с тем, о чём вы будете писать в рассылке. Шаблон рекламы Facebook, привлекающий подписчиков для B2B SaaS-рассылки, — это катастрофа качества списка, ожидающая своего часа. ## Шаг 3: Размещайте opt-in формы там, где они работают Расположение формы влияет на конверсию больше, чем текст. Размещайте opt-in формы там, где уже есть внимание: 1. **Выше линии сгиба на главной странице** — Не в подвале. Не на боковой панели. Выше линии сгиба, с чётким описанием того, что они получат. 2. **В конце каждой статьи блога** — Тот, кто прочитал всю статью, уже квалифицирован. Перехватите его, пока он вовлечён. 3. **Всплывающее окно при намерении выйти** — Срабатывает, когда посетитель собирается закрыть вкладку. Спорно, но работает. 4. **Специальная посадочная страница** — Автономная страница без навигации. Именно сюда вы направляете платный трафик. 5. **Апгрейды контента** — Ресурс, улучшающий конкретную статью. Таблица для оценки размера рынка внутри руководства TAM/SAM/SOM конвертирует в 3–5 раз лучше, чем общее предложение на той же странице. Совет по тексту: начинайте с результата, а не с формата. «Получите руководство из 5 страниц» слабее, чем «Узнайте размер рынка так, как это делают венчурные инвесторы.» ## Шаг 4: Напишите приветственную последовательность В момент подписки у вас есть максимальное внимание человека. Не тратьте его впустую на молчание. Отправьте минимум 3 письма: **Письмо 1 (немедленно):** Доставьте лид-магнит. Подтвердите, на что они подписались. Установите ожидания относительно того, что будет дальше. **Письмо 2 (день 2):** Ваш лучший контент — статья, кейс, фреймворк. Без продаж. Только доказательство того, что подписаться было стоило. **Письмо 3 (дни 4–5):** Ваша история и точка зрения. Почему вам важна эта тема? В чём вы убеждены, в отличие от большинства людей в вашей сфере? Именно здесь строится доверие. После этого поддерживайте стабильную периодичность. Еженедельная — стандарт. Раз в две недели работает, если вы не можете поддерживать качество еженедельно. Худшая ошибка — написать одно письмо при запуске, а потом исчезнуть на три месяца. ## Шаг 5: Привлекайте трафик к вашему opt-in Форма без трафика никого не конвертирует. Наиболее надёжные каналы роста: **Органический поиск** — Статьи блога, которые ранжируются по проблемам, которые решает ваш лид-магнит. Тот, кто ищет вашу тему и находит статью, уже квалифицирован для вашего предложения. Это самый дешёвый канал с наивысшим показателем удержания. **Социальные сети (органика)** — Посты в LinkedIn, треды в Twitter/X или короткие видео, ведущие людей на вашу opt-in страницу. Каждый пост должен быть тизером, а не полной историей. **Обмен рассылками и совместные акции** — Найдите рассылки в смежных нишах и обменяйтесь упоминаниями. Вы продвигаете их список; они продвигают ваш. Это один из самых быстрых способов вырасти с 500 до 5 000 подписчиков. **Гостевые выступления в подкастах** — Недооценённый канал. Эпизод на 30 минут, отправленный 2 000 нишевым слушателям, может добавить 50–100 глубоко заинтересованных подписчиков, которые с большей вероятностью будут открывать каждое ваше письмо. **Платная реклама** — Не запускайте рекламу для неподтверждённого предложения. Сначала добейтесь органических конверсий на opt-in странице, затем масштабируйтесь с помощью платного трафика. ## Шаг 6: Поддерживайте чистоту списка Список рассылки деградирует. Люди меняют работу, email-адреса, интересы. Если вы не чистите список, страдает доставляемость — а это значит, что даже вовлечённые подписчики перестают видеть ваши письма. Лучшие практики: - **Кампания по реактивации каждые 6 месяцев** — Отправьте письмо всем, кто не открывал письма 90+ дней. Дайте им причину остаться. Если они не реагируют — удалите. - **Немедленно удаляйте жёсткие отказы** — Высокий показатель отказов сигнализирует провайдерам почты, что ваш список нечистый. - **Сегментируйте по вовлечённости** — Отмечайте активных и холодных подписчиков отдельно. Срочные кампании отправляйте только активному сегменту. Удаление подписчиков ощущается как потеря. На практике это защищает тех подписчиков, которых вы хотите сохранить. ## Честные оговорки **Построение требует времени.** Начиная с нуля только органическими методами, ожидайте 3–6 месяцев до достижения 1 000 подписчиков. Кто обещает тысячи за недели — продаёт тщеславные метрики или холодные, незаинтересованные контакты, которые вам не нужны. **Ниша имеет значение.** Аудитория B2B реагирует на данные и кейсы. Потребительская аудитория реагирует на скидки и развлечения. Лид-магнит и периодичность контента должны соответствовать аудитории. **Лид-магниты устаревают.** То, что хорошо конвертирует сегодня, может устареть через 18 месяцев, когда конкуренты скопируют формат. Планируйте обновлять лид-магнит ежегодно. ## Реалистичные ориентиры | Метрика | Среднее по отрасли | Хорошо | |--------|-----------------|------| | Конверсия во всплывающем окне | 2–4% | 5–8% | | Конверсия на лендинге | 20–30% | 40–60% | | Открываемость приветственного письма | 50–60% | 70%+ | | Текущая открываемость | 20–25% | 35–45% | | Кликабельность | 2–3% | 5–10% | Не оптимизируйте эти показатели в первые 90 дней. Постройте инфраструктуру, запустите лид-магнит, отправляйте последовательно. Затем итерируйте. ## Обновлено для июня 2026 года **Лид-магниты, созданные с помощью ИИ** — Такие инструменты, как Claude, могут создать 10-страничное PDF-руководство, свайп-файл или шаблон за несколько минут. Барьер для создания высококачественного лид-магнита практически равен нулю. Дифференцирующим фактором теперь является конкретность обещания и релевантность вашей аудитории. **Аутентификация в Gmail и Yahoo** — С 2024 года DKIM, SPF и DMARC требуются для отправителей, рассылающих более 1 000 писем в день. И [ConvertKit](/recommends/convertkit), и [Moosend](/recommends/moosend) проводят вас через настройку во время онбординга. Сделайте это до того, как понадобится. **Трафик из ИИ-поиска** — Хорошо структурированная opt-in страница с чётким TL;DR и прямым ответом на поисковый запрос может появиться в ChatGPT, Perplexity и Google AI Overviews. Я видел, как opt-in лендинги генерируют стабильный трафик из ИИ-поиска без какой-либо SEO-работы — потому что страница напрямую отвечает на конкретный вопрос. ## Часто задаваемые вопросы **Сколько подписчиков нужно для монетизации?** Универсального числа нет. Я видел рассылки с 500 глубоко вовлечёнными подписчиками в нише с высоким намерением, которые превосходят списки из 20 000 общих контактов. Вопрос в том, есть ли у ваших подписчиков проблема и доверяют ли они вам её решение. **Стоит ли покупать список рассылки?** Нет. Купленные списки имеют ужасную вовлечённость, вас пометят как спам, и это может заблокировать ваш аккаунт. Коротких путей нет. **Как часто отправлять письма?** Так часто, как можете, поддерживая качество. Еженедельно держит вас в памяти. Самая большая ошибка — молчать месяцами и вернуться с продающим письмом. **Двойное или одиночное подтверждение?** В большинстве случаев — двойное. Подтверждение уменьшает размер списка, но резко улучшает вовлечённость и доставляемость. Исключение — когда вы привлекаете высококачественный, верифицированный трафик из конкретного источника. **Какая платформа лучше всего подходит для начинающих?** [ConvertKit](/recommends/convertkit) — для создателей, строящих личный бренд или контент-бизнес. [Moosend](/recommends/moosend) — для малого бизнеса, которому нужны доступность и автоматизация. Оба значительно лучше попыток использовать Gmail. ## Что делать дальше Список рассылки не существует в изоляции. Ваши лучшие статьи должны иметь апгрейды контента. Ваши письма должны ссылаться на подробные руководства. Ваш лид-магнит должен решать именно ту проблему, которую адресуют ваши страницы с наибольшим трафиком. Эта петля — трафик → подписка → нурчуринг → доверие → предложение — является основой каждого устойчивого онлайн-бизнеса, в котором я участвовал. Если вы хотите обсудить, как применить это в вашей конкретной ситуации, [страница контактов](/contact) — правильное место для начала. --- ## Как монетизировать рассылку: 5 моделей дохода, которые действительно работают Source: https://alejandrorioja.com/ru/how-to-monetize-a-newsletter/ Published: 2026-06-25 Tags: Entrepreneurship, Growth TL;DR: Большинство рассылок не могут монетизироваться, потому что они гонятся за неправильной моделью для своего размера списка. Пять моделей, которые работают: платные подписки (лучше всего для нишевого авторитета), спонсорство (лучше всего после 5 000+ подписчиков), партнёрские рекомендации (наименьшее сопротивление при любом размере), воронки курсов и продуктов (наивысший потолок дохода) и апселлы услуг (самый быстрый путь к реальным деньгам). Начните с одной. Добавляйте вторую только тогда, когда первая работает. ## Table of contents _Обновлено в июне 2026 года._ **TL;DR:** Большинство рассылок не могут монетизироваться, потому что они гонятся за неправильной моделью для своего размера списка. Пять моделей, которые работают: платные подписки (лучше всего для нишевого авторитета), спонсорство (лучше всего после 5 000+ подписчиков), партнёрские рекомендации (наименьшее сопротивление при любом размере), воронки курсов и продуктов (наивысший потолок дохода) и апселлы услуг (самый быстрый путь к реальным деньгам). Начните с одной. Добавляйте вторую только тогда, когда первая работает. **[Взгляд оператора]** Я веду рассылку с тех пор, как называть это "бизнесом рассылки" ещё не было модным. Честная версия пути: я пытался делать всё сразу, зарабатывал почти ничего, сократил до одной модели и начал зарабатывать. Вот что я узнал и что стабильно вижу работающим среди операторов, с которыми работаю. ## Почему большинство рассылок никогда не зарабатывают ни копейки Проблема монетизации — это обычно проблема последовательности. Люди запускают рассылку, медленно её развивают, а затем пытаются добавить все потоки дохода сразу — платный уровень здесь, спонсорский слот там, партнёрская ссылка в каждом выпуске. Результат — рассылка, которая ощущается как торговый центр: всё продаётся, ничто не кажется настоящим, и читатели теряют интерес. Рассылки, которые стабильно зарабатывают, сначала делают одно хорошо. Они доказывают, что одна модель работает для их конкретной аудитории. Затем — и только тогда — они добавляют вторую. Размер вашего списка также определяет, какие модели реалистичны. Список из 500 подписчиков — неправильный инструмент для поиска спонсоров. Список из 50 000 подписчиков оставляет значительные деньги на столе, если использует только партнёрские ссылки. Модель должна соответствовать списку. ## Модель 1: Платные подписки **Лучше всего для:** Нишевых авторитетных рассылок с определённой профессиональной или высокозаинтересованной аудиторией. Платные подписки — самая чистая форма монетизации рассылки: читатели платят напрямую за контент. Такие платформы, как Beehiiv и Substack, позволяют легко добавить это к бесплатному списку. Что заставляет это работать: - Конкретная, высокоценная ниша, где информация редка или экономит время (финансовый анализ, отраслевая аналитика, тактики уровня оператора) - Чёткий ответ на вопрос "что подписчик получает за оплату, что он не получает бесплатно?" - Бесплатный уровень, который действительно ценен — не разбавленная версия, а вкус подхода платного уровня Что убивает это: - Общие темы с низкой срочностью ("советы по маркетингу", "личностное развитие") - Запуск платного до того, как вы докажете, что бесплатные подписчики стабильно читают ваш контент Реалистичный доход: $5–$20/месяц на подписчика. При конверсии 5% из списка 2 000 человек — это 100 платных подписчиков по $10/месяц = $1 000 MRR. Небольшой, но реальный, и он накапливается. ## Модель 2: Спонсорство и нативная реклама **Лучше всего для:** Рассылок с 5 000+ подписчиков и определённой демографией аудитории. Спонсорство — самая заметная модель: слот выпуска продаётся бренду, релевантному для вашей аудитории. Когда это работает, это работает хорошо: $100–$500+ CPM (стоимость за тысячу подписчиков) типична для нишевой B2B или высокодоходной аудитории. Честное ограничение: спонсоры хотят масштаба и конкретики. "У меня 1 000 подписчиков, интересующихся маркетингом" не заключает сделки. "У меня 6 000 подписчиков — маркетинг-менеджеры в компаниях с 10–500 сотрудниками, с открываемостью 52%" — заключает. Как туда добраться: 1. **Определите свою аудиторию** в демографических терминах, а не в терминах интересов 2. **Достигните 5 000 подписчиков** как минимального порога доверия перед питчингом спонсоров 3. **Докажите вовлечённость** — показатели открываемости выше 40% — настоящий дифференциатор 4. **Создайте медиакит** — одностраничный PDF с количеством подписчиков, открываемостью, профилем аудитории и пакетами спонсорства 5. **Начните с inbound** — разместитесь на маркетплейсах спонсорства до создания процесса исходящих продаж Проверка CPM: если ваш список конвертируется при 45% открываемости и вы продаёте один спонсорский слот за выпуск при $200 CPM, список из 5 000 подписчиков генерирует $1 000 за спонсируемый выпуск. При четырёх выпусках в месяц — $4 000/месяц от одного спонсорского слота. При двух слотах — $8 000/месяц. Математика работает — в масштабе. ## Модель 3: Партнёрские рекомендации **Лучше всего для:** Любого размера списка, любой ниши, где вы по-настоящему используете инструменты и сервисы. Партнёрский маркетинг — модель с наименьшим сопротивлением для начала: вы рекомендуете продукты, которые действительно используете, читатели кликают и вы зарабатываете комиссию с покупок. Никаких спонсорских отношений для управления, никакого продукта для создания, никакого платного уровня для поддержания. Ключевое ограничение — доверие. Партнёрские рекомендации конвертируются только тогда, когда рекомендация по-настоящему полезна и надёжно обоснована. Раздел "лучшие выборы", заполненный продуктами, которые вы никогда не использовали, будет работать ниже ожиданий — или хуже того, повредит списку. Что работает: - Рекомендовать инструменты, которые вы используете в собственном стеке (для меня: [ConvertKit](/recommends/convertkit) для управления электронной почтой, [Semrush](/recommends/semrush) для SEO и исследования контента) - Контекстуальное размещение — упоминать инструмент там, где он релевантен для контента, а не в фиксированном блоке "спонсор этого выпуска", который читатели учатся пропускать - Давать реальное мнение: что нравится, что нет и для кого это не подходит Потолок дохода: партнёрские комиссии варьируются — инструменты SaaS обычно платят 20–40% на постоянной основе с конвертированных подписчиков, что хорошо накапливается. Список 1 000 подписчиков, где 2% читателей конвертируются на SaaS за $50/месяц при 30% комиссии = $300/месяц постоянных, растущих с каждой новой регистрацией, которая остаётся. ## Модель 4: Воронка курсов и цифровых продуктов **Лучше всего для:** Операторов с авторитетом обучения в конкретной области. Рассылка — верхняя часть воронки; курс или цифровой продукт — событие конверсии. Читатели, которые достаточно доверяют вам, чтобы открывать каждый выпуск, — наиболее квалифицированные лиды для платного продукта, который учит их тому, что вы знаете. Это модель с наивысшим потолком дохода при даже скромном списке. Курс за $497, проданный 2% списка из 5 000 человек — $49 700 за запуск. При трёх запусках в год с ростом списка это накапливается агрессивно. Что требуется: - Настоящий авторитет обучения в конкретной области — не просто "я знаю маркетинг", а "я вырастил три B2B-компании с помощью этого конкретного плейбука роста" - Контент, демонстрирующий авторитет неделя за неделей (не просто курируемые ссылки — ваши оригинальные фреймворки и кейсы) - Последовательность запуска, к которой список был подготовлен — не холодное письмо "купите мой курс" для списка, который только получает контент Это модель, на которую я больше всего опираюсь в своей работе. Рассылка строит доверие; курс его конвертирует. ## Модель 5: Апселлы услуг **Лучше всего для:** Рассылок на ранней стадии, где оператор предлагает консалтинг, коучинг или услуги "сделано за вас". Эта модель — самый быстрый путь к реальному доходу при небольших размерах списка, и она наиболее недооценена. Рассылка позиционирует вас как эксперта; услуга — это эксперт в действии. Если 500 человек читают вашу рассылку о growth-маркетинге и вы публикуете один выпуск в месяц, демонстрирующий ваше мышление, 1–2 из этих 500 читателей периодически поднимут руку и спросят, занимаетесь ли вы консалтингом. Если вы не предлагаете его, вы оставили доход на столе. Как сделать это явным: - Добавьте строку в нижний колонтитул рассылки: "Я работаю с небольшим количеством клиентов в квартал по [конкретному результату]. Ответьте на это письмо, если хотите изучить эту возможность." - Упомяните результаты клиентов (анонимизированные) в соответствующих выпусках — не как хвастовство, а как доказательство того, что фреймворки работают на практике - Держите мощность намеренно ограниченной — дефицит здесь не искусственный, он реален; у вас есть только определённое количество времени Реальность дохода: один консалтинговый клиент по $5 000/месяц и рассылка на 200 человек имеют лучшую экономику, чем 50 000 подписчиков, зарабатывающих $0,01/подписчик в разрозненном партнёрском доходе. Не ждите масштаба, чтобы начать здесь. ## Как выбрать правильную модель Фреймворк принятия решений: | Размер списка | Лучшая стартовая модель | Вторая модель для добавления | |--------------|------------------------|------------------------------| | 0–1 000 | Апселлы услуг | Партнёрские рекомендации | | 1 000–5 000 | Партнёрство + список ожидания курса | Платные подписки | | 5 000–20 000 | Спонсорство | Запуск курса | | 20 000+ | Спонсорство + курс | Платный уровень | Одно ограничение, которое не меняется ни при каком размере: сначала выбирайте одно. Разброс моделей убивает конверсию во всех моделях одновременно. ## Стек оператора рассылки Инструменты, которые я использую и рекомендую для построения бизнеса рассылки: - **Платформа электронной почты:** [ConvertKit](/recommends/convertkit) — теггирование подписчиков, сегментация и последовательности автоматизации, которые разделяют покупателей и читателей - **SEO и исследование тем:** [Semrush](/recommends/semrush) — определите, что ищет ваша целевая аудитория, прежде чем писать об этом - **Дизайн:** [Canva](/recommends/canva) — медиакит, обложки курсов и социальный контент без дизайнера - **Платежи:** Stripe — для платных уровней подписки или оплаты курсов ## Вывод оператора Рассылка — актив контента с наивысшим рычагом, который вы можете создать в 2026 году: внимание в почтовом ящике дефицитно и ценно так, как социальные ленты не являются. Но актив конвертируется в доход только тогда, когда вы выбираете модель, соответствующую размеру вашего списка, исполняете её с настоящими рекомендациями и реальным авторитетом, и сопротивляетесь желанию рассредоточиться по каждому методу монетизации сразу. Начните с модели, которая соответствует вашему текущему положению. Когда она работает — стабильно, с накапливающимися результатами — добавляйте следующую. --- **Связанные материалы:** [Как проверить бизнес-идею перед её реализацией](/how-to-validate-a-business-idea/) · [Руководство по стратегиям growth-маркетинга](/growth-marketing-strategies-guide/) · [6 лучших сервисов email-маркетинга для малого бизнеса](/6-best-email-marketing-services-for-small-business/) --- ## Как Создать Первый MCP-Сервер: Практическое Руководство Source: https://alejandrorioja.com/ru/how-to-build-your-first-mcp-server/ Published: 2026-06-23 Tags: AI Agents TL;DR: MCP (Model Context Protocol) — это способ предоставить Claude структурированный доступ к внешним инструментам и данным — базам данных, файлам, API — не перегружая контекстное окно. Сервер проще, чем кажется: установите SDK, определите инструменты как JSON-схему, реализуйте обработчики, подключитесь через stdio. Менее чем за 30 минут Claude сможет вызывать ваши кастомные инструменты. ## Содержание _Обновлено июнь 2026._ **TL;DR:** MCP (Model Context Protocol) — это способ предоставить [Claude](/recommends/claude) структурированный доступ к внешним инструментам и данным — базам данных, файлам, API — не перегружая контекстное окно. Сервер проще, чем кажется: установите SDK, определите инструменты как JSON-схему, реализуйте обработчики, подключитесь через stdio. Менее чем за 30 минут Claude сможет вызывать ваши кастомные инструменты. **[Взгляд оператора]** Я регулярно подключаю новые инструменты к своим агентам, и MCP стал стандартным способом делать это чисто. Как только сервер построен, любой совместимый клиент — Claude Desktop, Claude Code, любое приложение на Anthropic SDK — может его использовать без изменений в вызывающем коде. В этом ценность: создайте один раз, используйте везде. ## Что такое MCP на самом деле **Model Context Protocol** — открытый протокол, стандартизирующий подключение ИИ-моделей к внешнему контексту и инструментам. Представьте его как стандарт USB-C для ИИ-интеграций: раньше каждое приложение, желавшее подключить Claude к базе данных или API, изобретало собственные решения. Теперь создаёте один MCP-сервер, и любой совместимый хост может его использовать. MCP определяет три вещи, которые сервер может предоставить: - **Инструменты** — функции, которые Claude может вызывать (читать файл, запрашивать БД, отправлять сообщение в Slack) - **Ресурсы** — данные, которые Claude может читать (документы, строки баз данных, файловые деревья) - **Промпты** — многократно используемые шаблоны промптов, которые хост может внедрять Для большинства операторских случаев вы создаёте **серверы инструментов**. Ресурсы и промпты — позже, когда основное заработает. Архитектура клиент-серверная, где клиент (Claude Desktop, Claude Code, ваше приложение) всем управляет. Сервер пассивен — просто слушает запросы вызовов инструментов и возвращает результаты. ## Три части каждого MCP-сервера Каждый MCP-сервер имеет одинаковую структуру: 1. **Объект сервера** — объявляет имя, версию и возможности сервера (инструменты, ресурсы, промпты) 2. **Определения инструментов** — список инструментов с именами, описаниями и JSON-схемами для входных данных 3. **Обработчики запросов** — функции, запускаемые при вызове Claude инструмента Всё. Для начала не нужны база данных, HTTP-стек и слой авторизации. Минимальный сервер — менее 30 строк TypeScript. ## Предварительные требования (2 минуты) - **Node.js 18+** — проверьте `node --version` - **TypeScript 5+** (включён ниже как dev-зависимость) - MCP-клиент для тестирования — Claude Desktop бесплатен и проще всего показывает сервер в работе Для запуска MCP-сервера Anthropic API-ключ не нужен. Ключ живёт в клиенте (Claude Desktop), не в сервере. ## Шаг 1: Настройка проекта (3 минуты) ```bash mkdir my-mcp-server && cd my-mcp-server npm init -y npm install @modelcontextprotocol/sdk npm install -D typescript tsx @types/node ``` Добавьте в `package.json`: ```json { "type": "module", "scripts": { "build": "tsc", "dev": "tsx src/index.ts" } } ``` Создайте `tsconfig.json`: ```json { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "./build", "strict": true }, "include": ["src/**/*"] } ``` ## Шаг 2: Написать минимальный сервер (5 минут) Создайте `src/index.ts`: ```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { CallToolRequestSchema, ListToolsRequestSchema, } from "@modelcontextprotocol/sdk/types.js"; const server = new Server( { name: "my-mcp-server", version: "1.0.0" }, { capabilities: { tools: {} } } ); // Объявить инструменты сервера server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools: [ { name: "get_word_count", description: "Подсчитывает слова в блоке текста.", inputSchema: { type: "object", properties: { text: { type: "string", description: "Текст для подсчёта слов", }, }, required: ["text"], }, }, ], })); // Обработка вызовов инструментов от клиента server.setRequestHandler(CallToolRequestSchema, async (request) => { const { name, arguments: args } = request.params; if (name === "get_word_count") { const { text } = args as { text: string }; const count = text.trim().split(/\s+/).filter(Boolean).length; return { content: [{ type: "text", text: `Количество слов: ${count}` }], }; } throw new Error(`Неизвестный инструмент: ${name}`); }); // Подключиться через stdio — так Claude Desktop общается с сервером const transport = new StdioServerTransport(); await server.connect(transport); ``` Это полный сервер. Регистрирует один инструмент (`get_word_count`) и реализует его. Структура — главное. ## Шаг 3: Сборка и регистрация в Claude Desktop (5 минут) Скомпилируйте TypeScript: ```bash npm run build ``` Зарегистрируйте в конфигурационном файле Claude Desktop. На **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json` На **Windows**: `%APPDATA%\Claude\claude_desktop_config.json` Если файл не существует, создайте его: ```json { "mcpServers": { "my-mcp-server": { "command": "node", "args": ["/абсолютный/путь/к/my-mcp-server/build/index.js"] } } } ``` Используйте абсолютный путь. Перезапустите Claude Desktop после сохранения. В поле ввода сообщения появится значок молотка (🔨) — Claude обнаружил ваши инструменты. ## Шаг 4: Создание полезного инструмента Подсчёт слов — для иллюстрации. Вот более полезный инструмент: чтение файлов из директории проекта, что я использую для агентов инъекции контекста, суммирующих кодовые базы, changelogs или конфигурационные файлы. ```typescript import { readFileSync, readdirSync } from "fs"; import { join, extname } from "path"; const ALLOWED_EXTENSIONS = [".md", ".txt", ".ts", ".json", ".yaml"]; const PROJECT_DIR = process.env.PROJECT_DIR ?? process.cwd(); ``` Логика та же: определите инструменты с точными JSON-схемами, реализуйте обработчики, валидируйте входные данные для предотвращения path traversal, возвращайте текст клиенту. ## Ошибки, которые я совершил (чтобы вы не повторяли) **Путь должен быть абсолютным.** Относительные пути в конфигурации Claude Desktop разрешаются неожиданным образом. Всегда используйте полный путь `/home/user/...`. **Stdio означает никакого `console.log` в сервере.** Claude Desktop общается с сервером через stdin/stdout. Debug `console.log` повреждает JSON-RPC поток. Логируйте в stderr: ```typescript process.stderr.write(`Дебаг: ${message}\n`); ``` **Перезапускайте Claude Desktop после каждого изменения конфига.** MCP-серверы загружаются при запуске. Отредактированный файл конфига ничего не делает до перезапуска приложения. **Описания инструментов — это продукт.** Claude решает, вызывать ли инструмент, исходя из поля `description`. Расплывчатое описание — Claude не знает, когда его использовать. Точное — Claude берёт его в нужный момент. Тратьте больше времени на описания, чем на реализацию. ## Как я использую MCP-серверы в продакшне Паттерн stdio отлично подходит для Claude Desktop и Claude Code (локально). Для production-агентов — [30+ на Cloudflare Workers](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — напрямую использую tool-use API Anthropic SDK, поскольку мне нужна гибкость маршрутизации к [Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) по шагам. Паттерны, которые реально использую: 1. **Локальный dev-инструментарий** — MCP-серверы для Claude Code, экспонирующие проектоспецифичные инструменты 2. **Инъекция контекста** — MCP-серверы, предзагружающие релевантные документы без ручного копирования 3. **Мост прототип-к-API** — сначала строю MCP (быстрее итерировать), затем переношу логику в SDK tool-use для продакшна ## Что строить дальше Как только структура сервера понята, полезные инструменты — те, что дают Claude доступ к внешнему контексту: - **Читатель БД** — выполняет SQL-запрос только на чтение и возвращает результаты как JSON - **Читатель Slack** — получает последние N сообщений из канала - **Читатель GitHub** — список открытых PR, чтение файла на определённом коммите - **Обёртка внутреннего API** — вызывает ваш REST API со встроенными auth-заголовками ## Часто задаваемые вопросы ### Нужен ли API-ключ Anthropic для создания MCP-сервера? Нет. MCP-сервер не вызывает API Anthropic. Он лишь отвечает на запросы вызовов инструментов от клиента. API-ключ находится в клиенте, не в сервере. ### Может ли MCP-сервер вызывать внешние API? Да — обработчик просто асинхронный TypeScript-код. Получайте данные от погодного API, запрашивайте БД, пишите в файл. Сервер не интересуется, что делает обработчик внутри. ### В чём разница между транспортами stdio и HTTP? Stdio — для локальных серверов на одной машине с Claude Desktop или Claude Code. HTTP с SSE — для удалённых серверов, развёртываемых как веб-сервис. Начните со stdio; проще отлаживать. ### Как Claude знает, когда вызывать мой инструмент? Claude решает на основе поля `description` инструмента и контекста разговора. Если Claude продолжает игнорировать инструмент, уточните описание. --- ## Как проверить бизнес-идею до её реализации Source: https://alejandrorioja.com/ru/how-to-validate-a-business-idea/ Published: 2026-06-20 Tags: Entrepreneurship, Growth TL;DR: Большинство бизнес-идей терпят неудачу не из-за плохой реализации, а из-за пропущенной валидации. Самый быстрый путь: подтвердите существование проблемы через поисковый спрос и форумные доказательства, проанализируйте конкурентов, чтобы доказать, что кто-то уже зарабатывает, создайте минимально возможный дым-тест и получите обязательство — депозит, регистрацию в листе ожидания, письмо о намерениях — прежде чем что-либо строить. Если не удаётся получить обязательство хотя бы от одного человека, идея ещё не готова. ## Table of contents _Обновлено в июне 2026 года._ **TL;DR:** Большинство бизнес-идей терпят неудачу не из-за плохой реализации, а из-за пропущенной валидации. Самый быстрый путь: подтвердите существование проблемы через поисковый спрос и форумные доказательства, проанализируйте конкурентов, чтобы доказать, что кто-то уже зарабатывает, создайте минимально возможный дым-тест и получите обязательство — депозит, регистрацию в листе ожидания, письмо о намерениях — прежде чем что-либо строить. Если не удаётся получить обязательство хотя бы от одного человека, идея ещё не готова. **[Взгляд оператора]** Я видел этот паттерн десятки раз у основателей, с которыми работал, и в своих проектах: идея звучит убедительно, основатель полон энтузиазма, реализация надёжна — а потом они запускаются и получают тишину. Не потому что построили не то, а потому что пропустили единственный шаг, который предупредил бы их до того, как они потратили шесть месяцев. Вот фреймворк валидации, которым я пользуюсь и который рекомендую. ## Почему большинство усилий по валидации проваливается Очевидный способ провала — полное отсутствие валидации: сначала строить, потом задавать вопросы. Но более тонкая ловушка — театр валидации: проводить опросы, разговаривать с друзьями, собирать расплывчатые ответы типа «отличная идея!» и называть это сигналом. Опросы лгут. Люди вежливы. На вопрос «Заплатили бы вы за это 50 долларов?» в гипотетическом контексте ответ почти всегда положительный. Единственный сигнал, который имеет значение, — это обязательство: человек, который реально даёт вам деньги, время или письменное письмо о намерениях. Всё остальное — подавление шума, а не валидация. ## Шаг 1: Подтвердите, что проблема реально существует в масштабе Прежде чем валидировать своё решение, убедитесь, что проблема реальна и люди её ищут. **Поисковый спрос — самый быстрый индикатор.** Введите свою проблему в Google. Посмотрите на подсказки автозаполнения, раздел «Люди также спрашивают» и страницы с лучшими позициями. Если результатов нет, никто не ищет — а бизнес, решающий проблему, которую никто не ищет, будет тратить все усилия на образование, а не на конверсию. Воспользуйтесь инструментом для ключевых слов, например [Semrush](/recommends/semrush), чтобы проверить реальный ежемесячный объём поиска. Проблема с 1 000–10 000 месячных запросов на вашем целевом рынке жизнеспособна. Проблема с 20 запросами в месяц — нишевый продукт с проблемой дистрибуции. **Форумные доказательства — дополнительный качественный слой.** Ищите свою проблему на Reddit, Quora, в нишевых Facebook-группах и Discord-сообществах. Люди активно жалуются на неё? Ищут решения? Обходные пути? Настоящее разочарование — это золото: значит, боль достаточно сильна, чтобы побуждать людей искать помощь публично. Если вы не можете найти 20 форумных веток от реальных людей, описывающих проблему, будьте скептичны. ## Шаг 2: Проанализируйте конкурентов — доказательство, что деньги уже есть Распространённый инстинкт основателя: «нет конкуренции — значит, я завоюю рынок». Это почти всегда неверно. Отсутствие конкуренции обычно означает отсутствие рынка. Конкуренция — доказательство того, что клиенты существуют и готовы платить. Поищите в Google вашу категорию решений. Кто занимает топ позиции? Что обещают их лендинги? Сколько они берут? Читайте отзывы и рецензии — особенно негативные. Негативные отзывы — это продуктовая дорожная карта: они точно показывают, чего хочет рынок, но не получает. Если вы находите 3–5 устоявшихся конкурентов с реальными продуктами и реальными клиентами — это хороший знак. Если находите ноль, ищите глубже, прежде чем заключить, что рынка нет, — или расценивайте это как красный флаг. **Ключевые вопросы для ответа:** 1. Кто топ-3–5 игроков? 2. Сколько они берут? 3. Что критикуют рецензенты? 4. Есть ли позиционный разрыв, который я могу занять? ## Шаг 3: Создайте минимально возможный дым-тест Зная, что проблема существует и в рынке есть деньги, создайте минимальный артефакт, необходимый для проверки того, получает ли *ваша* версия тягу. Это не готовый продукт. Это механизм захвата сигнала. **Вариант А: Лендинг с захватом email.** Одностраничный сайт, описывающий проблему и решение, с призывом «Вступить в лист ожидания» или «Получить ранний доступ». Конверсия скажет вам, резонирует ли ваше позиционирование. Webflow, Carrd или даже публичная страница Notion — всё подойдёт. Не усложняйте. **Вариант Б: Предпродажа.** Реальный поток оплаты с реальными деньгами. Это сигнал наивысшего качества. Если кто-то платит вам за то, чего ещё нет, — он верит в решение. Даже возвращаемый депозит работает. **Вариант В: Консьерж-MVP.** Делайте это вручную, прежде чем автоматизировать. Консалтинг вместо SaaS. Кастомная таблица вместо программного инструмента. Вручную составленная рассылка вместо AI-генерированной. Вы обслуживаете горстку клиентов «в лоб», узнаёте, что именно они ценят, а затем строите продукт вокруг этого. ## Шаг 4: Получите обязательство до начала строительства Это шлюз, отделяющий реальную валидацию от wishful thinking. Определите, что означает «обязательство» для вашей идеи до проведения теста: - **SaaS / программное обеспечение:** Предпродажа по сниженной цене или подписанное письмо о намерениях - **Контент / медиа:** Email-подписчики, нажавшие для подключения (не просто подписчики) - **Услуги / консалтинг:** Оплаченный ознакомительный звонок или подписанное предложение - **Физический продукт:** Депозит или предзаказ на Kickstarter Если не получается добиться обязательства хотя бы от одного человека — даже со скидкой, даже с гарантией возврата денег — идея ещё не готова. Это не провал; это система работает. Она сэкономила вам месяцы времени разработки. ## Шаг 5: Установите порог прохождения/провала до начала Ловушка такова: вы проводите тест, получаете слабые результаты и всё равно убеждаете себя продолжать. «Текст лендинга был неудачным.» «Я недостаточно продвигал.» «Нужно просто больше времени.» Стоп. До проведения теста запишите порог: > «Если в течение 14 дней без платной рекламы я получу 50 регистраций в лист ожидания, я строю. Если не достигну 50 — не строю: либо меняю позиционирование, либо закрываю идею». Запишите это. Скажите другу. Сделайте публичным, если можете. А затем придерживайтесь этого. Число произвольно; главное — принять решение заранее и не сдвигать ворота, когда данные приходят холодными. ## Типичные ошибки валидации 1. **Спрашивать людей, купили ли бы они.** Они почти всегда говорят «да» из вежливости. Единственный вопрос, который имеет значение: «Вы купите это прямо сейчас?» 2. **Валидировать с друзьями и семьёй.** Они за вас болеют. Они не ваши клиенты. 3. **Решать собственную проблему, не проверив, есть ли она у других.** Ваша проблема может быть уникальной. Проверьте форумы. 4. **Называть ответы на опросы валидацией.** Опрос может генерировать идеи. Он не может подтвердить спрос. Только деньги или реальное обязательство могут. 5. **Ждать идеальной информации.** Валидация — это получить достаточно сигнала для следующего шага, а не полностью устранить неопределённость. ## Что означают сигналы «вперёд» Вы ищете сочетание: 1. Объём поиска выше 1 000 запросов в месяц по ключевому слову основной проблемы 2. Конкурентная активность — 3+ реальных игрока, берущих реальные деньги 3. Не менее 20 форумных или общественных веток, показывающих активное разочарование проблемой 4. Конверсия дым-теста выше 5% на целевом трафике 5. Хотя бы один человек берёт обязательство — платит, подписывает или вносит депозит — без ваших уговоров Все пять — у вас жизнеспособное направление. Два-три — есть сигнал, достойный доработки. Ноль — нужна принципиально другая идея или аудитория. ## Стек для валидации Инструменты, которые я использую и рекомендую для этого процесса: - **Поисковый спрос:** [Semrush](/recommends/semrush) — объём ключевых слов, анализ конкурентов и контентные пробелы в одном месте - **Исследование форумов:** Reddit, Quora, нишевые Facebook-группы, Discord-сообщества - **Лендинг:** Carrd (бесплатно, быстро) или Webflow для большего контроля дизайна - **Захват email / лист ожидания:** Kit (ConvertKit), чтобы начать строить список во время валидации - **Платежи:** Stripe — прямая ссылка на чекаут до создания продукта - **Аналитика:** Google Analytics на странице дым-теста для отслеживания реального поведения ## Итог оператора Самое дорогое, что вы можете построить, — это продукт, который никому не нужен. Валидация — не устранение риска, а быстрое провальное решение на бумаге вместо медленного провала в продакшн. Проведите тест, получите обязательство, установите порог до начала и соблюдайте результат. Если сигнал есть — вы это почувствуете. Если нет — тоже. --- **Связанное:** [Как построить прибыльный бизнес](/how-to-build-profitable-business/) · [Руководство по стратегиям роста маркетинга](/growth-marketing-strategies-guide/) · [Как стать предпринимателем](/how-to-become-an-entrepreneur/) --- ## Кэширование промптов в Claude API: снижаем затраты на ввод без смены модели Source: https://alejandrorioja.com/ru/prompt-caching-cut-your-claude-costs-without-switching-models/ Published: 2026-06-18 Updated: 2026-06-18 Tags: AI Agents, Operations TL;DR: Кэширование промптов снижает стоимость больших стабильных вводных данных — вашего системного промпта, определений инструментов, few-shot примеров — примерно до 10% от обычной цены на ввод при повторных запросах. Механизм — это совпадение префикса: поставьте маркер cache_control в конце стабильного контента и держите всё изменчивое после него. Ошибка, которая убивает процент попаданий в кэш, — это когда временная метка или UUID просачивается в префикс. ## Table of contents _Обновлено в июне 2026._ **Кратко:** Кэширование промптов снижает стоимость больших стабильных вводных данных — вашего системного промпта, определений инструментов, few-shot примеров — примерно до 10% от обычной цены на ввод при повторных запросах. Механизм — это совпадение префикса: поставьте маркер `cache_control` в конце стабильного контента и держите всё изменчивое после него. Ошибка, которая убивает процент попаданий в кэш, — это когда временная метка или UUID просачивается в префикс. **[Взгляд оператора]** Я запускаю более 100 агентов в своём консалтинговом бренде и в Pickleland. Самая крупная статья расходов — это не уровень модели, а то, как часто я заново отправляю один и тот же системный промпт на 4 000 токенов в каждом запросе. Кэширование промптов снизило эту стоимость почти до нуля на высокочастотных агентах, не затрагивая ни модель, ни качество вывода. Вот как именно это работает и где скрыты ловушки. ## Что на самом деле делает кэширование промптов Каждый вызов [Claude](/recommends/claude) API отправляет токены. Без кэширования каждый токен в вашем запросе — системный промпт, определения инструментов, few-shot примеры и сообщение пользователя — оплачивается по обычной ставке за ввод. С кэшированием префикс этих токенов сохраняется на серверах Anthropic после первого запроса. На последующих запросах, которые разделяют этот точный префикс, вы платите цену *чтения* из кэша вместо повторной обработки токенов с нуля. Разница в стоимости реальна: - **Запись в кэш:** ~1,25× от базовой цены на ввод (TTL 5 минут) или ~2× (TTL 1 час) - **Чтение из кэша:** ~0,1× от базовой цены на ввод - **Точка безубыточности:** 2 запроса при TTL 5 минут, 3 запроса при TTL 1 час Как только вы прошли точку безубыточности — а это происходит быстро на любом агенте, который запускается чаще нескольких раз в день, — каждое дополнительное попадание в кэш даёт скидку ~90% на эти токены. ## Инвариант совпадения префикса Это то единственное правило, из которого следует всё остальное: **ключ кэша — это совпадение префикса вашего отрендеренного промпта**. Серверы Anthropic хранят отрендеренный контент от начала вашего промпта до маркера `cache_control`. Чтобы при следующем запросе произошло попадание в кэш, каждый токен от начала промпта до этого маркера должен быть идентичным — побайтово. Порядок рендеринга для совпадения префикса такой: tools → system → messages. То есть сначала хэшируется массив ваших инструментов, затем системный блок, затем сообщения по порядку. Что это значит на практике: стабильный контент должен идти первым. Если ваш системный промпт ссылается на что-то динамическое — текущую дату, идентификатор пользователя, trace ID запроса — и это появляется *до* маркера `cache_control`, кэш будет промахиваться на каждом запросе, потому что префикс постоянно меняется. ## На что ставить маркер кэша Цели с наибольшей отдачей такие: **1. Ваш системный промпт** Системные промпты обычно — самый большой стабильный блок. Подробная персона агента, список поведенческих правил, набор инструкций по формату вывода — всё это идентично при каждом вызове одного и того же агента. Отметьте его: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic(); const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, system: [ { type: "text", text: `You are a content operations agent for alejandrorioja.com. Your job is to draft blog posts in Alejandro's voice: direct, practitioner, first-person, numbered lists, honest caveats. No hedging. No filler. Every section must earn its place. [... 2000 more tokens of stable instructions ...]`, cache_control: { type: "ephemeral" }, }, ], messages: [ { role: "user", content: "Draft a post about prompt caching.", }, ], }); ``` `cache_control: { type: "ephemeral" }` на системном блоке говорит Claude кэшировать всё вплоть до этого блока включительно. Массив `messages` изменчив — разный при каждом запросе — и остаётся за границей кэша. **2. Определения инструментов** Если ваш агент использует инструменты, их определения могут быть весьма объёмными. Хорошо документированная схема инструмента с описанием, именами параметров и значениями enum может занимать 500–1 000 токенов на инструмент. С 5 инструментами это до 5 000 токенов, за повторную обработку которых вы платите при каждом вызове: ```typescript const response = await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1024, tools: [ { name: "search_airtable", description: "Search the Airtable content queue...", input_schema: { type: "object", properties: { query: { type: "string" } } }, }, // ... more tools ... { name: "post_to_kit", description: "Schedule a broadcast via the Kit API...", input_schema: { /* ... */ }, // Mark the last tool to cache the entire tools array } as Anthropic.Tool & { cache_control: { type: "ephemeral" } }, ], system: "...", messages: [...], }); ``` Отметьте *последний* инструмент в массиве. Совпадение префикса покроет весь массив инструментов начиная с этой точки. **3. Few-shot примеры в сообщениях** Если вы передаёте статические few-shot примеры как первые сообщения в массиве `messages`, их тоже можно кэшировать. Структурируйте их как первые N сообщений и отметьте последний ход с примером: ```typescript const messages: Anthropic.MessageParam[] = [ { role: "user", content: [ { type: "text", text: "Here are examples of posts in my voice:\n\n[Example 1...]\n\n[Example 2...]", cache_control: { type: "ephemeral" }, } as Anthropic.TextBlockParam & { cache_control: { type: "ephemeral" } }, ], }, { role: "assistant", content: "Understood. I'll follow that voice.", }, // The actual user turn follows — this is volatile, no cache marker { role: "user", content: actualUserRequest, }, ]; ``` ## Что НЕ кэшировать (скрытые инвалидаторы) Это вещи, которые выглядят стабильными, но таковыми не являются, — и они тихо убьют ваш процент попаданий. API вас не предупредит. Вы просто будете видеть `cache_creation_input_tokens` на каждом запросе и недоумевать, почему. **Временные метки в системном промпте.** Самая распространённая ошибка: ```typescript // This invalidates the cache on every request const system = `You are an agent. Current time: ${new Date().toISOString()}`; ``` Перенесите временные метки в сообщение пользователя, где им и место: ```typescript // Stable system prompt — cacheable const system = `You are an agent. Use the current time provided by the user.`; // Volatile user message — not cached const userMessage = `Current time: ${new Date().toISOString()}. Run the daily brief.`; ``` **Случайные UUID и trace ID.** Та же проблема. Если вы вставляете trace ID в системный блок для логирования, каждый запрос получает новый префикс. **Недетерминированная сериализация JSON.** Если вы сериализуете объект в системный промпт, а порядок ключей не гарантирован, отрендеренная строка может отличаться, даже когда исходные данные те же самые. Сериализуйте со стабильным порядком ключей или используйте шаблонную строку. **Динамический выбор few-shot примеров.** Если вы выбираете few-shot примеры на основе текущего запроса и помещаете их в кэшируемый префикс, вы сделали «стабильный» префикс зависимым от запроса. Либо зафиксируйте примеры для слоя кэширования, либо перенесите динамические примеры в некэшируемый ход сообщения. ## Проверка процента попаданий в кэш Каждый ответ включает метаданные об использовании. Проверяйте их: ```typescript const response = await client.messages.create({ /* ... */ }); console.log({ inputTokens: response.usage.input_tokens, cacheRead: response.usage.cache_read_input_tokens, cacheWrite: response.usage.cache_creation_input_tokens, outputTokens: response.usage.output_tokens, }); ``` На первом запросе: `cache_creation_input_tokens` будет ненулевым, `cache_read_input_tokens` будет равен 0. Это запись. На попадании в кэш: `cache_read_input_tokens` будет ненулевым, `cache_creation_input_tokens` будет равен 0. Это чтение. Если вы видите `cache_creation_input_tokens` на каждом запросе, значит, ваш префикс меняется. Добавьте оператор логирования, который печатает первые 200 символов вашего отрендеренного системного промпта перед каждым вызовом, — плавающая временная метка тут же бросится в глаза. ## TTL в 1 час: когда дополнительная стоимость записи того стоит TTL по умолчанию — 5 минут. Если ваш агент работает с низкой частотой — реже одного раза в 5 минут, — вы будете платить за записи в кэш на большинстве запросов, не получая чтений. ```typescript // Opt into a 1-hour TTL cache_control: { type: "ephemeral", ttl: "1h" } ``` Запись с TTL в 1 час стоит ~2× от базовой цены на ввод вместо 1,25×. Расчёт: если вы попадаете в кэш 3 или более раз в час, TTL в 1 час экономит деньги. Если ваш агент работает раз в день (как мой ежедневный брифинг), даже TTL в 1 час не поможет — вы платите за запись каждый раз. В этом случае выгода от кэширования скромная, если только системный промпт не огромен. У моего агента ежедневного брифинга системный промпт на 3 000 токенов, но запускается он раз в день. Кэширование не помогает. Мой агент рассылки запускается десятки раз за сессию во время черновой работы — кэширование экономит существенно. ## Предварительный прогрев: как сделать первый запрос дешёвым Если вы знаете о приближающемся всплеске трафика — пакетном задании, запуске API, — вы можете предварительно прогреть кэш дешёвым фиктивным запросом: ```typescript // Pre-warm: write the cache at near-zero output cost await client.messages.create({ model: "claude-opus-4-8", max_tokens: 1, // minimal output system: [{ type: "text", text: stableSystemPrompt, cache_control: { type: "ephemeral" } }], messages: [{ role: "user", content: "ping" }], }); // Now the real requests read from cache ``` Это в основном полезно для пакетной обработки, когда вы запускаете множество параллельных запросов и хотите, чтобы каждый попал в тёплый кэш, а не гонялся за тем, кто его запишет. ## Кэширование промптов в агентных циклах В многоходовом агентном цикле история разговора растёт на каждом ходу. Кэш достаточно умён, чтобы справиться с этим: он использует окно просмотра назад в 20 блоков, находя самый длинный совпадающий префикс в пределах последних 20 блоков контента. Практический вывод: держите ваш стабильный контент (системный промпт, определения инструментов) закреплённым наверху. Растущая история разговора в конце массива сообщений не сломает совпадение префикса для стабильных блоков — они идут перед изменчивым контентом, а совпадение префикса начинается сверху. На практике мои агенты структурируют ходы так: ``` System (cached) → Tools (cached) → Few-shot (cached) → Turn 1 → Turn 2 → ... → Current turn ``` Кэш покрывает всё вплоть до маркера few-shot. Растущая история ходов после него обрабатывается заново каждый раз, но это нормально — эти токены специфичны для сессии и малы относительно стабильного префикса. ## Как это выглядит в счёте Возьмём высокочастотного агента: 100 вызовов в день, системный промпт на 4 000 токенов, цены Sonnet. Без кэширования: - 100 × 4 000 токенов × $3/1M = **$1,20/день** С кэшированием (TTL 5 минут, при допущении 50 вызовов в час на пике): - 1 запись каждые 5 минут × $3,75/1M × 4 000 токенов = ~$0,02/день на записи - ~98 чтений/день × $0,30/1M × 4 000 токенов = **$0,12/день на чтения** Это примерно 90% снижение на этих токенах ввода. На масштабе — 1 000 вызовов в день — разница усиливается ещё сильнее. И всё это поверх любой экономии от маршрутизации моделей из [математики Haiku против Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet): кэширование работает на любом уровне. ## Итог для оператора Кэширование промптов — самая простая оптимизация затрат в Claude API: одно дополнительное поле в блоках контента, которые вы и так уже пишете. Ограничение — это дисциплина в отношении стабильности префикса: ничего динамического перед маркером кэша. Если вы сможете держать ваш системный промпт, инструменты и любые статические примеры свободными от изменчивого контента, вы будете платить ~10% от обычной стоимости ввода на каждом попадании в кэш. Для высокочастотных агентов с большими стабильными промптами это более мощный рычаг, чем смена уровня модели. --- **Связанные материалы:** [Математика затрат на ИИ-агентов: когда Haiku обходит Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet/) · [Агенты по событиям против агентов по расписанию](/event-triggered-vs-scheduled-agents-which-pattern-for-which-job/) · [5 ИИ-инструментов, которые я реально использую для управления бизнесом](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/) --- ## Claude Fable 5: первые впечатления глазами оператора Source: https://alejandrorioja.com/ru/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 — самая способная модель Anthropic, и это видно на сложной, долгой агентной работе, но это не апгрейд по умолчанию. Она дороже за токен, использует новый токенизатор, который раздувает ваши счётчики токенов примерно на 30%, постоянно держит включённым thinking, который нельзя отключить, и может отклонять запросы на уровне классификатора. Для большинства задач Opus 4.8 по-прежнему верный выбор. Берите Fable 5, когда задача действительно трудная. ## Содержание _Обновлено в июне 2026 года._ **TL;DR:** Fable 5 — самая способная модель Anthropic, и это видно на сложной, долгой агентной работе, но это не апгрейд по умолчанию. Она дороже за токен, использует новый токенизатор, который раздувает ваши счётчики токенов примерно на 30%, постоянно держит включённым thinking, который нельзя отключить, и может отклонять запросы на уровне классификатора. Для большинства задач Opus 4.8 по-прежнему верный выбор. Берите Fable 5, когда задача действительно трудная. **[Взгляд оператора]** Я держу в проде больше 30 агентов — в консалтинговом бренде и на пиклбол-площадке, так что новая флагманская модель для меня не бенчмарк, а статья расходов и миграция. Вот что изменилось, когда я реально подключил Fable 5 к нескольким из них, и где я оставил Opus 4.8 на месте. ## Что такое Fable 5 на самом деле [Claude](/recommends/claude) Fable 5 — самая способная модель, которую Anthropic выпустила для широкого доступа. Она нацелена на требовательный край спектра: глубокие рассуждения и долгая агентная работа — те прогоны, где агенту нужно удерживать план на протяжении десятков вызовов инструментов, не теряя нить. Поверхность API почти идентична Opus 4.7/4.8, что упростило тестирование. Контекстное окно на 1M токенов по умолчанию, до 128K выходных токенов на запрос. Если вы что-то строили на недавней линейке Opus, форма запроса вам знакома. Различия — в деталях, а в деталях и кроются и деньги, и сюрпризы. Одна заметка по неймингу, чтобы вы не запутались: **Mythos 5** — это та же модель — те же возможности, та же цена, то же поведение — доступная только через программу Anthropic Project Glasswing. Если вы не в этой программе, нужная вам модель — это `claude-fable-5`. Всё, что ниже, относится к обеим. ## Где она действительно лучше Сначала я бросил в неё свою самую трудную агентную задачу: многошаговый прогон «исследование и синтез», который читает кучу источников, перепроверяет утверждения и пишет реферат со ссылками. Это та работа, где более слабые модели начинают дрейфовать — они теряют, какое утверждение из какого источника, где-то на десятом вызове инструмента. Fable 5 удержала нить. Синтез был плотнее, ссылки оставались привязаны к правильным утверждениям, и она поймала два противоречия между источниками, которые моя версия на Opus 4.8 тихо усредняла. На длинных, структурированных рассуждениях это реальный шаг вперёд — не маргинальный прирост в бенчмарке. Это честный аргумент в её пользу. Если режим отказа вашего агента — «разваливается на трудных 10%», Fable 5 сужает этот разрыв. Если ваш агент суммирует рассылки или набрасывает посты в соцсети, разницы вы не почувствуете — а платить будете за способности, которыми не пользуетесь. ## Ловушка со стоимостью, о которой никто не предупреждает Вот та, что укусит вас, если бегло пролистать релиз-ноуты. Fable 5 поставляется с **новым токенизатором**, и тот же контент токенизируется примерно в **на 30% больше токенов**, чем на линейке Opus. Перечитайте это, потому что эффект складывается с ценой. Fable 5 и так стоит выше уровня Opus ($10 за миллион входных токенов, $50 за миллион выходных). Теперь добавьте сверху раздувание токенов примерно на 30% к каждому промпту и завершению. Неизменная нагрузка — те же промпты, те же выходы — может стоить ощутимо дороже после миграции, ещё до того как вы поменяли хоть что-то в поведении агента. Так что не переиспользуйте старые цифры. Ваши настройки `max_tokens`, ваши бюджеты контекстного окна, ваши оценки стоимости за прогон — всё это измерялось на другом токенизаторе. Хорошая новость: эндпоинт подсчёта токенов возвращает счётчики по **обоим** токенизаторам, когда вы передаёте `model: "claude-fable-5"`, так что можно измерить дельту на ваших реальных промптах, прежде чем что-либо переключать. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` Я прогнал это сначала по своим самым тяжёлым промптам. Дельта не была однородной — она зависит от контента, — но «закладывай примерно на 30% больше, потом добавь ценовую надбавку» оказалось правильной ментальной моделью. ## Thinking всегда включён — и его нельзя выключить В Fable 5 адаптивный thinking работает постоянно. Единственное новое ломающее изменение по сравнению с линейкой Opus: если вы отправите явный `thinking: {type: "disabled"}`, вы получите 400. Лечится просто — просто полностью опустите параметр `thinking`, — но если у вас был код, который явно отключал thinking ради дешёвых, быстрых вызовов, этот код теперь падает с ошибкой. Сырую цепочку рассуждений вы тоже обратно не получаете. Fable 5 её защищает: вы получаете обычные блоки `thinking` и можете запросить читаемую сводку через `display: "summarized"`, но нефильтрованные рассуждения никогда не раскрываются. Для большинства приложений это не проблема — читайте сводку, если нужна видимость. Где это важно — так это в **многоходовых агентах**: когда вы продолжаете разговор на той же модели, блоки thinking надо передавать обратно **без изменений**. Уберёте их или отредактируете — и ход ломается. Если вы строите агентные циклы, относитесь к блокам thinking как к непрозрачным токенам, которые вы несёте дальше дословно. ## Отказы теперь — это задача потока управления Это изменение сильнее всего влияет на то, как вы пишете код вокруг модели. Fable 5 прогоняет классификаторы безопасности на входящих запросах, нацеленные в основном на исследовательскую биологию и большую часть кибербезопасного контента. Когда запрос отклоняется, вы получаете **успешный HTTP 200** со `stop_reason: "refusal"` — не ошибку, не исключение. Массив `content` может быть пустым. Если ваш код делает `response.content[0].text` без предварительной проверки `stop_reason`, он упадёт в тот день, когда запрос отклонят. А безобидная смежная работа — легитимный инструментарий по безопасности, задачи из наук о жизни — иногда может вызвать ложное срабатывание, так что это проблема не только для тех, кто занимается сомнительными вещами. Правило такое: **ветвитесь по `stop_reason`, никогда по `stop_details`.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` Для прода есть путь почище: серверный параметр `fallbacks` (в бете), который автоматически повторяет отклонённый запрос на `claude-opus-4-8` в том же раунд-трипе, с применением переоценки в кредитном стиле. Если вы гоняете агентов без присмотра, подключите это, чтобы единичный отказ по ложному срабатыванию не заводил весь прогон в тупик. Это тот же урок, который я раз за разом переусваиваю про агентов, которые [продолжают падать в проде](/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/): то, что модель становится умнее, не отменяет необходимости обрабатывать её краевые случаи — оно лишь сдвигает эти краевые случаи в другое место. ## Ещё две детали миграции Пара более мелких вещей, которые стоили времени мне, чтобы они не стоили его вам: - **Нет prefill ассистента.** Если вы направляли вывод, заполняя последний ход ассистента заранее, этого паттерна больше нет. Используйте структурированные выходы (`output_config.format`) или инструкции в системном промпте. - **Хранение данных 30 дней обязательно.** Fable 5 недоступна в режиме нулевого хранения данных. Если вы на ZDR по соображениям комплаенса, Fable 5 для вас закрыта, и вашим потолком остаётся Opus 4.8. Проверьте это *до* того, как планировать миграцию, а не после. ## Стоит ли вам реально переходить? Вот мой операторский вердикт после того, как я с ней пожил. **Fable 5 — это не цель по умолчанию для «апгрейда до новейшей модели»; это Opus 4.8.** Людей это удивляет, но это правильная рамка. Opus 4.8 — это смена ID модели с 4.7 без новых ломающих изменений, она дешевле, и для подавляющего большинства агентной работы она неотличима по качеству вывода. Fable 5 заслуживает своё место на действительно трудных задачах: долгие агенты, которым нужно оставаться связными на множестве шагов, глубокие рассуждения по многим источникам, прогоны, где отказ, который вы пытаетесь убить, тонкий. Для них способности реальны и стоят надбавки. Для всего остального — набросков контента, классификации, маршрутизации, суммирования — вы платите больше токенов по более высокой цене за качество, которое не способны воспринять. В итоге я стал гонять обе. Мой агент «исследование и синтез» переехал на Fable 5. Всё остальное осталось на Opus 4.8. В этом расщеплении и весь смысл: выбирайте модель под задачу, а не под моду. Если вы держите флот агентов, применима та же дисциплина, о которой я писал в [своём операторском стеке 2026 года](/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/): направляйте трудную работу к дорогой модели и перестаньте переплачивать за лёгкую. ## Операторский итог Протестируйте Fable 5 на своей единственной самой трудной задаче, прежде чем трогать что-либо ещё, — именно там она окупается, и если там она не сдвигает стрелку, то не сдвинет нигде. Прогоните счётчик токенов по своим реальным промптам, чтобы раздувание токенизатора примерно на 30% и ценовая надбавка не удивили вас в счёте. Добавьте проверку `stop_reason: "refusal"` (или серверный фолбэк на Opus 4.8) везде, где Fable 5 касается прода. А дальше маршрутизируйте осознанно: Fable 5 для трудных 10%, Opus 4.8 для остального. Лучшая модель — не самая способная, а та, что подобрана под задачу. --- ## Исчерпывающее руководство для начинающих по ИИ-агентам: Cowork, Codex и инструменты, которые действительно делают работу Source: https://alejandrorioja.com/ru/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: ИИ-агенты — это шаг вперёд по сравнению с чат-ботами: вы даёте им цель на обычном языке, и они выполняют работу — читают файлы, составляют черновики, организуют, пишут и запускают код. Cowork — это no-code-путь для тех, кто не пишет код; Codex и Claude Code — для тех, кто работает с кодовой базой. Важный навык — писать чёткое, хорошо сформулированное указание, а не учиться программировать. ## Table of contents _Обновлено июнь 2026 года._ **TL;DR:** ИИ-агенты — это шаг вперёд по сравнению с чат-ботами: вы даёте им цель на обычном языке, и они выполняют работу — читают файлы, составляют черновики, организуют, пишут и запускают код, проверяют свои результаты. **Cowork** — no-code-путь для нетехнических пользователей; **Codex** и **Claude Code** — для тех, кто работает с кодовой базой. Единственный важный навык — это умение писать чёткое, хорошо сформулированное указание, а не учиться программировать. **[Примечание автора]** Я ежедневно управляю более чем 30 кодированными агентами, но большинству людей не нужен код, чтобы получить 80% ценности. Им нужно чёткое задание и место для его выполнения. Это руководство — именно то введение, которое я бы дал умному другу, никогда не писавшему ни строчки кода. ## Что такое «ИИ-агент» на самом деле Чат-бот отвечает на вопросы. **Агент** выполняет задачи. Разница в том, что агент может совершать действия по кругу — прочитать документ, решить, что делать дальше, записать файл, выполнить команду, проверить результат, исправить ошибки — без вашего участия на каждом шагу. Конкретно: вы не спрашиваете «как мне привести в порядок эту таблицу?» Вы говорите: «вот таблица — удали дубликаты, исправь форматы дат и отметь строки с пустыми адресами электронной почты», — и агент делает это и возвращает вам готовый файл. Этот переход — от *совета* к *выполненной работе* — и есть суть дела. ## Два семейства инструментов В этот мир ведут две двери, и вам нужна только та, которая подходит к вашей работе. ### Дверь 1: No-code-агенты (начните здесь, если вы не пишете код) **Claude Cowork** — рабочее пространство, где вы даёте Claude цель плюс материалы — файлы, ссылки, заметки, — и он создаёт результат, который вы просматриваете и используете: черновик, резюме, план, очищенную таблицу. Вы пишете инструкции, а не код. Думайте об этом как об «очень способном помощнике, который быстро читает и никогда не устаёт», а не как о «программном инструменте». Это правильная отправная точка для маркетологов, основателей, операторов, авторов, аналитиков — всех, чья работа состоит преимущественно из документов, исследований и принятия решений. ### Дверь 2: Агенты для программирования (используйте их, как только в дело вступает кодовая база) **OpenAI Codex** и **Claude Code** — агенты, живущие там, где создаётся программное обеспечение: в терминале, в IDE или в облаке. Вы описываете изменение («добавь переключатель тёмного режима», «исправь этот падающий тест», «перенеси этот файл на новый API»), и агент редактирует код, запускает его и итерирует до тех пор, пока всё не заработает. Вы по-прежнему проверяете всё; агент занимается набором текста. Чтобы использовать их, не нужно быть опытным инженером. Многие непрограммисты используют агентов для программирования, чтобы запускать небольшие сайты, автоматизировать таблицы в виде скриптов и исправлять ошибки в инструментах, которые они не писали. Но кривая обучения реальна, поэтому большинству начинающих лучше начать с Двери 1 и перейти к Двери 2 только когда они столкнутся с задачей, которая действительно требует кода. ## Ваша первая победа (сделайте это сегодня) Выберите небольшую раздражающую задачу, которую вы часто выполняете. Хорошие первые кандидаты: - Превратить беспорядочную запись встречи в аккуратные заметки с перечнем пунктов действий. - Кратко изложить длинный PDF в 5 тезисах и 3 вопросах, которые стоит задать. - Переписать черновик письма, чтобы он был чётким, тёплым и не превышал 120 слов. Затем используйте структуру, которая делает агентов надёжными, а не непредсказуемыми — **роль → входные данные → точная инструкция → ограничение → проверка**: > Ты мой помощник. Вот [запись встречи / PDF / черновик письма], вставленный ниже. Сделай следующее: [преврати в аккуратные заметки с жирным списком «Пункты действий» / изложи в 5 тезисах + 3 уточняющих вопроса / перепиши так, чтобы текст был чётким, тёплым и не превышал 120 слов]. Сохрани мой стиль. Задай мне один вопрос, если что-то неясно, прежде чем начинать. > > [вставьте свой текст здесь] Всё. Вы только что делегировали задачу. Структура — это вся суть игры, и она работает одинаково — в Cowork, ChatGPT или в агенте для программирования. ## Четырёхчастный промпт, делающий агентов надёжными Новички думают, что секрет — в магической фразе. Нет. Секрет — в конкретности. Каждая надёжная инструкция для агента состоит из четырёх частей: 1. **Роль** — кем является агент для этой задачи («Ты мой исследовательский помощник»). 2. **Контекст** — материалы и *зачем* («Я готовлюсь к звонку по продажам с фаундером финтех-стартапа»). 3. **Задача** — точное, ограниченное действие («Найди три свежих факта о раундах финансирования и составь два вступительных вопроса»). 4. **Ограничения + проверка** — формат, объём, тон и инструкция спрашивать, а не угадывать («Только тезисы, указывай источники, задай мне один уточняющий вопрос, если название компании неоднозначно»). Расплывчато на входе — расплывчато на выходе. Чем больше агент может *делать*, тем важнее ваша точность — чат-бот, который неправильно понял, тратит одно предложение; агент, который неправильно понял, тратит вечер работы, который придётся переделывать. ## Ошибки новичков, которых стоит избегать - **Обращаться с ним как с поисковиком.** Не задавайте однострочные вопросы. Дайте ему настоящую работу с настоящими файлами. - **Пропускать ограничение.** «Напиши мне план» даст стену текста. «Напиши мне одностраничный план с тремя фазами и ответственным за каждую задачу» даст что-то пригодное к использованию. - **Не просить о проверке.** Добавьте «задай мне один вопрос, если что-то неясно» — и вы заметите недопонимание *до* того, как агент начнёт работу, а не после. - **Оставлять агентов для программирования без присмотра на важном коде.** Проверяйте diff. Агенты быстры и в основном правы, но «в основном» здесь несёт смысловую нагрузку — держите человека в петле при всём, что уходит в продакшн. - **Слишком рано переходить к Двери 2.** Если ваша задача — документы и решения, вам никогда не нужно открывать терминал. ## Как выбрать первый инструмент - **Ваша работа — документы, исследования и тексты** → начните с **Cowork** (или того чат-продукта, за который вы уже платите, используемого в режиме агента). - **Вы хотите создавать или исправлять программное обеспечение** → **Claude Code** или **OpenAI Codex**. - **Вы хотите регулярную работу в автономном режиме** (ежедневный дайджест, еженедельный отчёт) → переходите к **[запланированным задачам](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** после того, как освоите промпт вручную. ## ИИ-агенты для начинающих — FAQ 2026 ### Нужно ли мне уметь программировать, чтобы использовать ИИ-агентов? Нет. No-code-агенты вроде Claude Cowork созданы для нетехнических пользователей — вы пишете инструкции на обычном языке. Агенты для программирования вроде Codex и Claude Code требуют кривой обучения, но даже их всё чаще используют люди, не считающие себя программистами. Начните без кода, переходите к коду только когда задача этого требует. ### В чём разница между чат-ботом и ИИ-агентом? Чат-бот отвечает на вопросы; агент выполняет задачи. Агент может совершать последовательность действий — читать, решать, действовать, проверять, исправлять — по кругу, создавая готовую работу, а не советы. На практике один и тот же продукт часто делает и то, и другое; «режим агента» — это поведение агента. ### Cowork лучше, чем Codex? Они предназначены для разных задач, а не лучше или хуже. Cowork — no-code-рабочее пространство для документов, исследований и операций. Codex (и Claude Code) — агенты для программирования, создающие и исправляющие программное обеспечение. Выбирайте тот, который соответствует вашей задаче. ### Как получить хорошие результаты от ИИ-агента? Конкретность. Используйте четырёхчастную структуру: роль, контекст, точная задача и ограничения плюс проверка. Дайте ему настоящие материалы, укажите нужный формат и попросите отмечать неясности до начала работы. Чёткие инструкции важнее любого «магического промпта». ### Безопасно ли оставлять ИИ-агентов работать самостоятельно? Для низкорисковых, обратимых задач (составление черновиков, суммирование, организация) — да: проверьте результат и двигайтесь дальше. Для всего, что изменяет реальные системы (выпуск кода, отправка сообщений, удаление данных), держите человека в петле и проверяйте перед тем, как агент действует. Обратимость — правильный критерий: чем легче что-то отменить, тем больше автономии оно может безопасно иметь. **Связанные материалы:** [Как попасть в цитаты в ответах ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [Руководство по llms.txt](https://alejandrorioja.com/llms-txt-playbook/) · [Как использовать запланированные задачи Claude](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **Хотите помощи в применении агентов в вашем бизнесе?** Я создаю системы ИИ-агентов для операционных команд — [свяжитесь со мной](https://alejandrorioja.com/contact/) или прочитайте подробнее о [том, как я думаю об этом](https://alejandrorioja.com/seo-tips/). --- ## Как Anthropic зарабатывает деньги? Бизнес-модель Claude объясняется Source: https://alejandrorioja.com/ru/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic продаёт доступ к своим ИИ-моделям Claude по пяти основным каналам: API с оплатой по использованию (платите за токены), потребительские подписки (Claude Pro и Max), корпоративные планы (лицензии Team и Enterprise), Claude Code для разработчиков и дистрибуция через облачные маркетплейсы, такие как Amazon Bedrock и Google Vertex. API и корпоративный бизнес, а не потребительское приложение, являются главными источниками дохода. ## Table of contents _Обновлено июнь 2026._ **TL;DR:** Anthropic продаёт доступ к своим ИИ-моделям Claude по пяти основным каналам: **API с оплатой по использованию** (платите за токены), **потребительские подписки** (Claude Pro и Max), **корпоративные планы** (лицензии Team и Enterprise), **Claude Code** для разработчиков и **дистрибуция через облачные маркетплейсы**, такие как Amazon Bedrock и Google Vertex AI. API и корпоративный бизнес — а не потребительское чат-приложение — являются главными источниками дохода. **[Заметка оператора]** Я ежедневно работаю с API Anthropic, поэтому вижу бизнес изнутри. Главное, что нужно понять: Anthropic — это B2B-компания с потребительским фасадом. Чат-приложение, которым вы пользуетесь, — это маркетинг и одна из статей дохода; настоящие деньги — у разработчиков и компаний, которые измеряют токены через API и платят за лицензии в масштабе. ## Что такое Anthropic Anthropic — компания по исследованиям в области безопасности ИИ, основанная в 2021 году, которая разрабатывает семейство больших языковых моделей **Claude**. Она продаёт эти модели — и инструменты вокруг них — потребителям, разработчикам и предприятиям. Это частная компания, имеющая мощную поддержку стратегических инвесторов, включая Amazon и Google, которые также выступают партнёрами по облаку и дистрибуции. Продукт — это интеллект как услуга: вы не покупаете программное обеспечение в коробке, а арендуете доступ к модели, которая читает, пишет, рассуждает и действует от вашего имени. Каждый из перечисленных ниже каналов — это разная обёртка вокруг одного и того же основного актива. ## Как Anthropic зарабатывает деньги? ### 1. API (оплата по использованию, основной двигатель) Фундамент бизнеса. Разработчики и компании обращаются к Claude через API и платят **за токен** — примерно за каждый фрагмент текста на входе и выходе. Цена масштабируется в зависимости от возможностей модели: - **Claude Opus** (наиболее мощный уровень) стоит дороже всего — порядка нескольких долларов за миллион входных токенов и в несколько раз больше за выходные. - **Claude Sonnet** (сбалансированная рабочая лошадка) занимает средний уровень. - **Claude Haiku** (быстрый и дешёвый уровень) — самый доступный, для простых задач с большим объёмом. Выходные токены стоят дороже входных, а такие функции, как длинный контекст, кэширование промптов и пакетная обработка, имеют собственную тарификацию. Ключевая динамика: **доход масштабируется напрямую с использованием**. Стартап, который встраивает Claude в свой продукт и вырастает до миллионов пользователей, генерирует больше дохода от API каждый месяц без подписания нового контракта с Anthropic. Именно поэтому лаборатории ИИ говорят об «операционной выручке», растущей так быстро — она растёт вместе с собственным ростом клиентов. ### 2. Потребительские подписки (Claude Pro и Max) Приложения Claude (веб, десктоп, мобильные) можно попробовать бесплатно, с платными уровнями для тех, кто использует их интенсивно: - **Claude Pro** — фиксированная ежемесячная плата за более высокие лимиты использования, доступ к лучшим моделям и такие функции, как расширенный контекст и приоритетный доступ. - **Claude Max** — более дорогой уровень для опытных пользователей, которые достигают лимитов Pro, со значительно большим объёмом использования. Это самая заметная часть Anthropic, но для компании, клиентами которой в основном являются другие бизнесы, это меньший срез дохода, чем API и корпоративное направление. Его стратегическая ценность — это воронка и брендовая поверхность в той же мере, что и источник дохода. ### 3. Enterprise (лицензии Team и Enterprise) Именно здесь сосредоточена значительная часть стабильного дохода. Компании покупают Claude для своих сотрудников на основе **лицензии на пользователя**, с планами для организаций: - **Team** — для небольших компаний: общий пул использования, централизованная оплата, функции совместной работы. - **Enterprise** — для крупных организаций: более высокий уровень безопасности и соответствия требованиям, единый вход, более широкие контекстные окна, административный контроль и гарантии использования. Корпоративные сделки являются повторяющимися, расширяются со временем (больше лицензий, больше использования) и сопровождаются издержками переключения, которые делают доход стабильным. Это классическое SaaS-движение поверх модели. ### 4. Claude Code (инструменты для разработчиков) **Claude Code** — это агентный инструмент для написания кода от Anthropic — агент, который пишет, редактирует и выполняет код в вашем терминале, IDE или облаке. Монетизируется через те же рельсы подписки и использования (включён в уровни Pro/Max/Team/Enterprise и учитывается в вашем плане). Стратегически он выполняет две функции: является самостоятельной статьёй дохода и обеспечивает большое количество высокоценного использования токенов, поскольку агенты для написания кода потребляют значительную часть мощностей модели. ### 5. Дистрибуция через облачные маркетплейсы (AWS, Google и другие) Anthropic не только продаёт Claude напрямую — он также распространяется через крупные облачные платформы: - **Amazon Bedrock** и **Claude Platform on AWS** — клиенты, уже работающие на AWS, получают доступ к Claude через инфраструктуру и оплату Amazon. - **Google Vertex AI** и **Microsoft Foundry** — та же идея на Google Cloud и платформе Microsoft. Эти каналы встречают предприятия там, где уже сосредоточены их облачные расходы и закупки, что снижает барьер для внедрения Claude. Доход делится с платформой, но охват огромен — а глубокие инвестиции Amazon и Google делают эти партнёрства стратегическими, а не просто коммерческими. ### 6. Формирующаяся агентная платформа Всё чаще Anthropic продаёт не просто базовые вызовы модели, а **агентную инфраструктуру** — управляемые сервисы, где Anthropic запускает агентный цикл и размещает среду, в которой агенты выполняют задачи. По мере того как всё больше клиентов переходят от «задать модели вопрос» к «поручить агенту выполнить работу», этот уровень более высокого порядка становится новым местом для создания ценности поверх основы оплаты за токены. ## Прибыльна ли Anthropic? Anthropic — частная компания и не публикует аудированную финансовую отчётность, но публичная картина та же, что и у аналогов: **выручка растёт чрезвычайно быстро**, в то время как компания тратит огромные суммы на вычисления (обучение и обслуживание моделей) и исследовательские таланты. Как и другие передовые ИИ-лаборатории, она находится в фазе активных инвестиций, где рост верхней строки, а не текущая прибыль, является главным показателем. Ставка инвесторов заключается в том, что доход на основе использования продолжит расти по мере того, как ИИ встраивается во всё большее количество программного обеспечения, в конечном счёте превысив стоимость вычислений. ## Как это соотносится с OpenAI Структуры схожи — обе монетизируются через потребительские подписки, API с оплатой по использованию, корпоративные лицензии и инструменты для разработчиков. Различия в акцентах и партнёрствах: Anthropic делает ставку на API для разработчиков и предприятий и поддерживается Amazon и Google; OpenAI имеет более широкое присутствие среди потребителей и глубокое партнёрство с Microsoft. Если вы хотите увидеть другую сторону сравнения, посмотрите [как зарабатывает деньги OpenAI](https://alejandrorioja.com/how-does-openai-make-money/). ## Модель доходов Anthropic — FAQ 2026 ### Каков основной источник дохода Anthropic? **API с оплатой по использованию** и **корпоративные контракты** являются главными источниками. Разработчики и компании платят за токен для вызова Claude, а организации покупают планы с оплатой за пользователя для своих команд. Потребительская подписка Claude — самый заметный продукт, но меньшая часть дохода по сравнению с бизнес-направлениями. ### Как работает тарификация API Claude? Вы платите за токен — входные и выходные данные измеряются в фрагментах текста. Более мощные модели (Opus) стоят больше за токен, чем сбалансированные (Sonnet) или быстрые (Haiku) модели, а выходные токены стоят дороже входных. Такие функции, как длинный контекст, кэширование промптов и пакетная обработка, имеют собственную тарификацию. Доход масштабируется напрямую с объёмом использования моделей клиентами. ### Торгуется ли Anthropic на бирже? Нет. Anthropic — частная компания, поддерживаемая стратегическими и венчурными инвесторами, включая Amazon и Google. Её акции недоступны на публичных фондовых биржах, и подтверждённого IPO нет. ### Зарабатывает ли Anthropic на бесплатном приложении Claude? Не напрямую от бесплатных пользователей — бесплатный уровень является воронкой. Деньги поступают, когда бесплатные пользователи переходят на **Pro** или **Max**, когда команды покупают **корпоративные лицензии** и особенно когда разработчики работают на **API**. Задача бесплатного приложения — охват и брендинг; платные уровни и API — это то, где происходит конверсия. ### Кто является крупнейшими клиентами Anthropic? Прежде всего другие компании: программные компании, встраивающие Claude в свои продукты через API, и корпорации, разворачивающие Claude для своих сотрудников. Дистрибуция через облачные маркетплейсы AWS, Google и Microsoft также привлекает крупных корпоративных клиентов, которые покупают через своих существующих облачных провайдеров. **Дополнительное чтение:** [Как зарабатывает деньги OpenAI](https://alejandrorioja.com/how-does-openai-make-money/) · [Руководство для начинающих по ИИ-агентам](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Как попасть в цитаты ответов ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## Краткая версия Anthropic сдаёт в аренду доступ к своим моделям Claude. Разработчики платят за токен через API, потребители платят ежемесячно за Pro и Max, компании платят за лицензию за Team и Enterprise, инженеры используют Claude Code на тех же планах, а облачные гиганты (AWS, Google, Microsoft) перепродают Claude предприятиям через свои маркетплейсы. Это B2B-бизнес с потребительским фасадом — и счётчик, а не чат-приложение, — это то место, где находятся деньги. --- ## Как OpenAI зарабатывает деньги? Бизнес-модель ChatGPT и API Source: https://alejandrorioja.com/ru/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI зарабатывает четырьмя основными способами: подписки ChatGPT (Plus, Pro, Team, Enterprise, Edu), API с оплатой по токенам для разработчиков, крупные корпоративные контракты и партнёрство с Microsoft (дистрибуция плюс соглашение о разделе доходов). В отличие от большинства AI-лабораторий, бизнес потребительских подписок OpenAI — крупнейшая статья доходов: масштаб ChatGPT — это и есть двигатель. ## Table of contents _Обновлено в июне 2026 года._ **TL;DR:** OpenAI зарабатывает четырьмя основными способами: **подписки ChatGPT** (Plus, Pro, Team, Enterprise, Edu), **API с оплатой по токенам**, где разработчики платят за использование, крупные **корпоративные контракты** и **партнёрство с Microsoft** (дистрибуция плюс соглашение о разделе доходов). В отличие от большинства AI-лабораторий, бизнес потребительских подписок OpenAI — крупнейшая статья доходов: огромный масштаб ChatGPT — это и есть двигатель. **[Взгляд оператора]** OpenAI — это противоположность типичной корпоративной AI-компании: сначала был создан потребительский феномен, а уже затем — бизнес для разработчиков и предприятий. Сотни миллионов пользователей ChatGPT — это одновременно и бренд, и машина по генерированию прибыли. Все остальные игроки рынка мечтают о таком верхнем уровне воронки привлечения. ## Что такое OpenAI? OpenAI — это AI-исследовательская компания, создавшая **ChatGPT** и семейство моделей **GPT**, а также такие продукты, как видеомодель Sora, генерация изображений и агент-программист Codex. Основанная в 2015 году, она приобрела широкую известность после запуска ChatGPT в конце 2022 года, который стал одним из самых быстрорастущих потребительских продуктов в истории. Структура компании необычна: она начинала как некоммерческая организация и создала коммерческое подразделение с ограниченной прибылью, чтобы привлечь огромный капитал, необходимый для обучения моделей переднего края. Компания не является публичной и имеет глубокое многолетнее партнёрство с **Microsoft**, которое обеспечивает вычислительные мощности, дистрибуцию и капитал. Продукт, как и у любой AI-лаборатории, — это интеллект как услуга, продаваемый через потребительские, разработчические и корпоративные каналы. ## Как OpenAI зарабатывает деньги? ### 1. Подписки ChatGPT (крупнейшая статья доходов) Именно это отличает OpenAI от конкурентов. ChatGPT бесплатен, но есть платные уровни, которые конвертируют часть огромной пользовательской базы в регулярные доходы: - **ChatGPT Plus** — фиксированная ежемесячная плата за доступ к лучшим моделям, более высоким лимитам и премиум-функциям. Массовый рыночный уровень. - **ChatGPT Pro** — более дорогой уровень для опытных пользователей, желающих максимального использования и наиболее мощных настроек модели. - **ChatGPT Team** — поместные планы для малого бизнеса с общими рабочими пространствами и инструментами администрирования. - **ChatGPT Enterprise** — для крупных организаций: расширенная безопасность, соответствие требованиям, SSO, больший контекст и гарантии использования. - **ChatGPT Edu** — версия, адаптированная для университетов и школ. Поскольку ChatGPT охватывает сотни миллионов еженедельных пользователей, даже низкий однозначный процент конверсии в платные планы обеспечивает колоссальный подписочный бизнес. Этот потребительский масштаб — ключевое конкурентное преимущество OpenAI, и, по имеющимся данным, подписки являются крупнейшим источником доходов. ### 2. API (оплата по использованию, для разработчиков) Разработчики и компании встраивают модели OpenAI в свои продукты и платят **за токен** — за каждый фрагмент текста (или изображения, или аудио), который обрабатывается. Цены масштабируются в зависимости от возможностей модели: флагманские модели рассуждения стоят дороже за токен, чем меньшие, быстрые и дешёвые, а выходные данные оцениваются выше, чем входные. API превращает каждую компанию, строящую на GPT, в измеряемого клиента, чей счёт растёт вместе с его собственным использованием. Это та же динамика накопления, на которую полагается каждая AI-лаборатория: стартап, встроивший OpenAI и масштабировавшийся до миллионов пользователей, генерирует всё больше доходов от API каждый месяц без нового контракта. ### 3. Корпоративные контракты Помимо самостоятельного использования API и планов Team, OpenAI заключает крупные, индивидуальные сделки с большими компаниями — объёмное использование, выделенные мощности, персональная поддержка и обязательства по безопасности и соответствию требованиям. Они повторяются, расширяются со временем и становятся трудно заменимыми, когда компания строит критически важные рабочие процессы поверх моделей. Это корпоративное направление существует наряду с потребительским бизнесом и является важной областью роста. ### 4. Партнёрство с Microsoft Microsoft — крупнейший стратегический партнёр OpenAI. Отношения работают по нескольким осям: - **Вычислительные мощности** — облако Azure компании Microsoft обеспечивает большую часть инфраструктуры, на которой OpenAI обучает и обслуживает модели. - **Дистрибуция** — модели OpenAI предлагаются через платформы Microsoft (AI-сервисы Azure, продукты Copilot), ставя GPT перед гигантской корпоративной клиентской базой Microsoft. - **Разделение доходов** — две компании делят доходы согласно своему коммерческому соглашению, и Microsoft вложил значительные средства в OpenAI. Это партнёрство — частично капитал, частично выход на рынок: оно даёт OpenAI доступ к предприятиям, на прямую продажу которым ушли бы годы. ### 5. Новые и смежные продукты OpenAI продолжает расширять площадь, которую может монетизировать: - **Codex** — его агентный инструмент программирования, монетизируемый через подписки и использование API (и движок для интенсивного потребления токенов). - **Sora** — генерация видео, предлагаемая в платных уровнях и как самостоятельный продукт. - **Генерация изображений и другие модальности** — включены в подписки и измеряются через API. - **Экосистема разработчиков и агентов** — пользовательские GPT, платформа агентов и инструменты, позволяющие компаниям строить поверх моделей OpenAI. Каждый из них — ещё одна обёртка вокруг того же базового актива, направленная на захват большей доли того, что пользователи и разработчики готовы платить. ## Прибыльна ли OpenAI? OpenAI — частная компания и не публикует проверенных финансовых отчётов. Широко известная картина: **доходы очень велики и быстро растут**, но и затраты тоже — обучение моделей переднего края и обслуживание сотен миллионов пользователей потребляет поразительные объёмы вычислений. Как и конкуренты, OpenAI находится в фазе интенсивных инвестиций, где приоритет — рост и возможности, а не краткосрочная прибыль. Ставка в том, что масштаб плюс растущее корпоративное внедрение в конечном счёте превысит затраты на вычисления. ## Сравнение с Anthropic Строительные блоки схожи — потребительские подписки, API с оплатой по использованию, корпоративные сделки, инструменты программирования — но акценты разные. Определяющее преимущество OpenAI — **потребительский масштаб** (ChatGPT) и партнёрство с **Microsoft**; Anthropic делает больший упор на **API для разработчиков и корпораций** и поддерживается Amazon и Google. Для другой стороны сравнения смотрите [как зарабатывает Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/). ## Модель доходов OpenAI — FAQ 2026 ### Что является крупнейшим источником доходов OpenAI? **Подписки ChatGPT.** Поскольку ChatGPT охватывает сотни миллионов пользователей, его платные уровни (Plus, Pro, Team, Enterprise, Edu) составляют крупнейшую статью доходов OpenAI — необычный профиль для AI-лаборатории, большинство из которых зарабатывают больше на API и корпоративных клиентах, чем на потребителях. ### Как API OpenAI зарабатывает деньги? Разработчики платят **за токен** за использование моделей OpenAI в своих приложениях — за каждый фрагмент текста, изображения или аудио, который обрабатывается. Более мощные модели стоят дороже за токен, а выходные данные оцениваются выше входных. Доходы растут автоматически по мере роста собственного использования клиентов. ### Является ли OpenAI публичной компанией? Могу ли я купить акции OpenAI? Нет. OpenAI — частная компания, её акции не доступны на публичных биржах. Большинство людей не могут инвестировать напрямую. Microsoft владеет значительной долей через своё партнёрство, но это не то же самое, что публичное размещение OpenAI. ### Как партнёрство с Microsoft приносит OpenAI деньги? Microsoft предоставляет вычислительные мощности Azure, распространяет модели OpenAI через свои продукты и облако огромной корпоративной клиентской базе, и две компании делят доходы согласно своему коммерческому соглашению. Microsoft также вложил значительные средства в OpenAI. Это одновременно источник финансирования и канал дистрибуции. ### Зарабатывает ли OpenAI на бесплатных пользователях ChatGPT? Не напрямую — бесплатный уровень — это воронка. Доходы поступают, когда бесплатные пользователи переходят на **Plus** или **Pro**, когда компании покупают места **Team** или **Enterprise**, и когда разработчики строят на **API**. Роль бесплатного продукта — охват; платные уровни и API конвертируют его. **Дополнительное чтение:** [Как зарабатывает Anthropic](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Как зарабатывает SpaceX](https://alejandrorioja.com/how-does-spacex-make-money/) · [Руководство для начинающих по AI-агентам](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## Краткая версия OpenAI превращает огромную пользовательскую базу ChatGPT в доходы от подписок (Plus, Pro, Team, Enterprise), взимает с разработчиков плату за токен через свой API, заключает крупные корпоративные контракты и опирается на Microsoft в плане вычислений, дистрибуции и разделённых доходов. Его определяющая черта — потребительский масштаб: большинство AI-лабораторий монетизируют сначала разработчиков; OpenAI сначала создал потребительский феномен, а затем бизнес за ним. --- ## Как SpaceX зарабатывает деньги? Запуски, Starlink и вопрос об IPO Source: https://alejandrorioja.com/ru/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX зарабатывает тремя способами: услуги запуска (продажа мест на орбиту на многоразовых ракетах Falcon), Starlink (спутниковый интернет для потребителей, предприятий, морского/авиационного сектора и правительств) и государственные контракты (экипаж и грузы NASA, лунные посадочные модули, запуски в сфере национальной безопасности). Starlink теперь является крупнейшим источником дохода. SpaceX остаётся частной компанией; IPO самой SpaceX не предвидится в ближайшее время, хотя возможный выделенный IPO Starlink давно обсуждается. ## Table of contents _Обновлено в июне 2026 года._ **TL;DR:** SpaceX зарабатывает тремя способами: **услуги запуска** (продажа мест на орбиту на многоразовых ракетах Falcon), **Starlink** (спутниковый интернет для потребителей, предприятий, морского/авиационного сектора и правительств) и **государственные контракты** (экипаж и грузы NASA, лунные посадочные модули, запуски в сфере национальной безопасности). Starlink теперь является крупнейшим источником дохода. SpaceX остаётся частной компанией; IPO самой SpaceX не предвидится в ближайшее время, хотя возможный выделенный IPO Starlink давно обсуждается и неоднократно откладывался. **[Мнение оператора]** SpaceX — наглядный современный пример компании, которая использовала технологическое преимущество в области «жёсткого железа» (многоразовые ракеты), чтобы построить на его основе бизнес с экономикой программного обеспечения (спутниковый интернет). Запускной бизнес даёт право на существование; Starlink — это место, где находятся повторяющиеся, масштабируемые деньги. Вся история — в одном предложении. ## Что такое SpaceX SpaceX (Space Exploration Technologies Corp.) проектирует, создаёт и эксплуатирует ракеты и космические аппараты, а также управляет сетью спутникового интернета Starlink. Основанная в 2002 году с долгосрочной целью сделать человечество многопланетным видом, она стала доминирующим поставщиком пусковых услуг в мире, сделав то, чего никто другой не делал в таком масштабе: приземлила и повторно использовала первую ступень орбитальной ракеты, что обрушило стоимость доступа в космос. Это ценовое преимущество является двигателем всего остального. Дешёвые, частые, надёжные запуски — вот что делает созвездие из более чем 7000 спутников экономически возможным, а созвездие превращает неровный, проектный запускной бизнес в бизнес с повторяющимися доходами. ## Как SpaceX зарабатывает деньги? ### 1. Услуги запуска Исходный бизнес. SpaceX продаёт запуски трём типам клиентов: - **Коммерческие спутниковые операторы** — компании, которым нужна полезная нагрузка на орбите, платят за выделенный запуск или место на миссии **rideshare** (многие малые спутники на одной ракете, цена за килограмм). - **Правительство и военные** — полезные нагрузки для национальной безопасности и научные миссии, часто с премией за надёжность и гарантии. - **Другие космические компании** — включая, всё чаще, конкурентов, которые по-прежнему зависят от SpaceX, поскольку это самый дешёвый и доступный «рейс». Экономика единицы работает благодаря **многоразовости**: один и тот же ускоритель первой ступени летает много раз, поэтому предельная стоимость запуска намного ниже цены. Falcon 9 — это рабочая лошадка; Falcon Heavy берёт самые тяжёлые полезные нагрузки. ### 2. Starlink (машина повторяющихся доходов) Starlink — это созвездие тысяч спутников на низкой околоземной орбите, доставляющих высокоскоростной интернет в места, куда наземный широкополосный доступ не может добраться или не хочет обслуживать. Теперь это часть SpaceX, похожая на настоящий подписной бизнес, с несколькими уровнями: - **Потребительский** — домохозяйства платят за тарелку (оборудование) плюс ежемесячную подписку. - **Корпоративный и мобильный** — тарифы по более высокой цене для бизнеса, морского (суда, яхты) и **авиационного** (сделки по Wi-Fi на борту с авиакомпаниями) сектора. - **Правительственный** — включая **Starshield**, ориентированный на оборону вариант для военных и государственных клиентов. - **Прямая связь с мобильными устройствами** — партнёрства с мобильными операторами для обеспечения спутниковой связи непосредственно с обычными телефонами в зонах без покрытия. Starlink сочетает продажи оборудования (терминала) с ежемесячными повторяющимися доходами (подпиской) среди миллионов подписчиков — классическая форма «бритвы и лезвий» в планетарном масштабе. Именно поэтому большинство оценок теперь ставят Starlink впереди запусков как крупнейшую статью доходов SpaceX. ### 3. Государственные контракты Отдельный, очень крупный блок, который пересекается с запусками, но стоит рассматривать отдельно: - **NASA** — SpaceX доставляет астронавтов на Международную космическую станцию в рамках программы **Commercial Crew** (Crew Dragon) и снабжает её с помощью **Cargo Dragon**. Также выиграла контракт на создание лунной посадочной системы на базе **Starship** для лунных амбиций NASA. - **Национальная безопасность** — повторяющиеся контракты на запуски для оборонных и разведывательных полезных нагрузок. Эти контракты высокоценны, многолетние и финансируют большую часть разработок, которые приносят пользу коммерческому сектору. ### 4. Starship (двигатель будущего, пока не центр прибыли) Starship — полностью многоразовый сверхтяжёлый носитель SpaceX — долгосрочная замена Falcon и ключ к лунным/марсианским миссиям и к следующему, более крупному поколению спутников Starlink. Сегодня это центр затрат, финансируемый тремя другими направлениями бизнеса. Если он достигнет регулярных полётов, это снова резко снизит стоимость запусков и откроет возможности для значительно большего развёртывания Starlink — именно на это и делают ставку инвесторы. ## Прибыльна ли SpaceX? SpaceX является частной компанией и не публикует аудированную финансовую отчётность, поэтому любая точная цифра — это оценка. Широко распространённая картина: запуски прибыльны на уровне каждой миссии благодаря многоразовости, а Starlink перешёл в зону положительного денежного потока по мере роста базы подписчиков. Компания вкладывает огромные средства обратно в разработку Starship, поэтому «прибыль» во многом зависит от того, как трактовать эти расходы на НИОКР. Направление развития — растущие повторяющиеся доходы Starlink на фоне доминирующего запускного бизнеса — поддерживает огромную частную оценку компании. ## Вопрос об IPO Это та часть, о которой все спрашивают, так что вот честная версия. **Не ожидается, что SpaceX в ближайшее время проведёт IPO.** Илон Маск неоднократно заявлял, что предпочитает держать SpaceX частной, пока Starship и программа по Марсу капиталоёмки и ориентированы на долгосрочную перспективу — квартальное давление публичного рынка не подходит для многодесятилетней миссии. Вместо этого SpaceX обеспечивает ликвидность сотрудникам и ранним инвесторам через периодические **тендерные предложения** (компания облегчает продажу акций по установленной цене), что позволяет людям выходить в деньги без публичного листинга. Именно эти вторичные продажи формируют заголовочные цифры оценки — SpaceX оценивалась в сотни миллиардов долларов в последних раундах. **IPO выделенного Starlink давно обсуждается** — сам Маск несколько лет назад предполагал, что Starlink в конечном счёте может стать публичным, как только его доходы станут стабильными и предсказуемыми. Но он также неоднократно охлаждал ожидания относительно ближайших сроков. По состоянию на 2026 год Starlink не проводил IPO, и нет подтверждённой даты. Относитесь к любому заголовку «дата IPO Starlink» со скептицизмом, если он исходит не от самой компании. ## Итог Модель SpaceX — это стек: многоразовые запуски создают ценовой ров, этот ров делает Starlink экономически возможным, Starlink превращает всё в бизнес с повторяющимися доходами, а государственные контракты финансируют пионерную работу (Starship), которая снова сбрасывает кривую затрат. Компания остаётся частной по выбору, используя тендерные предложения вместо IPO — и наиболее вероятный путь на публичные рынки — это будущий листинг Starlink, а не SpaceX в целом, когда компания решит, что время пришло. ## Модель доходов SpaceX — FAQ 2026 ### Что является крупнейшим источником доходов SpaceX? Большинство оценок теперь ставят **Starlink** впереди услуг запуска как крупнейшую статью доходов SpaceX, обеспеченную миллионами подписок для потребителей, предприятий, мобильности и правительств, плюс продажами терминального оборудования. Услуги запуска по-прежнему велики и высокоприбыльны на уровне миссий, но повторяющаяся модель Starlink масштабируется быстрее. ### Торгуется ли SpaceX на бирже? Могу ли я купить акции SpaceX? Нет. SpaceX — частная компания, и её акции не доступны на публичных фондовых биржах. Большинство людей не могут инвестировать напрямую; доступ, как правило, ограничен сотрудниками и аккредитованными инвесторами, участвующими в частных раундах или тендерных предложениях. Остерегайтесь предложений «акций SpaceX», которые намекают на иное. ### Выйдут ли SpaceX или Starlink на IPO? Не ожидается, что SpaceX в ближайшее время станет публичной — Маск сказал, что хочет держать её частной в течение капиталоёмкой фазы Starship/Марс. IPO **Starlink** обсуждается годами как возможность, как только его доходы станут предсказуемыми, но по состоянию на 2026 год нет подтверждённой даты. К любому конкретному утверждению о «дате IPO» следует относиться скептически, если оно не исходит от компании. ### Как Starlink зарабатывает деньги? Starlink взимает с клиентов плату за спутниковую тарелку (оборудование) плюс ежемесячную подписку, по уровням для потребителей, бизнеса, морского, авиационного и государственного секторов — включая ориентированный на оборону Starshield и партнёрства с операторами прямой связи с мобильными устройствами. Это модель «бритвы и лезвий»: оборудование авансом, повторяющийся доход после. ### Как многоразовость помогает прибыли SpaceX? Посадка и повторный полёт одного и того же ракетного ускорителя много раз резко снижает предельную стоимость каждого запуска значительно ниже взимаемой цены. Это ценовое преимущество делает SpaceX самым дешёвым поставщиком пусковых услуг и делает развёртывание созвездия Starlink из нескольких тысяч спутников экономически жизнеспособным. **Похожие материалы:** [Как Uber зарабатывает деньги](https://alejandrorioja.com/how-does-uber-make-money/) · [Как Shopify зарабатывает деньги](https://alejandrorioja.com/how-shopify-makes-money/) · [Как PayPal зарабатывает деньги](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## Краткая версия SpaceX продаёт места на орбиту по низким ценам, потому что повторно использует свои ракеты, затем использует это ценовое преимущество для управления Starlink — подписным бизнесом спутникового интернета, который теперь является её крупнейшим источником дохода, — тогда как государственные контракты финансируют Starship следующего поколения. Компания намеренно остаётся частной; IPO Starlink, а не SpaceX, является наиболее вероятным путём на публичные рынки в конечном счёте. --- ## Как использовать запланированные задачи Claude: автоматизация повторяющейся работы с помощью cron Source: https://alejandrorioja.com/ru/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Запланированные задачи превращают разовый промпт Claude в повторяющуюся работу: она запускается по расписанию в стиле cron, выполняет работу и выдаёт результат. Используйте приложение Claude для личных повторяющихся промптов (утренний дайджест, еженедельная сводка) и рутины Claude Code или деплойменты Managed Agents для автоматизации разработки в облаке. Выгода заключается в автоматизации работы, которую иначе пришлось бы выполнять вручную каждый день или каждую неделю. ## Table of contents _Обновлено июнь 2026._ **TL;DR:** Запланированные задачи превращают разовый промпт Claude в повторяющуюся работу: она запускается по расписанию в стиле cron, выполняет работу и выдаёт результат. Используйте **приложение Claude** для личных повторяющихся промптов (утренний дайджест, еженедельная сводка) и **рутины Claude Code** или **деплойменты Managed Agents** для автоматизации разработки в облаке. Выгода заключается в автоматизации работы, которую иначе приходилось бы переделывать вручную каждый день или каждую неделю. **[Для операторов]** Самые рычажные автоматизации не выглядят эффектно — это небольшие повторяющиеся задачи, которые тихо пожирают по 20 минут в день. Запланированная задача — это способ передать их Claude один раз и больше никогда о них не думать. Я запускаю несколько: утренний скан конкурентов, ночная проверка статуса PR, еженедельный черновик контент-пайплайна. Ни одна не заняла больше десяти минут на настройку. ## Что такое запланированная задача Обычная сессия Claude синхронна: вы пишете, она отвечает, вы присутствуете. **Запланированная задача** — асинхронная и повторяющаяся: вы определяете промпт (или целый рабочий процесс агента) плюс расписание, и Claude выполняет его самостоятельно — в 7 утра каждый будний день, каждый понедельник, каждый час — и передаёт вам результат по завершении. Под капотом это cron-задача с LLM в центре. Вы не пишете код для склейки API; вы описываете результат на русском языке и позволяете агенту самому разбираться с шагами при каждом запуске. ## Три места, где вы будете их настраивать Нет одной кнопки — есть три поверхности, подходящие для разных профилей. ### 1. Приложение Claude (для всех) Потребительские приложения Claude поддерживают повторяющиеся задачи: вы сохраняете промпт и периодичность, Claude запускает его по расписанию и уведомляет вас с результатом. Это путь без кода — идеально для ежедневного брифинга, повторяющегося исследовательского запроса, работы «суммируй мои непрочитанные рассылки каждое утро». Если вы не разработчик, начните здесь. ### 2. Рутины Claude Code (для тех, кто живёт в терминале) Если вы используете **Claude Code**, вы можете запланировать промпт или слеш-команду для выполнения по cron-расписанию в качестве облачного агента — «рутины». Она работает на стороне сервера в вашем репозитории или рабочем пространстве, поэтому функционирует даже когда ноутбук закрыт. Типичное применение: следить за открытыми pull request'ами, запускать ночной проход lint-and-fix, каждое утро генерировать черновик поста для проверки. Вы определяете расписание и задачу; Claude Code управляет запуском и журналом выполнений. ### 3. Деплойменты Managed Agents (для разработчиков, создающих продукты) Для команд, работающих на Claude API, **запланированные деплойменты** запускают агента по повторяющемуся cron-расписанию — каждый запуск создаёт сессию, выполняющую работу автономно (ночное сканирование соответствия, еженедельный отчёт, почасовой мониторинг). Вы получаете журнал выполнения за каждый запуск для проверки успехов и сбоев. Это программная, production-уровневая версия той же идеи. ## Как думать о расписании Все три используют одну ментальную модель — **какая задача, как часто, что делать с результатом**: 1. **Задача** — напишите её так, как писали бы любой хороший промпт для агента: роль, контекст, точное действие, ограничения и проверка. Запланированная задача не может задать уточняющий вопрос в середине выполнения, поэтому она должна быть *полностью специфицирована заранее*. Это главное отличие от интерактивного использования. 2. **Периодичность** — ежедневно, еженедельно, ежечасно, только в будние дни, определённое время в вашем часовом поясе. Согласуйте её со скоростью, с которой реально меняется базовая вещь; «ежедневный» дайджест еженедельно обновляемого источника — это впустую потраченные запуски. 3. **Доставка** — куда попадает результат (уведомление, файл, сообщение, черновик). Решите это заранее, чтобы вывод был полезен в момент поступления. ## Паттерны, которые действительно себя оправдывают - **Утренний дайджест.** «Каждый будний день в 7 утра, собери последние новости по [темам], выдели три важных момента и пришли мне краткую сводку из 5 пунктов.» Заменяет 20 минут ручного мониторинга. - **Еженедельный отчёт.** «Каждый понедельник, составь [метрики] в одностраничную сводку с тем, что изменилось и почему.» Превращает повторяющуюся рутину в рецензию. - **Ночной работник.** Рутина кода, выполняющая долгую, хорошо специфицированную работу пока вы спите — рефакторинг, прогон тестов, очистка данных — чтобы вы проснулись с готовым к проверке результатом. - **Монитор.** «Каждый час, проверяй [вещь]; напиши мне только если [условие] истинно.» Лучшие автоматизации по большей части молчат и говорят только когда это важно. ## Советы по настройке из производственного использования - **Избыточно специфицируйте промпт.** Уточняющие вопросы в середине выполнения невозможны. Укажите формат, источники, ограничения и что делать в граничных случаях. - **Начните с ручного теста.** Запустите точный промпт один раз вручную. Если в интерактивном режиме он даёт желаемое, запланируйте. Если нет, сначала исправьте промпт — планирование плохого промпта лишь надёжно производит плохой вывод. - **Согласуйте периодичность со скоростью изменений.** Не запускайте ежечасно то, что обновляется еженедельно. - **Храните вывод как черновики при высоких ставках.** Для всего, что выходит во внешний мир — опубликованный пост, отправленное письмо — пусть задача производит *черновик* для вашей проверки, а не живое действие. Оставьте полностью автономное «просто сделай» для низкорискованной, обратимой работы. - **Следите за первыми запусками.** Запланированные задачи дрейфуют — источник меняет формат, фид замолкает. Проверяйте ранние журналы выполнения, потом доверяйте. ## Запланированные задачи Claude — FAQ 2026 ### Что такое запланированные задачи Claude? Это повторяющиеся задачи: вы определяете промпт или рабочий процесс агента плюс cron-расписание, и Claude выполняет его автоматически — ежедневно, еженедельно, ежечасно — доставляя результат без вашего присутствия у клавиатуры. Они существуют в потребительских приложениях Claude (для личных повторяющихся промптов), в Claude Code (как облачные рутины) и в Claude API (как деплойменты Managed Agents). ### Нужно ли быть разработчиком для их использования? Нет. Приложение Claude поддерживает повторяющиеся задачи без кода — только сохранённый промпт и периодичность. Рутины Claude Code и деплойменты Managed Agents — это версии для разработчиков для автоматизации рабочих процессов кода и продуктов. ### Чем запланированная задача отличается от обычного чата Claude? Обычный чат интерактивен — вы присутствуете, чтобы отвечать на уточняющие вопросы. Запланированная задача автономна и повторяется, поэтому промпт должен быть полностью специфицирован заранее; Claude не может сделать паузу, чтобы задать вам вопрос в середине выполнения. Она запускается по расписанию, завершает работу и передаёт вам результат. ### Что является хорошей первой запланированной задачей? Утренний дайджест. «Каждый будний день в 7 утра, суммируй последние новости по [вашим темам] в пяти пунктах.» Это низкорискованно, легко проверить и немедленно заменяет повторяющуюся ручную рутину — идеальный шаблон для изучения рабочего процесса перед автоматизацией чего-то большего. ### Может ли запланированная задача выполнять реальные действия, например отправлять письма? Да, но будьте осознанны. Для обратимой, низкорискованной работы позвольте ей действовать. Для всего, что направлено во внешний мир или трудно отменяется, пусть задача производит черновик для вашего одобрения, а не действует автоматически — особенно при выполнении без присмотра. Обратимость — правильный критерий для определения степени автономии. **Связанное чтение:** [Руководство для начинающих по ИИ-агентам](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Как Anthropic зарабатывает деньги](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Как попасть в цитаты ответов ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **Хотите систему запланированных агентов, управляющих вашей повторяющейся работой?** Именно это я и создаю — [свяжитесь со мной](https://alejandrorioja.com/contact/). --- ## Экономика затрат на ИИ-агентов: когда Haiku обходит Sonnet (а когда нет) Source: https://alejandrorioja.com/ru/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Выбор Claude Haiku вместо Sonnet способен резко снизить стоимость одного вызова, но только когда задача терпит более низкий процент успеха. Настоящая метрика — не стоимость за вызов, а стоимость за успешный результат, включая повторные попытки и ручную доработку. Я маршрутизирую по задаче, а не по умолчанию. ## Содержание _Обновлено в июне 2026._ **Кратко:** Выбор Claude Haiku вместо Sonnet способен снизить стоимость одного вызова на порядок, но только когда задача терпит более низкий процент успеха у Haiku. Значимая метрика — это **стоимость за успешный результат** — стоимость вызова плюс повторные попытки плюс ручная доработка, — а не ценник за токен. Я маршрутизирую по задаче, и заметная доля моих высокообъёмных шагов выполняется на Haiku, тогда как решения, требующие суждения, остаются на Sonnet. **Взгляд оператора:** Я веду более 100 агентов, и инференс — реальная статья расходов. Но я видел команды, которые «экономили», загоняя всё на самую дешёвую модель, а потом расплачивались повторными попытками, эскалациями и недовольными клиентами. Расчёт затрат работает только тогда, когда вы измеряете всю воронку. Самая дешёвая модель — не та, у которой ниже цена за токен. Это та, у которой ниже суммарная стоимость выполнить работу как надо. Это разные числа, и разрыв между ними — именно то место, где большинство решений о затратах на агентов даёт сбой. ## Экономика токенов, без обиняков Anthropic тарифицирует Claude за миллион токенов, причём ввод и вывод оплачиваются раздельно, а вывод стоит в несколько раз дороже ввода. Точные цифры меняются со временем, поэтому сверьтесь с актуальными ценами Anthropic — но решение определяет именно **структура**: - **Haiku** — дешёвый и быстрый уровень, с большим отрывом самая низкая стоимость за токен в семействе. - **Sonnet** — посередине: заметно дороже Haiku, заметно дешевле Opus. - **Opus** — премиальный уровень для самых сложных рассуждений. Отсюда следуют две вещи. Во-первых, в генеративных задачах стоимость определяют выходные токены, поэтому многословная модель обходится дороже даже при той же цене за токен. Во-вторых, разрыв в цене за токен между Haiku и Sonnet достаточно велик, чтобы на высокообъёмном шаге он непременно отразился в счёте. Это довод *за* Haiku. Теперь довод против. ## Метрика, которая действительно важна: стоимость за успешный результат Стоимость за вызов — показатель для тщеславия. Вот формула, которой я пользуюсь на самом деле: ``` стоимость_за_успех = (стоимость_вызова × попытки) + стоимость_доработки ÷ доля_успеха ``` Здесь `попытки` учитывают повторные попытки, а `стоимость_доработки` — ожидаемая стоимость того, что человек исправит просочившиеся сбои. Посмотрите, что это делает со сравнением. Допустим, Haiku обходится примерно в десятую часть стоимости Sonnet за вызов. Если на задаче Haiku успешен в 80% случаев, а Sonnet — в 98%, экономия за вызов выглядит огромной. Но если каждый сбой Haiku запускает одну повторную попытку и 1 из 10 всё ещё требует человека, который стоит реальных денег, член доработки может поглотить экономию на токенах. На малорисковой высокообъёмной задаче расчёт подавляюще в пользу Haiku. На задаче, где сбой отправляет письмо не тому клиенту, он может полностью перевернуться. Принять это решение нельзя, не измерив долю успеха у каждой модели — а это именно то, что даёт [стенд для оценок](/the-eval-harness-i-use-to-ship-ai-agents/). Прогоните один и тот же набор оценок на обеих моделях и считайте доли успеха по одной и той же мерке. ## Где Haiku побеждает безоговорочно Haiku — верный выбор, когда задача **узкая, структурированная и проверяемая**: - **Классификация и маршрутизация** — «это входящее сообщение — бронь, жалоба или спам?» Три корзины, легко проверить, выполняется постоянно. Haiku весь день. - **Извлечение по схеме** — вытащить из текста дату, имя, сумму, с валидацией через Zod. Если вывод парсится, он почти наверняка верен. - **Короткие переписывания и форматирование** — правка тона, резюмирование заведомо хорошего ввода, нормализация данных. - **Фильтрация первого прохода** — Haiku сортирует, и только неоднозначные случаи эскалируются на Sonnet. Это паттерн с наибольшим рычагом. Общая нить: цена ошибки Haiku низка, а саму ошибку дёшево поймать. Когда проверка дешева, а ставки низки, побеждает дешёвая модель. ## Где Sonnet отрабатывает свою цену Sonnet (а иногда и Opus) стоит того, когда задача **открытая, многошаговая или дорогая в случае ошибки**: - **Многоинструментальные циклы агента**, где один неверный вызов инструмента вызывает каскад. Более высокая надёжность рассуждений накапливается по шагам — паттерны оркестрации, которые я разбираю в [оркестрации мультиагентов](/multi-agent-orchestration-patterns-queues-state-handoffs/), держатся на том, что модель не теряет нить. - **Генерация, обращённая к клиенту**, где плохой вывод стоит доверия, а не просто одной повторной попытки. - **Всё, где проверка сама по себе сложна.** Если вы не можете дёшево определить, верен ли вывод, вы не можете позволить себе модель, которая часто ошибается. Сбой здесь стоит не одной повторной попытки — он стоит возврата денег, ушедшего клиента или моего времени. На этом фоне надбавка за токен — погрешность округления. ## Правило маршрутизации, которое я действительно внедряю Я не выбираю одну модель на агента. Я маршрутизирую по **задаче** внутри агента, обычно с дешёвым классификатором, решающим, какая нижестоящая модель возьмётся за работу: ```typescript function pickModel(task: Task): string { // Дёшево, проверяемо, высокий объём → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // Открытая задача или обращённая к клиенту → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // по умолчанию — безопасный выбор } ``` Здесь закодированы два принципа. **По умолчанию — безопасная модель**, а не дешёвая: вы оптимизируете стоимость *вниз* от работающей базовой линии, а не надёжность *вверх* от сломанной. И **эскалируйте, а не играйте в азартную игру**: пусть Haiku берёт лёгкие 80%, а трудные 20% передавайте Sonnet. Этот гибрид почти всегда обходит запуск всего на одной из двух моделей по отдельности. Сверху можно положить ещё и кэширование промптов: если системный промпт большой и переиспользуется, кэширование существенно снижает стоимость ввода независимо от уровня, что иногда делает Sonnet достаточно дешёвым, чтобы вопрос о Haiku вовсе отпал. ## Разобранный пример из моего собственного стека Возьмём высокообъёмный шаг сортировки входящих. Он выполняется тысячи раз, задача — трёхсторонняя классификация, а промах лишь означает, что элемент попадает в очередь на проверку — дёшево поймать, низкие ставки. Это хрестоматийная задача для Haiku, и перевод её с Sonnet ощутимо снизил стоимость этого шага без измеримого ущерба для результата, который имел значение. Теперь возьмём шаг, который составляет настоящий ответ клиенту. Меньший объём, открытая задача, а ушедший плохой черновик стоит доверия. Этот остаётся на Sonnet. Тот же агент, две модели, маршрутизация по ставкам. Я слежу за стоимостью на запуск и метриками успеха у обеих, как описываю в [как я измеряю, действительно ли работает ИИ-агент](/how-i-measure-whether-an-ai-agent-is-actually-working/) — и опускаю шаг на уровень ниже лишь после того, как оценка скажет, что более дешёвая модель удерживает долю успеха. ## Частые вопросы ### Всегда ли Claude Haiku дешевле Sonnet на практике? За токен — да, с большим отрывом. За успешный результат — не всегда. Если более низкая доля успеха Haiku запускает повторные попытки и ручную доработку, суммарная стоимость может превысить Sonnet на задачах, где ошибки дорого ловить или исправлять. ### Как выбрать между Haiku и Sonnet для конкретной задачи? Оцените задачу по двум осям: насколько проверяем вывод и насколько дорого обходится ошибка. Дешёвая в проверке, малорисковая, высокообъёмная работа идёт на Haiku; открытая, обращённая к клиенту или трудная для проверки — на Sonnet. Маршрутизируйте по задаче, а не по агенту. ### Какую единственную метрику затрат мне отслеживать? Стоимость за успешный результат — стоимость вызова, умноженная на попытки, плюс ожидаемая стоимость доработки, делённая на долю успеха. Одна лишь цена за вызов скрывает повторные попытки и человеческое время — а именно там дешёвые модели незаметно дорожают. ### Можно ли использовать обе модели в одном агенте? Да, и обычно так и стоит делать. Самый сильный паттерн — дешёвый первый проход (Haiku классифицирует или фильтрует), эскалирующий на Sonnet только неоднозначные случаи. Этот гибрид, как правило, обходит запуск всего на одном уровне. --- ## Как отлаживать ИИ-агента в продакшене (практическое руководство) Source: https://alejandrorioja.com/ru/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Отладка продакшен-агента ИИ — это в основном про изоляцию того, какой слой дал сбой: промпт, инструмент, модель или оркестрация. Я логирую каждый шаг с trace-ID, переигрываю те же самые входные данные и применяю бинарный поиск. В моих агентах ~70% 'багов ИИ' оказываются багами обвязки, а не модели. ## Содержание _Обновлено в июне 2026 года._ **TL;DR:** Отладка продакшен-агента ИИ — это в основном про изоляцию того, какой слой дал сбой: промпт, вызов инструмента, вывод модели или оркестрация. Я логирую каждый шаг с trace-ID, переигрываю те же самые входные данные и применяю бинарный поиск, отталкиваясь от этого. В моих агентах примерно 70% того, что выглядит как «баг ИИ», оказывается обвязкой: некорректно сформированный результат инструмента, обрезанный ввод, молча проглоченное исключение. **Взгляд оператора:** Я держу более 100 продакшен-агентов — потоки бронирования для Pickleland, контент-конвейеры, сортировщики входящих. Они ломаются так же, как ломается любое ПО, плюс несколькими новыми способами. Это то практическое руководство, которое я хотел бы иметь: как найти сбойный слой, не вглядываясь в стену из токенов. Когда агент ведёт себя неправильно в продакшене, инстинкт — обвинить модель. «Claude нагаллюцинировал». Иногда правда. Обычно нет. Модель — это один слой в стеке из пяти-шести, и баг куда чаще сидит в том слое, который написали вы, чем в том, что выпустила Anthropic. Этот пост — систематический способ, которым я его нахожу. ## Сделайте каждый запуск трассируемым прежде, чем что-либо отлаживать Нельзя отладить то, чего не видишь. Самое рычаговое, что вы можете сделать, — ещё до появления какого-либо конкретного бага — это прикрепить trace-ID к каждому запуску агента и логировать каждый его шаг. «Шаг» — это всё, что пересекает границу: входящий триггер, каждый вызов модели (с полным массивом сообщений), каждый вызов инструмента (с аргументами), каждый результат инструмента и финальный вывод. Логируйте их как структурированный JSON, ключом которого служит trace-ID. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` На Cloudflare Workers я отправляю их в очередь и в таблицу; локально они уходят в stdout. Правило абсолютно: если шаг не залогирован, то с точки зрения отладки его не было. Это отражает инструментирование, которое я описываю в [стеке агентов, который я использую](/the-agent-stack-i-use-to-run-30-production-agents-no-python/), — trace-ID это позвоночник, на котором держится всё остальное. ## Изолируйте слой: промпт, инструмент, модель или оркестрация Как только у вас есть трасса, отладка превращается в бинарный поиск. Слоёв четыре, и баг в большинстве случаев живёт ровно в одном из них. ### 1. Слой ввода (самый частый виновник) Вытащите тот самый массив `messages`, который пошёл в сбойный вызов модели. Не реконструкцию — буквальный payload из лога. Затем прочтите его так, как прочёл бы посторонний. Половина моих багов «модель проигнорировала инструкции» на самом деле такие: - Результат инструмента, вернувшийся как `"[object Object]"`, потому что что-то неправильно превратилось в строку. - Ввод, обрезанный посреди фразы, потому что он переполнил окно контекста, и наивный срез его разрубил. - Переменная, подставленная как `undefined`, тихо отравившая промпт. Если ввод неверный, модель безупречно сделала свою работу над мусором. Чините обвязку. ### 2. Слой инструментов Если ввод выглядит чистым, проверьте, не вернул ли инструмент ошибку, которую агент воспринял как успех. Классика: API возвращает `200` с телом `{ "error": "rate limited" }`, ваша обёртка инструмента не проверяет тело, и агент уверенно действует на основе сообщения об ошибке. Логируйте результаты инструментов в сыром виде и проверяйте их форму. ### 3. Слой модели Только исключив 1 и 2, я начинаю подозревать модель. Даже тогда «баг модели» обычно означает «мой промпт неоднозначен». Возьмите тот самый сбойный ввод, закиньте его в одноразовый скрипт против той же модели и температуры и посмотрите, воспроизводится ли. Если да, то исправление — это работа над промптом или [более строгий eval](/the-eval-harness-i-use-to-ship-ai-agents/), а не паническая смена модели. ### 4. Слой оркестрации Если отдельный шаг в изоляции в порядке, но многошаговый запуск падает, баг — в передаче: потерянное между шагами состояние, состояние гонки, повтор, заново выполнивший неидемпотентное действие. Это самые мерзкие, и их паттерны я разбираю в [паттернах оркестрации мультиагентов](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## Воспроизводите недетерминизм, а не боритесь с ним То, что делает агентов как будто неотлаживаемыми, — это недетерминизм: один и тот же ввод даёт разный вывод от запуска к запуску. Его можно укротить. Во-первых, **зафиксируйте то, что можете.** Установите `temperature: 0` на время отладки. Это не сделает Claude полностью детерминированным, но резко сузит разброс, так что вы сможете отличить настоящий баг от шума сэмплирования. Во-вторых, **прогоните это N раз.** Если сбой воспроизводится 1 раз из 20 запусков, прокрутите тот же самый ввод 50 раз и захватите каждый вывод. Теперь у вас есть выборка, а не байка. Баг, срабатывающий в 5% случаев, — настоящий баг; вам просто нужен объём, чтобы его увидеть. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # затем подсчитайте сбои grep -c '"status":"fail"' runs.jsonl ``` В-третьих, **сравните успешные и сбойные запуски.** При зафиксированной температуре и одинаковом вводе разница в выводе означает разницу во вводе, которую вы ещё не заметили: метку времени в промпте, меняющийся результат инструмента, изменившийся извлечённый документ. ## Постройте стенд воспроизведения, чтобы перестать отлаживать в продакшене Отладка через повторный запуск живого агента медленна и рискованна — он шлёт настоящие письма, бронирует настоящие корты. Вместо этого захватите трассу и переиграйте её офлайн. Стенд воспроизведения загружает залогированную трассу, реконструирует тот самый ввод для любого шага и заново прогоняет только этот шаг против модели. Поскольку вы залогировали полный массив `messages`, восходящая система вам вообще не нужна. Это превращает 10-минутный круг в продакшене в 2-секундный локальный цикл и является самым большим ускорением в моём рабочем процессе отладки. Хороший стенд воспроизведения также позволяет **мутировать и перезапускать**: измените одну строку системного промпта, переиграйте те же 50 сбойных трасс и посмотрите, сколько теперь проходит. Это мост от отладки к eval — как только у вас есть корпус сбойных трасс, у вас есть начало набора регрессионных тестов. ## Следите за метриками, которые действительно предсказывают поломки Некоторые сбои никогда не выбрасывают исключение. Агент работает, возвращает нечто правдоподобное и тихо делает не то. Чтобы ловить такие, вы следите за поведенческими метриками, а не только за частотой ошибок: - **Доля успешных вызовов инструментов** по каждому инструменту. Просадка здесь часто предшествует видимому сбою. - **Валидность схемы вывода** — какой % выводов парсится против ожидаемой структуры. Я валидирую каждый вывод с помощью Zod и поднимаю тревогу, когда валидность падает. - **Длина цикла** — среднее число шагов на запуск. Внезапный скачок обычно означает, что агент застрял в повторах. - **Стоимость на запуск** — вышедший из-под контроля цикл проявляется как скачок стоимости раньше, чем как жалоба. (Когда стоимость важна, стоит знать [математику Haiku против Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet).) Я отслеживаю их так же, как и всё остальное, — см. [как я измеряю, действительно ли ИИ-агент работает](/how-i-measure-whether-an-ai-agent-is-actually-working/). Метрика, ловящая тихий сбой, стоит десяти, ловящих громкие. ## Чек-лист сортировки за 5 минут Когда агент ломается, а время поджимает, я выполняю это по порядку: 1. **Получите trace-ID** сбойного запуска. 2. **Прочтите тот самый ввод** для сбойного шага. Хорошо ли он сформирован? (Решает здесь ~50% случаев.) 3. **Проверьте результаты инструментов** в этой трассе на ошибки, замаскированные под успех. 4. **Переиграйте шаг офлайн** при `temperature: 0`. Воспроизводится? 5. **Если воспроизводится,** это проблема промпта/модели — исправьте и перепрогоните корпус трасс. **Если нет,** это недетерминизм или баг состояния/оркестрации — прокрутите его 50×, чтобы охарактеризовать. Дисциплинированная изоляция каждый раз бьёт хитрый промптинг. Модель редко бывает проблемой; обычно ею является система вокруг неё. ## Часто задаваемые вопросы ### Как мне отладить ИИ-агента, который падает лишь иногда? Захватите тот самый ввод из залогированной трассы и переиграйте его 50+ раз при температуре 0. Перемежающиеся сбои — это настоящие баги с низкой частотой срабатывания; объём превращает байку в воспроизводимую выборку, которую можно сравнить и починить. ### Баг обычно в модели или в моём коде? В моих продакшен-агентах примерно 70% видимых «багов ИИ» — это обвязка: некорректно сформированные результаты инструментов, обрезанные вводы, проглоченные исключения или потерянное между шагами состояние. Исключите слои ввода и инструментов прежде, чем подозревать модель. ### Какой минимум логирования мне нужен, чтобы отлаживать агентов? Trace-ID на каждом запуске, плюс структурированные логи триггера, каждого вызова модели (полный массив сообщений), каждого вызова инструмента и его сырого результата, и финального вывода. Если шаг не залогирован, отладить его нельзя. ### Как перестать отлаживать против живого продакшена? Постройте стенд воспроизведения, который загружает залогированную трассу и заново выполняет любой отдельный шаг офлайн, используя захваченные входные данные. Он превращает медленный, рискованный продакшен-круг в быстрый локальный цикл и становится семенем вашего набора регрессионных тестов. --- ## Как Измерить, Действительно ли ИИ-поиск Приводит к Вам Трафик Source: https://alejandrorioja.com/ru/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: Большая часть трафика из ИИ-поиска проявляется как тонкий ручеёк переходов с chatgpt.com, perplexity.ai и claude.ai — но больший эффект тёмный: люди читают ответ ИИ и никогда не кликают. Я измеряю и то, и другое, используя рефереры для кликов и рост брендовых запросов для влияния. ## Содержание _Обновлено в июне 2026 года._ **Кратко:** Большая часть трафика из ИИ-поиска приходит как тонкий поток переходов с `chatgpt.com`, `perplexity.ai` и `claude.ai` — легко подсчитать, как только узнаешь, куда смотреть. Но больший эффект **тёмный**: люди читают ответ ИИ, впитывают ваш бренд и никогда не кликают. Я отслеживаю клики через сегменты реферера, а влияние — через рост брендовых запросов, сдвиги прямого трафика и мониторинг цитирований. Подсчёт одних только кликов сильно недооценивает ИИ-поиск. **Взгляд оператора:** Я веду контент-движок и ежедневно слежу за его аналитикой. У вопроса «приводит ли ИИ-поиск трафик?» есть досадный ответ: да, но большая часть ценности не появляется в вашем отчёте по сессиям. Вот как я измеряю ту часть, что появляется, и вывожу ту, что нет. Все хотят одно число — «сколько трафика приводит мне ChatGPT?». Честный ответ в том, что ИИ-поиск производит два очень разных эффекта, и вам нужны два разных измерения. Смешайте их — и вы либо запаникуете (клики выглядят крошечными), либо обманете себя (упустите реальное воздействие). ## Эффект 1: Прямые переходы — поддаются подсчёту и меньше, чем хотелось бы Когда кто-то кликает по цитированию внутри ChatGPT, Perplexity или ответа Claude, ваша аналитика фиксирует реферер. Это реальные, атрибутируемые сессии. В GA4 или любом инструменте аналитики постройте сегмент, который захватывает ИИ-движки: ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` Сохраните это как канал «ИИ-поиск» и наблюдайте за ним во времени. Несколько оговорок, на которых люди спотыкаются: - **Рефереры утекают.** Некоторые ИИ-поверхности срезают или искажают реферер, поэтому часть подлинных ИИ-кликов попадает вместо этого в «Прямой». Ваш подсчёт переходов — это нижняя граница, а не истина. - **Объём низкий относительно показов ответа.** ИИ-движки отвечают на вопрос прямо на странице; кликает только любопытное меньшинство. Горстка ежедневных переходов может соответствовать куда большему числу людей, увидевших вас процитированным. Так что сегмент переходов необходим, но недостаточен. Он говорит вам, что ИИ-поиск приводит *некоторый* трафик. Влияние он сильно недосчитывает. ## Эффект 2: Тёмное влияние — бóльшая и труднее различимая половина Настоящее действие происходит без кликов. Кто-то задаёт ChatGPT вопрос, ваш бренд появляется в ответе как рекомендованный источник, и человек никогда не кликает — он просто вас запоминает. Это проявляется позже как **брендовый запрос** или **прямой визит**, не атрибутированный ничему. Это та же динамика, что делала избранные сниппеты досадными для измерения, только усиленная. Тёмное влияние нельзя измерить напрямую, но его можно триангулировать: 1. **Объём брендовых запросов.** Отслеживайте запросы вашего имени/бренда в Google Search Console во времени. Если вас начинают цитировать ИИ-движки и ваши брендовые показы растут без соответствующей кампании, этот рост — отпечаток влияния ИИ. 2. **Тренд прямого трафика.** Устойчивый рост сессий «Прямой», не отслеживающий ни одну кампанию, часто отражает ИИ-переходы, лишённые своего реферера, плюс людей, набирающих вас напрямую после упоминания ИИ. 3. **Ассоциированные конверсии.** Посмотрите, появляются ли сессии ИИ-поиска, пусть и редкие, как *первое* касание в конверсионных путях. Канал, крошечный по последнему клику, может быть значимым по первому касанию. Ни одно из этого не является чистым числом. Вместе они говорят вам, движется ли тёмная половина. ## Отслеживайте цитирования, а не только клики Вот метрика, которая заботит меня больше всего в ИИ-поиске, и её вообще нет в вашей аналитике: **цитируют ли меня и по каким запросам?** Ведите список из 20–40 запросов, важных для вашего бизнеса, и прогоняйте их через ChatGPT, Perplexity и Claude по расписанию — еженедельно более чем достаточно. Записывайте для каждого запроса и движка: процитированы ли вы и на какой позиции? Это GEO-эквивалент отслеживания позиций, и это опережающий индикатор. Цитирования сдвигаются *раньше* нижестоящего трафика и роста бренда, поэтому именно здесь видно, срабатывает ли ваша [работа по GEO для локального бизнеса](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/). Я собрал небольшого агента, который выполняет эти проверки и логирует результаты — нечто тривиальное, как только у вас есть стек агентов. Если предпочитаете делать вручную, для начала вполне подойдёт таблица и еженедельный 30-минутный проход, либо используйте специализированный сервис проверки вроде [mentioned.at](https://mentioned.at), если не хотите создавать агента самостоятельно. Методология повторяет мой [тест цитирований ChatGPT против Google](/chatgpt-search-vs-google-50-term-test/), только выполняется непрерывно, а не однократно. ## Постройте дашборд: четыре числа, еженедельно Я не тону в метриках. Для ИИ-поиска я слежу за четырьмя вещами и пересматриваю их еженедельно: 1. **Сессии ИИ-переходов** — поддающиеся подсчёту клики из сегмента реферера. Тренд, а не абсолютное значение. 2. **Охват цитирований** — % моих отслеживаемых запросов, где меня цитируют по всем трём движкам. Опережающий индикатор. 3. **Показы брендовых запросов** — из Search Console, как прокси тёмного влияния. 4. **Конверсии из ИИ-источника** — пусть и небольшие, начинают ли когда-либо ИИ-сессии конверсионный путь. Если охват цитирований растёт, а сессии переходов остаются плоскими, это *не* провал — обычно это означает, что тёмная половина растёт и число брендовых запросов должно за ней последовать. Если охват цитирований падает, это раннее предупреждение, на которое надо реагировать прежде, чем сдвинется любое число трафика. Это та же дисциплина «измеряй опережающий индикатор», которую я применяю к агентам в [как я измеряю, действительно ли ИИ-агент работает](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Что делать с числами Измерение полезно только если оно меняет то, что вы делаете. Сценарий действий: - **Низкий охват цитирований по важному для вас запросу?** Это проблема контента + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). Страница либо не существует, либо не структурирована для извлечения, либо недостаточно авторитетна, чтобы попасть в ответ. - **Цитируют, но нет реферального трафика?** Ожидаемо и нормально — ИИ-поиск делает работу для бренда, а не для кликов. Не «чините» это, гоняясь за кликами; делайте ставку на то, чтобы быть цитируемым источником. - **Переходы с одного движка, но не с других?** Движки сильно расходятся в источниках (я измерил ~40% пересечения между ChatGPT и Google). Быть процитированным одним не даёт вам остальных — работайте над охватом каждого движка отдельно. ## Замечание о честности атрибуции Сопротивляйтесь желанию заявлять точность, которой у вас нет. Измерение ИИ-поиска в 2026 году — это триангуляция, а не атрибуция. Любой, кто продаёт вам чистое число вроде «ChatGPT принёс вам X долларов», преувеличивает то, что познаваемо, потому что рефереры утекают, а самый большой эффект по своей природе без кликов. Правильная позиция: считайте то, что можете посчитать, наблюдайте за прокси для того, что не можете, и принимайте решения по тренду. Тренд заслуживает доверия, даже когда абсолютное число — нет. ## Часто задаваемые вопросы ### Как увидеть трафик от ChatGPT или Perplexity в GA4? Постройте канал/сегмент, сопоставляющий домены ИИ-движков — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — как источник сессии. Это захватывает переходы по кликам, хотя некоторые срезаются в «Прямой», поэтому считайте число нижней границей. ### Почему мой реферальный трафик из ИИ-поиска такой низкий? Потому что ИИ-поиск преимущественно без кликов — движок отвечает на странице, и только меньшинство кликает дальше. Низкие подсчёты переходов часто совпадают с гораздо бóльшими показами цитирований. Измеряйте цитирования и рост брендовых запросов, чтобы увидеть ту часть, которую переходы упускают. ### Какой лучший опережающий индикатор для ИИ-поиска? Охват цитирований: процент ваших отслеживаемых критичных для бизнеса запросов, где вас цитируют по ChatGPT, Perplexity и Claude. Он сдвигается раньше трафика и роста бренда, поэтому рано говорит вам, срабатывает ли ваша работа по GEO. ### Могу ли я получить точную атрибуцию дохода из ИИ-поиска? Нет, не надёжно в 2026 году. Рефереры утекают в «Прямой», и бóльшая часть воздействия по своей природе без кликов. Относитесь к измерению ИИ-поиска как к триангуляции — считайте клики, наблюдайте за прокси брендовых запросов и прямого трафика и принимайте решения по тренду, а не по ложно-точной долларовой цифре. --- ## Паттерны оркестрации мультиагентных систем: очереди, состояние и передачи Source: https://alejandrorioja.com/ru/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Надёжные мультиагентные системы держатся не на хитрых промптах, а на скучной дисциплине распределённых систем: долговечные очереди между агентами, состояние вне модели и идемпотентные передачи, переживающие повторы. Модель — это работник; очередь — это хребет. ## Содержание _Обновлено в июне 2026 года._ **Кратко:** Надёжные мультиагентные системы выигрываются не хитрыми промптами, а скучной дисциплиной распределённых систем. Поставьте между агентами долговечную **очередь**, держите **состояние вне модели** и сделайте каждую **передачу идемпотентной**, чтобы повтор не мог сработать дважды. Модель — это работник; очередь — это хребет. Сделайте эти три вещи правильно, и оркестрация перестанет быть страшной. **Взгляд оператора:** Большинство из моих 100+ агентов — одношаговые. Те, что не такие, — конвейеры, которые классифицируют, затем обогащают, затем действуют, — стали надёжными лишь тогда, когда я перестал думать «цепочка промптов» и начал думать «очередь задач с LLM-работниками». Это архитектура, а не промпт-инжиниринг. «Мультиагентность» звучит так, будто агенты разговаривают друг с другом. На практике надёжная версия — противоположная: агенты вообще не общаются напрямую. Они кладут сообщения в очередь и забирают работу из очереди, а оркестрация живёт в трубопроводе между ними. Вот паттерны, которые держатся в продакшене. ## Паттерн 1: ставьте долговечную очередь между каждым агентом Первый порыв — вызвать агента B прямо изнутри агента A. Не делайте этого. Прямые вызовы связывают двоих: если B медленный, A блокируется; если B падает, работа A теряется; если нужно масштабировать B, не получится без касания A. Вместо этого A завершает свою работу и **ставит сообщение в очередь** для B. B — отдельный работник, который опустошает очередь в собственном темпе. ```typescript // Агент A закончил и передаёт через очередь — без прямого вызова B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // Задача A выполнена. B заберёт это независимо. ``` В Cloudflare я использую Workers Queues именно для этого — те же примитивы, что стоят за [стеком агентов, который я использую](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). Очередь даёт вам четыре вещи бесплатно: **буферизацию** (B может лежать, не теряя работу), **повторы** (неудавшиеся сообщения доставляются заново), **обратное давление** (всплеск встаёт в очередь, а не роняет систему) и **развязку** (масштабируйте или передеплойте B, не касаясь A). Каждая из них — то, что иначе пришлось бы строить вручную и сделать неправильно. ## Паттерн 2: держите состояние вне модели, всегда Самый частый мультиагентный баг — предполагать, что модель что-то помнит между шагами. Не помнит. Каждый вызов модели не имеет состояния; единственная память — то, что вы кладёте в промпт. Поэтому источник истины для «где эта задача в конвейере» должен жить в базе данных, а не в разговоре. Я держу одну запись задачи, которую каждый агент читает и обновляет: ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` Каждый агент выполняет один и тот же цикл: **прочитать** состояние задачи, сделать свою работу, **записать** новое состояние, поставить следующий этап в очередь. Модель никогда не держит состояние — она получает релевантный срез как вход и возвращает результат. Именно это делает систему перезапускаемой: если работник умирает посреди задачи, запись состояния по-прежнему точно говорит, где всё стояло, а повторно доставленное сообщение очереди подхватывает оттуда. Это также делает отладку управляемой, потому что таблица состояния — это запрашиваемый журнал пути каждой задачи — тот же настрой на измеримость, что в [том, как я измеряю, работает ли агент на самом деле](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Паттерн 3: делайте каждую передачу идемпотентной Очереди гарантируют доставку *хотя бы один раз*, а не ровно один раз. Это значит, что сообщение может быть доставлено дважды — сбои сети, повторы, передеплои. Если действие вашего агента не идемпотентно, двойная доставка действует дважды: два письма-подтверждения, две брони, два списания. Это самый мерзкий класс багов оркестрации, и именно его команды обнаруживают в продакшене. Решение — сделать действия идемпотентными с помощью ключа: ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // Уже обработано дальше этого этапа — это дубликат доставки. Пропустить. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` Проверка этапа делает операцию безопасной для двойного выполнения: вторая доставка видит, что задача уже продвинулась, и ничего не делает. Для внешних побочных эффектов (отправить письмо, списать с карты) передавайте ключ идемпотентности в нижестоящий API, чтобы *он* тоже дедуплицировал. Считайте, что каждое сообщение будет доставлено дважды, и проектируйте так, чтобы это было безвредно — потому что рано или поздно так и случится. ## Паттерн 4: оркестратор против хореографии — выбирайте осознанно Есть два способа связать поток, и правильный выбор зависит от сложности. **Хореография** (то, что я выбираю по умолчанию): каждый агент знает только следующий шаг и ставит его в очередь. Поток возникает из цепочки. Просто, децентрализованно, легко расширять — добавьте этап, вставив очередь. Недостаток в том, что нет единого места, описывающего весь поток, поэтому сложный конвейер может стать трудным для осмысления. **Оркестрация** (центральный координатор): один оркестратор владеет потоком, по очереди вызывает каждого агента и решает, что дальше, на основе результатов. Весь поток живёт в одном читаемом месте, а логика ветвления явная. Цена — центральный компонент, который сам должен быть долговечным: если собственное состояние оркестратора не вынесено наружу (Паттерн 2), он становится единой точкой отказа. Моё правило: **хореография, пока ветвление не станет сложным, затем долговечный оркестратор.** Линейный трёхэтапный конвейер — это хореография. Поток с условной маршрутизацией, параллельным fan-out и объединениями требует оркестратора, чьё состояние живёт в базе данных, чтобы он мог возобновиться после сбоя. ## Паттерн 5: fan-out, fan-in без потери кусочков Когда одна задача порождает N параллельных подзадач (обогатить 50 записей, обобщить 20 документов), и нужно дождаться их всех перед продолжением, вам нужно **объединение** (join). Хитрость — счётчик в состоянии задачи: 1. Родитель ставит в очередь N дочерних сообщений и пишет `expected: N, completed: 0` в запись задачи. 2. Каждый потомок делает свою работу и **атомарно инкрементирует** `completed`. 3. Потомок, доводящий `completed` до равенства с `expected`, ставит в очередь следующий этап. Атомарный инкремент несущий — без него два потомка, заканчивающие одновременно, могут оба решить, что они не последние, и объединение никогда не сработает. Используйте счётчик, который хранилище может инкрементировать атомарно, или транзакцию. Этот паттерн позволяет распараллелить дорогую середину конвейера (часто дешёвую для Haiku работу — см. [расчёт стоимости Haiku против Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)), сохраняя чистое объединение в конце. ## Что бы я пропустил Вам не нужен тяжеловесный фреймворк агентов, чтобы делать что-либо из этого. Очереди, таблица состояния и ключи идемпотентности — это примитивы, которые уже есть у каждой платформы. Я видел, как команды тянутся к замысловатым мультиагентным фреймворкам, чтобы получить функции, которые очередь даёт бесплатно, и наследуют чёрный ящик, который сложнее отлаживать, чем трубопровод, который он заменил. Начните со скучных примитивов. Тянитесь к фреймворку только тогда, когда ощутите конкретную боль, которую он решает. Резюме: агенты — это работники без состояния, очереди — долговечный хребет, состояние живёт в базе данных, и каждая передача безопасна для двойного выполнения. Вот и вся игра. ## Часто задаваемые вопросы ### Должны ли агенты вызывать друг друга напрямую или идти через очередь? Через очередь. Прямые вызовы связывают агентов — сбой или медлительность одного распространяется на другого, и вы не можете независимо масштабировать или передеплоивать. Долговечная очередь даёт вам буферизацию, повторы, обратное давление и развязку бесплатно. ### Где должно жить мультиагентное состояние? Вне модели, в базе данных, как запись задачи, которую каждый агент читает и обновляет. Вызовы модели не имеют состояния, поэтому источник истины для прогресса конвейера должен быть внешним — именно это делает систему перезапускаемой после сбоя. ### Как помешать агенту сработать дважды по одной и той же задаче? Сделайте передачи идемпотентными. Проверяйте этап задачи перед действием и ничего не делайте, если она уже продвинулась, и передавайте ключи идемпотентности во внешние API. Очереди доставляют хотя бы один раз, поэтому считайте, что каждое сообщение может прийти дважды, и проектируйте так, чтобы дубликаты были безвредны. ### Нужен ли мне мультиагентный фреймворк? Обычно нет. Долговечные очереди, таблица состояния и ключи идемпотентности покрывают большинство продакшен-нужд примитивами, которые ваша платформа уже предоставляет. Принимайте фреймворк только тогда, когда столкнётесь с конкретной проблемой, которую он решает уникально, а не по умолчанию. --- ## Стенд оценки, с которым я выкатываю ИИ-агентов без страха Source: https://alejandrorioja.com/ru/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Выкатывать агентов без страха помогает одна вещь: стенд оценки. Фиксированный набор размеченных тестовых случаев, оцениваемый автоматически (ассерции плюс LLM-судья), запускаемый перед каждым изменением промпта или модели. Если оценка держится — выкатывай. Тестовый набор строится из реальных продакшен-сбоев. ## Содержание _Обновлено в июне 2026 года._ **Кратко:** Причина, по которой я могу изменить промпт или поменять модель на работающем агенте, не затаив дыхание, — одна вещь: **стенд оценки**. Фиксированный набор размеченных тестовых случаев, оцениваемый автоматически — жёсткие ассерции там, где я могу их написать, LLM-судья там, где не могу, — запускаемый перед каждым изменением. Оценка держится — я выкатываю. Оценка падает — нет. Тестовый набор не синтетический; он строится из реальных продакшен-сбоев, так что каждый баг становится постоянным регрессионным тестом. **Взгляд оператора:** На более чем 100 агентах разница между теми, к которым я прикасаюсь уверенно, и теми, которых я боюсь, — в том, есть ли у них оценки. Отсутствие стенда оценки означает, что каждая правка промпта — это азартная игра. Стенд оценки превращает «думаю, так лучше» в «это измеримо лучше на 4 балла и ничего не сломало». В этом вся разблокировка. Вы не стали бы выкатывать код без тестов. Люди же постоянно выкатывают агентов без оценок, а потом недоумевают, почему «крошечная правка промпта» сломала продакшен. Стенд оценки — это набор тестов для недетерминированного ПО. Вот тот, который я действительно запускаю. ## Начните с тестового набора, построенного из реальных сбоев Стенд хорош ровно настолько, насколько хороши его тестовые случаи, а лучшие тестовые случаи приходят из продакшена, а не из вашего воображения. Каждый раз, когда агент даёт сбой в реальной работе, я фиксирую точный ввод (я логирую каждый прогон с трейс-идентификатором — см. [как отлаживать агента в продакшене](/how-to-debug-an-ai-agent-in-production)) и превращаю его в случай оценки: ```typescript interface EvalCase { id: string; input: AgentInput; // точный продакшен-ввод expected?: string; // эталон, когда он есть assertions: Assertion[]; // жёсткие проверки, которые должны пройти rubric?: string; // для LLM-судьи, когда вывод открытый } ``` Здесь важны две практики. **Берите из продакшена**, чтобы ваши оценки проверяли то, что действительно ломается, а не то, что вы предположили. И **охватывайте весь разброс** — счастливый путь, краевые случаи, состязательные вводы и пустые/искажённые вводы, вызывающие тихие сбои. Тестовый набор из 30–50 хорошо подобранных случаев ловит куда больше, чем 500 ленивых. Я предпочту 40 случаев, каждый из которых представляет реальный режим отказа, тысяче, которые все проверяют один и тот же лёгкий путь. ## Оценивайте сначала ассерциями, затем LLM-судьёй Не каждому выводу нужна модель для оценки. Я тянусь к самому дешёвому оценщику, который работает. **Жёсткие ассерции** для всего структурированного. Парсится ли вывод как валидный JSON? Содержит ли он обязательное поле? Попадает ли извлечённая дата в диапазон? Вызвал ли он правильный инструмент с правильными аргументами? Они детерминированы, бесплатны и однозначны — пишите их столько, сколько сможете. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **LLM-судья** для всего открытого остального — тон, полезность, «действительно ли это ответило на вопрос». Здесь вы даёте модели ввод, вывод и рубрику и просите её оценить. Два правила держат судью честным: сделайте рубрику **конкретной** (шкала от 1 до 5 с описанными опорными точками бьёт «оцените качество»), и используйте **сильную модель в роли судьи** — суждение есть задача рассуждения, поэтому это место, где я с радостью плачу за Sonnet, даже когда сам агент работает на Haiku согласно [математике затрат](/ai-agent-cost-math-when-haiku-beats-sonnet). Размытая рубрика или слабый судья дают вам шум, похожий на сигнал. ## Запускайте стенд перед каждым изменением Стенд существует, чтобы ответить на один вопрос: *сделало ли это изменение агента лучше или хуже?* Поэтому я запускаю его перед каждой правкой промпта, заменой модели или изменением инструмента. ```bash # базовая линия на main npm run eval -- --suite=booking-agent > baseline.json # внесите изменение, затем перезапустите npm run eval -- --suite=booking-agent > candidate.json # сравните npm run eval:diff baseline.json candidate.json ``` Дифф показывает агрегированную оценку, прохождение/провал по каждому случаю и — что критично — **какие именно случаи регрессировали.** Агрегат, который ползёт вверх, пока три случая тихо ломаются, — это не улучшение; это компромисс, который я хочу видеть и одобрить, а не тот, что проскальзывает незаметно. Следить за диффом по случаям — вот как вы избегаете «починил одно, сломал два других», того режима отказа, из-за которого люди боятся собственных промптов. ## Поставьте шлюз регрессии и дайте ему блокировать Как только вы доверяете стенду, встройте его как шлюз в путь к продакшену. Моё правило прямолинейно: **изменение, опускающее оценку ниже порога базовой линии, не выкатывается.** Не «посмотрю позже» — оно заблокировано, как провалившийся CI-тест. ```typescript const PASS_THRESHOLD = 0.90; // 90% случаев должны пройти if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` Именно это превращает оценки из приятного дополнения в то, что позволяет двигаться быстро. Шлюз делает «выкатывать без страха» буквально истинным: худший случай для плохого изменения — красный прогон оценки, а не инцидент в продакшене. И поскольку тестовый набор растёт каждый раз, когда что-то ломается, шлюз сам со временем становится строже и защищённее. ## Учитывайте недетерминизм при оценке Тонкость, на которой спотыкаются: один и тот же ввод может получить разную оценку в разных прогонах, потому что модель сэмплирует по-разному. Если запускать каждый случай один раз, вы увидите фантомные регрессии — случай, который «сломался», на деле просто шум сэмплирования. Два средства. Запускайте оценки при **`temperature: 0`**, чтобы сократить дисперсию (полностью её это не уберёт). А для случаев, которые мерцают, **запускайте их N раз и берите долю прохождений**, а не единичное прохождение/провал. Случай, проходящий 9 из 10, в лучшей форме, чем тот, что проходит 5 из 10, даже если оба могут показать зелёный единичный прогон. Это тот же принцип «объём важнее анекдота», который я применяю при [отладке перемежающихся сбоев](/how-to-debug-an-ai-agent-in-production) — один прогон — это мнение, пятьдесят прогонов — это данные. ## Замкните цикл мониторингом продакшена Стенд оценки проверяет против известных случаев. Продакшен подбрасывает новые. Поэтому цикл таков: мониторьте живое поведение, ловите новый режим отказа, превращайте его в случай оценки, чините — и теперь он под постоянной защитой. Сторона мониторинга — отслеживание доли успеха, валидности вывода и стоимости за прогон на живом трафике — это то, что я разбираю в [как я измеряю, действительно ли ИИ-агент работает](/how-i-measure-whether-an-ai-agent-is-actually-working/). Оценки и мониторинг — две половины одной системы: мониторинг находит баги, оценки следят за тем, чтобы они оставались мёртвыми. Эта петля обратной связи и есть настоящий продукт. Любой отдельный набор оценок устаревает; а *процесс*, превращающий каждый продакшен-сбой в постоянный тест, крепнет с каждой неделей. Вот как агент переходит от «страшно трогать» к чему-то, что я буду рефакторить в пятницу днём, не моргнув глазом. ## Часто задаваемые вопросы ### Что входит в набор оценок для ИИ-агента? Реальные продакшен-вводы, превращённые в размеченные случаи — счастливый путь, краевые случаи, состязательные и искажённые вводы — каждый с жёсткими ассерциями и, для открытых выводов, рубрикой LLM-судьи. От 30 до 50 случаев, взятых из реальных сбоев, бьют сотни синтетических, которые все проверяют лёгкий путь. ### Стоит ли использовать LLM для оценки выводов агента? Используйте жёсткие ассерции везде, где вывод структурирован (валидный JSON, верное поле, правильный вызов инструмента) — они бесплатны и детерминированы. Приберегите LLM-судью для открытых качеств вроде тона и полезности, с конкретной рубрикой и сильной моделью-судьёй, чтобы получать сигнал, а не шум. ### Как не дать изменению промпта тихо сломать продакшен? Запускайте стенд оценки перед каждым изменением и делайте дифф против базовой линии, следя за регрессиями по случаям, а не только за агрегированной оценкой. Затем привяжите деплои к результату, чтобы любое изменение, опускающееся ниже порога базовой линии, блокировалось как провалившийся тест. ### Как справляться с недетерминизмом в оценках? Запускайте при температуре 0, чтобы снизить дисперсию, а для мерцающих случаев запускайте их несколько раз и оценивайте долю прохождений вместо единичного прогона. Случай, проходящий 9 из 10 раз, здоровее того, что проходит 5 из 10, даже если единичный прогон показывает оба зелёными. --- ## Как Автоматизировать Рассылку с Помощью ИИ-агента Source: https://alejandrorioja.com/ru/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-25 Tags: AI Agents, Growth TL;DR: Агент Claude читает мою очередь контента, выбирает самый сильный угол недели, составляет рассылку в моём стиле, сегментирует список по уровню вовлечённости и планирует отправку через API Kit — всё без того, чтобы я открывал редактор. Я просматриваю отрендеренный превью и нажимаю «Одобрить». Сложная творческая работа — моя; механическое исполнение — агента. ## Содержание _Обновлено июнь 2026._ **TL;DR:** Агент Claude читает мою очередь контента, выбирает самый сильный угол недели, составляет рассылку в моём стиле, сегментирует список по уровню вовлечённости и планирует отправку через API Kit — всё без того, чтобы я открывал редактор. Я просматриваю отрендеренный превью и нажимаю «Одобрить». Сложная творческая работа — моя; механическое исполнение — агента. **[Заметка оператора]** Рассылка, которая отправляется последовательно, обходит ту, что «лучше», но выходит когда приходит вдохновение. Ограничением были накладные расходы на исполнение, а не идеи. Идеи были; не хватало пропускной способности, чтобы форматировать, планировать и сегментировать их каждую неделю. Агент устранил этот разрыв. ## Реальное узкое место в большинстве рабочих процессов рассылки Большинство советов по автоматизации рассылок фокусируются на неправильном: приветственные последовательности, автоматизации, логика тегирования. Это хорошо, но не решает проблему создания контента неделю за неделей. Настоящая помеха вот в чём: вы знаете, что хотите сказать, но садиться форматировать, писать варианты строки темы, выбирать правильный сегмент и планировать в нужное время стоит 2-3 часа переключения контекста в неделю. Умножьте на 52 недели — и вы потратите целую рабочую неделю только на *отправку* рассылок. Агент обрабатывает каждый шаг после «я знаю, каков угол этой недели». ## Стек, который я использую - **[Kit](/recommends/convertkit)** (бывший ConvertKit) — платформа электронной почты. Отличный API, надёжная маркировка подписчиков, чистая аналитика. API, дружественный к агентам, убедил меня. - **Claude (Anthropic SDK)** — уровень генерации - **Cloudflare Workers** — запланированный триггер (запускается каждый вторник в 8 утра CT) - **Airtable** — очередь контента и входящие для одобрения Если вы не на Kit, тот же паттерн работает с любой платформой, у которой есть REST API для создания и планирования рассылок. ## Шаг 1: Очередь контента Агенту нужен источник правды о том, «о чём мы пишем». У меня это таблица [Airtable](/recommends/airtable) со столбцами: - `Topic` — угол или вопрос - `Status` — Queue / Approved / Sent - `Tier` — для всех подписчиков или только для активных - `Notes` — любые ограничения (избегать этого тона, включить эту ссылку и т.д.) Каждую неделю я трачу 10 минут на добавление 2-3 тем в очередь. Это мой творческий вклад. Остальное — работа агента. ## Шаг 2: Агент-составитель ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## Шаг 3: Этап одобрения Агент создаёт рассылку в статусе черновика в Kit и помечает запись Airtable как «Approved». Kit отправляет мне уведомление со ссылкой на превью. Я нажимаю на неё, читаю, и если всё выглядит правильно, подтверждаю отправку. Если нужны изменения, редактирую напрямую в Kit. Это ворота, которые не дают агенту стать полностью автономным в исходящей почте. Я доверяю черновикам примерно 90% времени. 10%, которые я выявляю при проверке — слегка неверный тон, статистику, которую хочу проверить, ссылку, которую хочу добавить — стоят 3-минутного обзора. ## Что агент берёт на себя, чего я больше не хочу делать - Писать варианты строки темы и выбирать лучший - Форматировать текст прехедера - Вычислять оптимальное время отправки (моя аудитория открывает в четверг утром; агент это знает) - Корректно сегментировать на основе уровня темы - Фиксировать всё в Airtable, чтобы иметь запись ## Что по-прежнему моё *Идея*. Тема в очереди — моя. Угол — мой. Агент — отличный исполнитель чёткого брифа; это не стратегический уровень. Если я положу плохую тему в очередь, получу хорошо написанную рассылку о плохой теме. Также: ворота первой проверки. Каждая отправка проходит через мои глаза перед выходом. Это не изменится. ## Итог оператора Если вы тратите более часа в неделю на механику рассылки — форматирование, планирование, сегментацию — вам следует автоматизировать это. API Kit чистый, cron-триггер Worker надёжен как скала, а качество черновиков Claude достаточно высокое, чтобы я одобрял ~90% первых черновиков без изменений. Постройте очередь в Airtable, подключите Worker и вернитесь к созданию идей вместо выполнения отправок. --- ## Как Выйти в Топ ИИ-поиска без Написания Ни Одной Новой Статьи Source: https://alejandrorioja.com/ru/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-19 Tags: GEO, SEO TL;DR: ИИ-движки цитируют контент, который отвечает на вопросы напрямую, заявляет чёткое авторство и структурирует знания так, чтобы облегчить поиск. Большинство существующих статей в блоге можно адаптировать для соответствия всем трём критериям с помощью правок, а не переписывания. План: добавить прямой TL;DR, усилить сигналы сущностей, добавить FAQ-схему и отправить в llms.txt. Новый контент — необязателен; реструктуризация — нет. ## Содержание _Обновлено июнь 2026._ **TL;DR:** ИИ-движки цитируют контент, который отвечает на вопросы напрямую, заявляет чёткое авторство и структурирует знания так, чтобы облегчить поиск. Большинство существующих статей в блоге можно адаптировать для соответствия всем трём критериям с помощью правок, а не переписывания. План: добавить прямой TL;DR, усилить сигналы сущностей, добавить FAQ-схему и отправить в llms.txt. Новый контент — необязателен; реструктуризация — нет. **[Чтение оператора]** Я применил этот процесс к 341 существующей статье до того, как написал единственную новую статью, ориентированную на GEO. Цитирования в ChatGPT и Perplexity возросли. Новый контент ускорил результаты — но аудит существующего контента был отправной точкой, и он окупился быстрее, чем я ожидал. ## Почему ИИ-движки не цитируют ваш существующий контент Прежде чем писать что-то новое, спросите: почему то, что у меня уже есть, не цитируется? Ответ почти никогда не бывает «контент не существует». Обычно это одно из следующего: 1. **Нет прямого ответа вверху** — статья хоронит ответ в шестом абзаце 2. **Слабые сигналы авторства** — нет чёткой сущности автора, нет учётных данных в контенте 3. **Структурный шум** — длинные вступления, нерелевантные разделы, нет чёткой иерархии заголовков 4. **Нет машиночитаемых Q&A** — ИИ-движки предпочитают структурированные пары вопрос-ответ; большинство статей в блоге их не имеют 5. **Не в каком-либо ИИ-читаемом индексе** — нет llms.txt, нет карт сайта, которые находят сканеры Все пять устранимы на существующем контенте. Ни один не требует новой статьи. ## Четырёхшаговый процесс адаптации ### Шаг 1: Добавьте прямой TL;DR в первые 100 слов ИИ-движки делают нечто аналогичное тому, что делаете вы при беглом просмотре — они ищут прямой ответ перед тем, как углубиться. Если ваша статья начинается с истории, вопроса или установки контекста, модель может никогда не прочитать достаточно далеко, чтобы найти ваш реальный ответ. Исправление: добавьте блок **TL;DR** в первые 100 слов. Формат: вывод → почему → ограничение или оговорка. Два-четыре предложения. Без воды. Пример до: > *Вы когда-нибудь задумывались, почему некоторые компании, кажется, доминируют в результатах поиска Google? В этой статье мы рассмотрим стратегии, которые используют сайты с лучшими позициями...* Пример после: > **TL;DR:** Три вещи двигают иглу для локального SEO в 2026 году: полнота профиля компании Google, согласованность цитирований по каталогам и структурированная разметка для ваших данных NAP. Тактики вроде «публиковать каждый день» и «получить 100 отзывов быстро» вторичны относительно этих трёх. Потолок — точность вашего GBP — исправьте это в первую очередь. Переписывание не длиннее. Оно просто загружено в начало. ### Шаг 2: Усильте сигналы сущностей ИИ-движки строят граф знаний. Им нужно знать: кто это написал, о чём это и является ли автор авторитетным по данной теме? Для сущности автора: убедитесь, что ваша страница «О себе» связана с каждой статьёй, ваша схема автора включает ссылки `sameAs` на LinkedIn и Twitter, а ваша биография автора в каждой статье упоминает конкретные учётные данные (не «специалист по маркетингу» — «управлял SEO для трёх SaaS-компаний от 0 до 100K ежемесячных посетителей»). Для сущности темы: используйте точные термины, которые ищет ваша аудитория. Если вы освещаете «GEO» (оптимизацию под генеративные движки), скажите «оптимизация под генеративные движки» где-нибудь, а не только аббревиатуру. Модели используют совместную встречаемость терминов для классификации контента. ### Шаг 3: Добавьте FAQ-схему к каждой статье, отвечающей на вопросы Схема FAQPage является наиболее эффективным типом схем для цитирования GEO, поскольку явно сопоставляет вопрос с ответом в формате, который модели могут разобрать напрямую. Возьмите 3–5 вопросов, на которые ваша статья неявно отвечает, и сделайте их явными: ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` Добавьте это в `` вашей статьи или через поле схемы вашей CMS. Каждый крупный ИИ-движок сканирует и разбирает это. ### Шаг 4: Отправьте в llms.txt и в ИИ-индекс вашей платформы `llms.txt` — это развивающийся стандарт — текстовый файл по адресу `вашсайт.com/llms.txt`, который сообщает ИИ-сканерам, какой контент высококачественный и как его приоритизировать. Это аналогично `robots.txt`, но для LLM. Базовый llms.txt: ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` Совместите это с чистой картой сайта, включающей временны́е метки `lastmod`. ИИ-сканеры снижают приоритет контента, который выглядит устаревшим. ## Как приоритизировать, какие статьи адаптировать Не каждая статья стоит адаптации. Сосредоточьте первый проход на: 1. **Статьях, которые уже ранжируются на 1-й странице по ключевому слову в форме вопроса** — они ближе всего к тому, чтобы быть процитированными; им нужна только структурная правка 2. **Статьях по темам, в которых вы проверяемо авторитетны** — ИИ-движки сильно взвешивают авторство; статья, где ваши учётные данные релевантны, получает прирост цитирования от сигналов сущностей 3. **Статьях, которые прямо отвечают на вопрос, а не статьях, которые информируют** — «Как сделать X» и «Что такое X» адаптируются лучше, чем списки или мнения Используйте данные Search Console: фильтруйте по запросам, которые являются вопросами (как, что, почему, лучший способ). Статьи на позициях 5–15 по этим запросам — ваши лучшие кандидаты для адаптации — они релевантны, но ещё недостаточно близко к вершине, чтобы их цитировали. ## Ошибка, которую совершает большинство Они пишут новую статью, оптимизированную под ИИ-поиск, прежде чем адаптируют существующий архив. Новый контент помогает, но у существующих статей есть возраст, обратные ссылки и история сканирования. Хорошо структурированная трёхлетняя статья будет превосходить новую статью по той же теме месяцами. Сначала сделайте адаптацию. Пишите новый контент там, где есть реальные пробелы — вопросы, на которые ваши существующие статьи вообще не отвечают. Вот когда новое лучше старого. ## Итог оператора Если у вас более 20 существующих статей в блоге, ваша работа по GEO начинается с аудита и адаптации, а не с контент-календаря. Добавьте TL;DR, усильте сигналы сущностей, добавьте FAQ-схему и отправьте в llms.txt. Сделайте это для ваших топ-20 статей до написания чего-либо нового. Вы увидите улучшения в цитировании через недели, а не месяцы — и у вас будет более чистая базовая линия для измерения того, действительно ли новый контент двигает иглу. --- ## Я создал навык Claude, который управляет моей рекламой в Facebook — вот код Source: https://alejandrorioja.com/ru/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-24 Tags: AI Agents TL;DR: Я создал навык Claude, который читает мой аккаунт Meta Ads через Graph API, выявляет неэффективные объявления, переписывает рекламные тексты в голосе моего бренда и создаёт новые группы объявлений без необходимости заходить в Менеджер рекламы. Весь проект занимает менее 300 строк TypeScript. Окупаемость была немедленной: я сократил еженедельное время управления рекламой с ~3 часов до примерно 20 минут. ## Оглавление _Обновлено июнь 2026._ **TL;DR:** Я создал навык Claude, который читает мой аккаунт Meta Ads через Graph API, выявляет неэффективные объявления, переписывает рекламные тексты в голосе моего бренда и создаёт новые группы объявлений без необходимости заходить в Менеджер рекламы. Весь проект занимает менее 300 строк TypeScript. Окупаемость была немедленной: я сократил еженедельное время управления рекламой с ~3 часов до примерно 20 минут. **[Взгляд оператора]** Я управляю рекламой для Pickleland и своего консалтингового бренда. Два аккаунта, разные аудитории, постоянная усталость от креативов. Я тратил воскресные вечера в Менеджере рекламы на вещи, которые должна делать модель. Поэтому я автоматизировал это. ## Почему я перестал управлять рекламой в Facebook вручную Реальная работа по управлению рекламой в Facebook делится на три задачи: 1. **Мониторинг** — проверка, какие группы объявлений сжигают деньги, а какие их зарабатывают 2. **Диагностика** — выяснение *почему* что-то не работает (усталость от креативов? плохой таргетинг? лендинг?) 3. **Итерация** — написание нового текста, создание новых групп объявлений, корректировка бюджетов Задача 1 — механическая. Задача 3 — в основном механическая (с голосовым ограничением). Задача 2 требует суждения — и это единственная, которая выигрывает от присутствия человека в процессе. Навык Claude может делать 1 и 3. Я проверяю результаты задачи 2 до того, как что-либо будет опубликовано. На этой архитектуре я и остановился. ## Настройка Meta Graph API (это самая раздражающая часть) Перед кодом: вам нужен аккаунт Meta Business, Системный пользователь и постоянный токен доступа. Портал для разработчиков Facebook неудобен, но путь такой: 1. Создать **Meta App** на developers.facebook.com (тип: Business) 2. Добавить продукт **Marketing API** 3. В вашем Бизнес-портфеле → Настройки → Пользователи → Системные пользователи создать системного пользователя и дать ему роль `ADVERTISER` в вашем рекламном аккаунте 4. Создать токен с этими правами: `ads_read`, `ads_management`, `business_management` Сохраните токен как `META_ACCESS_TOKEN` и ID вашего рекламного аккаунта (формат: `act_XXXXXXXX`) как `META_AD_ACCOUNT_ID` в файле `.env`. ## Структура файлов навыка ``` .claude/skills/fb-ads/ SKILL.md ← инструкции, которые читает Claude index.ts ← реальная реализация инструмента types.ts ← общие типы ``` `SKILL.md` — это то, что говорит Claude, когда и как использовать навык. Мой файл гласит: ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` Ограничение «никогда не активировать автоматически» — непреложно. Этот навык создаёт вещи в состоянии ПАУЗЫ. Я проверяю и активирую вручную. Всё, что касается живых рекламных расходов, требует человеческой проверки. ## Основной код TypeScript (Блоки кода остаются на английском — переводится только окружающий текст.) ## Как я использую это ежедневно Навык вызывается из Claude Code (мой ежедневный инструмент). Типичная сессия в понедельник утром: ``` > check my ads from the last 7 days ``` Claude запускает `runAdsReport(7)`, форматирует результаты в виде таблицы, отмечает неэффективных и спрашивает, хочу ли я переработок. Я говорю да. Он генерирует новый текст, показывает мне обе версии рядом и создаёт ПРИОСТАНОВЛЕННЫЕ группы объявлений с новым креативом. Я проверяю их в Менеджере рекламы, активирую те, которые мне нравятся, и архивирую проигрышные. Общее время: 20 минут. Ноль воскресных вечеров в Менеджере рекламы. ## Что это не заменяет Навык не может сказать мне, маскируется ли проблема соответствия продукта рынку под проблему с текстом. Если ROAS повсюду плохой, это проблема воронки или предложения, а не заголовка. Claude добросовестно перепишет текст на сломанной воронке — и переработки её не спасут. Этап диагностики по-прежнему мой. Я читаю отчёт, смотрю на данные воронки и решаю, итерируем ли мы креатив или решаем что-то выше по течению. Агент быстр во всём *кроме* этого суждения. ## Вывод оператора Если вы управляете рекламой вручную и заходите в Менеджер рекламы чаще двух раз в неделю, вы выполняете операции, которые должен делать скрипт. Graph API хорошо документирован, а поток разрешений Meta, хотя и раздражающий, — это разовая настройка. Создайте навык за один вечер. Отдача в виде возвращённого времени проявляется на первой неделе. --- ## 5 ИИ-инструментов, которые я реально использую для ведения бизнеса (2026) Source: https://alejandrorioja.com/ru/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-25 Tags: AI Agents, Growth TL;DR: Пять инструментов: Claude (слой оператора + программирование), Cursor (разработка на TypeScript), Airtable (основа данных для всех агентов), Kit (рассылка + автоматизация email) и Cloudflare Workers (хостинг агентов). Всё остальное, что я пробовал, было заменено одним из этих инструментов или полностью исключено. Это стек, который я бы воссоздал, если бы пришлось начинать заново сегодня. ## Содержание _Обновлено июнь 2026._ **TL;DR:** Пять инструментов: Claude (слой оператора + программирование), Cursor (разработка на TypeScript), [Airtable](/recommends/airtable) (основа данных для всех агентов), [Kit](/recommends/convertkit) (рассылка + автоматизация email) и Cloudflare Workers (хостинг агентов). Всё остальное, что я пробовал, было заменено одним из этих инструментов или полностью исключено. Это стек, который я бы воссоздал, если бы пришлось начинать заново сегодня. **[Чтение оператора]** Я веду два бизнеса: личный бренд консалтинга в области ИИ (alejandrorioja.com) и Pickleland — площадку для пиклбола в Пфлугервилле, Техас. Разные контексты, разные аудитории, разные операции. Эти пять инструментов управляют обоими. Я перечисляю их не потому, что они в тренде; я перечисляю их потому, что удалил их замены. ## 1. Claude — слой оператора Claude (через Claude Code и Anthropic SDK) — это мозг всего, что движется. Я использую его в трёх режимах: **Claude Code** — мой ежедневный инструмент разработки. Я пишу TypeScript, создаю агентов, отлаживаю проблемы с инфраструктурой и управляю контентом — всё через интерфейс Claude Code. Это не просто автодополнение; это коллаборатор, который может прочитать файл из 500 строк, понять намерение и предложить рефакторинг, который я не рассматривал. **Anthropic SDK** питает каждого агента, которого я создал. Мой агент рассылки, мой навык Facebook-рекламы, мой контент-конвейер, мой генератор OG-карточек — всё это Claude на бэкенде. Качество модели достаточно высокое, чтобы я доверял первым черновикам примерно в 85% случаев. **Суждение Claude о голосе и бренде** недооценено. Когда я пишу что-то, что должно звучать как я, я обнаружил, что Claude + детализированный системный промпт превосходит каждую другую модель, которую я тестировал. Хитрость — в конкретном, с чёткой позицией системном промпте — не "пиши в непринуждённом тоне", а "пиши как Алехандро: прямо, практично, без хайпа, с нумерацией, от первого лица, с честными оговорками." Я плачу за Claude Max. Это самая используемая подписка, которая у меня есть, и ROI несопоставим. ## 2. Cursor — где пишется TypeScript Cursor — это IDE. Я перешёл с VS Code примерно год назад и не оглядывался. Автодополнение по Tab достаточно быстрое, чтобы реально изменить способ написания кода — я думаю на более высоком уровне и позволяю Cursor справляться с синтаксическим шаблонным кодом. Представление diff для предложений ИИ чистое. Многофайловое контекстное окно означает, что я могу попросить обновить функцию, и он обновляет также вызывающих. Я не использую Cursor для архитектурных решений. Я по-прежнему набрасываю их на бумаге или в Claude. Но когда дизайн ясен, Cursor — самый быстрый путь от дизайна к работающему TypeScript. Главная разблокировка: Cursor + Claude Code параллельно. Я использую Claude Code для высокоуровневого планирования и оркестрации агентов; использую Cursor для детальной работы по реализации. Они не конфликтуют — они покрывают разные уровни. ## 3. Airtable — основа данных Каждому ИИ-агенту, которым я управляю, нужно место для чтения и записи. Это место — [Airtable](/recommends/airtable). Вот для чего я использую его в обоих бизнесах: - **Очередь контента** — публикации и темы рассылки в процессе, с отслеживанием статуса - **Записи бронирований** — резервации кортов Pickleland, синхронизированные из системы бронирования - **Каталог партнёрских ссылок** — 105+ слагов с метаданными, которые агент контента читает при генерации - **Журнал аудита агентов** — что запускалось, когда, что произвело, любые ошибки API чистый и быстрый. Airtable — не база данных для высоконагруженных рабочих нагрузок, но для вспомогательных таблиц агентов, очередей проверки и рабочих процессов утверждения с участием человека это именно правильный инструмент. Визуальный интерфейс означает, что я могу проверить любую таблицу без написания запроса. Альтернатива, которую я пробовал: базы данных Notion. API Notion медленнее, а модель данных более неудобна для считывания агентами. Airtable побеждает для данных, смежных с агентами. ## 4. Kit — рассылка и автоматизация email Я перешёл на [Kit](/recommends/convertkit) (бывший ConvertKit) по одной причине: API действительно хорош. Большинство email-платформ относятся к своему API как к послемыслию. Kit относится к нему как к продукту первого класса. Я могу создавать рассылки, планировать отправки, сегментировать по тегу и читать аналитику — всё программно. Мой агент рассылки делает всё это без того, чтобы я касался редактора. Специфические функции Kit, которые я использую: - **Broadcasts API** — мой агент программно создаёт запланированные рассылки каждую неделю - **Теггинг подписчиков** — я тегирую подписчиков по поведению (открыл последние 5 отправок = "вовлечённый"; не открывал 60 дней = "в зоне риска") и мой агент нацелен на сегменты соответственно - **Формы + лендинги** — чистые, быстро загружающиеся, без кода. Я не трогаю их программно; они просто работают. Если вы на Mailchimp или устаревшей платформе: миграция того стоит. API Mailchimp требует трёх дополнительных вызовов, чтобы сделать то, что Kit делает за один. ## 5. Cloudflare Workers — где живут агенты Каждый запланированный агент работает на Cloudflare Workers. Аргумент: глобальное развёртывание на периферии, нулевые холодные старты на бесплатном уровне и система триггеров cron, которая действительно работает. Моим агентам не нужен сервер. Им нужна запланированная функция, которая работает надёжно, может делать внешние вызовы API и стоит почти ничего на моём масштабе. Workers — ответ. Что у меня работает на Workers: - **Контент-конвейер** — генерирует пост на английском, раздаёт на 12 переводов, генерирует OG-карточку - **Агент рассылки** — составляет и планирует еженедельную отправку - **Монитор рекламы Facebook** — читает производительность, помечает отстающих, уведомляет меня - **Репортёр занятости Pickleland** — читает данные бронирований, отправляет мне ежедневную сводку Общая ежемесячная стоимость за всё это: ~$5. Это платный план Workers. Агенты надёжно работают по расписанию cron; у меня был один сбой за шесть месяцев (проблема DNS на стороне Meta, а не моей). ## Что я исключил и почему **Zapier** — заменён Workers + соответствующими API платформ напрямую. Zapier добавляет задержку, стоит дороже при масштабировании и имеет потолок, которого нет у Workers. **ChatGPT** — контекстное окно Claude, использование инструментов и качество системного промпта лучше для случая использования оператора. Я держу вкладку ChatGPT для быстрых веб-поисков, но не строю на нём. **Webflow** — перенёс сайт на Astro + Cloudflare Pages. Больше контроля, лучшая производительность, процесс сборки, против которого можно скриптовать. **Grammarly** — Claude делает всё, что делает Grammarly, и лучше сохраняет мой голос. ## Итог оператора Пять вышеперечисленных инструментов не самые новые и не самые обсуждаемые. Они те, что выдержали ежедневное использование в продакшне в двух разных бизнесах. Прежде чем добавлять новый инструмент в свой стек, спросите: какой из этих пяти мог бы выполнить эту работу? Вы удивитесь, как часто ответ будет "один из них уже может." --- ## Почему ваш ИИ-агент продолжает давать сбои в продакшне (И как это исправить) Source: https://alejandrorioja.com/ru/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-23 Tags: AI Agents TL;DR: Большинство продакшн-отказов агентов происходит из-за пяти причин: хрупкие промпты, не обрабатывающие граничные случаи; отсутствие логики повторных попыток для переходящих ошибок API; нулевая наблюдаемость, не позволяющая видеть что ломается; бесконечные циклы без условия выхода; определения инструментов, достаточно неоднозначные, чтобы модель выбрала неправильный. Все пять поддаются исправлению без смены модели или фреймворка. ## Содержание _Обновлено июнь 2026._ **TL;DR:** Большинство продакшн-отказов агентов происходит из-за пяти причин: хрупкие промпты, не обрабатывающие граничные случаи; отсутствие логики повторных попыток для переходящих ошибок API; нулевая наблюдаемость, не позволяющая видеть что ломается; бесконечные циклы без условия выхода; определения инструментов, достаточно неоднозначные, чтобы модель выбрала неправильный. Все пять поддаются исправлению без смены модели или фреймворка. **[Чтение оператора]** Я управляю более чем 30 агентами в продакшне. Все эти сбои случались у меня. Те, что сожгли больше всего времени, были не экзотическими — это были скучные инфраструктурные сбои, которые я думал, что обработал. ## Сбой 1: Хрупкие промпты, ломающиеся на граничных входных данных Промпт, работающий на тестовых случаях, провалится на входных данных, которые вы не предвидели. Это не ограничение модели — это проблема написания инструкций. **Симптомы:** Агент выдаёт бессмысленный результат, вызывает неправильный инструмент или выдаёт некорректный JSON, когда входные данные слегка отличаются от протестированных. **Первопричина:** Ваш системный промпт описывает только счастливый путь. Он не говорит модели, что делать, когда данные отсутствуют, повреждены или неоднозначны. **Исправление:** Добавьте явную обработку граничных случаев в системный промпт: ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` Модель надёжно следует явным инструкциям для граничных случаев. Ошибка — предполагать, что она обобщит инструкции счастливого пути на грязные случаи. ## Сбой 2: Отсутствие логики повторных попыток для переходящих ошибок API Каждый внешний API, который вызывает ваш агент, в какой-то момент даст сбой. API Claude, Meta Graph API, ваша база данных — все они возвращают ошибки 5xx, таймаут или ограничения скорости. Если у агента нет логики повторных попыток, одна переходящая ошибка уничтожает весь прогон. **Симптомы:** Прогоны агента случайно завершаются неудачей на разных шагах. Логи показывают 503 или 429 без последующей попытки. **Исправление:** Оберните каждый внешний вызов в повторную попытку с экспоненциальной задержкой: ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` Три повторные попытки с экспоненциальной задержкой обрабатывают ~99% переходящих сбоев. Добавьте это к каждому внешнему вызову, и половина ваших случайных сбоев исчезнет. ## Сбой 3: Нулевая наблюдаемость — вы не можете видеть, что ломается Это наиболее распространённый режим отказа в продакшне и самый затратный по времени для отладки: агент молча падает или выдаёт неверный результат, и вы понятия не имеете, где в цепочке что-то пошло не так. **Симптомы:** Вы знаете, что что-то не так, но не можете определить шаг. Вы добавляете операторы `console.log` и вручную перезапускаете, пытаясь воспроизвести. **Исправление:** Структурированное логирование на каждом шаге с идентификатором прогона, отслеживающим всё выполнение: ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Если вы на Cloudflare Workers, логи идут в Logpush или Workers Tail. При локальном запуске или на VPS направьте в агрегатор логов. Структурированный JSON позволяет фильтровать по `runId`, чтобы точно видеть, что произошло в одном прогоне. ## Сбой 4: Бесконечные циклы без условия выхода Агентские циклы — где модель вызывает инструменты и итерирует до выполнения условия — могут работать вечно, если условие никогда не выполняется или модель неправильно его идентифицирует. **Симптомы:** Агент тратит сотни долларов на API-расходы до таймаута. Или многократно вызывает один и тот же инструмент, не продвигаясь вперёд. **Исправление:** Всегда имейте жёсткий лимит итераций и проверку прогресса: ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` Это перехватывает как режим «работал слишком долго», так и режим «крутился на месте». Лимит должен быть достаточно щедрым для счастливого пути, но достаточно жёстким, чтобы ограничить радиус поражения. ## Сбой 5: Неоднозначные определения инструментов, которые модель разрешает неверно Если дать модели два инструмента с перекрывающимися описаниями, она иногда вызовет неправильный. Это особенно распространено с инструментами вроде `search_database` vs `get_record` или `send_email` vs `create_draft`. **Симптомы:** Модель вызывает правильную категорию инструмента, но выбирает неправильный конкретный. Или вызывает инструмент в неправильном контексте (использует инструмент записи, когда уместно было только чтение). **Исправление:** Сделайте описания инструментов взаимоисключающими и явно добавьте «когда НЕ использовать»: ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` Оговорка «НЕ использовать, когда X» — часть, которую большинство пропускает. Это самая важная часть. Модели лучше следуют явным негативным ограничениям, чем выводят их из позитивных описаний. ## Ещё одна вещь: тестируйте агентов на плохих входных данных Большинство агентов тестируются только на чистых входных данных счастливого пути. В продакшне грязные входные данные: пустые строки, null-поля, граничные случаи Unicode, ответы API, возвращающие 200, но с неожиданной схемой. Добавьте тестовый набор, явно упражняющий: - Пустые или null входные данные - Входные данные максимальной ожидаемой длины - Входные данные со специальными символами или не-ASCII-текстом - Внешние API, возвращающие неожиданные формы ответа Если агент ломается на любом из них, исправьте это до запуска в продакшн. Производственная среда найдёт каждое сделанное вами предположение. ## Итог оператора Большинство продакшн-отказов агентов — это инфраструктурные проблемы, маскирующиеся под проблемы модели. Прежде чем менять модели, добавьте повторные попытки, структурированное логирование, лимиты циклов и явную обработку граничных случаев в промпты. Исправьте неоднозначные определения инструментов. Затем тестируйте на плохих входных данных. Сделайте всё это прежде чем обвинять модель — по моему опыту, модель обычно последнее, что нуждается в изменении. --- ## Как создать своего первого ИИ-агента за 15 минут Source: https://alejandrorioja.com/ru/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-20 Tags: AI Agents TL;DR: Вам не нужны ни фреймворк, ни курс, ни докторская степень. Вам нужны Node.js, SDK от Anthropic и 25 строк TypeScript. В этом руководстве создаётся настоящий рабочий агент — структурированный суммаризатор контента, которого вы можете развернуть на Cloudflare в той же сессии. Единственное предварительное требование — бесплатный API-ключ. ## Содержание _Обновлено в июне 2026 года._ **Кратко:** Вам не нужны ни фреймворк, ни курс, ни докторская степень. Вам нужны Node.js, SDK от Anthropic и 25 строк TypeScript. В этом руководстве создаётся настоящий рабочий агент — структурированный суммаризатор контента, которого вы можете развернуть на Cloudflare в той же сессии. Единственное предварительное требование — бесплатный API-ключ. **[Взгляд оператора]** Чаще всего от основателей, которые хотят автоматизировать работу с помощью ИИ, я слышу: «Мне сначала нужно больше изучить». Это не так. Паттерн агента прост, и самый быстрый способ понять его — построить одного. Вот точный путь, который я бы выбрал, если бы начинал с нуля сегодня. ## Почему большинство руководств «создайте ИИ-агента» вас подводят Они либо используют Python (нормально для ML-инженеров, но создаёт трение для всех остальных), либо прячут настоящий код за фреймворком вроде LangChain, либо строят нечто слишком абстрактное, чтобы связать это с вашей реальной работой. Это руководство делает три вещи иначе: 1. **Только TypeScript** — если вы когда-либо писали на JavaScript, вы сможете следовать этому 2. **Без фреймворка** — вы увидите каждую строку кода, которая касается модели 3. **Полезный результат** — вы создадите структурированный суммаризатор, который действительно сможете применять к письмам клиентов, отзывам или заметкам со встреч ## Что вы создаёте **Агент-суммаризатор контента**: вставьте любой блок текста и получите обратно структурированное резюме в едином формате. Один HTTP-запрос на входе, одно чистое резюме на выходе. Почему именно это в качестве первого проекта: паттерн — системный промпт + пользовательский ввод → структурированный вывод — это основа каждого агента, которого я запускаю. Замените системный промпт, и вы получите ответчик на вопросы, переписчик тона, классификатор или генератор черновиков. Освойте это один раз — и вы освоите 80% того, что на самом деле делают агенты в продакшене. ## Предварительные требования (2 минуты) - **Node.js 18+** — проверьте командой `node --version`. При необходимости установите с nodejs.org. - **API-ключ Anthropic** — зарегистрируйтесь в [Claude](/recommends/claude), получите ключ в консоли. Бесплатного тарифа достаточно. - Терминал и текстовый редактор. Никакого Docker. Никакого виртуального окружения. Никаких `pip install` чего-либо. ## Шаг 1: Создание проекта (2 минуты) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` Добавьте скрипт в `package.json`, чтобы легко запускать агента: ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## Шаг 2: Написание агента (5 минут) Создайте `agent.ts` и вставьте это: ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## Шаг 3: Запуск (1 минута) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` Ожидаемый вывод: ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` Это и есть рабочий ИИ-агент. Реальный ввод, кастомный системный промпт, структурированный вывод. Всё это — 30 строк кода. ## Шаг 4: Настройте его под свой сценарий использования Системный промпт — единственное, что делает этого агента вашим. Вот три готовых к подстановке альтернативы: **Классификатор отзывов клиентов:** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: