TL;DR
Governance Conversion — принцип работы с AI: когда модель делает одну и ту же ошибку дважды, это сигнал не поправить конкретный ответ, а добавить явное ограничение в промпт или задачу, которое сделает эту ошибку невозможной или заметной в будущем. Цикл простой: ошибка → диагноз → правило.
Когда AI постоянно отклоняется от нужного формата или тона, большинство пользователей исправляют каждый ответ вручную — снова и снова. Это значит тратить своё внимание на симптомы, а не на причину. Причина всегда структурная: в промпте нет ограничения, которое бы направляло модель правильно с самого начала.
Метод предлагает два способа реагирования на повторяющиеся сбои. Первый — устрани класс ошибок: переформулируй задачу или структуру промпта так, чтобы ошибка просто не могла возникнуть. Второй — добавь проверку: сделай явный список критериев, который ты или модель проверяет после каждого ответа. Наблюдение за паттернами — это и есть твоя главная работа с AI.
Схема метода
Цикл выполняется в голове + через отдельный запрос к модели:
ШАГ 1: НАБЛЮДЕНИЕ
Замечаешь, что AI делает одну и ту же ошибку повторно
→ Записываешь: "что именно пошло не так и при каких условиях"
ШАГ 2: ДИАГНОСТИКА (запрос к модели)
Спрашиваешь: "это случайность или структурная проблема?"
→ Получаешь: категорию сбоя + объяснение причины
ШАГ 3: ВЫБОР РЕАКЦИИ
Вариант А — АРХИТЕКТУРНЫЙ ФИX:
Переформулируй задачу/промпт так, чтобы ошибка стала невозможной
→ Новая структура промпта без уязвимости
Вариант Б — КОНТРОЛЬ:
Добавь явное правило-запрет или чеклист для проверки
→ Правило в системном промпте / инструкции
ШАГ 4: КОДИФИКАЦИЯ
Записываешь новое правило в свой «банк ограничений»
→ Растущий список правил для повторяющихся задач
Пример применения
Задача: Светлана — контент-директор бренда одежды, регулярно использует Claude для написания постов во ВКонтакте. Модель раз за разом делает одно и то же: пишет слишком корпоративно, использует «Мы рады представить» и похожие обороты, хотя Светлана просила живой разговорный тон. Она устала исправлять каждый раз вручную.
Промпт для диагностики и конвертации ошибки в правило:
Я регулярно создаю посты для бренда молодёжной одежды, и Claude
постоянно делает одни и те же ошибки.
Вот ошибки, которые повторяются:
1. Использует канцелярные обороты: "рады представить", "в рамках",
"данный продукт"
2. Начинает посты с "Мы" — хотя бренд говорит от лица подруги,
не компании
3. Добавляет призыв "Переходи в магазин" в конце — звучит как реклама
Сделай следующее:
— Для каждой ошибки скажи: это случайность или структурная проблема
(AI будет повторять без явного запрета)?
— Для структурных ошибок предложи два варианта исправления:
А) как переформулировать задачу, чтобы ошибка стала невозможной
Б) явное правило-запрет, которое добавить в промпт
— Собери финальную версию промпта для постов с встроенными
ограничениями — чтобы я использовала его как шаблон
Результат:
Модель разберёт каждую ошибку и объяснит почему она структурная (нет явного запрета) или случайная (зависит от конкретного запроса). Для каждой структурной предложит: либо изменение формулировки задачи (например, «пиши от лица конкретного персонажа — Маши, 24 года»), либо явные правила-запреты. В финале выдаст готовый шаблон промпта с встроенными ограничениями — его можно использовать при каждом следующем запросе.
Почему это работает
Модель не помнит прошлые ошибки. Каждый новый чат — чистый лист. Нет памяти о том, что прошлый раз ты попросил убрать канцелярит. Поэтому ручное исправление не учит модель — оно тратит твоё внимание.
Модель следует тому, что написано в промпте. Если ограничение явно записано — она его соблюдает. Если не записано — генерирует по умолчанию. Это не баг, это механика: модель заполняет пустоту наиболее вероятным паттерном из обучающих данных. Твоя работа — убрать пустоту.
Два типа ограничений работают по-разному. Архитектурный фикс убирает пространство для ошибки — «пиши от лица Маши» исключает корпоративный тон лучше, чем «не пиши корпоративно». Контроль добавляет явный барьер — список запрещённых оборотов, которые модель проверяет в конце. Рычаги управления:
- Насколько жёстко правило — "старайся избегать" vs "НИКОГДА не используй" → жёсткость формулировки влияет на соблюдение
- Архитектура vs правило — переформулировка задачи устойчивее, чем список запретов
- Банк правил — чем больше накопленных ограничений, тем меньше ручных правок со временем
Шаблон промпта
Я регулярно использую AI для задачи: {описание задачи}.
Вот ошибки, которые модель повторяет раз за разом:
— {ошибка 1}
— {ошибка 2}
— {ошибка 3}
Сделай следующее:
Для каждой ошибки определи:
- Это структурная проблема (без явного правила будет повторяться)
или случайная?
- Почему именно: что в текущей формулировке задачи позволяет
этой ошибке возникнуть?
Для каждой структурной ошибки предложи оба варианта:
A) АРХИТЕКТУРНЫЙ ФИX: как переформулировать задачу / сменить
структуру промпта, чтобы ошибка стала невозможной
Б) ПРАВИЛО-ЗАПРЕТ: явная инструкция, которую добавить в промпт
Собери финальную версию промпта для задачи {описание задачи}
с встроенными ограничениями из анализа выше.
Плейсхолдеры:
- {описание задачи} — что ты делаешь регулярно: «написание постов для Telegram», «составление коммерческих предложений», «анализ отзывов»
- {ошибка 1-3} — конкретно что не так: не «плохой тон», а «использует слово "осуществить"», «добавляет вывод, который я не просил»
🚀 Быстрый старт — вставь в чат:
Вот шаблон Governance Conversion. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какую задачу ты делаешь регулярно и какие ошибки повторяются — потому что без конкретного списка повторяющихся сбоев она не сможет диагностировать структурные причины и предложить точные ограничения.
Ограничения
⚠️ Работает только с повторяющимися задачами: Если запрос разовый — нет смысла. Метод ценен там, где одна и та же структура запроса используется регулярно.
⚠️ Требует наблюдательности: Нужно замечать паттерны ошибок, а не просто раздражаться. Если не записываешь что пошло не так — конвертировать нечего.
⚠️ Правила конфликтуют: Если накопишь слишком много ограничений в одном промпте, модель начнёт нарушать одни ради соблюдения других. Периодически нужно ревизировать банк правил.
⚠️ Контроль слабее архитектуры: Список запретов модель соблюдает хуже, чем переформулированную задачу. Если можешь переструктурировать промпт — это надёжнее, чем добавлять «никогда не делай X».
Как исследовали
Идея была простой: один опытный профессор программирования 12 недель строил реальный продукт исключительно с помощью Claude через VSCode-плагин — и вёл дневник. Он сознательно почти не смотрел на код, который генерировала модель. Всё внимание — на паттерны сбоев и на то, как он на них реагировал.
В итоге накопилось 88 полевых заметок, 18 662 коммитов и примерно 1,6 миллиона строк кода. Исследователи разобрали каждый инцидент как «критическое событие»: что спровоцировало, как отреагировал инженер, какое изменение внёс, что изменилось после. Второй автор независимо перекодировал выборку из 10 инцидентов — совпадение по основным категориям 10 из 10.
Самое интересное в дизайне: LLM использовались как инструменты качественного анализа — нормализовать заметки и сравнивать инциденты с кандидатскими классификациями. Интерпретацию оставили людям. Получился своеобразный мета-уровень: AI помогал изучать то, как люди работают с AI.
Из 72 инженерных инцидентов 35 касались контролей (добавил тест, линтер, валидатор) и 20 — архитектуры (изменил структуру так, чтобы ошибка стала невозможной). Это и есть ядро вывода: проблема не в конкретной ошибке, а в отсутствии правила. Неожиданный вывод: человек написал почти нулевой код, но при этом построил рабочий продукт на 400 тысяч строк — всё внимание ушло на direction, interpretation, abstraction.
Адаптации и экстраполяции
🔧 Техника: «Еженедельный аудит промптов» → накопительный эффект
Раз в неделю выдели 10 минут: вспомни все случаи, когда AI раздражал или требовал правок. Прогони список через диагностический промпт. Добавь 1-2 новых правила в свой «системный промпт» для регулярных задач. Через месяц количество правок упадёт заметно.
🔧 Техника: Два типа реакции как ментальный фильтр
Каждый раз когда правишь AI вручную — задай себе один вопрос: «Если я ничего не добавлю в промпт — это повторится?» Если да — это структурная проблема, и ты тратишь внимание впустую. Это перестраивает интуицию: ты начинаешь видеть не ошибки, а сигналы о пропущенных ограничениях.
Ресурсы
Работа: Cheap Code, Costly Judgment: A Case Study on Governable Agentic Software Engineering (2025)
Авторы: James C. Davis, Paschal C. Amusuo, Tanmay Singla, Berk Çakar, Kirsten A. Davis — Purdue University
Связанные концепции: governance-centric agentic SE, governance conversion theory, AGENTS.md