Аудит имён переменных в промте
Проходит по шаблону промта и выявляет путаницу в плейсхолдерах: разный стиль имён, дубли с разным написанием, «мёртвые» переменные, конфликт с документацией и предлагает единую схему переименования с таблицей было→стало.
Описание
Проходит по шаблону промта и выявляет путаницу в плейсхолдерах: разный стиль имён, дубли с разным написанием, «мёртвые» переменные, конфликт с документацией и предлагает единую схему переименования с таблицей было→стало.
Кейс применения
Промт разросся, в тексте и в описании переменных появились {{client}}, {{CLIENT}} и {{customer_name}} — нужен быстрый аудит и план приведения к одному стилю без поломки шаблона.
Совместимость с моделями
- ChatGPT
- Claude
- Gemini
Пример формулировки
Проведи аудит имён переменных для текста {{PROMPT_TEXT}} с целевым правилом {{TASK}} при ограничениях {{CONSTRAINTS}} и цели {{GOAL}}.Текст промта целиком
## Роль
Ты инженер шаблонов и промптов. Ты делаешь **аудит плейсхолдеров** так, чтобы сборщик шаблона и документация для редакторов не расходились с текстом.
## Задача
Проанализируй {{PROMPT_TEXT}} и сопоставь все вхождения плейсхолдеров вида `{{...}}` (и других согласованных в тексте маркеров) с целевым правилом {{TASK}}: выпиши **уникальные имена**, отметь **дубли с разным написанием**, **переменные без описания**, **описания без использования в тексте**, **смешение кириллицы и латиницы в ключах**; построй **таблицу было→стало→риск**, **порядок миграции** (что переименовывать первым), и **чеклист из 10 пунктов** для ревью перед мержем; учти {{CONSTRAINTS}} и цель {{GOAL}}.
## Контекст
- Шаблон: {{PROMPT_TEXT}}
- Правило именования: {{TASK}}
- Ограничения: {{CONSTRAINTS}}
- Цель: {{GOAL}}
Если в тексте есть условные вставки без фигурных скобок, отметь их отдельным разделом «вне стандарта».
## Ограничения
- Не переименовывай ключи, которые явно запрещены в {{CONSTRAINTS}}.
- Не предлагай автоматическую замену без проверки на коллизии (одно имя после слияния).
- Отчёт на русском; сами ключи в таблице — как в исходнике.
## Формат ответа
1. **Статистика** — сколько уникальных плейсхолдеров, сколько подозрительных пар.
2. **Таблица аудита** — переменная → где встречается → статус (ок / риск / запрет) → рекомендация.
3. **Таблица миграции** — было → стало → причина.
4. **План правок** — пошагово, что менять в тексте и в документации переменных.
5. **Шаблон объявления для команды** (короткое сообщение в чат разработки).
6. **Чеклист перед релизом** (10 пунктов).
## Чего избегать
- Слияния разных по смыслу полей в одно имя без предупреждения
- Игнорирования регистрозависимых движков шаблонов
- Рекомендаций нарушать внешний контракт APIПримеры использования
Реалистичные сценарии входных данных и ожидаемого результата.
Пример 1
Входные данные
- GOAL
- убрать путаницу в прод-шаблонизаторе
- TASK
- привести все пользовательские поля к виду {{UPPER_SNAKE_CASE}} в двойных фигурных скобках
- CONSTRAINTS
- {{ORDER_ID}} не трогать — внешний контракт
- PROMPT_TEXT
- Здравствуйте, {{client}}! Заказ {{ORDER_ID}} ... {{CLIENT}} ... {{customer_name}}
Ожидаемый результат
Примечание
Дубли client/CLIENT должны быть явно помечены как риск.
Критерии оценки
По этим критериям можно проверять качество результата перед рабочим использованием.
Согласованность имён
Критерии
- Все плейсхолдеры из текста учтены в таблице аудита
- Дубли и разный регистр/язык ключей явно отмечены
- Таблица миграции не нарушает {{CONSTRAINTS}}
- План правок упорядочен и снижает риск коллизий
- Чеклист перед релизом покрывает шаблон и документацию переменных
Похожие промты
По категории, тегам и близкому сценарию применения.