Использование /probe для выявления галлюцинаций ИИ перед написанием кода

Что делает /probe

Техника /probe заставляет ИИ-генерируемые планы выводить каждое утверждаемое утверждение в виде нумерованного УТВЕРЖДЕНИЯ (CLAIM) с ОЖИДАЕМЫМ (EXPECTED) значением. Затем она запускает команду для проверки реальной системы и фиксирует разницу между ожидаемыми и фактическими результатами.

Реальный пример из источника

Разработчик пытался разобрать файлы сессий Claude в формате JSONL, хранящиеся в ~/.claude/projects/.... Claude уверенно описал формат, но запуск /probe выявил четыре галлюцинации:

• Утверждение 1: ИИ сказал, что существует 2 типа верхнего уровня (пользователь, ассистент). Реальность: 7 типов, включая queue-operation, file-history-snapshot, attachment, system, permission-mode и summary.
• Утверждение 2: ИИ сказал, что контент ассистента = текст + tool_use. Реальность: Пропущены блоки thinking (размышления), которые составляют около трети вывода ассистента в расширенном режиме мышления.
• Утверждение 3: ИИ сказал, что контент пользователя всегда является массивом. Реальность: Полиморфный: строка ИЛИ массив.
• Утверждение 4: ИИ сказал, что именование папок заменяет / на -. Реальность: На самом деле сначала добавляется тире, а затем происходит замена.

Без /probe фильтр jq выдал бы ошибку на строковом контенте пользователя, выбросил бы блоки thinking как мусор и полностью пропустил 5 из 7 типов сообщений.

Как работает проверка

ИИ записывает утверждения типа "ОЖИДАЕМО (EXPECTED): 2 типа" перед запуском команд, таких как jq -r '.type' file.jsonl | sort -u. Один из выводов проверки выглядел так:

УТВЕРЖДЕНИЕ 1 (CLAIM 1): JSONL имеет 2 типа верхнего уровня (пользователь, ассистент)
ОЖИДАЕМО (EXPECTED): 2
КОМАНДА (COMMAND): jq -r '.type' *.jsonl | sort -u | wc -l
ФАКТИЧЕСКИ (ACTUAL): 7
РАЗНИЦА (DELTA): +5 неизвестных типов (queue-operation, file-history-snapshot, attachment, system, permission-mode, summary)

Ключевые инсайты из источника

Утверждения, которые стоит проверять, часто те, в которых ИИ наиболее уверен. Когда ИИ осторожничает, вы уже знаете, что нужно проверить. Когда он категорично утверждает X, вы не знаете. Высокоуверенные утверждения — это где прячутся галлюцинации.

Ещё одно преимущество в том, что одна проверка становится N постоянными тестами. Находка о 7 типах становится тестом схемы, который проваливает CI, если появляется новый тип. Находка о строке-или-массиве становится property-тестом, который фаззит обе формы. Когда вышестоящий формат меняется, тест проваливается, вы перепроверяете, и оракул обновляется.

Ограничения и улучшения

Проверка ловит только утверждения, которые ИИ догадывается сделать. Неизвестные неизвестности остаются невидимыми. Что помогает:

• Сначала запустить jq 'keys', чтобы перечислить реальность перед генерацией утверждений
• Паттерн CRISPY от Dex Horthy подталкивает ИИ к выявлению собственного списка пробелов
• Spec Kit от GitHub использует маркеры [NEEDS CLARIFICATION] в спецификациях, чтобы заставить ИИ отмечать слепые зоны
• Также рекомендуется ручной просмотр списка утверждений

Контраст с традиционным TDD

Традиционный TDD пишет тесты на основе того, что вы ДУМАЕТЕ, должно произойти. Probe-driven TDD пишет тесты на основе того, что вы изучили или ПРОВЕРИЛИ, что происходит. Моки тестируют вашу модель системы. Проверка тестирует саму систему.

Исходные файлы

Разработчик поделился полным файлом навыка /probe в gist с двумя файлами:

• README.md: Более длинное описание с углом REPL-as-oracle и контрастом с TDD
• probe-skill.md: 7-шаговый протокол, загружаемый как навык Claude Code

Паттерн просто "таблица утверждений + проверка реальной системы + фиксация разницы" и работает с любым REPL или CLI-инструментом, который может запрашивать систему, против которой вы собираетесь писать код.