AI App Builder အတွက် Prompt ရေးနည်း (မတိုင်မီနှင့် နောက်ပိုင်း ဥပမာများ)

AI app builder အတွက် ကောင်းသော prompt သည် code ကို မဟုတ်ဘဲ ထုတ်ကုန်ကို ဖော်ပြသည်- ဘယ်သူသုံးသလဲ၊ အဆင့်လိုက် ဘာလုပ်သလဲ၊ ဘယ် data သိမ်းသလဲ၊ ဘယ်သူက ဘာကို မြင်ခွင့်ရှိသလဲ။ ပထမ version ရှိပြီးနောက် တစ်ကြိမ်လျှင် တိကျသော ပြောင်းလဲမှု တစ်ခုကို တောင်းပါ၊ ဘာကို ထားရမည်ကို ပြောပါ၊ ပြဿနာများကို "ကျွန်ုပ် X လုပ်ခဲ့သည်၊ Y ဖြစ်မည်ဟု မျှော်လင့်ခဲ့သည်၊ Z ရခဲ့သည်" ဟု ဖော်ပြပါ။ အဓိပ္ပာယ်ဆိုသည်မှာ ဤအလေ့အကျင့် သုံးခုက စိတ်ပျက်စရာ ရလဒ်အများစုကို ပြင်ပေးသည်။

ဤလမ်းညွှန်ရှိ ကျန်အပိုင်းများတွင် ပုံစံများကို အသေးစိတ် ဖော်ပြထားပြီး သင်ကိုယ်တိုင် ပြင်သုံးနိုင်သော before-and-after ဥပမာများ ပါဝင်သည်။

AI app builder ကို prompt ပေးခြင်းသည် chat နှင့် ဘာကွာသလဲ

chat assistant ကို မေးခွန်းမေးသောအခါ prompt မရှင်းလျှင် အဖြေလည်း မရှင်းဘဲ ဆက်သွားနိုင်သည်။ သို့သော် AI app builder ကို prompt ပေးသောအခါ အဖြေသည် အလုပ်လုပ်သော program ဖြစ်သည်။ သင်ဖော်ပြချက်ရှိ ကွက်လပ်တိုင်းကို ခန့်မှန်းချက်ဖြင့် ဖြည့်ပြီး ထိုခန့်မှန်းချက်များသည် သင် နေ့တိုင်း ကြုံရမည့် code၊ database table နှင့် မျက်နှာပြင်များ ဖြစ်လာသည်။

ထို့ကြောင့် prompt ၏ ရည်ရွယ်ချက်မှာ ဉာဏ်ကြီးဟန်ပြရန် မဟုတ်ပါ။ အရေးကြီးသော ဆုံးဖြတ်ချက်များကို အခွင့်အရေးအတွက် မထားရန် ဖြစ်သည်။ ထိုအတွက် နည်းပညာဝေါဟာရ မလိုပါ။ သင်သာ သိသော အရာများ- သင့်အသုံးပြုသူများ၊ သင့်အလုပ်စီးဆင်းမှုနှင့် သင့်စည်းမျဉ်းများကို တိကျစွာ ပြောပြရန် လိုသည်။

ပထမ prompt တွင် ထည့်ရမည့်အရာများ

အရာတစ်ခုခု ရေးမီ အောက်ပါ မေးခွန်းများကို ဖြေပါ။ တစ်ခုစီက AI က ခန့်မှန်းရမည့် ကွက်လပ်တစ်ခုကို ပိတ်ပေးသည်။

နောက်ဆုံးအတန်းသည် အလွန်လျစ်လျူရှုခံရသည်။ သင် မလိုချင်သော အရာကို ပြောခြင်းက AI က သင်မတောင်းသော blog၊ ဈေးနှုန်းစာမျက်နှာနှင့် newsletter signup ထည့်ခြင်းကို တားဆီးသည်။

Before နှင့် after- ပထမ prompt

Before:

ကျွန်ုပ်၏ ဂျင်မ်အတွက် app တစ်ခု ဖန်တီးပေးပါ။

builder က အရာအားလုံးကို ခန့်မှန်းရမည်- အဖွဲ့ဝင်များလား ဝန်ထမ်းများလား။ class လား personal training လား။ ငွေပေးချေမှုရှိလား။ လိုအပ်သည့်အရာနှင့် မဆိုင်သော gym website တစ်ခုကို ရလိမ့်မည်။

After:

