Ինչպես փոփոխել AI-ով կառուցված հավելվածը՝ առանց այն կոտրելու

AI-ով կառուցված հավելվածը առանց կոտրելու փոփոխելու համար փոխեք մեկ բան յուրաքանչյուր հուշումում, ստուգեք այն նախադիտարկմամբ և պահեք ստուգակետ մինչ հաջորդ քայլը։ Նկարագրեք այն, ինչ տեսնում եք, այլ ոչ թե այն, ինչ կարծում եք, որ կոդը անում է։ Մեծ փոփոխությունները նախ պլանավորեք, ապա կառուցեք, և երբ փոփոխությունը սխալ է ստացվում, վերադարձեք վերջին աշխատող տարբերակին, այլ ոչ թե խնդրեք AI-ին շտկել իր սեփական շտկումը։

Առաջին տարբերակը հաճախ րոպեների ընթացքում է հավաքվում։ Դժվարը յուրաքանչյուր հաջորդ փոփոխությունն է, երբ յուրաքանչյուր նոր հուշում վտանգում է այն, ինչ արդեն աշխատում էր։ Այս ուղեցույցը այն ցիկլն է, որը դա կանխում է։

Փոփոխության ցիկլը

1. Ընտրեք մեկ փոփոխություն։ Մեկ գործառույթ, մեկ սխալ, մեկ էջ։
2. Նկարագրեք այն այն բանի տեսքով, թե ինչ է տեսնում և անում օգտատերը։
3. Մեծ փոփոխությունների համար՝ նախ պլանավորեք։ Խնդրեք պլան, կարդացեք այն, ապա կառուցեք։
4. Ստուգեք արդյունքը նախադիտարկմամբ՝ փոփոխությունը և դրա շրջակա հոսքերը։
5. Պահեք ստուգակետ կամ commit։
6. Կրկնեք։

Յուրաքանչյուր քայլ գոյություն ունի, որպեսզի փոփոխությունները մնան փոքր և հետադարձելի։

Քայլ 1. Պահեք կարճ ցուցակ

Նախքան հուշելը գրեք, թե ինչ եք ուզում փոխել, կարևորության կարգով։ Դա կանխում է, որ մեկ հաղորդագրությամբ տասը ցանկություն ուղարկեք, և տալիս է ձեզ եղանակ ասելու «ոչ հիմա» այն գաղափարներին, որոնք միջին ճանապարհին են առաջանում։

Եթե փոփոխությունը մեծ է, բաժանեք այն։ «Ավելացնել թիմային հաշիվներ»-ը դառնում է․ ստեղծել թիմեր, հրավիրել անդամ, փոխել թիմերի միջև, սահմանափակել տվյալները ընթացիկ թիմով։ Յուրաքանչյուրը առանձին հուշում է։ Օգտատերերի պատմությունների գրելը լավ եղանակ է դա անելու համար։

Քայլ 2. Նկարագրեք, ինչ տեսնում եք

AI-ը չի տեսնում ձեր էկրանը, եթե դուք չասեք։ Մատնանշեք կոնկրետ բաներ և ասեք, թե ինչ պետք է տեղի ունենա․

Գնային էջում հեռախոսի վրա Pro քարտի կոճակը կտրվում է աջ եզրից։ Պահեք աշխատասեղանի դասավորությունը նույնը․ 640 պիքսելից ցածր էկրաններում դասավորեք քարտերը մեկը մյուսի տակ և կոճակները դարձրեք լրիվ լայնությամբ։

Համեմատեք սա «գնային էջը վատ է երևում բջջայինում» ասելու հետ։ Առաջինը մեկ անգամում կատարելի և ստուգելի է, իսկ երկրորդը հրավիրում է վերաձևավորում, որը չէիք խնդրել։

Սկրինշոթները օգնում են։ Եթե ձեր կառուցողը ընդունում է պատկերներ, կցեք մեկը և շրջապատեք խնդիրը։

Քայլ 3. Պլանավորեք մեծ փոփոխություններից առաջ

Յուրաքանչյուր բանի համար, որ դիպչում է հավելվածի մի քանի մասերին՝ նոր տվյալների մոդել, վճարումներ, օգտատիրոջ դերեր, նախ խնդրեք պլան, մինչ որևէ կոդ է փոխվում․

