Инженерия промптов
Объединяйте сложные запросы для повышения производительности
Инженерия промптов
Объединяйте сложные запросы для повышения производительности
При работе со сложными задачами Claude иногда может допускать ошибки, если вы пытаетесь решить все в одном запросе. Цепочка мыслей (CoT) - отличный подход, но что если ваша задача состоит из нескольких отдельных шагов, каждый из которых требует глубокого размышления?
Представляем объединение запросов: разбиение сложных задач на более мелкие, управляемые подзадачи.
Зачем объединять запросы?
- Точность: Каждая подзадача получает полное внимание Claude, что снижает количество ошибок.
- Ясность: Более простые подзадачи означают более четкие инструкции и результаты.
- Отслеживаемость: Легко выявлять и исправлять проблемы в цепочке запросов.
Когда объединять запросы
Используйте объединение запросов для многоэтапных задач, таких как синтез исследований, анализ документов или итеративное создание контента. Когда задача включает в себя несколько преобразований, цитат или инструкций, объединение предотвращает пропуск или неправильную обработку шагов Claude.
Помните: Каждое звено в цепочке получает полное внимание Claude!
Совет по отладке: Если Claude пропускает шаг или плохо выполняет его, изолируйте этот шаг в отдельном запросе. Это позволяет точно настроить проблемные шаги без повторного выполнения всей задачи.
Как объединять запросы
- Определите подзадачи: Разбейте задачу на отдельные последовательные шаги.
- Структурируйте с помощью XML для четкой передачи: Используйте XML-теги для передачи результатов между запросами.
- Имейте цель для одной задачи: Каждая подзадача должна иметь одну четкую цель.
- Итерируйте: Уточняйте подзадачи на основе производительности Claude.
Примеры объединенных рабочих процессов:
- Многоэтапный анализ: См. юридические и бизнес-примеры ниже.
- Конвейеры создания контента: Исследование → Структура → Черновик → Редактирование → Форматирование.
- Обработка данных: Извлечение → Преобразование → Анализ → Визуализация.
- Принятие решений: Сбор информации → Список вариантов → Анализ каждого → Рекомендация.
- Циклы проверки: Создание контента → Проверка → Уточнение → Повторная проверка.
Совет по оптимизации: Для задач с независимыми подзадачами (например, анализ нескольких документов) создавайте отдельные запросы и запускайте их параллельно для ускорения.
Продвинутый уровень: Цепочки самокоррекции
Вы можете объединять запросы, чтобы Claude проверял свою собственную работу! Это позволяет обнаруживать ошибки и уточнять результаты, особенно для ответственных задач.
Запрос 1
| Роль | Содержание |
|---|---|
| Пользователь | Обобщите эту медицинскую исследовательскую статью. <paper>{{RESEARCH_PAPER}}</paper> Сосредоточьтесь на методологии, результатах и клинических выводах. |
| Ассистент {{SUMMARY}} | Методология: Двойное слепое РКИ с 500 пациентами с диабетом 2 типа. Группа A (n=250) получала новый двойной агонист GLP-1/GIP; Группа B (n=250) получала стандартный агонист GLP-1. 24-недельное исследование, первичная конечная точка: снижение HbA1c. Результаты: - Группа A: среднее снижение HbA1c на 1,8% - Группа B: среднее снижение HbA1c на 1,1% - 68% группы A против 52% группы B достигли HbA1c <7% - Группа A: среднее снижение веса на 5,2 кг - Группа B: среднее снижение веса на 3,1 кг Безопасность: Схожие профили нежелательных явлений, серьезных событий, связанных с лечением, не было. Клинические выводы: Двойной агонист показывает превосходный гликемический контроль и снижение веса по сравнению со стандартной терапией. Может стать прорывом, особенно для пациентов с ожирением и диабетом. |
Запрос 2
| Роль | Содержание |
|---|---|
| Пользователь | Ваша задача - дать обратную связь по резюме исследовательской статьи. Вот резюме медицинской исследовательской статьи: <summary> {{SUMMARY}} </summary> Вот исследовательская статья: <paper> {{RESEARCH_PAPER}} </paper> Проверьте это резюме на точность, ясность и полноту по шкале оценок от A до F. |
| Ассистент {{FEEDBACK}} | 1. Точность: A - Правильно указаны ключевые показатели: снижение HbA1c, потеря веса. - Точно отмечены профиль безопасности и отсутствие серьезных нежелательных явлений. - Утверждение о “прорыве” оправдано значительно лучшими результатами. 2. Ясность: A- - Краткое и хорошо структурированное с четкими разделами. - Хорошее использование сравнительного языка (например, “на 3% выше, чем в 1 квартале”) для контекста. - Незначительная проблема: Аббревиатуры “РКИ”, “GLP-1” и “GIP” не расшифрованы. Рассмотрите возможность расшифровки при первом использовании. 3. Полнота: B+ - Охватывает все запрошенные области: методологию, результаты, клинические выводы. - Отсутствует: Исходные характеристики групп (были ли они хорошо сопоставимы?). - Отсутствует: Любые вторичные конечные точки (например, артериальное давление, липиды). - Рассмотрите: Долгосрочные последствия или необходимость дальнейших исследований. В целом, резюме является точным и ясным, предоставляя ключевые выводы для быстрого понимания исследования. Чтобы повысить оценку до A+, расшифруйте аббревиатуры, упомяните исходные статистические данные групп, отметьте любые вторичные результаты и кратко коснитесь необходимости долгосрочных исследований. |
Запрос 3
| Роль | Содержание |
|---|---|
| Пользователь | Ваша задача - улучшить резюме статьи с учетом обратной связи. Вот первый черновик резюме медицинской исследовательской статьи: <summary> {{SUMMARY}} </summary> Вот исследовательская статья: <paper> {{RESEARCH_PAPER}} </paper> Вот обратная связь: <feedback> {{FEEDBACK}} </feedback> Обновите резюме на основе обратной связи. |
| Ассистент | Методология: Двойное слепое рандомизированное контролируемое исследование (РКИ) с участием 500 пациентов с сахарным диабетом 2 типа. Группа A (n=250) получала новый двойной агонист глюкагоноподобного пептида-1/глюкозозависимого инсулинотропного полипептида (GLP-1/GIP); Группа B (n=250) получала стандартный агонист GLP-1. Первичной конечной точкой 24-недельного исследования было снижение HbA1c. Группы были хорошо сопоставимы по возрасту, ИМТ и исходному HbA1c. Результаты: - Группа A: среднее снижение HbA1c на 1,8% - Группа B: среднее снижение HbA1c на 1,1% - 68% группы A против 52% группы B достигли HbA1c <7% - Группа A: среднее снижение веса на 5,2 кг - Группа B: среднее снижение веса на 3,1 кг Вторичные конечные точки показали улучшение артериального давления и липидного профиля в обеих группах, при этом группа A показала несколько лучшие результаты. Безопасность: Схожие профили нежелательных явлений, серьезных событий, связанных с лечением, не было. Клинические выводы: Двойной агонист GLP-1/GIP демонстрирует превосходный гликемический контроль и снижение веса по сравнению со стандартной терапией GLP-1. Эти результаты предполагают, что он может стать значительным прогрессом, особенно для пациентов с ожирением и диабетом. Однако необходимы более долгосрочные исследования для подтверждения устойчивой эффективности и безопасности, а также для изучения потенциальных преимуществ в отношении сердечно-сосудистых исходов. |
Примеры
Обратите внимание, что Claude пропускает инструкцию о предоставлении предлагаемых изменений в черновике электронного письма.
| Роль | Содержание |
|---|---|
| Пользователь | Вы наш главный юрисконсульт. Проверьте этот контракт SaaS на предмет рисков, уделяя особое внимание конфиденциальности данных, SLA и ограничениям ответственности. <contract> {{CONTRACT}} </contract> Затем составьте электронное письмо поставщику с вашими опасениями и предлагаемыми изменениями. |
| Ассистент | После рассмотрения контракта SaaS я выявил несколько проблем: 1. Конфиденциальность данных (Раздел 7): - Проблема: Поставщик имеет широкие права на использование клиентских данных для “улучшения сервиса”. - Риск: Может привести к несанкционированному обмену данными или их монетизации. 2. SLA (Раздел 5): - Проблема: Гарантия доступности 99,5% ниже отраслевого стандарта. - Риск: Чрезмерный простой может повлиять на нашу работу. 3. Ответственность (Раздел 9): - Проблема: Ограничение установлено в размере 3-месячной платы. - Риск: Недостаточно для потенциальных утечек данных или сбоев в обслуживании. Черновик письма: Уважаемый {{VENDOR}}, После рассмотрения соглашения SaaS у нас есть опасения: 1. Конфиденциальность данных: Мы требуем, чтобы наши данные использовались только для непосредственного предоставления услуг, а не для широкого “улучшения сервиса”. Пожалуйста, измените Раздел 7. 2. SLA: Доступность 99,5% недостаточна. Нам нужно 99,99% с четко определенными штрафами. Пожалуйста, пересмотрите Раздел 5. 3. Ответственность: Текущее ограничение в размере 3-месячной платы неадекватно. Мы предлагаем ограничение в размере 12-месячной платы, без ограничений за утечки данных или умышленные нарушения. Мы ценим наше потенциальное партнерство и считаем, что эти изменения под готовят нас к успеху. Пожалуйста, пришлите пересмотренное соглашение. С уважением, {{CLO_NAME}} |
Запрос 1
| Роль | Содержание |
|---|---|
| Пользователь | Вы наш главный юрисконсульт. Проверьте этот контракт SaaS на предмет рисков, уделяя особое внимание конфиденциальности данных, SLA и ограничениям ответственности. <contract> {{CONTRACT}} </contract> Выведите ваши выводы в тегах <risks>. |
| Ассистент {{CONCERNS}} | 1. Конфиденциальность данных (Раздел 7): - Проблема: Поставщик имеет широкие права на использование клиентских данных для “улучшения сервиса”. - Риск: Может привести к несанкционированному обмену данными клиентов или их монетизации. - Влияние: Потенциальное нарушение доверия клиентов, штрафы регуляторов (GDPR, CCPA). 2. SLA (Раздел 5): - Проблема: Гарантия доступности 99,5% ниже отраслевого стандарта (обычно 99,99%). - Риск: До 43,8 часов простоя в год против 52,6 минут при 99,99%. - Влияние: Сбои в работе, потеря дохода, недовольство клиентов. 3. Ответственность (Раздел 9): - Проблема: Ограничение ответственности установлено в размере 3-месячной платы. - Риск: Недостаточно для потенциальных утечек данных, кражи интеллектуальной собственности или длительных сбоев в обслуживании. - Влияние: Недостаточная компенсация ущерба, который может намного превысить ограничение, например, коллективные иски или штрафы регуляторов. |
Запрос 2
| Роль | Содержание |
|---|---|
| Пользователь | Составьте электронное письмо поставщику продукта SaaS с изложением следующих опасений и предлагаемых изменений. Вот опасения: <concerns> {{CONCERNS}} </concerns> |
| Ассистент {{EMAIL}} | Уважаемый {{VENDOR}}, После тщательного рассмотрения предлагаемого соглашения SaaS наша юридическая команда выявила несколько проблем высокого приоритета, которые необходимо решить, прежде чем мы сможем продолжить: 1. Конфиденциальность данных (Раздел 7): - Текущая версия: Широкие права на использование клиентских данных для “улучшения сервиса”. - Опасение: Потенциальный несанкционированный обмен данными или их монетизация. - Предлагаемое изменение: Ограничить использование данных непосредственным предоставлением услуг. Любое использование для улучшения, аналитики или маркетинга должно быть добровольным, отзывным и анонимным. 2. SLA (Раздел 5): - Текущая версия: Гарантия доступности 99,5%. - Опасение: До 43,8 часов простоя в год, риск сбоев в работе. - Предлагаемое изменение: 99,99% доступности с многоуровневыми сервисными кредитами. Например, 10% кредит за <99,99%, 25% за <99,9%, 50% за <99,5%. 3. Ответственность (Раздел 9): - Текущая версия: Ограничение в размере 3-месячной платы. - Опасение: Крайне недостаточно для утечек данных, кражи интеллектуальной собственности или длительных простоев. - Предлагаемое изменение: 12-месячная плата за общую ответственность. Без ограничений за утечки данных, умышленные нарушения, нарушения прав интеллектуальной собственности. Эти изменения не подлежат обсуждению для нас. Они соответствуют отраслевым стандартам и нашей приверженности безопасности данных, операционному совершенству и фидуциарной ответственности. Мы ценим потенциал нашего партнерства, и решение этих вопросов создаст прочную основу. Пожалуйста, попросите вашу юридическую команду рассмотреть и внести эти изменения. Мы будем рады обсудить дальнейшие детали, чтобы обеспечить взаимопонимание и согласие. С уважением, {{CLO_NAME}} |
Запрос 3
| Роль | Содержание |
|---|---|
| Пользователь | Ваша задача - проверить электронное письмо и дать обратную связь. Вот письмо: <email> {{EMAIL}} </email> Дайте обратную связь по тону, ясности и профессионализму. |
| Ассистент | 1. Тон: - Профессиональный и уверенный без конфронтации. - Использование “не подлежит обсуждению” является сильным, но оправданным, учитывая критичность проблем. - Язык сотрудничества (“мы ценим”, “будем рады обсудить”) уравновешивает твердость, сохраняя конструктивный тон. 2. Ясность: - Отличная структура: текущее состояние, опасение и предлагаемое изменение для каждой проблемы. - Технические термины (например, “EBITDA”, “многоуровневые сервисные кредиты”) уместны для контекста B2B SaaS. - Действия ясны: юридическая команда поставщика должна рассмотреть и внести изменения. 3. Профессионализм: - Фокусируется на взаимной выгоде и отраслевых стандартах, а не только на наших требованиях. - Упоминает более широкие обязанности (безопасность данных, операционное совершенство, фидуциарный долг), поднимая уровень обсуждения. - Предлагает дальнейшее обсуждение, демонстрируя приверженность пониманию и решению проблем. В целом, письмо находит правильный баланс между настойчивостью и сотрудничеством. Оно четко излагает наши опасения, предлагает конкретные решения и сохраняет профессиональный тон, ориентированный на партнерство. Никаких исправлений не требуется; можно отправлять. |
Запрос 1
| Роль | Содержание |
|---|---|
| Пользователь | Как старший архитектор решений, проанализируйте эту стратегию мультиарендности для нашего нового корпоративного SaaS-продукта. <strategy> {{STRATEGY}} </strategy> Сосредоточьтесь на масштабируемости, безопасности и экономической эффективности. |
| Ассистент {{ANALYSIS}} | 1. Масштабируемость: + Шардинг базы данных по арендаторам снижает конкуренцию, поддерживает высокий рост. + Микросервисы позволяют независимо масштабировать компоненты. - Общие серверы приложений могут стать узким местом при экстремальной нагрузке. - Нет упоминания об автомасштабировании или балансировке нагрузки для уровня приложений. 2. Безопасность: + Изоляция данных арендаторов через шардинг снижает риск утечек данных. + JWT с коротким сроком действия и токенами обновления - отраслевая лучшая практика. - Нет упоминания о шифровании (в покое, в пути) или управлении ключами. - Стратегия IAM не содержит деталей о ролях, разрешениях или RBAC. 3. Экономическая эффективность: + Общие серверы приложений снижают затраты на простаивающие ресурсы. + Бессерверные функции для редких задач оптимизируют затраты. - База данных для каждого арендатора может увеличить затраты в масштабе по сравнению с оптимизированной мультиарендной базой данных. - Нет обсуждения зарезервированных или спотовых экземпляров для экономии затрат. |
Запрос 2
| Роль | Содержание |
|---|---|
| Пользователь | Составьте документ с обзором стратегии для руководства инженерного отдела на основе этого анализа стратегии мультиарендности. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Включите краткое содержание, подробный анализ и рекомендации. |
| Ассистент {{STRATEGY_DOC}} | # Обзор стратегии мультиарендности: Корпоративный SaaS-продукт ## Краткое содержание Предлагаемая стратегия демонстрирует прочную основу в принципах масштабируемости и безопасности, но имеет пробелы в деталях реализации. Она превосходна в изоляции данных и масштабировании на уровне компонентов, но не хватает надежного масштабирования уровня приложений и расширенных мер безопасности. Оптимизация затрат присутствует, но может дать сбой при высоком масштабе. С целенаправленными улучшениями эта стратегия может эффективно поддерживать наши корпоративные амбиции SaaS. ## Подробный анализ ### 1. Масштабируемость: B+ Сильные стороны: - Шардинг базы данных по арендаторам отличный. Он минимизирует задержку запросов, поддерживает высокий рост данных и обеспечивает бесшовное масштабирование для каждого арендатора. - Архитектура микросервисов позволяет масштабировать отдельные компоненты в зависимости от спроса, что важно для обработки разнообразных корпоративных нагрузок. Слабые стороны: - Общие серверы приложений рискуют стать узким местом. По мере роста количества арендаторов и трафика они могут снизить производительность для всех арендаторов. - Отсутствие автомасштабирования и балансировки нагрузки для уровня приложений является критическим упущением. Они необходимы для обработки всплесков трафика без избыточного выделения ресурсов. ### 2. Безопасность: B- Сильные стороны: - Шардированные базы данных обеспечивают надежную изоляцию данных арендаторов, снижая риски утечек данных или несанкционированного доступа между арендаторами. - JWT с коротким сроком действия и токенами обновления соответствуют лучшим практикам OWASP, сокращая окна уязвимости токенов. Слабые стороны: - Нет упоминания о шифровании данных в покое или в пути (TLS 1.3). Это не обсуждается для корпоративных данных. - Отсутствует стратегия управления ключами. Как управляются и ротируются ключи шифрования, секреты JWT и учетные данные базы данных? - IAM не хватает глубины. Нам нужен RBAC с четко определенными ролями, контроль доступа на основе атрибутов (ABAC) для детальных разрешений и интеграция с корпоративными поставщиками удостоверений (SAML, OIDC). ### 3. Экономическая эффективность: B Сильные стороны: - Общие серверы приложений снижают затраты на простаивающие мощности, х орошо для трафика в стабильном состоянии. - Бессерверные функции для редких задач (например, отчетов) разумны; оплата только при использовании этих ресурсов. Слабые стороны: - Базы данных для каждого арендатора могут быть неэкономичными в масштабе по сравнению с хорошо спроектированной мультиарендной базой данных с надежным разделением данных. - Нет упоминания о мерах экономии затрат, таких как зарезервированные экземпляры для предсказуемых нагрузок или спотовые экземпляры для отказоустойчивых задач. - Отсутствие автомасштабирования уровня приложений может привести к избыточному выделению ресурсов, увеличивая затраты. ## Рекомендации 1. Устойчивость уровня приложений: Реализуйте автомасштабирование с Kubernetes или облачными сервисами (EKS, GKE). Разверните в нескольких зонах доступности с CDN для статических ресурсов. 2. Усиление безопасности: a. Шифруйте данные в покое (AES-256) и в пути (TLS 1.3). b. Используйте управляемый KMS (AWS KMS, GCP KMS) для управления ключами. c. Улучшите IAM с RBAC, ABAC и SAML/OIDC для корпоративного SSO. 3. Оптимизация затрат: a. Оцените колоночную мультиарендную базу данных (например, Snowflake) против шардинга в масштабе. b. Используйте зарезервированные экземпляры для серверов приложений, спотовые экземпляры для некритичных нагрузок. c. Внедрите проактивный мониторинг и правильный выбор размеров, чтобы избежать избыточного выделения ресурсов. 4. Proof of Concept (PoC): Перед полной реализацией проведите PoC с моделированием высокого масштаба: a. Протестируйте шардированную базу данных против оптимизированной мультиарендной базы данных на предмет затрат и производительности. b. Нагрузочное тестирование уровня приложений с моделированием всплесков трафика корпоративного уровня. c. Проведите сторонний аудит безопасности, сосредоточившись на изоляции данных и контроле доступа. С этими улучшениями наша стратегия мультиарендности будет корпоративного уровня: масштабируемой, безопасной и экономически эффективной. PoC подтвердит наш выбор дизайна и вселит уверенность в наших корпоративных клиентов. |
Запрос 3
| Роль | Содержание |
|---|---|
| Пользователь | Оцените этот документ с обзором стратегии на предмет ясности, выполнимости и соответствия корпоративным приоритетам. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Ассистент | 1. Ясность: A + Четкая структура с кратким содержанием, подробным анализом и рекомендациями. + Анализ использует систему оценок (B+, B-) для быстрого понимания сильных/слабых сторон. + Технические термины (RBAC, ABAC, TLS) объяснены или контекстуализированы, помогая нетехническому руководству. + Визуальные средства (маркеры списка, отступы) повышают читаемость. 2. Выполнимость: A- + Рекомендации конкретны и технически обоснованы (например, “Реализуйте автомасштабирование с Kubernetes”). + План PoC с четкими целями обеспечивает дорожную карту. + Отсутствуют: Сроки, требования к ресурсам или назначения команд для каждой рекомендации. + Рассмотрите: Добавьте раздел “Следующие шаги” с немедленными действиями, ролями и общим графиком. 3. Соответствие корпоративным приоритетам: A+ + Напрямую решает корпоративные приоритеты: - Масштабируемость: Обсуждает обработку всплесков трафика корпоративного уровня. - Безопасность: Фокусируется на изоляции данных, шифровании и корпоративном IAM. - Затраты: Стратегии соответствуют корпоративному FinOps (зарезервированные экземпляры, правильный выбор размеров). + PoC с “моделированием высокого масштаба” и аудитом безопасности демонстрирует приверженность качеству корпоративного уровня. + Язык резонирует с корпоративными проблемами: “неприемлемый риск”, “корпоративный уровень”, “вселяет уверенность”. В целом, документ отлично справляется с ясностью и соответствием корпоративным приоритетам. Выполнимость сильна, но может быть повышена до A+ с разделом “Следующие шаги”. Техническая глубина в сочетании с четкими объяснениями делает это очень эффективным как для технического, так и для нетехнического руководства. Отличная работа! |
Библиотека запросов
Вдохновитесь подборкой запросов для различных задач и вариантов использования.
Руководство по запросам на GitHub
Руководство с множеством примеров, охватывающее концепции разработки запросов, описанные в нашей документации.
Руководство по запросам в Google Sheets
Более легкая версия нашего руководства по разработке запросов через интерактивную таблицу.