ХАРДКОДИНГ PROГАЙД 02

ПАВЕЛ ДУМБРАО / ПРОЕКТИРОВАНИЕ ЧЕРЕЗ ИССЛЕДОВАНИЕ

Не изобретай
велосипед

Как находить готовые решения, отправлять ИИ исследовать документацию и форумы, сравнивать GPT, Gemini и китайские ИИ и только потом проектировать продукт.

28 разделов12 промптов4 разбора кейсов25 проверок

01 / 09Сначала исследовать задачу, затем строить решение

Исследование → доказательства → выбор → архитектура → код

КОРОТКИЙ МАРШРУТ · 15 МИНУТ

Если времени мало, пройди сначала эти 7 шагов

Опиши полезный результат для пользователя.
Попроси AI найти готовые продукты, repos, libraries и официальные примеры.
Оставь 2-3 разумных варианта.
Найди одно предположение, которое может разрушить весь план.
Проверь его маленьким PoC.
Выбери минимальную архитектуру и запиши причину выбора.
Передай coding agent один следующий шаг с измеримым результатом.

Остальные разделы этого гайда - deep reference. Не обязательно читать все 28 разделов перед маленькой задачей.

К содержанию урока

Результат: RESEARCH.md + DECISIONS.md + одна проверенная гипотеза.

Начать обучение →

Дополнительная практика из полной версии main: Исследование в Gemini Notebook. Необязательное продолжение для тех, кому нужно хранить источники и выводы.

Источники и дата проверки · 09.10.2026

Данные сверены: 09.10.2026. Оценка репозиториев, лицензий, зависимостей и безопасности сверена с официальными первоисточниками. Интерфейсы и условия могут измениться: перепроверяй их перед применением.

Кейсы и иллюстрации исходного урока сохранены. Исторические примеры не гарантируют текущие тарифы или возможности всех сервисов.

КАК ЧИТАТЬ

Этот гайд можно использовать как рабочую инструкцию

Для первого прохода прочитай постановку задачи, раздел про китайские ИИ и реальные кейсы. Когда появится свой проект, вернись к промптам, таблице выбора и чек-листу. Главный результат: не выучить терминологию, а принять обоснованное решение о том, что строить и что взять готовым.

Китайские ИИ и серые зоны Реальные кейсы Готовые промпты Непонятные слова

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

01 / МЫШЛЕНИЕ

Твоя задача не написать больше кода. Твоя задача получить работающий продукт

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

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

Главная мысль гайда

Не делегируй ИИ только написание кода. Делегируй ему сначала изучение задачи, поиск чужого опыта, сравнение решений и проверку предположений.

Это не запрет создавать новое. Уникальной может быть твоя услуга, логика работы с клиентом, способ подачи результата или сочетание инструментов. Но уникальность продукта не требует самостоятельно изобретать загрузку файлов, авторизацию, обработку аудио и отправку сообщений.

Подход Павла, который разбираем в этом уроке: сначала использовать ИИ как исследователя и архитектора, затем как исполнителя. GPT, Gemini и китайские ИИ можно подключать к одной задаче с разными исследовательскими поручениями. Принимать решение надо по найденным фактам и результатам проверки, а не по названию модели.

02 / 09Ищи готовые компоненты, а свою логику добавляй там, где она нужна

До кода нужно получить не «уверенный ответ», а понятную карту: что уже существует, что подходит тебе и что ещё предстоит проверить.

02 / ПОСТАНОВКА

Сначала опиши результат для человека

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

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

Вопрос	Пример понятного ответа
Кто пользуется?	Руководитель небольшой команды после рабочего созвона.
Что приходит на вход?	Аудиофайл длительностью до двух часов.
Что нужно на выходе?	Текст разговора, решения, список задач и ответственные, если они явно названы.
Где человек работает?	В Telegram с телефона. Отдельный кабинет пока не нужен.
Какой объём ожидаем?	Для примера: 20 записей в день. Это гипотеза для расчёта, а не статистика.
Что нельзя допустить?	Чужие записи нельзя показать другому пользователю. Придуманные договорённости недопустимы.
Что ограничено?	Время запуска, месячный бюджет и допустимые места хранения данных.
Как примем результат?	На пяти разрешённых тестовых записях бот возвращает отчёт, не теряет задания и показывает ошибки понятным языком.

Теперь ИИ уже может исследовать конкретную цепочку, а не фантазировать о «платформе будущего». Он понимает, что важны длительность файла, язык, очередь заданий, конфиденциальность и стоимость обработки. Красивый личный кабинет на первом этапе может вообще не понадобиться.

Отделяй обязательное от желательного

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

Вопрос к ИИ перед исследованием

«Какие три неизвестных могут полностью изменить выбор решения? Сначала помоги уточнить их. Не придумывай отсутствующие требования за меня».

03 / ДЕКОМПОЗИЦИЯ

Ищи не только готовый продукт. Ищи готовые части

Полного аналога твоей идеи может не оказаться. Это не означает, что всё нужно писать с нуля. Раздели продукт на блоки: интерфейс, получение данных, обработка, хранение, выдача результата, доступы и наблюдение за работой.

В примере с записью созвона это разные задачи. Telegram-интерфейс не обязан решать распознавание речи. Распознавание не обязано хранить задания. ИИ, который пишет итог встречи, не обязан управлять файлами. Чем яснее разделены обязанности, тем проще заменить слабую часть, не пересобирая весь продукт.

Блок	Что искать	Что проверить
Приём записи	Готовый инструмент для выбранного канала	Размер файла, доступы, ограничения способа загрузки
Подготовка аудио	Библиотеку или утилиту обработки	Поддерживаемые форматы и потребление памяти
Распознавание	API или локальное решение	Качество на твоём языке, длительность, цена
Сводка встречи	Модель и формат задания	Не добавляет ли отсутствующие решения и имена
Хранение	Базу данных и файловое хранилище	Срок хранения, изоляцию пользователей, удаление
Надёжность	Очередь, журнал событий, уведомления	Повторный запуск, сбои, отсутствие дубликатов

