Перевод статьи Thariq (команда Claude Code, Anthropic) — «A Field Guide to Fable: Finding Your Unknowns», опубликована 3 июля 2026 в X: https://x.com/trq212/status/2073100352921215386
Карта — не территория
Работа с Claude Fable 5 снова и снова напоминает автору старый урок: карта — не территория.
- Карта — это промпты, скиллы и контекст, то есть всё, что человек даёт Claude.
- Территория — это то, где реально должна быть сделана работа: кодовая база, реальный мир и его ограничения.
Разница между картой и территорией — это то, что автор называет unknowns («неизвестные»). Когда Claude сталкивается с unknown, ему приходится принимать решение на основе лучшей догадки о том, чего хочет пользователь. Чем больше объём работы — тем больше unknowns может встретиться Claude.
Fable — первая модель, где, по наблюдению автора, качество работы упирается именно в способность человека прояснять свои unknowns заранее. Причём одного планирования наперёд не всегда достаточно: unknowns могут обнаружиться глубоко в процессе реализации, а иногда они подсказывают, что задачу вообще нужно решать по-другому.
Работа с Fable — это итеративный процесс поиска своих unknowns до, во время и после реализации. Автор поделился набором готовых HTML-артефактов для этой цели: https://thariqs.github.io/html-effectiveness/unknowns/ — но подчёркивает, что важнее выработать интуицию, когда каким приёмом пользоваться.
Знай свои unknowns
Автор делит неизвестные на 4 типа:
- Known Knowns («известные известные») — то, что и так есть в промпте: что именно человек прямо говорит агенту.
- Known Unknowns («известные неизвестные») — то, что человек ещё не решил, но осознаёт этот пробел.
- Unknown Knowns («неизвестные известные») — то, что настолько очевидно, что никогда не будет написано в промпте, но человек узнает это, когда увидит.
- Unknown Unknowns («неизвестные неизвестные») — то, что вообще не приходило в голову: пробелы в знаниях, непонимание, насколько хорошим может быть результат.
Лучшие «агентные» кодеры отличаются тем, что у них относительно мало unknowns. Наблюдая, как промптят такие люди как Борис (Cherny) или Джаррэд (Sumner), видно: они детально знают, чего хотят, и находятся в глубокой синхронизации и с кодовой базой, и с поведением модели. Но и они делают предположения там, где есть unknowns. По мнению автора, умение сокращать и планировать свои unknowns — это и есть ключевой навык agentic coding, и его можно тренировать, работая с Claude.
Помоги Claude помочь тебе
Инструктирование Claude — это тонкий баланс:
- Слишком конкретный промпт → Claude будет слепо следовать инструкциям, даже если стоило бы свернуть в сторону.
- Слишком расплывчатый промпт → Claude будет опираться на общепринятые практики индустрии, которые не обязательно подходят конкретной задаче.
Если не учитывать свои unknowns — проигрываешь в обоих случаях: не знаешь, где путь усеян препятствиями, и не знаешь, где путь свободен, но всё равно хочешь, чтобы Claude отклонился от заданного курса.
Claude может помочь находить unknowns быстрее человека: он умеет очень быстро искать по кодовой базе и интернету, знает о большинстве тем больше среднего пользователя и быстрее итерируется после неудачи. Самое важное здесь — дать Claude контекст об исходной точке: где человек находится в своём мыслительном процессе, какой у него опыт с задачей и кодовой базой, чтобы Claude работал как мыслительный партнёр (thought partner).
Ранее автор уже писал о том, как использовать HTML-артефакты вместе с Claude — почти во всех описанных ниже случаях HTML-артефакт оказывается лучшим способом визуализировать и представить решение.
Дальше — набор конкретных приёмов для выявления unknowns (не все используются каждый раз, но это полезная коллекция техник).
До реализации
Blind Spot Pass («проверка слепых зон»)
Один из самых полезных шагов в начале работы — понять свои слепые зоны. Например, если пишется фича в незнакомой части кодовой базы или Claude используется для непривычной задачи (скажем, доработка дизайна), у человека, скорее всего, много unknown unknowns: непонятно, какие вопросы задавать, как выглядит «хорошо», какая работа уже была проделана раньше и какие есть подводные камни.
Для этого можно прямо попросить Claude помочь найти unknown unknowns и объяснить их. Автор буквально использует фразы «blindspot pass» и «unknown unknowns» — и обычно важно дать контекст о себе и своём уровне знаний.
Примеры промптов:
- «Я добавляю нового auth-провайдера, но вообще не знаю модули аутентификации в этой кодовой базе. Сделай blindspot pass, чтобы найти мои unknown unknowns и помочь мне промптить тебя лучше».
- «Я не знаю, что такое цветокоррекция, но мне нужно откорректировать это видео. Научи меня понимать мои unknown unknowns по цветокоррекции, чтобы я мог промптить точнее».
Брейнштормы и прототипы
Когда задача связана с областью, где много unknown knowns — критериев, которые узнаёшь только увидев, — стоит просить Claude брейнштормить и прототипировать вместе.
Крайне ценно проговорить unknown knowns рано, на этапе прототипа: обнаружить их уже во время реализации обходится (относительно) дорого — небольшие изменения в фиче или спецификации могут вызвать совершенно разную реализацию в коде, и агенту сложнее откатить уже сделанные изменения.
Например, иногда достаточно увидеть, как выглядит кнопка на макете, не подключая бэкенд-роут и не поддерживая лишнее состояние на фронтенде. Визуальный дизайн — то, что автору сложно сформулировать словами, но он «узнаёт, когда видит» — поэтому в таких случаях он просит несколько разных вариантов дизайна сразу.
Автор почти всегда начинает сессию кодинга с фазы исследования/брейнсторминга — это помогает задать намерение и границы проекта: Claude часто находит ценные подходы, которые человек упустил бы, а иногда, наоборот, не видит леса за деревьями. Брейншторм не даёт задать слишком узкий или слишком широкий скоуп.
Примеры промптов:
- «Хочу дашборд для этих данных, но у меня нет визуального вкуса и я не знаю, что вообще возможно. Сделай HTML-страницу с 4 совершенно разными направлениями дизайна, чтобы я мог отреагировать».
- «Прежде чем что-либо подключать, сделай один HTML-файл с макетом нового тулбара редактора на фейковых данных. Хочу отреагировать на layout, прежде чем ты тронешь настоящее приложение».
- «Вот грубая формулировка проблемы: пользователи отваливаются после онбординга. Поищи по кодовой базе и предложи брейнштормом 10 мест для вмешательства — от самых дешёвых до самых амбициозных. Я скажу, какие откликаются».
Интервью
После достаточного брейншторма unknowns обычно всё ещё остаются. В этом случае автор просит Claude проинтервьюировать его по поводу неясностей и двусмысленностей — важно дать контекст задачи, чтобы вопросы были релевантными.
Пример промпта:
- «Проинтервьюируй меня по одному вопросу за раз обо всём неоднозначном, в приоритете — вопросы, где мой ответ изменит архитектуру».
Референсы
Иногда описать желаемое подробно невозможно — либо не хватает языка, либо это заняло бы слишком много времени. В этом случае лучший ответ — референс. Можно приложить диаграммы, документацию или картинки, но лучший референс — это исходный код.
Если есть библиотека, реализующая нечто нужным образом, или компонент дизайна, который нравится — достаточно указать Fable на папку и сказать, что там искать, даже если это другой язык программирования.
Так же работает и Claude Design: не обязательно прикладывать файл (хотя можно и так) — можно указать на модуль на понравившемся сайте, и Claude прочитает именно код, а не просто скриншот. Это даёт гораздо более богатую детализацию по разметке, структуре и реальному устройству компонента.
Пример промпта:
- «Этот Rust-крейт в vendor/rate-limiter реализует ровно то поведение backoff, которое мне нужно. Прочитай его и реализуй ту же семантику в нашем TypeScript API-клиенте».
Планы реализации
Когда автор готов приступить к реализации, он просит Claude составить план реализации для ревью — с акцентом на части, которые вероятнее всего изменятся: модели данных, интерфейсы типов, UX-флоу. Это позволяет Claude показать то, что действительно может потребовать правок.
Пример промпта:
- «Напиши план реализации в HTML, но начни с решений, которые я, вероятнее всего, захочу поправить: изменения модели данных, новые интерфейсы типов и всё, что видит пользователь. Механический рефакторинг закопай в конец — здесь я тебе доверяю».
Во время реализации
Заметки по реализации (implementation notes)
Когда план утверждён, автор открывает новую сессию и передаёт в промпт все наработанные артефакты — например, спеку и прототип, прося реализовать их.
Но как бы тщательно ни планировать, unknown unknowns всё равно поджидают впереди: агент может обнаружить в процессе, что нужно пойти другим путём из-за найденного edge case в коде.
Автор просит Claude Code вести временный файл implementation-notes.md (или .html), где фиксируются принятые решения — чтобы можно было учиться на следующей попытке.
Пример промпта:
- «Веди файл implementation-notes.md. Если наткнёшься на edge case, вынуждающий отклониться от плана — выбирай консервативный вариант, зафиксируй его в разделе “Deviations” и продолжай».
После реализации
Питчи и объяснения
Один из важнейших этапов «отгрузки» результата — получить одобрение и buy-in. Артефакты-питчи и объяснения в финальном документе помогают:
- ускорить понимание — если у ревьюеров были те же unknowns, что и у автора изначально;
- ускорить согласование — если эксперты видят, что учтены unknowns и типичные точки отказа, которые они бы и сами предвидели.
Пример промпта:
- «Собери прототип, спеку и заметки по реализации в единый документ, который можно кинуть в Slack для получения одобрения. Начни с демо-гифки».
Квизы
После долгой рабочей сессии Claude мог сделать намного больше, чем кажется на первый взгляд. Чтение диффов кода даёт лишь поверхностное понимание происходящего, потому что многое зависит от уже существующих путей выполнения кода.
Автор просит Claude устроить ему квиз по сделанным изменениям после того, как получит достаточно контекста — это помогает по-настоящему понять, что произошло. Мерж делается только после того, как квиз пройден идеально.
Пример промпта:
- «Хочу убедиться, что понимаю всё, что произошло в этом изменении. Дай мне HTML-отчёт об изменениях для чтения — с контекстом, интуицией, тем, что было сделано, и т.д. — и квизом в конце по изменениям, который я обязан пройти».
Как это сочетается: запуск Fable
Видео к запуску Fable было полностью смонтировано Claude Code — для автора это была новая область, и он далеко не эксперт в видеомонтаже.
Поэтому он начал с того, что уже знал: Claude умеет монтировать и транскрибировать видео кодом, но не было уверенности, что это будет достаточно точно. Автор попросил Claude объяснить, как работает транскрипция вроде Whisper, и сможет ли она точно вырезать «эканья» и длинные паузы через ffmpeg.
Он хотел, чтобы Claude сделал интерфейс, синхронизированный со словами речи, но не был уверен, получится ли — поэтому попросил Claude сделать прототип видео на Remotion с транскрипцией, чтобы проверить гипотезу.
Наконец, само видео выглядело немного блёклым — автор понимал, что дело в цветокоррекции, но не знал, что это вообще такое. Первой попыткой было попросить Claude сделать несколько вариантов на выбор, но стало ясно, что автор не знает, как выглядит «хорошо» применительно к цветокоррекции. Поэтому вместо этого он попросил Claude научить его цветокоррекции — чтобы обнаружить собственные unknowns.
Более подробный разбор этого процесса — в видео по ссылке в оригинальной статье: https://x.com/trq212/status/2064826394589442448/video/1
Совмещение карты и территории
Чем лучше становятся модели, тем больше можно достичь при правильном подходе. Когда долгая задача возвращается «не туда» — скорее всего, стоило потратить больше времени на определение своих unknowns или составить план реализации, позволяющий Claude импровизировать вокруг них.
Каждый explainer, брейншторм, интервью, прототип и референс — это дешёвый способ узнать то, чего не знал заранее, пока это ещё не стало дорого стоить на этапе исправления.
Вывод автора: начинай следующий проект с того, что попроси Claude помочь найти твои unknowns.
Источник: Thariq (@trq212) на X, 3 июля 2026 — сотрудник команды Claude Code в Anthropic. Изображения — скриншоты из оригинальной статьи.