Как да подобрявате приложение, изградено с AI, без да го счупите

За да подобрявате приложение, изградено с AI, без да го счупите, променяйте по едно нещо наведнъж, проверявайте го в преглед и запазвайте контролна точка, преди да продължите. Описвайте какво виждате, а не какво мислите, че прави кодът, планирайте големите промени, преди да ги изградите, и когато някоя промяна се обърка, връщайте се към последната работеща версия, вместо да молите AI да поправи собствената си поправка.

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

Цикълът на подобрение

1. Изберете една промяна. Една функция, един бъг, една страница.
2. Опишете я с думи за това, което потребителят вижда и прави.
3. При големи промени планирайте първо. Поискайте план, прочетете го, след това изграждайте.
4. Проверете резултата в прегледа — промяната и потоците около нея.
5. Запазете контролна точка или комит.
6. Повторете.

Всяка стъпка съществува, за да останат промените малки и обратими.

Стъпка 1: Водете кратък списък

Преди да пишете промпт, запишете какво искате да промените, по важност. Това ви спира да изпращате параграф с десет желания в едно съобщение и ви дава начин да кажете „не сега“ на идеи, които изскачат по средата.

Ако промяната е голяма, разделете я. „Добави екипни акаунти“ става: създаване на екипи, покана на член, превключване между екипи, ограничаване на данните до текущия екип. Всяка е отделен промпт. Писането на потребителски истории е добър начин да направите това.

Стъпка 2: Описвайте какво виждате

AI не може да види екрана ви, освен ако не му кажете. Посочвайте конкретни неща и кажете какво трябва да се случва:

На страницата с цените в телефон бутонът на Pro картата е отрязан от дясната страна. Запази настолното оформление същото; на екрани под 640px сложи картите една под друга и направи бутоните на цялата ширина.

Сравнете с „страницата с цените изглежда зле на мобилни“. Първото може да се направи и провери наведнъж; второто кани към преизграждане, което не сте поискали.

Снимките на екрана помагат. Ако строителят ви позволява изображения, прикачете едно и оградете проблема.

Стъпка 3: Планирайте преди големите промени

За всичко, което засяга няколко части на приложението — нов модел на данни, плащания, роли на потребители — поискайте план, преди да се промени какъвто и да е код:

Не променяй кода още. Искам потребителите да принадлежат към екипи и да виждат само проектите на своя екип. Планирай промяната: кои таблици, страници и API маршрути се променят, какво се случва с данните на съществуващите потребители и в какъв ред бихте я изградили.

Прочетете плана. Ако е грешен, поправянето на план е много по-евтино от отмяната на изграждане.

Стъпка 4: Кажете какво не трябва да се променя

Инструментите с AI понякога „подреждат“ неща, за които не сте питали. Защитете това, което работи:

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

За правила, които важат навсякъде — цветове на марката, тон на комуникация, „никога не изтривай данни без потвърждение“ — ги сложете във файл с бележки за проекта или в настройка за знания, които AI чете всеки път, вместо да ги повтаряте.

Стъпка 5: Проверявайте повече от промяната

След всеки промпт тествайте:

• Самата промяна. Прави ли това, което поискахте, на настолен компютър и на телефон?
• Съседите ѝ. Нещата на същата страница и потоците, които използват същите данни.
• Критичния път. Регистрация, вход, основното действие, плащане. Тридесетсекундна проверка след всяка голяма промяна улавя повечето счупвания рано.

Ако нещо не е наред, опишете го точно — вижте как да напишете добър доклад за бъг.

Стъпка 6: Връщайте се назад, вместо да трупате

Когато една промяна счупи нещо и първата поправка не помага, спрете. Всяка допълнителна „поправка“ се гради върху счупено състояние и проблемите се натрупват.

Вместо това:

1. Върнете се към последната версия, която е работила (контролна точка или Git комит).
2. Разберете какво е било неясно в промпта.
3. Опитайте отново с по-малка или по-ясна заявка.

Тази промяна счупи запазването на чернови. Върнах се назад. Този път: добави индикатора за автоматично запазване само като текст в заглавката. Не променяй как се запазват черновите.

Стъпка 7: Знайте кога преизграждането е правилно

Преизграждането от нулата изхвърля много работещи детайли. Струва си само когато:

• Идеята за продукта се е променила напълно.
• Основната структура не може да поддържа това, което сега ви трябва — например е изградена като статичен сайт, а сега трябват акаунти и база данни.
• Проектът е още почти празен.

Когато все пак преизграждате, запишете какво да се запази: име, цветове, текстове, частите, които потребителите харесаха.

Примерни промпти

Преди да продължим, резюмирай как работи сега приложението: страници, данни, които съхранява, и всичко, което мислиш, че е крехко.

Искам да добавя повтарящи се резервации. Каква е най-малката версия, която би била полезна? Предложи я като три отделни промени, които да направим една по една.

Прегледай последните три промени за нещо, което може да е счупило потока на плащане. Все още не редактирай.

Чести грешки

• Десет заявки в един промпт. Някои се свършват, някои — наполовина, и не можете да разберете кои.
• Неясна обратна връзка. „Счупено е“ или „направи го по-добро“ води до предположения.
• Никога не проверявате съседите. Промяна в споделен компонент чупи три други страници.
• Поправяне на поправки. Четири промпта дълбоко в един бъг — върнете се назад.
• Повтаряне на контекста всеки път, вместо да държите постоянните правила в бележките на проекта.
• Преизграждане при затруднение. Повечето моменти „започни отначало“ всъщност значат „върни се две стъпки назад“.

Контролен списък

• Една цел на промпт.
• Описвам какво виждам и какво трябва да се случва.
• Големите промени получават план, преди да има код.
• Казвам какво не трябва да се променя.
• След всяка промяна тествам нея, съседите ѝ и критичния път.
• Запазвам контролна точка или комит след всяка работеща промяна.
• Когато поправка не работи, се връщам назад, вместо да трупам поправки.
• Постоянните правила живеят в бележките на проекта, които AI чете всеки път.

Подобрение в Mythex

Mythex е изграден около този цикъл:

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

По-малките заявки също струват по-малко кредити. За писането на самите промптове вижте как да пишете промпти за AI строители за приложения; когато нещо се счупи, как да отстраните грешки в приложение, изградено с AI.

Въпроси