Paano Pagbutihin ang AI-Built na App Nang Hindi Ito Nasisira

Para pagbutihin ang AI-built na app nang hindi ito nasisira, baguhin ang isang bagay kada prompt, suriin ito sa preview, at mag-save ng checkpoint bago magpatuloy. Ilarawan ang nakikita mo sa halip na kung ano sa tingin mo ang ginagawa ng code, magplano muna bago buuin ang malalaking pagbabago, at kapag may pumalpak, bumalik sa huling gumaganang bersyon sa halip na hayaan ang AI na ayusin ang sarili nitong ayos.

Kadalasan, nabubuo ang unang bersyon ng app sa loob ng ilang minuto. Ang mahirap ay ang ikalimampung pagbabago, kapag may panganib na masira ng bawat bagong prompt ang dating gumagana. Ito ang gabay sa loop na pumipigil doon.

Ang iteration loop

1. Pumili ng isang pagbabago. Isang feature, isang bug, isang pahina.
2. Ilarawan ito ayon sa nakikita at ginagawa ng user.
3. Para sa malalaking pagbabago, magplano muna. Humingi ng plano, basahin ito, saka bumuo.
4. Suriin ang resulta sa preview: ang pagbabago at ang mga daloy sa paligid nito.
5. I-save ang checkpoint o commit.
6. Ulitin.

Ang bawat hakbang ay umiiral para panatilihing maliit at nababawi ang mga pagbabago.

Hakbang 1: Magtago ng maikling listahan

Bago mag-prompt, isulat kung ano ang gusto mong baguhin, ayon sa kahalagahan. Pinipigilan nito ang pagpapadala ng isang talatang may sampung hiling sa isang mensahe, at nagbibigay ng paraan para sabihing "hindi muna" sa mga ideyang lumalabas sa kalagitnaan.

Kung malaki ang pagbabago, hatiin ito. Ang "Magdagdag ng team accounts" ay nagiging: gumawa ng team, mag-imbita ng miyembro, lumipat sa pagitan ng team, limitahan ang datos sa kasalukuyang team. Bawat isa ay sariling prompt. Magandang paraan ito ang pagsulat ng user stories.

Hakbang 2: Ilarawan ang nakikita mo

Hindi makikita ng AI ang screen mo maliban kung sasabihin mo. Ituro ang mga tiyak na bagay at sabihin kung ano ang dapat mangyari:

Sa pricing page sa telepono, nakaputol ang button ng Pro card sa kanang gilid. Panatilihin ang layout sa desktop; sa mga screen na mas maliit sa 640px, ilagay nang patong-patong ang mga card at gawing buong lapad ang mga button.

Ihambing iyon sa "mukhang pangit ang pricing page sa mobile". Ang una ay magagawa at masusuri nang isahan; ang pangalawa ay nag-iimbita ng redesign na hindi mo hiniling.

Makakatulong ang screenshot. Kung tumatanggap ng larawan ang builder mo, maglakip ng isa at bilugan ang problema.

Hakbang 3: Magplano bago ang malalaking pagbabago

Para sa anumang gumagalaw sa maraming bahagi ng app, tulad ng bagong data model, payments, o user roles, humingi ng plano bago magbago ng code:

Huwag pa munang baguhin ang code. Gusto kong kabilang ang mga user sa mga team at makita lang ang project ng sarili nilang team. Magplano ng pagbabago: aling mga table, pahina, at API route ang magbabago, ano ang mangyayari sa datos ng umiiral na user, at anong pagkakasunod-sunod ang bubuuin.

Basahin ang plano. Kung mali ito, mas mura ang pagtama ng plano kaysa sa pag-undo ng build.

Hakbang 4: Sabihin kung ano ang hindi dapat magbago

Minsan "inaayos" ng mga AI tool ang mga bagay na hindi mo hiniling. Protektahan ang gumagana:

Magdagdag ng date filter sa orders table. Huwag baguhin ang mga column, istilo, o export button ng table.

Para sa mga patakarang sumasaklaw sa lahat, gaya ng brand colors, tono ng pananalita, o "huwag kailanman magbura ng datos nang walang kumpirmasyon", ilagay ang mga ito sa project notes file o knowledge setting na binabasa ng AI sa bawat pagkakataon, sa halip na ulitin ang mga ito.

Hakbang 5: Suriin higit pa sa pagbabago

Pagkatapos ng bawat prompt, subukan:

• Ang mismong pagbabago. Ginagawa ba nito ang hiniling mo, sa desktop at sa telepono?
• Ang mga katabi nito. Mga bagay sa parehong pahina, at mga daloy na gumagamit ng parehong datos.
• Ang kritikal na landas. Mag-sign up, mag-log in, ang pangunahing aksyon, bayad. Ang tatlumpung segundong pagsusuri pagkatapos ng bawat malaking pagbabago ay nakakahuli ng karamihan ng pagkasira nang maaga.

