ИИ на подхвате: Как фрилансеру успевать больше и отдыхать без чувства вины

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

1. повторяется хотя бы раз в неделю;

2. приводит примерно к одинаковому результату;

3. не требует от ИИ самостоятельно принимать юридические, финансовые или репутационные решения;

4. поддаётся проверке по нескольким понятным признакам.

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

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

Упражнение «Сузить процесс»

Запишите процесс в одной фразе по формуле: «Раз в такой-то срок я превращаю такие-то исходные данные в такой-то результат для такого-то получателя».

Например: «Раз в неделю я превращаю записи о разработке сайта в короткий отчёт для клиента без технических подробностей».

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

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

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

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

Протокол испытания

Перед началом Павел завёл простую запись в рабочем документе. Он решил отслеживать пять показателей.

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

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

Исправления. Павел записывал фактические ошибки и переделки, которые возникли до или после отправки. Так становился заметен скрытый долг проверки.

Усталость. Сразу после завершения он ставил оценку от 0 до 10. Этот показатель помогал увидеть, как процесс влияет на состояние, а не только на количество потраченных минут.

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

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

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

Дневник семи дней

День первый. Проверить обещание скорости

В первый день Павел хотел взять привычные исходные данные и попросить ИИ подготовить черновик без сложной настройки.

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

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

Павел не отправил текст как готовый отчёт. Он обозначил его как пробный формат.

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

Марина: «Я вижу, что что-то изменилось в коде, но не понимаю, что уже готово для посетителей сайта. И нужно ли мне сейчас что-то проверить?»

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

К концу дня стало ясно: ИИ ускорил появление первого текста, но не создал понятного отчёта. Скорость черновика нельзя считать экономией, пока не учтены проверка, переделка и вопросы получателя.

День второй. Проверить качество входа

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

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

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

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

Павел разложил исходные сведения на три слоя.

Факт: обработчик формы перенесён на тестовый стенд.

Интерпретация: форма работает стабильнее.

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

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

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

Павел затратил 43 минуты. Четыре раза он возвращался к исходным заметкам, дважды исправлял статус и отдельно проверял, не перепутал ли тестовую и рабочую версии. Усталость составила 6 баллов из 10.

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

День третий. Проверить формат для получателя

Теперь Павел передал ИИ более чистые данные и хотел понять, решит ли это проблему понятности.

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

Факты действительно были переданы точно. Качество фактической части поднялось до пяти баллов из пяти. Но отчёт вырос до семисот слов и начинался с технического объяснения архитектуры формы. Для Павла это была логичная последовательность. Для Марины — лишний путь к ответу.

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

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

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

«Сделано» — две-три конкретные задачи без внутренних технических подробностей.

«Что это меняет» — один абзац о результате для сайта или бизнеса.

«Что ещё в работе» — незавершённые задачи с честными статусами.

«Что нужно от Марины» — конкретное действие или фраза «действий не требуется».

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

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

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

День четвёртый. Проверить цену отсутствия проверки

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

Он добавил в запрос требование не выдумывать статусы и соблюдать новую структуру. Черновик получился коротким и удачным. Через 22 минуты он был почти готов к отправке.

«Почти» оказалось самым важным словом всего эксперимента.

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

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

Павел ввёл короткую проверку из четырёх шагов.

Сначала он сверял даты, числа и названия выполненных работ с источником.

Затем отдельно проверял слова со статусом: «готово», «запущено», «проверяется», «заблокировано».

После этого читал только блок «Что это меняет» и задавал себе вопрос: следует ли вывод из фактов или он просто звучит убедительно?

В конце Павел проверял, ясно ли, требуется ли действие от Марины.

Проверка заняла семь минут. Ошибок в отправленном документе не было, но одна потенциальная ошибка была найдена и исправлена. Усталость составила 4 балла. Павел понял, что человеческая ответственность не исчезает от того, что текст написал ИИ. Она становится короче и конкретнее, если проверять не весь текст одинаково внимательно, а заранее определить зоны риска.

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

День пятый. Проверить, не стал ли инструмент отдельной работой

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

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

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

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

За день Павел потратил 68 минут. Он совершил девять непредвиденных действий: трижды переносил данные между форматами, дважды возвращался к исходному запросу, искал причину изменения структуры, вручную восстанавливал порядок блоков и перепроверял результат после каждой правки. Усталость составила 8 баллов.

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

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

День шестой. Убрать лишнее

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

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

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

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

Подготовка заняла 29 минут: десять минут ушло на заполнение формы, тринадцать — на черновик и шесть — на проверку. Качество внутренней версии составило 5 баллов из 5, усталость — 3 балла, непредвиденных действий было два.

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

Устойчивый процесс оказался не самым автоматизированным. Он состоял из чистого входа, одного ограниченного поручения ИИ и короткой проверки человеком.

День седьмой. Сравнить не впечатления, а способы

В последний день Павел подготовил настоящий отчёт и должен был принять решение по итогам всей недели.

Он заполнил шесть полей по текущей неделе, получил черновик и прошёл проверку. В финальной версии было четыре блока.

В разделе «Сделано» Павел указал, что форма заявки обновлена и проверена на тестовом стенде.

В разделе «Что это меняет» объяснил, что после запуска посетителю будет проще отправить заявку, а Марине станет легче отслеживать обращения.

В разделе «Что ещё в работе» честно написал, что проверка на рабочем сайте ещё не завершена.

В разделе «Что нужно от Марины» попросил подтвердить удобство двух полей формы после тестовой проверки.

Сообщение клиентке было коротким.

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

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

Ответ Марины не доказывал, что ИИ стал незаменимым. Он подтверждал более узкое утверждение: при чистом входе, заданном формате и человеческой проверке новый способ делает отчёт удобнее.

Павел свёл результаты в несколько строк.

Прежний способ занимал 52 минуты. Качество отчёта оценивалось в 4 балла из 5. После отправки понадобилось ещё восемь минут объяснений. Усталость составила 6 баллов из 10, а непредвиденных действий было пять.

Первый вариант с ИИ занимал 43 минуты до отправки. Качество отчёта составило 2 балла из 5. На проверку ушло 14 минут, ещё семь минут потребовалось на объяснение клиентке. Усталость осталась на уровне 6 баллов, а число непредвиденных действий выросло до шести.

Упрощённый вариант потребовал 29 минут подготовки и шесть минут проверки. Качество достигло 5 баллов из 5, исправлений после отправки не было. Усталость снизилась до 3 баллов, а непредвиденных действий осталось два.

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

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

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

Журнал сбоев

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

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

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

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

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

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

Запись может выглядеть так: «Черновик утверждает, что форма запущена. Источник говорит “готово к проверке”. Причина: смешаны рабочий и тестовый статусы. Изменение: добавить отдельное поле “где проверено” и запретить объединение статусов».

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

Четыре решения после недели

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

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

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

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

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

Упражнение «Закрыть испытание»

В конце своей недели составьте короткую запись из четырёх строк.

«Старый способ занимал…»

«Новый способ занимает…»

«Качество изменилось так…»

«Моё решение и причина…»

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

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

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

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