Oldin internetdagi bir foydalanuvchi menga mening AI ishlab chiqish jarayonim qanday ekanini so‘ragan edi. Xuddi o‘tgan kunlarda AI yordamida kichkina bir funksiyani yaratdim, uni namoyish qilish uchun misol sifatida chiqarishga arziydi; shuningdek, bu sizga ham ma’lumot bo‘lishi mumkin.
Bu funksiyaning kelib chiqishi GitHub’ning Issues bo‘limida bir foydalanuvchining menga qoldirgan savoliga borib taqaladi (1-rasm). U mening BaoCut subtitr (subtitle) transkripsiya va tarjima ilovamga masofaviy transkripsiya funksiyasini qo‘shib bera olasanmi, deb so‘ragan.
Ya’ni menda ikkita kompyuter bor: bittasi — Nvidia grafik kartali, yuqori unumdor kompyuter A; ikkinchisi esa — kundalik ishlar uchun ishlatiladigan kompyuter B. Men kompyuter A ning hisoblash quvvatidan foydalanmoqchiman, lekin odatda B kompyuterda ishlayman. B’da BaoCut orqali transkripsiya qilayotganimda, hisoblash talab qiladigan transkripsiya ishini A kompyuter bajarib bersin.
Men buni juda yaxshi talab deb o‘yladim, lekin bunday ishni ilgari qilmaganman va umuman mumkinmi-yo‘qmi, bilmasdim.
Shuning uchun men birinchi qadam sifatida darhol kod yozishga o‘tmadim, avval imkoniyatlarni tahlil qildim.
1. Mumkinlik tahlili
Agar imkoniyatlarni tahlil qilmasdan bevosita kirishib ketilsa, qilgan mehnatim ko‘pincha behuda ketgan — bu meni juda ko‘p marta aldab ketgan. Bundan tashqari, tahlil qilinsa ham ba’zan noto‘g‘ri xulosa qilish mumkin. Masalan, bir necha kun oldin mahalliy matn modeli (local text model) yordamida ajratish va moslashtirishga ko‘mak beradigan kichik yechim qilgandim. Mumkinlik tahlili paytida bu yaxshi ko‘rinib ketgan, lekin tajriba qilish jarayonida natija juda yomon chiqdi. Oxir-oqibat baribir tashlab yubordim va bir necha kun vaqt yo‘qotdim, ustiga-ustak tokenlar ham ko‘p ketdi — yaxshi tomoni, bu faqat tokenlar xolos.
Mumkinlik tahlili odatda ikki darajada bo‘ladi:
Biri — mahsulot nuqtayi nazaridan: bu funksiya foydalanuvchilar uchun qanchalik qiymatga ega, u ilovaning maqsad/lokatsiyasiga mos keladimi.
Ikkinchisi — texnik nuqtayi nazardan: bu funksiya texnik jihatdan amalga oshadimi, xarajat nazorat ostidami.
Men bu yerda mahsulot nuqtayi nazaridan bu funksiya foydalanuvchilarga foydali va mahsulot yo‘nalishiga mos deb hisobladim. Shuning uchun faqat texnik mumkinlik tahliliga e’tibor qaratdim.
Claude Code ichiga asl talabni yubordim va uni loyihaning hozirgi holati bilan birga baholashini so‘radim (2-rasm). U tahlildan so‘ng amalga oshadi, degan xulosani berdi va bir nechta variant taklif qildi (3-rasm).
Bu variantlarni yaxshiroq tushunish uchun texnik fon kerak bo‘lishi mumkin, lekin men o‘qib chiqqanimdan keyin tezda o‘zimning xulosamni qildim:
Variant 0 va Variant C kodga o‘zgartirish kiritishni talab qilmaydi, ammo foydalanuvchi uchun juda noqulay: foydalanuvchi o‘zi asr serverni qurishi kerak bo‘ladi.
Variant A yaxshi ko‘rinadi: ilovani o‘rnatib, o‘zining transkripsiya xizmatini ishga tushirish yetarli.
Variant B Windows uchun qulay emas.
Shuning uchun men Variant A bo‘yicha davom etishga qaror qildim. Shuningdek, Variant 0 ishonchsiz bo‘lsa ham, u ichida mavjud bo‘lgan http transkripsiya API — qo‘shimcha foydali funksiyaga aylanib, yonma-yon qo‘shib olish mumkin.
2. Dizayn hujjati yozish
Mumkinlik tasdiqlanganidan va dastlabki texnik yechim aniqlangandan keyin ham men darhol kod yozishni boshlamadim — avval dizayn hujjatini yozdim.
Bu dizayn hujjati, aslida, mahsulot dizayni hujjati va texnik dizayn yechimining aralashmasiga o‘xshaydi: talablari, arxitektura dizayni va UI dizayn hujjatlari aralash tarzda tushuntiriladi.
Maqsad shuki, AI amalga oshirishda ishlatiladigan texnologiyalarni, ayni paytdagi loyihaning holatini — hammasini hujjatga yozib bersin. Shunda keyingi bosqichda amalga oshirish uchun yaxshi tayanch bo‘ladi, kelajakdagi texnik xizmatda ham referens sifatida ishlaydi. Eng muhimi — odam yo‘nalish to‘g‘rimi-yo‘qmi tasdiqlab olishi mumkin. (4-rasmga qarang)
Albatta, bu yerda men biroz dangasalik qildim: uni to‘liq hujjat qilib berib, keyin darhol ishga kirishdim. Asosan, oldin berilgan variantlarda katta muammo yo‘qdek tuyulgani uchun va Fable’ga ishonchim ham bor edi — imkon bo‘lsa yana ko‘proq tekshirgan bo‘lardim.
3. Prototip dizayni
Kod yozishdan oldin prototip qilishga sabab — prototip orqali talabni arzon narxda tezkor tekshirish, UI dizayn va interaksiyani tezroq aniq qilib olish. Bu yerda men baoyu-design skill’ni (github.com/jimliu/baoyu-design) o‘rnatganman, shuning uchun prototip dizayn deyishim bilan avtomatik ishga tushadi.
Ilovamda prototip dizayn uchun alohida sahifa bor: har safar funksiya qo‘shilganda yoki o‘zgartirilganda, avval prototip dizayn sahifasi yangilanadi.
Oldingi dizayn hujjatlari bo‘lgani uchun prototip qilish nisbatan oson kechdi. Birinchi versiya (5-rasm)ning o‘ziyoq yaxshi natija berdi: sozlamalar sahifasida yangi optsiya sahifasi qo‘shildi, unda xizmatni yoqish va node’larni aniqlash (topish) mumkin.
E’tibor bering: bu prototip dizayni aslida yuqori aniqlikdagi prototip bo‘lib, u prototip dizayn va UI dizaynni birlashtiradi — prototip aynan UI dizayn. Bu Claude Design’ning asosiy xususiyatlaridan biri.
Prototip tayyor bo‘lgandan keyin ham uni sozlash kerak bo‘ladi: bu paytda odam agentga prototip natijasi asosida feedback berishi va uni tuzatishga undashi zarur. Men bu yerda bir necha marta qayta-qayta sozlaganman. (6-rasmga qarang)
Avval joylashuvni Tab’ga o‘zgartirdim, xizmatni yoqish va boshqa node’larga ulanishni alohida qildim. Chunki men uchun bu ikki xil vaziyat. Yana belgi (ikonka) orqali xizmat holatini ko‘rsatdim: ikonka orqali xizmat ishga tushganmi yoki to‘xtaganmi aniq ko‘rinadi. (7-rasmga qarang)
Keyin uni sozlamalar sahifasiga qo‘yib qo‘yish qulay emasligini bildim, shuning uchun yana asosiy interfeysga ko‘chirdim. Nihoyat, yetarli darajada bo‘ldi degan qarorga keldim. (8-rasm, 9-rasm)
4. Amalga oshirish
Agar sizda dizayn hujjati va prototip (UI) tayyor bo‘lsa, AI’ning kod yozishi hozirgi Agentlar uchun juda oddiy ish.
Odatda bu paytda men /goal orqali hujjatlarni birga Claude Code’ga (Fable 5) yuboraman, u esa hujjatda belgilangan Milestones bo‘yicha ketma-ket amalga oshiradi. U natijani tekshirish uchun o‘zi ham screenshot olib beradi. (10-rasm, 11-rasm)
5. Sinov va tasdiqlash
Agent bizga tekshirishi mumkin, lekin bu AI natijasiga to‘liq ishonish mumkin degani emas. Keyingi qadamda ham bir necha bor qo‘lda ishga tushirib, topilgan muammolarni Agent’ga aytib, uni tuzattirib chiqish kerak (12-rasm).
Shuncha turdagi sozlashlardan keyin u deyarli ishlaydigan holatga keladi.
Yakuniy tayyor mahsulotni ko‘ring (13-rasm, 14-rasm).
Sizdan kodni Review qilganmanmi, deb so‘rasangiz?
Yo‘q. Men o‘zimni QA sifatida tutdim: faqat black-box test qildim. Shunga qaramay, men Fable’ning imkoniyatlariga ishonaman.
Bu funksiyaning kelib chiqishi GitHub’ning Issues bo‘limida bir foydalanuvchining menga qoldirgan savoliga borib taqaladi (1-rasm). U mening BaoCut subtitr (subtitle) transkripsiya va tarjima ilovamga masofaviy transkripsiya funksiyasini qo‘shib bera olasanmi, deb so‘ragan.
Ya’ni menda ikkita kompyuter bor: bittasi — Nvidia grafik kartali, yuqori unumdor kompyuter A; ikkinchisi esa — kundalik ishlar uchun ishlatiladigan kompyuter B. Men kompyuter A ning hisoblash quvvatidan foydalanmoqchiman, lekin odatda B kompyuterda ishlayman. B’da BaoCut orqali transkripsiya qilayotganimda, hisoblash talab qiladigan transkripsiya ishini A kompyuter bajarib bersin.
Men buni juda yaxshi talab deb o‘yladim, lekin bunday ishni ilgari qilmaganman va umuman mumkinmi-yo‘qmi, bilmasdim.
Shuning uchun men birinchi qadam sifatida darhol kod yozishga o‘tmadim, avval imkoniyatlarni tahlil qildim.
1. Mumkinlik tahlili
Agar imkoniyatlarni tahlil qilmasdan bevosita kirishib ketilsa, qilgan mehnatim ko‘pincha behuda ketgan — bu meni juda ko‘p marta aldab ketgan. Bundan tashqari, tahlil qilinsa ham ba’zan noto‘g‘ri xulosa qilish mumkin. Masalan, bir necha kun oldin mahalliy matn modeli (local text model) yordamida ajratish va moslashtirishga ko‘mak beradigan kichik yechim qilgandim. Mumkinlik tahlili paytida bu yaxshi ko‘rinib ketgan, lekin tajriba qilish jarayonida natija juda yomon chiqdi. Oxir-oqibat baribir tashlab yubordim va bir necha kun vaqt yo‘qotdim, ustiga-ustak tokenlar ham ko‘p ketdi — yaxshi tomoni, bu faqat tokenlar xolos.
Mumkinlik tahlili odatda ikki darajada bo‘ladi:
Biri — mahsulot nuqtayi nazaridan: bu funksiya foydalanuvchilar uchun qanchalik qiymatga ega, u ilovaning maqsad/lokatsiyasiga mos keladimi.
Ikkinchisi — texnik nuqtayi nazardan: bu funksiya texnik jihatdan amalga oshadimi, xarajat nazorat ostidami.
Men bu yerda mahsulot nuqtayi nazaridan bu funksiya foydalanuvchilarga foydali va mahsulot yo‘nalishiga mos deb hisobladim. Shuning uchun faqat texnik mumkinlik tahliliga e’tibor qaratdim.
Claude Code ichiga asl talabni yubordim va uni loyihaning hozirgi holati bilan birga baholashini so‘radim (2-rasm). U tahlildan so‘ng amalga oshadi, degan xulosani berdi va bir nechta variant taklif qildi (3-rasm).
Bu variantlarni yaxshiroq tushunish uchun texnik fon kerak bo‘lishi mumkin, lekin men o‘qib chiqqanimdan keyin tezda o‘zimning xulosamni qildim:
Variant 0 va Variant C kodga o‘zgartirish kiritishni talab qilmaydi, ammo foydalanuvchi uchun juda noqulay: foydalanuvchi o‘zi asr serverni qurishi kerak bo‘ladi.
Variant A yaxshi ko‘rinadi: ilovani o‘rnatib, o‘zining transkripsiya xizmatini ishga tushirish yetarli.
Variant B Windows uchun qulay emas.
Shuning uchun men Variant A bo‘yicha davom etishga qaror qildim. Shuningdek, Variant 0 ishonchsiz bo‘lsa ham, u ichida mavjud bo‘lgan http transkripsiya API — qo‘shimcha foydali funksiyaga aylanib, yonma-yon qo‘shib olish mumkin.
2. Dizayn hujjati yozish
Mumkinlik tasdiqlanganidan va dastlabki texnik yechim aniqlangandan keyin ham men darhol kod yozishni boshlamadim — avval dizayn hujjatini yozdim.
Bu dizayn hujjati, aslida, mahsulot dizayni hujjati va texnik dizayn yechimining aralashmasiga o‘xshaydi: talablari, arxitektura dizayni va UI dizayn hujjatlari aralash tarzda tushuntiriladi.
Maqsad shuki, AI amalga oshirishda ishlatiladigan texnologiyalarni, ayni paytdagi loyihaning holatini — hammasini hujjatga yozib bersin. Shunda keyingi bosqichda amalga oshirish uchun yaxshi tayanch bo‘ladi, kelajakdagi texnik xizmatda ham referens sifatida ishlaydi. Eng muhimi — odam yo‘nalish to‘g‘rimi-yo‘qmi tasdiqlab olishi mumkin. (4-rasmga qarang)
Albatta, bu yerda men biroz dangasalik qildim: uni to‘liq hujjat qilib berib, keyin darhol ishga kirishdim. Asosan, oldin berilgan variantlarda katta muammo yo‘qdek tuyulgani uchun va Fable’ga ishonchim ham bor edi — imkon bo‘lsa yana ko‘proq tekshirgan bo‘lardim.
3. Prototip dizayni
Kod yozishdan oldin prototip qilishga sabab — prototip orqali talabni arzon narxda tezkor tekshirish, UI dizayn va interaksiyani tezroq aniq qilib olish. Bu yerda men baoyu-design skill’ni (github.com/jimliu/baoyu-design) o‘rnatganman, shuning uchun prototip dizayn deyishim bilan avtomatik ishga tushadi.
Ilovamda prototip dizayn uchun alohida sahifa bor: har safar funksiya qo‘shilganda yoki o‘zgartirilganda, avval prototip dizayn sahifasi yangilanadi.
Oldingi dizayn hujjatlari bo‘lgani uchun prototip qilish nisbatan oson kechdi. Birinchi versiya (5-rasm)ning o‘ziyoq yaxshi natija berdi: sozlamalar sahifasida yangi optsiya sahifasi qo‘shildi, unda xizmatni yoqish va node’larni aniqlash (topish) mumkin.
E’tibor bering: bu prototip dizayni aslida yuqori aniqlikdagi prototip bo‘lib, u prototip dizayn va UI dizaynni birlashtiradi — prototip aynan UI dizayn. Bu Claude Design’ning asosiy xususiyatlaridan biri.
Prototip tayyor bo‘lgandan keyin ham uni sozlash kerak bo‘ladi: bu paytda odam agentga prototip natijasi asosida feedback berishi va uni tuzatishga undashi zarur. Men bu yerda bir necha marta qayta-qayta sozlaganman. (6-rasmga qarang)
Avval joylashuvni Tab’ga o‘zgartirdim, xizmatni yoqish va boshqa node’larga ulanishni alohida qildim. Chunki men uchun bu ikki xil vaziyat. Yana belgi (ikonka) orqali xizmat holatini ko‘rsatdim: ikonka orqali xizmat ishga tushganmi yoki to‘xtaganmi aniq ko‘rinadi. (7-rasmga qarang)
Keyin uni sozlamalar sahifasiga qo‘yib qo‘yish qulay emasligini bildim, shuning uchun yana asosiy interfeysga ko‘chirdim. Nihoyat, yetarli darajada bo‘ldi degan qarorga keldim. (8-rasm, 9-rasm)
4. Amalga oshirish
Agar sizda dizayn hujjati va prototip (UI) tayyor bo‘lsa, AI’ning kod yozishi hozirgi Agentlar uchun juda oddiy ish.
Odatda bu paytda men /goal orqali hujjatlarni birga Claude Code’ga (Fable 5) yuboraman, u esa hujjatda belgilangan Milestones bo‘yicha ketma-ket amalga oshiradi. U natijani tekshirish uchun o‘zi ham screenshot olib beradi. (10-rasm, 11-rasm)
5. Sinov va tasdiqlash
Agent bizga tekshirishi mumkin, lekin bu AI natijasiga to‘liq ishonish mumkin degani emas. Keyingi qadamda ham bir necha bor qo‘lda ishga tushirib, topilgan muammolarni Agent’ga aytib, uni tuzattirib chiqish kerak (12-rasm).
Shuncha turdagi sozlashlardan keyin u deyarli ishlaydigan holatga keladi.
Yakuniy tayyor mahsulotni ko‘ring (13-rasm, 14-rasm).
Sizdan kodni Review qilganmanmi, deb so‘rasangiz?
Yo‘q. Men o‘zimni QA sifatida tutdim: faqat black-box test qildim. Shunga qaramay, men Fable’ning imkoniyatlariga ishonaman.