AI-воркшоп для фаундеров: риски промптов и правила рабочего процесса

Почему маленькие команды застревают с ИИ

Маленькие команды редко застревают потому, что ИИ слишком сложный. Обычно проблема в том, что каждый использует его по-своему. Один человек пишет аккуратные промпты. Другой вставляет туда половину письма клиенту. Кто-то еще просит сгенерировать код или текст и пропускает проверку. В итоге качество скачет, доверие падает, а сомнений становится только больше.

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

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

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

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

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

Что нужно принести в комнату

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

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

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

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

• имена клиентов и контакты
• частные договоры или условия цен
• не опубликованные планы продукта
• пароли, токены и внутренние данные систем

Такой список помогает команде говорить о рисках конкретно. Разговор остается на нормальном языке и не уходит в абстрактную политику.

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

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

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

Риски промптов простыми словами

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

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

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

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

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

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

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

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

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

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

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

Затем назначьте проверяющего для каждого типа результата еще до того, как кто-то начнет пользоваться инструментом. Не оставляйте это на принцип «кто будет рядом». Если ИИ пишет sales-копирайт, его проверяет founder или руководитель маркетинга. Если он генерирует код, который затрагивает billing, его проверяет инженер, отвечающий за эту область. Один четкий владелец всегда лучше общей ответственности.

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

• остановиться, если в результате упоминаются цена, экономия, выручка или гарантии
• остановиться, если есть юридические формулировки, текст политики или заявления о compliance
• остановиться, если указаны факты, цифры или имена, которые команда не предоставляла
• остановиться, если даются медицинские, налоговые или security-советы уверенным тоном

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

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

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

Как выбрать подходящий рабочий процесс

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

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

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

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

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

Простой таблицы решений достаточно:

• Внутренняя сводка -> один промпт и быстрая проверка
• Письмо клиенту -> черновик от ИИ плюс человеческая редактура
• Политика или юридический текст -> только вручную
• Шаблоны для массовой поддержки -> черновик ИИ на основе одобренных примеров

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

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

План 90-минутного воркшопа

Держите комнату небольшой: founder, один builder, один operator и человек, который будет проверять результат ИИ на следующей неделе. Четырех человек достаточно. Цель — уйти с одним рабочим процессом, а не с россыпью идей.

1. Минуты 0–10: выведите на экран две реальные задачи команды. Выберите работу, которую команда уже делает каждую неделю, например, ответ клиенту или превращение sales-звонка в список действий. Для каждой задачи спросите, что входит на вход, каким должен быть результат и кто его проверяет.
2. Минуты 10–25: вместе отметьте риски промптов. Используйте тот текст, который команда реально вставила бы в инструмент, и обведите все, что не должно покидать компанию, все, что модель может придумать, и все, что может создать юридические проблемы или подорвать доверие клиента. Лучше всего это работает, когда люди немного спорят.
3. Минуты 25–45: запишите правила проверки простыми словами. Без языка политик. Пишите правила, которые люди смогут выполнить в обычный загруженный вторник, например: «ИИ может написать черновик, но отправляет его человек» или «Если в результате есть числа, проверьте источник перед тем, как делиться текстом».
4. Минуты 45–70: перестаньте спорить и протестируйте один рабочий процесс на живом примере. Выберите только один путь, например: промпт -> черновик -> проверка человеком -> отправка. Посмотрите, где команда начинает сомневаться, где промпту не хватает контекста и где проверка занимает слишком много времени. Если процесс уже в комнате ощущается неловким, позже он провалится еще быстрее.
5. Минуты 70–90: назначьте владельцев и следующие шаги. Один человек отвечает за шаблон промпта, второй — за чеклист проверки, третий — собирает первые пять результатов для обратной связи. Назначьте короткий тест уже на следующий день, а не на следующий месяц.

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

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

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

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

Обычный промпт работает хорошо:

Write a short customer support reply based on these ticket details.

Issue: Customer says the package arrived late and wants a refund.
Order status: Delivered 3 days after the promised date.
Policy: Refunds need human approval. We can offer an apology and explain the review process.
Tone: Calm, clear, polite, no blame.

Draft a reply in 120 words or less. Do not promise a refund. Do not invent facts. If details are missing, say what support will check next.

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

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

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

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

Ошибки, которые съедают сессию

Самый быстрый способ потерять комнату — потратить половину времени на спор об инструментах. Фаундеры часто сравнивают модели, вкладки и цены еще до того, как определят задачу. Это заводит команду в круги. Начните с одной реальной задачи, которая уже болит, например, follow-up после продаж, заметка по разбору бага, ответ поддержки или слишком долгий черновик спецификации.

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

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

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

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

Короткая проверка перед началом

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

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

Перед началом сессии проверьте такие пункты:

1. Команда может назвать несколько разрешенных задач простыми словами, и все согласны, что остается под запретом.
2. Правила промптов достаточно простые, чтобы их запомнить. Никаких паролей, сырых данных клиентов, условий частных договоров или всего, что вы не стали бы вставлять в общий чат.
3. У каждой задачи есть один владелец проверки. Один человек смотрит результат, дает обратную связь и решает, безопасен ли результат.
4. Команда сохраняет один стартовый промпт для первого живого прогона. Это убирает догадки и не дает людям тестировать сразу пять разных стилей.
5. У пилота есть scorecard. Считайте ошибки, минуты на исправление и то, как часто команде приходится переделывать работу с нуля.

Небольшой пример помогает это представить. Допустим, стартап из четырех человек хочет использовать ИИ, чтобы превращать заметки с sales-звонков в follow-up письма. Более безопасная первая версия — не «отправить письмо», а «сделать черновик письма из очищенных заметок, убрав имена и цены». Founder или sales lead проверяет каждый черновик. Команда смотрит, сколько правок требует каждый вариант и экономит ли он хотя бы 10 минут.

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

Что делать в первую неделю после воркшопа

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

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

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

• какую задачу человек пробовал
• что именно ИИ сделал неправильно
• что пришлось исправить человеку
• сколько времени задача заняла до и после
• заметило ли правило проверки проблему

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

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

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

Если вам нужна внешняя проверка, Oleg Sotnikov на oleg.is помогает стартапам уточнять границы промптов, правила проверки и практичные AI-процессы в роли Fractional CTO и советника стартапов. Короткий разбор может заметить пробелы, которые изнутри компании выглядят нормальными.