Fits Calc
ИИ для инженера · Промпты · часть 10/10

Промпт: Generator + reviewer без ложной независимости

Готовый инженерный шаблон для задачи: generator + reviewer без ложной независимости.

Назначение шаблона

Этот материал даёт готовый prompt, чтобы generator + reviewer без ложной независимости. Он специально построен для инженерного review: модель обязана сохранить исходные данные, показать допущения и назвать то, что она не смогла подтвердить.

Модели и тарифы меняются. GPT/ChatGPT, Gemini, Claude/Claude Code, локальные модели через Ollama и другие продукты приведены как примеры классов инструментов, а не как рейтинг. Функции, контекст, tools, лимиты, стоимость и доступность зависят от модели, плана, региона и даты. Для ответственного процесса фиксируйте конфигурацию и проверяйте официальную документацию.

Что подготовить

ПолеТребование
цельФактическое значение/описание; для числа — единица; для документа — версия и источник.
объект/узелФактическое значение/описание; для числа — единица; для документа — версия и источник.
исходные данные с единицамиФактическое значение/описание; для числа — единица; для документа — версия и источник.
ограниченияФактическое значение/описание; для числа — единица; для документа — версия и источник.
критерий готовностиФактическое значение/описание; для числа — единица; для документа — версия и источник.
Специальный акцентСильный prompt отделяет цель, факты, ограничения, output schema и критерии проверки.

Готовый промпт

Промпт: Generator + reviewer без ложной независимости
Ты — инженер по агентным workflow и безопасной автоматизации.

ЗАДАЧА
Generator + reviewer без ложной независимости.

РАБОЧИЙ СЦЕНАРИЙ
Generator и reviewer обязаны ссылаться на независимые проверки; второй LLM-ответ сам по себе не считается независимым доказательством.

ИСХОДНЫЕ ДАННЫЕ
- цель: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- объект/узел: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- исходные данные с единицами: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- ограничения: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- критерий готовности: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]

ОБЯЗАТЕЛЬНЫЕ ПРАВИЛА
1. Не придумывай отсутствующие числа, размеры, свойства, стандарты, ссылки, паспортные параметры или результаты испытаний.
2. Не меняй значения и единицы молча. Любое преобразование покажи отдельно.
3. Разделяй ФАКТ ИЗ ВХОДА / ИЗВЛЕЧЁННЫЙ ФАКТ / ВЫЧИСЛЕНИЕ / ИНТЕРПРЕТАЦИЮ / ДОПУЩЕНИЕ.
4. Если критического входа или доказательства нет, верни вопрос или статус «требует проверки», а не правдоподобную подстановку.
5. Сначала plan/dry-run; действие разрешено только в заданном workspace и после проверки precondition, postcondition и approval policy.

СПЕЦИФИЧЕСКАЯ ПРОЦЕДУРА
Generator создаёт candidate, reviewer ищет defects по отдельному rubric. Не называй это независимой проверкой, если обе роли используют тот же model/context.

ТРЕБУЕМЫЙ РЕЗУЛЬТАТ
Candidate + reviewer findings; unresolved conflicts; external verification points; final human decision.

ACCEPTANCE
- diff ограничен поставленной задачей
- есть позитивный, негативный и граничный тест
- опасные операции имеют dry-run/backup/rollback
- секреты не помещаются в prompt или репозиторий

ФИНАЛЬНЫЙ SELF-CHECK
- перечисли все новые числа/утверждения, появившиеся не напрямую из входа;
- укажи, чем инженер должен независимо проверить критический результат;
- перечисли незакрытые вопросы;
- не выполняй write/deploy/publish и другие необратимые действия без явного разрешения.

STOP CONDITION
Если без отсутствующего критического параметра, первичного источника или разрешения корректный вывод невозможен — остановись и запроси это явно.

Почему он работает лучше короткой команды

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

Self-check остаётся проверкой внутри той же генеративной системы, поэтому он полезен только как фильтр очевидных несогласованностей. Независимое подтверждение выполняется профильным средством: расчётным модулем, первичным стандартом, CAD/CAE, измерением, unit-test или контрольным экспериментом.

Адаптация под облачную и локальную модель

  • В ChatGPT/GPT, Gemini или Claude передавайте только релевантный контекст и фиксируйте используемый режим/tools.
  • Через API задайте JSON-schema или другой строгий output contract и машинную валидацию.
  • Для локальной LLM через Ollama/другой runtime сохраните тот же контракт, но проверяйте качество на собственном eval-наборе.
  • Если есть web/RAG/коннекторы, явно ограничьте допустимые источники и права на запись.
  • После смены модели, тарифа или системной инструкции повторите эталонные тесты.

