Договорись с ИИ. Часть 2 Реальные проекты, профессиональные практики и продвинутые возможности Claude Code

например "/remind Позвонить маме через 2 часа"

3. В указанное время бот присылает пользователю сообщение

с текстом напоминания

4. Команда /list — показать все активные напоминания

пользователя

5. Возможность удалить напоминание из списка

Токен бота: [вставьте сюда ваш токен]

Claude Code самостоятельно выберет подходящий технический подход для реализации бота (обычно используется готовая библиотека для работы с Telegram API, о котором мы говорили в первой книге, глава 16) и создаст структуру проекта.

СОВЕТ: Если не хотите вставлять токен прямо в текст сообщения (например, если сессия синхронизируется в облаке или её видит кто-то ещё), попросите: «Создай файл для хранения токена отдельно от основного кода, а токен я впишу туда сам» — это относится к теме переменных окружения, о которой шла речь в главе 3, и мы вернёмся к ней подробнее в главе 21.

Шаг 3. Запускаем бота локально и тестируем

После создания кода Claude Code, скорее всего, предложит запустить бота прямо на вашем компьютере командой вроде:

python bot.py

Пока эта команда выполняется (и терминал остаётся «занятым» — то есть строка ввода не появляется снова, потому что программа продолжает работать и ждать сообщений), откройте Telegram, найдите своего бота по имени пользователя и отправьте /start.

РАЗБОР КЕЙСА. Частый первый опыт новичка с ботом: команда запущена, но бот не отвечает. Прежде чем паниковать, проверьте простое: не закрылось ли случайно окно терминала (тогда программа бота остановилась), и действительно ли вы написали боту в правильном чате. Если проблема не в этом — самое время вернуться к главе 12 первой книги: скопируйте всё, что terminal вывел после отправки сообщения боту, и покажите Claude Code.

Шаг 4. Логика напоминаний — что происходит «под капотом»

Полезно понимать общий принцип, даже не вникая в детали кода: бот должен где-то хранить список всех активных напоминаний (обычно — в небольшой базе данных, о которой мы подробнее поговорим в главе 19) и постоянно, в фоновом режиме, проверять, не наступило ли время для отправки одного из них. Это отличается от привычной для веб-страниц модели «запрос — ответ»: бот должен «жить» непрерывно, даже когда никто с ним не общается в данный момент, чтобы вовремя напомнить о том, что было запланировано заранее.

Шаг 5. От локального запуска — к боту, который работает всегда

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

Чтобы бот работал постоянно, его нужно разместить (задеплоить, вспоминая термин из главы 3) на сервере, который всегда включён. Подробно процесс размещения проектов в интернете мы разберём в главе 9 — принципы, изложенные там, применимы и к ботам, и к обычным сайтам.

Расширяем функциональность бота

После того как базовая версия работает, можно постепенно добавлять более сложные сценарии:

Добавь возможность создавать повторяющиеся напоминания —

например, "каждый день в 9 утра" или "каждый понедельник"

Добавь inline-кнопки под сообщением с напоминанием:

"Отложить на час" и "Отметить выполненным"

Обратите внимание, что второй запрос вводит понятие, специфичное именно для интерфейса ботов, — кнопки, встроенные прямо в сообщение (в отличие от обычных кнопок на веб-странице). Если формулировка непонятна — как всегда, можно и нужно спросить: «Что такое inline-кнопки в Telegram и как они выглядят для пользователя?»

Небольшое резюме главы

• Бот в мессенджере работает принципиально иначе, чем сайт: общение происходит через сообщения, а не через клики на странице.

• Перед созданием бота его нужно зарегистрировать через @BotFather и получить секретный токен доступа.

• Токен бота — это пароль, который нельзя публиковать в открытом доступе.

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

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

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

Глава 6. Личный кабинет с авторизацией и базой данных

Зачем нужен личный кабинет

Многие проекты, в отличие от простого сайта-визитки, подразумевают, что у каждого пользователя есть своя, персональная область — история заказов в интернет-магазине, личные напоминания в боте, заявки клиента в системе учёта. Это требует двух вещей, которые мы пока рассматривали только теоретически (в главе 3 и в первой книге): базы данных для хранения информации разных пользователей и системы авторизации, чтобы каждый видел только своё.

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

Шаг 1. Формулируем задачу с учётом ролей

Хочу сделать систему учёта для мастерской по ремонту техники.

Нужны две роли:

1. Администратор — видит всех клиентов, все заявки, может

создавать и редактировать записи

2. Мастер — видит только заявки, назначенные лично ему,

может менять статус заявки (в работе / готово)

Начни с регистрации и входа: страница логина с email и

паролем, после входа — перенаправление в зависимости от роли

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

Шаг 2. Как устроена регистрация и вход технически

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

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

Шаг 3. Структура данных

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

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

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

и у заявки на ремонт

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

Таблица "Пользователи": id, имя, email, пароль (хеш), роль