Такой разбор не требует от тебя знать названия библиотек. Названия должен найти ИИ. От тебя нужен смысл: какие операции выполняет продукт и где нужна гарантия результата.

Полезно отдельно спросить: «Какие из этих блоков уже есть в моём проекте?» Иначе агент может предложить вторую базу данных, второй механизм авторизации и второй планировщик, хотя рабочие компоненты уже существуют. Повторное использование собственного кода тоже часть принципа «не изобретай велосипед».

04 / РАБОЧИЙ МАРШРУТ

От идеи до кода через исследование

03 / 09Исследование, сравнение, проверка риска, архитектура и минимальный продукт

Используй маршрут из семи шагов. Он подходит и для нового сервиса, и для отдельной функции в существующем проекте. Масштаб исследования меняется, логика остаётся.

Сформулировать результат. Записать пользователя, вход, выход, ограничения и критерии готовности.
Найти варианты. Посмотреть продукты, библиотеки, репозитории, официальные примеры и решения в обсуждениях.
Отсеять неподходящее. Учитывать доступы, лицензию, окружение, стоимость и объём поддержки.
Сравнить оставшееся. Выбрать два-три варианта, которые действительно закрывают задачу.
Проверить риск. Сделать маленький эксперимент, который подтверждает ключевую возможность.
Спроектировать сборку. Решить, какие части соединяем, где храним данные и что делаем при сбое.
Разрабатывать по этапам. Передать кодеру выбранный план, доказательства и список проверок.

Исследование не должно превращаться в месячный ритуал. Для знакомой маленькой задачи достаточно найти подходящий официальный пример и проверить его на своей версии. Для продукта с платными API, пользовательскими файлами и несколькими интеграциями понадобится более глубокая работа.

Учебный таймбокс

Например, выделить 45 минут на первичный поиск, 30 минут на сравнение и 60 минут на проверку одного риска. Это предложенная рамка, не обещание успеть любой проект за такое время. По окончании каждого этапа должен появиться результат, а не просто новые вкладки.

05 / «ОТПРАВЬ ИИ УЧИТЬСЯ»

Что эта фраза означает на практике

Фраза «сначала сходи в интернет и обучись» полезна как бытовая постановка. Но ученику важно понимать механизм. В обычном исследовательском запросе ты не переобучаешь веса модели. Ты заставляешь систему получить дополнительные сведения и использовать их при решении текущей задачи.

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

OpenAI описывает Deep Research как исследование с источниками и управлением областью поиска. Google описывает grounding через поиск как подключение актуального веб-контекста к ответу. Это полезные механизмы получения дополнительных данных, но не доказательство правильности любого итогового вывода.

Почему это может уменьшить выдумки

Когда у ИИ перед глазами документация с точными параметрами, меньше необходимости достраивать неизвестный интерфейс по памяти. Но ошибка всё равно возможна: найдена старая страница, неверно понята оговорка, перепутана версия, выбран не тот пакет. Поэтому поиск должен заканчиваться проверкой, а не заменять её.

Ссылки тоже надо читать. Агент может сослаться на реальную страницу, которая не подтверждает написанное рядом. Правильный вопрос: «Где именно в источнике сказано, что эта возможность существует?» Для ключевой интеграции следующий вопрос: «Какой минимальный тест это проверит?»

Получить сведения ≠ обучить модель навсегда

Чтобы находки пережили новый чат, сохрани их в документации проекта. Укажи дату, версию, проверенный факт и способ воспроизведения. Гайд №11 про память и контекст здесь напрямую пригодится.

06 / МОДЕЛЬ И ИНСТРУМЕНТЫ

GPT, ChatGPT и Claude Code нельзя сравнивать как одинаковые коробки

Модель формирует ответ. Приложение или агент добавляет ей инструменты: поиск, браузер, чтение файлов, терминал. Провайдер определяет, через какой сервис ты получаешь доступ. Эти три слоя могут давать совершенно разный результат даже при похожем названии модели.

Claude Code в документации Anthropic описан как агентная среда вокруг модели: он может читать проект, выполнять команды, искать в интернете и проверять результат. Поэтому «Claude Code ничего не знает про этот репозиторий» и «ему не дали прочитать репозиторий» являются разными проблемами.

С китайскими моделями то же самое. Наличие названия GLM, Qwen, DeepSeek или Kimi в списке не доказывает, что конкретный чат умеет открывать сайты. Например, Z.AI отдельно документирует веб-поиск как инструмент. Значит, в исследовании нужно проверять не только модель, но и включённые возможности доступа.

Что проверить	Что попросить показать
Есть ли живой поиск?	Фактически выполненные запросы и открытые страницы, а не обещание поискать.
Читает ли код?	Путь к конкретному файлу, версия или коммит, найденная функция.
Может ли проверить запуск?	Команду, окружение, результат теста и ограничения проверки.
Есть ли доступ к источнику?	Полный текст или честное указание, что виден только фрагмент выдачи.
Какой режим включён?	Поиск, анализ загруженных материалов или ответ по внутренним знаниям.

Не заставляй агента изображать доступ, которого нет. Если он не может открыть закрытый форум, это ограничение источника. Если не умеет запустить Windows-приложение в Linux-окружении, это ограничение проверки. В отчёте эти пункты должны остаться непроверенными, а не превратиться в красивое «всё работает».

07 / НЕСКОЛЬКО ИИ

Собери исследовательскую команду, а не конкурс красноречия

04 / 09Несколько исследователей, единые критерии проверки

