Kitobni o'qish: «Электронная книга «ИИ-разработка без программиста»»

Предисловие и содержание

ИИ-разработка без программиста

Как создавать сайты, лендинги и цифровые системы с помощью ChatGPT, Claude и других ИИ-инструментов

Содержание

Введение

1. Как превратить идею в продукт

2. Домен и VPS: покупаем адрес и готовим площадку

3. PowerShell и SSH: первый безопасный вход на сервер

4. ChatGPT и Remote Desktop Commander: разрешённый доступ к серверу

5. GitHub и ChatGPT: сохраняем код, а не переписки

6. Первый деплой: Nginx, HTTPS и проверка результата

7. Как определить MVP и не строить лишнего

8. Как заставить ИИ правильно понять задачу

9. Создание технического задания

10. Архитектура будущего проекта

11. Проектирование интерфейсов

12. База данных, пользователи и роли

13. Что такое frontend и backend

14. Как читать код, не зная языка программирования

15. Как давать ИИ задачу на изменение проекта

16. Почему нельзя просить «просто всё исправить»

17. Работа небольшими изменениями

18. Поиск ошибок

19. Логи: как понять, что произошло

20. Code review при помощи ИИ

21. Зачем нужен Git

22. Репозиторий проекта

23. Ветки

24. Commit

25. Pull Request

26. Merge

27. Почему нельзя экспериментировать сразу в main

28. Как откатить неудачное изменение

29. Лендинг с нуля

30. Структура страницы, которая приводит к действию

31. Генерация текстов и офферов

32. Адаптивная версия

33. Формы, заявки и интеграции

34. SEO при помощи ИИ

35. Аналитика и события

36. Публикация сайта

37. Личный кабинет

38. Регистрация и авторизация

39. Административная панель

40. Пользователи и права доступа

41. Работа с файлами

42. Уведомления

43. Поиск и фильтрация

44. Отчёты и аналитика

45. Платежи и подписки

46. Интеграции через API

47. Почему «страница открывается» ещё ничего не значит

48. Автоматические тесты

49. Проверка интерфейса

50. Проверка API

51. Проверка авторизации

52. Тестирование платежей

53. Регрессионные ошибки

54. Чек-лист перед публикацией

55. Что такое сервер

56. Домен и DNS

57. HTTPS

58. Docker

59. Nginx

60. Переменные окружения и секреты

61. Как происходит deployment

62. Логи production

63. Резервные копии

64. Мониторинг

65. ИИ-продуктолог

66. ИИ-аналитик

67. ИИ-дизайнер

68. ИИ-разработчик

69. ИИ-тестировщик

70. ИИ-DevOps

71. ИИ-код-ревьюер

72. Как разделять задачи между моделями

73. Лендинг услуги

74. Интернет-магазин

75. CRM для отдела продаж

76. SaaS-сервис

77. Система аналитики

78. AI-сервис на базе API

79. Внутренняя корпоративная система

80. Проект с личным кабинетом и оплатой

81. ИИ придумал существование функции

82. ИИ переписал слишком много кода

83. После исправления сломалось другое

84. Данные удалились

85. Секретный ключ попал в код

86. Тестов нет, но «всё работает»

87. Разработка превратилась в хаос

88. Когда всё-таки нужен профессиональный разработчик

89. Как поддерживать roadmap в актуальном состоянии

90. Backlog

91. Приоритеты

92. Статусы задач

93. Definition of Done

94. Как выпускать изменения регулярно

95. Как развивать продукт месяцами вместе с ИИ

96. Заключение. От идеи к работающему продукту

Справочник терминов

Введение

Введение

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

От чужой очереди — к своим решениям

От чужой очереди — к своим решениям

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

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

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

Введение. Практические шаги

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

Поэтому начнём с плана, а не с хаотичных действий. В первой главе мы создадим дорожную карту проекта в Google Таблицах и зафиксируем последовательность работ — от покупки домена и настройки VPS до подключения GitHub к ChatGPT, настройки Remote Desktop Commander и публикации сайта. Затем, в главах 2–6, пройдём этот маршрут по шагам: зарегистрируем домен, подготовим сервер, настроим безопасный доступ, подключим рабочие инструменты и опубликуем первую страницу с HTTPS. Каждую операцию можно проверить самостоятельно.

Как пользоваться практическими главами. Не нужно заучивать команды из книги. Они помогают понять, что происходит. На каждом этапе можно спрашивать ChatGPT или Claude: «Что мне сделать сейчас, почему именно так и как проверить результат?». Главное — понимать цель и безопасность действий, а не помнить синтаксис PowerShell, SSH или Git наизусть.

Это учебный проект, а не рекомендация вслепую повторять команды на действующем бизнес-сервере. Примеры доменов, IP-адресов и названий учётных записей условные. Не передавайте ИИ пароли, токены или приватные ключи и не выполняйте потенциально разрушительные команды без резервной копии и понимания их последствий.

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

Глава 1. Как превратить идею в продукт

Сначала — дорожная карта проекта в Google Таблицах

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

На первых этапах нам нужен MVP (Minimum Viable Product, минимально жизнеспособный продукт) — самая простая версия, которая уже решает главную задачу пользователя и позволяет проверить, нужна ли она людям. MVP не означает плохое качество или отсутствие защиты данных. Он означает, что в первую версию входит только необходимое: например, для сервиса записи клиентов — форма, сохранение заявки и уведомление, но пока не система бонусов, сложная аналитика и мобильное приложение.

Цель этой главы: создать в Google Таблицах roadmap реальной идеи, выделить обязательные задачи MVP и затем двигаться по нему вместе с ChatGPT или Claude — по одной проверяемой задаче за раз.

Шаг 1. Подключаем Google Таблицы к ChatGPT

В ChatGPT откройте Настройки → Плагины (или Apps) и найдите Google Drive. Пройдите подключение Google-аккаунта и внимательно проверьте запрашиваемые разрешения. Доступ к таблицам предоставляется через подключённый Google Drive; отдельное приложение Google Sheets для работы из самого чата может не требоваться. Возможность создавать или изменять таблицы зависит от тарифа, настроек рабочей области и выданных разрешений.

Другой вариант — открыть Google Таблицы и установить ChatGPT for Google Sheets через Google Workspace Marketplace, затем запустить его из меню расширений. Это отдельный способ работать с ИИ непосредственно внутри таблицы.

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

Подсказка ИИ: «Помоги подключить мой Google Drive к ChatGPT, чтобы мы могли создать roadmap в Google Таблицах. Я начинающий пользователь. Проведи по одному шагу через настройки, объясняй, какие разрешения нужны, и в конце проверь реальную возможность создать файл. Не утверждай, что таблица создана, пока не получишь ссылку на неё».

Шаг 2. Даём ChatGPT конкретное техническое задание

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

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

Идея: [опишите проект своими словами]. Для кого: [основные пользователи]. Главная проблема: [что не работает без продукта]. Ограничения: [бюджет, срок, доступные сервисы].

Сначала задай до семи уточняющих вопросов, без которых нельзя составить рабочий план. После моих ответов создай в моём Google Drive новую Google Таблицу «Roadmap — [название проекта]». Если создание недоступно, сообщи это и подготовь аналогичную таблицу для ручного переноса; не выдумывай ссылку.

Сделай лист «Задачи». Колонки: ID (например, PRJ-001), Этап, Задача, Короткое описание, Ожидаемый результат, Для MVP (Да/Нет), Приоритет (P0/P1/P2), Статус, Зависит от ID, Ответственный, Оценка трудоёмкости, Плановая дата, Фактическая дата, Проверка готовности, Ссылка на результат, Комментарий, Выполнено (чекбокс).

Статусы для выпадающего списка: Не начато → В работе → На проверке → Готово, а также Заблокировано. Приоритет P0 — критично для MVP, P1 — важно после запуска, P2 — дополнительные улучшения. Сделай фильтры, закрепи строку заголовков, выдели статусы цветом. Добавь чекбоксы выполнения. Если формула или выпадающий список не поддерживаются доступным действием, объясни, как настроить их вручную.

Добавь лист «MVP», который показывает только обязательные задачи первой версии, и лист «Прогресс» с количеством задач, числом выполненных, числом заблокированных и долей готовности MVP. Добавь лист «Риски и решения»: ID, риск или вопрос, влияние, принятое решение, дата, ссылка на задачу.

Разбей проект на этапы: проверка идеи → структура MVP → прототип → домен и инфраструктура → разработка → тестирование → публикация → первые отзывы. Сформируй 20–35 конкретных задач, укажи зависимости по ID и логическую последовательность, не ставь выдуманные даты и трудозатраты. В MVP включи только действительно необходимые задачи.

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

Возможно, ChatGPT сначала попросит подтвердить действие с Google Drive. Подтверждайте только создание нужной таблицы. Факт успешного создания — реальная ссылка на файл, который открывается в вашем аккаунте, а не текст «Готово!».

Шаг 3. Читаем roadmap без технического образования

Откройте вкладку «Задачи». Например, проект — небольшой сайт для приёма заявок.

ID | Задача | MVP | Приоритет | Статус

ID: PRJ-001; Задача: Описать клиента и главную проблему; MVP: Да; Приоритет: P0; Статус: Не начато

ID: PRJ-002; Задача: Утвердить структуру первой страницы; MVP: Да; Приоритет: P0; Статус: Не начато

ID: PRJ-003; Задача: Подобрать и зарегистрировать домен; MVP: Да; Приоритет: P0; Статус: Не начато

ID: PRJ-004; Задача: Создать форму заявки и проверить отправку; MVP: Да; Приоритет: P0; Статус: Не начато

ID: PRJ-005; Задача: Подключить HTTPS и опубликовать сайт; MVP: Да; Приоритет: P0; Статус: Не начато

ID: PRJ-006; Задача: Добавить расширенную аналитику; MVP: Нет; Приоритет: P1; Статус: Не начато

ID — уникальный номер задачи; его не меняют при сортировке. Зависимость — номер задачи, без завершения которой нельзя приступать к следующей. Статус показывает, что происходит сейчас; чекбокс подтверждает завершение. Наличие красивого списка не означает, что сайт построен: отметка «Готово» появляется только после проверки результата.

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

Шаг 4. Двигаемся по задачам вместе с ChatGPT

Каждое рабочее занятие можно начинать так:

Открой roadmap проекта в Google Таблицах. Покажи первую задачу со статусом «Не начато», у которой завершены зависимости и которая имеет приоритет P0. Объясни человеческим языком, что нужно сделать. Составь короткий план, дай команды по одной и предложи проверку результата. Не меняй статус на «Готово» без моего подтверждения. После проверки обнови именно эту строку по ID, сохрани ссылку на подтверждение результата и предложи следующую задачу.

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

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

Как понять, что план действительно помогает

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

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

Актуальные инструкции: подключение Google Drive к ChatGPT, ChatGPT в Google Таблицах, чекбоксы, выпадающие списки.

После выбора ИИ-инструментов хочется сразу открыть редактор и написать: «Создай современный SaaS (программа как онлайн-услуга) для автоматизации продаж». Через несколько минут модель действительно предложит страницы, базу данных и красивую кнопку «Начать бесплатно».

Проблема в том, что набор страниц и функций ещё не является продуктом.

Идея — это общее представление о возможном решении: «сервис для контроля заявок», «лендинг для юридической компании», «личный кабинет для клиентов».

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

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

Начинайте не с функции, а с проблемы

Слабая формулировка идеи обычно начинается с технологии:

Хочу CRM с искусственным интеллектом.

Из неё непонятно:

• кто будет пользоваться системой;

• что сейчас происходит без неё;

• какая именно проблема требует решения;

• почему существующие инструменты не подходят;

• какой результат должен измениться.

Более полезная формулировка выглядит так:

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

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

Попробуйте заполнить конструкцию:

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

Например:

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

Это ещё не техническое задание. Но это уже надёжная основа для него.

Определите пользователя точнее

Фраза «наш продукт нужен бизнесу» почти ничего не объясняет. Бизнес — не человек: он не нажимает кнопки и не забывает пароль. Это делают конкретные пользователи.

В одной системе могут участвовать несколько ролей:

• клиент создаёт заявку;

• менеджер обрабатывает её;

• руководитель смотрит показатели;

• администратор управляет пользователями;

• бухгалтер проверяет оплату.

У каждой роли своя цель. Если собрать их в абстрактного «пользователя», требования начнут конфликтовать.

Возьмём CRM (система работы с клиентами и сделками). Менеджеру важно быстро увидеть новые обращения и связаться с клиентом. Руководителю — понять, сколько заявок теряется на каждом этапе. Администратору — выдавать права и блокировать уволенных сотрудников. Клиенту вообще не нужна CRM: ему нужен быстрый ответ.

Полезно составить простую таблицу:

Роль | Чего хочет | Что мешает сейчас | Что должно измениться

Роль: Менеджер; Чего хочет: Не пропускать новые заявки; Что мешает сейчас: Обращения приходят из разных каналов; Что должно измениться: Все новые заявки видны в одной очереди

Роль: Руководитель; Чего хочет: Контролировать работу отдела; Что мешает сейчас: Отчёты собираются вручную; Что должно измениться: Доступна актуальная сводка

Роль: Администратор; Чего хочет: Управлять доступом; Что мешает сейчас: Общие пароли и ручные настройки; Что должно измениться: У каждого сотрудника своя учётная запись

Такая таблица полезнее раннего обсуждения цвета кнопок. Хотя кнопка, разумеется, тоже однажды потребует срочного совещания.

Опишите ситуацию до появления продукта

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

Например, агентство получает заявки с лендинга:

1. Посетитель заполняет форму.

2. Заявка приходит на общую почту.

3. Сотрудник копирует данные в таблицу.

4. Руководитель вручную назначает менеджера.

5. Менеджер связывается с клиентом.

6. Результат разговора записывается в комментарий.

7. В конце недели данные переносят в отчёт.

Теперь задайте вопросы:

• На каком шаге возникают задержки?

• Где данные теряются или дублируются?

• Какие действия выполняются вручную?

• Какие ошибки происходят чаще всего?

• Кто принимает решение на каждом этапе?

• Какие исключения встречаются?

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

Автоматизировать непонятный процесс опасно. Компьютер не исправляет беспорядок — он помогает воспроизводить его быстрее и без обеденного перерыва.

Сформулируйте полезный результат

Функция описывает, что умеет система. Результат описывает, что получает человек.

Сравните:

• функция: «добавить фильтр по статусу»;

• результат: «руководитель за минуту находит сделки без активности»;

• функция: «отправлять уведомления»;

• результат: «менеджер узнаёт о новой заявке не позднее чем через минуту»;

• функция: «создать личный кабинет»;

• результат: «клиент самостоятельно видит состояние заказа и не звонит в поддержку».

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

Для каждой важной возможности задавайте четыре вопроса:

1. Кто ею пользуется?

2. В какой ситуации?

3. Какое действие выполняет?

4. Какой результат получает?

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

Превратите идею в пользовательские сценарии

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

Рассмотрим сервис записи на консультацию.

Основной сценарий:

1. Посетитель открывает страницу специалиста.

2. Выбирает доступную дату и время.

3. Указывает имя, телефон и электронную почту.

4. Подтверждает согласие на обработку данных.

5. Система создаёт запись.

6. Клиент получает подтверждение.

7. Специалист видит запись в своём календаре.

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

• выбранное время уже занял другой клиент;

• адрес почты введён с ошибкой;

• сообщение не отправилось;

• клиент повторно нажал кнопку;

• специалист отменил приём;

• пользователь хочет перенести запись;

• внешний календарь временно недоступен.

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

Отделите факты от предположений

На раннем этапе многие решения основаны не на данных, а на догадках:

• «клиенты хотят регистрироваться по номеру телефона»;

• «руководителю нужен ежедневный отчёт»;

• «пользователь будет готов подключить банковскую карту»;

• «менеджеры станут заполнять восемь обязательных полей»;

• «компания заплатит за такую систему 10 000 рублей в месяц».

Предположение — не ошибка. Ошибка — принять его за факт и потратить месяц на реализацию.

Составьте список гипотез:

Предположение | Как проверить | Признак подтверждения

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

Предположение: Менеджеры готовы работать в новой CRM; Как проверить: Показать прототип и пройти рабочий сценарий; Признак подтверждения: Сценарий понятен без постоянных подсказок

Предположение: Компании готовы платить за отчёты; Как проверить: Провести интервью с руководителями; Признак подтверждения: Есть конкретная потребность и бюджет

Для проверки не всегда нужен код. Иногда достаточно макета, таблицы, ручной услуги или простой формы.

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

Определите ценность для бизнеса

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

Ценность может выражаться в том, чтобы:

• получать больше заявок;

• быстрее обрабатывать обращения;

• уменьшать количество ошибок;

