Открыт к новым проектам и коллаборациям в Q3 2026. Связаться →

2026.06.29 · tools · agents

Проверяй риск, а не инструмент

Как я оцениваю чужой AI-инструмент перед внедрением — не полным прогоном, а одним дешёвым тестом главного риска, который и решает go/no-go.

Оценивать чужой AI-инструмент полным прогоном — дорого и почти всегда лишнее. У любого нового инструмента десятки свойств, но под конкретную задачу почти всегда есть один риск, который реально может его похоронить. Я начинаю не с тура по возможностям, а с вопроса: что здесь может не сработать так, что всё остальное потеряет смысл? И проверяю сначала только это.

Недавно мне нужно было собирать двуязычные русско-китайские питчи как редактируемые презентации — настоящие текстовые объекты, а не картинки, чтобы партнёр на той стороне мог править файл у себя. Инструмент, который это обещал, выглядел убедительно. Но единственный вопрос, от которого зависело всё, был узкий: переживёт ли кириллица соседство с китайским внутри нативных фигур, или одна из письменностей рассыплется, потеряет шрифт или молча уедет в картинку. Качество шаблонов, скорость, набор форматов — всё вторично к этому go/no-go. Если две письменности не уживаются на одном слайде, остальное неважно.

РИСК ИНСТРУМЕНТ — МНОГО ЧАСТЕЙ один тест

GO / NO-GO остальное — потом

Не прогоняй весь инструмент — ткни в одну точку, которая решает go/no-go.

Полный конвейер инструмента тяжёлый: он собирает каждую страницу по очереди и требует ряда подтверждений по дороге. Прогонять его целиком ради одного вопроса — расточительно. Поэтому я собрал две страницы руками, поставив русский и китайский вплотную на одном слайде, прогнал только финальный экспорт и вскрыл получившийся файл. Внутри — настоящие текстовые объекты, обе письменности целы, а шрифт под китайский движок подставил сам. Несколько минут, и вердикт получен — дальше уже можно тратить время на качество.

Отдельная история — как инструмент чуть не получил неверный приговор на ровном месте. Системный интерпретатор оказался слишком старым, а установка зависимостей спотыкалась о прокси, который пересжимает пакеты и ломает их контрольные суммы. Лечится свежим окружением и установкой через зеркало, но эти полчаса не имеют никакого отношения к тому, хорош ли сам инструмент. Именно на такой ерунде чаще всего и выносят приговор «не работает» — а он оказывается про окружение, не про инструмент.

И главное, ради чего всё это. Соблазн — судить по витрине: описание обещало «почти автоматически», а внутри оказался серьёзный конвейер с ручной работой; я и сам сперва заглянул не в ту папку и недосчитал половину возможностей. Поэтому я держу два вопроса раздельно: работает ли движок технически — и даёт ли он хороший результат. Первый решает go/no-go, стоит копейки и проверяется на реальном выводе, а не на описании. Второй — вопрос продакшена, и его незачем задавать, пока не закрыт первый. Большинство неудачных внедрений путают эти две вещи: гоняют инструмент вширь, устают и бросают — так и не проверив ту единственную точку, которая всё решала.