Иллюстрация показывает идею распределения ролей. Она не является рейтингом моделей: доступ к источникам и результат нужно проверять в выбранном сервисе.

Вместо четырёх одинаковых запросов «какой инструмент лучший?» раздай разные задачи. Один ИИ собирает официальные варианты. Второй ищет альтернативную архитектуру. Третий исследует другой языковой сегмент. Четвёртый пытается опровергнуть предварительный выбор.

Участник	Поручение в этом методе	Что принести
ChatGPT / GPT с поиском	Собрать карту задачи и официальные подходы	Ограничения, источники, варианты
Google Gemini с поиском	Независимо проверить рынок решений и спорные предположения	Альтернативы и то, что пропустил первый отчёт
Qwen / GLM / DeepSeek / Kimi в подходящей среде	Искать региональные проекты, другие названия, китайскоязычные материалы	Новые источники с переводом и оговорками
Агент с доступом к коду	Проверить финалистов на конкретном окружении	Воспроизводимый запуск или конкретный блокер

Это назначенные роли, а не утверждение, что только одна модель умеет соответствующую работу. Меняй распределение по фактическому качеству. Claude Code тоже можно отправить исследовать, а Gemini или китайский агент тоже могут помогать с проверкой, если у них есть нужные инструменты.

Не голосуй по большинству ответов

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

Пусть итоговый редактор сделает таблицу: утверждение, кто его привёл, источник, дата, противоречия, способ проверки. Так «команда ИИ» начинает приносить доказательства, а не увеличивать количество текста.

08 / БОЛЬШОЙ РАЗДЕЛ

Китайские ИИ и «серые зоны» информации

Китайские модели могут оказаться полезнее конкретного запуска GPT или Claude Code на отдельных малоописанных задачах. Но преимущество нужно искать в полезных находках и проверяемых деталях, а не в самой готовности модели ответить.

Сначала разделим три разных смысла

Серая зона знаний: информация существует, но разбросана по обсуждениям, старым примерам, региональным сайтам и частично документированным интерфейсам. Например, редкий конфликт зависимостей или неизвестная западному поиску библиотека.

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

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

Где может появиться реальное преимущество

Первое возможное преимущество связано с языком поиска. Если решение обсуждается по-китайски, локальное название библиотеки или правильная формулировка запроса могут привести к результатам, которых нет в русской выдаче. Qwen, например, заявлял для Qwen3 поддержку 119 языков и диалектов. Это подтверждает многоязычную направленность конкретного семейства, но само по себе не доказывает превосходство над GPT на твоей задаче.

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

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

Рабочая гипотеза, которую стоит проверять

Для поиска неочевидных, региональных и плохо документированных решений имеет смысл подключать китайские ИИ как независимых исследователей. На конкретной задаче они могут дать более полезный результат. Из этого не следует, что они всегда лучше GPT, Gemini или Claude.

Более свободный ответ не равен более точному

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

Смотри на измеримые признаки: существуют ли репозитории, открываются ли источники, совпадают ли названия параметров с документацией, воспроизводится ли пример, подтверждается ли цена. Длинный ответ без этих признаков не выигрывает у короткого честного «не проверено».

Нельзя также описывать все китайские ИИ как модели без ограничений. В исследовании R1dacted 2025 года авторы изучали отказы DeepSeek R1 на политически чувствительных вопросах. Это конкретное исследование конкретной модели, не общий вердикт обо всей экосистеме. Но оно показывает, почему формула «китайская модель = отвечает на всё» неверна.

Как сравнить честно

Возьми одинаковую задачу, ограничения и набор вопросов. Отдельно оцени два режима. В первом все модели получают один и тот же пакет источников: так сравнивается качество анализа. Во втором каждая работает со своим доступным поиском: так сравнивается исследовательская система целиком.

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

Добавь цену исследования и время своей проверки. Неудачный реселлер с привлекательным тарифом может потребовать больше сопровождения, чем экономит. Неизвестный репозиторий может сэкономить разработку, но усложнить обновления. Решение выбирается по итоговой полезности и риску.

Как просить искать в этом сегменте

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

Не проси «обойти правила другой модели». Это подменяет исследовательскую задачу. Проси изучить саму техническую проблему, происхождение решения, условия доступа и подтверждения. Так ты получаешь материал для выбора, а не коллекцию сомнительных советов.

Ценность китайского исследователя: расширить круг источников и решений. Ценность твоего процесса: превратить находку в проверенный факт. Одно не заменяет другое.

09 / ПОИСК БЕЗ ЯЗЫКОВОГО ТУПИКА

Одна задача, несколько формулировок и языков

Поиск «лучший ИИ для бота» даёт слишком широкий результат. Более полезны запросы, в которых есть операция, среда и симптом. Например: «распознавание русской речи длинные аудио очередь Python» или точный текст ошибки вместе с названием библиотеки.

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

Направление	Пример поискового запроса	Цель
Готовый компонент	`speech transcription job queue Python open source`	Найти решения по функции
Конкретная ошибка	`"CUBLAS_STATUS_NOT_SUPPORTED" "faster-whisper"`	Найти похожее окружение и обсуждение
Китайскоязычный сегмент	`语音转文字开源长音频部署`	Распознавание речи, открытый код, длинное аудио, развёртывание
Риски интеграции	`название проекта known issues migration breaking changes`	Найти ограничения и несовместимости

Китайские слова здесь являются примером запросов, не обязательным словарём. Попроси модель объяснить каждый запрос по-русски. Пусть найденный материал возвращает в виде: оригинальный заголовок, ссылка, краткий перевод, техническая находка, что проверить.

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

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

10 / ДОКАЗАТЕЛЬСТВА

Источник выбирают под вопрос, а не по количеству звёздочек