Դեռ կոդը մի փոխեք։ Ուզում եմ, որ օգտատերերը պատկանեն թիմերի և տեսնեն միայն իրենց թիմի նախագծերը։ Պլանավորեք փոփոխությունը․ որ աղյուսակները, էջերը և API երթուղիները կփոխվեն, ինչ կլինի գոյություն ունեցող օգտատերերի տվյալների հետ և ինչ հերթականությամբ կկառուցեք դրանք։

Կարդացեք պլանը։ Եթե սխալ է, պլանը ուղղելը շատ ավելի էժան է, քան կառուցվածքը հետ թողնելը։

Քայլ 4. Ասեք, թե ինչ չպետք է փոխվի

AI գործիքները երբեմն «կարգի են բերում» այն բաները, որոնց մասին չեք խնդրել։ Պաշտպանեք այն, ինչ աշխատում է․

Ավելացրեք ամսաթվի ֆիլտր պատվերների աղյուսակին։ Մի փոխեք աղյուսակի սյուները, ոճավորումը կամ արտահանման կոճակը։

Կանոններ, որ կիրառվում են ամենուր՝ բրենդի գույները, խոսքի ոճը, «երբեք մի ջնջեք տվյալներ առանց հաստատման», դրեք նախագծի նշումների կամ գիտելիքների կարգավորման մեջ, որը AI-ն կարդում է ամեն անգամ, այլ ոչ թե կրկնեք դրանք։

Քայլ 5. Ստուգեք ավելին, քան փոփոխությունը

Յուրաքանչյուր հուշումից հետո փորձարկեք․

• Փոփոխությունը։ Անում է արդյոք այն, ինչ խնդրել եք, աշխատասեղանի և հեռախոսի վրա։
• Դրա հարևանները։ Այն, ինչ նույն էջի վրա է, և այն հոսքերը, որ օգտագործում են նույն տվյալները։
• Կրիտիկական ուղին։ Գրանցում, մուտք, հիմնական գործողություն, վճարում։ Երեսուն վայրկյանանոց անցում յուրաքանչյուր մեծ փոփոխությունից հետո բռնում է խզումների մեծ մասը վաղ փուլում։

Եթե որևէ բան այլ է, ճշգրիտ նկարագրեք այն․ տե՛ս ինչպես գրել լավ սխալի հաշվետվություն։

Քայլ 6. Վերադարձեք, այլ ոչ թե կուտակեք

Երբ փոփոխությունը ինչ-որ բան է կոտրում, և առաջին շտկումը չի աշխատում, կանգ առեք։ Յուրաքանչյուր լրացուցիչ «շտկում» կառուցված է կոտրված վիճակի վրա, և խնդիրները բազմապատկվում են։

Փոխարենը․

1. Վերադարձեք վերջին աշխատող տարբերակին (ստուգակետ կամ Git commit)։
2. Պարզեք, թե ինչն էր անորոշ հուշման մեջ։
3. Նորից փորձեք ավելի փոքր կամ հստակ հարցումով։

Այս փոփոխությունը կոտրեց սևագրերի պահպանումը։ Վերադարձա։ Այս անգամ՝ ավելացրեք միայն ինքնապահպանման ցուցիչը որպես տեքստ վերնագրում։ Մի փոխեք, թե ինչպես են սևագրերը պահվում։

Քայլ 7. Իմացեք, թե երբ է վերակառուցումը ճիշտ

Չափազանց շատ աշխատող մանրամասներ է կորցվում, երբ վերակառուցում եք զրոյից։ Արժե միայն, երբ․

• Արտադրանքի գաղափարը ամբողջությամբ փոխվել է։
• Հիմնական կառուցվածքը չի կարող աջակցել այն, ինչ այժմ պետք է․ օրինակ՝ կառուցվել է որպես ստատիկ կայք, իսկ այժմ պետք են հաշիվներ և տվյալների բազա։
• Նախագիծը դեռ գրեթե դատարկ է։

