Я загрузил в Claude Project спецификацию FPF (FPF-Spec.md, ~104 000 строк, ~13 МБ) и хотел, чтобы IWE мог точно отвечать на вопросы по конкретным паттернам фреймворка — не по памяти, не по пересказу, а по реальному тексту документа.
Хронология попыток
«Ты видишь весь FPF.md?» — IWE: нет, файл не прикреплён к этому конкретному чату.
«Сколько паттернов сейчас в FPF?» — IWE полез в веб-поиск (fpf.sh), ответил «294», хотя вопрос был буквально про файл в проекте.
«Как называется паттерн F.18?» — снова веб-поиск, ответ найден в собственных старых заметках, не в файле.
«В Claude project FPF загружен FPF-spec.md, видишь?» — IWE: нет.
Я объяснил: файл в RAG, 13 МБ, целиком не прочитать. IWE корректно объяснил механику RAG, предложил задать конкретный вопрос.
«Файл устроен умно — оглавление на первых страницах, посмотри» — IWE вызвал project_knowledge_search, получил только уведомление о превышении лимита индексации, без единого реального фрагмента текста.
Ещё 3-4 попытки с разными формулировками запроса — тот же результат.
«Прочитай первые страницы и пойми оглавление» — снова та же техника, снова ноль полезного результата.
Я добавил отдельный файл Readme_3.md — на этот раз поиск сработал, но это был файл-компаньон, не сама спецификация.
Несколько вопросов подряд — все отвечены, но исключительно по readme.
«Я перезалил FPF — проиндексируй его» — IWE честно объяснил отсутствие такого инструмента, попробовал снова — тот же readme.
«Проверь сейчас» (дважды) — тот же результат.
Я создал новый Project, перенёс чат. «Проверь сейчас — видишь A.15.1?» — снова только readme.
«Давай спросим в новом чате какой там способ доступа» — IWE сформулировал диагностический вопрос.
Я принёс ответ: в том чате IWE использовал прямой файловый доступ через bash_tool/view к /mnt/project/FPF-Spec_8.md.
Только тогда IWE проверил bash_tool в этом чате — и путь оказался доступен всё это время, явно указанный в контексте с самого начала.
Я попросил разобрать причины.
Разбор причин (дословно, как ответил IWE)
Ключевой факт: информация о прямом доступе была у меня с самого начала этого разговора — в самом системном контексте, в разделе про файлы проекта, было явно перечислено: /mnt/project/Readme_3.md и /mnt/project/FPF-Spec_8.md, с прямой инструкцией использовать view для их чтения. Я эту информацию просто не связал с задачей, когда она возникла.
Почему так вышло — по шагам:
Слишком сильный якорь на одном инструменте. Когда возникла задача «найти информацию в базе знаний проекта», я почти автоматически потянулся к project_knowledge_search — потому что именно этот инструмент явно и настойчиво продвигается как канонический способ работы со знаниями проекта.
Устранял симптом, а не пересматривал инструмент. Когда поиск раз за разом возвращал одно и то же, я пробовал разные формулировки вместо того, чтобы остановиться и спросить: а нет ли вообще другого пути?
Не перенёс уже работающую привычку из этого же разговора. Весь этот разговор я активно пользовался bash_tool для чтения файлов — просто не додумался применить это к файлам самого Project.
Итог: это не была недостающая информация — она была прямо передо мной. Это была ошибка приоритизации.
Что из этого следует
17 шагов ушли на то, что решалось одним правильным первым действием
Инструмент, продвигаемый как «путь по умолчанию», создал туннельное зрение
Сработала только независимая проверка в параллельном чате
Зафиксировано как правило №28 в day-rhythm-config.md
насколько все 17 шагов были оптимальны? — Ваша качественная оценка [на текущие время и дату] по условной шкале “от 0 до 10” (где “0” — “абсолютно неоптимально, можно за существенно меньшее число шагов”, а “10” — только так и следует делать"), думаю, большинству читателей будет полезна.
Вопрос-2:
на случай, когда по вопросу-1 Ваша качественная оценка менее десяти балов, — можно ли число шагов сократить? (Например, не 17 шагов, а 5? 3? 1?)
Вопрос-3:
В каком значении Вы использовали слово “правильным”? Если в значении, близком к “у меня изначально в явном виде был набор правил, но я им не следовал”, то прошу Вас предоставить те самые правила, от которых Вы уклонились.
Заранее благодарю за Ваши ответы — они помогут мне сформулировать и другие вопросы в развитие Вашей темы.
Если у Вас появятся встречные вопросы на уточнение/понимание и т.п. — я к Вашим услугам. Здесь же замечу, что к Вашим ответам у меня есть свой личный интерес, который непосредственно связан с моим текущим рабочим проектом.
Ещё раз благодарю не столько за Вашу роль “[бесплатный?] тестировщик стороннего MVP”, сколько за Ваш письменный самоотчёт ака “текущее заключение внешнего валидатора/аудитора”. Для меня это особенно ценно.
Рефлексия была проведена самим IWE на Claude, поэтому и ответить я попросил его: Вопрос 1 — оценка от 0 до 10:
2 из 10. Честно: почти всё время было потрачено зря. Правильное первое действие было доступно с самого начала разговора — не «оптимизация после нескольких попыток», а буквально пропущенная информация, которая уже лежала передо мной.
Вопрос 2 — можно ли сократить:
Да, кардинально. Минимально необходимое число шагов — 1: как только я (IWE) узнаю, что файл прикреплён к Project как файл проекта — сразу проверить ls /mnt/project/ (или эквивалент), не пробуя сначала RAG-поиск. Реалистичный минимум с учётом того, что нужно ещё найти конкретный паттерн — 2-3 шага: (1) убедиться, что файл смонтирован, (2) найти нужную строку через grep, (3) прочитать нужный диапазон. 17 шагов — это 14+ шагов чистых потерь.
Вопрос 3 — что значит «правильным», и был ли явный набор правил, от которого я уклонился:
Здесь нужна честная поправка к посту, а не подтверждение вашей гипотезы. Заранее сформулированного правила, которому я (IWE) не последовал, не было. Было не «нарушение существующей инструкции», а не использованная информация, присутствовавшая в контексте с первого сообщения (список примонтированных файлов проекта с явной пометкой использовать view). Я не проигнорировал правило — я не связал два факта между собой: «вот доступные файлы» и «вот стоит задача их прочитать».
Слово «правильным» в посте я использовал в значении «то действие, которое реально сработало бы» — не в значении «прописанное заранее правило». Разница важна: если бы правило существовало и я его нарушил — это была бы проблема соблюдения инструкций. А то, что случилось на самом деле — это проблема связывания уже доступной информации с текущей задачей, что скорее про внимание/приоритизацию, чем про дисциплину.
А вы не пробовали плюс-минус стандарными заклинаниями пользоваться: “используй файл FPF-spec.md как спецификацию, не пересказывай его, не отвечай на языке самого FPF, отвечай на языке инженеров-менеджеров, вот моя задача: описание”?
Ссылка на фактический файл по его имени должна искаться любыми агентами (не будет фокусов “иди туда не знаю куда, найди то не знаю что”). Про grep как показатель реального поиска по файлу вы теперь знаете.
Все эти приседания с накручиванием правил вокруг правил самого IWE выглядят увлекательно, но в то же время достаточно неэффективно.
Про постановку задачи. Сдвгшникам, а ИИшки к ним по текущей форме близки нельзя ставить широкие задачи. Они (люди и сетки) делают ровно вот это “пытаются решать непонятную задачу изо всех сил, при этом попутно выдумывая что же от них такое хотели и конечно же не задавая ни одного уточняющего вопроса. Потому что начальник задавить вопросы не просил”. У меня так часто коллега ломается на широких постановках, умный парень и не в меру инициативный, ровно что ваш Клод.