Универсальная таблица «документация всегда права, форуму верим меньше» слишком груба. Документация объясняет обещанный интерфейс. Исходный код выбранной версии показывает реализацию. Обсуждение пользователя помогает заметить проблему, но не обязательно правильно объясняет её причину. Собственный тест показывает поведение в твоём окружении, но не гарантирует, что оно повторится у всех.

Нужно выяснить	Основной материал	Чем дополнить
Какие параметры поддерживаются?	Документация и код выбранной версии	Минимальный запрос
Почему у человека сломалось?	Первичный отчёт, логи, окружение	Ответ сопровождающего и воспроизведение
Разрешено ли использовать код?	Лицензия конкретного проекта и версии	Условия зависимостей; профильная проверка при сомнениях
Какова цена?	Действующие условия поставщика	Учёт фактического расхода в ограниченном тесте
Подойдёт ли нам?	Наши требования и маленький эксперимент	Стоимость сопровождения и варианты замены

Для каждого важного утверждения вводи один из трёх статусов: найдено в источнике, проверено в эксперименте, пока гипотеза. Не смешивай их. «Автор пишет, что поддерживается» ещё не равно «мы запустили и проверили».

Карточка доказательства

Утверждение: выбранная библиотека поддерживает нужный режим обработки.
Источник: официальная документация, точный раздел.
Версия: релиз или коммит.
Применимость: наша операционная система и формат данных.
Проверка: один тестовый файл с ожидаемым результатом.
Статус: запуск ещё не выполнен.

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

11 / GITHUB

Как выбирать репозиторий, если ты не программист

05 / 09Проверяй репозиторий по задаче, версии, условиям и результатам

Репозиторий можно представить как папку проекта с историей изменений. В ней лежат код, описание, примеры, тесты и иногда обсуждения разработки. Тебе не нужно вручную разбираться во всех файлах. Нужно поставить ИИ правильные вопросы.

Восемь проверок перед выбором

1. Соответствие задаче. Какую именно часть закрывает проект? «Есть ИИ» или «поддерживает ботов» недостаточно. Нужны конкретные операции, форматы и ограничения.

2. Происхождение. Это репозиторий автора, официальный SDK, сторонняя обёртка или зеркало? Кто отвечает за изменения? Куда ведут ссылки с сайта продукта?

3. Поддержка. Есть ли ответы на критичные проблемы, понятные релизы, инструкция обновления? Старый коммит сам по себе не доказывает, что проект мёртв: маленький стабильный инструмент может редко меняться. Но открытые серьёзные поломки без реакции являются отдельным риском.

4. Примеры и тесты. Есть ли минимальный пример нужного тебе сценария? Можно ли понять ожидаемый результат? Скриншот красивого интерфейса не заменяет работающий пример.

5. Окружение. Какая нужна система, версия языка, база, видеокарта или внешний сервис? Это особенно важно, когда разработка идёт на Mac, а запуск планируется на Linux-сервере.

6. Зависимости. Что ещё нужно установить? Какие компоненты критичны? Сколько новых систем появится ради одного небольшого улучшения?

7. Лицензия. Публичный доступ к коду не равен разрешению использовать его любым способом. GitHub прямо объясняет разницу между видимостью репозитория и правами по лицензии. Условия нужно читать для проекта и зависимостей; спорные случаи не решаются одним ответом ИИ.

8. Цена выхода. Сможешь ли ты заменить компонент, перенести данные и продолжить работу, если проект перестанет поддерживаться? Если нет, это нужно учитывать до интеграции.

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

12 / ПРОВЕРКА РЕАЛИЗАЦИИ

Как попросить ИИ изучить код, не читая его самому

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

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

Полезная формулировка

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

Проверяй форму входа и выхода

Фраза «есть загрузка файлов» слишком общая. Один интерфейс может принимать только изображения. Другой может выдавать временную ссылку для последующей загрузки. Третий принимает готовое вложение. Все три называются upload, но требуют разных действий.

Зафиксируй простую таблицу: что передаём, в каком виде, какой размер допускается, что возвращается, когда результат готов и как заметить ошибку. Это называется контрактом интерфейса. Для ученика смысл простой: заранее договориться, что одна часть отдаёт другой.

Если схема API неизвестна, не проси ИИ угадывать названия методов десятками. Сначала найди документацию, исходный код SDK или допустимый тестовый запрос. Точное «этот интерфейс принимает только текст» экономит больше времени, чем длинный список возможных обходных путей.

13 / ФОРУМЫ И ОБСУЖДЕНИЯ

README объясняет замысел. Обсуждения показывают опыт эксплуатации

06 / 09Сопоставляй документацию с первичными обсуждениями и кейсами

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

Но не каждый комментарий является правильным диагнозом. Автор может перепутать библиотеку, не показать важные настройки или использовать старую версию. Поэтому читать надо не только первый пост и не только самый популярный ответ.

Как читать обсуждение с пользой

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

Наконец, выясни исход. Проблема исправлена? Автор нашёл ошибку в настройках? Тема закрыта без решения? Существует лишь предположение другого пользователя? Слово «Closed» не означает автоматически «исправлено для всех».

Что нашли	Как использовать
Один пользователь описал симптом	Добавить гипотезу и проверить похожесть окружения
Несколько людей воспроизвели проблему	Считать риск существенным, искать условия возникновения
Есть минимальный воспроизводимый пример	Повторить в изолированной среде
Есть ответ автора и исправление	Проверить релиз, в который оно вошло
Есть только совет отключить защиту	Не переносить его автоматически; выяснить причину и безопасные варианты

Проси ИИ приносить не «три ссылки на Reddit», а три полезных вывода: какая проблема возникает, при каких условиях и как её проверять. Если обсуждение ничего не меняет в твоём плане, возможно, оно не стоит времени на чтение.