Таблица "Клиенты": id, имя, телефон, дата первого обращения

Таблица "Заявки": id, клиент_id, мастер_id, описание проблемы,

статус, дата создания, дата завершения

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

Шаг 4. Реализация авторизации

Реализуй регистрацию и вход по описанной структуре. После

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

приходилось вводить пароль заново при каждом переходе между

страницами. Добавь также кнопку "Выйти"

Шаг 5. Разграничение доступа

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

Убедись, что страница со списком всех заявок доступна только

администратору. Мастер при попытке напрямую открыть эту

страницу должен видеть сообщение "Доступ запрещён" и

перенаправляться на свою страницу с назначенными ему заявками

ВНИМАНИЕ: Разграничение доступа — одна из тех областей, где стоит проявлять особую тщательность при проверке (вспоминая материал главы 18 первой книги о том, чему стоит доверять безоговорочно, а что перепроверять). Обязательно протестируйте сценарий «что если мастер попробует напрямую открыть адрес страницы администратора, введя его в браузере вручную» — а не только «не видна ли ссылка на эту страницу в интерфейсе». Скрытая, но фактически доступная страница — распространённая и серьёзная уязвимость.

Шаг 6. Восстановление пароля и другие практические мелочи

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

Добавь функцию "Забыли пароль?" — отправку ссылки для

сброса пароля на email пользователя

Добавь ограничение: после 5 неудачных попыток входа подряд

временно блокировать возможность входа для этого email на

15 минут, чтобы защититься от подбора пароля

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

Небольшое резюме главы

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

• Пароли должны храниться в захешированном, а не открытом виде — это стандартная и обязательная практика.

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

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

• Полноценная система авторизации включает такие практические детали, как восстановление пароля и защиту от подбора пароля.

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

Глава 7. Автоматизация для небольшого бизнеса: кейс от заявки до отчёта

От разрозненных задач — к цельному процессу

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

Сценарий: от заявки клиента до ежемесячного отчёта

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

Шаг 1. Автоматическое распределение заявок

Когда поступает новая заявка без указанного мастера,

автоматически назначай её тому мастеру, у которого сейчас

меньше всего активных (незавершённых) заявок. Если у

нескольких мастеров одинаковое количество — выбирай того,

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

Обратите внимание, насколько эта задача отличается от простого CRUD-интерфейса (создание, чтение, обновление, удаление записей), которым мы занимались в предыдущей главе, — здесь появляется настоящая бизнес-логика, отражающая реальное правило распределения нагрузки в мастерской. Именно такие правила стоит формулировать предельно точно, поскольку неоднозначность здесь напрямую ведёт к неправильному, но незаметному на первый взгляд поведению системы.

Шаг 2. Уведомления на ключевых этапах

Добавь уведомления:

1. Когда заявка назначена мастеру — отправить email мастеру

с описанием заявки

2. Когда мастер отмечает заявку выполненной — отправить email

клиенту с уведомлением, что ремонт завершён

3. Если заявка находится в статусе "в работе" дольше 3 дней

без изменений — отправить email администратору с

напоминанием проверить эту заявку

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

Шаг 3. Автоматическое формирование отчёта

Добавь автоматическое формирование ежемесячного отчёта в

формате Excel: первого числа каждого месяца собирать все

заявки за прошедший месяц со статусами, суммами и мастерами,

и отправлять готовый файл на email администратора

РАЗБОР КЕЙСА. При реализации подобной задачи полезно сразу же попросить возможность запустить формирование отчёта вручную, не дожидаясь начала следующего месяца: «Добавь также кнопку в административной панели “Сформировать отчёт за текущий период сейчас”, чтобы я мог проверить, что всё работает правильно, не дожидаясь календарной даты». Это общий, крайне полезный приём при работе с любой логикой, привязанной к дате или времени, — тестирование по «настоящему» календарю занимает недели, тестирование по требованию — секунды.

Шаг 4. Взгляд на процесс целиком

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

Опиши весь процесс от момента поступления новой заявки до

момента, когда информация о ней попадает в месячный отчёт —

по шагам, включая все автоматические уведомления

Такой запрос выполняет ту же функцию, что и просьба «объяснить, что было сделано» из первой книги (глава 11), но применительно уже не к отдельному изменению, а ко всему выстроенному процессу целиком — это хороший способ убедиться, что общая картина в голове совпадает с тем, что реально реализовано.

Пределы автоматизации: когда стоит остановиться

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

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

Небольшое резюме главы

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

• Бизнес-правила (например, порядок распределения заявок) стоит формулировать предельно точно, поскольку неоднозначность приводит к незаметным, но реальным ошибкам поведения.

• Для логики, привязанной к дате или времени, полезно сразу предусмотреть возможность запуска вручную для тестирования.

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

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

Часть 3. Профессиональные практики

Глава 8. Тестирование: как убедиться, что всё работает, не проверяя вручную

Проблема ручной проверки

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