TL;DR
SWE-Clar — бенчмарк (набор тестовых задач) на 100 реальных заказах с Upwork, на которых проверяют, как кодинг-агент сначала выясняет требования у заказчика, а потом пишет проект с нуля без дальнейших подсказок. Схема такая: агент задаёт вопросы, контекст «замораживается», и дальше идут две изолированные ветки. В одной агент пишет код и проходит приёмочные тесты. В другой отвечает на контрольные вопросы по требованиям, и его ответы сверяют с эталоном. Так отдельно видно, что агент понял и что он сделал.
Главная находка: заказчик ответил на вопрос ≠ агент понял. Даже когда требование полностью раскрыто в диалоге, агент иногда неверно пересказывает его в итоге. Агент неправильно отвечает на вопрос по требованию — и код по этому требованию чаще всего не проходит тест. Без уточняющих вопросов агент почти всегда проваливает проект: он строит догадки вместо знаний. С вопросами результат вырастает в разы, но закрывает лишь половину-две трети разрыва до уровня «полное ТЗ заранее». Даже с полным ТЗ агент справляется не со всеми задачами.
Практический смысл: этап вопросов до кода нужен, но его недостаточно. Дайте агенту задать вопросы, пока вы доступны, и потребуйте пересказать требования своими словами, чтобы проверить понимание до старта. Чем полнее бриф, тем лучше результат.
Схема метода
ШАГ 1: Агент изучает материалы и задаёт вопросы заказчику → раунды «вопрос — проверенный ответ»
(особенно: как запускается ПО, какие входы и выходы)
ШАГ 2: Заказчик отвечает, подтверждает или поправляет интерпретации агента → ответы
проверяет супервизор (точность, полнота, не вышел ли за рамки вопроса)
ШАГ 3: Агент сам решает, что уточнение закончено → контекст «замораживается»
(запрос + диалог + то, что агент увидел в рабочей папке)
ШАГ 4а: Ветка реализации: агент пишет код без доступа к заказчику → приёмочные тесты
ШАГ 4б: Ветка проверки понимания (отдельный запуск): агент отвечает на вопросы
по требованиям → судья сверяет с эталоном (верно / частично / неверно)
Шаги 1–3 идут в одном диалоге. Ветки 4а и 4б — отдельные запуски от одного замороженного контекста. Вопросы проверки не должны подсказывать агенту, что писать в код.
Пример применения
Задача: Владелец магазина косметики на Wildberries заказывает у Claude Code скрипт, который из выгрузки отчётов продаж считает юнит-экономику по каждому артикулу. Заказ звучит так: «Нужно считать маржу по товарам, чтобы понимать, что убирать из ассортимента». Таких требований, которые заказчик не сказал, море: комиссия, логистика, возвраты, налоги, формат вывода.
Промпт:
Ты — фрилансер-разработчик. Заказчик — я, владелец магазина на Wildberries.
Моё исходное задание: «Нужен скрипт, который считает маржу по товарам из выгрузки
отчётов WB, чтобы я понимал, что убирать из ассортимента». Файлы с выгрузкой лежат в папке /data.
ФАЗА 1. УТОЧНЕНИЕ (код писать нельзя).
- Изучи файлы в /data.
- Задавай мне вопросы пачками по 3–5, пока не поймёшь, что нужно.
- Обязательно уточни: как я буду запускать скрипт, что подаю на вход, что хочу получить на выходе.
- Предлагай свою интерпретацию («Я понял так: ... Верно?»), а не только открытые вопросы.
- Спрашивай про исключения и краевые случаи: возвраты, отмены, товары без продаж.
- Когда будешь готов, напиши «УТОЧНЕНИЕ ЗАВЕРШЕНО» и перечисли 5–7 требований своими словами.
ФАЗА 2. РЕАЛИЗАЦИЯ — только после моего «ок». Дальше я недоступен, вопросов не будет.
Результат: Агент не начнёт писать код сразу, а пришлёт серию вопросов с вариантами интерпретации: как считать комиссию, что делать с возвратами, в каком виде нужен отчёт. После ваших ответов он выдаст список требований своими словами. Вы увидите, где он понял неверно, поправите и только потом дадите добро на код.
Почему это работает
Слабость: при неполном задании модель достраивает недостающее догадками и уверенно пишет код. Без вопросов она проваливает почти все задачи. Но и после ответов заказчика понимание не гарантировано: часть полностью раскрытых требований модель потом пересказывает неверно.
Сильная сторона: модель хорошо формулирует уточняющие вопросы и пересказывает требования своими словами. Пересказ можно сверить с тем, что вы имели в виду. Ошибка в пересказе предсказывает провал в коде по этому требованию.
Как метод это использует: - Фаза вопросов собирает недостающее, пока вы доступны. - Отдельный пересказ требований — дешёвая проверка до дорогой реализации. - Изоляция проверки от кода нужна, чтобы контрольные вопросы не выдали модели подсказку и не исказили проверку.
Рычаги управления: - Интерпретации вместо открытых вопросов («Я понял так...») → заказчик быстрее подтверждает или поправляет. - Обязательные темы (запуск, вход, выход) → закрывают самые дорогие дыры. - Размер пачки вопросов → меньше пачка, больше раундов, но меньше путаницы. - Контроль ответов (кто-то второй проверяет ваши ответы на точность и полноту) → меньше ошибок в самом брифе.
Шаблон промпта
В статье нет полных промптов в доступном тексте (роли вынесены в Приложение F). Шаблон ниже собран по описанной в статье механике: обязательное уточнение критичных деталей, подтверждение интерпретаций, запрет кода до конца уточнения.
Ты — {роль_исполнителя}. Заказчик — {кто_заказчик}.
Исходное задание: «{начальный_запрос}». Материалы лежат в {папка_или_файлы}.
ФАЗА 1. УТОЧНЕНИЕ (код писать нельзя).
- Изучи материалы и пойми, чего в задании не хватает.
- Задавай вопросы пачками по {число} штук.
- Обязательно уточни: как запускается результат, что подаётся на вход,
что должно получиться на выходе, как обрабатывать {критичные_исключения}.
- Предлагай свою интерпретацию («Я понял так: ... Верно?»).
- Когда считаешь, что хватает, напиши «УТОЧНЕНИЕ ЗАВЕРШЕНО» и перечисли
требования своими словами.
ФАЗА 2. РЕАЛИЗАЦИЯ — только после моего «ок».
Заказчик недоступен, вопросов больше не будет. Сделай {результат} и проверь его сам.
Плейсхолдеры:
- {роль_исполнителя} — разработчик, аналитик, автор.
- {начальный_запрос} — ваш реальный, как есть, неполный запрос.
- {критичные_исключения} — ваши известные «острые углы»: возвраты, отмены, пустые данные.
🚀 Быстрый старт — вставь в чат:
Вот шаблон фазы уточнения перед реализацией. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что за задача, какие материалы есть, как будет запускаться результат и какие исключения вам известны. Это нужно, чтобы фаза уточнения сразу била в самые дорогие дыры, а не в общие места.
Ограничения
⚠️ Это бенчмарк, не проверенный приём: авторы измеряли, как модели справляются, а не проверяли, улучшает ли именно «пересказ требований перед кодом» результат. Связь между правильным ответом и рабочим кодом показана как корреляция.
⚠️ Заказчик в эксперименте — модель: клиента, его проверяющего и судью играла одна и та же LLM. Живой человек отвечает хуже, противоречивее и дольше.
⚠️ Уточнение закрывает не весь разрыв: оно возвращает лишь часть потерянного результата. Полное ТЗ заранее по-прежнему заметно лучше. Вопросы не заменяют хороший бриф.
⚠️ Ответ и код — разные вещи: бывает, что требование названо верно, а код его не выполняет. И наоборот: ответ неполный, а код проходит тест. Пересказ — сигнал, не гарантия.
⚠️ Узкая зона: новые проекты с нуля, локальная разработка, заказчик доступен только в начале. Для правок в существующем коде и непрерывной работы с заказчиком выводы переносятся слабее.
Как исследовали
Команда Upwork взяла 100 реальных заказов на разработку «с нуля» стоимостью от 4 000 долларов. По записям переписок клиентов и фрилансеров модель выделила требования, критичные для сдачи работы: сказанные прямо и выведенные из контекста. Из них собрали 512 контрольных вопросов с эталонными ответами и приёмочные тесты. Девять топовых моделей работали агентами-фрилансерами. Роли клиента, супервизора и судьи играла одна модель. Идея была в том, чтобы развести понимание и исполнение: после диалога контекст замораживали и запускали две изолированные ветки.
Самая показательная часть — сравнение трёх условий на двух слабых моделях. Без вопросов к заказчику агенты проходили 5–6% задач. С протоколом уточнения — 39–49%. С полным ТЗ заранее — 71–75%. Уточнение закрывает 51–62% разрыва, а оставшаяся часть — цена непрозвучавших деталей. Лучшая модель прошла 67% задач, худшая — 39%. Чем выше оценка за пересказ требований, тем выше результат кода: корреляция 0,89 по девяти моделям.
Дальше сравнили ответы и код по каждому требованию. Прохождение теста по требованию с верным ответом — 86–91%. С неверным — 34–68%, то есть заметно ниже. Но связь неполная: 6–8% требований с верным ответом всё равно проваливают код. Удивило другое: 3–6% требований, полностью раскрытых заказчиком, агент всё равно излагает неверно. Раскрыть информацию и понять её — не одно и то же.
Адаптации и экстраполяции
🔧 Техника: добавить контрольный пересказ → ловить недопонимание до кода
В статье проверку понимания делают отдельным запуском. Практик может сделать то же в обычной работе. После «УТОЧНЕНИЕ ЗАВЕРШЕНО» попросите:
Ответь письменно на три вопроса, не глядя в код:
1) Что делает программа в случае {краевой_случай_1}?
2) Что делает, если {краевой_случай_2}?
3) Как её запускают и что она возвращает?
Укажи, где ты не уверен.
Вы сверяете ответы со своими ожиданиями и поправляете до реализации. Это экстраполяция: статья показала, что неверные ответы предсказывают провал, но не проверяла такой приём как способ его предотвратить.
🔧 Техника: второй чат как «супервизор» → меньше ошибок в ваших ответах
В статье ответы клиента проверяет отдельный агент: точность, полнота, не вышел ли за рамки вопроса. Если вы отвечаете агенту на много вопросов, отправьте свои ответы в другой чат с просьбой найти противоречия и пропуски. Затем отправьте исправленное обратно.
Ресурсы
- SWE-Clar: Can Coding Agents Clarify Incomplete Client Requirements and Deliver Greenfield Software? (Preprint, under review)
- Код и данные: https://github.com/upwork/SWE-Clar
- Авторы: Jialei Li, Dingxian Wang, Xiaoyan Zhao и др. — University of Science and Technology of China, National University of Singapore, Upwork Inc.
- Родственные бенчмарки, упомянутые в работе: SWE-Lancer, ClarifyCodeBench, Ambig-SWE, SWE-Together, SWE-Interact, ICAE-Bench