သေးငယ်သော yoga studio အတွက် class booking app တစ်ခု တည်ဆောက်ပါ။ အဖွဲ့ဝင်များက ဒီအပတ်ရှိ class များကို ကြည့်နိုင်ရမည် (နာမည်၊ ဆရာ၊ အချိန်၊ နေရာကျန်)၊ နေရာ ကြိုတင်ဘွတ်နိုင်ရမည်၊ class မစတင်မီ နာရီ ၂ နာရီ အတွင်း ဖျက်နိုင်ရမည်။ အဖွဲ့ဝင်များက email နှင့် password ဖြင့် signup လုပ်သည်။ studio ပိုင်ရှင်က class ထည့်ရန်၊ ဘယ်သူ ဘွတ်ထားသလဲ ကြည့်ရန်နှင့် တက်ရောက်မှု မှတ်ရန် login ဝင်သည်။ class၊ အဖွဲ့ဝင်နှင့် ဘွတ်ကင်များကို database တွင် သိမ်းပါ။ ဖုန်းပေါ်တွင် ကောင်းစွာ အလုပ်လုပ်သော တိတ်ဆိတ်ပြီး အလင်းရောင်ရှိသော ဒီဇိုင်း။ ငွေပေးချေမှု ယခု မရှိသေးပါ။

ဒုတိယ version သည် ဆက်တိုက်တိုတောင်းသေးသည်။ အထက်ပါ ဇယားမှ မေးခွန်းများကို ဖြေထားခြင်းသာ ဖြစ်သည်။

အကောင်အထည်ဖော်ပုံမဟုတ်ဘဲ အပြုအမူကို ဖော်ပြပါ

မည်သို့ တည်ဆောက်ရမည်ထက် ဘာ ဖြစ်ရမည် ကို ဖော်ပြခြင်းဖြင့် ပိုကောင်းသော ရလဒ် မကြာခဏ ရနိုင်သည်။

Before:

bookings ကို ဆွဲယူသော useEffect နှင့် ပြင်ဆင်ရန် modal component ထည့်ပါ။

After:

ပိုင်ရှင်က booking တစ်ခုကို နှိပ်လျှင် အချိန်ပြောင်းနိုင်သော သို့မဟုတ် ဖျက်နိုင်သော panel ဖွင့်ပါ။ ပြောင်းလဲမှုများသည် စာရင်းတွင် ချက်ချင်း ပေါ်ရမည်။

ပထမ prompt က AI ကို အထူးနည်းပညာတစ်ခုသို့ ချိတ်ထားနိုင်ပြီး app ၏ ရေးပြီးသား code နှင့် မကိုက်ညီနိုင်ပါ။ ဒုတိယ prompt က ရလဒ်ကို ပြောပြပြီး ရေးပြီးသား code အတွက် သင့်တော်သော နည်းလမ်းကို AI ကို ရွေးခွင့်ပေးသည်။ သင် developer ဖြစ်ပြီး ပြင်းထန်သော နှစ်သက်မှု ရှိလျှင် ထိုအကြောင်း ပြောပါ၊ သို့သော် ရလဒ်နှင့် တွဲပြောပါ။

စည်းမျဉ်းများကို တိကျစွာ ပြောပါ

စီးပွားရေးစည်းမျဉ်းများသည် AI ဖြင့် တည်ဆောက်သော app များ မှားသည်များ အများဆုံး ဖြစ်သည်။ သင်အတွက် ရှင်းနေသော်လည်း AI အတွက် မမြင်ရသောကြောင့် ဖြစ်သည်။ အသေးစိတ် ရေးပါ။

• ကန့်သတ်ချက်များ: "အဖွဲ့ဝင်တစ်ယောက်က အနာဂတ် booking ၃ ခုအထိသာ ထားနိုင်သည်။"
• အချိန်: "ဖျက်ခြင်းကို class မစတင်မီ နာရီ ၂ နာရီတွင် ပိတ်သည်။"
• Edge case: "class ပြည့်နေလျှင် Book အစား waitlist ခလုတ် ပြပါ။"
• Permission: "ဆရာများက ကိုယ်ပိုင် class ၏ တက်ရောက်မှုကို မြင်နိုင်သည်၊ အခြားဆရာများကို မမြင်ရပါ။"

ဤတစ်ခုစီသည် ဝါကျတစ်ကြောင်းစီဖြစ်သည်။ တစ်ခုခု ချန်လှပ်ခဲ့လျှင် app က စည်းမျဉ်းကို မလိုက်နာနိုင်ပါ သို့မဟုတ် ကိုယ်ပိုင် ဗားရှင်း တီထွင်ပါလိမ့်မည်။

ပထမ version ပြီးနောက်- မက်ဆေ့ခ်ျတစ်ခုလျှင် ပြောင်းလဲမှု တစ်ခု

preview တွင် အရာတစ်ခု အလုပ်လုပ်ပြီးနောက် ထုတ်ကုန်တစ်ခုလုံးကို ဖော်ပြခြင်းမှ စစ်ဆေးနိုင်သော သေးငယ်သော ပြောင်းလဲမှုများ တောင်းခြင်းသို့ ပြောင်းပါ။

Before:

ဒီဇိုင်း မှားနေသည်၊ booking မှန်စွာ အလုပ်မလုပ်ပါ၊ ပြက္ခဒိန် view နှင့် အီးမေးလ်များ လိုချင်ပါသည်။

After (မက်ဆေ့ခ်ျ ၄ ခုခွဲ၍):

၁။ class တစ်ခု၏ နေရာနောက်ဆုံးတစ်ခုကို ဘွတ်လိုက်သောအခါ class သည် "နေရာ ၁ ခုကျန်" ဟု ဆက်ပြနေသည်။ "ပြည့်သည်" ဟု ပြပြီး Book ခလုတ်ကို ဝှက်ပါ။ ၂။ schedule စာမျက်နှာတွင် ရက်တစ်ရက်စီအတွက် column တစ်ခုစီဖြင့် အပတ်စဉ် ပြက္ခဒိန် view ထည့်ပါ။ လက်ရှိ list view ကို ရွေးချယ်မှုအဖြစ် ဆက်ထားပါ။ ၃။ ဖုန်းပေါ်တွင် class card များကို ပိုသေးငယ်စေပါ- padding လျှော့ပါ၊ ဆရာ၏အမည်ကို အချိန်နှင့် တူညီသော လိုင်းတွင် ထားပါ။ ၄။ အဖွဲ့ဝင်ဘွတ်သည့်အခါ အတည်ပြုအီးမေးလ် ပို့ပါ။

ဤနည်းလမ်း အလုပ်ဖြစ်ရခြင်း အကြောင်း:

• ပြောင်းလဲမှုတစ်ခုစီသည် AI က တစ်ကြိမ်တည်းဖြင့် မှန်အောင်လုပ်နိုင်လောက်အောင် သေးငယ်သည်။
• နောက်တစ်ခုသို့ မသွားမီ တစ်ခုစီကို စမ်းသပ်နိုင်သည်။
• တစ်ခုမှားသွားလျှင် အခြားအရာများ ဆုံးရှုံးခြင်းမရှိဘဲ အဆင့်တစ်ခုတည်းကို ပြန်လှည့်နိုင်သည်။

ထိန်းသိမ်းထားရမည့်အရာကို ပြောပါ

ရှိပြီးသား အလုပ်လုပ်နေသော အရာကို ပြောင်းရန် တောင်းသောအခါ ဘာမပြောင်းရမလဲ ကို AI အား ပြောပါ။ ဤသည်သည် regression (အရင်က အလုပ်လုပ်ခဲ့သော အရာ ပြင်ပြီးနောက် ပျက်ခြင်း) ကို တားဆီးရန် အလွယ်ဆုံးနည်း ဖြစ်သည်။

ပင်မ hero ကို ခေါင်းစဉ်ကြီးပြီး ဘယ်ဘက်ဆီတွင် ဓာတ်ပုံဖြင့် ပြန်ဒီဇိုင်းပါ။ navigation၊ အရောင်များနှင့် hero အောက်ရှိ အရာအားလုံးကို ယခုအတိုင်း ထားပါ။

ဤသည်သည် data အတွက်လည်း တူညီသည်- "members တွင် ဖုန်းနံပါတ် field ထည့်ပါ။ ရှိပြီးသား field များကို မဖျက်ပါနှင့်၊ အမည်မပြောင်းပါနှင့်။"

Screenshot နှင့် တိကျသော စာသား သုံးပါ

"အပေါ်ရှိအရာ" ကဲ့သို့ စကားလုံးများသည် မရှင်းလင်းပါ။ AI app builder အများစုသည် ပုံများကို လက်ခံပြီး screenshot နှင့် မှတ်ချက်တိုတစ်ခုသည် စာပိုဒ်ရှည်ထက် ပိုမြန်သည်။

