ဆောင်းပါးများ
AI အသုံးပြုမှု၏ မျက်နှာကျက်သည် သင့်ရည်မှန်းချက်ပင်ဖြစ်သည်- အရှိန်၊ အမြင့်၊ အနက်နှင့် အကျယ် ဟူသော ရှုထောင့်လေးခု
Anthropic ၏ engineering lead ဖြစ်သူ Felix Rieseberg သည် "AI နှင့်ပတ်သက်၍ ပိုမိုရည်မှန်းချက်ကြီးခြင်း" ကို အရှိန်၊ အမြင့်၊ အနက်၊ အကျယ် ဟူသော ရှုထောင့်လေးခုအဖြစ် ခွဲခြားထားသည်။ ဤဆောင်းပါးတွင် သူ၏နည်းလမ်းများနှင့် ဥပမာများကို စုစည်းထားပြီး ကျွန်ုပ်ကိုယ်တိုင်၏ လက်တွေ့အသုံးချမှတ်စုများလည်း ပါဝင်သည်- ရည်မှန်းချက်ကို ဗဟိုပြုသော ညွှန်ကြားချက်များပေးပြီး Multi-AI Agents ကျွမ်းကျင်သူအဖွဲ့ကို ရှုထောင့်ပေါင်းစုံမှ ဖြတ်ကျော်ပြန်လည်စစ်ဆေးစေကာ အလုပ်၏အရည်အသွေးကို မြှင့်တင်ခြင်း။
· 1 မိနစ် ဖတ်ရန်
Anthropic ၏ engineering lead ဖြစ်သူ Felix Rieseberg သည် "How to be more ambitious: A tutorial for humans with models" ဆောင်းပါးတွင် အခြားသူများ AI ဖြင့် အံ့မခန်းရလဒ်များ ထုတ်လုပ်သည်ကို မြင်ရသောအခါ သူနှင့် သူ့ပတ်ဝန်းကျင်လူများတွင် တူညီသောတုံ့ပြန်မှုတစ်ခု ရှိတတ်သည်ဟု ဖော်ပြထားသည်- "ကျွန်ုပ်တို့ ရည်မှန်းချက် မလုံလောက်သေးဘူး။"
ကျွန်ုပ်၏ အနက်ဖွင့်ချက်မှာ လူသားများ AI အသုံးပြုမှု၏ မျက်နှာကျက်သည် မော်ဒယ်မဟုတ်ဘဲ မိမိကိုယ်ပိုင် ရည်မှန်းချက်နှင့် စိတ်ကူးစိတ်သန်းတွင် မကြာခဏ ပိတ်မိနေတတ်သည်။
သူက "ရည်မှန်းချက်" ကို ရှုထောင့်လေးခုအဖြစ် ခွဲခြားသည်-
- အရှိန် (Speed): အလုပ်တူတူကို အချိန်တိုတိုဖြင့် ပြီးစီးစေခြင်း။
- အမြင့် (Altitude): စိတ္တဇအဆင့်ကို မြှင့်တင်ပြီး တစ်ခုတည်းသော တာဝန်ကို မကြည့်ဘဲ နောက်ဆုံးရလဒ်ကို ကြည့်ခြင်း။
- အနက် (Depth): ထိုနယ်ပယ်ရှိထိပ်တန်းကျွမ်းကျင်သူများ၏ စံနှုန်း၊ကိရိယာနှင့် နည်းလမ်းများဖြင့် လုပ်ဆောင်ခြင်း။
- အကျယ် (Range): နယ်ပယ်တစ်ခုတည်းမှ ထွက်ပြီး နယ်ပယ်ကျော် ဖြေရှင်းချက်ရှာခြင်း။
နိဂုံးကို အရင်ပြောရလျှင်- ရည်မှန်းချက်ကို ဗဟိုပြုသော ညွှန်ကြားချက်များကို တိကျစွာပေးပြီး Multi-AI Agents ကျွမ်းကျင်သူအဖွဲ့ကို ရှုထောင့်ပေါင်းစုံမှ ပူးပေါင်းဆောင်ရွက်ကာ ဖြတ်ကျော်ပြန်လည်စစ်ဆေးစေမှသာ အလုပ်အရည်အသွေး ခြုံငုံမြင့်တက်လာမည်။
တစ်၊ အရှိန်- အခြေခံအကျဆုံးဖြစ်ပြီး အတားအဆီးအနည်းဆုံး#
အလုပ်တူတူကို အချိန်တိုတိုဖြင့် ပြီးစီးစေခြင်း။ Felix က ဤအချက်ကို လူတိုင်း ရင်းနှီးပြီးသားဟု ယူဆသဖြင့် ဆောင်းပါးတွင် တိုက်ရိုက်ကျော်သွားသည်။
ကျွန်ုပ်၏ အမြင်- အရှိန်သည် AI ၏ အတိုက်ရိုက်မြင်ရဆုံး တန်ဖိုးဖြစ်သော်လည်း အရှိန်တစ်ခုတည်းကိုသာ လိုက်လျှင် ပူးပေါင်းဆောင်ရွက်ပုံ အများကြီး မပြောင်းလဲပါ။ အမှန်တကယ် ကွာခြားမှုဖန်တီးသည်မှာ နောက်ရှုထောင့်သုံးခုဖြစ်သည်။
နှစ်၊ အမြင့်- "ရည်မှန်းချက်နောက်ကွယ်က ရည်မှန်းချက်" ကို မေးပါ#
အဓိကမေးခွန်း- ကျွန်ုပ် အမှန်တကယ်လိုချင်သော နောက်တစ်ဆင့်ရလဒ်က ဘာလဲ။ ဤရည်မှန်းချက်နောက်ကွယ်က ရည်မှန်းချက်က ဘာလဲ။
Felix ၏ ဥပမာများ-
- Crash တစ်ခုကို ပြင်ခြင်းမှ App ကို Crash မဖြစ်စေခြင်းသို့။ အရင်က သူသည် Claude ကို Crash တစ်ခုတည်းကိုသာ ပြင်ခိုင်းခဲ့ပြီး နောက်ပိုင်းတွင် App ကို zero Crash ဖြစ်အောင် ထိန်းထားရန် တောင်းဆိုမှုကို ပြောင်းခဲ့သည်။ ဤအရာကို အလိုအလျောက် ဆက်တိုက်လည်ပတ်စေရန် သူသည် မိမိ၏လုပ်ငန်းစဉ်ကို ဦးစွာ ပြောင်းရသည်- Crash report များကို လွယ်လွယ်ရရှိစေရန်၊ App ဗားရှင်းကို Git Commit နှင့် တိုက်ဆိုင်ချိတ်ဆက်ရန်၊ Claude အား Windows, macOS, Linux စက်များသုံး၍ ပြင်ဆင်မှုကို ပြန်လည်ဖြစ်ပေါ်စေပြီး အတည်ပြုခွင့်ပေးရန်။
- သုံးလပတ်စီးပွားရေးသုံးသပ်ချက် (QBR) ကို အဆင့်သုံးဆင့်ဖြင့် မြှင့်တင်ခြင်း-
- ဤသုံးလပတ်တွင် ဘာပြောင်းလဲသည်၊ ဘာကြောင့်ဖြစ်သည်၊ နောက်ထပ်ဘာလုပ်သင့်သည်ကို ရှင်းပြရန် ဒေတာအကြမ်းကို တတ်နိုင်သမျှ အသုံးပြုပါ။
- အလျင်စလိုဆုံး ဆုံးဖြတ်ချက် 3 ခုကို ရှာပြီး တစ်ခုချင်းစီအတွက် ထောက်ခံသည့်နှင့် ကန့်ကွက်သည့် ငြင်းခုံချက်များ ရေးပါ။
- သုံးလပတ်တင်ပြမှုထက် ပြဿနာကို ပိုစောစီးစွာ တွေ့ရှိနိုင်သော အစားထိုးယန္တရားတစ်ခု ဒီဇိုင်းဆွဲပြီး သမိုင်းဒေတာဖြင့် စမ်းသပ်ကာ လက်ရှိလုပ်ငန်းစဉ်နှင့် တစ်ပြိုင်နက် သုံးလပတ်ကာလ ပြေးကြည့်ပါ။
သူက နယ်နိမိတ်အကြောင်းကိုလည်း သတိပေးသည်- 2026 ခုနှစ်တွင် "Claude၊ ငါ့အတွက် ပိုက်ဆံသွားရှာပေး" ကဲ့သို့ မရှင်းလင်းသော ရည်မှန်းချက်များ မရသေးသော်လည်း မော်ဒယ်များ ကိုင်တွယ်နိုင်သော စိတ္တဇအဆင့်သည် ဆက်လက်မြင့်တက်လာမည်ဟု သူမျှော်လင့်သည်။
သုံး၊ အနက်- နယ်ပယ်ရှိ ထိပ်တန်းကျွမ်းကျင်သူများ၏ စံနှုန်းအတိုင်း#
Felix ၏နည်းလမ်း-
- ထိုလုပ်ငန်းက အမှန်တကယ်သုံးသော ကိရိယာများကို သုံးပါ။ မော်ဒယ်သည် စကားလုံးကိုသာ ပြောင်းပြီး နည်းလမ်းကို မပြောင်းတတ်ဘဲ Markdown ဇယားတစ်ခုပေးကာ အပြီးသတ်တတ်သည်။ ဒေတာဘေ့စ်နှင့် စာရင်းအင်းမော်ဒယ်ကဲ့သို့ အမှန်တကယ် ခွဲခြမ်းစိတ်ဖြာရေးကိရိယာများကို အတင်းအကျပ် သုံးခိုင်းပါ။
- မဖြစ်နိုင်ဟု ထင်ရသော ပန်းတိုင်ကို သတ်မှတ်ပြီး ဖြေရှင်းနိုင်သည်ဟု မော်ဒယ်ကိုပြောပါ။ သူ၏ဥပမာ- ဝက်ဘ်ဆိုက် loading ကို 10 စက္ကန့်မှ 5 စက္ကန့်သို့ လျှော့ပြီးနောက် 200 မီလီစက္ကန့်ကို ဆက်တောင်းဆိုခြင်း။ မော်ဒယ်နောက်ဆုတ်သည့်အခါ ဤပန်းတိုင်ကို ရောက်နိုင်သည်ဟု ခိုင်ခိုင်မာမာ ဆက်ပြောပါ။
- မိမိယုံကြည်ထားသော ယူဆချက်များကို စိန်ခေါ်ပါ။ မော်ဒယ်ကို ဒေတာအကြမ်းပေးပြီး ဆန့်ကျင်ဘက်ရှုထောင့်မှ စစ်ဆေးခိုင်းပါ။ ဥပမာ- "အသုံးပြုသူများ စွန့်ခွာရခြင်း၏ အကြောင်းရင်းမှာ onboarding ဟု ကျွန်ုပ်တို့ထင်သည်၊ ဒေတာအကြမ်းမှ ဤနိဂုံးကို ပြန်လည်ဖန်တီးကြည့်ပါ။"
- ဗဟုသုတအသစ် ဖန်တီးပါ။ Logs မှ simulation တည်ဆောက်ပြီး သင်မသိသေးသော စွန့်ခွာမှု၏ အစောဆုံးအချက်ပြကို ရှာကာ မမြင်ဖူးသေးသောဒေတာဖြင့် အတည်ပြုပါ။
- ပြင်ပတရားသူကြီး (Outside Judge) ရှာပါ။ မော်ဒယ်ကို ကိုယ့်ကိုယ်ကိုယ် မစစ်ခိုင်းပါနှင့်။ မော်ဒယ်ကိုယ်တိုင် run နိုင်ပြီး ချက်ချင်း တုံ့ပြန်ချက်ရနိုင်သော ကိရိယာတစ်ခုကို ချိတ်ဆက်ပေးခြင်းက အကောင်းဆုံးဖြစ်သည်။
သူ၏ Prompt စည်းမျဉ်းမှာ တောင်းရမည့်အရာသည် "ပိုကြီးသော ဗားရှင်း" မဟုတ်ဘဲ "ပိုနက်သော ဗားရှင်း" ဖြစ်သည်။ ထိပ်တန်းပညာရှင်က ထပ်လုပ်မည့်အရာ၊ အမူလအကြမ်းဆုံးဒေတာ ဘယ်မှာရှိသည်၊ ဘာနည်းလမ်းနှင့် ကိရိယာများ သုံးမည်၊ မော်ဒယ် သို့မဟုတ် သင့်ဆုံးဖြတ်ချက်မှလွဲ၍ ရလဒ်မှန်ကန်ကြောင်း သက်သေပြနိုင်သည့်အရာ ဘာရှိသေးသည်ကို မော်ဒယ်အား ပြောခိုင်းပါ။
လေး၊ အကျယ်- နာမ်အစား ကြိယာသုံးပြီး ကျွမ်းကျင်သူအဖွဲ့ ဖွဲ့စည်းပါ#
- နာမ်အစား ကြိယာ။ ဤအယူအဆကို Felix က The Art of Innovation မှ ကိုးကားထားသည်။ QBR သည် "ဆလိုက်တစ်စုံ" မဟုတ်ဘဲ "မိနစ် 30 အတွင်း အလုပ်များသူများ အကြောင်းနှင့်အကျိုးကို နားလည်ပြီး မသေချာမှုအလယ်တွင် ဆုံးဖြတ်နိုင်စေခြင်း" ဖြစ်သည်။ ရည်မှန်းချက်ကို ကြိယာဖြင့် သတ်မှတ်လိုက်သောအခါ ဘယ်နယ်ပယ်များမှ စွမ်းရည်များ လိုအပ်သည်ကို မြင်လာမည်။
- အဖွဲ့ဖွဲ့ပါ။ ကောင်းမွန်သော ဆလိုက်များ ပြုလုပ်လိုလျှင် လေ့လာသုံးသပ်သူ၊ သတင်းထောက်နှင့် အယ်ဒီတာကို ရှာပါ။ စင်ပေါ်တင်ပြလိုလျှင် motion နှင့် အသံ ဒီဇိုင်နာများ ထပ်ထည့်ပါ။ ဆန့်ကျင်ဘက်ပြန်လည်စစ်ဆေးမှု လုပ်လိုလျှင် short-selling ကုမ္ပဏီ၏ သုတေသီနှင့် forensic စာရင်းကိုင်ကို ရှာပါ။
- အဓိပ္ပာယ်မဲ့ အခန်းကဏ္ဍသရုပ်ဆောင်ခြင်း မလုပ်ပါနှင့်။ မော်ဒယ်ကို "short-selling ကုမ္ပဏီ၏ လေသံဖြင့် ရေးပါ" ဟု မခိုင်းဘဲ short-selling ကုမ္ပဏီ၏ သုတေသနနည်းလမ်းကို အလုပ်၏အစိတ်အပိုင်းတစ်ခုတွင် အမှန်တကယ် အကောင်အထည်ဖော်စေပါ။ လေသံတစ်ခုတည်း ပြောင်းလျှင် ရလဒ် ပိုမကောင်းလာပါ။
ကြိုတင်လိုအပ်ချက်မှာ- မော်ဒယ်တွင် software ထည့်သွင်းနိုင်သော ကွန်ပျူတာတစ်လုံးရှိရမည်ဖြစ်ပြီး MCP connector ကဲ့သို့သော နည်းလမ်းများဖြင့် သက်ဆိုင်ရာဒေတာကို ရယူနိုင်ရမည်။
ငါး၊ ကျွန်ုပ်၏ လက်တွေ့အသုံးချမှတ်စု- "ဒေတာပေးပို့ခြင်း" မှ "ရည်ရွယ်ချက်ပြည့်မီခြင်း" သို့#
အောက်ပါအပိုင်းသည် software architecture နှင့် အင်ဂျင်နီယာလက်တွေ့ကို ပေါင်းစပ်ထားသော ကျွန်ုပ်ကိုယ်ပိုင်တိုးချဲ့ချက်ဖြစ်ပြီး မူရင်းဆောင်းပါး၏ အကြောင်းအရာ မဟုတ်ပါ။
1. Jobs to be Done နှင့် Intent-Based#
- "ဘာလုပ်မလဲ" မမေးဘဲ "ဘာပြည့်မီမလဲ" ကို မေးပါ။ ဒီဇိုင်းသည်
generate_deck_pdf() ကဲ့သို့ လှုပ်ရှားမှုမရှိသော ဒေတာပေးပို့ရေး pipeline တွင် မရပ်သင့်ဘဲ resolve_leadership_uncertainty_and_commit_budget() ကဲ့သို့ အခြေအနေပြောင်းလဲမှု၏ ရည်ရွယ်ချက်အဆင့်သို့ မြှင့်တင်သင့်သည်။
- အစစ်အမှန် loss function ကို သတ်မှတ်ပါ။ ထုတ်ကုန်ကိုသာ တောင်းလျှင် မော်ဒယ်သည် အပြည့်အစုံဟု ထင်ရသော်လည်း အနှစ်သာရမရှိသော စာသားကို ထုတ်ပေးမည်၊ ဆုံးဖြတ်ချက်၏ မသေချာမှုကို ဖြေရှင်းရန် တောင်းလျှင်သာ မော်ဒယ်နှင့် Sub-agent များက ယုတ္တိဗေဒအပေါက်များနှင့် အန္တရာယ်နယ်နိမိတ်များကို ကိုယ်တိုင်ဖြည့်ပေးမည်။
2. စူးစမ်းချိန်တွင် ဖြန့်ပါ၊ လက်ခံချိန်တွင် စုပါ#
- စူးစမ်းချိန်တွင် ဖြစ်နိုင်ခြေများ ရှာရန် အရင်ဖြန့်ပြီးမှ စုပါ။
- လက်ခံစစ်ဆေးချိန်တွင် ထပ်မဖြန့်ပါနှင့်။ "ဒါကို တခြားဘယ်လိုလုပ်လို့ရသေးလဲ" ကဲ့သို့ နယ်နိမိတ်မရှိသော မေးခွန်းများကို ရှောင်ပါ၊ ယေဘုယျအဖြေများသာ ရလိမ့်မည်။
- ရည်မှန်းချက်နယ်ပယ်၊ ကန့်သတ်ချက်များနှင့် ဓမ္မဓိဋ္ဌာန်ကျသော စစ်ဆေးရေးကိရိယာများကို ရှင်းရှင်းလင်းလင်း ရေးပါ (သီးသန့် test script၊ စီးပွားရေးညွှန်ကိန်း အတိုင်းအတာ) ထိုမှသာ Multi-Agent အဖွဲ့က အာရုံစိုက်ထားသော ဘောင်အတွင်း stress test လုပ်ပြီး အရည်အသွေးမြင့် ရလဒ်ပေးနိုင်မည်။
မှတ်စုအနှစ်ချုပ်#
- ရည်မှန်းချက်ဗဟိုပြု- နာမ်အစား ကြိယာ။ တာဝန်လွတ်ရုံသက်သက် ထုတ်ကုန်မဟုတ်ဘဲ ပြဿနာဖြေရှင်းပေးသော ရလဒ်ကို ပေးအပ်ပါ။
- စူးစမ်းခြင်းနှင့် စုစည်းခြင်း- စူးစမ်းချိန်တွင် ဖြစ်နိုင်ခြေရှာရန် ဖြန့်ပါ၊ လက်ခံစစ်ဆေးချိန်တွင် နယ်နိမိတ်စစ်ရန် တင်းကျပ်စွာ စုပါ။
- စိတ္တဇအာရုံစိုက်မှု- အဓိကမေးခွန်းမှ စတင်ပြီး အလုပ်စီးဆင်းမှုတစ်ခုလုံးကို ပြန်လည်တည်ဆောက်ပါ။
- ကျွမ်းကျင်သူအနက်- ကျွမ်းကျင်သူ၏ လေသံကို အတုယူရုံသာမက မော်ဒယ်ကို ထိပ်တန်းကျွမ်းကျင်သူများ၏ ကိရိယာနှင့် နည်းလမ်းများဖြင့် ပြဿနာဖြေရှင်းစေရန် တွန်းအားပေးပါ။
မူရင်းဆောင်းပါး: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)