Како да ја подобрувате апликација изградена со AI без да ја расипете

За да ја подобрите апликацијата изградена со AI без да ја расипете, менувајте по една работа во секој упат, проверете ја во прегледот и зачувајте контролна точка пред да продолжите. Опишете што гледате, а не што мислите дека прави кодот, планирајте ги големите промени пред да ги градите, а кога некоја промена ќе пође наопаку, вратете се на последната добра верзија наместо да го замолите AI да ја поправи сопствената поправка.

Првата верзија на апликацијата често се склопува за минути. Тежокот дел е педесеттата промена, кога секој нов упат ризикува да расипе нешто што веќе функционирало. Овој водич е јамката што го спречува тоа.

Јамката за подобрување

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

Секој чекор постои за промените да останат мали и реверзибилни.

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

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

Ако промената е голема, поделете ја. „Додај кориснички сметки за тим“ станува: создај тимови, покани член, префрлај се меѓу тимови, ограничи ги податоците на тековниот тим. Секоја е посебен упат. Пишувањето кориснички приказни е добар начин за тоа.

Чекор 2: Опишете што гледате

AI не може да ви го види екранот освен ако не му кажете. Посочете конкретни работи и кажете што треба да се случи:

На страницата со цени на телефон, копчето на картичката Pro е отсечено на десниот раб. Задржете го распоредот на десктоп; на екрани под 640px, наредете ги картичките една под друга и направете ги копчињата со целата ширина.

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

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

Чекор 3: Планирајте пред големите промени

За секое што допира неколку делови од апликацијата — нов модел на податоци, плаќања, улоги на корисници — побарајте план пред било каква промена во кодот:

Не менувај го кодот уште. Сакам корисниците да припаѓаат на тимови и да ги гледаат само проектите на својот тим. Планирај ја промената: кои табели, страници и API рути се менуваат, што се случува со податоците на постојните корисници и по кој редослед би ја градел.

Прочитајте го планот. Ако е погрешен, поправањето на планот е многу поевтино од поништувањето на градењето.

Чекор 4: Кажете што не смее да се менува

Алатките за AI понекогаш „средуваат“ работи за кои не сте прашале. Заштитете го она што функционира:

Додај филтер по датум на табелата со нарачки. Не менувај ги колоните, стилот или копчето за извоз на табелата.

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

Чекор 5: Проверете повеќе од самата промена

По секој упат, тестирајте:

• Самата промена. Дали прави што сте побарале, на десктоп и на телефон?
• Соседите. Работи на истата страница и текови што ги користат истите податоци.
• Критичниот пат. Регистрација, најава, главното дејство, плаќање. Брз преглед од триесет секунди по секоја голема промена фаќа најголем дел од расипувањата рано.

Ако нешто не е во ред, пријавете го прецизно — видете како да напишете добар извештај за грешка.

Чекор 6: Вратете се назад наместо да нагомилувате

Кога промената ќе расипе нешто и првата поправка не функционира, застанете. Секоја дополнителна „поправка“ е изградена врз расипана состојба, а проблемите се зголемуваат.

Наместо тоа:

1. Вратете се на последната верзија што функционирала (контролна точка или Git commit).
2. Утврдете што не било јасно во упатот.
3. Обидете се повторно со помало или појасно барање.

Таа промена ги расипа зачувувањата на нацрти. Се вратив назад. Овој пат: додај само индикатор за автоматско зачувување, како текст во заглавието. Не менувај како се зачувуваат нацртите.

Чекор 7: Знајте кога е вистинско градење повторно

Градењето од почеток ги фрла многу работни детали. Вреди само кога:

• Идејата за производот целосно се променила.
• Основната структура не може да ја поддржи она што ви треба — на пример, била изградена како статична страница, а сега ви требаат сметки и база на податоци.
• Проектот е уште речиси празен.

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

Примери на упати

Пред да продолжиме, резимирај како функционира апликацијата моментално: страници, податоци што ги чува и што мислиш дека е кревко.

Сакам да додадам повторливи резервации. Која е најмалата верзија што би била корисна? Предложи ја како три одделни промени што можеме да ги направиме една по една.

Прегледај ги последните три промени за нешто што можеби го расипало текот на плаќање. Не уредувај уште.

Чести грешки

• Десет барања во еден упат. Некои се направени, некои на пола, а не можете да видите кои.
• Нејасни повратни информации. „Расипано е“ или „направи го подобро“ дава погодувања.
• Никогаш не ги проверувате соседите. Промена на заедничка компонента расипува три други страници.
• Поправање на поправки. Четири упати длабоко во една грешка — вратете се назад.
• Повторување на контекстот секој пат наместо да ги чувате постојаните правила во белешките на проектот.
• Градење повторно кога сте заглавени. Повеќето моменти на „почнете од почеток“ всушност значат „вратете се два чекора назад“.

Листа за проверка

• Една цел по упат.
• Опишувам што гледам и што треба да се случи.
• Големите промени добиваат план пред било каков код.
• Кажувам што не смее да се менува.
• По секоја промена ја тестирам, нејзините соседи и критичниот пат.
• Зачувувам контролна точка или commit по секоја промена што функционира.
• Кога поправката не успева, се враќам наместо да нагомилувам поправки.
• Постојаните правила живеат во белешките на проектот што AI ги чита секој пат.

Подобрување на Mythex

Mythex е изграден околу оваа јамка:

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

Поедноставните барања чинат и помалку кредити. За самото пишување на упатите, видете како да пишете упати за AI градители на апликации; кога нешто ќе се расипе, видете како да дебагирате апликација изградена со AI.

Прашања