• screenshot တစ်ခု ထည့်ပြီး "အနီရောင်ဝိုင်းထားသော ခလုတ်က ဖုန်းပေါ်တွင် menu ကို ထပ်နေသည်" ဟု ပြောပါ။
• error message ၏ စာသားကို အတိအကျ ကူးထည့်ပါ၊ အနက်ဖော်မဆွဲပါနှင့်။
• မျက်နှာပြင်ရှိ label များကို အတိအကျ ကိုးကားပါ- "Settings စာမျက်နှာရှိ Save changes ခလုတ်"။

bug များအတွက် အောက်ပါပုံစံကို သုံးပါ-

bookings စာမျက်နှာတွင် မနက်ဖြန် booking တစ်ခုအတွက် Cancel ကို နှိပ်ခဲ့သည်။ ၎င်း ကျွန်ုပ်၏ စာရင်းမှ ပျောက်သွားမည်ဟု မျှော်လင့်ခဲ့သည်။ သို့သော် ဘာမှမဖြစ်ဘဲ refresh လုပ်ပြီးနောက်လည်း booking ရှိနေသေးသည်။ ပြင်ပေးပြီး cancel အလုပ်လုပ်ကြောင်း စစ်ပါ။

AI ဖြင့် တည်ဆောက်ထားသော app ကို debug လုပ်နည်း လမ်းညွှန်တွင် ဤအကြောင်းကို ပိုမိုဖော်ပြထားသည်။

ကြီးမားသော ပြောင်းလဲမှုများအတွက် အရင် plan ချပါ

app ၏ အပိုင်းများစွာကို ထိခိုက်သော အရာများအတွက်- အကောင့်မရှိသော app တွင် user account ထည့်ခြင်း၊ ငွေပေးချေမှု ထည့်ခြင်း၊ data ဖွဲ့စည်းပုံ ပြောင်းခြင်း- code မပြောင်းမီ plan ကို တောင်းပါ။

အရာတစ်ခုမျှ မပြောင်းမီ team accounts ကို ဘယ်လိုထည့်မလဲ ရှင်းပြပါ- ဘယ် table အသစ်များ၊ ဘယ်စာမျက်နှာများ ပြောင်းမည်နှင့် ရှိပြီးသား အသုံးပြုသူများကို ဘာဖြစ်မလဲ။ code ကို ယခု မပြင်ပါနှင့်။

plan ကို ဖတ်ပါ။ AI က တစ်စုံတစ်ခုကို နားမလည်ခဲ့လျှင် ပြီးသော feature တစ်ခုကို ပြင်ရန်ထက် paragraph တစ်ခုကို ပြင်ရန် အလွန်ပိုသက်သာသည်။ builder များစွာတွင် ဤအတွက် အထူး mode ရှိသည်၊ Mythex တွင် ၎င်းသည် Plan mode ဖြစ်ပြီး Build နှင့် Ask နှင့် ဘေးချင်းယှဉ်ရှိသည်။

ရှောင်ရမည်များ

API key အကြောင်း- payment သို့မဟုတ် email ဝန်ဆောင်မှု လိုအပ်ပါက ၎င်း၏ key များကို prompt တွင် မထည့်ဘဲ project secrets တွင် ထည့်ပါ။ အသစ်ဖြစ်ပါက environment variable နှင့် secret ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။

ပြန်သုံးနိုင်သော prompt ပုံစံများ

ကွင်းစများရှိ အပိုင်းများကို အစားထိုးပြီး သုံးပါ။

App အသစ်:

[app အမျိုးအစား] ကို [ဘယ်သူ] အတွက် တည်ဆောက်ပါ။ သူတို့က [အဓိက စီးဆင်းမှု၊ အဆင့်လိုက်]။ [ဒုတိယ အသုံးပြုသူအမျိုးအစား] က [ဘာလုပ်ရန်] အတွက် login ဝင်သည်။ [data] ကို database တွင် သိမ်းပါ။ [ပုံစံနှင့် ခံစားချက်]။ [နောက်မှလုပ်မည့်အရာများ] ကို ထားခဲ့ပါ။

Feature အသစ်:

[စာမျက်နှာ] သို့ [feature] ထည့်ပါ။ [အသုံးပြုသူ] က [လုပ်ဆောင်ချက်] လုပ်သောအခါ [ဘာဖြစ်ရမည်]။ [ဘယ်သူ] သာ [ဘာလုပ်နိုင်သည်]။ ရှိပြီးသား [အရာများ] ကို ယခုအတိုင်း ထားပါ။

