TGViewer
Аналитик, который думал Аналитик, который думал @analysts_thinking · 92 subscribers
Post #178 8
Перед запуском работы с AI-агентом полезно проверить не сам запрос, а то, что вы собираетесь считать результатом.

В требованиях часто описывают действие: «собери документы», «проверь интеграцию», «подготовь вывод». Но действие ещё не задаёт границу приёмки. Если заранее не определить, какой артефакт должен появиться, проверка начнётся слишком поздно: команда увидит красивый ответ и будет спорить уже о деталях реализации.

Представим интеграционный проект. Перед стартом нужно зафиксировать четыре вещи:

1. Какой результат существует физически: документ, запись в системе, изменение схемы или решение с указанным владельцем.
2. Какие свойства можно проверить автоматически: обязательные разделы, ссылки на источники, формат данных, наличие всех файлов.
3. Что считается неполным результатом: путь к будущему файлу, заглушка, фраза «уточняется», конфликт источников без вынесенного решения.
4. Кто принимает остаточный риск, если все технические проверки зелёные, а бизнес-ситуация всё ещё допускает несколько трактовок.

Без этого агент легко превращает неизвестное в уверенный текст. Например, в контракте указана одна версия API, в переписке с поставщиком — другая. Агент может выбрать одну и продолжить, хотя правильным исходом запуска было бы зафиксировать конфликт и вернуть его владельцу решения.

Поэтому evidence нужно собирать до запуска, а не после. Сначала записываем источники, их даты, владельцев и область действия. Затем формулируем критерий: что должно быть доказано и каким наблюдением это подтверждается. Только потом запускаем агента и проверяем, что он создал полный артефакт.

Такой порядок меняет и смысл зелёной галочки. Она показывает, что конкретная проверка прошла. Она не сообщает, что найден правильный ответ для пользователя. Проверка схемы не заменяет проверку содержания, а полный документ не означает, что его уже можно принять.

Практический минимум перед стартом:

— назовите будущий артефакт и место, где он должен появиться;
— выпишите обязательные свойства результата;
— перечислите известные отрицательные сценарии;
— укажите источники и владельцев спорных решений;
— назначьте человека, который имеет право принять остаточную неопределённость.

После этого агент получает измеримую границу работы. Аналитик сохраняет право остановить выполнение, если доказательства расходятся, а команда видит, что именно нужно пересмотреть.
More from @analysts_thinking
  1. Oct 8, 2026Потерянный webhook остаётся открытым решением Таймаут не сообщает, произошло событие или н…
  2. Oct 7, 2026Промежуточное состояние нужно проектировать, а не скрывать processing не является неудобно…
  3. Oct 6, 2026return_url не означает payment.succeeded Возврат пользователя в интерфейс сообщает только…
  4. Oct 5, 2026Что на самом деле доказывает зелёный тест? Он показывает, что реализация соответствует зап…
  5. Oct 4, 2026«Показывать статус заявки» — так требование выглядело в начале. После уточнений оказалось,…
  6. Oct 3, 2026Позитивный сценарий обычно помещается в одну строку: оператор запускает проверку, сервис р…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →