Как я, незрячий разработчик, организовал работу с ИИ-агентом: от задачи до проверенного результата

Схема: задача, инструмент, результат и способ проверки в трёх рабочих процессах.

Я пользуюсь ИИ-агентом Hermes для разработки, чтения материалов и работы со своим блогом. Я незрячий, поэтому привычный способ «открой несколько вкладок, посмотри видео, найди нужную кнопку» часто требует лишних действий. С агентом я могу сформулировать результат словами и получить файл, выборку или отчёт, не проходя каждый интерфейс самому.

Со временем выяснилось, что одноразового запроса мало для задач, которые повторяются. Я уточняю формат ответа, объясняю, какие подробности нельзя терять, и проверяю результат. Когда рабочий способ найден, оформляю его как скилл: инструкцию для агента, иногда с отдельным скриптом и тестами. Покажу три таких инструмента. Все они опубликованы открыто, но решают разные задачи.

Длинная запись: получить текст целиком

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

Для этого я опубликовал whisper-groq. В нём есть инструкция для агента и исполняемый Python-скрипт. Скрипт приводит звук к одноканальному WAV с частотой 16 кГц, делит длинную запись на части с перекрытием, отправляет их в Groq Whisper и собирает расшифровку. Если облачное распознавание части не сработало, можно попробовать локальный Whisper. При пропавшей части процесс по умолчанию завершается ошибкой, а не выдаёт неполный текст как готовый.

Команда для файла выглядит так:

			python scripts/transcribe.py recording.ogg --language ru --output transcript.txt
		

Для приватной записи предусмотрен локальный режим --local-only: обычный режим отправляет части звука сервису Groq. После расшифровки длинной записи я отдельно смотрю, покрыта ли вся длительность, нет ли повторов на стыках и не исказились ли имена и числа.

Сам скилл заканчивает работу на расшифровке. Статья из записи — следующий этап. Например, однажды я передал агенту четыре записи одного автора и попросил убрать повторы, сохранить уникальные подробности старых записей и учитывать более новое мнение автора. Первая версия получилась для меня слишком сжатой, поэтому я попросил расширить текст. Такое уточнение относится к редакторской задаче; приписывать создание статьи одному скрипту распознавания было бы неверно.

Реестр публикаций: не загружать весь архив ради одного вопроса

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

Так появился registry-search. Это небольшой локальный поиск по JSON или JSONL. Агент вызывает скрипт с путём к реестру, запросом и ограничением выдачи. Например:

			python3 scripts/registry_search.py --registry posts.jsonl --query 'доступность сайта' --match any --limit 10
		

Скрипт просматривает файл локально и отдаёт короткий результат: найденные записи, статусы и ссылки. У него есть фильтры по дате и площадке, ограничение размера ответа и явный признак того, что часть совпадений не показана. Он не изменяет реестр и не отправляет его в сеть. Публичная версия принимает путь пользователя и не содержит моего личного архива.

Эта схема экономит место в контексте агента: вместо всего файла модель получает записи по теме. Я не измерял экономию в токенах для каждого запуска, поэтому не буду называть процент или число. Есть и важное различие в проверке результата: реестр помогает найти возможный повтор, но статус публикации при необходимости нужно сверить с самой площадкой. Индекс может отстать от того, что уже произошло в VK или Telegram.

Аудит доступности: от личного опыта к воспроизводимому процессу

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

В accessibility-auditor-skill я собрал порядок проверки сайтов и исходников приложений. Агент определяет тип проекта, изучает страницу или код, применяет подходящий список проверок и готовит отчёт: что обнаружено, где находится проблема, какое требование доступности затронуто и что можно изменить. Для сайта это могут быть подписи полей и кнопок, структура заголовков, управление с клавиатуры. Для мобильного или настольного приложения — соответствующие элементы в исходном коде.

Есть и пример, когда такой разбор дошёл до исправления. При проверке открытого приложения School Table агент изучил код на PyQt5 и отметил проблемы с доступными именами элементов и связью подписей с полями. После этого был подготовлен PR с изменениями: в код добавили доступные имена для таблиц и полей, описания для основных кнопок. Автор проекта принял PR. Это подтверждённое изменение кода, а не утверждение, что всё приложение после него полностью доступно.

Вот фрагмент принятого изменения из main.py:

			table_names = {
    self.Mon_school: "Расписание на понедельник",
    self.Tue_school: "Расписание на вторник",
}
for table, name in table_names.items():
    table.setAccessibleName(name)
		

Теперь у этих таблиц есть доступные имена. Это изменение можно подтвердить по коду и принятому PR; как конкретная версия приложения озвучивается у пользователя, нужно проверять при запуске.

Технически здесь важно отделять доступные способы проверки. Если агент видит только исходники, он может указать подозрительный компонент и место в коде, но не может утверждать, как его озвучит скринридер при запуске. Если доступен браузер, можно проверить больше интерактивных сценариев. Отчёт должен называть охват проверки и конкретное основание для каждой находки. Автоматическая оценка — не сертификат соответствия.

Для меня этот скилл — способ быстрее начать осмысленное обследование проекта и не забыть о других группах пользователей. Я хочу, чтобы им пользовались разработчики и команды продуктов: это даст больше шансов заметить проблему доступности до того, как с ней столкнётся пользователь.

Что общего у этих инструментов

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

Скилл не заменяет инструменты. Для расшифровки нужны ffmpeg и распознавание речи; для поиска по реестру — скрипт; для аудита — доступ к странице, браузеру или исходникам. Скилл связывает их с моей задачей и задаёт правила: где остановиться, что указать в ответе и чего не выдавать за проверенный результат. А если Hermes получает сообщения из VK, это уже другая часть системы — плагин канала, а не ещё один скилл для анализа текста.

Мне хочется, чтобы особенно далеко ушёл инструмент для аудита доступности. Доступный интерфейс означает, что человек может сам прочитать материал, оформить заказ или выполнить рабочую задачу. Это влияет и на удовольствие от использования продукта, и на самостоятельность. Если вы разрабатываете интерфейсы или знаете команду, которой такой инструмент пригодится, покажите ей публичный скилл и расскажите о моей работе. Буду рад реальным проверкам и обратной связи: какие находки оказались полезны и чего в процессе не хватает.

Денис Скрипник — незрячий разработчик. Публичные проекты и скиллы: GitHub.

О том, как я использую ИИ-агентов и проверяю доступность, рассказываю в моём блоге во VK. Подписывайтесь, если вам интересны эти темы.