AI IDE List
블로그로 돌아가기
목차8개 섹션

यह मार्गदर्शिका सितंबर 2026 की जानकारी पर आधारित है। कीमतें, मॉडल और इंटरफ़ेस के नाम बदल सकते हैं; यह वास्तविक समय की उत्पाद जानकारी नहीं है।

हर प्रॉम्प्ट को स्पेसिफ़िकेशन बनाए बिना उपयोगी प्रोजेक्ट सीमाएँ दें।

जाँच योग्य नियम लिखें

जाँच कमांड, ज़रूरी सोर्स फ़ोल्डर और कुछ आर्किटेक्चर सीमाओं से शुरू करें। “मौजूदा फ़ॉर्म सत्यापन सहायक लें” कहना “साफ़ कोड लिखें” से स्पष्ट है। ये लेखन सुझाव हैं; फ़ाइल नाम और लागू होने के नियम टूल अनुसार बदलते हैं।

शुरुआती निर्देश

उदाहरण को रिपॉज़िटरी के अनुसार बदलकर टूल की दस्तावेज़ित नियम या निर्देश सुविधा से सहेजें।

Before editing, inspect the nearest existing implementation.
Use the package manager already configured in this repository.
Run the relevant checks for changed behavior.
Report any check you could not run and why.
Do not edit generated output directly.

नियम लागू होने की पुष्टि करें

ऐसा छोटा काम आज़माएँ जहाँ निर्देश से दिखने वाली क्रिया बदले। परिणाम और कमांड देखें; असंबंधित काम पर लागू हो तो दायरा घटाएँ। बिल्ड निर्देशों की तरह नियमों की समीक्षा रिपॉज़िटरी के साथ करें।

पहला वास्तविक कार्य: बदलाव, जाँच और समीक्षा

  1. एक छोटी रिपॉज़िटरी चुनें जो पहले से बिल्ड होती हो। साफ़ Git चेकपॉइंट सहेजें और अभी सफल होने वाली जाँच कमांड दर्ज करें।

  2. एक दिखाई देने वाला परिणाम बताएँ, जैसे मौजूदा फ़ॉर्म में अनिवार्य फ़ील्ड जोड़ना। संबंधित फ़ाइलें, मौजूदा सत्यापन और अपरिवर्तित रहने वाला व्यवहार बताएँ।

  3. संपादन से पहले छोटी योजना देखें। प्रभावित घटक, डेटा प्रवाह और जाँच की पुष्टि करें तथा पहले अधूरा संदर्भ पूरा करें।

  4. बदलाव छोटे हिस्सों में जाँचें। निर्भरताएँ, बनी हुई फ़ाइलें, पर्यावरण चर और त्रुटि प्रबंधन भी देखें। सफलता और विफलता दोनों रास्ते चलाएँ।

  5. स्वीकृत परिणाम, समीक्षा का समय और उपयोग दर्ज करें। भुगतान योजना या टीम स्थानांतरण से पहले दूसरे प्रतिनिधि कार्य पर दोहराएँ।

कार्य विवरण का नमूना

लक्ष्य: उपयोगकर्ता को दिखने वाला बदलाव।
संदर्भ: संबंधित फ़ाइलें और मौजूदा कोड।
सीमाएँ: सार्वजनिक API और निर्भरताएँ बनाए रखें।
जाँच: परियोजना की जाँच और विफलता का रास्ता।
समापन: बदली फ़ाइलें, की गई जाँच और शेष सीमाएँ बताएँ।

परिणाम काम न करे तो

सफल उत्तर सही कोड का प्रमाण नहीं है। गलत फ़ाइल बदले तो दायरा घटाएँ और प्रवेश बिंदु बताएँ। कमांड उसी टर्मिनल में दोहराएँ। MCP के लिए सर्वर शुरू होना, प्रमाण-पत्र और क्लाइंट सेटअप अलग जाँचें। उपयोग समाप्त हो तो दोबारा कोशिश से पहले शेष राशि और मॉडल देखें। छोटे बदलाव रखें जिन्हें अन्य काम खोए बिना वापस किया जा सके।

बदलने से पहले सामान्य सवाल

क्या भुगतान सदस्यता में एजेंट का उपयोग असीमित है?

नहीं। कीमत, शामिल उपयोग, मॉडल पहुँच और अतिरिक्त उपयोग अलग हैं। असीमित ऑटोकम्प्लीट का अर्थ असीमित मॉडल अनुरोध नहीं है।

क्या सभी MCP सर्वर एक साथ जोड़ने चाहिए?

अभी आवश्यक एक एकीकरण से शुरू करें। शुरू होने, टूल और भेजे जाने वाले संदर्भ की जाँच करके अगला जोड़ें।

दो एडिटर की तुलना कैसे करें?

एक ही रिपॉज़िटरी, कार्य और स्वीकृति मानदंड रखें। सही बदलाव, समीक्षा मेहनत, सेटअप और वास्तविक उपयोग की तुलना करें।

संबंधित TRAE गाइड

이 글 공유