За этот урок ты сделаешь две вещи: настроишь приватность — три минуты — и заберёшь рабочий промпт, который превращает «глянь это резюме» в структурированную справку с доказательствами. А дальше начнётся самое интересное: как понять, где эта справка врёт.
Резюме — это персональные данные человека, который доверил их тебе под конкретную вакансию. Отвечает за них не сервис, а тот, кто их собрал (в законе — «контролёр» или «оператор» данных): ты, агентство или клиент, который дал тебе вакансию. Что бы ты ни делал с ИИ, три вещи не меняются: отдавай минимум данных, работай только в инструменте, разрешённом работодателем или клиентом, и решение о человеке принимай сам. Упражнения этого урока сделаны на синтетических резюме именно поэтому — чтобы учиться можно было не на живых людях.
По умолчанию потребительские тарифы всех трёх систем могут использовать твою переписку для обучения моделей. Проверено нами, август 2026: на только что созданном бесплатном аккаунте Claude этот переключатель стоял включённым. Это не заговор — просто настройка по умолчанию, и она меняется за три минуты. Раз в несколько месяцев туда стоит заглянуть ещё раз: интерфейсы и названия переключателей меняются, а новый тариф настройки не наследует.
| Система | Переключатель | Где |
|---|---|---|
| Claude | «Help improve our AI models» | Settings → Privacy → выключить |
| ChatGPT | «Improve the model for everyone» | Settings → Data Controls → выключить |
| Gemini | «Keep Activity» | Activity → выключить + удалить историю |
Одна честная поправка: это не то же самое, что «данные нигде не хранятся». Сервис всё равно обрабатывает их и какое-то время держит: Claude — 30 дней после удаления чата, ChatGPT — тоже до 30 дней, Gemini — 72 часа даже с выключенной активностью, а то, что попало на проверку людям, живёт дольше и твоей кнопкой не удаляется. Поэтому тренироваться лучше на синтетических резюме (они есть ниже, забирай), а перед работой с реальными CV сверься с правилами своего работодателя или клиента: у части компаний есть собственный перечень разрешённых инструментов.
Два нюанса: платный тариф «для одного пользователя» переключатель сам не выключает, и действует это только вперёд. Если работаешь с данными клиентов агентства — потребительского тарифа мало, и собственный «тариф для команд» сам по себе вопрос не закрывает. Нужны две вещи: бизнес-тариф с подписанным соглашением об обработке персональных данных (его ещё называют DPA) — и разрешение клиента именно на этот сервис. Клиент, который дал тебе вакансию, отвечает за данные своих кандидатов и имеет право знать, через какие инструменты они проходят. Проверь оба пункта до первого реального резюме — это одна короткая переписка, а не проект. Актуальные пути держим в «Срезе рынка» — он входит в Модуль 1.
Большинство формулирует задачу одним предложением: «глянь это резюме под вакансию». Ответ приходит уверенный — и звучит одинаково уверенно независимо от того, хватало ли системе данных для вывода. Аккуратный текст и правдивый текст — разные вещи, и на глаз они не отличаются.
Вместо одного предложения даём структуру из шести блоков: роль — кем система работает; контекст — что подаём на вход; задача — одно конкретное действие; критерии успеха — как выглядит хороший ответ; формат и ограничения — что делать, когда данных не хватает. Самые ценные — два последних: именно они ловят выдумки ещё до того, как те появятся.
Вставь его в любую систему, подставь свою вакансию и резюме кандидата в квадратные скобки — и получишь структурированную справку вместо пересказа.
Роль: ты — ассистент-рекрутер, который готовит аналитическую справку по кандидату для рекрутера, а не окончательное решение о найме. Контекст: Вакансия: [вставить полный текст вакансии]. Кандидат: [вставить резюме — без ФИО и контактов, компании как «отрасль + размер», учебное заведение как категория]. Задача: проанализируй соответствие кандидата вакансии. Критерии успеха ответа: 1. Оцени соответствие по каждому требованию вакансии отдельно (стек/навыки, годы опыта, уровень должности). 2. Выдели сильные стороны кандидата со ссылкой на конкретный факт из резюме. Доказательством считается описанное действие: выполненная задача, полученный результат или измеримая метрика. Перечень навыков и название должности доказательством не являются. Утверждение об изменении — «во столько-то раз», «на столько-то процентов», «значительно», «существенно» — без значений до и после доказательством не считай: отметь его как требующее проверки. Это касается именно изменения; абсолютные числа («~600 сценариев», «40 DAG-ов») проверяются вопросом, а не этим правилом. Если результат описан через «мы» — «мы снизили», «мы перешли», «нам удалось» — в сильные стороны его не засчитывай: из текста не видно, что делал именно этот кандидат. Отнеси к «Рискам» с пометкой «вклад кандидата не виден». Это не минус кандидату: цифры могут быть правдивы, неизвестна лишь его роль в них. Обратное — тоже правило. Если кандидат пишет о себе в единственном числе («сделал», «вынесла», «построил»), не ставь авторство под сомнение: вопрос «сам ли это делал» задаётся тогда, когда на него указывает текст резюме, а не тогда, когда результат кажется слишком большим для этого кандидата. 3. Выдели риски и пробелы (требования вакансии без подтверждения, несоответствие уровня, устаревшие навыки) — тоже со ссылкой на конкретный факт из резюме. 4. Не рекомендуй и не отклоняй кандидата. Вместо вывода дай одну гипотезу для проверки: что именно нужно подтвердить или опровергнуть на скрининге, чтобы решение принял рекрутер. Формат вывода: подзаголовки «Соответствие», «Сильные стороны», «Риски», «Гипотеза для проверки». Максимум 250 слов. Ограничения: не оценивай кандидата по признакам, которых нет в требованиях вакансии: возраст, пол, фото, название вуза, гражданство, семейное положение, отношение к воинской службе, миграционный статус или статус беженца, перерывы в работе. Не выдумывай факты, которых нет в резюме (работодателей, даты, должности, навыки). Если информации не хватает для вывода — прямо напиши, чего именно не хватает, вместо того чтобы додумывать. Каждое допущение отметь отдельно словом «допущение:».
Мы прогнали промпт через Claude, ChatGPT и Gemini на синтетическом резюме, где была одна невинная фраза: «оптимизировал производительность системы в 10 раз». Без метрики. Без базы сравнения. Без способа проверить.
Почему так выходит — и будет выходить дальше, с любой следующей версией моделей. Система не проверяет факты: она продолжает текст. «Оптимизировал в 10 раз» написано в той же грамматической форме, что и «сократил время ответа с 2,4 с до 180 мс» — оба выглядят как описание выполненного действия. Разница между ними не языковая, а фактическая: во втором есть база сравнения, в первом нет. Языковая модель работает с формой, поэтому уравнивает их. Отсюда правило, которое работает всегда: цифра без базы сравнения — не доказательство, а утверждение, которое нужно проверить голосом.
Чтобы не верить на слово даже себе, мы взяли другое синтетическое резюме — с фразой «сократил количество инцидентов втрое», тоже без единого числа до и после, — и прогнали тот же промпт дважды: со строкой об утверждениях об изменении и без неё.
Claude (Opus 5), 18 августа 2026. Резюме новое, в этом уроке больше нигде не упоминается — чтобы система не могла подсмотреть ответ в самом задании. Абсолютные числа из того же резюме («~800 запросов/мин», «240 автотестов») оба прогона засчитали как доказательства: правило касается именно изменения, а не любой цифры.
Теперь посмотри на справку, которую только что получил по своему кандидату. Там тоже есть уверенные формулировки. Вопрос уже не в том, сработал ли промпт — он сработал. Вопрос в том, какие из этих утверждений ты можешь проверить, а какие просто хорошо звучат.
Разбор одного кандидата — это половина работы. Вторая начинается, когда на вакансию пришло пять откликов и нужно решить, кого зовёшь. Ниже — второй промпт урока: на входе вакансия и несколько резюме, на выходе одна таблица, где каждая оценка подкреплена цитатой из резюме.
Одно «но», и оно не про паранойю. В файле резюме приедет всё: ФИО, телефон, почта, иногда фото и дата рождения. Это персональные данные другого человека — и отвечает за них не сервис, а тот, кто их собрал: ты, твоё агентство или клиент.
Выключенное обучение эту ответственность не снимает. Оно закрывает одно: твои чаты не пойдут в тренировку модели. Но сам факт передачи резюме стороннему сервису оно не узаконивает — для этого нужен договор об обработке данных, а потребительские тарифы (Free, Pro «для одного человека») его не дают. Поэтому порядок такой:
Что не загружай в чат вообще: медицинские справки и всё о состоянии здоровья, отношение к воинской службе и отсрочки, миграционный статус или статус беженца, сканы паспорта, ИИН/ИНН и другие номера документов. Для оценки под вакансию это не нужно, а защита для таких данных нужна более строгая.
Роль: ты — ассистент-рекрутер, который готовит сравнительную таблицу кандидатов под одну
вакансию для рекрутера. Решение о найме принимает человек, не ты.
Контекст:
Вакансия: [вставить полный текст вакансии].
Кандидаты: [вставить 3–7 резюме подряд, каждое начать строкой «=== Кандидат-001 ===»
— или прикрепить файлы резюме к этому сообщению. ФИО и контакты убери
до вставки или до загрузки файла: в промпте это уже не сработает, данные
передаются вместе с файлом].
Если в резюме всё равно остались ФИО, контакты, фото, возраст или пол — не
используй их в сравнении и не упоминай в ответе. О кандидатах в своих
колонках пиши без родовых форм: «в резюме…», «на скрининге уточнить…»,
«кандидат(ка) назовёт…».
Задача: построй одну сравнительную таблицу кандидатов по требованиям этой вакансии.
Критерии успеха ответа:
1. Одна строка — один кандидат. Колонки — ключевые требования вакансии плюс колонки
«Риски и вопросы на скрининг» и «Гипотеза для проверки»: что именно нужно
подтвердить или опровергнуть на скрининге.
Одно требование — одна колонка. Не объединяй несколько требований в одно («Git + CI/CD»):
так не видно, какое из них закрыто. Если требований больше восьми — возьми восемь
самых важных, а остальные перечисли строкой под таблицей. Объединять, чтобы
влезть в лимит, нельзя: лучше меньше колонок, чем склеенные.
2. Проверяй требования в том порядке, в котором они перечислены в вакансии, и не
меняй этот порядок от кандидата к кандидату.
3. Формат каждой ячейки требования — оценка, вертикальная черта, дословная цитата
из резюме в кавычках; при необходимости — третьим элементом пометка (см. ниже):
оценка | «дословная цитата из резюме в кавычках» | пометка
Если цитаты нет, различай два случая и пиши по-разному:
«нет цитаты — резюме об этом молчит» — это «нет данных»;
для «нет» цитата обязательна: приведи именно тот признак, из-за которого требование не
закрыто («нет | «стек .NET 8, ASP.NET Core»»). «Нет» без цитаты невозможно —
если процитировать нечего, это «нет данных», а не «нет».
Пересказ своими словами («подтверждено опытом», «есть в навыках») не
принимается: это не цитата.
Пометка — это короткая приписка, на чём держится оценка или почему она не
выше: «из списка навыков» (слово в перечне выглядит как доказательство, но им не является),
«требует проверки» (для утверждений об изменении без значений до и после),
«вклад кандидата не виден» (результат описан без самого кандидата как
исполнителя), «косвенное» (требование не названо, но без него не существует то, что
названо), «самодекларация» (уровень языка, заявленный самим кандидатом). Если
добавить нечего — оставляй два элемента.
4. Сначала определи тип требования, затем примени шкалу этого типа. Шкала одинакова
для всех кандидатов. Тип отметь в заголовке колонки: «Английский от B1
(формальное)».
Формальное требование закрывается самим фактом и не требует описания действия: годы
опыта, уровень должности, диплом, локация, уровень языка.
Содержательное требование — об умении: стек, инструмент, практика, тип задач.
Для формального требования:
да — факт в резюме есть и сходится с датами;
нет — факт есть и не дотягивает до требования;
нет данных — факта в резюме нет.
«Частично» для формального требования не используй: четыре года при требовании
трёх — это «да». Уровень языка кандидат декларирует сам; это тоже «да», а
пометка «самодекларация» ставится третьим элементом. Уровень, названный
не по шкале CEFR («intermediate», «свободно»), или с оговоркой
(«говорю хуже») — так же «да | самодекларация»; проверка языка
на скрининге одинакова для всех, у кого стоит эта пометка.
Для содержательного требования:
да — описано действие кандидата: выполненная задача, полученный результат или
измеримая метрика, и цитата называет предмет именно этого требования — этот
инструмент, эту базу, эту практику. «Улучшил работу с базой» без названия БД
не доказывает PostgreSQL. Цитата, которую ты в другой колонке или пометке признал
требующей проверки, не может быть доказательством «да» — для неё
максимум «частично | требует проверки»;
частично — только перечень навыков, пет-проект или косвенное подтверждение.
Косвенное подтверждение — это упоминание инструмента или практики, которые без этого
требования не существуют: Helm не бывает без Kubernetes, GitHub Actions — без Git.
Такое — «частично» с пометкой «косвенное». Смежная технология той же
категории, которую вакансия не называет (MariaDB, когда в требовании только
PostgreSQL), — тоже «частично»;
нет — в резюме есть признак, что требование не закрыто: прямо написано «не работал»
или другой стек без единого упоминания языка или области требования. Если кандидат
упоминает этот язык в пет-проектах или обучении — это «частично» или «нет
данных», а не «нет»;
нет данных — резюме об этом просто молчит. Молчание — это «нет данных»,
а не «нет»: разница между «не умеет» и «не написал» решается на скрининге.
Годы работы и название должности содержательное требование не закрывают: стаж на Python
не означает, что человек писал веб-сервисы. Для содержательного требования это
максимум «частично».
5. После таблицы — отдельный блок «Чего не видно из резюме»: что именно придётся
выяснить голосом по каждому кандидату.
6. После таблицы — список вопросов, которые закроют пробелы. Порядок вопросов —
по порядку требований в вакансии, не по кандидатам: иначе список
превращается в рейтинг слабости резюме.
Формат вывода: одна таблица, под ней два блока. Без вступления и итоговых
похвал.
Ограничения:
— Не ранжируй кандидатов и не рекомендуй, кого звать. Твоя задача — разложить
доказательства и пробелы по одинаковым критериям; сравнивает и решает рекрутер.
— Цитаты приводи на языке оригинала резюме, не переводи: переведённую цитату
невозможно найти поиском в самом резюме.
— Не выдумывай фактов, которых нет в резюме: технологий, дат, должностей, компаний.
— Не выравнивай кандидатов между собой. Если резюме пустое по требованию — так и
напиши, даже если все остальные ячейки заполнены.
— Не сравнивай по признакам, которых нет в требованиях вакансии: возраст, пол, фото,
название вуза, гражданство, семейное положение, внешность, отношение к воинской службе,
миграционный статус или статус беженца. Перерыв в работе не называй риском: за ним
может стоять декрет, уход за близкими, болезнь, переезд, военная служба, сокращение —
а не качество специалиста.
— Утверждение об изменении — «во столько-то раз», «на столько-то процентов»,
«значительно», «существенно» — без значений до и после не засчитывай как доказательство: отметь
его как требующее проверки. Абсолютные числа («~600 сценариев»)
под это правило не подпадают.
— Пометку «вклад кандидата не виден» и вопрос об авторстве ставь только там,
где текст резюме не называет исполнителем самого кандидата: «мы», «команда»,
«нам удалось», «we», «our team» — или результат без действующего лица
(«снижено с … до …», «было внедрено»). Цифры могут быть правдивы, а
роль человека в них — нет; это вопрос на скрининг, а не оценка. Если кандидат
пишет о себе в единственном числе — «сделал», «настроила», «построил» — авторство
под сомнение не ставь. И наоборот: если основание есть, поставь пометку всем, у
кого оно есть. Вопрос об авторстве не может достаться одному кандидату и
обойти другого с такой же формулировкой. Это касается и колонки
«Гипотеза для проверки»: гипотеза об авторстве ставится только по
текстовому основанию, а не потому, что результат выглядит слишком большим для этого
кандидата.
— Если резюме нечитаемо или данных не хватает — напиши это прямо, вместо того
чтобы додумывать.
Вот что вернул этот промпт на пяти синтетических резюме под вакансию Middle Python Developer. Это фрагмент: в полной таблице восемь колонок требований — стаж, Django/FastAPI, БД, индексы, Git, CI/CD, Docker, английский — плюс риски и гипотеза. Здесь показаны две колонки, на которых лучше всего видна разница между фактом и словами.
| Кандидат | Django / FastAPI | Индексы и оптимизация запросов | Гипотеза для проверки |
|---|---|---|---|
| Кандидат-009 | да | «Сервис поиска и фильтрации товаров на FastAPI: вынесла его из монолита» | да | «Разбирала медленные запросы к PostgreSQL через EXPLAIN ANALYZE» | Подтвердить или опровергнуть: индекс и устранение N+1 на странице каталога, а также рост покрытия тестами — работа самого кандидата(ки), а Docker используется в ежедневной работе, а не только назван в навыках |
| Кандидат-002 | частично | «Python, Django, Flask» | из списка навыков | нет данных | нет цитаты — резюме об этом молчит | Подтвердить или опровергнуть: на обоих местах работы бэкенд писался именно на Django (а не на Flask), с конкретной реляционной БД, и кандидат(ка) назовёт пример оптимизированного запроса или индекса |
| Кандидат-007 | да | «Разработка и поддержка сервисов на Django и FastAPI» | частично | «Оптимизировал производительность системы в 10 раз за счёт переработки запросов к базе данных» | требует проверки | Подтвердить или опровергнуть: на текущей позиции кандидат(ка) работает с PostgreSQL или MySQL и назовёт конкретные значения до и после оптимизации запросов и что именно изменено (индексы, переписанные запросы) |
| Кандидат-010 | частично | «Django — на уровне пет-проекта» | нет данных | нет цитаты — резюме об этом молчит | Подтвердить или опровергнуть: кандидат(ка) писал(а) запросы именно к PostgreSQL и понимает индексы и планы запросов в транзакционной БД, а знания Django достаточно для коммерческого веб-сервиса |
| Кандидат-003 | нет данных | нет цитаты — резюме об этом молчит | нет данных | нет цитаты — резюме об этом молчит | Подтвердить или опровергнуть: Python-пет-проекты кандидата(ки) включают веб-сервис на Django или FastAPI с реляционной БД, а работа с PostgreSQL в платёжном оркестраторе включала оптимизацию запросов лично |
Вакансия и все пять резюме, на которых сделан этот прогон, лежат отдельной страницей — с кнопками копирования: материалы прогона. Все имена, компании и даты вымышлены: это синтетический пакет для обучения, живых людей в нём нет.
Промпт у тебя есть, данные тоже — на странице материалов. Прогони промпт 2 на пятерых кандидатах в своей системе и проверь не ответ, а три конкретных места. Это и есть навык урока: не «получить таблицу», а знать, где она слабая.
Промпт закрывает половину задачи. Вторая половина — процедура проверки того, что система вернула. Её мы и собираем дальше:
Промпты уже твои, возвращаться за ними не нужно. А когда выйдет следующий модуль курса — напишем тебе. Без рассылки каждую неделю.