ဒီဇိုင်း ပြောင်းလဲမှု:

[စာမျက်နှာ] တွင် [တိကျသော element] ကို [တိကျသော ပြောင်းလဲမှု] သို့ ပြောင်းပါ။ [ထိန်းသိမ်းမည့်အရာ] ကို ထားပါ။ ဖုန်းအကျယ်ရှိ မျက်နှာပြင်တွင် မှန်ကန်စွာ ကြည့်ရသည်ကို စစ်ပါ။

Bug:

[စာမျက်နှာ] တွင် [အဆင့်များ] လုပ်ခဲ့သည်။ [မျှော်လင့်ချက်] ကို မျှော်လင့်ခဲ့သည်။ သို့သော် [ဖြစ်ခဲ့သည်၊ error စာသား အပါအဝင်]။ ပြင်ပြီး စီးဆင်းမှု အလုပ်လုပ်ကြောင်း စစ်ပါ။

ပြောင်းလဲမှု မပါဘဲ မေးခွန်း:

code မပြောင်းပါနှင့်။ app ၏ [အပိုင်း] ဘယ်လိုအလုပ်လုပ်သလဲ၊ [data] ကို ဘယ်နေရာတွင် သိမ်းသလဲ ရှင်းပြပါ။

ပိုရှည်သော spec ရေးခြင်း

ပိုကြီးသော project များအတွက် စာမျက်နှာတစ်ခုတည်းသော brief ကို ဦးစွာ ရေးပြီး ပထမ prompt အဖြစ် ကူးထည့်ခြင်းက ကူညီနိုင်သည်- အသုံးပြုသူများ၊ core စီးဆင်းမှုများ၊ data၊ စည်းမျဉ်းများနှင့် scope ပြင်ပ အရာများ။ AI ဖြင့် draft ရေးဖို့ပင် ကူညီနိုင်သည်၊ AI ဖြင့် PRD ရေးခြင်း လမ်းညွှန်တွင် ရှင်းပြထားသည်။ သို့သော် ပထမ build တောင်းဆိုချက်ကို core စီးဆင်းမှုသို့သာ ကန့်သတ်ပြီး ကျန်အရာများကို အဆင့်လိုက် ထည့်ပါ။

Mythex တွင် prompt ရေးခြင်း

အထက်ပါ အရာအားလုံး Mythex တွင် အလုပ်လုပ်သည်။ အထောက်အကူဖြစ်စေသော အချက်အချို့-

• Build၊ Plan နှင့် Ask mode များ။ ကြီးမားသော သို့မဟုတ် အန္တရာယ်ရှိသော ပြောင်းလဲမှုများအတွက် Plan ကို သုံးပါ၊ တည်းဖြတ်ခြင်းမရှိဘဲ ရှင်းပြချက် လိုချင်လျှင် Ask ကို သုံးပါ။
• Checkpoint များ။ ပြောင်းလဲမှု အောင်မြင်တိုင်း Mythex က checkpoint သိမ်းပြီး တုံ့ပြန်ချက်ပေါ်ရှိ Revert to this point က project ကို ပြန်လှည့်သည်။ ယခင် message ကို တည်းဖြတ်ပြီး ပြန်ပို့ခြင်းဖြင့် ထို အမှတ်မှ prompt အခြားပုံစံ စမ်းနိုင်သည်။
• Secrets card။ agent က API key လိုအပ်သောအခါ chat ထဲရှိ card မှတစ်ဆင့် မေးသည်၊ တန်ဖိုးကို သင့်စာတွင် မရေးဘဲ project secret အဖြစ် သိမ်းသည်။
• ပုံများ။ screenshot သို့မဟုတ် mockup ထည့်ပါက agent က ကြည့်သည်။

docs တွင် ထိရောက်သော prompt များ နှင့် ပြန်မတည်ဆောက်ဘဲ ပြင်ဆင်ခြင်း စာမျက်နှာများ ရှိသည်။ အစမှ စတင်ပါက AI ဖြင့် app တည်ဆောက်နည်း တွင် project တစ်ခုလုံး ရှင်းပြထားပြီး AI ဖြင့် ကြည့်ကောင်းသော app ဒီဇိုင်းနည်း တွင် visual ပြင်ဆင်ရန် prompt များ ပါဝင်သည်။

မေးခွန်းများ