14 / РЕАЛЬНЫЕ КЕЙСЫ

Четыре примера, где исследование меняет план

Первые три кейса основаны на открытых первоисточниках. Четвёртый взят из работы над этой серией гайдов. Это разбор источников и нашего процесса, а не заявление о проведении новых запусков чужих проектов.

КЕЙС 1 · ДЕТАЛЬ ИЗ ДОКУМЕНТАЦИИ

yt-dlp: «поставил пакет» ещё не значит «установил нужный инструмент»

Реальный факт. В документации yt-dlp отдельно подчёркнуто, что для соответствующих операций нужен исполняемый файл ffmpeg, а не одноимённый Python-пакет. В этом же репозитории описаны зависимости для работы с аудио и видео.

Почему это полезно. Новичок видит знакомое название и предполагает, что установка пакета закрыла задачу. ИИ, который не проверил требования, может поддержать эту ошибку. Между тем проблема не в идее продукта, а в форме установленного компонента.

Что меняется в плане. Перед сборкой сервиса агент проверяет список зависимостей и доступность нужных исполняемых программ. Затем запускает маленький тест на собственном или разрешённом видео. Не обещает поддержку любого сайта и не пытается объяснить отсутствие зависимости сложной архитектурной проблемой.

Вывод: точное чтение требований способно заменить часы случайных переустановок.

КЕЙС 2 · ISSUE + ТРЕБОВАНИЯ

faster-whisper: проблема может быть в GPU-окружении, а не в промпте

Реальный отчёт. В Issue #1260 пользователь описал ошибку cuBLAS на RTX 5070 Ti и проблемы с длинными записями. Участник проекта попросил уточнить версию cuBLAS или CUDA Toolkit. Это первичное сообщение о проблеме, а не доказательство, что все такие видеокарты не работают.

Что даёт второй источник. README faster-whisper содержит отдельные требования к GPU-зависимостям и заметки о совместимости CUDA, cuDNN и CTranslate2. Сам факт таких требований показывает, почему фраза «на сервере есть видеокарта» недостаточна.

Что меняется в плане. Агент сначала фиксирует версии окружения и сравнивает их с требованиями выбранного релиза. Затем тестирует короткую и длинную запись. Диагноз строится по результатам, а не по догадке «модель плохая». Не нужно без проверки повторять команды переустановки из чужого обсуждения.

Вывод: опыт пользователя помогает найти направление диагностики; документация и собственный тест помогают проверить его.

КЕЙС 3 · НЕОЧЕВИДНЫЙ КРИТЕРИЙ ГОТОВНОСТИ

Playwright: страница уже полезна, а тест продолжает ждать

Реальный отчёт. В Issue #41513 описано ожидание networkidle, которое в указанном окружении доходило до таймаута при открытом соединении EventSource. Приведён небольшой пример воспроизведения.

Сверка. Документация Playwright не рекомендует использовать networkidle как критерий готовности в тестах и предлагает проверять конкретное состояние интерфейса.

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

Вывод: иногда надо изменить не длительность ожидания, а само определение «готово».

КЕЙС 4 · ИЗ ЭТОЙ СЕРИИ ГАЙДОВ

Передать готовый HTML: важно, что умеет интерфейс, а не как называется сервис

Во время публикации этой серии большой HTML-файл оказалось неудобно передавать через интерфейс, который принимает содержимое строкой. Маленький пример работал, но этого было недостаточно, чтобы считать транспорт готовым для полноценного документа с изображениями.

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

Что здесь важно ученику: сначала выяснить, принимает инструмент строку, файл или ссылку. Если требуется заменить способ доставки, зафиксировать причину и согласовать следующий шаг. После успешной проверки сохранить рабочий путь, чтобы новый агент не начинал эксперименты заново.

Вывод: исследование полезно только тогда, когда заканчивается проверенным решением и записанным правилом работы.

15 / ВЕРСИИ И УСЛОВИЯ

Одинаковое название не гарантирует одинаковых условий

У решения есть не только имя. Есть версия, способ поставки, набор зависимостей, лицензия и условия сервиса. Ответ ИИ «это бесплатный open source» слишком общий, чтобы на его основе строить коммерческий продукт.

Реальный пример: в анонсе Redis 8 разработчик сообщил о добавлении AGPLv3 как варианта лицензии вместе с другими условиями. Для нашего урока важен не юридический разбор Redis, а сам факт: условия нужно проверять по конкретной версии, а не по воспоминанию о продукте.

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

Паспорт выбранного компонента

Название и автор → точный релиз или коммит → документация для этой версии → условия использования → зависимости → результат нашего теста → дата следующей проверки.

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

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

16 / ЧЕТЫРЕ СПОСОБА СДЕЛАТЬ ПРОДУКТ

Написать, купить, адаптировать или соединить

Слова Build, Buy, Fork и Integrate обозначают разные способы получить нужную функцию. Ни один не является правильным всегда. Выбор зависит от того, насколько задача типовая, какие риски допустимы и кто будет поддерживать результат.

Подход	Когда рассматривать	Что проверить заранее
Build: написать своё	Ключевая уникальная логика, специфические ограничения	Срок разработки, тесты, поддержка, зависимость от автора
Buy: взять готовый сервис	Типовая функция, важен быстрый старт	Цена на твоём объёме, данные, лимиты, экспорт, устойчивость поставщика
Fork: сделать свою версию	Основа подходит, нужны изменения внутри	Лицензия, сложность обновлений, объём собственного отличия
Integrate: соединить готовое	Нужны несколько зрелых компонентов	Контракты, отказ одного звена, дубликаты, наблюдение за цепочкой

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

Когда свой код оправдан

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

Когда форк становится обязательством