Երբ վերակառուցում եք, ցուցակագրեք, թե ինչ պահել․ անունը, գույները, տեքստը, այն մասերը, որ օգտատերերին դուր եկան։

Օրինակ հուշումներ

Նախքան շարունակելը ամփոփեք, թե ինչպես է հավելվածն այժմ աշխատում․ էջերը, տվյալները, որ պահում է, և այն, ինչ կարծում եք, որ փխրուն է։

Ուզում եմ ավելացնել կրկնվող ամրագրումներ։ Ո՞րն է ամենափոքր տարբերակը, որ օգտակար կլինի։ Առաջարկեք այն որպես երեք առանձին փոփոխություն, որ կարող ենք մեկ-մեկ անել։

Ստուգեք վերջին երեք փոփոխությունները՝ արդյոք որևէ բան կարող էր կոտրել վճարման հոսքը։ Դեռ մի խմբագրեք։

Սովորական սխալներ

• Տասը հարցում մեկ հուշումում։ Ոմանք արվում են, ոմանք կիսատ, և չեք կարող ասել, թե որոնք։
• Անորոշ արձագանք։ «Կոտրված է» կամ «ավելի լավ արա» կարծիքներ՝ ենթադրությունների հիման վրա։
• Երբեք չստուգել հարևաններին։ Փոփոխությունը ընդհանուր բաղադրիչի վրա կոտրում է երեք այլ էջ։
• Շտկել շտկումները։ Չորս հուշում խորն ընկած սխալի մեջ՝ վերադարձեք։
• Յուրաքանչյուր անգամ կրկնել համատեքստը՝ նախագծի նշումներում պահելու փոխարեն։
• Վերակառուցել, երբ խրվել եք։ Շատ «նորից սկսենք» պահեր իրականում «վերադարձեք երկու քայլ» են։

Ստուգաթերթ

• Մեկ նպատակ յուրաքանչյուր հուշումում։
• Նկարագրում եմ, թե ինչ եմ տեսնում և ինչ պետք է լինի։
• Մեծ փոփոխությունները նախ ունեն պլան, նախքան կոդը։
• Ասում եմ, թե ինչ չպետք է փոխվի։
• Յուրաքանչյուր փոփոխությունից հետո փորձարկում եմ այն, հարևանները և կրիտիկական ուղին։
• Պահում եմ ստուգակետ կամ commit յուրաքանչյուր աշխատող փոփոխությունից հետո։
• Երբ շտկումը ձախողվում է, վերադառնում եմ, այլ ոչ թե կուտակում շտկումներ։
• Մշտական կանոնները ապրում են նախագծի նշումներում, որ AI-ն կարդում է ամեն անգամ։

Mythex-ում փոփոխելը

Mythex-ը կառուցված է այս ցիկլի շուրջ․

• Plan, Build և Ask ռեժիմներ։ Plan-ը քննարկում է մոտեցումը խմբագրելուց առաջ, Ask-ը պատասխանում է առանց կոդը փոխելու, Build-ը կատարում է փոփոխությունը։ Տե՛ս Չաթ։
• Ստուգակետեր։ Յուրաքանչյուր հաջող հերթափոխից հետո Mythex-ը պահում է git ստուգակետ․ Վերադառնալ այս կետին վերադարձնում է։ Կարող եք նաև խմբագրել նախորդ հաղորդագրությունը և Չեղարկել և նորից ուղարկել՝ այդ կետից այլ հուշում փորձելու համար։ Տե՛ս Փոփոխեք առանց վերակառուցելու։
• Գիտելիք։ Նախագծի կարգավորումներ → Գիտելիք պահում է մշտական նշումներ, որոնք գործակալը հետևում է յուրաքանչյուր հաղորդագրության վրա։
• /test-ը ստիպում է գործակալին սեղմել նախադիտարկման մեջ, ինչպես օգտատերը՝ մեծ փոփոխությունից հետո։

Փոքր հարցումները նաև քիչ կրեդիտ են արժենում։ Հուշումները գրելու մասին տե՛ս ինչպես գրել հուշումներ AI հավելվածի կառուցողների համար․ երբ ինչ-որ բան կոտրվում է, ինչպես վրիպազերծել AI-ով կառուցված հավելվածը։

Հարցեր