Kung may hindi tama, iulat ito nang tiyak. Tingnan ang paano sumulat ng magandang bug report.

Hakbang 6: Mag-rollback sa halip na magdagdag ng ayos

Kapag may nasirang bagay dahil sa pagbabago at hindi gumana ang unang ayos, huminto ka. Ang bawat dagdag na "ayos" ay nakapatong sa sirang estado, at lalong dumarami ang problema.

Sa halip:

1. Bumalik sa huling bersyong gumana (checkpoint o Git commit).
2. Alamin kung ano ang malabo sa prompt.
3. Subukan ulit gamit ang mas maliit o mas malinaw na hiling.

Nasira ng pagbabagong iyon ang pag-save ng mga draft. Nag-rollback na ako. Sa pagkakataong ito: idagdag lang ang autosave indicator, bilang teksto sa header. Huwag baguhin kung paano sine-save ang mga draft.

Hakbang 7: Alamin kung kailan tama ang buong rebuild

Ang pagbuo mula sa simula ay nagtatapon ng maraming gumaganang detalye. Sulit lang ito kapag:

• Ganap nang nagbago ang ideya ng produkto.
• Hindi na kayang suportahan ng pinagbabatayang istruktura ang kailangan mo ngayon. Halimbawa, ginawa itong static na site pero kailangan na nito ng accounts at database.
• Malapit pa ring walang laman ang project.

Kapag mag-rebuild ka, ilista kung ano ang dapat panatilihin: pangalan, kulay, copy, at ang mga bahaging nagustuhan ng mga user.

Mga halimbawang prompt

Bago tayo magpatuloy, buodin kung paano gumagana ang app ngayon: mga pahina, datos na iniimbak nito, at anumang sa tingin mong marupok.

Gusto kong magdagdag ng paulit-ulit na booking. Ano ang pinakamaliit na bersyon na magiging kapaki-pakinabang? Imungkahi ito bilang tatlong magkakahiwalay na pagbabago na puwede nating gawin nang isa-isa.

Suriin ang huling tatlong pagbabago para sa anumang maaaring nakasira sa checkout flow. Huwag pa munang mag-edit.

Mga karaniwang pagkakamali

• Sampung hiling sa isang prompt. May natatapos, may kalahating tapos, at hindi mo malalaman kung alin.
• Malabong feedback. Ang "sira" o "gawing mas maganda" ay nagbubunga ng hula.
• Hindi kailanman sinusuri ang mga katabi. Ang pagbabago sa isang shared component ay sumisira sa tatlo pang pahina.
• Pag-aayos ng mga ayos. Apat na prompt na malalim na sa iisang bug? Mag-rollback.
• Paulit-ulit na pagbibigay ng konteksto sa halip na itago ang permanenteng patakaran sa project notes.
• Pag-rebuild kapag natigil. Karamihan ng sandaling "magsimula ulit" ay talagang "bumalik nang dalawang hakbang".

Checklist

• Isang layunin kada prompt.
• Inilalarawan ko ang nakikita ko at kung ano ang dapat mangyari.
• Ang malalaking pagbabago ay may plano bago ang anumang code.
• Sinasabi ko kung ano ang hindi dapat magbago.
• Pagkatapos ng bawat pagbabago, sinusubukan ko ito, ang mga katabi nito, at ang kritikal na landas.
• Nagse-save ako ng checkpoint o commit pagkatapos ng bawat pagbabagong gumagana.
• Kapag pumalpak ang ayos, nagrorollback ako sa halip na magsalansan ng ayos.
• Ang permanenteng patakaran ay nasa project notes na binabasa ng AI sa bawat pagkakataon.

Pagbabago sa Mythex

Nakabatay ang Mythex sa loop na ito:

• Plan, Build, at Ask na mode. Pinag-uusapan ng Plan ang paraan bago mag-edit; sumasagot lang ang Ask nang hindi binabago ang code; ginagawa ng Build ang pagbabago. Tingnan ang Chat.
• Checkpoints. Pagkatapos ng bawat matagumpay na turn, nagse-save ang Mythex ng git checkpoint; ibinabalik ng Revert to this point ang estado. Puwede mo ring i-edit ang naunang mensahe at piliin ang Discard & resend para subukan ang ibang prompt mula sa puntong iyon. Tingnan ang Mag-iterate nang hindi nire-rebuild.
• Knowledge. Ang Project settings → Knowledge ang naglalaman ng permanenteng tala na sinusunod ng agent sa bawat mensahe.
• /test ay pinapa-click ng agent ang preview na parang user pagkatapos ng malaking pagbabago.

Mas kaunti ring credits ang nagagastos sa mas maliliit na hiling. Para sa pagsulat ng mismong prompt, tingnan ang paano magsulat ng prompt para sa AI app builder; kapag may nasira, tingnan ang paano mag-debug ng AI-built na app.

Mga tanong