• снижать ручные затраты;

• повышать повторные продажи;

• сокращать нагрузку на поддержку;

• обеспечивать прозрачность процессов;

• выполнять обязательные требования законодательства.

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

Для лендинга это могут быть:

• доля посетителей, оставивших заявку;

• стоимость заявки;

• количество целевых обращений.

Для CRM:

• время до первого ответа;

• число необработанных заявок;

• доля сделок с заполненным следующим шагом.

Для SaaS:

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

• количество активных клиентов;

• продление подписки;

• отказы от оплаты.

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

Используйте ИИ как аналитика, а не как источник желаний клиента

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

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

Затем полезно попросить ИИ выступить критиком:

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

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

Составьте краткий паспорт продукта

Перед переходом к функциям соберите идею на одной странице.

Паспорт продукта

• Название или рабочее обозначение:

• Для кого создаётся:

• Какая проблема решается:

• Как проблему решают сейчас:

• Почему текущий способ не подходит:

• Какой результат должен получить пользователь:

• Какая польза возникает для бизнеса:

• Основные роли:

• Главный пользовательский сценарий:

• Критические исключения и ошибки:

• Что мы знаем как факт:

• Какие предположения нужно проверить:

• По какому показателю оценим результат:

• Какие ограничения уже известны: бюджет, сроки, законодательство, интеграции, устройства.

Если паспорт нельзя заполнить без фраз «для всех», «удобнее» и «на базе ИИ», идея пока недостаточно определена.

Практический чек-лист

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

• [ ] Назван конкретный пользователь, а не «весь бизнес».

• [ ] Описана реальная проблема и её последствия.

• [ ] Понятно, как задача решается сейчас.

• [ ] Выделен главный полезный результат.

• [ ] Описан основной сценарий от начала до результата.

• [ ] Учтены типичные ошибки и исключения.

• [ ] Функции не подменяют ценность для пользователя.

• [ ] Факты отделены от предположений.

• [ ] Для рискованных гипотез выбран способ проверки.

• [ ] Определён измеримый показатель результата.

• [ ] Зафиксированы ограничения продукта.

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

Когда эти ответы есть, ИИ способен помочь превратить их в структуру функций, сценарии, архитектуру и код. Когда ответов нет, он тоже что-нибудь построит. Просто это может оказаться аккуратным, современным и совершенно ненужным.

Глава 2. Домен и VPS: покупаем адрес и готовим площадку

Что мы построим

Начнём не с разговора о будущем технологий, а с действий. Через пять глав мы получим собственный домен, Linux-сервер, безопасный доступ, GitHub (платформа хранения кода и истории изменений) и работающий сайт с HTTPS. Для начала достаточно одностраничного сайта услуги: заголовок, описание, контакты. Он достаточно прост, чтобы понимать каждую ошибку, и достаточно реален, чтобы показать его заказчику.

Нужны компьютер с Windows 10/11, браузер, почта, домен, VPS, аккаунт GitHub и доступ к ChatGPT. В примерах site-example.ru — условное доменное имя; 203.0.113.10 — адрес из диапазона для документации. Они не подходят для реального деплоя: подставляйте свои значения.

Ни при каких обстоятельствах не передавайте в чат пароли, приватные SSH (защищённое подключение к серверу)-ключи, токены GitHub и содержимое .env. ИИ может подготовить команду, но ответственность за её выполнение остаётся у владельца системы.

Шаг 1. Регистрируем домен

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

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

Домен можно купить и у другого регистратора, например Timeweb или RU-CENTER. Регистратор управляет регистрацией имени, а сервер выполняет код. Это разные услуги: покупка домена не создаёт сайт.

Результат: в панели регистратора виден действующий домен, вы можете изменять его DNS (система доменных имён)-записи.

Шаг 2. Арендуем виртуальный сервер

У провайдера VPS выберите Ubuntu (операционная система семейства Linux) LTS и минимальный тариф, на котором можно запустить Nginx и статический сайт. Для полноценного приложения с базой данных ресурсов может понадобиться больше. Оцените: процессор, оперативную память, размер диска, стоимость продления, возможность резервных копий и наличие веб-консоли восстановления. Не выбирайте только по самой низкой цене.

После создания VPS запишите в технический журнал (без паролей): IP-адрес, версию Ubuntu, провайдера, дату платежа и ссылку на консоль управления сервером. Первый доступ может предоставляться временным паролем или SSH-ключом.

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

Шаг 3. Настраиваем DNS

Можно спросить ChatGPT или Claude: «Я купил домен и VPS. Помоги связать их: где искать управление DNS, какие A-записи создать и как проверить, что они заработали? Давай по одному шагу и объясняй результат проверки». Не нужно запоминать названия всех DNS-записей — важно понимать, для чего они служат.

Зайдите в раздел управления доменом. На REG.RU обычно используется раздел «DNS-серверы и зона». Сначала проверьте, какие NS-серверы делегированы домену. Если домен обслуживается внешним DNS-провайдером, запись нужно менять именно там.

Создайте две DNS-записи:

Тип | Имя | Значение

Тип: A; Имя: @; Значение: 203.0.113.10

Тип: A; Имя: www; Значение: 203.0.113.10

Замените 203.0.113.10 на собственный IPv4 VPS. @ — корневой домен, www — его поддомен. Не создавайте AAAA-запись для IPv6, пока на сервере действительно не настроен IPv6.

DNS может обновляться не сразу. На время распространения записей не меняйте настройки хаотично: сначала проверьте NS и сохранённое значение.

Результат: DNS-запрос к домену показывает IP выбранного сервера. Сам сайт пока может не открываться — веб-сервер мы установим позже.

Шаг 4. Составляем карту проекта с ChatGPT

Откройте ChatGPT. На этом этапе попросите не выполнять команды, а проверить план:

Я на Windows, приобрёл домен и VPS с Ubuntu. Хочу опубликовать одностраничный сайт. Составь план: DNS → SSH → пользователь с ограниченными правами → GitHub → Nginx → HTTPS → проверка. Для каждого этапа укажи цель, одну-две безопасные диагностические команды, признак успеха и способ отката. Не проси у меня секреты. Не предлагай менять firewall или отключать доступ без резервного канала через консоль провайдера.

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

Частые затруднения

Домен не отвечает: не спешите обвинять VPS. Проверьте статус регистрации, NS и A-записи. DNS показывает IP, но страницы нет: пока Nginx (веб-сервер для выдачи страниц) не установлен, это нормально. Потеряли доступ к серверу: используйте консоль провайдера и штатный механизм восстановления. Не пытайтесь делиться административным паролем ради «быстрой помощи».

Что должно получиться

В рабочем журнале есть три строки: домен, публичный IP, провайдер VPS. Рядом — отметки «домен зарегистрирован», «сервер работает», «A-записи созданы». На этом этапе мы не затрагивали рабочие сервисы и не публиковали секреты.

Проверяемые инструкции по DNS: справка REG.RU. Интерфейсы провайдеров меняются — ориентируйтесь на названия действий, а не на расположение кнопок.

Глава 3. PowerShell и SSH: первый безопасный вход на сервер

Важно: технические команды можно разбирать вместе с ChatGPT или Claude. Далее встретятся DNS, SSH, PowerShell, ключи доступа и команды Ubuntu. Всё это не требуется заучивать: просите ИИ объяснять шаги простыми словами, готовить команды под вашу систему и помогать с настройкой DNS, SSH и учётных записей. Если ChatGPT подключён к серверу через разрешённый инструмент, он может выполнять разрешённые операции после вашего подтверждения. Не передавайте в чат пароли, приватные ключи или токены и не позволяйте менять рабочий сервер без плана и проверки.

Пример запроса для ChatGPT или Claude: «У меня Windows и VPS на Ubuntu, домен куплен у регистратора. Я не программист. Проведи меня шаг за шагом: проверь DNS, покажи, как создать SSH-ключ и отдельного пользователя, подключиться через PowerShell и проверить результат. Сначала объясняй каждую команду и её риски. Не выполняй действия без моего подтверждения, не проси пароли и секретные ключи, предусмотри способ восстановления доступа».

Сначала — проверка DNS с собственного компьютера

Нажмите Win, введите PowerShell (командная оболочка Windows) и откройте приложение. Администраторские права для обычной проверки не нужны. Выполните:

Resolve-DnsName site-example.ru -Type A

Test-NetConnection site-example.ru -Port 22

В первой команде подставьте свой домен. Поле IPAddress должно совпасть с публичным адресом VPS. Вторая команда проверяет доступность SSH-порта с вашего компьютера. TcpTestSucceeded : True означает, что TCP-соединение доступно; это ещё не подтверждает, что пароль или ключ верны.

Если DNS пока возвращает старый адрес, проверьте NS и записи у действующего DNS-провайдера. Если порт 22 закрыт, проверьте правила сетевого экрана провайдера и запущен ли SSH-сервер через веб-консоль VPS.

Что такое SSH — без лишней теории

SSH — зашифрованное удалённое соединение с сервером. PowerShell — терминал вашего Windows-компьютера. Команда ssh, запущенная в PowerShell, открывает интерактивную сессию на Linux. После подключения команды выполняются уже на сервере, а не на ноутбуке. Это главная разница, которую нужно понимать до любых экспериментов.

Проверьте наличие клиента:

ssh -V

Если он не установлен, добавьте компонент OpenSSH Client через дополнительные компоненты Windows или официальные инструкции Microsoft. Скачивать «специальный взломанный SSH-клиент» не нужно.

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

Создаём собственный ключ

На Windows в PowerShell:

ssh-keygen -t ed25519 -C "my-laptop"

Когда появится вопрос о пути, можно выбрать стандартный $env:USERPROFILE\.ssh\id_ed25519, если такого ключа у вас ещё нет. Если файл уже существует, не перезаписывайте его: создайте другой ключ с понятным именем. Установите парольную фразу (passphrase) для приватного ключа.

Два файла играют разные роли:

• id_ed25519 — приватный ключ. Не отправляйте его никому и не копируйте на сервер;

• id_ed25519.pub — публичный ключ. Его можно добавить на сервер.

Посмотреть публичную часть:

Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"

Публичный ключ — длинная строка, которая начинается примерно с ssh-ed25519. Если провайдер позволяет добавить SSH-ключ в панели VPS, вставьте туда только строку из файла .pub.

Создаём отдельного пользователя на Ubuntu

Не обязательно настраивать пользователя по памяти. Напишите ChatGPT или Claude: «Мы создали VPS с Ubuntu и открыли веб-консоль провайдера. Помоги по шагам создать отдельного пользователя, настроить SSH-ключ и проверить его права. Сначала объясни команду, затем подожди моего результата. Не отключай действующий доступ, пока новый не проверен».

Войдите на только что полученную VPS через веб-консоль провайдера или разрешённый начальный доступ. Здесь команды вводятся на Ubuntu:

sudo adduser deployer

sudo usermod -aG sudo deployer

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

Переключитесь на нового пользователя и подготовьте каталог ключей:

sudo -iu deployer

mkdir -p ~/.ssh

chmod 700 ~/.ssh

nano ~/.ssh/authorized_keys

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

chmod 600 ~/.ssh/authorized_keys

exit

Не надо копировать в authorized_keys текст из секретного файла без расширения .pub.

Проверяем подключение с Windows

Подсказка ИИ: команды в книге — примеры, а не материал для заучивания. Спросите: «У меня Windows и Ubuntu VPS. Какую команду написать в PowerShell, чтобы проверить SSH-подключение? Как выглядит успешный ответ, что делать при ошибке?». ChatGPT или Claude могут вести вас по шагам, сверяясь с фактическим выводом терминала.

Не закрывая веб-консоль провайдера, откройте второе окно PowerShell на компьютере:

ssh deployer@203.0.113.10

Подставьте реальный IP вашей VPS. При первом подключении SSH может показать отпечаток сервера. Не соглашайтесь механически: сопоставьте отпечаток с данными провайдера или получите его через доверенную веб-консоль. Появится приглашение Ubuntu. Выполните безопасные команды:

whoami

hostname

pwd

uname -a

В whoami вы должны увидеть deployer. Это подтверждение, что вы подключились не как root и не остались случайно в локальном PowerShell.

Firewall: порядок важнее команды

Попросите ИИ подготовить безопасный план: «У меня VPS Ubuntu с SSH. Помоги проверить действующие правила firewall и разрешить SSH, HTTP и HTTPS. Прежде чем менять настройки, покажи диагностику, объясни риск потери доступа и способ восстановления через консоль провайдера». Не включайте новые правила вслепую.

На VPS прежде чем включать ufw, разрешите SSH. Команды ниже выполняются на сервере, если ufw используется и нет конфликтующих правил другого firewall:

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw status verbose

Если ufw ещё выключен, сначала убедитесь через панель провайдера, что порт 22 открыт и есть аварийный доступ. Только после проверки и понимания текущих правил можно включать sudo ufw enable. На работающем сервере с базами данных, VPN или нестандартным SSH-портом такой шаг требует индивидуального анализа: универсальная команда может отключить вас от сервера.

Не отключайте вход по паролю и не запрещайте root-login до тех пор, пока вход с новым ключом, права sudo и канал восстановления не проверены. Не экспериментируйте с этим на единственной доступной сессии.

Практика с ИИ: пусть сначала диагностирует

Попросите ChatGPT:

Я подключился к учебной VPS по SSH под пользователем deployer. Не изменяй настройки. Предложи пять команд только для чтения, чтобы проверить Ubuntu, наличие SSH, свободное место, сетевые порты и конфигурацию firewall. Объясни, какие признаки означают проблему. Любые изменения предложи отдельно и жди моего одобрения.

Затем сравните предполагаемый и фактический вывод. Для ИИ это отдельная дисциплина: предлагать действия — не то же самое, что выполнять их.

Результат главы

Из PowerShell вы входите в Ubuntu по собственному SSH-ключу, видите имя пользователя deployer, умеете проверить DNS и порт, а также понимаете, где вводится каждая команда. Следующий шаг — подключить к этому серверу ChatGPT через Remote Desktop Commander, чтобы он мог работать с разрешёнными файлами и процессами.

Документация по SSH-ключам: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent . Пароли, содержимое приватных ключей и токенов в печатные примеры не включаются.

Глава 4. ChatGPT и Remote Desktop Commander: разрешённый доступ к серверу

Зачем нужен ещё один инструмент, если PowerShell уже работает

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

Один из таких каналов — Remote Desktop Commander. Он соединяет ChatGPT с агентом, установленным на выбранный компьютер или VPS, через удалённый MCP (протокол подключения инструментов к ИИ)-сервис. Это не «встроенный SSH в ChatGPT» и не разрешение на всю вашу инфраструктуру: управлять можно только устройствами, которые вы явно подключили. Учитывайте, что агент исполняет команды с правами системного пользователя, под которым он запущен.

Для первого опыта выберите учебный сервер, а не работающую базу клиентов. На production (рабочая среда для реальных пользователей) не стоит сразу выдавать ИИ полномочия root.

Шаг 1. Готовим VPS

Не требуется разбираться во всех командах заранее. Можно открыть ChatGPT или Claude и написать: «Я хочу подключить Remote Desktop Commander к моей учебной Ubuntu VPS. Проведи меня от проверки Node.js до запуска агента. Объясняй каждую команду, спрашивай результат и не запрашивай приватные ключи». ИИ подсказывает шаги; устройство и права доступа вы подтверждаете самостоятельно.

На Ubuntu под отдельным пользователем, созданным для учебного проекта, проверьте Node.js:

node --version

npm --version

По документации Remote Desktop Commander требуется Node.js 18 или новее. Если команды отсутствуют либо версия слишком старая, установите актуальную поддерживаемую LTS-версию Node.js по официальной инструкции для вашей Ubuntu. Не вставляйте случайные команды установки из непроверенных блогов и не скачивайте скрипты по непонятным ссылкам.

Проверьте, что пользователь, запускающий агента, имеет доступ только к нужной рабочей папке. Для знакомства можно завести ~/ai-site-lab. Если агент запущен под root или пользователем с неограниченным sudo, ошибка в предложенной команде станет гораздо опаснее.

Шаг 2. Подключаем устройство

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

npx @wonderwhy-er/desktop-commander@latest remote

Перед запуском при необходимости изучите опубликованный пакет и его полномочия. Служба покажет шаги подтверждения устройства: откройте указанную страницу, войдите в аккаунт Remote Desktop Commander, убедитесь, что код на экране совпадает с кодом в терминале, подтвердите подключение. Затем устройство должно появиться в списке вашей учётной записи.

Адрес панели устройства: https://mcp.desktopcommander.app/.

В стандартном сценарии агент работает, пока запущена его терминальная сессия. Закрыли терминал — связь пропала. На удалённом VPS для длительной работы можно использовать отдельный управляемый процесс, но не включайте автоматический запуск с привилегиями администратора «на всякий случай». Запишите, как отключить и отозвать устройство.