Сделать копию репозитория легко. Поддерживать её после нескольких собственных изменений сложнее: надо понимать, какие обновления автора совместимы с твоими изменениями. До выбора форка спроси: «Можно ли сделать расширение или отдельный адаптер, не меняя ядро?» Иногда это снижает будущие расходы.

Выбирай минимальную конструкцию, которая выполняет требования и которую ты сможешь поддерживать. Не самую модную и не самую длинную.

17 / ДЕНЬГИ

Считай стоимость результата, а не только тариф API

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

Общая стоимость

Подготовка и интеграция + инфраструктура + использование API + сопровождение + ожидаемые расходы на сбои и переделки.

Ниже учебный расчёт. Это не цены конкретных поставщиков и не коммерческое обещание. Все числа введены для демонстрации метода. Стоимость часа принимаем равной 2 000 ₽.

Статья	Готовый компонент	Своя реализация
Старт	10 часов × 2 000 ₽ = 20 000 ₽	45 часов × 2 000 ₽ = 90 000 ₽
Инфраструктура и API за 3 месяца	6 000 ₽ × 3 = 18 000 ₽	2 000 ₽ × 3 = 6 000 ₽
Поддержка за 3 месяца	2 часа × 2 000 ₽ × 3 = 12 000 ₽	4 часа × 2 000 ₽ × 3 = 24 000 ₽
Итого без оценки сбоев	50 000 ₽	120 000 ₽

В этом сценарии готовый компонент выгоднее на 70 000 ₽. Но если объём запросов вырастет, постоянная часть расходов может изменить вывод. Тогда нужен второй расчёт на ожидаемый объём, а не спор о том, что «своё всегда дешевле».

Почему дешёвый запрос может дать дорогой результат

Допустим, для теста берём условные 2 ₽ за попытку и 80% успешных попыток. Если считать только попытки до одного успеха при неизменной вероятности, средний прямой расход составит 2 / 0,8 = 2,50 ₽. При 3 ₽ за попытку и 98% успеха получится примерно 3,06 ₽. Второй вариант дороже по прямому расходу, но в реальности нужно добавить ожидание, поддержку и повторную обработку. Это упрощённая модель, а не прогноз поведения конкретного API.

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

Полезное бизнес-правило: оцени стоимость одного принятого результата. Для транскрипции это не «API вернул 200», а «получен пригодный текст нужного качества». Для генерации это не «создан файл», а «клиент получил пригодный файл».

18 / ПРОЕКТИРОВАНИЕ

Из списка ссылок должна получиться архитектура

Исследование не завершено, пока у тебя только названия инструментов. Архитектура отвечает на другие вопросы: кто принимает запрос, где сохраняется задание, кто его выполняет, что происходит при ошибке, как человек получает результат и кто имеет право его видеть.

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

Запрос пользователя→Запись задания→Обработка→Сохранение→Ответ и проверка

Контракт между компонентами

Для каждого перехода договорись о входе, выходе и ошибке. Что передаётся: файл, ссылка или идентификатор? Как называется задача? Как узнать, завершилась ли она? Может ли повторный запрос создать второй платёж или вторую обработку? Где записан факт успеха?

Оркестрация отдельно от тяжёлой работы

Если используешь n8n, разумно рассматривать его как координатора: принять событие, вызвать нужную операцию, передать результат дальше. Сложную обработку видео или долгую вычислительную логику можно вынести в отдельный сервис. Это выбранный в этом методе принцип, не обязательное устройство любого проекта.

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

Хороший результат исследования: ты можешь объяснить весь путь данных и назвать причину выбора каждого компонента.

19 / МАЛЕНЬКИЙ ЭКСПЕРИМЕНТ

Маленькая проверка идеи (PoC): сначала проверь главный риск

PoC, или proof of concept, это маленькая проверка принципиальной возможности. Не готовый продукт, не красивое демо, не первый месяц разработки. Его задача: подтвердить или опровергнуть одно важное предположение.

Например, ты рассчитываешь, что выбранный движок правильно распознаёт длинную русскую запись. Для проверки не нужны оплата, профиль пользователя и красивое меню. Нужна разрешённая тестовая запись, способ запуска, ожидаемые критерии и фактический результат.

Риск	Минимальная проверка	Что считать доказательством
Большой файл не проходит	Передать один файл нужного размера	Файл принят целиком, размер и содержимое совпали
Режим API не поддерживается	Один документированный тестовый запрос	Получен ожидаемый формат, включая нужные поля
Код не запускается на сервере	Запустить минимальный пример в похожем окружении	Версии зафиксированы, результат воспроизводим
Обработка слишком дорогая	Ограниченная серия тестов с учётом расхода	Известна стоимость принятого результата
Важны редкие ошибки	Смоделировать один допустимый сбой	Задание не потерялось, понятен следующий шаг

Такой эксперимент может содержать небольшой код. Это не противоречит правилу «сначала исследование»: ты пишешь не весь продукт, а проверку решения. Объём должен соответствовать вопросу. Если ради проверки загрузки файла агент строит полноценный кабинет, задача потеряла фокус.

Где проводить

В отдельной папке или изолированной среде, на тестовых данных и с ограниченными полномочиями. Не запускай первый попавшийся установщик на сервере с клиентскими проектами. Не передавай незнакомому коду основные ключи. Практики изоляции тестов и проверки поведения пользователя также описаны в документации Playwright.

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

20 / ВЫБОР

Как выбрать между тремя хорошими вариантами

Когда все финалисты выглядят достойно, вернись к первоначальным ограничениям. Не добавляй новые критерии только ради понравившегося инструмента. Иначе исследование превращается в оправдание заранее выбранной технологии.

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

