मार्गदर्शक

AI ने बनवलेले ॲप न मोडता कसे सुधारायचे

AI ने बनवलेले ॲप न मोडता सुधारण्यासाठी, प्रत्येक प्रॉम्प्टमध्ये एकच गोष्ट बदला, प्रीव्ह्यूमध्ये तपासा, आणि पुढे जाण्यापूर्वी चेकपॉइंट सेव्ह करा. तुम्हाला कोड काय करतो असे वाटते त्याऐवजी तुम्हाला काय दिसते ते वर्णन करा, मोठे बदल बांधण्यापूर्वी त्याचे नियोजन करा, आणि एखादा बदल चुकला तर AI ला स्वतःच्या दुरुस्तीची दुरुस्ती करायला सांगण्याऐवजी शेवटच्या चांगल्या आवृत्तीवर रोलबॅक करा.

पहिली आवृत्ती अनेकदा काही मिनिटांत तयार होते. कठीण भाग पन्नासावा बदल असतो, जेव्हा प्रत्येक नव्या प्रॉम्प्टमुळे आधीपासून चालणारे काहीतरी मोडण्याचा धोका असतो. हे मार्गदर्शक तो प्रकार टाळणारी लूप शिकवते.

पुनरावृत्तीची लूप

  1. एक बदल निवडा. एक फीचर, एक बग, एक पेज.
  2. त्याचे वर्णन करा, वापरकर्त्याला काय दिसते आणि काय करतो या दृष्टीने.
  3. मोठ्या बदलांसाठी आधी नियोजन करा. नियोजन मागा, ते वाचा, मग बांधा.
  4. प्रीव्ह्यूमध्ये निकाल तपासा — बदल आणि त्याच्या जवळचे प्रवाह.
  5. सेव्ह करा चेकपॉइंट किंवा कमिट.
  6. पुन्हा करा.

प्रत्येक पायरी बदल लहान आणि उलटवता येण्याजोगे ठेवण्यासाठी आहे.

पायरी 1: एक लहान यादी ठेवा

प्रॉम्प्ट करण्यापूर्वी, तुम्हाला काय बदलायचे आहे ते महत्त्वाच्या क्रमाने लिहा. त्यामुळे एका संदेशात दहा इच्छांचा परिच्छेद पाठवणे टाळता येते, आणि मध्येच येणाऱ्या कल्पनांना "आत्ता नाही" म्हणण्याचा मार्ग मिळतो.

बदल मोठा असेल तर त्याचे तुकडे करा. "टीम अकाउंट्स जोडा" हे बनते: टीम तयार करा, सदस्याला आमंत्रित करा, टीम्समध्ये बदला, डेटा सध्याच्या टीमपुरता मर्यादित करा. प्रत्येक स्वतंत्र प्रॉम्प्ट आहे. वापरकर्ता कथा कशा लिहायच्या हा हे करण्याचा चांगला मार्ग आहे.

पायरी 2: तुम्हाला काय दिसते ते वर्णन करा

तुम्ही सांगितल्याशिवाय AI तुमची स्क्रीन पाहू शकत नाही. विशिष्ट गोष्टींकडे निर्देश करा आणि काय घडले पाहिजे ते सांगा:

फोनवर प्राइसिंग पेजवर Pro कार्डचे बटण उजव्या कडेला कापले जाते. डेस्कटॉप लेआउट तसाच ठेवा; 640px पेक्षा कमी स्क्रीनवर कार्ड्स एकावर एक रचा आणि बटणे पूर्ण रुंदीची करा.

याची तुलना "प्राइसिंग पेज मोबाइलवर वाईट दिसते" या वाक्याशी करा. पहिले एका फेरीत करता आणि तपासता येते; दुसरे तुम्ही न मागितलेल्या पुनर्रचनेला आमंत्रण देते.

स्क्रीनशॉट्स मदत करतात. तुमचा बिल्डर इमेजेस स्वीकारत असेल, तर एक जोडा आणि समस्येभोवती वर्तुळ काढा.

पायरी 3: मोठ्या बदलांपूर्वी नियोजन करा

ॲपच्या अनेक भागांना स्पर्श करणाऱ्या कोणत्याही गोष्टीसाठी — नवे डेटा मॉडेल, पेमेंट्स, वापरकर्ता भूमिका — कोणताही कोड बदलण्यापूर्वी नियोजन मागा:

अजून कोड बदलू नका. मला वापरकर्ते टीम्समध्ये असावेत आणि त्यांना फक्त त्यांच्या टीमचे प्रोजेक्ट्स दिसावेत. बदलाचे नियोजन करा: कोणते टेबल्स, पेजेस आणि API राउट्स बदलतात, विद्यमान वापरकर्त्यांच्या डेटाचे काय होते, आणि तुम्ही कोणत्या क्रमाने बांधाल.

नियोजन वाचा. ते चुकीचे असेल तर, नियोजन दुरुस्त करणे बांधलेले काही उलटवण्यापेक्षा खूप स्वस्त आहे.

