Портфолио и кейсы фрилансеров по AI-автоматизации процессов

Агент собирает заявки с бирж, проверяет их по заданным критериям, готовит персональный отклик и перемещает подходящий лид по воронке продаж в Битрикс24. Полный кейс: https://satori.ist/

Ассистент ведёт закупку от извещения в ЕИС до запроса поставщикам: разбирает документы, проверяет требования, формирует товарные позиции и ищет подходящие предложения. Полный кейс: https://satori.ist/

AI-ассистент ИТ-компании закрывает первую линию продаж и найма, участвует во встречах, готовит сметы, ведёт проекты в Битрикс24 и координирует профильных агентов. Полный кейс: https://satori.ist/

Веб-приложение и личный кабинет для сети АЗС: клиентский сценарий, карта станций, программа лояльности и административный интерфейс. Продумал структуру продукта, адаптивный интерфейс и безопасный демонстрационный режим без обращения к боевым SMS, оплате и оборудованию АЗС. Для просмотра демо используйте код 1234.

Задача: сделать приложение, которое ставится на домашний экран и работает без интернета, но без разработки под две мобильные платформы отдельно. Что сделано: устанавливаемое веб-приложение целиком — манифест и service worker дают установку и офлайн-режим, иконки под установку (192/512, maskable для Android, apple-touch для iOS), локальное хранение прогресса, родительский раздел, правовые тексты, 23 графических ассета: три фона, три персонажа в четырёх состояниях каждый, карточки звукоподражаний и предметы. Режим бесплатного доступа переключается одним флагом в коде — без переписывания логики оплаты. Вокруг продукта собран коммерческий пакет: обзор, ценообразование, платёжная схема, порядок публикации в магазине приложений, маркетинговая и юридическая части. Зачем это в портфолио автоматизатора: тот же приём закрывает задачу «нужно приложение для сотрудников или клиентов, работающее в поле без связи» — без бюджета на две нативные разработки. Стек: PWA (манифест, service worker, офлайн-кеш), JavaScript, локальный стор состояния. Приложение в магазины не публиковалось: числа установок и пользователей не привожу — их нет. Это мой собственный продукт, а не работа по заказу внешнего клиента. Моя роль: постановка задачи, техническое задание, приёмка и эксплуатация.

Задача: перестать вручную копировать содержимое страниц, статей и видео в рабочую базу. Что сделано: три входа под разные типы источников. Первый: забор страницы браузерным движком с отрисовкой скриптов, извлечение основного содержимого в чистый Markdown с шапкой — источник, заголовок, дата, статус; категория раскладывает файл по папкам. Одна команда, есть режим сухого прогона. Второй: изолированный контур для субтитров видео, страниц через reader-прокси и RSS. Третий: синхронизация внешнего репозитория в данные приложения одной командой: извлечение → проверка → преобразование → запись, с полями происхождения (репозиторий, коммит, дата) в каждом файле. Две вещи, которые отличают рабочий парсер от одноразового скрипта. Первая: красные линии закреплены в самой установке — логины не подключаются, площадки, живущие только на cookie-логине, в контур не входят: доступны 4 канала из 15, ровно беcлогиновые. Вторая: вывод принудительно в UTF-8, потому что консоль Windows по умолчанию в другой кодировке и кириллица приходит битой — на этом ломается большинство самодельных парсеров. Рядом лежат журналы смоук-прогонов по трём разным сайтам: проверка была не «в теории». Стек: Python, crawl4ai и Playwright, yt-dlp, Jina Reader, RSS, изолированные окружения. Это внедрение в моей собственной инфраструктуре, а не работа по заказу внешнего клиента. Моя роль: постановка задачи, техническое задание, приёмка и эксплуатация.

Задача: держать под контролем несколько десятков автоматических процессов и узнавать о поломке раньше, чем о ней сообщит клиент. Что сделано: ежедневный прогон по чек-листу, где по каждому процессу смотрят не на факт запуска, а на артефакт: свежую строку журнала, файл отчёта, ответ сервиса, прирост выходного файла. Расхождение оформляется тикетом с приоритетом, тикет живёт до закрытия. Раз в день — один сводный отчёт, а не поток разрозненных уведомлений. Есть ремонтный режим: он поднимает исполнителя на найденную поломку, а не просто уведомляет о ней. Объём: 15 машинных пробников, манифест задач планировщика с ожидаемым состоянием — чтобы разницей ловить исчезнувшие, очередь тикетов и письменный отчёт по каждому прогону. Отдельно ведётся каталог из 18 проверок-обманок — с разбором, почему каждая ничего не доказывает и чем её заменить. Пример: нулевой код возврата у скрипта-вахтёра одинаково нулевой и когда подопечный жив, и когда он сам в цикле перезапусков. Стек: PowerShell, Python, планировщик задач Windows, тикеты и отчёты в markdown, журнал вердиктов. Это внедрение в моей собственной инфраструктуре, а не работа по заказу внешнего клиента. Моя роль: постановка задачи, техническое задание, приёмка и эксплуатация.