Шаг 3. Разрешаем подключение в ChatGPT

Если в интерфейсе нет нужного пункта, не угадывайте. Спросите: «Как сейчас подключить Remote Desktop Commander к ChatGPT и убедиться, что видно именно мою VPS? Я напишу, какие пункты доступны в настройках. Подскажи следующий шаг». Названия разделов и доступность подключений могут меняться.

Откройте ChatGPT → Настройки → Плагины, найдите Remote Desktop Commander, установите его и выполните авторизацию. В интерфейсах с поддержкой пользовательских MCP-подключений может использоваться адрес:

https://mcp.desktopcommander.app/mcp

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

Авторизуйте тот же аккаунт Remote Desktop Commander, под которым связывали VPS. В разделе устройств должен отображаться именно ваш учебный сервер. У нескольких VPS могут быть похожие имена: прежде чем что-либо менять, попросите инструмент указать имя выбранного устройства и рабочую папку.

Шаг 4. Первая задача — только чтение

Отправьте ChatGPT:

Через Remote Desktop Commander подключись к устройству с именем моего учебного сервера. Пока ничего не изменяй. Покажи hostname, текущего пользователя, рабочую директорию и список файлов каталога ~/ai-site-lab. Не читай файлы секретов. Если устройство недоступно, сообщи ошибку подключения; не утверждай, что выполнил проверку.

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

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

Создай в ~/ai-site-lab текстовый файл check.txt с текущей датой и строкой Connection test. Сначала покажи путь, затем создай файл и прочитай его обратно. Не работай за пределами этой папки.

Проверьте существование файла самостоятельно из PowerShell:

ls -l ~/ai-site-lab/check.txt

cat ~/ai-site-lab/check.txt

У вас появился проверяемый цикл: поручение → действие инструмента → файл на сервере → независимая проверка.

Где проходит граница доверия

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

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

1. Сначала инвентаризация, потом план.

2. Перед изменением рабочих файлов — резервная копия или контроль версий.

3. Без явного разрешения нельзя удалять базы, менять firewall, создавать платные ресурсы или проводить деплой в production.

4. Не выводить в чат токены, приватные ключи и конфигурации с секретами.

5. В конце каждого действия — команда или тест, подтверждающий результат.

6. Для production пользоваться отдельным пользователем с минимальными разрешениями.

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

Если устройство недоступно

Проверьте в панели устройства статус Online. Затем через PowerShell проверьте, продолжает ли работать процесс агента, доступен ли интернет с VPS и не завершилась ли авторизация. Если сервер доступен только через VPN или туннель, сначала восстановите этот маршрут; ошибка доступа не доказывает, что сервер выключен.

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

Результат главы

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

Актуальные инструкции: Remote Desktop Commander; подключение к ChatGPT.

Глава 5. GitHub и ChatGPT: сохраняем код, а не переписки

Зачем GitHub, если файлы уже лежат на сервере

GitHub тоже можно настраивать с ИИ. Например: «Помоги подключить GitHub к ChatGPT для чтения моего репозитория и организовать безопасную работу с кодом: ветки, коммиты и Pull Request. Я новичок. Давай по одному шагу, объясняя, зачем он нужен». Историю версий важно сохранять, а названия всех команд помнить необязательно.

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

Git (система контроля версий) хранит историю изменений, GitHub размещает репозиторий. Это не одно и то же. Git можно использовать без сайта GitHub, а GitHub не обязан иметь доступ к вашему серверу.

Разделим три зоны: рабочие файлы (там мы редактируем), репозиторий (там храним историю) и опубликованный сайт (там пользователи видят только проверенный результат). Именно это разделение позволяет работать с ИИ без постоянного страха что-нибудь испортить.

Шаг 1. Создаём пустой репозиторий

Зарегистрируйтесь на GitHub и включите двухфакторную защиту. Выберите New repository. Назовите репозиторий, например site-example. Для первой тренировки разумно поставить Private, чтобы черновой код не был публичным. Не добавляйте лицензию, README или шаблон .gitignore прямо в GitHub, если планируете инициализировать проект на компьютере с нуля.

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

Шаг 2. Ставим Git на Windows

Если установка вызывает вопросы, напишите: «У меня Windows. Помоги установить Git с официального сайта и проверить его через PowerShell. Я пришлю вывод команды; объясни, всё ли настроено». Не нужно разбираться во всех установочных параметрах самостоятельно.

Установите Git с официального сайта https://git-scm.com/. В PowerShell проверьте:

git --version

Создайте папку проекта:

New-Item -ItemType Directory -Force "$HOME\Documents\site-example"

Set-Location "$HOME\Documents\site-example"

git init -b main

Создайте index.html через редактор кода, например VS Code. Не обязательно использовать автоматическую генерацию на первом шаге: важно, чтобы на диске был понятный файл, а не только текст в переписке.

Добавьте .gitignore:

.env

.env.*

!.env.example

node_modules/

*.key

*.pem

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

Шаг 3. Первый коммит

Коммит (commit) — зафиксированный снимок выбранных изменений кода в истории Git. Коммит содержит идентификатор и краткое сообщение. Это ещё не публикация сайта и не отправка кода на сервер: он лишь сохраняет версию проекта.

В папке проекта:

git status

git add index.html .gitignore

git commit -m "Initial site page"

Если Git просит указать имя и email, настройте их по официальной инструкции. Затем скопируйте адрес вашего репозитория на GitHub и свяжите проект с ним:

git remote add origin git@github.com:YOUR-LOGIN/site-example.git

git push -u origin main

Замените YOUR-LOGIN своим логином. Для SSH-доступа к GitHub предварительно добавьте публичный ключ вашего Windows-компьютера в GitHub → Settings → SSH and GPG keys. При выборе HTTPS (защищённый протокол связи браузера с сайтом) вместо SSH потребуется другой способ аутентификации; пароль от аккаунта в командную строку вводить нельзя.

После git push откройте репозиторий в браузере. Вы должны увидеть index.html и первый коммит.

Результат: файл доступен в GitHub, локальные изменения можно сравнивать с предыдущими версиями.

Шаг 4. Подключаем GitHub к ChatGPT

Запрос для ИИ: «Помоги подключить мой GitHub к ChatGPT. Покажи, как ограничить доступ только нужным репозиторием и проверить, что ChatGPT может его прочитать. Не проси у меня пароль или токен». Подключение для чтения репозитория не означает автоматическое право изменять его содержимое.

Откройте ChatGPT → Настройки → Плагины → GitHub и выполните подключение. Подтвердите права в GitHub, выберите доступ к нужному репозиторию — желательно конкретному, а не ко всем своим проектам. Наличие функции зависит от тарифа и интерфейса.

Важно не путать две возможности. По официальной документации обычное подключение GitHub к ChatGPT предназначено в первую очередь для чтения и анализа разрешённых репозиториев. Не следует автоматически считать, что такое подключение может редактировать файлы, выполнять git push или деплоить код. Для изменений используются подходящие инструменты с записью, например Codex или Remote Desktop Commander с установленным Git и необходимыми разрешениями.

Для первой проверки попросите:

Прочитай репозиторий YOUR-LOGIN/site-example через GitHub. Коротко перечисли файлы, объясни назначение index.html и предложи три улучшения. Не делай изменений и не придумывай файлы, которых нет в репозитории.

Сравните ответ с реальным содержимым GitHub. Если проект не виден, проверьте, что плагину выдан доступ к нужному репозиторию, и не переподключайте всё подряд.

Шаг 5. Работаем через ветки

Четыре термина перед первым изменением. Ветка (branch) — отдельная линия разработки, в которой можно менять код, не затрагивая основную версию. main (основная ветка Git) — основная ветка с принятой версией проекта. Merge (слияние) — перенос и объединение проверенных изменений рабочей ветки с main. Deploy (деплой) — публикация версии на сервере для посетителей. Слияние веток само по себе ещё не обновляет сайт.

Когда ChatGPT предложил улучшение, не изменяйте сразу main. В PowerShell создайте новую ветку:

git switch -c feat/contact-button

Измените кнопку контактов в index.html, затем:

git diff

git add index.html

git commit -m "Add contact button"

git push -u origin feat/contact-button

На GitHub откройте Pull Request (запрос на проверку и принятие изменений) из feat/contact-button в main. Проверьте изменённые строки, выполните тесты и только затем объедините изменения. После merge обновите локальную главную ветку:

git switch main

git pull --ff-only

Не позволяйте ИИ говорить «готово» только потому, что он написал код. Готово — когда есть коммит, понятная проверка и подтверждённый результат.

Шаг 6. Как связать GitHub и сервер

Серверу для публикации сайта может понадобиться читать репозиторий. Для приватного проекта предпочтителен отдельный ключ развёртывания с доступом только на чтение. Его публичную часть можно зарегистрировать как Deploy key конкретного репозитория. Не копируйте приватный ключ с домашнего компьютера на VPS и не раздавайте серверу полный доступ ко всем GitHub-репозиториям.

В терминале VPS, где установлен Git, можно получить проект командой:

git clone git@github.com:YOUR-LOGIN/site-example.git ~/site-example

Она выполнится только после настройки авторизации GitHub для самого VPS. Это другой доступ, не тот, что вы дали плагину ChatGPT. Для безопасного деплоя проект на сервере обычно только читается, а изменения в него отправляются через GitHub с компьютера разработчика.

Результат главы

У вас есть приватный репозиторий, первая версия сайта, новая ветка для изменения, Pull Request и подключение GitHub к ChatGPT для анализа кода. В следующей главе разместим подготовленный файл на Nginx и проверим HTTPS.

Официальные инструкции: https://help.openai.com/en/articles/11145903-connecting-github-to-chatgpt ; https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent .

Глава 6. Первый деплой: Nginx, HTTPS и проверка результата

Деплой (deployment) — выпуск проверенной версии приложения в рабочую среду. Это не просто копирование файлов: перед выпуском нужны проверки, а после — контроль доступности сайта и возможность отката.

Что такое «выложить сайт»

Когда файл index.html лежит на вашем компьютере, он открывается только у вас. Когда он загружен на сервер и его отдаёт Nginx, к нему могут обратиться посетители по домену. HTTPS защищает соединение между браузером и сайтом. Ни DNS, ни GitHub сами по себе веб-сервер не заменяют.

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

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

Шаг 1. Забираем проект на VPS

Сначала подключитесь из Windows PowerShell:

ssh deployer@203.0.113.10

Замените IP на свой. Все дальнейшие команды этой главы, если не указано иное, выполняются на Ubuntu-сервере.

Проверьте, что Git установлен:

git --version

Если его нет, обновите индексы пакетов и установите:

sudo apt update

sudo apt install -y git

Получите копию проекта (в четвёртой главе мы настроили для VPS ключ с правом чтения репозитория):

git clone git@github.com:YOUR-LOGIN/site-example.git ~/site-example

ls -la ~/site-example

Вы должны увидеть index.html. Если GitHub отвечает Permission denied (publickey), это проблема отдельной авторизации VPS в GitHub, а не проблема DNS сайта. Не пытайтесь исправить её публикацией приватного ключа в чате.

Шаг 2. Устанавливаем Nginx

Можно пройти настройку вместе с ИИ: «У меня чистая Ubuntu VPS и простой сайт в GitHub. Помоги установить Nginx, но сначала проверь, нет ли уже веб-сервера. После каждой команды объясняй вывод и жди моего ответа». Так проще разобраться, что именно запускается на сервере.

sudo apt update

sudo apt install -y nginx

sudo systemctl status nginx --no-pager

Статус active (running) означает, что процесс запущен. Для минимального сайта этого достаточно. Если на порту 80 уже работает другой веб-сервер, сначала выясните, кому принадлежит порт; не отключайте незнакомую службу.

Создайте каталог, из которого Nginx будет отдавать файлы:

sudo mkdir -p /var/www/site-example.ru/public

sudo install -m 0644 ~/site-example/index.html /var/www/site-example.ru/public/index.html

Мы копируем только опубликованный файл, а не всю папку репозитория с .git и возможными служебными файлами. Для настоящего приложения будут нужны отдельные инструкции сборки и миграций, но наша первая страница не требует ни Node, ни Python на веб-сервере.

Шаг 3. Создаём конфигурацию сайта

Создайте новый конфигурационный файл:

sudo nano /etc/nginx/sites-available/site-example.ru

Вставьте (и замените домен на свой):

server {

listen 80;

server_name site-example.ru www.site-example.ru;

root /var/www/site-example.ru/public;

index index.html;

location / {

try_files $uri $uri/ =404;

}

}

Сохраните файл. Затем включите конфигурацию:

sudo ln -s /etc/nginx/sites-available/site-example.ru /etc/nginx/sites-enabled/site-example.ru

sudo nginx -t

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

Когда nginx -t успешен:

sudo systemctl reload nginx

curl -I http://site-example.ru

HTTP-ответ 200 OK говорит, что веб-сервер отвечает на этот запрос. На пустом чистом сервере это проверка учебной страницы; на сервере с несколькими сайтами дополнительно откройте страницу браузером и убедитесь, что это именно ваш контент.

Если вместо сайта открывается страница «Welcome to nginx», проверьте, какая конфигурация выбрана для доменного имени, и действительно ли A-запись ведёт на нужный сервер. Не удаляйте конфигурацию по умолчанию на чужом или общем сервере без проверки.

Шаг 4. Подключаем HTTPS

Подсказка ChatGPT или Claude: «DNS уже настроен, сайт отвечает по HTTP. Помоги пошагово выпустить сертификат HTTPS через Certbot, проверить продление и исправить возможные ошибки. Не изменяй другие сайты на сервере». Важен работающий HTTPS, а не заученная команда установки.

Для сертификата необходимы работающий DNS, доступность порта 80 извне и корректная конфигурация домена в Nginx. Используем Certbot из официального проекта Let's Encrypt. Пакет устанавливайте способом, поддерживаемым вашей версией Ubuntu; один из документированных вариантов — Snap:

sudo snap install --classic certbot

Проверьте наличие /snap/bin/certbot. Когда DNS уже указывает на эту VPS, запустите:

sudo /snap/bin/certbot --nginx -d site-example.ru -d www.site-example.ru

Указывайте только те имена, для которых вы контролируете DNS. Certbot выполнит проверку владения доменом и при успехе настроит сертификат. Не просите ИИ обещать выпуск сертификата до завершения проверки центра сертификации.

Проверьте:

curl -I https://site-example.ru

sudo /snap/bin/certbot renew --dry-run

Первая команда должна успешно установить TLS (протокол шифрования сетевого соединения)-соединение; вторая проверяет механизм будущего обновления сертификатов. При неудаче сначала изучайте сообщения Certbot и DNS, а не запускайте команду заново бесконечно.

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

Шаг 5. Делаем первое изменение через GitHub

Теперь наша цель — пройти полный цикл изменения, а не один раз «сделать красивую страницу». В Windows откройте проект, создайте ветку feat/new-headline, измените заголовок в index.html, создайте коммит и Pull Request. После проверки и объединения в main выполните на сервере:

cd ~/site-example

git pull --ff-only

sudo install -m 0644 index.html /var/www/site-example.ru/public/index.html

curl -I https://site-example.ru

Откройте сайт в приватном окне браузера и проверьте, что текст заголовка действительно поменялся. Для статической страницы перезапуск Nginx после замены index.html не нужен.

В будущем обновление можно автоматизировать через CI/CD (автоматизация тестирования, сборки и выпуска). Но сначала оно должно хотя бы раз надёжно сработать вручную. Автоматизация хаотичного процесса лишь ускоряет ошибки.

Шаг 6. Поручаем ChatGPT проверку, а не выдуманный отчёт

Когда Remote Desktop Commander подключён к серверу, отправьте задачу:

Подключись к учебной VPS через Remote Desktop Commander. Ничего не изменяй. Покажи текущий коммит Git в каталоге ~/site-example, выполни nginx -t и безопасный HTTP-запрос к моему домену. Сравни фактический заголовок страницы с index.html. Сформулируй вывод только по реально полученным результатам. Не открывай секретные файлы и не выполняй деплой.

Так вы учитесь различать отчёт о действиях и доказательство результата. Если код на GitHub новый, а страница старая, проблема может быть в том, что файлы ещё не скопированы в каталог Nginx или запрос попал в кэш. Если страница меняется через HTTP, но не работает HTTPS, проверяем сертификат и конфигурацию TLS, а не переписываем HTML.

Контрольный лист результата

• Домен указывает на IP VPS.

• В PowerShell работает SSH-вход под отдельным пользователем.

• ChatGPT имеет только разрешённый доступ к учебной директории через Remote Desktop Commander.

