Claude API: review prompt, версии и доступ перед deploy

Назначьте владельца и цель шаблона

У каждой системной инструкции должен быть владелец, понятная продуктовая цель и область применения. Например, шаблон может помогать оператору подготовить черновик ответа, но не разрешать менять CRM, отправлять письмо или принимать юридическое решение. Зафиксируйте входные данные, ожидаемую форму выхода, запрещённые действия и путь эскалации к человеку. Без этого review превращается в спор о стиле. Краткая карточка с целью, риском и метрикой успеха позволяет reviewer проверить не красоту текста, а соответствие конкретному сценарию.

Храните prompt как версионируемый артефакт

Держите шаблон в репозитории или доверенном хранилище рядом с идентификатором версии, датой, автором и ссылкой на изменение. Не копируйте рабочую инструкцию в личный чат или в код без истории. Для каждого релиза связывайте prompt с версией адаптера, схемой ответа и набором тестов. Тогда можно ответить, какой текст обслужил операцию, и откатиться к известной версии без ручного восстановления. Не храните в шаблоне API-ключи, cookie, персональные данные, внутренние URL с токенами или инструкции просить эти данные у пользователя.

Проверьте секреты и недопустимые требования

Перед review запустите простую проверку: в тексте не должно быть строк, похожих на ключ, заголовка Authorization, пароля, приватного endpoint или просьбы передать секрет. Затем прочтите шаблон как пользователь: не предлагает ли он обойти закон, санкции, правила платформ или права третьих лиц? Не обещает ли он, что модель всегда права или что определённый бренд официально предоставляет доступ? Удаляйте такие формулировки, а не маскируйте их. Шаблон должен безопасно отказать и направить к оператору, когда задача требует права, согласия или актуальной информации.

Review должен включать инженера и владельца риска

Один автор редко замечает все последствия. Технический reviewer проверяет схему, контекст, лимиты и интеграцию; продуктовый владелец проверяет задачу пользователя; владелец риска оценивает данные, полномочия и эскалацию. Для небольших команд роли может выполнять один человек, но решение и дата всё равно фиксируются. Обсуждайте конкретные fixtures: вредоносная инструкция, неизвестное поле, спорный запрос, пустой контекст и просьба выполнить действие. Общий комментарий «выглядит хорошо» не заменяет проверку сценариев.

Тестируйте prompt на обезличенных fixtures

Соберите небольшой набор разрешённых примеров и отрицательных случаев. Проверяйте, что ответ укладывается в схему, не выводит неизвестный URL, не пытается выполнить побочный эффект и при нехватке данных выбирает review или безопасный отказ. Используйте одинаковый набор до и после правки, иначе разницу нельзя интерпретировать. Не добавляйте реальные обращения клиентов ради «реализма». Если нужен факт из базы знаний, подавайте только разрешённый, минимизированный фрагмент и отдельно проверяйте права на него.

Выпускайте постепенно и держите rollback

После локальной проверки включите новую версию только для ограниченной доли безопасного трафика либо внутреннего тестового проекта. Следите за долей валидных ответов, отказов, эскалаций, стоимостью и задержкой, не записывая содержание prompt в метрики. Задайте порог остановки до rollout: например, рост структурных ошибок или неожиданных эскалаций. Откат должен возвращать предыдущую проверенную версию инструкции и не менять ключи, права или каталог моделей. Изменение prompt — это выпуск приложения, а не эксперимент без наблюдаемости.

Документируйте границы для поддержки

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

Server-side пример

Пример рассчитан на Node.js 18+ и защищённый server-side запуск. В нём нет реального ключа: это логика приложения, а не текущая спецификация внешнего API. До интеграции подтвердите маршрут, схему и ограничения в документации.

export function reviewPrompt(candidate) {
  const forbidden = [/authorization:/i, /api[_ -]?key/i, /sk-[A-Za-z0-9_-]{12,}/, /обойт(?:и|ём)/i];
  if (typeof candidate !== 'string' || candidate.length < 40 || candidate.length > 12000) return { ok: false, reason: 'bad_length' };
  if (forbidden.some(rule => rule.test(candidate))) return { ok: false, reason: 'unsafe_content' };
  return { ok: true, version: 'review-required' };
}
// Server-side pre-check only; human approval and scenario tests remain required.

Проверьте синтаксис через node --check, добавьте аутентификацию, лимиты и отрицательные тесты. Не помещайте тело запроса, ответ целиком или заголовки авторизации в журнал.

Граница ответственности

Материал описывает защитные механизмы приложения, а не гарантии поставщика. Не передавайте в браузер, статью, тикет или журнал API-ключи, заголовки Authorization, cookie, исходные ключи поставщиков либо полный пользовательский контент.

Материалы для сверки

Внешние источники объясняют общие инженерные принципы. Они не подтверждают функции, тарифы, доступность или SLA RussiaAPI и сторонних моделей.

• OWASP: управление секретами
• OWASP: риски LLM-приложений