पायरी 4: काय बदलायचे नाही ते सांगा

AI साधने कधीकधी तुम्ही न मागितलेल्या गोष्टी "नीटनेटक्या" करतात. जे काम करते त्याचे संरक्षण करा:

ऑर्डर्स टेबलमध्ये तारीख फिल्टर जोडा. टेबलचे कॉलम्स, स्टायलिंग किंवा एक्स्पोर्ट बटण बदलू नका.

सर्वत्र लागू होणाऱ्या नियमांसाठी — ब्रँड रंग, बोलण्याची शैली, "पुष्टीशिवाय कधीही डेटा हटवू नका" — त्यांना प्रोजेक्ट नोट्स फाइल किंवा ज्ञान सेटिंगमध्ये ठेवा, जे AI प्रत्येक वेळी वाचते, प्रत्येक वेळी पुनरावृत्ती करण्याऐवजी.

पायरी 5: बदलापेक्षा जास्त तपासा

प्रत्येक प्रॉम्प्टनंतर, तपासा:

  • बदल स्वतः. तुम्ही मागितल्याप्रमाणे तो डेस्कटॉप आणि फोनवर काम करतो का?
  • शेजारचे भाग. त्याच पेजवरील गोष्टी, आणि त्याच डेटाचा वापर करणारे प्रवाह.
  • महत्त्वाचा मार्ग. साइन अप, लॉग इन, मुख्य कृती, पेमेंट. प्रत्येक मोठ्या बदलानंतर तीस सेकंदांची तपासणी बहुतेक मोडतोड लवकर पकडते.

काही चुकत असेल तर अचूकपणे नोंदवा — चांगला बग रिपोर्ट कसा लिहायचा पहा.

पायरी 6: भर घालण्याऐवजी रोलबॅक करा

बदलाने काहीतरी मोडले आणि पहिली दुरुस्ती चालली नाही, तर थांबा. प्रत्येक अतिरिक्त "दुरुस्ती" तुटलेल्या स्थितीवर रचलेली असते, आणि समस्या वाढत जातात.

त्याऐवजी:

  1. शेवटच्या चालणाऱ्या आवृत्तीवर रोलबॅक करा (चेकपॉइंट किंवा Git कमिट).
  2. प्रॉम्प्टमध्ये काय अस्पष्ट होते ते शोधा.
  3. लहान किंवा स्पष्ट विनंतीने पुन्हा प्रयत्न करा.

हा बदल ड्राफ्ट सेव्ह करणे मोडत होता. मी रोलबॅक केले आहे. यावेळी: फक्त हेडरमध्ये मजकूर म्हणून ऑटोसेव्ह इंडिकेटर जोडा. ड्राफ्ट कसे सेव्ह होतात ते बदलू नका.

पायरी 7: पुन्हा बांधणे योग्य कधी आहे ते जाणून घ्या

शून्यापासून पुन्हा बांधल्याने खूप चालणारे तपशील फेकले जातात. ते फक्त तेव्हाच फायद्याचे आहे जेव्हा:

  • उत्पादनाची कल्पना पूर्णपणे बदलली आहे.
  • मूळ संरचना आता आवश्यक असलेले सपोर्ट करू शकत नाही — उदाहरणार्थ, ती स्टॅटिक साइट म्हणून बांधली होती आणि आता खाती आणि डेटाबेस हवे आहेत.
  • प्रकल्प अजून जवळजवळ रिकामा आहे.

पुन्हा बांधताना, काय ठेवायचे ते यादी करा: नाव, रंग, मजकूर, वापरकर्त्यांना आवडलेले भाग.

उदाहरण प्रॉम्प्ट्स

पुढे जाण्यापूर्वी, ॲप सध्या कसे चालते ते सारांशित करा: पेजेस, ते साठवणारा डेटा, आणि तुम्हाला नाजूक वाटणाऱ्या गोष्टी.

मला आवर्ती बुकिंग्स जोडायची आहेत. सर्वात लहान उपयुक्त आवृत्ती कोणती असेल? ती तीन वेगवेगळ्या बदलांच्या रूपात सुचवा जे आपण एका वेळी एक करू शकतो.

शेवटच्या तीन बदलांचे पुनरावलोकन करा आणि चेकआउट फ्लो मोडू शकणारे काही आहे का ते पहा. अजून संपादन करू नका.

सामान्य चुका

  • एका प्रॉम्प्टमध्ये दहा विनंत्या. काही पूर्ण होतात, काही अर्धवट, आणि कोणते ते सांगता येत नाही.
  • अस्पष्ट अभिप्राय. "हे तुटले आहे" किंवा "हे अधिक चांगले करा" अंदाजांना जन्म देते.
  • शेजाऱ्यांची कधीच तपासणी न करणे. एका सामायिक घटकातील बदल तीन इतर पेजेस मोडू शकतो.
  • दुरुस्त्यांच्या दुरुस्त्या करणे. बगमध्ये चार प्रॉम्प्ट्स खोल गेल्यावर रोलबॅक करा.
  • प्रत्येक वेळी संदर्भ पुन्हा सांगणे प्रोजेक्ट नोट्समध्ये कायमचे नियम ठेवण्याऐवजी.
  • अडकल्यावर पुन्हा बांधणे. बहुतेक "पुन्हा सुरू करा" क्षण खरेतर "दोन पावले रोलबॅक करा" असतात.

