Script > Model: где в работе с AI лучше написать скрипт

В эпоху AI-хайпа звучит соблазнительная мысль: “AI решает всё”. Это неправда. Есть класс задач, где AI избыточен, дорог и хрупок. Это задачи с детерминированным правилом — “если X, то Y”. Их надо писать как скрипт, не как промпт.

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

Table of contents

Простой критерий: it-условие vs суждение

Задача попадает в одну из двух категорий:

A) Детерминированное правило — есть чёткий if-then. Например:

• “Если файл содержит дату в формате YYYY-MM-DD в имени, переместить в архив прошлого года”
• “Если ответ API вернул код 200, распарсить JSON и записать в БД; если 5xx — повторить через минуту”
• “Если в директории больше 100 файлов, разбить по 20”

B) Задача с суждением — нет однозначного правила, нужна оценка контекста. Например:

• “Этот текст — токсичный или нет?”
• “Какой подход к рефакторингу лучше для этого кода?”
• “Стоит ли эту идею продукта развивать или отбросить?”

Категория A — это скрипт. Категория B — это промпт к AI.

Если задача — это if-then, ей не нужно “понимание”. Ей нужна стабильная функция, которая всегда возвращает одинаковый ответ на одинаковый вход. AI этого не гарантирует.

Почему “всё через AI” дорого и хрупко

Когда вы решаете if-условие через AI, вы получаете:

Дорого. Каждый вызов AI — это токены. На API — деньги. На Pro-подписке — квота. Скрипт стоит ноль за каждый вызов после написания.

Медленно. Скрипт работает миллисекунды. Запрос к Claude — секунды. На батч из 1000 операций разница превращается в часы.

Недетерминированно. AI на одинаковый вход может выдать разный ответ. Это фундаментальное свойство, а не баг. Для if-задачи это значит — вы периодически будете получать “странные” результаты, которые трудно воспроизвести.

Хрупко при изменении формулировки. “Парсинг даты из имени файла” — AI может промахнуться если файл назвали чуть иначе. Регулярка не промахнётся.

Требует evaluation. Если AI делает работу скрипта, вы обязаны проверять каждый его ответ. Иначе тихая ошибка пройдёт в продакшен.

Примеры из моей инфраструктуры

У меня в C:\Projects\_system\scripts\ лежит набор PowerShell-скриптов с триггер-фразами. Несколько типичных:

Создание нового проекта (new-project.ps1):

• Триггер-фразы: “создай проект”, “новый проект”, “create project”, “init project”
• Что делает: создаёт структуру папок по шаблону, инициализирует git, ставит .claude/, генерирует CLAUDE.md-заглушку, делает первый commit
• Почему это скрипт, а не промпт: каждый шаг — детерминированный. AI здесь не нужен, он только добавит вариативность и токены

Архивация старого проекта:

• Если последний commit был >180 дней назад и нет ветки в работе — переносим в _archive/
• Чистый if-then, AI не нужен

Бэкап критичных директорий:

• Список путей известен, расписание известно, формат архива стандартный
• Скрипт через Windows Task Scheduler, никакого AI

Что НЕ скрипт, а промпт:

• “Разобрать новую статью из raw/” — нужно понимание, классификация, оценка применимости
• “Провести идея-applicability check” — суждение
• “Рефакторинг функции X” — творческая задача

Триггер-фразы как мост между разговором и скриптом

У меня в CLAUDE.md есть раздел “Script Triggers”:

## Script Triggers
Когда запрос матчит паттерн — запустить скрипт, не выдумывать структуру с нуля.

**Новый проект** → "создай проект", "новый проект", "create project"
→ Извлечь: Name (спросить если не указано), Type (code/docs/finance)
→ Запустить: `.\new-project.ps1 -Name "[Name]" -Type "[Type]"`

Это создаёт мост: я разговариваю с AI — но AI запускает скрипт, когда видит триггер. Я получаю удобство голосового интерфейса + детерминизм скрипта.

Это идеальный компромисс: AI как парсер интента, скрипт как исполнитель.

Как отличить — практическая эвристика

Перед тем как написать промпт для повторяющейся задачи, задайте 4 вопроса:

1. Можно ли описать задачу через if-then? Если да — это скрипт.

2. Нужен ли мне одинаковый результат на одинаковом входе? Если да — это скрипт. AI не гарантирует детерминизм.

3. Буду ли я делать это больше 10 раз? Если да — скрипт окупается. Меньше — может быть промпт.

4. Есть ли в задаче “оценка”, “анализ”, “выбор”, “интерпретация”? Если да — это промпт. AI добавляет ценность.

Если на вопросы 1–3 ответы “да” и 4 — “нет” — пишите скрипт. Не AI.

Стоимость “всё через AI”

Простая арифметика. Допустим, вы автоматизируете задачу “переименовать 500 файлов по паттерну”:

Через AI (Claude Sonnet, API-цены примерные):

• 500 запросов × ~500 input + ~200 output токенов
• ≈ 250к input + 100к output = ~$1 + ~$1.5 = $2.5
• • время на ~10 минут API calls
• • риск что 5-10 файлов получат “странное” имя

Через скрипт (PowerShell с regex):

• 30 минут на написание + тестирование (один раз)
• 0 секунд на выполнение (буквально мгновенно для 500 файлов)
• $0
• 100% детерминированный результат

Скрипт окупается за один прогон. На следующих 50 запусках разница уже значимая.

Когда AI всё-таки нужен в “скриптовой” задаче

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

Из 100 PDF-файлов извлечь даты публикации.

Если дата всегда в одном месте (например, в metadata) — это скрипт. Если дата может быть в разных местах текста, в разных форматах, иногда отсутствовать — нужно суждение. Здесь AI имеет смысл.

Правильный паттерн: разделите задачу. Скрипт делает детерминированную часть (открывает файл, парсит metadata, ходит по структуре). AI делает часть с суждением (находит дату в свободном тексте). Не смешивайте.

Чек-лист: это скрипт или промпт?

Перед автоматизацией повторяющейся задачи:

• Можно описать через if X then Y? → скрипт
• Нужен одинаковый результат на одинаковом входе? → скрипт
• Больше 10 повторений? → скрипт окупится
• Есть оценка / анализ / выбор? → промпт
• Можно ли разделить на детерминированную часть + часть с суждением? → гибрид: скрипт + AI на куске

Заключение

AI-хайп ставит знак равенства между “автоматизация” и “AI”. Это неправильно. Автоматизация шире, чем AI, и большая часть рутины — это именно скриптовая работа, а не AI-работа.

Принцип Script > Model — это дисциплина выбора правильного инструмента. Не “AI как default, скрипт как исключение”. А: детерминированная задача → скрипт, суждение → AI.

Когда вы перестаёте использовать AI как “молоток для всех гвоздей”, три вещи происходят сразу:

1. Квота / счёт за API падает значимо
2. Скорость работы вырастает (скрипты быстрее запросов к LLM)
3. Доверие к AI растёт — потому что вы используете его там, где он реально нужен

И отдельная польза: писать скрипт — это дисциплина точной формулировки задачи. Если вы не можете написать скрипт, вы скорее всего и не понимаете задачу до конца.

Перед следующей автоматизацией спросите себя: “Это if-then или суждение?” Если if-then — пишите скрипт. AI оставьте для задач, где он реально незаменим.