Как выполнять код в Claude API и получать созданные файлы

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

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

Пошаговая настройка

1. Удалите из CSV персональные данные и формулы. Добавьте контрольную сумму и две строки с заранее известным итогом.
2. Загрузите файл способом из актуальной Files API документации и передайте container_upload с file_id в user content.
3. Добавьте code_execution tool точной версии, указанной в актуальном гайде. Не просите shell-доступ к внутренней сети.
4. Попросите вычислить показатели и создать output.csv плюс краткий отчёт о пропусках. Извлеките file_id из response content.
5. Скачайте файл, проверьте MIME, размер, заголовки и контрольные строки. Не доверяйте только текстовому «готово».

После вызова сохраняйте request ID, HTTP-статус, model id, версию инструкции и usage, если он доступен. Таймаут не означает, что операция не произошла: перед повтором проверьте фактическое состояние.

Копируемый шаблон

Открой sales.csv. Колонки: order_id, amount, status.
Не удаляй строки.
Создай output.csv: status, count, sum_amount.
Пустые amount вынеси в errors.csv и не считай нулём.
В ответе укажи file_id обоих файлов и число ошибочных строк.

Не добавляйте просьбу «додумай при необходимости» в задачу извлечения. Отсутствующий факт должен давать null, missing или blocked. Это позволяет отличить незнание от технической ошибки.

Реалистичный пример входа и результата

В CSV три paid по 100, 200 и пустому значению. Ожидается count=2, sum_amount=300 и одна строка в errors.csv. Итог 300 при count=3 считается логической ошибкой.

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

Проверка результата по уровням

Технический уровень: статус, формат, типы, ID и отсутствие секретов. Смысловой: посимвольная сверка чисел, дат, названий и отрицаний. Процессный: таймаут, отказ в доступе, повтор и безопасный откат.

Создайте таблицу с колонками case_id, expected, actual, source, status, error_type. Размечайте format_error, unsupported_claim, wrong_action и security_error отдельно. Иначе красивый средний процент скроет критический вызов не той функции.

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

Контроль в рабочей системе

Разделите вход, сетевой вызов, разбор ответа и бизнес-валидацию. Сначала проверяются размер, тип и права, затем выполняется API-запрос, потом структура и только после неё значения. Невалидный ответ не передаётся следующему узлу.

В журнал кладите hash входа, case_id, модель, версию промпта, request ID, длительность и решение валидатора. Не сохраняйте ключ, персональные данные и полный документ без необходимости. Для операций записи используйте idempotency_key.

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

Приёмка на конкретных данных

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

Для каждого ответа фиксируйте не субъективную оценку, а набор булевых проверок: формат разобран; обязательные поля присутствуют; ID совпал; источник разрешён; действие входит в allowlist; отсутствующий факт отмечен. Итоговый pass получается только при выполнении всех обязательных условий. Текст может быть стилистически слабым и пройти, если задача — точное извлечение; красивый текст с неверным числом обязан провалиться.