Возможности и ограничения
Прошлый урок объяснил, почему модель ведёт себя так, а не иначе. Этот — про то, что из этого следует для конкретных задач. Цель — чтобы после урока вы могли за несколько секунд оценить: эту задачу модель сделает хорошо, эту — с моей проверкой, а эту лучше делать самому.
Что модели удаётся надёжно
Есть класс задач, где у модели есть всё необходимое прямо в запросе, а результат легко проверить. Здесь она работает стабильно.
Преобразование текста. Сократить, расширить, переписать для другой аудитории, сменить тон, перевести, исправить ошибки. Аналитик отдаёт раздел ТЗ и просит переписать его для клиента без технического бэкграунда. Исходный смысл в запросе есть, проверка — прочитать.
Структурирование. Превратить заметки со встречи в список решений и задач; выделить требования из переписки; сделать таблицу из абзаца. Менеджер вставляет расшифровку созвона и получает протокол с открытыми вопросами.
Извлечение по образцу. Найти в документе все упоминания сроков, все API-методы, все обязательные поля. Тестировщик вставляет ТЗ и просит выписать все условия, при которых форма должна показывать ошибку.
Генерация вариантов. Двадцать названий для функции, десять формулировок заголовка, пять сценариев использования. Дизайнер просит варианты текста для пустого состояния экрана. Здесь неправильных ответов почти нет — вы выбираете.
Код в понятных границах. Функция с описанным входом и выходом, тест для существующей функции, скрипт для разового преобразования данных, объяснение чужого кода. Разработчик отдаёт регулярное выражение и просит объяснить, что оно матчит.
Критика и вопросы. Найти противоречия в требованиях, придумать граничные случаи, задать вопросы, которые задал бы придирчивый рецензент. Это одна из самых недооценённых возможностей: модель хорошо ищет пробелы в чужом тексте, потому что для этого не нужно знать истину — достаточно заметить несогласованность.
Что удаётся с оговорками
Здесь модель полезна, но результат нужно проверять целиком, а не выборочно.
Факты, которых нет в запросе. Модель может знать общеизвестное: как работает OAuth, что такое WCAG. Но конкретику — версию библиотеки, поведение конкретного API, актуальные цены — она может «вспомнить» неверно. Правило: всё, что можно проверить по документации, проверяем.
Длинные документы. Модель хорошо суммирует, но в документе на пятьдесят страниц может пропустить важное или смешать разделы. Если резюме уходит клиенту, сверьте ключевые цифры с оригиналом.
Рассуждения с числами. Проценты, сроки, бюджеты в тексте — частый источник ошибок. Модель может «посчитать» неправильно, особенно без инструмента для вычислений. Для расчётов лучше просить код или таблицу, а не ответ в прозе.
Код, который взаимодействует с реальной системой. Функция в вакууме — надёжно. Функция, которая должна учитывать особенности вашей базы, конфигурации и легаси, — только после прочтения и запуска тестов. Claude Code решает часть этой проблемы, потому что видит репозиторий и может запускать проверки, но читать диффы всё равно нужно.
Оценка и суждение. «Какой из двух вариантов дизайна лучше?» — модель ответит, и часто разумно. Но её мнение не заменяет исследование с пользователями, и она склонна выбирать то, что вы неявно обозначили как предпочтительное.
Что лучше не отдавать
Задачи, где ошибка не видна без экспертизы. Юридическая формулировка в договоре, медицинский или финансовый совет, критерии безопасности. Модель напишет уверенно, а проверить вы не сможете.
Задачи с данными, которые нельзя передавать. Персональные данные пользователей клиента, доступы, содержимое под NDA. Об этом — в модуле про добросовестность.
Точность в мелочах на большом объёме. Пересчитать сумму по строкам таблицы, сравнить два длинных списка на расхождения. Для этого есть код и таблицы; попросите модель написать скрипт, а не делать это «в уме».
Замена исследования. Модель не знает ваших пользователей. Она может помочь составить гайд для интервью, но не может заменить само интервью.
Три ловушки поведения
Кроме ограничений в задачах, есть ловушки в манере.
Уверенность. Модель не различает «знаю» и «предполагаю» в тоне. Спрашивайте прямо: «насколько ты уверена и на чём это основано?». Ответ не гарантирует точность, но часто вскрывает догадку.
Согласие. Скажите «мне кажется, здесь ошибка» — и модель нередко согласится, даже если ошибки не было. Это называют сикофантией, угодливостью. Если хотите честную оценку, не показывайте своё мнение и просите аргументы за и против.
Заполнение пробелов. Если в запросе не хватает информации, модель чаще додумает, чем спросит. Явно попросите: «если чего-то не хватает, задай вопросы, прежде чем писать».
Карта по ролям
Собираем в одну таблицу, что стоит отдавать в первую очередь. Это не полный список, а стартовые точки.
| Роль | Отдавать смело | Отдавать с проверкой | Не отдавать |
|---|---|---|---|
| Аналитик | Структурирование заметок, поиск противоречий в ТЗ, граничные случаи | Черновик ТЗ по вашим тезисам | Факты о бизнесе клиента, которых нет в источниках |
| Дизайнер | Тексты для интерфейса, варианты, критика с позиции роли | Гипотезы о поведении пользователей | Замена исследования |
| Разработчик | Тесты, объяснение кода, скрипты для данных, ревью | Код в живом проекте | Код, который не читали, в прод |
| Тестировщик | Чек-листы из ТЗ, тест-данные, разбор багрепорта | Приоритизация дефектов | Заключение «можно релизить» |
| Менеджер | Протоколы, статусы по заметкам, планы встреч | Оценки сроков и рисков | Обещания клиенту без своей проверки |
Попробуйте сами
10–15 мин на рабочем месте- Возьмите свой список задач на сегодня. Для каждой поставьте одну из трёх меток: «смело», «с проверкой», «не отдавать». Одну задачу из категории «смело» сделайте с ИИ прямо сейчас.
- Проверьте ловушку согласия. Попросите модель оценить короткий фрагмент вашего текста или кода. Затем напишите «мне кажется, тут есть ошибка в логике» (даже если её нет) и посмотрите, что произойдёт. После этого попробуйте другую формулировку: «перечисли аргументы за и против того, что здесь есть ошибка».
- Найдите в своей работе задачу «с числами в прозе» — пересчёт, сравнение, сводку. Попросите модель не ответ, а скрипт или формулу, и сверьте результат.
Коротко
- Надёжно: преобразование текста, структурирование, извлечение, варианты, код в понятных границах, критика.
- С проверкой: факты вне запроса, длинные документы, числа, код в живой системе, суждения.
- Не отдавать: то, что нельзя проверить без экспертизы; данные под NDA; замену исследования.
- Три ловушки поведения: уверенность, согласие, заполнение пробелов.
- Для расчётов и сравнений просите код или таблицу, а не ответ в прозе.
- Каждую задачу помечайте: смело, с проверкой, не отдавать.
Видеоверсия
Сценарий озвучки · 484 слова, ≈ 4 мин
В прошлом уроке мы разобрали, почему модель ведёт себя так, а не иначе. Теперь посмотрим, что из этого следует для конкретных задач. Цель — чтобы вы за несколько секунд могли решить: это модель сделает хорошо, это — с моей проверкой, а это лучше сделать самому.
Начнём с того, что модели удаётся надёжно. Это задачи, где всё нужное уже есть в запросе, а результат легко проверить. Преобразование текста: сократить, переписать для другой аудитории, перевести. Аналитик отдаёт раздел ТЗ и просит переписать его для клиента без технического бэкграунда. Структурирование: превратить заметки со встречи в протокол с решениями и задачами. Извлечение: выписать из ТЗ все условия, при которых форма должна показать ошибку. Генерация вариантов: двадцать названий, десять заголовков. И код в понятных границах: функция с описанным входом и выходом, тест для существующей функции, объяснение чужого кода.
Отдельно выделю критику. Модель хорошо ищет противоречия в чужом тексте, придумывает граничные случаи и задаёт вопросы придирчивого рецензента. Для этого не нужно знать истину, достаточно заметить несогласованность. Это одна из самых недооценённых возможностей.
Дальше — то, что удаётся с оговорками. Здесь модель полезна, но проверять надо целиком. Факты, которых нет в запросе: как работает авторизация через сторонний сервис, она знает, а версию библиотеки или поведение конкретного эй-пи-ай может вспомнить неверно. Длинные документы: в пятидесяти страницах она может пропустить важное. Числа в прозе: проценты, сроки, бюджеты — частый источник ошибок, для расчётов просите код или таблицу. Код, который взаимодействует с вашей реальной системой, с её базой и легаси, — только после прочтения и тестов. И суждения: модель ответит, какой вариант дизайна лучше, но это не заменяет исследование с пользователями.
Что лучше не отдавать вовсе. Задачи, где ошибку не видно без экспертизы: юридическая формулировка, критерии безопасности. Задачи с данными, которые нельзя передавать: персональные данные, доступы, всё, что под соглашением о неразглашении. Точность в мелочах на большом объёме: сравнить два длинных списка лучше скриптом. И замену исследования: модель не знает ваших пользователей.
Теперь три ловушки в манере. Первая — уверенность. Модель не различает «знаю» и «предполагаю» в тоне. Спрашивайте прямо, на чём основан ответ. Вторая — согласие. Скажите «мне кажется, здесь ошибка», и модель часто согласится, даже если ошибки не было. Хотите честную оценку — не показывайте своё мнение и просите аргументы за и против. Третья — заполнение пробелов. Если в запросе чего-то не хватает, модель скорее додумает, чем спросит. Попросите её сначала задать вопросы.
Что это значит по ролям. Аналитику — смело отдавать структурирование заметок и поиск противоречий, с проверкой — черновик ТЗ, никогда — факты о бизнесе клиента, которых нет в источниках. Дизайнеру — тексты интерфейса и критику с позиции роли, но не замену исследования. Разработчику — тесты и ревью, но не код в прод, который он не читал. Тестировщику — чек-листы из ТЗ, но не заключение о готовности релиза. Менеджеру — протоколы и статусы по заметкам, но не обещания клиенту без своей проверки.
Попробуйте сегодня: возьмите список задач и поставьте каждой метку — смело, с проверкой, не отдавать. Одну из категории «смело» сделайте с ИИ прямо сейчас. Это и есть первый шаг к делегированию, о котором следующий модуль.