TL;DR
Триада — это схема работы с ИИ для человека, который разбирается в предметной области, но не умеет программировать. Три роли не смешиваются. Эксперт формулирует потребность языком своей профессии и принимает результат. LLM-архитектор (обычный чат) превращает его жалобы в структурированную инструкцию в Markdown: задачи, правки по файлам, критерии приёмки. Кодинг-агент (Cursor и подобные) пишет и чинит код по этой инструкции.
Главная находка: готовые решения «по умолчанию» ломаются в реальной работе, а причина в том, что эксперт сам не знает, что он знает. Модель предложила резать речь на куски фиксированной длины, и они рвали предложения. Агент предложил фильтровать вывод по алфавиту, а это стёрло бы профессиональные аббревиатуры, ради которых инструмент и нужен. Эксперт не мог заранее назвать эти требования. Они всплывали только после провала в боевых условиях. Чинить параметрами было бесполезно, помогало одно: заново сформулировать, для чего нужна функция.
Метод по шагам: вы описываете проблему архитектору → он выдаёт инструкцию с критериями приёмки → агент исполняет → вы тестируете в реальных условиях → сбой возвращается в диалог. Каждая инструкция превращается в письменную фиксацию вашего неявного знания. Мелкие локальные баги можно отдавать напрямую агенту, но редко, чтобы не засорять его контекст.
Схема метода
ШАГ 1: Эксперт описывает боль/потребность профессиональным языком → чат с LLM-архитектором
ШАГ 2: Архитектор раскладывает задачу → Markdown: задачи + правки по файлам + критерии приёмки
ШАГ 3: Кодинг-агент исполняет инструкцию → код
ШАГ 4: Эксперт тестирует в РЕАЛЬНЫХ условиях (не в лаборатории) → вердикт: принято / сбой
ШАГ 5: Сбой → обратно к шагу 1 (формулируем, ДЛЯ ЧЕГО это нужно, а не «подкрути параметр»)
Обходные пути:
• мелкий локальный баг → сразу агенту (намеренно редко)
• смена чата/платформы → заново передать контекст (архитектор и агент не делят память)
Власть: требования и вето — у человека. ИИ — исполнители.
Шаги идут в разных окнах: архитектор — один чат, агент — другой.
Пример применения
Задача: Бухгалтер-фрилансер ведёт десяток ИП на УСН. Выписки из Т-Банка (Тинькофф Бизнес) — это конфиденциальные данные клиентов, в облачные сервисы их загружать нельзя. Нужен локальный инструмент: читает CSV-выписку и раскладывает платежи по статьям доходов и расходов. Программировать он не умеет.
Промпт (для чата-архитектора):
Ты — архитектор-постановщик задач для кодинг-агента. Я бухгалтер, не программист.
Я описываю проблему языком бухгалтерии. Ты НЕ пишешь код. Ты возвращаешь
инструкцию для кодинг-агента в Markdown:
1) список задач с границами (что входит, что не входит);
2) изменения по файлам;
3) критерии приёмки, которые я смогу проверить глазами на реальной выписке.
Проблема: нужно локально (без интернета, данные клиентов не покидают ноутбук)
разбирать CSV-выписку из Т-Банка по ИП на УСН «Доходы минус расходы».
Каждый платёж — в статью: доход, расход принимаемый, расход непринимаемый,
налоги и взносы, личные траты ИП.
Мои неочевидные требования:
— Назначения вроде «Оплата по счёту» ничего не говорят о статье. Угадывать нельзя.
Ошибочная классификация хуже пропуска: такие платежи помечай «требует решения».
— Названия контрагентов и ИНН — главный признак. Их нельзя ни отфильтровать, ни «исправить».
— Результат — таблица, которую я проверю за 10 минут. Никакой «умной» перестановки колонок.
Если не хватает информации для критериев приёмки — сначала задай мне вопросы.
Результат: Архитектор сначала задаст уточняющие вопросы о формате выписки и категориях. Затем вернёт Markdown-документ: задачи с границами, список файлов и изменений, проверяемые критерии приёмки. Например, «платёж без однозначного признака попадает в очередь на ручное решение». Документ вы целиком отдаёте кодинг-агенту. Дальше проверяете на реальной выписке, и каждый сбой превращается в новую формулировку требования.
Почему это работает
Слабость. Знание эксперта в основном неявное: «мы знаем больше, чем можем сказать». Если просто попросить агента «сделай инструмент», он возьмёт типовое решение. Типовое решение не знает ваших условий, и вы узнаёте об этом только когда оно ломается. Плюс кодинг-агент и чат не разделяют память, и информация теряется между окнами.
Сильная сторона LLM. Модель хорошо превращает сырую жалобу в структурированную спецификацию и хорошо исполняет чёткую инструкцию. А эксперт отлично узнаёт неправильное, когда видит его в реальной работе, и умеет объяснить, почему оно неправильное.
Как метод это использует. Письменная формулировка для ИИ принуждает вас проговаривать приоритеты и условия провала, которые раньше были «в руках». Каждая инструкция становится фиксацией неявного знания. Роли жёстко разведены: архитектор переводит боль в задание, агент исполняет, человек судит. Поэтому при смене платформ (авторы поменяли и чат, и агента посреди проекта) всё продолжило работать, потому что схема привязана к ролям, а не к продуктам.
Рычаги управления: - Критерии приёмки → пишите их проверяемыми на реальных данных. Это граница между «похоже на правду» и «работает». - Негативные требования («никогда не делай X») + проверка на выходе → слоями защиты закрывается класс ошибок, который вы не терпите. - Прямой канал к агенту → оставьте только для мелких локальных багов, иначе у агента и архитектора расходятся контексты. - Тестирование → в условиях, где инструмент будет жить, а не за рабочим столом.
Шаблон промпта
В статье нет дословных промптов. Ниже собрано по описанию ролей: архитектор получает проблему на профессиональном языке и возвращает Markdown с задачами, правками по файлам и критериями приёмки.
Чат 1 — архитектор:
Ты — LLM-архитектор. Я — эксперт в области {область}, не программист.
Ты переводишь мои жалобы и требования в инструкции для кодинг-агента.
Код ты не пишешь. Решения о требованиях принимаю я, у меня право вето.
Проблема: {проблема профессиональным языком}
Среда использования: {где и как будет работать: без интернета, на ноутбуке, при конфиденциальных данных и т.п.}
Что для меня недопустимо: {какие сбои я не терплю}
Чат / окно 2 — кодинг-агент:
Исполняй инструкцию ниже строго по задачам и файлам.
Не добавляй функций, которых в ней нет. Если критерий приёмки неясен, спроси.
После выполнения перечисли, что сделано по каждому критерию.
{вставить Markdown-инструкцию от архитектора}
Обратная связь после теста (в чат архитектора):
Тест в реальных условиях: {что произошло}.
Что я ожидал: {что ожидал}.
Почему это неприемлемо для моей работы: {профессиональная причина}.
Не подкручивай параметры. Сначала скажи, для чего эта функция нужна,
и предложи, как переформулировать требование.
🚀 Быстрый старт — вставь в чат:
Вот шаблон триады «эксперт — LLM-архитектор — кодинг-агент». Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про вашу область, условия использования и то, какие сбои для вас недопустимы. Эти поля нужны, чтобы архитектор написал критерии приёмки под вашу реальность, а не под типовой случай.
Ограничения
⚠️ Один автор, один случай: это автоэтнография: исследователь, разработчик и пользователь — один человек. Авторы прямо отказываются от утверждений о том, что метод лучше других. Это описание того, как оно работало, а не доказательство эффективности.
⚠️ Готовых промптов нет: в статье описаны роли и формат инструкции, но не сами тексты. Шаблон выше — реконструкция по описанию.
⚠️ Нужен эксперт, который умеет судить: вся ответственность за требования и приёмку лежит на человеке. Если вы не можете проверить результат в реальных условиях, схема не поможет.
⚠️ Потери контекста: архитектор и агент не делят память. При каждом переходе между окнами приходится заново передавать контекст, это постоянные издержки.
⚠️ Не для продакшна: это личный рабочий инструмент одного специалиста, а не промышленная разработка. Масштаб, безопасность и поддержка не проверялись.
⚠️ Лаборатория скрывает проблемы: часть сбоев вообще не про код (гул от заземления в кабине был железной проблемой). ИИ их не найдёт, нужны тесты на месте.
Как исследовали
Автор — синхронный переводчик с опытом свыше ста конференц-дней в год. Без навыков программирования он за пару недель собрал локальный инструмент: распознавание речи и переводящая модель работают на обычном ноутбуке, без интернета. Инструмент сразу пошёл в боевое использование на реальных мероприятиях.
Материал для анализа: 101 обмен с чатом-архитектором, 122 инструкции агенту, дневник и телеметрия. На двухчасовой конференции система перевела 971 высказывание целиком локально, медиана задержки перевода составила 0,94 с. Диалоги разобрали тематическим анализом: в каждом эпизоде искали, какое знание проговорено и какое решение из него вышло.
Неожиданные выводы: во-первых, решающие требования появлялись только после провала. Эксперт не мог назвать их заранее, но мгновенно узнавал нарушение. Во-вторых, платформы сменились посреди проекта (Gemini → GLM, Cursor → ZCode), а схема продолжила работать, что подтверждает привязку к ролям. В-третьих, решение часто было не про «настроить параметр», а про смысл: нарезка речи — это не «кусок в N секунд», а «отправить, как только фраза узнаваемо завершена, а лимит — потолок, а не ритм».
Для практики отсюда следует простое правило: в инструкции пишите, для чего нужна функция и что для вас недопустимо. Параметры подбирать потом.
Адаптации и экстраполяции
🔧 Техника: добавить допрос перед спецификацией → вытянуть неявное знание
Это моя достройка, в статье такого шага нет. Идея вытекает из её наблюдения: требования всплывают после провалов. Можно попробовать вытянуть часть из них заранее:
Прежде чем писать инструкцию, задай мне 5 вопросов вида
«Что должно пойти не так, чтобы ты перестал доверять этому инструменту?»
и «Что в твоей работе типовое решение обычно портит?».
Экстраполяция: связка «негативная инструкция + проверка на выходе»
В статье для борьбы с «попугайством» модели (она копировала исходный текст вместо перевода) использовали два слоя: запрет в промпте («никогда не воспроизводи исходное предложение») и проверку результата (перевод, совпадающий с оригиналом на 85% и больше, отбрасывается). Тот же принцип можно перенести в любую автоматизацию без кода:
Правило 1 (в промпте): никогда не {нежелательное поведение}.
Правило 2 (после ответа, отдельным шагом проверки): если в ответе есть {признак нарушения} —
ответ не показывать, пометить «сбой» и запросить повтор.
Сбой инструкции превращается в сбой отображения, а не в ложное доверие.
Ресурсы
- Работа: The interpreter as developer: An autoethnographic design study of building a computer-assisted interpreting tool through human–LLM co-creation
- Автор: Zhao Zeming (профессиональный синхронный переводчик, доктор истории науки и техники)
- Опорные концепции: vibe coding (Karpathy, 2025), lead users (von Hippel), неявное знание (Polanyi), экстернализация знания (Nonaka & Takeuchi)
- Логи диалогов доступны автору «по запросу» для аудита