चेकलिस्ट

  • प्रत्येक प्रॉम्प्टसाठी एक ध्येय.
  • मी काय दिसते आणि काय घडले पाहिजे ते वर्णन करतो.
  • मोठ्या बदलांना कोडपूर्वी नियोजन मिळते.
  • मी काय बदलायचे नाही ते सांगतो.
  • प्रत्येक बदलानंतर मी त्याची, त्याच्या शेजाऱ्यांची आणि महत्त्वाच्या मार्गाची चाचणी करतो.
  • जो बदल काम करतो त्यानंतर मी चेकपॉइंट किंवा कमिट सेव्ह करतो.
  • दुरुस्ती अयशस्वी झाल्यावर मी दुरुस्त्या रचण्याऐवजी रोलबॅक करतो.
  • कायमचे नियम प्रोजेक्ट नोट्समध्ये राहतात जे AI प्रत्येक वेळी वाचते.

Mythex वर सुधारणा

Mythex ही लूप सभोवती बांधलेली आहे:

  • Plan, Build आणि Ask मोड्स. Plan संपादन करण्यापूर्वी दृष्टिकोनावर चर्चा करते; Ask कोड न बदलता उत्तर देते; Build बदल करते. Chat पहा.
  • चेकपॉइंट्स. प्रत्येक यशस्वी वळणानंतर, Mythex एक git चेकपॉइंट सेव्ह करते; Revert to this point मागे नेते. तुम्ही मागील संदेश संपादित करून Discard & resend करूनही त्या बिंदूपासून वेगळा प्रॉम्प्ट वापरून पाहू शकता. पुन्हा न बांधता सुधारा पहा.
  • ज्ञान. प्रोजेक्ट सेटिंग्ज → Knowledge मध्ये कायमच्या नोट्स असतात ज्या एजंट प्रत्येक संदेशावर पाळतो.
  • /test मोठ्या बदलानंतर एजंटला वापरकर्त्याप्रमाणे प्रीव्ह्यूमध्ये क्लिक करायला लावते.

लहान विनंत्यांना कमी क्रेडिट्स लागतात. प्रॉम्प्ट्स स्वतः कसे लिहायचे यासाठी, AI ॲप बिल्डर्ससाठी प्रॉम्प्ट्स कसे लिहायचे; काही तुटल्यास, AI ने बनवलेले ॲप कसे डीबग करायचे पहा.

प्रश्न

मी फीचर्स जोडतो तेव्हा माझे AI ने बनवलेले ॲप का मोडते?

सहसा कारण प्रत्येक प्रॉम्प्ट एकाच वेळी खूप जास्त मागतो, किंवा AI आधीच्या दुरुस्त्या दुरुस्त करत असते. प्रत्येक प्रॉम्प्टमध्ये एकच बदल मागा, तो चालतो का ते तपासा, चेकपॉइंट सेव्ह करा, आणि तुटलेल्या स्थितीवर दुरुस्त्या रचण्याऐवजी रोलबॅक करा.

मी ॲप शून्यापासून पुन्हा बांधावे की सुधारत राहावे?

बहुतेक वेळा सुधारत राहा. उत्पादनाची कल्पना पूर्णपणे बदलली असेल, संरचना तुम्हाला आता आवश्यक असलेले सपोर्ट करू शकत नसेल, किंवा प्रकल्प अजून जवळजवळ रिकामा असेल तरच पुन्हा बांधा. पुन्हा बांधताना काय ठेवायचे ते सांगा.

मी AI ला माझ्या ॲपबद्दलचे निर्णय कसे लक्षात ठेवायला लावू?

ते असे लिहा जिथे AI ते प्रत्येक वेळी पाहील: प्रोजेक्ट नोट्स किंवा ज्ञान फाइलमध्ये, किंवा प्रॉम्प्ट्समध्ये समाविष्ट करता येईल असा छोटा सारांश. प्रेक्षक, शैलीचे नियम आणि जे बदलू नये त्या गोष्टी समाविष्ट करा.

प्रत्येक प्रॉम्प्ट किती मोठा असावा?

प्रत्येक प्रॉम्प्टसाठी एक स्पष्ट ध्येय: एक फीचर, एक बग, एक पेज. निकाल एक-दोन मिनिटांत तपासता येत नसेल, तर तो बदल एकाच वेळी मागण्यासाठी कदाचित खूप मोठा आहे.

Mythex · Pricing · AI सह काहीही बनवा · वेबसाइट आणि अ‍ॅप टेम्प्लेट्स · Mythex ची तुलना · AI अ‍ॅप निर्मिती शब्दावली · मोफत AI अ‍ॅप निर्मिती साधने · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)