После этого сравни гибкие критерии: скорость запуска, общую стоимость, сопровождение, качество документации, наблюдение за ошибками и простоту замены. Вес каждого критерия выбираешь ты. Для первого платного пилота срок запуска может быть важнее максимальной гибкости. Для продукта с большой нагрузкой стоимость эксплуатации может стать решающей.

Пример итогового вывода

«Выбираем вариант B для пилота. Он прошёл проверку длинного файла, укладывается в бюджет и не требует GPU. Вариант A дешевле на большом объёме, но пока не проверен на нашем сервере. Вариант C отклонён, потому что неясны условия хранения данных. Повторим сравнение при росте объёма или изменении требований».

Это лучше, чем «B самый лучший». Здесь есть причина, ограничения и момент пересмотра. Ты не выдаёшь временный выбор за вечную истину.

Когда достаточно исследования

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

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

21 / ДОКУМЕНТЫ ПРОЕКТА

Сохрани исследование так, чтобы следующий ИИ не начинал заново

08 / 09Сохрани исследование и причины выбранных решений

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

Документ	Что внутри
Описание задачи	Пользователь, результат, ограничения, критерии готовности
Исследование	Варианты, первоисточники, даты, найденные ограничения
Сравнение	Почему выбран один путь и отклонены другие
Проверка прототипа	Окружение, входные данные, ожидаемый и фактический результат
Архитектура	Компоненты, путь данных, доступы, ошибки и контроль результата
Чекпоинт	Что уже подтверждено, что осталось, один следующий шаг

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

Передача задачи кодеру

Хорошее поручение включает пять частей: что строим глобально; что делаем сейчас; какие факты уже подтверждены; какие файлы и источники нужны; какой измеримый результат должен получиться. Так агент меньше тратит времени на восстановление смысла.

Например: «Строим бота для обработки записей. Сейчас реализуем только приём файла и запись задания. Формат входа проверен в прототипе. Используй существующую базу. Результат: тестовый файл принят, запись создана, повторная отправка не создаёт дубль». Это конкретная задача, которую можно принять.

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

22 / БЕЗОПАСНОСТЬ ИССЛЕДОВАНИЯ

Чужой текст является материалом, а не начальником твоего ИИ

Внешний README, страница форума или файл могут содержать не только полезные сведения, но и инструкции, которые пытаются изменить поведение агента. Это называется prompt injection: команда прячется внутри материала, который ИИ должен был просто прочитать. OWASP разбирает такие риски и способы ограничения полномочий.

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

Как ограничить риск

Раздели чтение и выполнение. На этапе исследования разрешены поиск, анализ и создание отчёта. Установка и тестовый запуск происходят отдельно, в изолированном месте. Производственные данные, основная база и реальные аккаунты в первый эксперимент не передаются.

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

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

Особенно важно для неизвестного кода

Работающий пример может делать больше, чем обещает его описание. Разрешение прочитать репозиторий не означает разрешение запустить его установщик с полным доступом к компьютеру.

23 / ЦЕЛЬНЫЙ УЧЕБНЫЙ ПРОЕКТ

Как пройти весь путь на примере бота для записей

Дальше учебный сценарий, а не заявленный клиентский кейс. Мы используем его, чтобы показать последовательность решений.

Шаг 1. Не начинать с названия модели

Владелец говорит: «Хочу бота, который разбирает созвоны». Вместо выбора самого популярного ИИ задаём вопросы: какая длительность записи, какие языки, что считается полезным отчётом, куда идут данные, кто оплачивает обработку и какие ошибки недопустимы.

Допустим, для пилота достаточно загрузки файла и текстового отчёта. Тогда не строим автоматически запись звонков в реальном времени, голосовой интерфейс и CRM. Они не нужны для проверки основной ценности.

Шаг 2. Разделить исследование

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

В ответах могут появиться разные стеки. Не соединяем их автоматически в один огромный проект. Сначала сравниваем, какую проблему решает каждый компонент и какие новые зависимости он добавляет.

Шаг 3. Выбрать главный риск

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

Шаг 4. Сделать ограниченный эксперимент

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

Результат записываем без украшений. Не «качество отличное», а «в этих записях пропущены такие фрагменты; имена требуют проверки; обработка закончилась; расход составил столько-то по учёту». Числа появляются только после измерения.

Шаг 5. Спроектировать минимальный продукт

Выбранная цепочка получает явные состояния: принято, обрабатывается, завершено, ошибка. Файл и результат относятся к конкретному пользователю. Длительная работа не держится только в памяти открытого чата. Повторная отправка не создаёт бесконечные платные операции.

Шаг 6. Передать кодеру готовую основу

Кодер получает не десять противоречивых отчётов, а итоговый выбор, источники, проверенный прототип и этапы. Сначала один пользовательский путь, затем ошибки и восстановление, затем дополнительные функции. После каждого изменения применяются тесты из Гайда №13.

Шаг 7. Проверить бизнес-результат

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

В этом маршруте ИИ пишет код, но только после того, как стало понятно, какой результат нужен и на каких готовых компонентах разумно его строить.

24 / ТРЕНИРУЕМ ВЫБОР

Три фразы, которые нужно научиться проверять

Нажми на пример и сравни своё решение с разбором. Здесь нет скрытого теста на знание программирования. Проверяем качество мышления.

«У проекта 30 тысяч звёзд, значит можно брать»

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

«Китайский ИИ дал более подробный ответ, значит он прав»

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

«Мы нашли SDK, осталось просто подключить»

Нужно проверить, поддерживает ли SDK нужную функцию и текущую версию API. Затем вход, выход, ошибки, таймауты, лимиты и условия работы с данными. Готовый SDK уменьшает объём своего кода, но не отменяет проектирование интеграции.

Ошибка противоположного знака: бесконечно исследовать