• GitHub хранит исходный код и историю изменений.

• nginx -t проходит без ошибок.

• Сайт открывается по HTTPS, сертификат действителен.

• Изменение заголовка проходит по цепочке ветка → Pull Request → merge →git pull → проверка сайта.

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

Куда идти дальше

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

Дополнительные руководства: https://nginx.org/en/docs/ ; https://certbot.eff.org/ ; https://docs.github.com/ .

Глава 7. Как определить MVP и не строить лишнего

В первой главе мы сформировали первоначальную дорожную карту и разобрали идею продукта. Затем подготовили домен, сервер и инструменты управления проектом. Теперь определим, какие функции действительно нужны для первой версии: не всё из roadmap обязано попасть в MVP.

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

Чтобы этого избежать, нужен MVP.

Что такое MVP

MVP — Minimum Viable Product, минимально жизнеспособный продукт.

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

1. дать конкретному пользователю полезный результат;

2. проверить важное предположение;

3. получить реальные данные для следующего решения.

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

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

MVP — не недоделанный большой продукт. Это законченный маленький продукт.

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

Начните с вопроса, который хотите проверить

Слабая постановка звучит так:

Нужно сделать первую версию CRM.

Сильная постановка:

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

Во втором случае становится понятнее, что должно войти в первую версию:

• автоматическое создание заявки;

• единая очередь;

• назначение ответственного;

• изменение статуса;

• отметка о последнем контакте;

• список заявок без ответа.

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

Перед определением MVP запишите:

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

Например:

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

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

Выберите один главный сценарий

Первая версия должна поддерживать основной путь пользователя от потребности до результата.

Для сервиса записи этот путь может выглядеть так:

1. Клиент открывает страницу специалиста.

2. Видит доступное время.

3. Выбирает подходящий слот.

4. Вводит контактные данные.

5. Подтверждает запись.

6. Получает уведомление.

7. Специалист видит новую запись.

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

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

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

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

Разделите функции на четыре группы

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

1. Обязательно для основного результата

Без этих функций пользователь не завершит главный сценарий.

Для CRM это могут быть:

• получение заявки;

• просмотр данных клиента;

• назначение менеджера;

• изменение статуса;

• фиксация следующего действия.

2. Обязательно для безопасной работы

Эти функции не всегда заметны пользователю, но без них продукт опасно выпускать.

Например:

• разграничение доступа;

• проверка вводимых данных;

• защита от повторной отправки формы;

• резервное копирование;

• журнал критических действий;

• корректная обработка ошибок оплаты.

Безопасность и надёжность нельзя автоматически отправлять в категорию «когда-нибудь потом». MVP интернет-магазина без проверки суммы заказа — минимальный, но не жизнеспособный. Особенно жизнеспособным в нём окажется покупатель, заказавший ноутбук за три рубля.

3. Полезно, но можно выполнить вручную

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

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

1. пользователь загружает файл;

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

3. запускает обработку;

4. проверяет результат;

5. отправляет отчёт клиенту.

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

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

4. Не входит в первую версию

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

• несколько языков;

• мобильное приложение;

• сложная персонализация;

• дополнительные способы входа;

• расширенная аналитика;

• экспорт во все известные форматы;

• интеграции «на будущее».

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

Оценивайте не только ценность, но и стоимость сложности

Небольшая на вид функция может сильно увеличить объём разработки.

Например, требование «добавить оплату» включает не одну кнопку. Нужно учесть:

• создание платежа;

• успешный и неуспешный результат;

• повторные уведомления платёжной системы;

• отмену;

• возврат;

• изменение статуса заказа;

• хранение истории;

• тестовый режим;

• защиту от повторного списания.

Поэтому каждую функцию полезно оценивать по трём признакам:

Функция | Польза для проверки | Сложность и риск | Решение

Функция: Единая форма заявки; Польза для проверки: Высокая; Сложность и риск: Низкие; Решение: Включить

Функция: Назначение менеджера; Польза для проверки: Высокая; Сложность и риск: Средние; Решение: Включить

Функция: Прогноз вероятности продажи; Польза для проверки: Низкая на старте; Сложность и риск: Высокие; Решение: Отложить

Функция: Выгрузка списка в CSV; Польза для проверки: Средняя; Сложность и риск: Низкие; Решение: Включить при необходимости

Функция: Мобильное приложение; Польза для проверки: Низкая на старте; Сложность и риск: Высокие; Решение: Не включать

Оценки не обязаны быть математически точными. Их задача — сделать компромиссы видимыми.

Не путайте MVP с прототипом и пилотом

Эти понятия решают разные задачи.

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

MVP даёт пользователю реальный результат. Если это сервис записи, запись действительно сохраняется.

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

Часто разумная последовательность выглядит так:

макет → проверка сценария → MVP → пилот → расширение.

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

Определите границы первой версии

Хорошее описание MVP содержит не только список функций, но и ограничения.

Например:

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

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

Зафиксируйте:

• кто пользуется первой версией;

• какой сценарий поддерживается;

• какие роли нужны;

• какие данные хранятся;

• какие интеграции обязательны;

• что выполняется вручную;

• какие ограничения допустимы;

• что точно не входит в первую версию.

Заранее установите критерии успеха

MVP нужен не ради факта публикации. Он должен помочь принять решение.

Для разных продуктов критерии могут выглядеть так:

• не менее 30% посетителей формы завершают запись;

• менеджеры обрабатывают 90% заявок в течение рабочего часа;

• минимум 5 из 10 пилотных клиентов используют отчёт повторно;

• число пропущенных обращений снижается вдвое;

• пользователь создаёт первый проект без помощи сотрудника;

• три компании готовы оплатить следующий месяц использования.

Заранее определите и возможные решения:

• если гипотеза подтверждается — развиваем продукт;

• если результат слабый — изучаем причины и меняем сценарий;

• если потребности нет — останавливаем разработку;

• если ценность есть, но пользоваться сложно — улучшаем интерфейс;

• если спрос есть, но ручной процесс не справляется — автоматизируем узкое место.

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

Как использовать ИИ для сокращения объёма

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

Полезный запрос:

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

Раздели функции на категории: / 1. обязательные для основного сценария; / 2. обязательные для безопасности и сохранности данных; / 3. допустимые как ручной процесс; / 4. отложенные.

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

После ответа задайте второй вопрос:

Сократи предложенный MVP ещё на 30%. Какие функции можно убрать или заменить ручной операцией, не разрушив полезный результат?

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

Практический шаблон MVP

Заполните одну страницу:

• Главная гипотеза:

• Целевой пользователь:

• Полезный результат:

• Основной сквозной сценарий:

• Обязательные функции:

• Обязательные меры безопасности и надёжности:

• Что временно выполняется вручную:

• Ограничения первой версии:

• Что явно не входит в MVP:

• Метрика успеха:

• Сколько пользователей участвует в проверке:

• Сколько времени длится проверка:

• Какое решение принимаем по результатам:

Чек-лист перед началом разработки

• [ ] MVP проверяет одну понятную гипотезу.

• [ ] Назван конкретный пользователь.

• [ ] Есть сквозной сценарий от потребности до результата.

• [ ] Каждая функция связана с этим сценарием или безопасностью.

• [ ] Необязательные операции по возможности заменены ручными.

• [ ] Указано, что не входит в первую версию.

• [ ] Ограничения продукта записаны явно.

• [ ] Учтены ошибки, доступ к данным и критические сбои.

• [ ] Определена измеримая метрика.

• [ ] Понятно, какое решение будет принято после проверки.

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

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

Глава 8. Как заставить ИИ правильно понять задачу

После определения MVP становится понятно, что именно должно войти в первую версию продукта. Но между списком функций и работающим кодом остаётся опасный промежуток — постановка задачи.

Допустим, в MVP сервиса записи есть функция:

Клиент должен получать уведомление о записи.

Человеку эта фраза может казаться вполне ясной. ИИ сразу найдёт в ней десяток неизвестных:

• уведомление приходит по электронной почте, в SMS или мессенджере;

• когда его отправлять;

• что должно быть внутри;

• кому ещё оно приходит;

• что делать, если отправка не удалась;

• можно ли создать запись, если сервис уведомлений недоступен;

• нужно ли отправлять письмо повторно;

• на каком языке писать;

• откуда брать дату, адрес и имя специалиста.

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

ИИ не читает мысли. Он читает описание. А описание обычно гораздо короче мыслей автора.

Почему ИИ понимает не задачу, а переданный контекст

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

ИИ знает только то, что оказалось в доступном ему контексте:

• текст запроса;

• приложенные документы;

• переданные фрагменты кода;

• файлы, доступные агенту;

• предыдущие сообщения диалога.

Если важное правило существует только в вашей голове, для модели его не существует.

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

ИИ не нарушил сформулированное требование. Требование просто не содержало главного бизнес-правила.

Поэтому хорошая постановка начинается не со слов «напиши код», а с ответа на три вопроса:

1. Что происходит сейчас?

2. Что должно происходить после изменения?

3. По каким признакам мы поймём, что результат правильный?

Начинайте с цели, а не с кнопки

Слабая задача описывает элемент интерфейса:

Добавь кнопку «Повторить».

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

Более полезная постановка:

Иногда формирование отчёта завершается ошибкой из-за временной недоступности внешнего API. Пользователь должен иметь возможность повторно запустить обработку того же файла, не загружая его заново. Для отчётов со статусом failed нужно показать кнопку «Повторить обработку».

Здесь появляются:

• причина изменения;

• пользователь;

• условие появления кнопки;

• повторно используемые данные;

• ожидаемое действие.

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

Полезная формула:

[Кто] в ситуации [условие] должен иметь возможность [действие], чтобы получить [результат].

Например:

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

Передавайте текущее состояние

Задача на изменение проекта всегда зависит от того, как он устроен сейчас.

Фраза «добавь авторизацию через Google» недостаточна, если не указано:

• есть ли обычная регистрация;

• как хранятся пользователи;

• можно ли связать Google с существующей учётной записью;

• что происходит при совпадении адресов электронной почты;

• какой сервис отвечает за авторизацию;

• какие роли существуют;

• куда направлять пользователя после входа.

Перед изменением дайте ИИ краткую карту местности:

• назначение продукта;

• используемые технологии;

• текущее поведение;

• связанные файлы или модули;

• правила бизнеса;

• известные ограничения;

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

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

Передавайте только то, что влияет на решение.

Отделяйте требования от предположений

Требование — это правило, которое должно быть выполнено.

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

Предположение — это вывод, который ещё нужно подтвердить.

Вероятно, отправка писем уже реализована через существующий почтовый сервис.

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

• известно: записи хранятся в таблице appointments;

• требуется: отправлять подтверждение после создания записи;

• предположение: в проекте уже есть общий модуль отправки писем;

• нужно проверить: можно ли использовать его для этого сценария.

Хороший ИИ-помощник должен не маскировать неизвестность, а обнаруживать её. Просите модель перечислить предположения до начала работы:

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

Это занимает несколько минут и иногда экономит день исправлений.

Указывайте границы изменения

Без ограничений ИИ может решить задачу слишком широко.

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

Укажите:

• какие части системы можно менять;

• какие нельзя менять;

• допустимо ли добавлять зависимости;

• можно ли изменять базу данных;

• нужно ли сохранять обратную совместимость;

• какие существующие сценарии не должны измениться.

Например:

Измени только страницу создания заявки и существующий API-метод. Не меняй схему базы данных, систему авторизации и общий дизайн компонентов. Новые библиотеки не добавляй.

Такие рамки не мешают качеству. Они уменьшают число случайных решений.

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

Добавляйте критерии приёмки

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

Требование:

Сделать поиск клиентов.

Слишком расплывчато. Что именно считать поиском?

Критерии могут выглядеть так:

1. Поиск работает по имени, электронной почте и номеру телефона.

2. Регистр букв не влияет на результат.

3. Пробелы в начале и конце запроса игнорируются.

4. Поиск начинается после ввода минимум двух символов.

5. Если совпадений нет, пользователь видит сообщение «Клиенты не найдены».

6. Пользователь видит только клиентов своей организации.

7. В списке отображается не более 20 результатов на странице.

8. Очистка поля возвращает исходный список.

Теперь задачу можно проверить без телепатии и продолжительного обсуждения смысла слова «работает».

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

При 100 000 клиентов результаты должны появляться не более чем за две секунды в тестовой среде.

Показывайте примеры и контрпримеры

Примеры особенно полезны для форматов, расчётов и бизнес-правил.

Допустим, скидка действует на повторный заказ:

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

Добавьте примеры:

• есть завершённый заказ на 5 000 рублей — скидка применяется;

• есть только отменённый заказ — скидка не применяется;

• заказ оплачен, но полностью возвращён — скидка не применяется;

• создан неоплаченный заказ — скидка не применяется.

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

Описывайте ошибки и крайние случаи

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

Для каждой важной задачи спросите:

• что произойдёт при пустых данных;

• что произойдёт при неверном формате;

• есть ли ограничения по длине и размеру;

• что делать при повторном запросе;

• что увидит пользователь при сбое;

• сохранятся ли уже введённые данные;

• кто имеет право выполнить действие;

• что записывается в журнал событий;

• можно ли безопасно повторить операцию.

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

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

Просите ИИ сначала пересказать задачу

Перед созданием кода полезен короткий этап согласования.

Дайте модели инструкцию:

Перескажи задачу своими словами. Затем перечисли: 1. ожидаемое поведение; 2. бизнес-правила; 3. затрагиваемые части системы; 4. неизвестные данные; 5. рискованные предположения; 6. проверки, которые подтвердят результат. / Не предлагай код, пока противоречия не устранены.

Если пересказ неверен, исправить его намного дешевле, чем код.

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

Практический шаблон задачи для ИИ

Используйте такую структуру:

Контекст продукта:

[Что это за продукт и кто им пользуется]

Текущее поведение:

[Что происходит сейчас]

Проблема:

[Почему текущее поведение мешает пользователю или бизнесу]

Желаемый результат:

[Что должно происходить после изменения]

Бизнес-правила:

[Обязательные правила, роли, ограничения]

Критерии приёмки:

1. ...

2. ...

3. ...

Ошибки и крайние случаи:

[Пустые данные, повторы, сбои, недостаток прав]

Границы задачи:

[Что можно и нельзя менять]

Доступный контекст:

[Файлы, схема данных, документация, сообщения об ошибках]

Порядок работы:

Сначала перескажи задачу, перечисли предположения и недостающие данные.

Затем предложи минимальный план изменений.

Не начинай реализацию, если критически важной информации недостаточно.

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

Чек-лист перед передачей задачи

• [ ] Указана цель изменения, а не только название функции.

• [ ] Описано текущее и ожидаемое поведение.

• [ ] Назван пользователь или роль.

• [ ] Бизнес-правила отделены от предположений.

• [ ] Есть проверяемые критерии приёмки.

• [ ] Учтены ошибки, повторы и недостаток прав.

• [ ] Определены границы изменения.

• [ ] Передан только нужный контекст без секретов и реальных персональных данных.

• [ ] ИИ должен сначала пересказать задачу и задать вопросы.

• [ ] Понятно, как проверить результат вручную или тестами.

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

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

Глава 9. Создание технического задания

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

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

Если постановка отдельной задачи отвечает на вопрос:

Что именно нужно изменить сейчас?

то техническое задание отвечает:

Что мы создаём, для кого, в каких границах и как поймём, что система работает правильно?

ТЗ не обязано быть документом на сто страниц с печатью, подписями и выражением «в соответствии с вышеизложенным». Для небольшого продукта оно может занимать несколько страниц. Важен не объём, а отсутствие критических пробелов.

Хорошее техническое задание — это не памятник серьёзности проекта. Это общая карта, по которой человек, ИИ и привлечённый разработчик должны прийти примерно в одно место.

Что должно делать техническое задание

Практическое ТЗ выполняет пять функций.

1. Фиксирует цель

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

Слабая формулировка:

Создать CRM для отдела продаж.

Более полезная:

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

Во втором варианте уже понятны пользователи, основные действия и ценность.

2. Устанавливает границы

Без границ проект быстро начинает расширяться.

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

В ТЗ нужно прямо указать:

• что входит в текущую версию;

• что не входит;

• какие ограничения принимаются сознательно;

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

3. Описывает поведение системы

ТЗ должно показывать, что происходит при действиях пользователя.

Например:

1. Клиент отправляет заявку через форму.

2. Система проверяет обязательные поля.

3. Заявка сохраняется со статусом «Новая».

4. Ответственный менеджер получает уведомление.

5. Руководитель видит заявку в общем списке.

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

Такое описание полезнее фразы «реализовать модуль обработки заявок», потому что слово «модуль» звучит солидно, но само по себе ничего не объясняет.

4. Даёт основу для проверки