Задача: выпускать материалы по календарю в двух соцсетях и не дать уйти в публикацию тексту, который нарушает требования к формулировкам. Что сделано: календарь публикаций, публикатор по расписанию в Telegram, кросспостер в VK (разметка сплющивается в плоский текст — на стене VK её нет), напоминание о завтрашнем слоте и вахтёра публикаций. Перед отправкой текст проходит машинный гейт: проверка → один раунд автоисправления → повторная проверка → публикация либо блокировка с оповещением. Ровно один раунд — чтобы не зациклиться и не замаскировать дефекты самой проверки. Отдельный реестр рекламных материалов с токенами маркировки работает fail-closed: материал в реестре с пустым токеном не публикуется вообще. Отдельно стоит отметить критерий приёмки: признаком «сработало» назначен пост, физически видимый в канале, а не код ответа API. Причина — реальный случай: API отвечал «успешно», а обложка в канал не попадала, потому что серверы мессенджера не могли забрать картинку с нашего домена. Стек: Python, Telegram Bot API, VK API, расписание в JSON, задачи планировщика. Это внедрение в моей собственной инфраструктуре, а не работа по заказу внешнего клиента. Моя роль: постановка задачи, техническое задание, приёмка и эксплуатация.

Задача: связать аккаунт на сайте с Telegram без пароля и ручного сопоставления, и рассылать уведомления адресно — с учётом уровня доступа. Что сделано: бот с командами и промежуточным слоем обработки — привязка аккаунта по одноразовому токену, форматирование события в сообщение, адресная рассылка по подписчикам с учётом тарифа и задержкой для бесплатного уровня, дежурные оповещения, настройки уведомлений в кабинете и отписка. Отдельно — вахтёр поллинга, и в нём смысл работы. Он проверяет не «запущен ли процесс», а две вещи, по которым видно, что бот действительно работает: свежесть последнего успешного ответа Telegram API (нет ответов дольше пяти минут — петля поллинга перезапускается) и свежесть выдаваемых данных (запись старше суток бот не отдаёт как «последнюю»). Живой процесс, который молча ничего не делает, — самый частый и самый дорогой вид отказа в таких контурах: снаружи всё зелёное, а сообщения не идут. Объём: 12 модулей, 2 набора автотестов — на вахтёра поллинга и на правило свежести выдачи. Бот-агент вынесен в отдельную службу с установщиком, вахтёром и ограничителем расхода. Стек: TypeScript, Telegram Bot API и MTProto, маршрут приёма на Next.js, тесты на node:test. Это внедрение в моей собственной инфраструктуре, а не работа по заказу внешнего клиента. Моя роль: постановка задачи, техническое задание, приёмка и эксплуатация.

Задача: ежедневно выпускать аналитические материалы, не читая каждый вручную перед публикацией. Главный риск не в стиле, а в том, что языковая модель уверенно пишет число, которого во входных данных не было. Конвейер: данные → расчёт фактов кодом → текст → машинные гейты → публикация. Текстовый слой с тройным запасом по убыванию качества: платный API, затем локальный запуск по квоте, затем детерминированный генератор текста прямо из посчитанных фактов — он стоит ноль и доступен всегда. Ключевое: любой из трёх выходов проходит одни и те же проверки — контроль запрещённой лексики и валидатор чисел, который требует, чтобы каждое число из текста присутствовало во входных фактах. Не прошёл — материал не публикуется, остаётся прошлый. Объём: 10 инструментов в разборах, суточный лимит вызовов, кэш, защита от параллельных прогонов, пять регулярных сводок по расписанию с блокирующей проверкой перед каждой выгрузкой. Два реальных дефекта найдены и закрыты с записью причины в код: проверка лексики жила только в тексте промта, и материалы уходили без неё; имя журнала бралось по локальной дате машины в другом часовом поясе. Стек: Python, Anthropic API с фолбэками, планировщик, приёмники на сайте. Это внедрение в моей собственной инфраструктуре, а не работа по заказу внешнего клиента. Моя роль: постановка задачи, техническое задание, приёмка и эксплуатация.