Можно потратить неделю на сравнение двадцати похожих библиотек и ни разу не проверить одну из них. Чтобы этого не произошло, у исследования должен быть критерий завершения: выбран подход, подтверждена критичная возможность, известны основные ограничения и есть следующий шаг.

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

Исследуй до управляемой неопределённости

Тебе не нужна абсолютная уверенность во всём. Нужно понимать, что уже доказано, что ещё неизвестно и как ограничить последствия этой неизвестности.

25 / ШПАРГАЛКА

Непонятные слова простыми словами

Таблица специально сделана для телефона. Можно вернуться к ней из нижней панели в любой момент. Термины не нужно учить наизусть: достаточно понимать, какую задачу они обозначают.

Словарь терминов исследования и проектирования
Термин	Что означает и пример
Исследование (research)	Поиск и проверка сведений перед выбором решения.Не «назови инструмент», а «найди варианты и проверь ограничения».
сначала исследование	Сначала исследование, затем осознанный план реализации.Перед написанием загрузчика посмотреть готовые решения.
Опора на источники (grounding)	Ответ строится с использованием конкретных материалов.Вывод сопровождается разделом документации, который его подтверждает.
Галлюцинация	Правдоподобное, но неподтверждённое или ошибочное утверждение ИИ.Модель выдумала параметр API.
Первоисточник	Материал автора продукта, исследования или исходного сообщения.Документация автора или Issue человека, столкнувшегося с ошибкой.
Репозиторий	Хранилище файлов проекта и истории изменений.Папка проекта на GitHub.
README	Вводное описание проекта.Что делает инструмент и как начать.
Карточка проблемы (issue)	Карточка проблемы, вопроса или предложения в проекте.Пользователь описал сбой на определённой версии.
Обсуждение (discussion)	Обсуждение применения, идеи или вопроса.Как организовать обработку длинных файлов.
Commit / коммит	Зафиксированный набор изменений.Точная точка в истории, к которой относится вывод.
Релиз (release)	Опубликованная версия продукта или библиотеки.Версия, которую выбрали для установки.
Журнал изменений (changelog)	Список заметных изменений между версиями.Какие параметры переименовали при обновлении.
Запрос на объединение (pull request)	Предложение внести изменение в код проекта.Исправление есть в обсуждении, но ещё не вошло в релиз.
Форк, отдельная копия проекта	Отдельная копия проекта со своей историей изменений.Адаптируем существующий проект под свою задачу.
Библиотека	Готовая функциональность, которую можно подключить к программе.Обработка формата файла без собственной реализации формата.
Фреймворк	Каркас с правилами построения приложения.Общая организация веб-приложения.
Набор инструментов разработчика (SDK)	Набор инструментов для работы с конкретной системой.Клиент для вызова API поставщика.
API	Интерфейс, через который программы обмениваются запросами и результатами.Сервис принимает аудио и возвращает текст.
Контракт интерфейса	Точные договорённости о входе, выходе и ошибках.Принимается файл, возвращается идентификатор задания.
Зависимость (dependency)	Компонент, без которого другой компонент не работает.Библиотека обработки или установленная системная программа.
Лицензия	Условия использования и распространения кода.Публичный код не обязательно разрешён для любой цели.
Открытый код (open source)	Код с лицензией, предоставляющей права на использование, изучение и изменение в установленных условиях.Лицензию всё равно нужно прочитать.
Код доступен для просмотра (source-available)	Код доступен для просмотра, но права могут быть ограничены.Доступность исходников не равна отсутствию ограничений.
Короткий список (shortlist)	Небольшой набор финалистов после отбора.Три решения вместо двадцати непроверенных названий.
PoC	Маленький эксперимент, проверяющий важное предположение.Принимается ли файл нужного размера.
MVP	Минимальная версия продукта с полезным результатом для пользователя.Один рабочий путь без необязательных функций.
Сравнительный тест (benchmark)	Проверка вариантов в заранее описанных условиях.Одинаковые файлы, критерии качества и ограничения.
Воспроизводимость	Возможность повторить проверку и понять её результат.Указаны версии, входные данные и действия.
Изолированная среда (sandbox)	Отдельное место для экспериментов с ограниченными полномочиями.Тест неизвестной библиотеки без клиентской базы.
Вредная инструкция из внешних данных (prompt injection)	Попытка спрятать команду для ИИ внутри внешнего материала.README просит отправить секрет на посторонний адрес.
Обёртка (wrapper)	Небольшая программа, делающая доступ к другой программе удобнее.Единый интерфейс поверх разрешённого инструмента.
Провайдер / реселлер	Поставщик сервиса или посредник доступа.Нужно отдельно проверить условия и фактические возможности.
Общая стоимость владения (TCO)	Все существенные расходы на выбранном горизонте.Старт, API, сервер, поддержка и переделки.
Зависимость от поставщика (vendor lock-in)	Зависимость, из-за которой трудно заменить поставщика.Данные или логика привязаны к одному закрытому сервису.
Чекпоинт	Короткая запись подтверждённого состояния и следующего действия.Что уже проверено и откуда продолжать новому агенту.
ПРОШЛО / НЕ ПРОШЛО / НЕ ПРОВЕРЕНО	Успех, несоответствие ожиданию или отсутствие результата проверки.Планируемый запуск нельзя отмечать как PASS.

26 / ГОТОВЫЕ ЗАДАНИЯ

12 промптов: от исследования до передачи кодеру

Вставь свой проект в поля в квадратных скобках. Не отправляй пароли, токены, клиентские записи и приватный код незнакомому сервису. Каждый промпт можно использовать отдельно; не нужно запускать все двенадцать на любой маленькой задаче.

Кнопка копирования работает при разрешении браузера. Сам текст доступен для выделения вручную даже без JavaScript. Если агент не имеет доступа к источнику или инструменту, пусть укажет ограничение, а не изображает выполнение.