У каждого важного требования должен быть способ проверки.

Если написано:

Страница должна загружаться быстро,

возникает вопрос: быстро — это сколько?

Проверяемый вариант:

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

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

5. Сохраняет договорённости

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

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

Из каких разделов состоит рабочее ТЗ

Структура зависит от проекта, но для большинства лендингов, CRM, SaaS-сервисов и внутренних систем подходит следующий каркас.

1. Назначение продукта

Кратко опишите:

• какую проблему решает продукт;

• кто им пользуется;

• какой результат должен получить пользователь;

• какую бизнес-метрику планируется улучшить.

Пример:

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

Этот раздел удерживает разработку возле цели. Если новая функция не влияет на пользовательский результат или проверяемую гипотезу, возможно, ей пока не место в MVP.

2. Роли пользователей

Перечислите роли и доступные им действия.

Например:

Роль | Возможности

Роль: Клиент; Возможности: Отправить заявку и получить подтверждение

Роль: Менеджер; Возможности: Видеть назначенные заявки, менять статус, добавлять комментарии

Роль: Руководитель; Возможности: Видеть все заявки и отчёт по скорости обработки

Роль: Администратор; Возможности: Управлять пользователями и настройками

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

3. Границы версии

Здесь фиксируется состав MVP.

Входит:

• форма создания заявки;

• список заявок;

• назначение менеджера;

• изменение статуса;

• уведомление по электронной почте;

• отчёт по времени первого ответа.

Не входит:

• телефония;

• мобильное приложение;

• автоматическое распределение заявок;

• интеграция с бухгалтерией;

• конструктор отчётов.

Раздел «Не входит» не менее важен, чем список функций. Он защищает проект от незаметного расширения и напоминает, что отложенная идея не потеряна, а сознательно перенесена.

4. Пользовательские сценарии

Для каждой роли опишите основные последовательности действий.

Пример сценария:

Сценарий: менеджер принимает новую заявку

Менеджер входит в систему. Открывает список назначенных ему заявок. Выбирает заявку со статусом «Новая». Просматривает контактные данные и описание запроса. После звонка нажимает «Связались». Система сохраняет время первого контакта и меняет статус. Заявка учитывается в отчёте руководителя.

Добавьте альтернативные варианты:

• заявка уже обработана другим пользователем;

• менеджер потерял доступ;

• данные клиента неполные;

• запрос на сохранение не прошёл;

• пользователь дважды нажал кнопку.

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

5. Функциональные требования

Функциональные требования описывают, что система должна уметь.

Их удобно группировать по возможностям:

Создание заявки

• Поля: имя, телефон, электронная почта, комментарий.

• Имя и телефон обязательны.

• Телефон сохраняется в едином формате.

• После отправки заявке присваивается уникальный номер.

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

• При ошибке пользователь видит понятное сообщение, а введённые данные не исчезают.

Работа со статусами

• Доступные статусы: «Новая», «Назначена», «Связались», «Закрыта».

• Менеджер может менять статус только назначенных ему заявок.

• Переход из «Закрыта» обратно в «Новую» доступен только руководителю.

• Каждое изменение статуса сохраняется в истории.

Одно требование должно выражать одно понятное правило. Длинный абзац с пятью условиями труднее реализовать, проверить и обсуждать.

Полезно присваивать требованиям номера: FR-01, FR-02 и так далее. Тогда в задаче можно написать: «Реализовать FR-07 и проверить сценарии AC-12–AC-15», а не искать нужный абзац по фразе «где-то ближе к середине».

6. Данные и бизнес-правила

Опишите, какие данные нужны системе и как они связаны с процессом.

Для заявки это могут быть:

• номер;

• дата создания;

• имя клиента;

• контактные данные;

• источник;

• статус;

• ответственный менеджер;

• время первого контакта;

• комментарии.

На этом этапе не обязательно проектировать таблицы базы данных — это уже техническое решение. Но нужно зафиксировать смысл данных.

Например:

Время первого контакта записывается один раз при первом переходе в статус «Связались» и не изменяется при последующих переключениях статуса.

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

Отдельно определите:

• какие данные обязательны;

• кто может их видеть и менять;

• сколько времени они хранятся;

• можно ли их удалить;

• нужна ли история изменений;

• содержат ли они персональную или финансовую информацию.

7. Интеграции

Если система взаимодействует с внешними сервисами, для каждой интеграции укажите:

• назначение;

• какие данные передаются;

• в какой момент происходит запрос;

• что считается успешным результатом;

• что делать при ошибке;

• можно ли повторить запрос;

• есть ли тестовый режим;

• кто предоставляет доступы.

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

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

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

8. Нефункциональные требования

Нефункциональные требования описывают не отдельную функцию, а качества системы:

• производительность;

• безопасность;

• доступность;

• совместимость с устройствами;

• резервное копирование;

• журналирование;

• требования к хранению данных.

Примеры:

• интерфейс работает в актуальных версиях Chrome, Safari и Firefox;

• основные страницы адаптированы для экранов от 360 пикселей;

• пароль не хранится в открытом виде;

• действия администраторов записываются в журнал;

• резервная копия базы создаётся ежедневно;

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

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

9. Критерии приёмки

Критерии приёмки превращают требования в конкретные проверки.

Например:

Требование: менеджер видит только назначенные ему заявки.

Проверки:

менеджер А видит заявку, назначенную ему; менеджер А не видит заявку менеджера Б в списке; прямой запрос к API за заявкой менеджера Б возвращает отказ в доступе; руководитель видит обе заявки; администратор может изменить ответственного.

Такой набор становится основой ручной проверки и автоматических тестов.

Как использовать ИИ при подготовке ТЗ

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

Полезный запрос:

На основе описания продукта подготовь черновик технического задания.

Структура:

1. Назначение продукта.

2. Роли.

3. Границы MVP.

4. Пользовательские сценарии.

5. Функциональные требования.

6. Данные и бизнес-правила.

7. Интеграции.

8. Нефункциональные требования.

9. Критерии приёмки.

10. Открытые вопросы и риски.

Не придумывай отсутствующие правила.

Отдельно помечай:

- известные факты;

- предположения;

- противоречия;

- вопросы, без которых нельзя начинать реализацию.

После получения черновика попросите ИИ провести отдельную проверку:

• найти термины без определения;

• обнаружить требования без критериев приёмки;

• найти противоречия между ролями и правами;

• перечислить сценарии ошибок;

• указать места, где модель вынуждена догадываться;

• проверить, не появились ли функции за границами MVP.

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

ТЗ должно меняться контролируемо

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

Изменения нормальны. Ненормально, когда они остаются только в переписке.

Для документа полезно фиксировать:

• номер или дату версии;

• автора изменения;

• что изменилось;

• почему принято решение;

• какие задачи и проверки затронуты.

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

Практический чек-лист ТЗ

Перед началом реализации проверьте:

• [ ] Понятно, какую проблему решает продукт.

• [ ] Названы пользователи и их роли.

• [ ] Зафиксированы границы MVP.

• [ ] Явно перечислено то, что не входит в версию.

• [ ] Основные сценарии описаны от начала до результата.

• [ ] Для важных сценариев указаны ошибки и альтернативы.

• [ ] Функциональные требования сформулированы как конкретные правила.

• [ ] Описаны данные, права доступа и история изменений.

• [ ] Для интеграций определено поведение при сбоях и повторах.

• [ ] Указаны требования к безопасности, скорости и устройствам.

• [ ] У требований есть проверяемые критерии приёмки.

• [ ] Предположения отделены от подтверждённых фактов.

• [ ] Открытые вопросы собраны в отдельный список.

• [ ] В документе нет паролей, секретных ключей и реальных персональных данных.

• [ ] Версия ТЗ зафиксирована и доступна участникам проекта.

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

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

Так ТЗ становится не бюрократической остановкой перед разработкой, а рабочим мостом между человеческим замыслом и будущей системой.

Глава 10. Архитектура будущего проекта

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

Если ТЗ говорит: «Менеджер должен видеть назначенные ему заявки», архитектура уточняет:

• где хранятся заявки;

• какой компонент проверяет права менеджера;

• откуда интерфейс получает данные;

• как фиксируется изменение статуса;

• что происходит, если база данных или почтовый сервис недоступны.

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

Зачем архитектура нужна небольшому проекту

Иногда кажется, что архитектура нужна только банкам, маркетплейсам и космическим программам. А небольшой CRM или SaaS можно просто «начать писать».

Можно. Проблемы обычно появляются позже.

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

Архитектура помогает заранее определить:

• основные части системы;

• ответственность каждой части;

• движение данных;

• внешние зависимости;

• правила безопасности;

• возможные точки отказа;

• границы текущей версии.

Её задача — не предсказать всё будущее, а не допустить очевидного хаоса.

Начинайте со сценариев, а не с технологий

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

Правильный порядок обратный:

1. Какие пользовательские сценарии должна поддерживать система?

2. Какие данные для них нужны?

3. Какие правила необходимо выполнять?

4. Какие внешние сервисы участвуют?

5. Каковы ожидаемые нагрузка, риски и бюджет?

6. Какие технические решения подходят под эти условия?

Для CRM из предыдущей главы основной сценарий выглядит так:

1. Клиент отправляет заявку.

2. Система проверяет данные.

3. Заявка сохраняется.

4. Менеджеру отправляется уведомление.

5. Менеджер входит в личный кабинет и меняет статус.

6. Руководитель видит время первого контакта в отчёте.

Уже из этого сценария можно выделить основные части проекта:

• публичная форма;

• интерфейс сотрудников;

• серверная логика;

• база данных;

• система авторизации;

• сервис уведомлений;

• отчёты;

• журнал ошибок и действий.

Это и есть начало архитектуры. Пока без выбора конкретного языка, базы и хостинга.

Основные слои системы

Большинство веб-проектов удобно рассматривать как несколько слоёв.

Интерфейс

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

Он отвечает за отображение информации и ввод данных. Но важные бизнес-правила нельзя оставлять только в интерфейсе.

Например, кнопка «Удалить пользователя» может быть скрыта от менеджера. Однако этого недостаточно. Менеджер способен отправить запрос напрямую к серверу, случайно или намеренно. Поэтому сервер тоже обязан проверить права.

Интерфейс можно сравнить с дверью в офис. Табличка «Служебное помещение» полезна, но замок всё равно нужен.

Серверная часть

Серверная часть, или backend (серверная логика приложения), принимает запросы, проверяет права, выполняет бизнес-правила, обращается к базе данных и внешним сервисам.

Например, при переводе заявки в статус «Связались» сервер должен:

1. проверить, имеет ли сотрудник доступ к заявке;

2. убедиться, что переход статуса разрешён;

3. сохранить новый статус;

4. при первом таком переходе записать время контакта;

5. добавить событие в историю;

6. вернуть интерфейсу результат.

Серверная часть должна оставаться источником правил, даже если в проекте появятся второй интерфейс, мобильное приложение или внешняя интеграция.

База данных

База данных хранит сведения о пользователях, заявках, статусах, платежах и других сущностях продукта.

На уровне архитектуры важно определить:

• основные виды данных;

• связи между ними;

• кто может их читать и менять;

• нужна ли история;

• какие данные нельзя удалять безвозвратно;

• какие сведения являются персональными;

• сколько времени они хранятся.

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

Внешние сервисы

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

Для каждой интеграции нужно определить:

• когда она вызывается;

• какие данные получает;

• что считается успехом;

• сколько ждать ответа;

• можно ли повторить запрос;

• что происходит при сбое;

• где хранится идентификатор внешней операции.

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

Нарисуйте движение данных

Полезная архитектурная схема может быть очень простой:

Клиент

↓

Форма на сайте

↓

API серверной части

↓

База данных

↓

Сервис уведомлений

Менеджер

↓

Личный кабинет

↓

API серверной части

↓

База данных

Стрелка означает передачу запроса или данных. Для каждой стрелки стоит задать три вопроса:

1. Что передаётся?

2. Кто имеет право это отправлять и получать?

3. Что произойдёт при ошибке?

Например:

Форма → API:

имя, телефон, комментарий, источник заявки

API → база:

проверенные данные и дата создания

API → почтовый сервис:

адрес менеджера и номер заявки

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

Монолит или микросервисы

Эти термины часто звучат сложнее, чем устроены.

Монолит — приложение, в котором основные функции находятся в одном проекте и обычно публикуются вместе.

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

Для большинства MVP разумнее начинать с хорошо организованного монолита:

• проще запускать;

• меньше серверов и настроек;

• легче тестировать;

• дешевле сопровождать;

• проще искать ошибки.

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

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

Что создавать, а что брать готовым

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

Обычно имеет смысл использовать готовые решения для:

• авторизации;

• отправки писем и SMS;

• приёма платежей;

• хранения файлов;

• аналитики;

• резервного копирования;

• мониторинга ошибок.

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

При выборе внешнего сервиса оцените:

• стоимость сейчас и при росте;

• возможность выгрузить данные;

• наличие тестового режима;

• ограничения API;

• регион хранения данных;

• правила обработки персональных данных;

• зависимость проекта от поставщика;

• поведение при недоступности сервиса.

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

Выбор технологического стека

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

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

• подходит ли технология для задачи;

• легко ли найти документацию и специалистов;

• умеют ли с ней работать выбранные ИИ-инструменты;

• насколько просто запустить проект локально;

• поддерживается ли она на выбранном хостинге;

• регулярно ли обновляются библиотеки;

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

Для обычного кабинета с формами, ролями и отчётами не требуется экзотическая архитектура. Часто достаточно распространённого веб-фреймворка, реляционной базы данных и управляемого хостинга.

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

Предложи архитектуру MVP для CRM обработки заявок.

Условия:

- до 30 сотрудников;

- до 1000 заявок в день;

- роли: менеджер, руководитель, администратор;

- нужны email-уведомления и отчёт по времени ответа;

- мобильного приложения нет;

- команда разработки небольшая;

- приоритеты: простота поддержки, безопасность, низкая стоимость запуска.

Дай:

1. Компоненты системы.

2. Движение данных.

3. Два варианта стека с плюсами и минусами.

4. Внешние сервисы.

5. Основные риски.

6. Что не следует усложнять в MVP.

Не придумывай отсутствующие бизнес-правила.

Безопасность закладывается в схему

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

Архитектура должна заранее отвечать:

• где выполняется авторизация;

• где проверяются роли и права;

• как изолируются данные разных организаций;

• где хранятся секретные ключи;

• какие действия журналируются;

• как создаются резервные копии;

• кто имеет доступ к production;

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

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

Зафиксируйте архитектурные решения

Для небольшого проекта достаточно короткого документа:

1. Назначение

Что строится и какие сценарии поддерживает.

2. Компоненты

Интерфейс, серверная часть, база, файловое хранилище, внешние сервисы.

3. Потоки данных

Откуда приходят данные, где проверяются, сохраняются и передаются дальше.

4. Технологии

Выбранный стек и причины выбора.

5. Безопасность

Авторизация, права, секреты, журналирование, резервные копии.

6. Отказы

Что происходит при недоступности базы, почты, платежей или другого API.

7. Ограничения

Какие нагрузки поддерживает первая версия и что сознательно отложено.

8. Открытые вопросы

Решения, которые пока нельзя принять из-за нехватки данных.

Если важное решение меняется, запишите причину. Например: «Файлы перенесены из локального хранилища в объектное, потому что приложение запускается на нескольких серверах». Такая запись спасает от будущего вопроса: «А кто вообще это придумал?»

Практический чек-лист архитектуры

Перед началом реализации проверьте:

• [ ] Основные пользовательские сценарии связаны с компонентами системы.

• [ ] Понятно, где находится интерфейс, серверная логика и база данных.

• [ ] Бизнес-правила проверяются на сервере.

• [ ] Определены основные сущности и связи между ними.

• [ ] Нарисовано движение данных.

• [ ] Для каждой интеграции описано поведение при сбое.

• [ ] Секретные ключи не должны попадать в браузер или репозиторий.

• [ ] Права проверяются не только визуально, но и на уровне API.

• [ ] Есть разделение локальной, тестовой и рабочей среды.

• [ ] Продуман способ резервного копирования и восстановления.

• [ ] Выбор технологий объясняется условиями проекта.

• [ ] Архитектура не сложнее, чем требует MVP.

• [ ] Открытые вопросы явно зафиксированы.

• [ ] Решения с высокой ценой ошибки отмечены для отдельной проверки.

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

Если эти ответы понятны владельцу продукта, ИИ и разработчику, архитектура выполняет свою работу.

Глава 11. Проектирование интерфейсов

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

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

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

• кто обратился;

• когда поступила заявка;

• что требуется клиенту;

• кто отвечает за обработку;

• какой сейчас статус;

• какое действие нужно выполнить дальше.

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

Начинайте не с экранов, а с задач пользователя

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

