Как дорабатывать приложение, созданное с ИИ, и не сломать его

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

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

Цикл доработки

1. Выберите одно изменение. Одна функция, один баг, одна страница.
2. Опишите его в терминах того, что видит и делает пользователь.
3. Для крупных изменений сначала план. Попросите план, прочитайте его, затем стройте.
4. Проверьте результат в превью — само изменение и связанные с ним сценарии.
5. Сохраните контрольную точку или коммит.
6. Повторите.

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

Шаг 1. Ведите короткий список

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

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

Шаг 2. Опишите то, что видите

ИИ не видит ваш экран, пока вы ему не расскажете. Укажите конкретные вещи и то, что должно происходить:

На странице цен на телефоне кнопка карточки Pro обрезана у правого края. Оставь раскладку для десктопа прежней; на экранах уже 640 px сложи карточки в столбик и сделай кнопки на всю ширину.

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

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

Шаг 3. Планируйте перед крупными изменениями

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

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

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

Шаг 4. Скажите, что не должно меняться

ИИ-инструменты иногда «приводят в порядок» то, о чём вы не просили. Защищайте то, что работает:

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

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

Шаг 5. Проверяйте больше, чем изменение

После каждого промпта проверьте:

• Само изменение. Делает ли оно то, что вы просили, на компьютере и на телефоне?
• Соседние части. Что на той же странице и какие сценарии используют те же данные.
• Критический путь. Регистрация, вход, главное действие, оплата. Тридцатисекундная проверка после каждого крупного изменения ловит большую часть поломок.

Если что-то не так, опишите проблему точно — см. как написать хороший баг-репорт.

Шаг 6. Откатывайтесь, а не наслаивайте

Когда изменение что-то ломает и первое исправление не помогает, остановитесь. Каждое новое «исправление» строится на сломанном состоянии, и проблемы множатся.

Вместо этого:

1. Откатитесь к последней рабочей версии (контрольной точке или коммиту Git).
2. Разберитесь, что было неясно в промпте.
3. Попробуйте снова с меньшим или более ясным запросом.

Это изменение сломало сохранение черновиков. Я откатился. Теперь: добавь только индикатор автосохранения, как текст в шапке. Не меняй то, как сохраняются черновики.

Шаг 7. Знайте, когда пересборка оправдана

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

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

Когда всё-таки переписываете, составьте список того, что сохранить: название, цвета, тексты, части, которые понравились пользователям.

Примеры промптов

Прежде чем продолжим, опиши, как сейчас работает приложение: страницы, данные, которые оно хранит, и то, что тебе кажется хрупким.

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

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

Частые ошибки

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

Чек-лист

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

Доработка на Mythex

Mythex построен вокруг этого цикла:

• Режимы Plan, Build и Ask. Plan обсуждает подход до правок; Ask отвечает, не меняя код; Build вносит изменение. См. Чат.
• Контрольные точки. После каждого успешного хода Mythex сохраняет git-контрольную точку; Revert to this point откатывает изменения. Вы также можете отредактировать более раннее сообщение и выбрать Discard & resend, чтобы попробовать другой промпт с этого места. См. Доработка без пересборки.
• Знания. Настройки проекта → Knowledge содержат постоянные заметки, которые агент учитывает в каждом сообщении.
• /test заставляет агента пройти по превью, как пользователь, после крупного изменения.

Короткие запросы также стоят меньше кредитов. О том, как писать сами промпты, читайте как писать промпты для ИИ-конструкторов приложений; если что-то всё же сломалось, — как отлаживать приложение, созданное с ИИ.

Вопросы