Разбор рабочего примера

Промпт: Generator + reviewer без ложной независимости. Рабочий вариант применения: Generator и reviewer обязаны ссылаться на независимые проверки; второй LLM-ответ сам по себе не считается независимым доказательством.

Перед первым запуском заполните placeholders реальными значениями и сохраните исходный prompt как версию. После ответа сравните его с acceptance-критериями статьи: любое новое число, ссылка или действие без происхождения переводится в open question. Для регулярного использования добавьте этот пример в eval-набор и прогоняйте после смены модели, тарифа, runtime или системной инструкции.

Критерии acceptance для этой задачи

Agent-prompt — это политика действий. Помимо цели, он задаёт tools, границы workspace, разрешённые операции, pre/post conditions, лимиты, approval gates и критерий остановки. Агент должен уметь завершить итерацию без действия, если доказательств или разрешений недостаточно.

  • diff ограничен поставленной задачей
  • есть позитивный, негативный и граничный тест
  • опасные операции имеют dry-run/backup/rollback
  • секреты не помещаются в prompt или репозиторий
Мини-пример заполненияПример входа должен содержать реальный объект, измеримые параметры, единицы, ограничения и критерий готовности. Если хотя бы одно критическое поле неизвестно, модель должна вернуть вопрос, а не правдоподобную подстановку.

Контрольный прогон именно для этой задачи

Проверка агентного действия. Агентный prompt обязан задавать разрешения, workspace, precondition, postcondition и критерий остановки. Для первого прогона предпочтительны dry-run или одно обратимое действие; write/deploy/publish проходят отдельный approval gate.

Для «Промпт: Generator + reviewer без ложной независимости» соберите небольшой fixture, где явно присутствуют цель, объект/узел, исходные данные с единицами и ограничения. Сохраните этот набор без изменений: он нужен как эталон для повторного запуска после смены модели, режима, тарифа, system prompt или подключённых tools.

Negative testУдалите или пометьте как неизвестное поле «цель». Хороший ответ не должен молча подставлять правдоподобное значение: он обязан показать, какой вывод заблокирован.
Boundary testИзмените «объект/узел» на граничное, но допустимое значение. Проверьте, изменился ли только тот вывод, который действительно зависит от этого входа.
Conflict testДобавьте противоречие между «исходные данные с единицами» и «ограничения». Модель должна зафиксировать конфликт и запросить правило приоритета, а не самостоятельно выбрать удобный вариант.
Acceptance testПроверьте два обязательных свойства результата: diff ограничен поставленной задачей; есть позитивный, негативный и граничный тест. Затем подтвердите третий критерий — опасные операции имеют dry-run/backup/rollback.

Фиксируйте результат прогона как PASS/FAIL по каждому тесту и сохраняйте причину исправления. Это превращает prompt из одноразового текста в проверяемую инженерную процедуру: последующее обновление модели можно оценить на тех же входах, а не по субъективному впечатлению от нового ответа.

Как запускать шаблон

Сначала заполните все поля, которые реально известны, и не удаляйте placeholder у неизвестного критического параметра — лучше явно написать «нет данных». Первый запуск используйте как draft. Затем сравните ответ с acceptance-критериями выше и верните модели только конкретные замечания, а не просьбу «улучшить всё». Для регулярной задачи сохраните prompt, входной fixture и ожидаемые свойства результата в системе версий. После смены модели/режима повторите минимум три кейса: нормальный, граничный и с отсутствующим критическим входом.

Проверка результата

ЧислаКонтрольный пересчёт и размерности.
НормативыПервичный документ и область применения.
КодSandbox, тестовые данные, diff и rollback.
CAD/CAEНативные измерения, solver/test, а не только изображение.

Когда ответ нужно остановить

  • появились новые исходные числа без источника;
  • ссылка или стандарт не открывается/не относится к задаче;
  • вывод зависит от отсутствующего параметра;
  • модель пытается выполнить write/deploy/publish без разрешения;
  • нет способа восстановить, какие входы дали итог.

Навигация по 10 промптам этой части

Использовать ИИ поверх проверяемых данных Fits Calc

Fits Calc даёт расчётный и справочный контекст; ИИ помогает анализировать, объяснять, оформлять и автоматизировать. Критические числа, геометрия и нормативные требования остаются предметом инженерной проверки.

Открыть Fits Calc →

Источники и документация

  1. OpenAI — Prompt engineering
  2. Google AI — Prompt design strategies
  3. Anthropic — Prompt engineering
  4. NIST — AI Risk Management Framework
Проверено: 02.10.2026Инженерная проверка обязательнаМодели и тарифы меняются