До экранов нужно вернуться к ролям и сценариям, которые были определены в ТЗ.

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

1. Зачем человек входит в систему?

2. Какой результат он хочет получить?

3. Какие данные ему нужны для решения?

4. Какое действие он должен выполнить?

Например, в CRM есть три роли.

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

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

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

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

Постройте пользовательский поток

Пользовательский поток, или user flow, — это последовательность шагов от входа в сценарий до результата.

Для обработки новой заявки поток может выглядеть так:

Менеджер входит в систему

↓

Открывает список новых заявок

↓

Выбирает заявку

↓

Изучает контактные данные и комментарий

↓

Звонит клиенту

↓

Меняет статус на «Связались»

↓

Добавляет заметку

↓

Видит подтверждение сохранения

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

Для каждого шага проверьте:

• откуда пользователь сюда пришёл;

• что он должен понять;

• какое основное действие доступно;

• какие данные требуются;

• что произойдёт после действия;

• как вернуться назад;

• что случится при ошибке.

Не все потоки должны быть длинными. Если пользователь хочет скачать счёт, путь из семи экранов обычно говорит не о серьёзности системы, а о неудачном проектировании.

Составьте карту экранов

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

Для CRM первой версии карта может быть такой:

Вход

├── Список заявок

│ ├── Фильтры

│ └── Карточка заявки

├── Отчёт по времени ответа

├── Пользователи

│ └── Карточка пользователя

└── Настройки

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

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

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

Сделайте черновые макеты

Макет интерфейса показывает расположение элементов на странице. На раннем этапе достаточно простого черновика — его часто называют wireframe.

Он может выглядеть так:

------------------------------------------------

Заявка №1842 Статус: Новая

Анна Петрова

+7 900 000-00-00

Интересует подключение пяти сотрудников

Ответственный: Алексей

Создана: сегодня, 10:35

[Позвонить] [Изменить статус] [Добавить заметку]

------------------------------------------------

История

10:35 Заявка создана

------------------------------------------------

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

• видна ли главная информация;

• понятно ли основное действие;

• не перегружен ли экран;

• логично ли расположены элементы;

• хватает ли данных для принятия решения.

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

Проектируйте состояния, а не только идеальную картинку

Интерфейс существует не только в момент, когда всё загрузилось и данные аккуратно заполнили экран.

Для каждого важного блока нужно продумать состояния.

Загрузка

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

Иначе человек нажмёт «Оплатить» четыре раза — исключительно из желания помочь компьютеру сосредоточиться.

Пустые данные

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

Вместо пустого белого пространства лучше показать:

Новых заявок пока нет. Они появятся здесь после отправки формы на сайте.

Если раздел предполагает создание данных, уместна кнопка действия:

Пользователи ещё не добавлены. / Добавить первого пользователя

Ошибка

Сообщение «Error 500» полезно разработчику, но почти бесполезно клиенту.

Пользовательское сообщение должно объяснять:

• что не получилось;

• сохранились ли данные;

• что можно сделать;

• нужно ли повторять действие.

Например:

Заявка сохранена, но письмо менеджеру не отправилось. Повторите отправку уведомления позже.

Это точнее, чем тревожное «Что-то пошло не так».

Успех

После важного действия система должна подтвердить результат:

Статус изменён на «Связались».

Для удаления, оплаты, отправки документа или изменения прав полезно указать конкретный объект. Фраза «Операция выполнена» звучит уверенно, но оставляет вопрос: какая именно?

Недостаточно прав

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

Если человек открыл недоступную страницу по старой ссылке, интерфейс должен спокойно сообщить:

У вас нет доступа к этому разделу. Обратитесь к администратору организации.

Формы требуют особого внимания

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

Для каждого поля спросите:

• зачем эти данные нужны;

• обязательно ли получать их сейчас;

• можно ли определить значение автоматически;

• понятна ли подпись;

• есть ли пример формата;

• что произойдёт при ошибке.

Плохая подпись:

Значение

Более понятная:

Рабочий email

Полезная подсказка:

На этот адрес придёт приглашение в систему.

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

Сообщение об ошибке должно находиться рядом с проблемным полем:

Укажите телефон в формате +7 900 000-00-00.

Фраза «Некорректные данные формы» заставляет пользователя самостоятельно проводить расследование. Это лишняя работа, а он не нанимался тестировщиком вашего продукта.

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

Один экран — одно основное действие

На экране может быть несколько кнопок, но одна обычно является главной.

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

Визуальное различие помогает пользователю быстро сориентироваться:

• основная кнопка заметнее;

• вторичные действия спокойнее;

• опасные действия отделены;

• редко используемые функции можно поместить в дополнительное меню.

Не стоит делать все кнопки яркими. Если всё привлекает внимание, ничто не привлекает внимание.

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

• «Создать заявку» вместо «Отправить»;

• «Сохранить изменения» вместо «ОК»;

• «Удалить пользователя» вместо «Подтвердить»;

• «Перейти к оплате» вместо «Продолжить».

Учитывайте реальные данные

Макеты часто рисуют на удобных примерах: «Иван Иванов», «Компания» и сумма «1000 ₽». В работе данные оказываются менее воспитанными.

Проверьте интерфейс на примерах:

• длинное название организации;

• пользователь без фотографии;

• комментарий на несколько абзацев;

• нулевой результат поиска;

• тысяча строк в таблице;

• очень большая сумма;

• неизвестное значение;

• дата в прошлом или будущем;

• несколько объектов с одинаковыми именами.

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

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

Доступность — не дополнительное украшение

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

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

• текст должен иметь достаточный контраст с фоном;

• поля должны иметь видимые подписи;

• нельзя передавать смысл только цветом;

• кнопки и ссылки должны быть понятны по названию;

• фокус при работе с клавиатуры должен быть заметен;

• изображениям с полезным смыслом нужно текстовое описание;

• размер интерактивных элементов должен позволять нажать на них пальцем.

Красный и зелёный индикаторы статуса лучше дополнить словами «Ошибка» и «Успешно». Цвет помогает, но не должен быть единственным источником информации.

Как использовать ИИ при проектировании

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

Пример запроса:

Спроектируй черновой интерфейс карточки заявки для CRM.

Роль пользователя: менеджер.

Цель: понять суть обращения, связаться с клиентом,

изменить статус и оставить заметку.

Данные:

- имя и телефон клиента;

- комментарий;

- источник;

- дата создания;

- ответственный;

- текущий статус;

- история изменений.

Ограничения:

- менеджер не может удалять заявку;

- статус «Закрыта успешно» требует комментария;

- телефон виден только сотрудникам своей организации.

Подготовь:

1. Состав и порядок блоков.

2. Основное и вторичные действия.

3. Состояния загрузки, пустых данных и ошибки.

4. Тексты подтверждений.

5. Возможные ошибки проектирования.

Не добавляй новые бизнес-правила.

После первого варианта полезно попросить ИИ провести отдельную проверку:

• какие действия неоднозначны;

• где пользователь может потерять данные;

• какие состояния пропущены;

• учтены ли права;

• какие элементы окажутся неудобны на телефоне;

• соответствует ли макет критериям приёмки из ТЗ.

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

Проведите короткую проверку сценария

Дайте человеку задачу без подробной инструкции:

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

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

• где человек остановился;

• какие подписи не понял;

• что попытался нажать;

• заметил ли подтверждение;

• смог ли исправить ошибку;

• получил ли ожидаемый результат.

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

Чек-лист интерфейса

Перед передачей макетов в разработку проверьте:

• [ ] Для каждой роли определены основные задачи.

• [ ] Ключевые сценарии представлены пользовательскими потоками.

• [ ] У каждого экрана есть понятная цель.

• [ ] Основное действие визуально выделено.

• [ ] Продуманы загрузка, пустые данные, успех и ошибка.

• [ ] Учтены ограничения прав доступа.

• [ ] Формы содержат только необходимые поля.

• [ ] Ошибки объясняют, что исправить.

• [ ] Опасные действия требуют осознанного подтверждения.

• [ ] Макеты проверены на длинных и необычных данных.

• [ ] Интерфейс не полагается только на цвет.

• [ ] Кнопки и сообщения используют понятные формулировки.

• [ ] Макет сопоставлен с требованиями и критериями приёмки.

• [ ] Основной сценарий проверен хотя бы на нескольких пользователях.

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

Глава 12. База данных, пользователи и роли

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

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

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

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

Начинайте не с таблиц, а с данных

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

Возьмём CRM для обработки заявок. Менеджер должен:

1. увидеть новую заявку;

2. изучить контакты клиента;

3. связаться с ним;

4. изменить статус;

5. добавить заметку.

Из этого сценария появляются основные объекты:

• организация;

• сотрудник;

• клиент;

• заявка;

• статус заявки;

• заметка;

• история изменений.

Такие объекты называют сущностями. Сущность — это тип объекта, информацию о котором система должна хранить.

Конкретная заявка Анны Петровой — это уже запись сущности «Заявка».

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

• идентификатор;

• имя клиента;

• телефон;

• комментарий;

• источник;

• статус;

• ответственный сотрудник;

• дата создания.

Однако не стоит складывать всё в одну огромную таблицу. Если сведения о сотруднике повторяются в каждой заявке, изменение его имени потребует обновить множество записей. А если где-то обновление не произойдёт, один и тот же Алексей станет Алексеем Сергеевым, Алексеем С. и загадочным пользователем №17.

Обычно повторяющиеся самостоятельные объекты выносят в отдельные таблицы и связывают идентификаторами.

Организация

└── Пользователи

└── Заявки

└── Заметки

Что такое идентификатор

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

Имена, телефоны и адреса электронной почты для этого не подходят:

• имя может повторяться;

• телефон может измениться;

• email иногда исправляют;

• название организации не всегда уникально.

Поэтому система создаёт технический идентификатор, например:

user_id: 842

request_id: 1842

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

Важно также не выдавать последовательный номер за средство защиты. Если адрес заявки выглядит как /requests/1842, пользователь может заменить число на 1843. Сервер обязан проверить право доступа к запрошенной записи. Надежда на то, что никто не догадается поменять цифру, — не модель безопасности.

Связи между сущностями

В базе данных объекты редко существуют поодиночке. Между ними есть связи.

Один ко многим

Одна организация может иметь много сотрудников. Одна заявка — много заметок.

Организация 1 → много пользователей

Заявка 1 → много заметок

В записи пользователя хранится идентификатор организации, а в заметке — идентификатор заявки.

Многие ко многим

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

Для такой связи обычно создаётся промежуточная таблица:

project_members

- project_id

- user_id

- role

Она показывает не только факт участия, но и роль пользователя в конкретном проекте.

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

Пользователь, учётная запись и сотрудник — не всегда одно и то же

В простом MVP эти понятия иногда объединяют. Но перед этим стоит проверить реальные правила продукта.

Учётная запись отвечает за вход в систему:

• email или логин;

• пароль в защищённом виде;

• состояние доступа;

• дата последнего входа;

• настройки многофакторной аутентификации.

Профиль хранит сведения о человеке:

• имя;

• фотографию;

• телефон;

• должность;

• часовой пояс.

Членство в организации описывает отношение человека к компании:

• организация;

• роль;

• подразделение;

• дата присоединения;

• состояние членства.

Такое разделение полезно, если один человек может работать с несколькими организациями. Если продукт этого не допускает и не планирует, для MVP можно выбрать более простую модель. Главное — зафиксировать ограничение явно, а не обнаружить его после продажи системы первому холдингу.

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

Роли и права доступа

Роль — это набор разрешений, соответствующий обязанностям пользователя.

Для CRM роли могут быть такими:

• менеджер;

• руководитель;

• администратор организации;

• системный администратор.

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

Действие | Менеджер | Руководитель | Администратор

Действие: Смотреть свои заявки; Менеджер: Да; Руководитель: Да; Администратор: Да

Действие: Смотреть все заявки организации; Менеджер: Нет; Руководитель: Да; Администратор: Да

Действие: Менять статус заявки; Менеджер: Да; Руководитель: Да; Администратор: Да

Действие: Смотреть отчёты; Менеджер: Нет; Руководитель: Да; Администратор: Да

Действие: Добавлять сотрудников; Менеджер: Нет; Руководитель: Нет; Администратор: Да

Действие: Назначать роли; Менеджер: Нет; Руководитель: Нет; Администратор: Да

Действие: Удалять организацию; Менеджер: Нет; Руководитель: Нет; Администратор: Нет

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

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

Правило лучше формулировать не так:

Руководитель имеет расширенный доступ.

А так:

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

Чем конкретнее разрешения, тем легче написать код и тесты.

Изоляция данных организаций

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

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

requests

- id

- organization_id

- client_id

- assigned_user_id

- status

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

Недостаточная проверка:

Найти заявку с id = 1842

Безопаснее:

Найти заявку с id = 1842

и organization_id = организации текущего пользователя

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

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

Ограничения защищают данные

Бизнес-правила следует фиксировать не только в интерфейсе, но и на уровне backend и, где возможно, базы данных.

Полезные ограничения:

• обязательное поле не может быть пустым;

• email в пределах организации не должен повторяться;

• заметка должна ссылаться на существующую заявку;

• статус может принимать только допустимые значения;

• дата окончания не может быть раньше даты начала;

• сумма платежа не может быть отрицательной.

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

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

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

История, удаление и жизненный цикл

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

Для заявки может быть важно знать:

• кто изменил статус;

• когда это произошло;

• каким был предыдущий статус;

• какой комментарий добавили.

Для этого создают журнал событий или таблицу истории.

request_history

- request_id

- changed_by_user_id

- old_status

- new_status

- created_at

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

Заранее определите жизненный цикл данных:

• когда запись создаётся;

• кто может её изменять;

• когда она становится архивной;

• можно ли её восстановить;

• когда она удаляется окончательно;

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

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

Для персональных данных нужны отдельные правила хранения и удаления. «Сохраним навсегда, вдруг пригодится» — не стратегия, а будущая проблема.

Как описать модель данных для ИИ

Не просите ИИ просто «сделать базу для CRM». Передайте сущности, связи и правила.

Спроектируй черновую модель данных CRM для нескольких организаций.

Сущности:

- организация;

- пользователь;

- членство пользователя в организации;

- заявка;

- заметка;

- история статусов.

Правила:

- пользователь может состоять в нескольких организациях;

- роль задаётся отдельно для каждого членства;

- менеджер видит только назначенные ему заявки;

- руководитель видит все заявки своей организации;

- заявки нельзя удалять через интерфейс;

- удалённый пользователь не должен исчезать из истории;

- email пользователя уникален для учётной записи.

Подготовь:

1. Таблицы и основные поля.

2. Связи между таблицами.

3. Ограничения целостности.

4. Индексы для поиска.

5. Риски утечки данных между организациями.

6. Вопросы, которые нужно уточнить до реализации.

Не добавляй бизнес-правила без пометки «предположение».

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

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

Практический чек-лист

Перед включением модели данных в ТЗ проверьте:

• [ ] Основные сущности получены из пользовательских сценариев.

• [ ] У каждой сущности есть уникальный идентификатор.

• [ ] Описаны связи между объектами.

• [ ] Повторяющиеся данные не размножаются без причины.

• [ ] Учётная запись отделена от ролей и членства, если это требуется продукту.

• [ ] Для каждой роли перечислены конкретные разрешения.

• [ ] Права проверяются на сервере, а не только в интерфейсе.

• [ ] Данные разных организаций изолированы.

• [ ] Определены обязательные поля и уникальные значения.

• [ ] Учтены повторные запросы внешних сервисов.

• [ ] Зафиксирована история критичных изменений.

• [ ] Описаны архивирование, восстановление и удаление.

• [ ] Определены персональные данные и сроки их хранения.

• [ ] Пароли и секреты не хранятся в открытом виде.

• [ ] Рискованные решения отмечены для отдельной проверки.

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

Глава 13. Что такое frontend и backend

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

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

Большинство веб-систем условно делится на две части:

• frontend — то, с чем взаимодействует пользователь;

• backend — серверная часть, которая применяет правила, работает с данными и внешними сервисами.

Между ними обычно находится API — договор о том, какие запросы frontend может отправить и какие ответы backend должен вернуть.

Упрощённая схема выглядит так:

Пользователь

↓

Frontend в браузере

↓ HTTP-запрос

Backend

↓

База данных, файловое хранилище, платёжный сервис, CRM

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

Frontend: то, что работает на стороне пользователя

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

К frontend относятся:

• страницы и блоки;

• меню, кнопки и формы;

• модальные окна;

• таблицы и фильтры;

• адаптивная версия;

• состояния загрузки и ошибок;

• проверка удобства ввода;

• отправка запросов к API;

• отображение полученных данных.

Основные технологии браузерного frontend:

• HTML описывает структуру страницы;

• CSS отвечает за оформление и расположение элементов;

• JavaScript добавляет поведение и взаимодействие.

В современных проектах часто используются React, Vue, Angular и другие инструменты. Они не отменяют HTML, CSS и JavaScript, а помогают организовать сложный интерфейс.

Например, пользователь открывает страницу заказов. Frontend:

1. показывает заголовок и индикатор загрузки;

2. отправляет запрос на backend;

3. получает список заказов;

4. строит таблицу;

5. позволяет применить фильтр;

6. показывает понятную ошибку, если запрос не удался.

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

Backend: правила и операции системы

Backend работает на сервере. Пользователь обычно не видит его напрямую, но именно там выполняется значительная часть настоящей работы.

Backend отвечает за:

• регистрацию, вход и серверные сессии;

• проверку ролей и разрешений;

• создание и изменение записей;

• чтение и запись в базу данных;

• расчёт стоимости;

• формирование отчётов;

• обработку платежных вебхуков;

• работу с файлами;

• отправку уведомлений;

• интеграции с CRM и другими API;

• журналирование важных действий.

Backend может быть написан на JavaScript или TypeScript, Python, PHP, Java, C#, Go и других языках. Для владельца продукта конкретный язык не всегда принципиален. Важнее понимать, где находятся бизнес-правила и как они проверяются.

Допустим, менеджер нажимает кнопку «Вернуть оплату». Frontend показывает кнопку, запрашивает сумму и просит подтвердить действие. Backend должен:

1. определить вошедшего пользователя;

2. проверить право на возврат;

3. найти платёж в нужной организации;

4. убедиться, что возврат ещё возможен;

5. проверить доступный остаток;

6. создать операцию возврата;

7. обратиться к платёжному провайдеру;

8. сохранить результат;

9. записать действие в аудит.

Если оставить эти проверки только во frontend, пользователь сможет обойти интерфейс и отправить запрос напрямую. Спрятанная кнопка — это занавеска, а не дверной замок.

Браузеру нельзя доверять

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

Например, браузер отправляет:

{

"orderId": 1048,

"organizationId": 27,

"status": "paid"

}

Backend не должен рассуждать так:

Раз браузер сообщил организацию №27 и статус paid, значит всё верно.

Он должен самостоятельно проверить:

• к какой организации относится текущий пользователь;

• принадлежит ли ей заказ №1048;

• разрешено ли пользователю менять заказ;

• допустим ли переход в новый статус;

• кто и на каком основании подтверждает оплату.

То же относится к цене, скидке, роли и сроку подписки. Поле формы можно изменить за несколько секунд через инструменты браузера. Поэтому frontend помогает пользователю вводить данные, а backend заново проверяет всё, что влияет на права, деньги и сохранённое состояние.

Как frontend и backend общаются через API

Рассмотрим создание задачи в CRM.

Frontend отправляет запрос:

POST /api/tasks

Content-Type: application/json

{

"clientId": 847,

"title": "Позвонить по договору",

"dueDate": "2025-05-20"

}

Backend проверяет пользователя и данные, создаёт запись и отвечает:

201 Created

{

"id": 3152,

"title": "Позвонить по договору",

"status": "open",

"dueDate": "2025-05-20"

}

Frontend получает ответ и добавляет новую задачу в список.

При ошибке backend возвращает другой статус и безопасное описание:

422 Unprocessable Entity

{

"code": "INVALID_DUE_DATE",

"message": "Дата выполнения не может быть раньше сегодняшней"

}

Frontend показывает сообщение рядом с полем даты. Он не обязан знать все бизнес-правила заранее: источником окончательного решения остаётся backend.

Полезно разделять два уровня ошибок:

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

• понятный текст объясняет человеку, что делать.

Сообщение ValidationException at task.service.ts:184 пользователю не помогает. Зато разработчику оно может пригодиться в серверном логе. У каждого текста своя аудитория.

Где находится база данных

База данных не является frontend или экраном административной панели. Это отдельный слой хранения, с которым обычно работает backend.

Frontend → Backend → База данных

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

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

Один проект — не обязательно два репозитория

Frontend и backend — это роли частей системы, а не обязательное количество папок, серверов или GitHub-репозиториев.

В одном проекте структура может выглядеть так:

project/

├── frontend/

│ ├── pages/

│ ├── components/

│ └── styles/

├── backend/

│ ├── routes/

│ ├── services/

│ └── models/

└── tests/

Но современный фреймворк способен хранить интерфейс и серверные обработчики рядом:

app/

├── dashboard/

├── components/

├── api/

└── server/

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

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

Всегда ли сайту нужен backend

Нет. Простой статический лендинг может состоять только из HTML, CSS и JavaScript. Если он показывает информацию и ведёт пользователя на внешний сервис записи, отдельный backend может не понадобиться.

Но серверная часть обычно появляется, если нужно:

• безопасно принимать и хранить заявки;

• скрывать ключ CRM или другого API;

• регистрировать пользователей;

• разграничивать права;

• сохранять данные;

• принимать оплату;

• обрабатывать вебхуки;

• выдавать закрытые файлы;

• выполнять фоновые задачи.

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

Как определить, где искать ошибку

Представим, что пользователь нажимает «Сохранить», но изменения не появляются.

Проблема может находиться на разных уровнях:

Вероятно, frontend

• кнопка не реагирует;

• поле невозможно заполнить;

• модальное окно перекрыто;

• данные сохранились, но интерфейс показывает старое значение;

• ошибка есть только на определённой ширине экрана;

• запрос вообще не отправляется.

Вероятно, backend

• сервер возвращает ошибку500;

• права проверяются неправильно;

• запись создаётся дважды;

• сумма рассчитана неверно;

• запрос принят, но данные не сохранились;

• пользователь одной организации видит чужой объект.

Возможно, внешняя система или инфраструктура

• платёжный провайдер не отвечает;

• CRM отклоняет запрос;

• база данных недоступна;

• истёк API-ключ;

• DNS ведёт не на тот сервер;

• новая версия frontend обращается к старой версии API.

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

Пользователь с ролью «Менеджер» открывает заказ №1048,

меняет поле «Комментарий» и нажимает «Сохранить».

Frontend отправляет PATCH /api/orders/1048.

Сервер отвечает 403.

Ожидание: менеджер своей организации может менять комментарий.

Фактически: изменение отклоняется.

С таким описанием ИИ значительно проще проверить нужный участок, не отправляясь чинить весь проект лопатой.

Одно изменение может затронуть оба слоя

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

1. добавить колонку или поле в базе;

2. обновить серверную модель;

3. принять значение через API;

4. проверить формат и права;

5. вернуть поле в ответе;

6. добавить ввод во frontend;

7. показать серверные ошибки;

8. обновить тесты;

9. учесть импорт и экспорт.

Если изменить только форму, пользователь сможет ввести ИНН, но после обновления страницы значение исчезнет. Это классический цифровой фокус: поле было, поле пропало, аплодисменты не предусмотрены.

Поэтому перед изменением полезно спрашивать ИИ:

Какие слои затрагивает задача и почему?

А уже затем требовать список конкретных файлов и минимальный план работ.

Практический запрос для ИИ

Проанализируй задачу, не изменяя код.

Задача: добавить поле «ИНН» в карточку организации.

Определи:

1. Какие части относятся к frontend.

2. Какие части относятся к backend.

3. Нужны ли изменения базы данных и миграция.

4. Как изменится API-контракт.

5. Где должна выполняться валидация.

6. Какие права необходимо проверить на сервере.

7. Какие существующие сценарии могут сломаться.

8. Какие тесты нужно добавить или обновить.

Для каждого вывода укажи конкретный файл и функцию.

Не предлагай переписывать несвязанные части проекта.

Если информации недостаточно, перечисли вопросы.

Короткий чек-лист

Перед постановкой задачи определите:

• [ ] Что пользователь должен увидеть или сделать во frontend?

• [ ] Какой запрос отправляется на backend?

• [ ] Какие данные и права backend обязан проверить?

• [ ] Нужно ли читать или изменять базу данных?

• [ ] Затрагиваются ли файлы, платежи или внешние API?

• [ ] Какие состояния покажет интерфейс: загрузка, успех, ошибка, отсутствие прав?

• [ ] Что произойдёт при повторном запросе?

• [ ] Какие тесты нужны для каждого затронутого слоя?

• [ ] Как проверить изменение после публикации?

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

Глава 14. Как читать код, не зная языка программирования

После разделения проекта на frontend, backend и другие слои возникает практический вопрос: что делать, когда ИИ предлагает изменить файл, внутри которого живут фигурные скобки, стрелки и загадочное слово async?

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

• находить нужный участок;

• понимать назначение файла;

• прослеживать движение данных;

• замечать условия и ограничения;

• проверять, соответствует ли изменение задаче;

• задавать ИИ точные вопросы.

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

Читать код — не значит понимать каждый символ

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

Код лучше читать не по строкам, а по вопросам:

1. Какова роль этого файла?

2. Какие данные он получает?

3. Что с ними делает?

4. Какие условия проверяет?

5. Куда передаёт результат?

6. Что происходит при ошибке?

7. Кто вызывает этот код?

Вам не нужно сразу понимать всё. Нужно восстановить сценарий.

Например:

Пользователь нажимает «Сохранить»

→ форма собирает значения

→ frontend отправляет запрос

→ backend проверяет данные и права

→ база обновляет запись

→ backend возвращает результат

→ frontend показывает уведомление

Затем каждый шаг сопоставляется с конкретным файлом и функцией.

Начинайте с карты проекта

Перед чтением отдельных строк осмотрите структуру репозитория. Названия папок часто подсказывают архитектуру:

src/

├── pages/

├── components/

├── api/

├── services/

├── models/

├── utils/

└── tests/

Типичные назначения:

• pages, routes, screens — страницы и маршруты;

• components — элементы интерфейса;

• api, controllers, routes — обработчики запросов;

• services — бизнес-операции;

• models, entities — структуры данных;

• repositories — работа с базой;

• middleware — промежуточные проверки, например авторизация;

• utils, helpers — вспомогательные функции;

• tests, spec — тесты;

• migrations — изменения структуры базы данных.

Это не универсальный стандарт. Папка services в одном проекте содержит бизнес-логику, а в другом — обращения к внешним API. Поэтому название даёт гипотезу, а содержимое должно её подтвердить.

Сначала полезно найти:

• README.md — описание запуска и устройства проекта;

• package.json, pyproject.toml, requirements.txt или аналогичный файл — технологии и команды;

• конфигурацию маршрутов;

• схему базы данных;

• тесты интересующего сценария.

Тесты особенно полезны: они часто описывают поведение понятнее основного кода.

Ищите по словам из пользовательского сценария

Допустим, нужно понять, как меняется статус заказа. Начните с поиска:

• текста кнопки:Изменить статус;

• адреса API:/api/orders;

• названия поля:status;

• кода ошибки:INVALID_STATUS;

• названия функции:updateOrderStatus.

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

Лучше двигаться от уникального к общему:

"Изменить статус"

→ компонент кнопки

→ функция обработчика

→ API-запрос

→ серверный маршрут

→ сервис изменения заказа

→ запрос к базе

Так восстанавливается цепочка исполнения.

Пять конструкций, которые встречаются почти везде

Языки программирования различаются, но основные идеи похожи.

1. Переменная — подписанная коробка со значением

const orderId = 1048;

const status = "paid";

Здесь созданы значения с именами orderId и status. Хорошие имена помогают понять смысл без знания синтаксиса.

2. Функция — отдельная операция

function calculateTotal(items) {

return items.reduce((sum, item) => sum + item.price, 0);

}

Функция calculateTotal получает список позиций и возвращает итоговую сумму.

При чтении функции выясните:

• что она принимает;

• что возвращает;

• изменяет ли данные;

• обращается ли к базе или внешнему сервису;

• какие ошибки может вызвать.

3. Условие — развилка

if (!user.canRefund) {

throw new Error("FORBIDDEN");

}

Смысл: если у пользователя нет права на возврат, операция прерывается.

Особенно внимательно читайте условия вокруг:

• прав доступа;

• цены и скидки;

• статусов;

• принадлежности организации;

• удаления;

• платежей;

• выгрузки данных.

Одна пропущенная проверка иногда важнее пятисот красиво оформленных строк.

4. Цикл — повторение действия

for (const user of users) {

sendNotification(user);

}

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

5. Обработка ошибок — запасной маршрут

try {

await crm.createLead(data);

} catch (error) {

logger.error(error);

return { success: false };

}

Код пытается создать заявку в CRM. Если сервис отвечает ошибкой, выполняется блок catch.

Но наличие catch ещё не означает надёжность. Нужно проверить:

• сохранена ли заявка до обращения к CRM;

• будет ли повторная попытка;

• увидит ли сотрудник проблему;

• не попадут ли персональные данные или секреты в лог.

Как читать реальный обработчик

Рассмотрим упрощённый серверный код:

async function updateOrder(request, response) {

const user = request.user;

const orderId = request.params.id;

const comment = request.body.comment;

const order = await orders.findById(orderId);

if (!order || order.organizationId !== user.organizationId) {

return response.status(404).json({ code: "ORDER_NOT_FOUND" });

}

if (!user.permissions.includes("orders.edit")) {

return response.status(403).json({ code: "FORBIDDEN" });

}

const updatedOrder = await orders.update(orderId, { comment });

return response.json(updatedOrder);

}

Даже без знания JavaScript можно восстановить ход операции:

1. Из запроса берётся пользователь.

2. Из адреса извлекается ID заказа.

3. Из тела запроса берётся комментарий.

4. Заказ ищется в хранилище.

5. Проверяется существование заказа и совпадение организации.

6. Проверяется разрешениеorders.edit.

7. Комментарий сохраняется.

8. Обновлённый заказ возвращается клиенту.

Теперь можно задавать содержательные вопросы:

• Проверяется ли длина комментария?

• Можно ли передать HTML или опасный текст?

• Записывается ли изменение в аудит?

• Что произойдёт при ошибке базы?

• Может ли заблокированный пользователь выполнить операцию?

• Есть ли тест, где пользователь другой организации пытается изменить заказ?

Это уже чтение кода на уровне продукта, а не попытка выиграть конкурс фигурных скобок.

Обращайте внимание на входы и выходы

Для любого участка кода полезно составить маленькую таблицу:

Вопрос | Пример

Вопрос: Что входит?; Пример: ID заказа, комментарий, текущий пользователь

Вопрос: Откуда приходит?; Пример: URL, тело запроса, серверная сессия

Вопрос: Что проверяется?; Пример: Права, организация, формат данных

Вопрос: Что изменяется?; Пример: Поле комментария в заказе

Вопрос: Что выходит?; Пример: Обновлённый заказ или ошибка

Вопрос: Какие побочные действия?; Пример: Аудит, уведомление, интеграция

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

Не путайте объявление и вызов

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

Объявление:

function sendInvoice(invoice) {

// отправка счёта

}

Вызов:

await sendInvoice(invoice);

Найти функцию недостаточно. Нужно посмотреть:

• кто её вызывает;

• с какими данными;

• сколько раз;

• при каких условиях;

• что делает вызывающий код при ошибке.

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

Читайте изменения через diff

Если ИИ уже изменил проект, не перечитывайте все файлы. Начните с diff — сравнения старой и новой версий.

Обычно:

• строки с+ добавлены;

• строки с- удалены;

• остальной текст показывает контекст.

При проверке diff задайте вопросы:

• Изменены только необходимые файлы?

• Не удалена ли существующая проверка?

• Не заменён ли рабочий механизм новым без причины?

• Не появились ли секреты, токены или пароли?

• Обновлены ли тесты?

• Не изменились ли зависимости и конфигурация?

• Есть ли миграция, если изменилась база?

• Не добавлен ли временный обход вродеreturn true?

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

Просите ИИ показывать основания

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

Используйте запрос:

Объясни этот код человеку без технического образования.

Для каждого вывода укажи:

- файл;

- функцию;

- конкретные строки или фрагмент;

- входные данные;

- проверки;

- результат;

- возможные побочные эффекты.

Отдельно перечисли то, что нельзя определить по представленному коду.

Не предполагай наличие функций и проверок, которых нет в файлах.

Если ИИ говорит: «Доступ проверяется на уровне middleware», попросите назвать middleware и показать, где оно подключено к маршруту. Уверенный тон модели не является ссылкой на доказательство.

Полезно также попросить две версии объяснения:

1. краткую — на уровне пользовательского сценария;

2. техническую — с файлами, функциями и маршрутами данных.

Практический порядок чтения

Когда нужно разобраться в конкретной функции системы:

1. Сформулируйте действие пользователя.

2. Найдите страницу или кнопку, с которой оно начинается.

3. Найдите обработчик нажатия или отправки формы.

4. Определите API-запрос: метод, адрес и данные.

5. Найдите серверный маршрут.

6. Проследите проверки прав и валидацию.

7. Найдите изменение базы или вызов внешнего сервиса.

8. Посмотрите обработку успеха и ошибки.

9. Найдите тесты этого маршрута.

10. Сверьте код с фактическим поведением в браузере и логах.

Не пытайтесь изучить весь репозиторий перед первой полезной задачей. Читайте вертикальный сценарий от действия пользователя до результата. Так проект постепенно перестаёт быть лесом файлов и превращается в карту знакомых маршрутов.

Короткий чек-лист чтения кода

• [ ] Я понимаю назначение файла.

• [ ] Я нашёл, кто вызывает эту функцию.

• [ ] Я вижу входные данные и их источник.

• [ ] Я понимаю основные условия и проверки.

• [ ] Я нашёл операции с базой, файлами или внешними API.

• [ ] Я понимаю, что возвращается при успехе.

• [ ] Я вижу, что происходит при ошибке.

• [ ] Я проверил права и принадлежность данных.

• [ ] Я посмотрел связанные тесты.

• [ ] Выводы ИИ подтверждены конкретными фрагментами проекта.

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

Глава 15. Как давать ИИ задачу на изменение проекта

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

Фраза «добавь фильтр в CRM» понятна человеку на уровне общего намерения. Но для разработки в ней слишком много неизвестного:

• где должен появиться фильтр;

• по какому полю он работает;

• можно ли выбрать несколько значений;

• должен ли выбор сохраняться после обновления страницы;

• кто имеет право видеть результаты;

• что делать с архивными записями;

• как проверить готовое изменение.

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

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

Начинайте не с кода, а с результата

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

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

Слабая постановка:

Сделай удобный поиск клиентов.

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

Более точная постановка:

На странице «Клиенты» менеджер должен находить клиента по имени, email или телефону. Поиск запускается через 400 мс после окончания ввода. Телефон ищется независимо от пробелов, скобок и дефисов. Результаты должны содержать только клиентов текущей организации. Выбранные фильтры сохраняются в URL.

Здесь уже можно определить:

• что видит пользователь;

• какие данные вводит;

• как работает поиск;

• какие правила безопасности обязательны;

• как выглядит ожидаемый результат.

Техническую реализацию ИИ может предложить после изучения проекта.

Дайте модели контекст проекта

Одна и та же функция реализуется по-разному в статическом лендинге, React-приложении, интернет-магазине и корпоративной системе с несколькими организациями.

Перед задачей полезно кратко сообщить:

• назначение продукта;

• используемые технологии;

• где находится нужный сценарий;

• какие роли участвуют;

• какие ограничения уже известны;

• какие материалы доступны: репозиторий, документация, скриншоты, описание API.

Например:

Проект — SaaS для подготовки ежемесячных отчётов.

Frontend: React.

Backend: Node.js.

База данных: PostgreSQL.

Пользователь может состоять в нескольких организациях.

Отчёты одной организации не должны быть видны другой.

Нужно изменить форму создания отчёта.

Перед изменением изучи связанные файлы, API, схему данных и тесты.

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

Если технологии неизвестны, так и напишите:

Сначала определи стек и найди файлы, связанные с этим сценарием. Не изменяй код до составления плана.

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

Опишите текущее и желаемое поведение

Формат «сейчас → должно стать» заметно уменьшает число недоразумений.

Сейчас:

- после нажатия «Сохранить» кнопка остаётся активной;

- пользователь может отправить форму несколько раз;

- в базе появляются дубли заявок.

Должно стать:

- после первой отправки кнопка блокируется;

- интерфейс показывает состояние загрузки;

- повторный запрос с тем же ключом не создаёт новую заявку;

- при сетевой ошибке пользователь может безопасно повторить отправку;

- после успеха показывается номер заявки.

Такое описание показывает, что проблема не сводится к кнопке. Блокировка интерфейса улучшает поведение страницы, но сама по себе не защищает сервер от повторного запроса. Значит, изменение может затронуть frontend, backend, базу и тесты.

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

1. Открыть страницу /request.

2. Заполнить обязательные поля.

3. Включить в браузере медленное соединение.

4. Нажать «Отправить» три раза.

5. В CRM появляются три одинаковые заявки.

ИИ получает конкретную отправную точку, а не предложение «посмотри, там что-то дублируется».

Разделяйте требования и предположения

Требование описывает обязательный результат:

Только бухгалтер может скачать акт.

Предположение описывает возможный способ:

Возможно, для этого нужно добавить проверку в documentsController.

Не смешивайте их. Название файла может оказаться неверным, а требование всё равно останется правильным.

Хорошая формулировка:

Обязательное поведение:

- акт доступен пользователю с разрешением documents.download;

- акт должен принадлежать текущей организации;

- попытка прямого скачивания без права отклоняется сервером;

- отказ записывается в журнал безопасности.

Предположение:

- вероятно, маршрут находится в папке api/documents.

Проверь это по коду и не считай предположение фактом.

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

Ограничьте область изменения

Для задачи полезно определить scope — границы того, что входит и не входит в работу.

Пример:

В задачу входит:

- фильтр по статусу на странице заказов;

- передача статусов в API;

- серверная фильтрация;

- сохранение параметров в URL;

- тесты прав и комбинаций фильтров.

Не входит:

- изменение списка статусов;

- новый дизайн таблицы;

- экспорт заказов;

- переход на другой компонент интерфейса.

Такая граница защищает проект от «полезных улучшений», которые никто не заказывал. ИИ может решить, что заодно стоит заменить библиотеку таблиц, переименовать маршруты и привести весь проект к архитектурной гармонии. Архитектурная гармония прекрасна, пока Pull Request не напоминает капитальный ремонт ради замены дверной ручки.

Если во время изучения обнаружится необходимое дополнительное изменение, модель должна сначала объяснить причину и запросить согласование.

Добавьте критерии приёмки

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

Для функции «смена email» они могут выглядеть так:

• пользователь вводит новый email и текущий пароль;

• новый адрес проверяется на корректный формат;

• занятый адрес нельзя использовать повторно;

• на новый адрес отправляется ссылка подтверждения;

• до подтверждения вход выполняется по старому email;

• ссылка одноразовая и имеет ограниченный срок;

• после подтверждения старые сеансы отзываются;

• пользователь получает уведомление на старый адрес;

• пользователь другой организации не может повлиять на аккаунт прямым API-запросом.

Критерии должны охватывать не только счастливый путь, но и ошибки:

• неверные данные;

• отсутствие прав;

• объект другой организации;

• повторный запрос;

• недоступность внешнего сервиса;

• пустой результат;

• истёкшая ссылка или сессия.

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

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

Безопасный процесс состоит из двух этапов.

Этап 1. Исследование и план

Сначала попросите ИИ:

1. найти связанные файлы;

2. восстановить текущий сценарий;

3. перечислить затронутые слои;

4. показать существующие проверки и тесты;

5. выявить риски;

6. предложить минимальный план изменения;

7. указать неизвестные данные и вопросы.

Пример запроса:

Пока не изменяй код.

Изучи сценарий редактирования заказа и подготовь план:

- где начинается действие в интерфейсе;

- какой API вызывается;

- где проверяются права и организация;

- какие данные изменяются;

- какие тесты уже есть;

- какие файлы потребуется изменить;

- нужны ли миграции или новые зависимости;

- какие риски и неизвестные обнаружены.

Каждый вывод подтверждай конкретным файлом и функцией.

Этап 2. Реализация согласованного плана

После проверки плана можно дать разрешение:

Реализуй согласованный вариант.

Условия:

- не меняй несвязанные файлы;

- не удаляй существующие проверки;

- не добавляй зависимости без необходимости;

- сохрани обратную совместимость API;

- добавь или обнови тесты;

- не помещай секреты в код и логи;

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

Это медленнее, чем команда «делай». Зато обычно быстрее, чем восстановление проекта после бодрой импровизации.

Укажите технические запреты

Некоторые ограничения не видны из пользовательского сценария, но критичны для проекта.

Стоит явно написать, если нельзя:

• менять публичный API;

• удалять или переименовывать поля базы;

• добавлять библиотеки;

• менять формат дат;

• нарушать поддержку старых клиентов;

• выполнять внешние вызовы в тестах;

• отправлять реальные письма из тестовой среды;

• изменять production-конфигурацию;

• записывать персональные данные в логи.

Если изменение касается базы данных, спросите:

• нужна ли миграция;

• безопасна ли она для существующих данных;

• можно ли откатить изменение;

• что произойдёт со старыми записями;

• требуется ли заполнение нового поля;

• будет ли приложение работать во время поэтапного развёртывания.

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

Требуйте отчёт по результату

После реализации попросите ИИ не просто сообщить «готово», а предоставить проверяемое резюме:

После выполнения укажи:

1. Какие файлы изменены и зачем.

2. Как теперь работает сценарий.

3. Какие проверки прав и данных добавлены.

4. Какие тесты созданы или обновлены.

5. Какие команды запущены и каков результат.

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

7. Что не удалось проверить.

8. Какие риски остались.

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

Универсальный шаблон задачи

Цель:

Какой бизнес-результат нужен и для кого.

Контекст:

Тип проекта, технологии, роли, связанные страницы и API.

Сейчас:

Как работает сценарий или проявляется ошибка.

Должно стать:

Новое поведение пользователя и системы.

Критерии приёмки:

Проверяемые условия успеха и ошибок.

Ограничения:

Что нельзя менять, требования безопасности и совместимости.

Входит в задачу:

Конкретные части сценария.

Не входит:

Несвязанные улучшения.

Порядок работы:

Сначала исследование и план, затем реализация после согласования.

Проверка:

Какие тесты и ручные сценарии нужно выполнить.

Отчёт:

Изменённые файлы, команды, результаты, неизвестное и оставшиеся риски.

Короткий чек-лист перед отправкой задачи

• [ ] Понятно, кто пользователь и чего он хочет добиться.

• [ ] Описано текущее поведение.

• [ ] Описан ожидаемый результат.

• [ ] Есть шаги воспроизведения ошибки, если это исправление.

• [ ] Указаны роли, права и границы организаций.

• [ ] Учтены состояния ошибки и повторные действия.

• [ ] Определено, что входит и не входит в задачу.

• [ ] Технические догадки отделены от обязательных требований.

• [ ] Есть проверяемые критерии приёмки.

• [ ] ИИ должен сначала изучить проект и предложить план.

• [ ] Запрещены несогласованные масштабные изменения.

• [ ] Требуются тесты и отчёт о фактически выполненных проверках.

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

В этом и состоит рабочее разделение ответственности: не диктовать модели каждую строку кода, но и не отдавать ей проект со словами «сделай нормально».

Глава 16. Почему нельзя просить «просто всё исправить»

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

Можно ведь дать ему репозиторий и написать:

Посмотри проект, исправь все ошибки и сделай как лучше.

Звучит удобно. Примерно как передать мастеру ключи от квартиры со словами: «Тут что-то неуютно, переделайте всё». Через неделю можно получить прекрасную новую кухню — и обнаружить, что спальня почему-то исчезла.

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

«Всё» не является границей задачи

В реальном проекте почти всегда найдётся что улучшить:

• обновить зависимости;

• переименовать непонятные переменные;

• ускорить запросы к базе;

• переписать старый компонент;

• добавить проверки данных;

• изменить дизайн формы;

• удалить предупреждения сборки;

• переработать API;

• увеличить покрытие тестами;

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

Часть этих изменений действительно полезна. Но полезное изменение не обязательно нужно выполнять прямо сейчас.

Предположим, в CRM не сохраняется комментарий клиента. Вы просите ИИ «проверить проект и всё исправить». Модель обнаруживает:

1. ошибку в названии поля комментария;

2. несколько устаревших библиотек;

3. повторяющийся код в таблицах;

4. предупреждение линтера;

5. старый формат маршрутов API.

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

Формально проект стал «современнее». Практически отдел продаж остался без CRM.

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

ИИ не знает бизнес-приоритетов

Код показывает, как работает система, но не всегда объясняет, зачем она работает именно так.

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

Однако запрет мог появиться по деловой причине:

• заказ уже передан в службу доставки;

• стоимость рассчитана для конкретного региона;

• адрес указан в фискальном документе;

• изменение требует дополнительной проверки;

• оператор должен подтвердить его вручную.

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

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

Поэтому человек должен задать контекст:

• что считается проблемой;

• насколько она критична;

• какое поведение является ожидаемым;

• какие ограничения нельзя нарушать;

• что сейчас важнее остальных улучшений.

Разные ошибки требуют разных решений

Фраза «в проекте много ошибок» может обозначать совершенно разные ситуации.

Ошибка интерфейса

Кнопка выходит за границы экрана на телефоне. Вероятно, изменение затронет стили или компонент страницы.

Ошибка бизнес-логики

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

Ошибка доступа

Менеджер одной организации видит заказ другой. Это уже инцидент безопасности. Недостаточно скрыть строку в таблице — необходимо исправить серверную фильтрацию и проверить прямые API-запросы.

Ошибка данных

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

Ошибка инфраструктуры

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

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

Разумнее сначала выполнить триаж — первичную сортировку проблем по важности и срочности.

Сначала составьте список, а не разрешайте ремонт

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

Безопасный запрос выглядит так:

Не изменяй код.

Проведи аудит сценария создания заказа:

- найди возможные ошибки;

- раздели их на безопасность, данные, бизнес-логику, интерфейс,

производительность и качество кода;

- для каждой проблемы укажи подтверждение в коде;

- опиши последствия;

- оцени срочность;

- предложи минимальное исправление;

- перечисли необходимые тесты.

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

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

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

• критический — утечка данных, обход авторизации, потеря платежа, удаление информации;

• высокий — основной сценарий недоступен или даёт неправильный результат;

• средний — функция работает частично или неудобно, но есть обходной путь;

• низкий — косметика, технический долг, редкое неудобство.

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

Большой diff скрывает опасные изменения

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

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

В большом diff могут спрятаться:

• удалённая проверка прав;

• новый пакет с уязвимостью;

• изменение формата API;

• случайно записанный секретный ключ;

• отключённый тест;

• переименование поля базы;

• временный обход, оставленный как постоянное решение.

Количество строк само по себе не определяет качество. Иногда большое изменение необходимо. Но его размер должен объясняться задачей.

Если для исправления цвета кнопки модель переписала систему авторизации, это не смелая архитектура. Это повод закрыть Pull Request и спокойно выяснить, где разговор свернул не туда.

«Работает» может означать лишь один удачный сценарий

После команды «всё исправить» ИИ способен сообщить:

Все обнаруженные проблемы устранены, приложение работает корректно.

Это утверждение нужно разложить на проверяемые факты.

Что именно было проверено?

• Проект собирается?

• Автоматические тесты прошли?

• Форма работает в браузере?

• Сервер отклоняет запрос без прав?

• Данные другой организации недоступны?

• Повторный запрос не создаёт дубль?

• Платёж проверен в тестовом режиме?

• Изменение опубликовано и работает в реальной среде?

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

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

Исправление симптома может скрыть причину

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

Быстрое исправление на frontend:

После первого нажатия отключить кнопку.

Интерфейс станет аккуратнее, но повтор всё ещё возможен:

• пользователь обновил страницу;

• браузер повторил запрос;

• мобильная сеть отправила его снова;

• запрос вызвали напрямую через API;

• внешний сервис повторил вебхук.

Настоящее решение может потребовать идемпотентности на backend: одинаковая операция с одним ключом не должна создавать второй платёж.

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

Повтор одного и того же запроса не создаёт второй платёж независимо от действий интерфейса.

Тогда проверяется не только кнопка, но и серверная защита.

Автоматический рефакторинг — не бесплатная уборка

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

ИИ часто предлагает рефакторинг как сопутствующее улучшение:

Заодно я вынес общую логику, унифицировал обработчики и обновил архитектуру.

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

Перед таким изменением стоит спросить:

• какую конкретную проблему оно решает;

• необходимо ли оно для текущей задачи;

• какие сценарии могут пострадать;

• есть ли тесты, фиксирующие старое поведение;

• можно ли вынести рефакторинг в отдельную задачу.

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

Что делать, если проблем действительно много

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

Используйте последовательность:

1. Зафиксируйте симптомы. Что не работает для пользователей и сотрудников?

2. Отделите факты от предположений. Ошибка в журнале — факт; «наверное, виновата база» — гипотеза.

3. Проведите аудит без изменений.

4. Выделите критические риски. Доступ, платежи, потеря данных, секреты.

5. Разбейте проблемы по сценариям.

6. Определите порядок исправлений.

7. Для каждой задачи задайте границы и критерии проверки.

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

Например, не одна задача «починить личный кабинет», а несколько: